Accessibility overlays – demystifying secrets

What are accessibility overlays? Are overlays good for accessibility? Why overlays are not accessible? Let's explore and demystify secrets.

What accessibility overlay is? Are overlays good for accessibility? What are accessibility widgets? So many questions to answer. Let’s explore accessibility overlays and demystify secrets and unclarities from a human and business perspective.

What accessibility overlay is?

Accessibility overlay (widget) is all about: let me fix automatically, on-the-fly all accessibility issues on your site. No code and no other human actions are required. Once installed on your page you don’t have to worry about digital accessibility.

Going further those tools promise to not only find and fix issues but also to make your site fully ADA (Americans with Disabilities Act) and WCAG (Web Content Accessibility Guidelines) compliant.

But wait. How is this possible?

How does accessibility overlay work?

Behind the scene, it is the JavaScript code snippet embedded within your page. Once it’s installed it waits for the page to be loaded, then determine potential issues and applies fixes when needed. That’s all.

How do I add widgets to accessibility?

If you think about a widget that enhances accessibility through specific features then go ahead. For example: read aloud the content or change the font family or the like. This is good, but you’re looking for automatic fixes for all accessibility issues from a simple human perspective.

Can automated accessibility tools really fix all issues?

Unfortunately, it is not possible. You may feel disappointed now. However, to understand why accessibility overlay won’t be able to fix all issues let’s dive into it a bit deeper.

Are accessibility overlays WCAG compliant?

Conforming with WCAG can’t be done using only tools that claim to fix all accessibility issues automatically. There are cases where you can’t automatically determine the potential issue and apply the solution.

Example: when users enlarge content up to 400% of the default size, they should not have to scroll in their browser in more than one direction – horizontally and vertically. The page should adapt to the actual viewport size.

Due to the code complexity that generates layout fixing issues automatically and without risk of impacting the current page layout is not possible.

Is it possible for an overlay product to prevent the legal risk?

No available overlay product can make a website entirely compatible with any existing accessibility standard, and hence cannot eliminate legal risk.The complete accessibility audit is a combination of automated and manual audits.

Why do accessibility overlays often break page layout and behavior?

From a technical perspective, your site is a combination of HTML, CSS, and JavaScript. From the user’s perspective, there is a page and its layout and behavior. Now, when the page is loaded and the accessibility overlay tool finds the issue, it decides what to do.

Soft issues

Let’s take a look at the very simple case: the image has no defined alternative description (technically a description in the alt attribute). The tool can fix it automatically by adding an empty description. Very well, the first step was done correctly, and it makes an image decorative by automatically adding an alt attribute with an empty value (alt=""). Even more, this change doesn’t impact the layout (we will come to that a bit later).

Assuming all images are decorative on the page, we can think that the issue has been fixed.

Hard issues

Let’s now dive into another case – headings hierarchy. Headings are normally ranked from Heading 1 or HTML element h1 to Heading 6 or HTML element h6. It’s important that your headings are logical, without skipping levels and hierarchies. For example, make sure that h3 element is not followed by h5 without an intervening h4.

So, after loading the page the accessibility overlay found issue that there is an incorrect headings hierarchy and h3 should be set as h2. Easy to fix from the code perspective. However, once the fix is applied your page layout is broken. We are now in the moment called oh, how come?.

The reason is simple: a new heading is styled differently than the previous one. The same styles were not applied, and while the page from a coding perspective may look fine, visually the page layout is broken. Moreover, the previous heading may have attached some behavior that now, after fixes, doesn’t work. So, at this point, we have a broken layout and behavior. That’s not something you’d expect.

The following example represents the original layout:

Now, let’s see what happens when the accessibility overlay tool tries to fix the heading hierarchy:

The heading hierarchy was fixed, but the layout is broken now. That’s because both headers are styled differently; hence, the issue can’t be fully fixed automatically.

Summary in bulletpoints

The overall accessibility overlay idea looks fantastic, but due to technical limitations, it can’t fix all issues automatically. Not convinced yet? Let’s see more examples and concerns.

• Users of assistive technology have already customized their devices and browsers to their preferred settings. The overlay technology may interfere with the user’s assistive technology and override user preferences, forcing them to use the overlay instead. This reduces the website’s accessibility to certain user groups and may prevent access to content.
• The majority of the functionality provided by accessibility overlays duplicates built-in mainstream capabilities seen in today’s browsers and operating systems. There is no use in trying to replicate these capabilities using an overlay. Making people aware of common features would be a significantly more effective method to provide assistance when needed.
• Some overlays may potentially try to detect when an assistive technology is active on a user’s device. This can be problematic if there is no way to opt out of such tracking, because assistive technology is frequently connected with a disability, and disability information is sensitive personal data.
• Live changes may and in most cases impacts the layout and/or behavior. However, custom solutions that are dedicated to a certain case could be acceptable.
• It is impossible to determine all 3rd party solutions on your page and fix automatically issues caused by those solutions. For example, if you have on your site the solution that helps with customer shopping flow then you have no control over what’s being served on your page. Hence, any issue that will eventually be on that 3rd party solution will impact your page and the visitor.
• Negative SEO impacts because of loading the additional scripts, and styles, and applying changes on the page which forces the browsers to re-render the page. Loading and rendering performance are measured by search engines, e.g. Google Core Web Vitals report.
• There is no 100% reliable way to auto-generate an alternative (alt text) description for the image or SVG (Scalable Vector Graphics).
• You can’t determine incorrect HTML semantics and fix them correctly with 100% certainty without breaking the layout and/or behavior.
• You can’t fix wrong behavior generated by JavaScript code. There might be so many different features on the page created by JavaScript. The tool won’t be able to determine any issues related to them.
• You can’t fix the color contrast issue for the text in every case because there is no way technically to determine in a reliable way background and foreground color. For example, the element might be absolutely or fixed positioned or may have defined semi-opacity.
• Application that are using frameworks like Angular, React, VueJS, etc. are having their own way of rendering content. For example, in Angular, a component’s styles can be encapsulated within the component’s host element so that they don’t affect the rest of the application. Angular uses the browser’s built-in Shadow DOM API to enclose the component’s view inside a ShadowRoot, used as the component’s host element, and apply the provided styles in an isolated manner. Shadow DOM serves for encapsulation. It allows a component to have its very own shadow DOM tree, that can’t be accidentally accessed from the main document, may have local style rules, and more. This means that the overlay will be able to audit, but not modify.
• You can’t fix the color contrast issue when the text is on the image.
• Got 2 scroll bars (horizontal and vertical)? There is no way to fix it automatically without impact on the page layout.
• You can’t determine when the content or description of an action makes sense.
• People with low vision need to enlarge text and read it in a single column. When the browser zoom is used to scale content to 400% (it reflows), then it must be presented in one column so that scrolling in more than one direction is not necessary. Determining both scrolls – horizontal and vertical – is easy. Fixing the issue is impossible due to the complexity of the code and making any automatic changes will impact the layout or behavior.
• Fake headings (bold text). A line of bold text might look like a heading, but it will not appear in the content outline, so screen reader users cannot tell that it is important or jump to its content. Its visual weight is also incorrect for the site design. Users would expect a much heavier heading for this break in the content. This could or not be determined. If determined then changing bold text (strong) to any heading is possible, but it will break the layout and/or behavior. That’s not what we want.
• Open captions are embedded in the video itself. There is no way to automatically determine open captions and verify if they make sense.
• Embedded or linked document PDF can’t be fixed automatically.
• Overlay tools may impact the local tool the engineer is using to determine accessibility issues. While trying to test the app changes locally on the computer some overlay tools try to determine other accessibility tools and fool them by saying: Hey, there are no issues. All good!. To make it robust and predictable the engineer must disable the accessibility overlay.
• Changing the HTML semantics: Sometimes automatic algorithms may incorrectly judge that a given HTML element is, for example, a checkbox. So they change its behavior and/or appearance, which can lead to the original element no longer behaving as it was designed.
• The sequential focus order of links, form controls, embedded apps, and widgets must be meaningful. This can’t be determined, especially when the page content changes dynamically.
• Some cases require manual verification and an automated tool won’t be able to fix it. Example: color contrast or indicate status by color only.
• There is a risk that the overlay tool won’t even be available. Many places like hotel rooms, and public places across the world, may have filters and blockers on certain resources/domains.
• Some overlays block certain hotkeys. E.g. Option (or Alt) ⌥ + Command (or Cmd) ⌘ + I (on macOS) or F12 or Control + Shift + I (on Windows/Linux), which opens developer tools in the browser.
• Government Websites Can’t Rely on the Claims of Accessibility Overlays.

Business perspective

While installing an accessibility overlay might be an easy step, the consequences of using it are highly undesirable.

• Every single user that visits your site has a different environment. Adding an extra tool on top of your site pages increases the chances of having broken pages.
• Cost of software development increases because the software engineer must implement changes and test them with and without overlay tool.
• Regardless of the auto-fix overlay tool you use, a potential lawsuit will still include testing.

The recommended solution

The issue should always be fixed in the original place – the source code, user interface design, and content. There are a few ways to approach this work:

1. Perform an automated and manual audit of your website and address all accessibility problems at their core. The automated accessibility audits will give you a consistent way of auditing, especially on large sites.
2. The manual audit should include testing using a screen reader (e.g. Apple VoiceOver, JAWS, Windows Narrator, and NVDA), design review, ensuring that the text of the Web page is not difficult to read, and all actions clearly define their purpose.

Other resources

• Accessibility overlays don’t guarantee compliance with European legislation
• Accessibility Overlay Fact Sheet
• Overlay False Claims