Your Choices Matter: 6 Ways HTML Impacts Your Page’s Accessibility

We all want our websites and apps to be accessible. Did you know that as a front-end developer, a lot of the work you can do is actually in being aware and intentional when writing HTML?

Here are some tips you can apply right away, taken from a talk I gave at JSConf Budapest.

What is web accessibility?

Before we go into the details, let’s look at what web accessibility actually means. Web accessibility is the practice of ensuring that people with disabilities can use your website or app. And ensuring that they can buy your products or use your services.

This concerns a lot of people: roughly 15% of the world’s population have a disability.

A motor impairment might mean someone can’t use a mouse to press ‘Next,’ a neurological condition might mean they have short term memory loss, color deficiencies might mean they don’t see the difference between green and red, and hearing loss might mean they use the transcript to follow along with your podcast. Often, there is overlap and gradations in these disabilities.

Some people will use specific tools and techniques to access the web, like voice control, switch controls, braille displays, and screenreaders (see also: How people with disabilities use the web). As web developers, we can ensure compatibility.

In today’s post, we will mostly focus on optimizations that are specific to people who use screenreaders, because that’s an area where front-end developers and markup can make a large impact. Other parts of accessibility will probably be ensured by other team members, like designers and content editors.

How browsers process markup: from DOM to end users

When you visit a website, the browser requests the website and the server will respond with a blob of markup: HTML. The browser then turns that into a DOM tree, an abstract and real-time representation of what was in your markup.Your headings, links, buttons, lists: they’re all there.

After that tree is constructed, it can change at any time. You might add a classname here and there or render a full-fledged React app.

In certain cases, the browser will create another tree: the accessibility tree. This tree is based on the DOM tree, but it contains all the accessibility-relevant information, like “roles”, “names” and “states”. This information answers questions like “what kind of thing is this?” (is it a text input, a button, a link?) and “how should we refer to it” (is it named ”Save my changes”, “International news” or “First name”?).

The accessibility tree also has meta-information like “is this thing expanded” or “is this checked”, for a checkbox.

The accessibility tree has all this information, and passes it on to Accessibility APIs that are built in to all the major platforms (Windows, Mac, Linux, etc). Those APIs communicate with screenreaders and others tools. This is how a screenreader knows to say “here’s a checkbox called ‘Save my changes’ that is checked”.

Long story short, your markup has a significant impact on how end users understand a page. It communicates what everything is on the page, how to refer to it and more.

Should you want to look at the accessibility tree of your page, you can inspect it in all modern browsers. In Chromium-based browsers, some of the accessibility tree data (name, role) is also available in the tooltips you see when you hover over elements with Developer Tools.

The practical effects of our markup

To understand what this means in practice, let’s look at some markup examples. Whether you use Astro, Ember, Eleventy or Vue, all of them will ultimately end up as HTML in browsers, with DOM and accessibility trees based on them.

Titles

The <title> element is likely on your pages, but it’s usually hidden away in some template that you don’t open daily. It is essential, though, for users of screenreaders.

When a page loads, most screenreaders will read out the contents of the <title> element. This gives people a quick heads up about the page they’ve ended up on.

Ideally, the unique part goes first: all pages on Sanity’s website probably have the word Sanity in their title, but if I open the page about Sanity Studio and the one about Content Lake, I want to hear that first, not that they both relate to Sanity.

Headings

The headings (h1, h2, h3 etc) on your page are like tables of contents, especially for users of screenreaders. Via the H key (NVDA) or the Rotor‘s list of headings (VoiceOver), users can access just the headings in a page, and then choose to jump to the one they want.

This is a common way to navigate, and for us, it means that what we put into our heading tags matters, because it will be used for navigation.It’s a little bit like when you call a customer service number and the recording says, “Press 1 for Sales, press 2 for Support”, but with your page’s headings as the options.

Landmarks

With landmarks (elements like header, footer, nav, aside, main), you can identify what the most important sections of a given web page are. Technically, that means wrapping the area of your page in that element, and ideally using aria-label or aria-labelledby to give them a name.

One way to think about what HTML landmarks do on a page is to compare them to a physical space. In a theatre venue, landmarks may be the main auditorium, the toilets, the wardrobe and the bar. They are the things visitors would ask you about, and they are the things you would probably decide to add some signage for.

But you don’t want to go overboard – each of the individual seats, toilets, hangers or wine bottles aren’t landmarks, if there are too many it is no longer useful. That’s the same with landmarks in a web page: yes, mark a header, footer, a couple of navs, but don’t mark each individual product if you have a long list of them (see Accessible landmarks for more tips).

Form controls

There is a lot to say about form controls, but today we will focus on labelling them. When WebAIM, a US-based non-profit, looked at the top 1 million websites, they found that almost half of them had unlabelled form inputs.

Basically, any input field, radio button, checkbox, select and text area needs to be labelled, as that is what gives them an accessible name in the accessibility tree.

The Accessible Name and Description Computation has the full details on how browsers calculate names for form fields, but the easiest ways to add a label are by using the label element (that way, you can also make them visible for sighted users) or applying an aria-label attribute to the input directly. You can find out if it worked in the browser’s accessibility tree.

Tables

You may have heard tables aren’t good for accessibility, but that’s mostly when they are used for page layout. Tables that are used for tabular data can actually be great for accessibility.

Screenreaders have some ergonomics built in to work with tables. They will work out of the box with tables, but only if they are well marked up.

First, you will want to make sure your table has a caption to name it, especially if you have multiple, so that people can distinguish them, just like they can distinguish pages with title elements and page sections with headings. For instance, if you have financial results of three years in three separate tables, you’ll want their captions to clearly mark which one is which.

Second, it’s helpful to useth elements to mark which cells are headings, with scope attributes that specify whether they apply to a column (scope=column) or row (scope=row).

Buttons

We looked at form elements earlier, but the button element deserves a special mention.

This element is great, because it comes with a lot of stuff built in: you can find it when you use TAB to go through a page, users can press it with just a keyboard and they can submit forms, even if JS fails. It has been popular for a while to build buttons out of div elements, but that is not advisable, as you would need to recreate a lot of functionality that the browser provides for buttons from scratch.

One thing to note when building buttons is if they have only an icon in them, eg no text. This is common, especially in more complex UIs. That way, if they show up in the accessibility tree, there is no text to derive the accessible name from.

You can fix that by adding visually hidden text or using the aria-label attribute on the button.

It’s the markup that matters

In this post, we saw we can improve a lot of our page’s accessibility right in our markup.

Good markup indicates what’s what on a page, it helps assistive technologies that parse the page on behalf of our users. Good content within our markup is equally important: a clear “name” makes a link, heading, or table easier to find – for all users.