How to prevent the collapse of society by building an accessible web
It’s 2031. Society, as we knew it in 2021, has officially collapsed. Broken hardware and a very slow internet connection are all we have left.
Accessibility on the web is now paramount to the survival of the human race.
But how do you ensure your website is accessible amidst a raging apocalypse?
Join whitep4nth3r to explore why only the most accessible and inclusive websites will survive an apocalypse, how you can utilise free tools to ensure you are building for the apocalypse, and why all of this is more important than ever now, in 2021.
How to prevent the collapse of society by building an accessible web. Hi friends, I'm Salma. I help developers build stuff, learn things, and love what they do. If you've seen me on the internet already, you might know me as whitep4nth3r or white-p-4-nth-3-r if you use a screenreader. I am a Developer Evangelist for Contentful, and if you've never heard of Contentful, it's a headless CMS with a REST API, GraphQL API, generous free community plan limits, and some great CLI tooling and other packages to help you build great stuff.
Stephen Hawking said, "I believe that life on earth is at an ever-increasing risk of being wiped out by a disaster, such as a sudden nuclear war or genetically engineered virus or other dangers."
It's 2031. The apocalypse has arrived. The internet is running on a slow 3G connection, and display screens are broken. And this is what people are now Googling for — how to build a fallout shelter. And accessibility on the web is paramount to the survival of the human race. So, how do we prepare the web for the apocalypse of 2031? And why is this important now?
In the apocalypse, time-to-interactive is the difference between life and death. People need to know how to fight off those zombies as quickly as possible.
So what's very interesting is that the statically generated Next.js version s actually very very comparable to my static HTML page — although my static HTML page does kind of win. So these Jamstack frameworks are pretty good.
In the apocalypse, screens are broken. Everything is a wasteland. You don't see fancy website designs and animations anymore.
There are almost two billion websites in the world, and 96% of those websites use CSS. And why is this bad news for the apocalypse? developers.google.com tells us that by default, CSS is treated as a render-blocking resource, meaning that the browser won't render any processed content until the CSS object model is constructed. This page recommends that we keep our CSS lean, deliver it as quickly as possible, and use media types and queries to unblock rendering. I say in the apocalypse let's not do that. Because in the apocalypse, time-to-interactive is the difference between life and death.
How can we serve critical content faster? Do we also abandon CSS?
You might have noticed I like tattoos. There's a big saying in the tattoo industry — go big or go home. In this case, I say go small or go die. So let's take that static HMTL page and make it as small as possible.
Let's remove all CSS and class names. Every byte counts. Let's remove useless font imports. We can't see them on broken screens. Let's remove SVGs — we don't need those bytes. Let's turn these links into just really simple links that don't even need any aria labels or anything like that. And a little trick I found as well. I'm going to replace the favicon with a sneaky zero kilobyte favicon. You might notice that in the network tab if you don't have a favicon on your site — the browser will throw a 404. I found a little way to make a base64 encoded string masquerade as a favicon. It's zero kilobytes. We just put that string into our head and there we go.
So here's what my page looks like now. It actually looks pretty well laid out. We've got links, we've got sections, we've got lists — and it actually looks very much like this very iconic website. It's lightweight. It's responsive. And it just works. So how does my no-CSS page compare to my HTML with CSS? So here we go — 100kb versus 4.6kb — and on slow 3G — 4.7 seconds versus 2.1. And if we look at the Lighthouse performance on web dev measure — everything is 100. That's going to rank really well in Google search results — and we're going to get to that later.
In 2021 WebAim surveyed one million home pages for accessibility
And across those one million home pages, over 51 million distinct errors were detected. That's an average of 51.4 errors per page. So what's going wrong? It seems pretty broken! Here's a breakdown of the most common failures from this report, and let's look at these, one by one, and see what's going on.
Low contrast text
86.4% of home pages — and what's that caused by? CSS — and we already know we're going to abandon that, but let's have a look. I looked at some of the top 50 websites in the world to try and find these errors and they were present on quite a few of them. We've got youtube.com, and this violation appears in the little copyright disclaimer on the sidebar. Now, you may think this doesn't matter really, but let's have a look. We've got the HTML here, and the colour contrast error is caused by this CSS rule. The background and the foreground colours do not offer an accessible solution. Using one of my favorite colour contrast checker tools (actually built by an ex-colleague of mine) you can see here that on three out of four of the criteria that color contrast fails. If we remove CSS, we don't even need to think about this.
Next, missing alternative text for images
On 60.6 of homepages. What's this caused by? The HTML. Now you're going to see a running theme as I look through all of these failures and we're going to start with AliExpress. Now, on AliExpress there is a rotating carousel on their home page full of lots and lots of images and links. If we look at the accessibility tree in Chromium dev tools, you'll see that it's just an image, and you get no supporting information in that accessibility tree. Here's the HTML, div, div, div, a link with no information and an image with no alternative text. And what's very, very interesting is that AliExpress has chosen to hide the whole carousel for screen readers, maybe with the assumption that if it's hidden — it doesn't matter. And I don't agree with that.
accessibilitydeveloperguide.com says, "Whenever you think about hiding something from any audience, better ask yourself whether this is really a good solution. Most of the time it's better to create a solution that works the same way for everybody, which does not need any shaky aria." Let's look at the fix for this violation. On AliExpress, add an alt tag — "This is a great image description," and we'll get to this later — but if you want to avoid cumulative layout shift, add a height and width on the image as well.
Missing form input labels
On 54.4 of home pages, again caused by incorrect HTML. I spent a long time trying to find an example of this, and what's interesting, is that if a placeholder is present in the input field, screenreaders and accessibility trees kind of get around that and give you some information. However, I did put a call out on Twitter to ask if anybody had any examples of HTML forms without labels and placeholders. A wonderful member of the community, Alex, said he had a gimmicky one on his 404 page to do redirects. And this was like gold dust to me. This was an absolutely abysmal experience for screenreaders, and let's look at what's happening.
It looks pretty cool. There's some ASCII art. The instructions are to press enter to continue, which redirects you to Alex's home page. Here is what the HTML looks like. We have a form, we have an input field. We have no labels, we have no placeholders, and in the accessibility tree we have no information. And furthermore, when you focus on this element with VoiceOver on Mac, it reads out to you — "edit text blank main." It's not really what you're expecting when you land on a 404. So my question is, does this page really need a form? Is this HTML giving meaning to what needs to be done on that page? Furthermore, a fun little easter egg — if you focus on the ASCII art in its current state with VoiceOver, it reads this out to you: "underscore new line forward slashs pace underscore space back slash space undercore underscore underscore underscore etc," and there is a good fix for that, where you can use aria labels and roles to allow the screenreader to know what that is. You add role=image and an aria label. And when you focus on that now with a screen reader, you getmore contextual information about what's on the page. It's a pretty fancy page for a 404. I think I'd prefer my 404s to be functional, especially when we're in an apocalypse.
Now for a moment let's talk about placeholders
As I mentioned earlier, placeholders actually are not labels. w3schools.com says, "The placeholder attribute specifies a short hint that describes the expected value of an input field e.g a sample value or a short description of the expected format."
Let's go back to AliExpress. When you refresh the page on AliExpress you get a new contextual placeholder. It told me to search for true love, Starbucks, fancy underwear and car accessories. In the accessibility tree, the placeholder says "true love" — which is fair enough. But there is no label on the form. If I focus on that input with a screen reader, I don't actually know what that form is for — especially when the placeholder is changing on every load of the page. Without a label that placeholder is meaningless.
So what does a good form input look like? We have a label and we tell the HTML, the DOM, what input that label is for using the for and the id attributes. We give the input a contextual placeholder — here it's first name — and that is going to really help you out when you can't see that screen.
Let's go on to empty links
51.3 of home pages — again caused by HTML. And we go back to AliExpress. In the footer of AliExpress there are a set of social links. They are empty. They are full of non-breaking spaces — and the accessibility tree tells us no information, apart from "space". When we focus on those links as a screen reader user — as someone without a working display — I'm going to ask myself what will happen if I click on this link?
And it's not just empty links that are problematic. Let's take a look at the basket icon on AliExpress. Again, there is a text of "zero" inside that, when I'm hovering over that with a screen reader — when I'm focused on it. I've gone through the input field that says "true love," I go to the basket icon and it just reads out "zero". Here's the HTML. A link, an icon and "zero". And when I focus on it with a screen reader, it reads out to me: "link, zero." I don't know where that link is going — I'm not going to want to click on it. I'm going to be asking myself again — what even is this?
Let's look at the fix. Add an aria label onto the link. Make it descriptive. How about, "You have zero items in your basket. Go to basket." Tell the user what they're going to do if they click on that link.
Missing document language attribute
28.9 of home pages, again caused by the very opening tag of your HTML. accessibilitydeveloperguide.com says, "In the example of a screen reader, the synthesiser needs to know which language the content is, in order to pronounce the output correctly. Otherwise it will be hard to understand, even if you know the other language."
We go back to AliExpress and here you can see Axe Dev tools, a great free Chromium extension to test accessibility. There is no language attribute on the HTML, and you can see here AliExpress have prioritised merging the Facebook and OpenGraph schema into their HTML before they've thought about language.
The fix? Very simple. Add lang equals whatever your language is on the HTML.
Finally, we come to empty buttons
26.9 of home pages — again caused by HTML, but in this case — it's also caused by CSS (which we're going to abandon). We go to a product page of AliExpress and there are two buttons on this page that presumably increment and decrement the amount of items you would like to add to your basket. When using VoiceOver, when you focus on this element it just reads out "button" — no one is going to click that if they don't know what it's for. Here is the HTML. It's a button element with an icon element inside it. So how is that plus and minus added? With CSS pseudo elements. And what's really interesting is this character is not actually supported by a lot of browsers, and also my VSCode. I presume they mean a plus, but literally in the CSS inspector the character is unrecognised. And I had to bring the WAT duck out for that.
The fix? Give a fallback to your button. Put a plus in there. Give it an aria label that tells the users what they're going to do when they click on that button. Give it some meaning.
So when we have a look at all of these most common failures, they're caused by incorrect CSS and HTML. They are not built for accessibility.
So what do we do for accessibility for broken screens in the apocalypse?
Don't fake content with css. Put it there in the DOM. Use semantic HTML. Use forms where it's appropriate. Don't break the web. Because if the web is unusable in the apocalypse — everyone dies.
So we're talking about the apocalypse. 2031 is 10 years off — but why is all of this important now?
Worldwide, the internet is slow
Furthermore, globally at least 2.2 billion people have a near or distance vision impairment
I'm one of them. I have really bad eyes — I can't see. Those of you who have seen me live-streaming know that I miss placeholders all the time when they are really low contrast. And also, not all users of screen readers have vision impairments. Here's a survey by WebAim in 2017, and it shows here that not everyone is blind who answered this survey. Some people have cognitive disabilities, some people are deaf, some people have motor disabilities. So it's not just blind people who use these — there are a lot more people you're affecting if you don't build accessible websites.
And lastly, as of this month, Google now uses Core Web Vitals as a ranking factor in search results
So what are the Core Web Vitals? We've got the largest contentful paint, which means how quickly does the page render. We've got the first input delay — how quickly does the page respond to user input. And we've got cumulative layout shift — how stable is the page layout. So in order to make the most out of search rankings and Google Core Web Vitals, what do we need to do?
We need to get our content to our users as fast as possible. We need to make our web applications usable as soon as possible, and we need to make our web applications as stable as possible — or we risk being forgotten in the apocalypse.
Billions of people use the internet on a slow connection, and millions of people use the internet via a screen reader. People won't find your website if it's not performant or accessible.
The apocalypse of 2031 might not happen but if it does? Hopefully, with this information, we'll be prepared.
My name is Salma or whitep4nth3r. I encourage developers to build stuff, learn things and love what they do. You can find me on all of these social platforms as whitep4nth3r. Thank you very much I've had a lovely time!