Information Management, A Proposal

Yesterday, the Web turned 30.

Thirty years ago, Tim Berners-Lee submitted a document called “Information Management, A Proposal,” his formulation of an information network for sharing and exchanging information at CERN, marking the birth of the World Wide Web. Three decades later, the Web has permeated every pore of our societies and daily lives and the number of people with access to the web has surpassed 50 percent of the population of humans on this planet. The Web is by far the most impressive and revolutionary technological invention mankind has ever managed to create. As with every new technology, the Web started with a lot of enthusiasm and great hopes. Finally, information would be free and available to all, regardless of gender, religion, place of birth, or social status. The Web is for everyone!

Except, it is not.

Also yesterday, Ethan Marcotte expressed his deep frustration over the results of WebAIM’s latest study covering the state of accessibility on the Web. WebAIM analyzed the top 1 million home pages and although – or maybe even though – they only looked at the things that could be detected automatically, “the results paint a rather dismal picture of the current state of web accessibility.” I don’t want to list all of the findings here. Instead, please look at them yourself. Only to give you a first idea of what we are talking about: 97.8% of home pages had detectable WCAG 2 failures. Thirty years after its invention, we obviously failed miserably in keeping the original promise of a Web that is inclusive and empowering to all. As Ethan rightfully points out, “we’ve created a web that’s actively excluding people, and at a vast, terrible scale. […] Improving the state of accessibility on the web is work we have to support. The alternative isn’t an option. Leaving the web in it’s current state isn’t fair. It isn’t just.”

I also really like Ethan’s suggestion that instead of trying to get “accessibility” right at large, maybe we could all do one thing this week to broaden our understanding of how people use the Web. I’d even add: Write about it, too.

Léonie Watson, an accessibility advocate who recently recorded a webinar with Smashing Magazine that is freely available and that I highly encourage you to watch and listen to, agrees and shared this quote with me, which she included in one of her talks:

I think Léonie and Ethan are right: We would certainly not be talking about the Web as the inaccessible, discriminatory mess it appears to be, if we had all improved it one bit at a time. But as much as I appreciate that this quote doesn’t blame anyone directly and, in a way, also acknowledges that building something accessibly is often quite challenging and even harder if you try to solve everything at once, I also fear that it leaves too much room for interpretation and excuses. There simply are no excuses. Accessibility is a civil right. Or to put it another way: If your work isn’t accessible, it’s not done yet. We are all accountable. And we should be held accountable.

That is not to say that all of this is easy or that you’re a bad person if there are still things that could be improved. Of course not. But let’s be honest: Far too often, accessibility is still a mere afterthought in digital projects, if it is considered at all. I happen to see a staggering discrepancy between what is discussed by a relatively small group of thought leaders who share a deep understanding of and interest in accessibility and many of the people in agencies, marketing offices, and development shops doing the ground work. If we want to invoke change, we need to find the root cause of the devastating state of accessibility. And for this, we have to look at where and especially how the majority of sites gets built.

Because reality still often looks somewhat like this: Neither the client who wants to spend as less money as possible for a site nor the agency that promised a stunning, state-of-art design are even aware of accessibility as an important topic to consider. Maybe, the client has heard of “response web design” (no typo) and of course they need tracking. KPIs FTW! But many just don’t know that a website explicitly has to be built to be accessible. Maybe some also just take it for granted. But certainly, it won’t be part of their project requirements.

Many agencies, then, are too busy getting miscalculated projects out of the door that pose a challenge on so many levels: All those different static Photoshop or Sketch layouts that now also have to be broken down into Atomic design components and documented in a style guide. Managing the creation of all of the content and then replacing it in the layouts again. Including last minute change requests by the client who “just doesn’t understand good design.” Then handing everything over to the other company that does the frontend development. Accessibility? Come on, we need to finish the job and, by the way, we’re already running out of budget! Also, the client didn’t ask for it, specifically! But we can maybe leave a note for the devs – that’s their responsibility anyway, right?

At the bottom of the food chain and with an unrealistically set deadline approaching rapidly, the developers are struggling with their build process and with making sense of poorly documented static layouts that have to be translated into React components or, alternatively, Twitter Bootstrap. That the external developers in Asia are working in a different time zone doesn’t help, either. Accessibility? That wasn’t a requirement, as far as I know. Maybe, if there’s some time left, I’ll add some ARIA roles in the end. Alt texts for images? Nobody sent us those.

Of course, there are countless other ways in which things for the Web get built and maybe I’m exaggerating a bit here and there – but then again, not so much. If an inaccessible site gets built, then obviously nobody thought of accessibility as being important enough to raise their voice, at no step of the process. But then again, nobody builds inaccessible websites on purpose. And that’s exactly why it is so important to never stop advocating for accessibility. Every day. Persistently and passionately. Because it still can work if we keep making noise.

That being said, this job is never done. We have to keep educating not only fellow designers and developers, but also clients and other stakeholders. It is vitally important that they, too, care and see the need for building inclusive experiences. It is hard work to raise awareness. Yet there is no other option. We can all do better – and never stop learning.

So follow people on social media, go to conferences and meetups and talk to people about their struggles and successes, read articles and newsletters, listen to podcasts and most importantly: Consider accessibility in every project you are part of. Ask why when accessibility isn’t considered, file bugs, and insist on improvements, regardless of your role in the team – because accessibility should be part of every step of the process. Plan with accessibility in mind, design with accessibility in mind, prototype with accessibility in mind, develop with accessibility in mind – and learn how to test it. There have never been better tools at our disposal. And then, share what you've built and what you learned along the way.

There really are no excuses for building inaccessible websites and applications in 2019. As Ethan wrote, we are all constantly under deadlines. But that’s no excuse for excluding people from a medium that still comes with the promise that it’s for everyone. It’s our job. Let’s not wait another thirty years. Let us fix this together.

~