It’s been over a year now that, after reading an article by Ethan Marcotte, I wrote about why we all need to do better to make the Web truly inclusive. Ethan had shared the results of WebAIM’s 2019 study covering the state of accessibility on the Web and the results were devastating: 97.8 % of the sites had detectable WCAG 2 failures. The study seemed to be a wake-up call and over the following year, accessibility as a topic received much more attention than in previous years – at least that was my perception. But in February 2020, the next WebAIM study showed the exact opposite: Instead of making the Web more accessible, we actually managed to make the Web even more inaccessible. Now, 98.1 % of the sites had detectable accessibility issues.
As I wrote back then, nobody builds inaccessible websites on purpose. Mostly, it is still a lack of awareness. But this lack of awareness reveals a problem that runs much deeper: It shows a lack of diversity within the teams that build those websites. As Olu Niyiawosusi writes in her great article “Building the Woke Web: Web Accessibility, Inclusion & Social Justice” for A List Apart:
Hiring inclusively creates teams full of people who aren’t like you or each other. And those kinds of teams build better products, bring better ideas to the table, and better reflect the user base of the majority of products. It is important to remember that diversity isn’t just about race or hiring women; there are neurodiverse people, people with physical disabilities, people of other genders, people from various backgrounds, and many other marginalizations than could be listed here.
One of the sites that I’m working on has to be WCAG-compliant by the end of September to comply with the European Accessibility Act. We are currently working on improving the codebase and we will also do extensive accessibility testing over the next months. But one thing bothers me already: While it is great to have the budget to test for compliance with accessibility guidelines, there is currently no time and budget planned for doing accessibility tests with real end-users who, for example, are using assistive technology to access the Web. Also, we don’t have anyone on the team who could add their experience as a person with access requirements. And this is exactly the problem that many teams face. On that note: I will try to share as many experiences from this project as possible. Maybe it will help other teams avoid some of the errors we made and will run into.
Building the inclusive Web will take a long time, obviously, and it requires all of us to understand that inclusive, accessible, and performant websites and apps must not be a “nice-to-have” anymore. Building inclusive products is a requirement and if our work isn’t accessible, it’s not done yet. Testing for compliance is a good start, but going forward, we will also have to include the voices of the people who depend on our solutions. And ultimately, there is no better way to do this than to hire them.
-
This is the 15th post of my 100 days of writing series. You can find a list of all posts here.
~
