Semi-Automated Testing of a Website Using Browser Plugins

There are many ways to examine a website for accessibility issues, including the use of plugins and tools. Many of these tools are based on the Web Content Accessibility Guidelines (WCAG). In today’s article, I’ll focus on browser plugins that can uncover a large number of accessibility-related issues on websites.

These plugins partly automate the inspection of a website’s HTML code for potential weaknesses. But why focus on HTML code? Many assistive technologies navigate using the accessibility tree automatically generated by the website, which roughly represents the structure of the site in terms of accessibility. Errors in this structure can lead to usability limitations.

In addition to various tools that analyze specific aspects of accessibility, such as contrast checking, Axe Accessibility Testing Tools are especially popular. Google Lighthouse and Wave are also well-known tools. During my project work, I used two additional plugins: IBM Equal Access Accessibility Checker and Microsoft Accessibility Insights for Web, which I’d like to explore in more detail below.

IBM Equal Access Accessibility Checker

I’ll begin with the IBM Equal Access Accessibility Checker, which I use most frequently in my current project context. This browser plugin scans the page being tested and displays the identified issues and manually verifiable problems in a clear table. Each entry includes a detailed explanation of the resulting usability limitations as well as a reference to the relevant guideline. The tool also offers an extended ruleset that includes not only WCAG but additional IBM-specific guidelines.

Not every message indicates a true issue and may therefore require manual review. For instance, it should be verified whether an element is reachable via keyboard and whether the visible focus is clearly recognizable. The tool often lists testing the site in high contrast mode as a recommendation, as this mode offers substantial usability improvements for various visual impairments. Without such a prompt, this feature might be overlooked during accessibility testing.

In cases of false positives—issues flagged that aren’t actually problems—there’s an option to hide these elements from the list. This helps maintain focus on real issues during evaluation. These types of messages are exceptions, but they highlight the importance of manual verification before initiating fixes.

By default, the messages are grouped by element roles, which can be useful for developers in relation to specific HTML elements. Personally, I prefer sorting by requirements or rules. This better groups the types of errors (missing alt text, contrast issues, etc.) and makes it easier to communicate with the whole team, since team members may have varying levels of HTML knowledge.

Microsoft Accessibility Insights for Web

Another product in the field of automated website auditing comes from Microsoft. It exists both as a browser plugin and as a standalone application for testing apps. In this article, I’ll focus only on the browser plugin. It offers various modes of operation, from a short Fast Pass to a more detailed Assessment.

Each method begins with an analysis of the webpage’s HTML code. The tool identifies several accessibility issues, such as contrast problems or incorrectly labeled form elements. It’s comparable to IBM’s tool but presented differently. Further checks follow.

In the Fast Pass, for example, keyboard navigation using the Tab key or arrow keys is tested. A checklist is provided, some parts of which are automatically completed as the tester navigates through the site. During this walkthrough, the focus order is also visualized and entries in the checklist are automatically filled where applicable. If the plugin detects errors (e.g., the focus order does not match the DOM structure), they are recorded automatically. However, responses in the checklist can also be manually edited or reset.

At the end of the test, the findings are presented for review so testers or developers can decide which issues need to be addressed and which do not. Each step should be reviewed carefully and thoughtfully.

The plugin supports accessibility testing with well-structured guidance. Unlike other tools, the evaluation takes place in a separate browser window. This can be placed on a second monitor, for example, but might also be distracting since the user must constantly switch attention between the checklist and the site. One useful feature is the ability to create GitHub or Azure Board issues directly from identified problems, which is especially helpful in a project setting where these tools are used.

In General

Each tool for testing website accessibility has its strengths and weaknesses. The choice of tool depends on the project context, requirements, and sometimes personal preferences. It’s important to note that different tools may detect certain issues differently—or may not detect them at all. However, most issues were identified by all the tools I’ve used.

Even though semi-automated tools can detect a large number of accessibility barriers, additional manual testing is still necessary. These manual checks shouldn’t be limited only to those aspects marked as requiring manual review, but should also include verification of automated findings. Also important: tools cannot or can only poorly detect content-related errors. These tools are excellent aids for testers and developers in identifying a majority of accessibility issues, but manual testing remains essential.

So, what tools do you use? Are you particularly satisfied with one and would like to share it?