As a freelancer helping larger companies achieve their goals, I’ve gained a lot of insights into how people work. And I know many people — including me — have said this for over a decade but it bears repeating: We have fantastic JavaScript (TypeScript included) developers who can build impressive solutions to complex problems. But there are still very few frontend developers today who truly know how to write semantic HTML and build with accessibility in mind. This is more important than ever, especially with the European Accessibility Act (EAA) now being enforced across Europe.

In almost all of the projects I’ve been working on, people relied on component libraries like MUI, Mantine or similar for their React software. If we implemented custom markup, it was mainly a div-soup that actually contained the relevant semantic information — just not in HTML but in custom data attributes. Now when we’re talking about accessibility, it’s the same idea that many developers come up with: Let’s add more informational attributes. Let’s add focus handling.

Adding code is easier than refactoring it. To add bits of code, you don’t need to fully understand everything. To refactor, you need to.

It’s the same old problem of software engineering: Adding code is easier than refactoring it. To add bits of code, you don’t need to fully understand everything. To refactor code, you need to.

How to convince people about semantic markup and accessible code

I’ve tried to convince people with simple arguments about accessibility, machine-readability, robustness of a codebase but it never had the effect I intended. What really worked was doing a demo with a Screenreader showing them that I close my eyes and navigate through the project using nothing else than the screenreader. Usually, this has the effect of people being surprised that anyone can use such an assistive technology (known as e.g. "screenreader") and how bad the status of the application is in terms of accessibility.

Next step is to explain that accessibility is a step-by-step process. You can’t just do it right from the beginning, especially if you’re just starting. It’s iterative and learning by doing:

1. Get used to the screenreader and use it often on many websites or apps you regularly use to realise what’s possible.
2. Check your knowledge and improve: Check the patterns by W3C WCAG to get an idea of what’s needed in code.
3. Improve the basic HTML (JSX and TSX are just HTML with Type-/JavaScript-bridges) and check the app again.
4. Now slowly start to play around with the huge beast called ARIA. Be aware that the official guideline says "no ARIA is better than bad ARIA" which is what I referred to earlier. Please don’t add aria attributes everywhere and think it’s good practice or helps to improve accessibility. These attributes are great but test it well and make sure what you do is useful.
5. Slowly understand how too much information can be worse than no information.
6. Check the countless resources on the web about accessibility and ask people. You’re not alone here, there are few people who don’t need to ask others in this area and getting feedback from colleagues is always great in this case.

Is semantic markup and accessibility easy? No.

No one said that accessibility is easy. Even semantic code is not always trivial to achieve in modern web applications. You can tell your manager and reference me (or any other dev working in the field), if needed. It’s not your fault that you didn’t know about it before, frontend development has become so complex that focusing on specific parts is good.

If there’s anyone to blame though there’s no need, it’s Product ownership. As a Product owner, I have the power to decide which quality my software should have. If I decide for quick development, it’s no wonder to have poor semantics or accessibility. If I set accessibility standards and tell the team about it, they can and will handle that.

Start somewhere

With new laws going into effect these days, it’s easy to get overwhelmed by the requirements. It’s good to comply with WCAG 2.2 Level AA but please start and improve step-by-step. If you’re owing a complex web app, this is not a one-off thing, it’s not done in a few days but will take weeks or months to do it right. Nevertheless be aware that every single improvement that adds to semantics and therefore accessibility adds to the user experience of many people. It may not be perfect yet but it will become if you strive for it.

Change people’s minds

Nothing is as powerful as seeing people changing their minds and way of thinking within a few months. Suddenly, people refer to contrast, use a screenreader, ask which UX-pattern is better or realise how complicated and unintuitive the current product is for newcomers.

Use the power to unblock and improve your team’s workflows

Finally, there’s a good chance that during this process it gets more clear how unrefined and unclear the Acceptance Criteria, the Product Value for the customer for a specific feature were in the past. Refinements will take a bit longer but QA easier and faster than before with less bugs or follow-up improvements being introduced.

Take the opportunity to analyse your current workflow (no matter if Scrum, Kanban, or other) and improve it based on where you see a lack of resources, process blockers. As hybrid-role person (Scrum Master and Frontend developer) I helped my teams pointing it out and starting to improve it. The result? People are happier and can work in a calmer mode. Managers are happier because the team effort is more predictable and the result is more stable, often of better quality.

What’s this all about? Accessibility is a core part of building products that work for everyone. It can help people becoming better developers, product owners, QA-testers, UX-designers.