Getting started with accessibility? Embrace the power of HTML

#a11y #html #webdev

Be honest with yourself - how long did you spend learning HTML when you first started learning web development? For the majority of folks, 1-2 weeks is usually enough to understand the basics and get up and running, given the flexible and forgiving nature of the language. And then you move onto more complex things.

However, when we move on to more complex things we often miss out on learning about some of the things that HTML gives us for free, especially the inbuilt accessibility. So I’d like to encourage you to revisit HTML. It has over 100 different tags and a variety of attributes available. Many of those elements have built in features that make your site accessible without much extra effort (and sometimes even less).

Here are 10 tips to get started with writing more accessible HTML today:

Some elements are designated as landmarks. These include things like <nav> <header> <footer> and <main>. Although they may just seem like divs with fancy names, typing out the extra couple of letters helps people who use screen readers to navigate your site find their way to the different sections of a page more easily. Sighted users have the ability to scan pages and find what they’re looking for. Screen reader users can use landmarks to navigate sections in a similar way, instead of having to go through everything on the page.
Similar to landmarks, correct heading structure is another way that screen reader users can quickly find the information they’re looking for. Heading structure should be based on hierarchy and not styling. Each page should ideally contain a single h1, followed by multiple h2s. These h2s can be broken down into h3s if necessary. Just don’t jump from h2 to h4 because you want the headings to be different sizes. Here, CSS is your friend.
Focus on using correct semantic HTML, where the element matches its intended purpose. If it’s something you click and it takes you somewhere else then you probably want an <a> element. If you click something and it performs an action, such as opening and closing a menu, you probably want a <button>. These semantic elements have inbuilt functionality which allow them to be triggered by both mouse and keyboard without you needing to add any extra code. If you use a div to make a button you will need to add all the extra functionality yourself and that can be quite complex and easy to forget something.
Write clear and concise link text that accurately describes the link's destination. Avoid using vague terms like "click here" or "read more". Links should make sense even when read out of context so that users know where the link will take them.
Provide alternative text for visuals. All the images and icons on your page need descriptions for those that can’t see them. This is often called alternative text and is added to the img element with an alt=”Your description here” attribute. Provide enough information to understand why the image is there, and in the case of icons, you usually need to think about the function of the image and not what it actually depicts. For example, a magnifying glass is often used to symbolise both search and zoom. An alternative text matching the function is much more useful than describing the magnifying glass itself.
Make sure inputs have labels and that they are programmatically associated with each other. What does that mean? It means the label has a for attribute and the input has an identical id in order to show that they are connected. This tells screen readers and other assistive tech that the label belongs to the input.
Placeholders are not a good substitute for labels as they disappear as soon as someone tries to input something. This can be quite demanding on memory, especially if the placeholder text contains information about the format the input should be in. Clear labels that are always present next to the input gives a much better experience for everyone.
Prioritise Keyboard Navigation. This is crucial for users who rely on keyboard navigation due to motor disabilities. Start at the top of your page and start tabbing through the content. Can you reach every interactive element and is the order you tab through them logical? Can you see where your focus is at all times as you are tabbing through or does the visible focus disappear sometimes? Can you activate links with the enter key and buttons with the space or enter key? Often, if you’ve got semantic HTML right then this shouldn’t be a problem. If you come across issues, either go back and improve the HTML where possible or you’ll need to start adding appropriate keyboard support with javascript.
It’s perfectly fine to use <div> and <span> if there’s not a more appropriate semantic element. Divs and spans are invisible to the accessibility tree and therefore ignored by screen readers and other assistive technology. This makes them perfect to use for styling and positioning elements without making the screen reader experience too noisy.
Attributes are also useful. For example, adding the lang attribute to the <html> element informs assistive technology like screen readers which language to use. Screen reader will then adapt the output accordingly and read with the correct pronunciation.

Most of these changes take a couple of extra seconds but they can make a huge difference to how accessible your website is. Why not choose just one of the things suggested above and make it a new habit today? Small improvements over time add up in the long run.