Back to Blog Posts

Toolbars, overlays and testing: demystifying the tech behind online accessibility

AudioEye

Posted April 15, 2020

Share this post

Whether you’re working for a government agency or a private-sector company, you need to ensure that your website is accessible for all users. In the US, courts are overwhelmingly ruling in favor of digital accessibility. Hundreds of organizations are being sued every month for violations of the federal Americans with Disabilities Act (ADA), and many states are now passing online-specific accessibility legislation too.

Yet accessibility remains a hard problem: different people recommend different approaches, it’s easy to get bogged down in the technical detail, and there’s a lot of misleading information out there.

To understand how to make a website truly accessible—which, in the opinion of most legal experts, means conforming to the current version of the Web Content Accessibility Guidelines (WCAG)—you need to understand a little about the technology that AudioEye and other accessibility specialists provide. This blog takes a high-level look at three of those technologies: toolbars, overlays, and expert-mediated testing.

What is a toolbar?

From a technical perspective, a toolbar is a small piece of code that you can add to an existing website, which displays a set of tools that users can apply to change the appearance of the site. For example, the tools might include a way to toggle the website into a high-contrast mode, or increase the size or spacing of the fonts to make them easier to read.

Toolbars are the simplest approach to making a website more personalized based on an individual’s specific needs, and it’s a good idea to have one: different users have different requirements, and there’s no “one size fits all” solution, so it makes sense to allow users to customize the way they view your site to meet their unique needs.

However, a toolbar alone doesn’t make your site WCAG-compliant. The problem is that toolbars rely on the user to browse your site, recognize what the problems are for them (the font is too small, the contrast between text and background is too low, and so on), and apply the appropriate tools to fix them. But what if the user can’t see the text at all when they first visit the site, or doesn’t understand how to apply the tools?

The point is: you need to provide a baseline level of accessibility to make the site usable as soon as it loads. The role of the toolbar is then to allow the user to fine-tune their experience and improve on that baseline—it doesn’t replace the need for your site to be accessible in the first place.

Ok, then what’s an overlay?

The next step up in terms of accessibility technology is an overlay. Again, this is a piece of code that you can inject into an existing website, which alters the way the website is displayed. The difference is that unlike a toolbar, an overlay doesn’t wait for a user to select options to make the site more accessible—instead, it automatically evaluates the website’s code, identifies accessibility issues, and fixes them automatically before the content reaches the screen.

As a result, when a user first visits your website, they’ll see a version that already has many remediations applied. Pervasive issues impeding access for users relying on assistive technologies such as screen readers should no longer be a problem, and the user should be able to navigate much more easily from the moment the site loads, without needing to tweak the settings manually.

The overlay controversy

Overlays are controversial, though, because some commentators on accessibility think they take fundamentally the wrong approach.

According to this school of thought, instead of relying on an overlay to remediate the problems in your site just before it gets rendered on screen, you should be fixing those problems at the root by rewriting your website’s source code to comply with accessibility standards.

This is known as a “shift left” approach, because it shifts the responsibility for accessibility to the earliest possible stage in the development process; conversely, applying overlays and other tooling on a just-in-time basis is known as a “shift right” approach, because it leaves accessibility to the end of the process.

Shift left seems like a persuasive argument, because it seems intuitively correct to prefer curing the disease to treating the symptoms. As a result, both “toolbar” and “overlay” are now dirty words for those who think shifting left is the best way to solve the problem.

But in the real world, it’s not that simple. In many cases, your organization won’t have full control of its website’s source code, especially if that website is generated using a third-party content management platform. And even you do write all your webpages from scratch, it’s very difficult for your developers to become experts in the accessibility standards and ensure that every line of code follows all the guidelines perfectly. What’s more, the standards are constantly evolving, as are the tools that people with disabilities use on the web, so the work is never-ending.

For most companies, while shifting left might be the long-term goal, shifting right is essential in the short to medium term. Given the threat of lawsuits, you need a quick way to make sure your website is accessible today and will remain accessible in the future. An overlay is one of the best ways to ensure that when there’s an accessibility issue in your underlying code, it doesn’t slip through and impact your users in production.

Why overlays aren’t enough

Nevertheless, one of the chief criticisms of overlays does ring true: as shift left advocates often point out, overlays can’t fix all of the accessibility issues a site can have. Some aspects of WCAG compliance are just too difficult for the simple logic of today’s overlays to automatically detect and remediate—and even though new artificial intelligence and machine learning techniques are broadening the scope of what overlays can do, there’s still a long way to go.

As a result, it’s estimated that most overlays only catch about 30% of the accessibility problems that WCAG describes. And while fixing those 30% automatically can be a huge time saving, it does nothing to protect the organization from legal risk, since it only takes one unaddressed issue to spark a lawsuit.

Doing the right thing

So what can we do about the remaining 70%? That’s where testing and custom fixes come in. At AudioEye, with our Managed service, our team of expert accessibility testers manually checks and monitors our customers’ web content, using the most common assistive technologies. This enables us to provide custom remediations to issues that automated checks can’t (yet) detect on their own. Our Pro service provides web owners the same tools we use to test and fix site-specific problems themselves. That’s because, in order to be truly compliant, there must be what we call a “human in the loop” as part of the accessibility process. 

That’s why our multi-tier approach (toolbar, overlay, testing, manual remediation, and continuous monitoring) gives you the best possible assurance that your websites will remain fully compliant with the latest accessibility standards, regardless of the state of the underlying source code. And as a side-benefit, that means your developers can focus on building pages, adding features and delivering business value, while leaving it to us to solve the inevitable accessibility headaches.

With AudioEye’s comprehensive accessibility strategy, “toolbar” and “overlay” don’t need to sound like dirty words for your users with disabilities, and you can achieve immediate results without the cost and complexity of shifting left. Start your accessibility journey with AudioEye today.

Share this post

Subscribe to our blog

Sign up for the latest stories about accessibility and AudioEye.