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?
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.
How is it possible to automatically fix all accessibility 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.
What’s wrong with accessibility overlay?
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.
Let’s now dive into another case – headings hierarchy. Headings are normally ranked from
1 or HTML element
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
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.
- 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 (
alttext) 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 the color contrast issue for the text in every case because there is no way technically to determine in a reliable way
foregroundcolor. 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
shadowDOM 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
incorrectfor 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.
- 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.
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:
- 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.
- 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.