Accessibility and HTML5: Semantic Elements and More

A div for everything and everything is in its div…

If you’ve been working on websites for a while, you’ve no doubt had a few that seem to be just div after div, where the div explosion serves to place or style each part of the page as needed. The problem is, a div by itself doesn’t tell the user (or, more to the point, the user agent) anything about what the div contains, and the styling is likely to be lost on someone using a screen reader.

In HTML5, we have the semantic elements, which generally act like divs – they’re block elements that contain other elements – but also provide meaning; each tag describes what it contains, which allows a user agent (such as a screen reader) to handle it appropriately. We still use divs, when no semantic element is appropriate, but they should no longer be the first choice. The semantic elements include:

  • <nav> encloses a navigation block; this will often contain a list of links, but not every list of links needs to belong to a nav. Screen readers may be able to go directly to the nav section or skip it if not needed.
  • <main> is for the main content of the document; it should contain only content that is unique to that document, not content repeated across multiple pages. User agents will often be able to navigate directly to the main content block, bypassing navigation links. At most one main element should exist in a given document, and it cannot descend from an article, aside, header, footer, or nav element.
  • <article> describes a self-contained block; it could be moved to another page and still make sense on its own. A page that consists of one self-contained block of content will simply hold it inside a <main> element, but multiple blocks that do not depend on each other will be <article>s instead. An <article> can contain other <article>s that are related to it, such as comments on a story.
  •  <aside> contains information which is tangentially related to the primary content, but isn’t required to understand it; this content is likely to be visually represented as a sidebar or pull quote.
  • <figure> encloses some self-contained content, which may be (but is not required to be) graphical in nature. Each <figure> may contain one <figcaption>, which provides a caption for everything contained in the figure; this groups all of the contents and provides a way to refer to them even if the page layout changes.
  • <section> is a…er…section of the document; it groups together part of the document, such as a chapter. Sections generally come with headers and should contain content that logically belongs together.

If none of the above signpost elements are appropriate, then we look for a more specific element, such as <address>, <blockquote>, or even <p>. Only if the content doesn’t have any semantics do we use the plain <div>. It’s a bit more work, but it allows the user agent to process each type of content according to its own rules, according to the user’s desires.

Lack of accessibility: my experience

We’ve been talking about guidelines for making websites accessible in general, and how to make them screen reader accessible in particular. Now let’s get away from the how and look at the actual impact of this work. Here are a few times when I’ve been impacted by a lack of accessibility.

  • Some years back, someone lent me an instructional video for West Coast Swing. The instructor was trying to explain how to dance in time with the music, and you were supposed to listen to the beat while he pointed up and down, which would have been great – except he also SAID “up” or “down” each time, so I couldn’t actually hear what he was trying to point out!
  • When Netflix started doing streaming video, there weren’t any captions. Many people complained (including myself) and Netflix told us that they were in the process of adding them. A few years later, they added streaming captions…for the first five seasons of Lost.
  • When listening to podcasts, it’s not unusual to have people sometimes speaking over music, which makes them harder to understand.
  • When I’ve been to conferences, speakers often show video with no captions.

In many cases, these aren’t even difficult things to fix. The dance instructor could have simply pointed rather than speaking, there’s no reason to have music on in the background when recording speech, and of course adding the already-existing captions to more of their streaming videos was well within Netflix’s capabilities if they had prioritized it. For speakers showing video, captioned versions are often available (sometimes the captions just need to be turned on!), and adding captions to original videos is fairly straightforward with modern video editing software. In each case, the problem isn’t technological; the problem is people either not thinking about the needs of viewers with hearing impairments or simply not caring.

Fortunately, things are improving. Netflix was sued under the Americans with Disabilities Act and now captions pretty much everything. Conference organizers are starting to pay more attention to accessibility. I’m in the process of booking a cruise as I write this, and the cruise ship provides assistive listening devices, sign language interpreters, and open captions on some movies. Movie theaters are now required to provide some way (usually Captiview, which is not a great option but is way better than nothing) for deaf patrons to follow what’s being said.

I’m writing this from the perspective of someone with hearing loss, because I’m deaf, but I’m sure people with visual or mobility impairments could provide a similar list of issues. What’s happening lately, partially through awareness and partially through political/legal action, is that more service providers are considering what they need to do in order for their product to be truly usable for everyone.

Testing for accessibility: Web Content Accessibility Guidelines

What makes a website accessible?

The answer, of course, is that a website is accessible if it is usable by all people, regardless of disability. When building a website, however, we need something a little more concrete; we need a way to test whether the website is accessible, without having to have people with a hundred different impairments actually testing it. That’s where the Web Content Accessibility Guidelines (WCAG) from W3C come in. Following the guidelines doesn’t guarantee that your website is usable for everyone, but it’s a good starting point for handling the most common accessibility issues. The guidelines help insure that all users can both access the content and navigate the website.

How important is the WCAG standard?

Many countries require that their government websites follow the WCAG standard (the US uses Section 508 guidelines, which are expected to require AA WSAG compliance, described below). Last month, a federal court ruled that having an inaccessible website is a violation of the Americans with Disabilities Act (ADA), and the Justice Department has successfully sued companies (including Carnival and Wells Fargo) over lack of accessibility (both physical and online). The ADA requires that places of public accommodation be accessible to the disabled, and websites which directly sell goods or services, or connect to physical locations which do, have been ruled to be places of public accommodation and thus subject to the ADA requirements.

How are websites evaluated?

WCAG includes three levels of compliance: A, AA, and AAA. A is the minimum level of conformance; a website that does not meet the level A requirements is simply not usable by people with certain disabilities. These are things that every accessible website MUST do. AA requirements make the website easier to use; these are things that every accessible website SHOULD do. Finally, AAA requirements are going “above and beyond” to make things easier for people with disabilities; they are things that a website MAY do. In order to claim compliance for a particular WCAG level, every part of the website must meet every WCAG requirement for that level (as well as for the levels underneath it).

What is covered?

The WCAG standard is composed of four basic principles, with a number of guidelines that lay out specific requirements for meeting those principles. The principles are:

  • Perceivable. This is the most straightforward: information must be presentable to the user in a way that he or she can perceive. This includes things like text alternative for non-text content (pictures, recorded audio, recorded video), not communicating information solely by color, allowing the user to resize text, etc.
  • Operable. This means that a user is able to navigate the website. This includes obvious things like being able to navigate using a keyboard alone, without losing focus, but also things like not having anything that flashes more than three times per second, which could trigger a seizure.
  • Understandable. This principle at first seems more subjective; who’s to judge whether the text of a website is understandable or not? Guidelines here include that the browser can determine what language the page is in, explaining abbreviations (such as by putting the first use of the abbreviation immediately after the expanded form, as we did with WCAG and ADA above), and making the website perform in predictable ways (for example, having consistent navigation).
  • Robust. The website can be interpreted reliably by a variety of user agents – this is any piece of software acting on behalf of the user, such as a screen reader. This includes things like closing tags (so that the site can be parsed correctly) and associating labels with their corresponding fields.

Getting started

Because the standards include things like website navigation, the easiest way to meet them is to design in accessibility from the very beginning. Failing that, the guidelines are relatively straightforward to test for, and many of the accommodations, such as providing alt text for images, are fairly trivial to make. Even small changes like this can make a huge difference for someone trying to use your site, and many of them benefit your typically-abled users as well.

When to say “I don’t know”

Many years ago, I taught middle school math. One day a student asked me a (non-math related) question that I didn’t know the answer to, so I told her that I didn’t know. She then got annoyed with me because apparently, teachers are supposed to know everything.

I was reminded of this recently when seeing comments about hiring people because they weren’t afraid to admit in an interview that they didn’t know something. Apparently this is somewhat uncommon, which suggests that an awful lot of people are trying to BS their way through interviews.

Of course, nobody wants to hear “I don’t know” to every question, but assuming that you’re qualified for the job you presumably can answer most of them. This applies to working as well; I’d much rather you tell me that you don’t know how to do the task you’re assigned than pretend you already know and get in over your head.

So, here are some acceptable ways to say “I don’t know”:

  • I’m about 80% confident that this is the answer, but I’d have to double check to be sure.
  • I haven’t worked on that functionality, but Jim would know. Let me conference him in.
  • I can’t give a firm deadline for when the project will be completed because we’re waiting on feedback from QA. I’ll follow up with them and see when they expect to be done testing.

Here are some less acceptable ways to do it:

  • I don’t remember. [And I’m too lazy to look it up]
  • I don’t know. [And I can’t be bothered to find out]
  • It was exactly 1,429.3. [Or some other BS answer]

Simply put, if you don’t know something but can find out the answer or direct me to the person better suited to answer the question, that’s just fine. If you are the person who should know the answer, but for some reason you don’t, then you should be finding out; don’t just shrug it off or (worse) make something up. Nobody (well, except apparently some 7th graders) expects you to know everything, but if you’re being lazy or BSing the answer, people won’t be particularly eager to work with you.

tldr: You don’t have to know or remember everything; just be honest.

Making your site screen reader accessible

One of the things I’ve been working on lately is ensuring that our web apps are accessible, which primarily means that those with visual impairments can use them. Partially that means making sure to use high-contrast colors and large buttons, and partially it means the webpages work well with screen readers.

Screen reader compatibility largely breaks down into the following:

  • Is the entire page keyboard accessible; can the user access all functionality and information without using the mouse?
  • Does the screen reader tell the user everything he needs to know about what’s going on on the page?
  • Does the screen reader avoid throwing gibberish at the user?


Is the page keyboard accessible?

Can all of the page functionality  be used without a mouse? This means more than just being able to tab to all fields (although that’s the obvious first step). Other things to consider:

  • Is there any information that’s only available when hovering over an area of the screen? Unless this is a field that can be tabbed to (in which case a screen reader will read the tooltip), that information may not be available to keyboard users (or mobile users).
  • If there is a popup window, does focus return to the main page when the popup is closed? Similarly, when clicking a button, does focus go away? If focus is lost, a keyboard user is stuck.

Will all visible information actually be read?

  • If the page contains text which isn’t associated with a control that can gain focus, it may be ignored entirely by the screen reader.
  • If taking an action causes a visual change elsewhere in the page – say, making a warning visible – then even if that change is visible to the screen reader, the user is unlikely to know about it immediately and could either miss it entirely or become frustrated when it is encountered and it’s either not clear what caused the warning or it’s difficult to navigate back to the appropriate section.

Will extra information be read?

If you don’t tell them what not to read, screen readers will try to grab everything. Even a well-designed page will throw a lot of information at the user (which is why screen readers talk really fast). If you’re using tables to style your content, the screen reader will read off all the details of the table. When testing, I’ve found that sites like Facebook can completely overwhelm the screen reader. There are various attributes you can add to clean this up (such as role=”presentation”) which may or may not be correctly interpreted, depending on which screen reader you use.


Unsurprisingly, accessibility ends up being something that, while you can follow best practices, you still need to test for. The top screen reader option, JAWS, is horrendously expensive (starting at $900 for a home license), but NVDA is a free, open source alternative that works well for testing. Helpfully, there is a text box option so you can see what it’s saying rather than simply listening at high speed. So far I’ve only used it for work, but while writing this post I tried it out on this site and determined that the site is not actually screen reader friendly, which tells me I need to make some revisions! Hopefully I’ll have an update on that in a future post.

Is it worth it?

Making a website accessible can be a lot (and I mean a lot) of work, for relatively little reward (the number of people using screen reader software is obviously a small percentage of the overall audience, particularly for some specialized sites). However, we still have an obligation (both moral and, in some cases, legal) to make our work usable for as many people as possible. As a bonus, efforts taken to improve usability for people with disabilities often end up being a great help to people we wouldn’t normally think of as disabled, simply impaired – the elderly, for example, who may have weakening vision. In a future post, we’ll talk about accessibility improvements we can make that will help improve usability for all of our users.