Talk starts at 12:37

View slides on Speaker Deck

Transcript

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?

Let's first talk about accessibility for slow connections

There are almost two billion websites in the world, and 95% of those websites use JavaScript. And why is this bad news for the apocalypse?

Let's take a look at the network tab of mobile.twitter.com. On the first request, it loads 37 javascript files worth 1.44 megabytes (compressed), 27 other files and nine image files. If we look at Lighthouse Dev Tools, we'll see that the time-to-interactive is 5.8 seconds and on the original trace of the page you see absolutely nothing on that first load. That's a lot of requests for JavaScript. And they're pretty expensive. It takes time to load — plus — it might fail.

Here's a tweet from 2018 where "our monitoring tells us that around one percent of requests for JavaScript on BuzzFeed time out, and that's around 13 million requests per month." That's 156 million failed requests for JavaScript each year for BuzzFeed alone. And that's potentially that many failed JavaScript requests on the web each year. (Assuming that all websites that use JS have the same traffic as BuzzFeed.)

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 how can we serve critical content faster? Do we abandon JavaScript?

The Jamstack has gone some way to try and solve this problem. The Jamstack is an architecture designed to make the web faster, more secure, and easier to scale. The key feature of the Jamstack is pre-rendering — where the entire front end is pre-built into highly optimised static pages and assets during a build process, and then enhanced with JavaScript. You might have heard of some of the most popular static site generators — Nuxt.js which uses Vue, Universal which uses Angular, and Next.js which uses React. But does modern Jamstack really solve this problem that we saw with Twitter?

Here's my website and the network tab. It's built with Next.js and hosted on Vercel. On a normal load of this site in a browser, it loads more than 30 javascript files on the client. The first document to load is the HTML document. But why do we need all that JavaScript when the document has already loaded, and the Jamstack is telling us that our pages are pre-rendered and served statically?

Let's do an experiment and let's turn off JavaScript on my website. Here it is. You can see the blocked requests in the network tab — JavaScript is disabled. But as you can see it still loads. It still works! Let's compare this site with JavaScript disabled and JavaScript enabled. The load time for the JavaScript disabled site is 259 milliseconds compared to 793 milliseconds. And that is on a normal speedy connection in the UK. What if we switched that to slow 3G, which the apocalypse will be using? The load times are incredibly different without JavaScript — 8.67 seconds and with JavaScript over 25 seconds. And the sizes of these pages are phenomenally different. 300 kilobytes for no JavaScript versus 1.4 megabytes using JavaScript. And that's compressed! The uncompressed sizes are even greater in difference. 3.6 megabytes to load the same site with JavaScript enabled.

I did another experiment. To test this theory I wanted to see how low we can get the size of the page and the load time of the page without JavaScript. So the first thing is I recreated my blog article list fetching data at build time, statically generated on Next.js. 105kb loaded in just under 5 seconds. I created the same page but loaded all the data on the client without JavaScript. We obviously get no content because there's no JavaScript to load it — and it's only slightly less than 92.7kb, loads in just about five seconds again. So what if we could turn this into a static HTML page, no framework? HTML and CSS, no JavaScript, 100 kb in 4.71 seconds.

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.

And so in terms of accessibility for slow connections, you can remove as much JavaScript as possible. Harness these Jamstack frameworks — but always use your judgment. I was still able to get the load time and the page weight down. So what I recommend for accessibility for slow connections: websites must work without JavaScript in the apocalypse. Decrease your load time, decrease your page weight. Because there is no progressive enhancement in the apocalypse. There's just simply no time.

Accessibility for broken screens

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?

Let's quickly recap

How do we prepare the web for the apocalypse of 2031? we start with semantic HTML. We use minimal CSS, and we use as little JavaScript as possible. And why is this important now?

Worldwide, the internet is slow

worldpopulationreview.com did a survey on internet speeds by country in 2021 and the average speed in the world is 55.13 megabits per second. If we look at the code from Chromium Dev Tools, the slow 3G simulated connection is 51.2 megabits per second. These are pretty much the same. So all of the results you've seen when I had slow 3G in my dev tools — loading that page with JavaScript — the results are going to be very similar for a lot of people around the world. They are not going to survive if pages take that long to load.

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!