Accessibility Insights makes code more accessible

We’re all going to need accessible software at some point. It might be because we’re disabled or broke an arm or need to hold a baby. How we’re attempting to access software matters far more than why; accessibility is situational. When we make software accessible by adding assistive technologies, we make it more usable, providing tools that allow it to be used by anyone at any time.

It’s perhaps better to think of accessibility as part of an approach we call universal design. It is characterized by building applications that can be accessed by the widest possible group of people, across all abilities, in as many situations as we can imagine. It’s an important concept that ensures software is accessible by default—that it’s harder to remove accessibility features from user experiences than it used to be to add them.

This means it’s important to address accessibility issues from the very start of a project, ensuring they’re part of our application requirements capture. Once we’re building code, we need to continue the process, ideally ensuring that accessibility is part of our testing process, checked before any code is committed to a source repository or merged with a main branch.

Introducing Accessibility Insights

Microsoft has made inclusive design a key platform in its own products, using a “solve for one, extend to many” model that aims to understand constraints and use them to build inclusive applications. As part of that approach, it uses global accessibility standards, such as the Web Content Accessibility Guidelines (WCAG) to define how it implements accessibility in its own code.

Those standards are now built into a set of accessibility testing tools you can use in your own development process for Android mobile applications, the web, and Windows, downloadable from Microsoft’s Accessibility Insights website. Windows and mobile are desktop analysis tools, whereas the web tool is a browser plug-in for both Edge and Chrome. The tools are open source with active GitHub repositories.

All three tools offer similar features, starting with a FastPass set of quick tests. These give you the most value: an automated way to discover the most common accessibility issues in your applications. You can get a feel for how it works by installing the browser extension and running it over a familiar website.

Running FastPass on a web application

On the web, FastPass ensures that your sites comply with WCAG, testing for features like ARIA (Accessible Rich Internet Applications). ARIA is a common tool for delivering accessible web content, and while many of its features have been rolled into HTML 5, it’s still widely used. Unfortunately, that makes it surprisingly easy to accidentally add an ARIA error to a page. That’s a problem since badly implemented ARIA can affect screen readers and other assistive technologies, often doing more harm than good.

The Accessibility Insights tool will show the document object model path to errors, with a snippet of code to explain exactly what’s wrong. If there’s a simple way to fix the problem, you’ll see a suggested change. There’s also a link to a page on the Accessibility Insights site that explains exactly why the error causes a problem. For example, if a hidden element is still accessible from a keyboard, you’re shown that this makes it silent to screen reader users who can still interact with the element but can’t see what it does.

Often an accessibility error is something you might not have considered. For example, I scanned a popular website to test the tool and found many color-contrast errors. WCAG has a rule about the ratio between foreground and background colors, with the intent of ensuring that pages are readable for as many users as possible. A gray foreground on a white background had a contrast ratio of 2.33:1, significantly less than the standard’s 4.75:1. Accessibility Insights suggests alternate, similar colors that you can try using the F12 developer tools in your browser, aiming to keep your initial design consistent with the WCAG guidelines.

Once you’ve gathered all the details from an automated pass-through, you can start to use the manual tools. The tab stops tool helps navigate through a page, guiding you from element to element via the keyboard. The purpose is to ensure that all interactive parts of a page can be accessed via assistive technologies or simply via tabs for someone who needs to access information but has a broken mouse. Enable the visual helper to add a focus circle so you can see which element is being tested. Once tested, elements are numbered so you can check that they’re visible and accessible and that any overlays open as intended.

I’d recommend using multiple monitors with these tools, as they sit in a separate browser window from your application. You can have your site on one screen and Accessibility Insights open on another, along with the developer tools for your site.

Assessing a site

The tool next provides a guided assessment for your application. First, it details the automated tests carried out by FastPass. This is a more comprehensive version, filling out the assessment form automatically and showing which sections of HTML need corrections. Once the automated tests are complete, the tool walks you through a set of manual tests. These include testing for visual cues to show that an element has focus, exploring the use of ARIA landmarks to enhance application navigation, and much more. The full assessment has 24 sections and needs to be part of your overall UI testing strategy.

It’s worth using the Accessibility Insights tools during development too; a final option in the extension gives access to a set of ad-hoc testing tools. These offer guidelines on how to test specific features, such as colors or tab stops, along with quick access to a list of features that need review.

Accessibility Insights is an important component of your usability testing, whether you’re building an Android mobile application, a website, or Windows software. We need to make software as accessible as possible, focusing on inclusive design to ensure everyone can use our code. Tools like this are essential, and because they are essential it would be nicer to have them built into Visual Studio and Visual Studio Code rather than be optional extras we have to go out and install.