Accessible design is that which accommodates everyone, which special attention to those with disabilities and limitations. We see accessibility baked into the world around us, from closed captioning to curb cuts.
When it comes to accessibility on the web, however, we have a lot more work to do. According to a recent survey of screen reader users, 60% of respondents believed that overall web accessibility had either remained the same or had worsened since the previous year.
The good news is that, with a bit of extra care taken on the back-end, any website can be made accessible to users of assistive technologies like screen readers. By investing in web accessibility, not only do you ensure a positive user experience for everyone — you also show your visitors that you care about equal access to your content. And it all starts with taking a look at your site’s underlying HTML.
In this guide, you’ll learn the basics of how to build a web page that works with assistive technologies — we’ll review six aspects of HTML that make this possible. For those unfamiliar with web development, we recommend first reviewing our introduction to HTML, CSS, and JavaScript, as well as our full guide to HTML, before continuing.
Semantic HTML
HTML — as well as its companion style language, CSS — is flexible. If you want to build a certain type of page, there are probably multiple ways you could go about writing it with HTML and styling it with CSS. However, not all HTML elements are made equal when it comes to accessibility.
When writing web pages, the single best way to make them accessible is to use semantic HTML. Semantic HTML is HTML code that says what it does — in other words, the tag itself conveys the purpose of the element. Semantically rich elements include <button>, <form>, <header>, <footer>, <nav>, and the headings <h1>, <h2>, etc.
Consider the example below. Here, we have two button elements that, at least to the human eye, look the same:
See the Pen button vs. div by Christina Perricone (@hubspot) on CodePen.
But, if you reveal the underlying HTML, you’ll see that the first element is a <button> element, while the second is a <div> element. The former is semantic, while the latter is not.
Another example: Below, we have two lists. However, the first uses the semantic <ol> (ordered list) tag, while the second is formatted with generic tags:
See the Pen ol vs. div by Christina Perricone (@hubspot) on CodePen.
While the difference between semantic and non-semantic tags might not seem important to sighted users, it matters significantly to those using screen readers for several reasons:
First, semantic HTML tells screen reader users exactly what they’re viewing. The semantic <button> element tells the screen reader that this element is meant to be clicked to perform some action, and the <ol> element says that the elements it contains are part of a numbered list. Since <div> is not semantically rich, it does not convey this information — all the user knows is that the element in question is some generic block-level … thing.
Second, semantic elements come with their own keyboard accessibility built-in, with no extra work required on your part. The <button> element, for example, lets users “click” the element with the Enter/Return key, and focus on it with the Tab key. This isn’t the case with <div>. When you use semantic elements, you enable complimentary accessible functionality.
Lastly, many screen readers help users navigate a page by letting them skip between tags of the same name (i.e. H2s), or aggregate all of the same tags for an easier way to scan the contents of a page. So, it’s clear why using mostly <div> tags would negate this feature.
To sum up, avoid creating specific interaction elements with the generic <div> tag and its inline sibling, <span>, if you can. While these tags are often useful for layouts, always choose the native semantic HTML element when possible for better accessibility.
Image Alt Text
If you’re a marketer, you’ve likely heard of alternative text, or “alt text,” in the context of SEO. Alt text tells search engine crawlers the contents of your images, and is an opportunity to provide more information to rank higher in SERPs.
However, the original purpose of alt text was to add context for those using screen readers and for those who cannot see your images for any reason (e.g., low vision, a poor connection, or a broken source link). When a screen reader encounters alt text, it simply reads it to the user. Browsers can also be set to display alt text onscreen in lieu of the image.
Image alt text isn’t hard to implement. In the code, it’s as easy as placing the alt attribute inside the <img> tag like so:
<img src="cute-dog.jpg" alt="a small, brown sitting in a field of dandelions with a chew toy in its mouth">
If an image lacks the alt attribute, a screen reader will either read the image filename, title attribute if one exists, or skip over the image altogether. All of these outcomes prevent users from fully accessing your content, so it’s important to add concise, clear alt text to all non-decorative <img> tags on your page. Your alt text should directly describe the contents of the image. It’s okay to include a keyword or two, but avoid keyword stuffing, a practice which impedes accessibility.
For decorative images inside your HTML file, those which add visual style but are not essential to understand the page content, include the alt attribute but leave the value empty. This tells the screen reader that an image exists, but is not important to the reader. It prevents the screen reader from reading the image file name or title attribute.
<img src="background-image.jpg" alt="">
Note that decorative images may be better implemented as a CSS background image rather than part of your HTML.
Well-Structured HTML
When sighted users land on a web page, their eyes dart around the page in search of their desired content. A screen reader, however, processes pages in a linear manner — it starts at the top of the HTML and reads down through each page element one-by-one.
To help screen reader users better understand your pages, it helps to structure your content in a useful way.
This means two things: First, use semantic HTML tags to segment different regions of your page. For example:
- Use heading and subheading tags (<h1>, <h2>, <h3>, etc.) to designate text areas by order of importance. <h1> is the most visible heading and should only be used once.
- Indicate separate paragraphs inside separate <p> tags.
- Indicate numbered lists and non-numbered lists with <ol> and <ul> respectively. Nested listed items use <li> tags.
- Use <header> and <footer> tags for your header and footer regions.
- Place any navigational elements inside the <nav> tag.
- Place the main page content inside the <main> tag. Use this tag only once per page. Main page content is any content that isn’t repeated across pages on your site, so it excludes things like headers, footers, and navigation.
Second, order these tags logically. Usually, visitors expect your header and navigation to come first, followed by <main> content, followed by your footer. Inside <main>, place your headers in descending order, and do not skip header levels (i.e. don’t place an <h4> element directly under an <h2> element without an <h3> in between).
Well-structured semantic HTML helps screen reader users better understand the layout of your page. It also lets them preview sections and skip between different content regions, similar to how sighted readers skim web pages. This HTML structure is much more navigable than a clump of generic <div> and <span> tags.
The HTML lang Attribute
Here’s a quick win for writing more accessible HTML — every page on your website should include the lang (language) attribute placed inside the opening <html> tag. This identifies the primary language of the page to the browser, search engines, translation software, and screen readers.
Add your lang attribute like so:
<html lang=“en”>
<!-- the rest of the page content, in English -->
</html>
If you have an instance of a foreign word on your page, you can place the lang attribute inside any other tag, such as <p> or a <span>, to indicate a temporary language change:
<html lang=”en”>
<body>
<p>The language of this document is English, as indicated in the html tag above.</p>
<p>We can also use the lang attribute to indicate a foreign word, like <span lang=“fr”>salut</span> or <span lang=“de”>hallo</span>.</p>
<p lang=“es”>Este párrafo está en español.</p>
</body>
</html>
For screen readers specifically, the lang attribute tells the text-to-speech function how to pronounce the words on a page. If the wrong lang value is used, visitors will hear your page read in, at best, a heavy accent. This is why it’s a good idea to check that all of your pages are set to the right language.
Descriptive Hyperlinks
When designing for better accessibility, we want to inform users what to expect before they take a particular action on a page. The most common action a user can take is clicking a link to a different page — before a user does this, they should know where they are going from the link text alone, without any additional context.
To achieve this, write link text that adequately describes where it leads and is unique from other link text. Consider the following two sentences:
- Click here to learn more about web accessibility.
- To learn more about accessible websites, see our Ultimate Guide to Web Accessibility.
Though people reading these sentences will know what to expect from both of these links, the problem is that a screen reader user might pull a list of all links on a page and select one from this list. Someone reading the link text from example 1 in isolation won’t know where it leads. Plus, if there are multiple links that read “Click here,” it’s not apparent if or how these links are different.
On the other hand, it’s clear from the text in example 2 that we’re linking to our web accessibility guide.
ARIA Roles
The Accessible Rich Internet Applications suite of web standards, shortened to ARIA, is a set of standards to make user interface controls more accessible for those using assistive technologies.
The ARIA documentation outlines how to use HTML attributes called ARIA roles, which specify the function of a particular interactive element or landmark element for screen reader users who may not be able to visually grasp the purpose of an element. ARIA roles are best used on <div> and <span> tags.
There are ARIA roles for most page elements. For example, to indicate that a list contains navigational links, you can use the ARIA role navigation:
<div role=”navigation”>
<ul>
<li>Product</li>
<li>Solutions</li>
<li>About Us</li>
<li>Blog</li>
</ul>
</div>
ARIA is a complex accessibility topic in and of itself — to fully adhere to ARIA guidelines, we recommend consulting the full documentation or consulting with an accessibility specialist.
Accessibility Starts With Your HTML
After implementing the measures above, try running your page through an accessibility testing tool. Here’s one accessibility checker endorsed by the Web Accessibility Initiative that grades your website on a zero-to-100 scale and lists any accessibility violations that you can address.
Like many aspects of web design, accessibility is best considered from the start of the building process, rather than an afterthought. Implementing accessible best practices from the start will save you from having to revamp your pages later on.
However, at their most basic level, web pages are just text documents that can be reconfigured as needed. With some extra tweaking and several accessibility checks, you’ll quickly improve the browsing experience for your visitors who need it. After that, move on to other content-related changes that help your visitors.
Everyone deserves equal access to public information online. To make the web a better place, start with your own site.
