Illustration by Kika Fuenzalida
HTML is at the core of many things we do. It’s so ingrained in the frameworks we deal with on a daily basis, many of us might feel like we know it relatively well. I guess I was one of these people - I thought I knew what I was doing. At least sort of. Until I started diving into accessibility.
While many of us have solid knowledge of semantic HTML, it appears to be a common source of issues when it comes to accessible web development. The ‘semantic’ part, it seems, is often overlooked: the tags which are meant to give each element meaning and structure the page, are often replaced by an armada of <div>s and <span>, styled up with CSS and given some functionality - who will ever know, right?
While this might superficially solve whatever problem you are facing in the short term, there are a variety of issues with this. Besides many other good reasons to use proper HTML (inherit functionality, code maintenance, SEO benefits, to name a few), it is absolutely crucial for accessibility.
Without proper HTML structure, how would a screen reader know where to go?
Screen readers highly depend on html to navigate the page: semantic tags are their way to find out which part of the page is relevant (e.g. <main>), where the navigation is (<nav>), what to read out (e.g. <h1>, <h2>,...) and what to skip or which actions can be derived from an element (e.g. <a>, <button>). Without them, browsing a site using a screen reader will be a lot more complicated and messy. Try it out yourself: Sample page with most html elements
This of course does not mean you are not allowed to use <div>'s or <span>'s at all - just be reasonable ;). <div> can be a great way to group otherwise not reusable elements together and style them - just make sure you are not randomly dishing them out without intention.
Another great way to check quickly if you did an ok job with the structure is turning off CSS completely: while it’s not necessarily pretty, you should still be able to navigate your site.
Inherit functionality
Semantic HTML comes with a bunch of functionality already built in which saves a lot of time and effort, for example when it comes to keyboard navigation or input fields. Adding the right kind of input type makes everyone's life easier (e.g. <input type=”number”> instead of “text” opens up a different input option on mobile), avoids erroneous data entries and provides out of the box error messages in the user’s own language.
While keyboard navigation is an essential part of of web accessibility and important for users with for example motor disabilities, like so many aspects of web accessibility, this benefits everyone: regardless of whether you are just holding a coffee and navigating a page with one hand, got a temporary injury or are balancing a kid on your lap while working from home: keyboard navigation and shortcuts are beneficial for a much wider range of users than you might think.
Call it by its name
To make all aspects of your content, including images and video accessible to visually impaired users, you need a text alternative that the screen reader can use. Unless your visuals are purely decorative, give the media element a meaningful name if you can and provide a descriptive alt text. For decorative elements, it’s considered good practise to leave the alt text empty.
Another great way to label images is the aria-labelledby attribute. By doing so, you can refer the user to a description by id without using an alt text. That way, you can for example use the same label for different images or use a headline or text description as the text alternative.
The same goes for buttons and links, of course: how is the user supposed to know where a link or click of a button is taking them if the label reads ‘click here!’ or worse, if there is no label, or worse textual context at all? Make sure you provide enough context for all users, especially on interactive elements.
Every little thing counts
In an ideal world, all of this would be considered right from the start, which of course would save a lot of time and effort. Yet, even if this is not the case for your project and you are facing a jungle of <div>s despite good intentions, don’t worry.
While it can of course be more challenging to implement semantic HTML after a project has already been completed, it’s not impossible.
And: every little step counts! Don’t give up just because you can not fix it all - it’s always better to do the little things you can than not do anything at all :)
Top comments (0)