Before I dive into the details of web accessibility, let me explain in my own words what it actually is. WCAG stands for Web Content Accessibility Guidelines. It’s a set of guidelines designed to ensure that websites and web applications are accessible to everyone, including people with disabilities such as visual, auditory, motor, or cognitive impairments. The guidelines provide developers and designers with specific recommendations for structuring and designing content in a way that makes it perceivable, operable, understandable, and robust. The goal of WCAG is to promote digital accessibility, ensuring that everyone, regardless of their abilities or limitations, has access to information and functionality on the web.
In 2025, the European Accessibility Act (EAA) will come into effect. This law mandates that e-commerce companies make their digital services accessible. While there are many details to consider, the key takeaway is that as of mid-2025, WCAG will no longer be optional but a requirement for most businesses.
Before you continue reading, I want to make it clear that I fully support the EAA and advocate for every aspect of WCAG. In this article, part of the bullshit series, I’ll explain our flawed approach. Our approach is too ad-hoc and targets the wrong objectives.
Before I give you a glimpse into what we are doing wrong during the implementation of WCAG, I’d like to highlight what we are doing well. The fact that we are taking action is already great. Let me explain how I see the implementation taking shape.
Many Product Owners, managers, and IT leads have been busy with WCAG over the past year. Driven by the EAA, websites and apps must comply with regulations within a few sprints to avoid potential fines. Naturally, everyone wants to prevent this, so what often happens is that, alongside the standard features developers need to deliver, additional tasks are pulled into the sprint aimed at improving the accessibility of the website and app. Sprints become packed with these tasks, and the issue is expected to be resolved in no time. So far, this sounds quite good: you'll comply with the law, and your website or app will become accessible. You or a fellow developer takes on the role of accessibility expert, tackling most of the tasks. As the documentation prescribes, the right attributes are added to the correct HTML elements, and designers ensure that all designs meet contrast requirements. Small design changes are implemented where necessary.
To know if you're on the right track, there are tools available. Audits and tests scan designs and web pages for accessibility errors. If you've done your job well in the past sprints, very few issues will be found, and if anything is identified, you immediately tackle it as an extra task in the next sprint. In projects where I was hired as a consultant, I often saw that these tests and audits were conducted by external vendors. They provided a clear Excel sheet detailing what was wrong for each URL. This Excel sheet serves as perfect input for designers and developers to further enhance the websites and apps.
Don't get me wrong. You can be proud that the website or app is now accessible; everyone has achieved their goal. However, there is a lot wrong with the way this has been accomplished (and there are certainly positive aspects, so please don't misunderstand me). This project was initiated with the wrong intentions; your manager, product owner, or IT lead aimed to comply with regulations, but legislation should merely serve as a guiding principle. The ultimate goal is accessibility for everyone. This is, in fact, the essence of this entire article: complying with the EAA is not the objective; having an accessible website or app is the true goal.
You and the designer have also made mistakes despite your good intentions. Have you considered the sustainability of your changes? Is your code still accessible six months from now after 100+ features have been added? And do those new features even meet accessibility standards? Will the designer fall back into old patterns after making changes, ensuring that the contrasts in new designs are correct? Do you challenge the designer? And does the one responsible for QA in your team or department tests the accessibility? It’s likely that not everything will hold up. Additionally, you probably worked from a massive list of errors identified by external vendors, solving problems one page at a time. There’s too much ad-hoc thinking regarding accessibility. If an issue was found, you fixed it right away. At the time of testing, the identified issues were valid, but new findings might emerge the next day, and you wouldn’t know because audits and tools are no longer being utilised. So, it’s entirely possible that you comply with the regulations today, but may not do so tomorrow.
Moreover, it's highly likely that within a team, one person was responsible for implementing the accessibility improvements. This allowed everyone else to continue with their tasks, but it left the expert isolated. As a result, only this expert has knowledge of WCAG, meaning that accessibility is not integrated into the daily responsibilities of all team members. This poses a significant risk, as everyone should have at least a basic understanding of accessibility. Furthermore, it’s crucial for everyone to develop a sense of responsibility. Without this sense of accountability, there’s little motivation for individuals to prioritise accessibility unless someone specifically points it out to them.
There is no focus on a structured approach to addressing accessibility improvements. In fact, there is no emphasis on preventing accessibility issues. Accessibility is not just a task; it’s a way of working. It’s the responsibility of everyone on the team. Product Owners should write stories from an accessibility perspective and consider user needs. Designers must test their designs for accessibility before delivery, developers should ensure their component library undergoes audits to test for accessibility, and they should point out small errors to each other through pull requests. Testers need to verify not only that features work through automated technical tests but also that they are genuinely accessible. Accessibility is not a goal, task, or user story. I’m frustrated to say this because it sounds cliché, but accessibility is simply part of our work. We should not deliver anything that isn't accessible. Not to comply to EAA, but to make our websites and apps accessible for everyone.
Accessibility is not a designers thing, or a development task. You should do it with your whole team and department. That means that everyone in the department should have a basic knowledge about accessibility and the impact of the lack of accessibility. You could consider a 101 training, a presentation from the Frontend Architect or an e-learning. Make sure everyone agrees on the definition of accessibility.
The most important rule for everyone to understand is this: accessibility itself is the goal. The EAA, compliance, fancy tooling, or having/being an expert are not.
Don't just start with solving issues. Take a step back and gather your team around to setup a good approach. In my opinion, when using Scrum, accessibility should be part of the `definition of done` And accessibility should be one of all customer-facing user stories. Designers should test their designs. Ideally with real user tests, but also with tooling. Developers should provide feedback at pull request and use tooling during the build-fase of their code. Tooling should be in place to help the team with testing when design and development comes together into a working application of website, and the QA member should take ownership in auditing the tooling from time to time.
Tooling could help each team member with their task, but tooling should only be used as 2nd set of eyes, you should not rely on the tooling itself. You as professional should come up with ideas, and the tooling is only there to double check implementation and outcomes.
Only when everyone has a basic understanding of accessibility and your team has established a clear plan of action, can you start addressing existing issues. Although it might seem like this step should come first, it’s crucial to complete the earlier steps beforehand. This is the only way to create a future-proof approach and ensure that the list of quick wins doesn’t keep growing. Only then will you truly be in control when implementing accessibility.
Additionally, while it may be tempting to have one person handle all the quick wins, it’s actually more effective to have each team solve a few of them. This approach fosters a sense of responsibility across all teams.
When an approach is established and all quick wins are resolved, it’s important to maintain the accessibility of your website or app. This will require time and a mindset shift from the entire team, but accessibility needs to be ingrained in everyone’s thinking. It should be a default consideration when designing, developing, and testing new features. I’ll repeat the unavoidable cliché: accessibility is simply part of your work.
Author:
Jasper Seinhorst
Do you ever feel like the frontend of every website and application has become increasingly complex over time? In the past, we built everything using CSS, HTML, and a little bit of JavaScript, but now everything is done with Angular, React, or Vue, with just a bit of CSS and HTML. What has changed, and is this shift actually a positive one?
Since my childhood, I have been passionate about cars and everything related to them. Even at a young age, I knew every model. I spent hours flipping through car magazines searching for new facts and always dreamed of owning an exotic car. Initially, I used to dream of owning a Ferrari, but as I grew older and wiser,…
As a frontend developer, my days are primarily filled with crafting JavaScript-based components using frameworks like Vue, React, or Angular. These frameworks excel at empowering me to create reusable frontend elements, whether it's buttons, modals, links, or accordions. However, as I reflect on my reliance on these…
