Accessibility assessments: The first step toward an inclusive digital product
As a frontend developer, one of the key aspects that you have to consider when you create a digital product, intended to be used by the general public, is related to inclusion. The question is simple.
Is your website, or your product, built in such way that it can be used by everyone?
In recent years, accessibility has become a regulated requirement across the European Union. Companies with digital products that don’t meet the standards risk fines and potential damage to their reputation.
You have a significant responsibility to ensure that your product is usable by everyone, including individuals with various disabilities or impairments, such as those affecting vision or hearing. Designing digital products that are accessible to all users falls under the broader concept of accessibility.
Ideally, accessibility should be considered from the outset of any project. However, if your application isn’t accessible yet, perhaps due to shifting priorities or a lack of user complaints, there’s still time to make improvements.
But don’t get too comfortable. According to the European Accessibility Act, the deadline for compliance is June 28, 2025 [1].
So, where should you begin?
Accessibility assessment
Start with an accessibility assessment. When it comes to making your products accessible, don’t rely solely on automated unit tests for accessibility (although they are valuable). It’s essential to identify what needs fixing before diving into the fixes.
There are several Chrome extensions available to help with this process. One of my favorites is Accessibility Insights for Web [2], an open-source tool developed by Microsoft.
In this example, I will use it to conduct an accessibility assessment. Let’s start by examining some intentionally inaccessible code that violates key rules related to colour contrast, alternative text and missing labels.
<style>
.hidden-text {
color: #f8f8f8;
background-color: #fff;
}
.button {
background-color: #008CBA;
color: #fff;
...
}
...
</style>
<div class="container">
<h1>...</h1>
<img src="product.jpg" width="300">
<p class="hidden-text">...</p>
<button class="button">...</button>
</div>Now, let’s run the report, by selecting “Assessment” in the Accessibility Insights for Web Chrome extension launchpad. A new window will open, with a specific URL.
Automated checks
In my example, the Automated checks feature quickly identified a few accessibility issues. Specifically, it flagged one instance of a missing alternative text for an image (image-alt), which is crucial for users who rely on screen readers. Additionally, it found two instances where the colour contrast didn’t meet the minimum required ratio, which is essential for ensuring that text is readable for users with visual impairments.
However, you can’t rely solely on automated checks to ensure full accessibility. While they’re great for catching common issues, they can’t detect everything. That’s where manual checks come into play.
Manual checks
Manual testing is essential for identifying more complex accessibility problems that automated tools might miss, such as ensuring proper keyboard navigation or verifying that interactive elements are accessible to screen readers.
One helpful feature of the Accessibility Insights extension is the Visual Helper, which marks the specific areas of your page that need attention with a red exclamation point. This makes it easy to see exactly where the issues are, so you know where to focus your manual testing effort.
During manual testing, you’ll interact with a detailed interface that includes a navigable menu on the left side. This menu covers various aspects of accessibility, such as page navigation, parsing, images, and language settings, among others. It allows you to focus on specific elements of the assessment process.
Let’s take native widgets as an example, focusing on the “Instructions” subsection. Each of these subsections includes a description, steps that need to be verified, and references to the relevant WCAG (Web Content Accessibility Guidelines) criteria. At the bottom, you’ll find instances that need testing, which you can mark with Pass or Fail.
In this case, I have an instance of a button element that has an accessible name “Buy Now”, but shows “no value” for the accessible description.
Now, should this test fail?
The answer depends on the context, which is where the know-how of an accessibility expert comes into play. In this case, for the sake of the demo, I’ve chosen to be very strict and mark it as a fail because the accessible name “Buy Now” might not provide enough context about the button’s function.
When an instance is marked as failed, you have to provide a clear explanation of why the test failed and how to resolve the issue. To be more specific, here’s what you need to do:
- Provide a detailed explanation: When you mark an instance as failed, a text explanation will be needed. This is where you describe why the element didn’t meet the accessibility standards. For example, if the instance for the button labelled “Buy Now” was marked as failed, you might explain that the accessible name alone doesn’t fully convey the button’s function (maybe if it initiates a multi-step process or has other complex implications).
- Offer a solution: Along with the explanation, provide actionable steps to fix the issue. In this case, you might suggest adding an “aria-label” to give the user more context. This attribute can describe the button's action in more detail, ensuring that users with screen readers understand its purpose.
In the end, after all the manual checks have been completed, the assessment report can be exported as HTML, and it will look like this:
If you scroll to the bottom of the report, you will find a section with detailed information on each test performed, including more details about the issues that have been found, and the suggested remediations. This section provides an “in-depth” look at each accessibility test, helping you understand exactly what needs to be addressed and how to fix it.
Conclusion
Performing an accessibility assessment is a crucial first step in ensuring your digital products are usable by everyone, including those with disabilities.
Once the assessment is complete, you can move on to addressing the identified issues. This is the time to make necessary corrections and improvements to your digital products, ensuring they meet accessibility standards. By taking these steps, you not only comply with regulations but also enhance the overall user experience.
Bibliography
[1] European accessibility act, https://ec.europa.eu/social/main.jsp?catId=1202
[2] Accessibility Insights for Web Chrome Extension, https://chromewebstore.google.com/detail/accessibility-insights-fo/pbjjkligggfmakdaogkfomddhfmpjeni
