Accessibility Widget Competitor Performance Testing Methodology
Accessibility Widget Competitor Performance Testing Methodology
To compare the front-end impact of competing accessibility widgets, we tested each tool in the same controlled way: loaded on a blank page, measured before and after user activation, and reviewed using browser developer tools in both Chrome and Firefox.
The purpose of this test was to understand what each tool adds to a customer’s website in practical terms: download size, number of requests, browser workload, visual stability impact and client-side storage behaviour.
Test setup
Each competitor widget was installed on an otherwise blank HTML page. This allowed us to isolate the files and behaviours introduced by the widget itself, rather than measuring the host website, theme, CMS, analytics stack or third-party scripts already present on a real customer site.
Testing was carried out using Chrome and Firefox developer tools. For consistency, network throttling was applied across all tests at 20 Mbps. This was used to create a controlled comparison point between products rather than to replicate every possible real-world connection speed.
For each product, we recorded the assets loaded by the widget, including JavaScript, CSS, SVGs, fonts and other files that were introduced specifically by the accessibility tool. Where Google Fonts or similar third-party assets were loaded only because of the widget, these were included in the widget payload.
Each competitor widget was installed on an otherwise blank HTML page. This allowed us to isolate the files and behaviours introduced by the widget itself, rather than measuring the host website, theme, CMS, analytics stack or third-party scripts already present on a real customer site.
Testing was carried out using Chrome and Firefox developer tools. For consistency, network throttling was applied across all tests at 20 Mbps. This was used to create a controlled comparison point between products rather than to replicate every possible real-world connection speed.
For each product, we recorded the assets loaded by the widget, including JavaScript, CSS, SVGs, fonts and other files that were introduced specifically by the accessibility tool. Where Google Fonts or similar third-party assets were loaded only because of the widget, these were included in the widget payload.
Each competitor widget was installed on an otherwise blank HTML page. This allowed us to isolate the files and behaviours introduced by the widget itself, rather than measuring the host website, theme, CMS, analytics stack or third-party scripts already present on a real customer site.
Testing was carried out using Chrome and Firefox developer tools. For consistency, network throttling was applied across all tests at 20 Mbps. This was used to create a controlled comparison point between products rather than to replicate every possible real-world connection speed.
For each product, we recorded the assets loaded by the widget, including JavaScript, CSS, SVGs, fonts and other files that were introduced specifically by the accessibility tool. Where Google Fonts or similar third-party assets were loaded only because of the widget, these were included in the widget payload.
Payload measurements
We separated payload into three stages:
Unopened payload
The amount of data loaded before the user interacts with the accessibility opener. This is important because it affects every page view, including users who never open or use the widget.
Activated payload
The additional data loaded once the user opens or activates the widget. This shows the extra cost of using the tool after the initial page load.
Total opened payload
The combined payload after the widget has fully loaded and been opened. This gives a practical view of the total front-end weight introduced when the accessibility interface is used.
For each stage, we totalled the files loaded by the tool, including relevant CSS, JavaScript, SVGs, fonts and widget-specific supporting assets.
We separated payload into three stages:
Unopened payload
The amount of data loaded before the user interacts with the accessibility opener. This is important because it affects every page view, including users who never open or use the widget.
Activated payload
The additional data loaded once the user opens or activates the widget. This shows the extra cost of using the tool after the initial page load.
Total opened payload
The combined payload after the widget has fully loaded and been opened. This gives a practical view of the total front-end weight introduced when the accessibility interface is used.
For each stage, we totalled the files loaded by the tool, including relevant CSS, JavaScript, SVGs, fonts and widget-specific supporting assets.
Performance indicators recorded
Alongside payload size, we recorded several browser-level indicators:
Main thread time
The amount of time spent by the browser processing the widget’s JavaScript and related work on the main thread. This matters because heavy main-thread activity can affect page responsiveness, especially on lower-powered devices.
CLS impact
Any observed Cumulative Layout Shift impact caused by the widget loading or opening. This helps identify whether the tool moves visible page content or introduces instability into the user experience.
Network requests
The number of separate network requests made by the widget. Some tools made a high number of requests, with certain competitors making up to 38 requests. Request count matters because even where individual files are small, many separate requests can still add overhead, complexity and third-party dependency.
Storage method
We recorded whether the tool used local storage, first-party cookies, third-party cookies or cross-site cookies. This helps assess privacy, consent and compliance considerations, especially where preferences, identifiers or user settings are stored in the browser.
Alongside payload size, we recorded several browser-level indicators:
Main thread time
The amount of time spent by the browser processing the widget’s JavaScript and related work on the main thread. This matters because heavy main-thread activity can affect page responsiveness, especially on lower-powered devices.
CLS impact
Any observed Cumulative Layout Shift impact caused by the widget loading or opening. This helps identify whether the tool moves visible page content or introduces instability into the user experience.
Network requests
The number of separate network requests made by the widget. Some tools made a high number of requests, with certain competitors making up to 38 requests. Request count matters because even where individual files are small, many separate requests can still add overhead, complexity and third-party dependency.
Storage method
We recorded whether the tool used local storage, first-party cookies, third-party cookies or cross-site cookies. This helps assess privacy, consent and compliance considerations, especially where preferences, identifiers or user settings are stored in the browser.
What was included
The measurement included files and browser activity attributable to the accessibility widget itself, such as:
Widget JavaScript
Widget CSS
SVGs and icons
Fonts loaded specifically for the widget
Configuration or preference files
Third-party assets introduced by the widget
Storage written by the widget
Requests triggered by opening or activating the widget
The measurement included files and browser activity attributable to the accessibility widget itself, such as:
Widget JavaScript
Widget CSS
SVGs and icons
Fonts loaded specifically for the widget
Configuration or preference files
Third-party assets introduced by the widget
Storage written by the widget
Requests triggered by opening or activating the widget
What was excluded
The measurement was designed to isolate the widget, so it did not include:
The weight of a real customer website
CMS, theme or template assets
Host-site analytics, consent tools or advertising tags
Images or content belonging to the host page
Performance issues caused by the customer’s existing site
Important limitations
These figures should be treated as controlled comparative measurements, not universal performance scores. Actual impact on a live website will vary depending on the host site, caching, geography, device speed, browser, consent configuration and how the widget is implemented.
The test does not assess the accessibility quality, WCAG conformance, remediation accuracy or legal adequacy of each tool. It focuses only on the front-end payload, browser performance signals and storage behaviour introduced by the widget.
Why this matters
Accessibility tools are often evaluated on features alone, but their technical footprint also matters. A tool that loads a large unopened payload affects every visitor, not only users who open the accessibility interface. High request counts, heavy JavaScript execution, layout shift and cross-site storage can all introduce performance, privacy and operational considerations for site owners.
By measuring unopened payload, activated payload, total opened payload, main-thread time, CLS impact, request count and storage method, this comparison gives a clearer view of the real browser-side cost of each competitor tool.
Accessibility tools are often evaluated on features alone, but their technical footprint also matters. A tool that loads a large unopened payload affects every visitor, not only users who open the accessibility interface. High request counts, heavy JavaScript execution, layout shift and cross-site storage can all introduce performance, privacy and operational considerations for site owners.
By measuring unopened payload, activated payload, total opened payload, main-thread time, CLS impact, request count and storage method, this comparison gives a clearer view of the real browser-side cost of each competitor tool.
Feedback
If you have any questions about our comparison testing methodology, please contact us using the information below:
Email: info [at] getadjustable [dot] com
Contact us: Contact Adjustable
Address: Adjustable, 71-75 Shelton Street, Covent Garden, London, WC2H 9JQ.
If you have any questions about our comparison testing methodology, please contact us using the information below:
Email: info [at] getadjustable [dot] com
Contact us: Contact Adjustable
Address: Adjustable, 71-75 Shelton Street, Covent Garden, London, WC2H 9JQ.