Companies are turning their attention to accessibility and so should you. Why now? With the European Accessibility Act entering into force in June 2025, it's a good time to start planning the steps to perform accessibility audits and make sure all your digital products comply with the regulation.
By the time the legislation is in force, a majority of companies that sell services in the EU will have to follow WCAG guidelines in their digital products. However, it is also an opportunity to reach a wider audience and offer services to a more diverse range of users. In this article, we will explore why accessibility matters and what it entails for product development.
When you're ready to jump straight into the practical side of things, check out our article on how to get started with implementing accessibility.
Why accessibility?
There are many people who live with disabilities. According to WHO, over 1 billion people are estimated to live with some form of disability, which corresponds to about 15% of the world's population. In the EU alone, it totals 135 million. This number includes people who suffer from impaired vision, people with specific learning disabilities such as dyslexia, people dealing with mental health issues, or people who live with motor or auditory disabilities.
Besides permanent disabilities, there are also temporary and situational disabilities that can occur anytime over the course of our lifetimes. As an example, imagine that someone breaks their arm and cannot use a computer mouse, so they temporarily rely on the keyboard only. As an example of situational disabilities, new parents appreciate one-handed modes on smartphones when carrying their babies around. The point here is that everyone can benefit from accessible products and services—it's just a matter of time and circumstances.
This opens up an opportunity for product managers to focus on accessibility during product discovery and make it a part of their product strategies. As a result, the path to WCAG compliance can be guided by user needs and UX improvements instead of just quickly patching the technical issues to cover what's needed by the regulation.
Interested in learning more? Watch our QA Crew Talk about Accessibility.
What counts as accessibility?
Generally speaking, accessibility consists of three pillars that need to be covered—accessible code, design and content:
Accessible code refers to the markup language, which should be as semantic as possible and should follow a logical structure. For example, ARIA roles and attributes, which define accessibility roles for assistive technologies, should be used when necessary. This is important because people with visual impairments use screen readers that interpret the meaning of the website based on the markup used. Semantic HTML ensures that tags like <header> or <footer> clearly communicate the role of the element. Screen reader users also generally proceed in a linear order through the website, so all elements should follow a logical order, such as the correct use of <h1> to <h6> tags. If the structure doesn't follow the HTML rules, users with screen readers will get lost.
When we talk about accessible design, several examples illustrate its importance. One fundamental rule is that colours alone should never be used to convey information. You can't give instructions such as “Please, correct the field forms marked in red” because there are many people with colour blindness who are not able to distinguish between colours. Relatedly, an important 4.5:1 ratio is the minimum WCAG recommended luminance ratio between colours used for the foreground and background in regular texts to be readable for people with impaired vision.
The third pillar is accessible content. All images and icons should have an alternate text that clearly describes the meaning of the image for someone who can't see. Generally, a 9th-grade pupil should be able to understand your website, unless the content is intentionally targeted at a specific target audience (e.g. scientific content). In the same manner, links should be distinct and clear. For example, you should say “Read our full mission” instead of “Learn more”, and avoid using the same label with multiple links.
How to get started?
The right moment to start is as soon as possible. The sooner you kick off, the more money you will save. A well-known case study conducted by Deque found that 67% of accessibility defects that were detected using automated testing originated in the design stage. This is one of the cheapest parts of the project in terms of hours needed to fix the issue. Conversely, if you start fixing accessibility issues only after you've gone to production, it can take up to 10 times more time!
But where exactly should you begin? In our follow-up article, Accessibility in product discovery: 5 steps to get you started, we dive deep into practical steps you can take right away. From digesting relevant data to conducting usability testing with real users, you’ll learn how to integrate accessibility into your product development process.
