In the third post of her “Accessibility pitfalls for developers” series, Julie takes on information and relationships. This success criteria is about making sure that everyone gets the information, even if they can’t perceive the page the way other people can.

After learning that our third most common accessibility problem was with images, and our second most common was with colour, both of which are abundant on the web, would it surprise you to learn that the most common problem we encountered during assessments last year was with HTML markup?

What we mean by “information and relationships”

In 2015, the highest amount of accessibility issues we found were classified under a specific guideline defined by the W3C: WCAG 1.3.1 Info and Relationships. This guideline requires that “information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.” Yeah, it’s a mouthful, and it’s not immediately obvious what it means.

When most people are using a website, they don’t just read the text for content and look at the pretty pictures. They look at the way the page is organized, with sidebars or highlighted areas, and the way things are styled or grouped. Designers use the visual appearance of elements to help us understand the structure of the page, and which items are related to each other. For example, check out this wireframe of a page.

A wireframe diagram of a product page. It doesn't have readable text, but the usual site elements like menu, images and forms are distinguishable from their shapes.

You can’t understand the content, of course, because the text is represented by squiggly lines. But you could probably point to the headings, the list and the alert message. This is because the designer has included visual cues to help you understand what types of information are available.

The Info and relationships success criteria is about making sure that everyone gets the information, even if they can’t perceive the page the way other people can. When we’re talking about information and relationships, what we’re talking about is more than visual presentation, we’re really talking about HTML.

HTML is the backbone of the web. Or rather, the forgotten backbone. Done right, HTML is humble. And because it’s “just markup” and not programming, it tends to get less time and attention than the more challenging languages, or whichever new framework was announced this week.

Sometimes programmers think that learning HTML is beneath them because it’s not real programming. But HTML markup is how people actually get the results of your programming. It’s the part of the web that connects your content to the whole world, so it deserves just as much care and attention as your programming and your server.

Results from our research

When I looked through the data from last year, I saw hundreds of accessibility issues caused by mistakes with basic HTML markup. People who had great content which deserves to be seen, but who had made a mistake in building their tables, or used spans to make a list, or didn’t realize what the hell the rarely-seen sup element is for.

A pie chart showing the percentages of the structure issues as described below.

You’ll see in the graph above that headings represented our biggest problem, totalling 35.92% of our issues with criteria 1.3.1. Tables were next at 24.27%. It seems people are still confused about when to use tables and when not to use them. Half of those issues reported were for tables being used for layout, and the other half were data being presented by divs or lists instead of tables. Speaking of lists, not using ordered and unordered lists were next with 11.89%. This was a bit surprising to me, because most WYSIWIGS and text editors provide good list tools. Forms made up 9.59% of the problems, which was mostly due to people using fieldsets and labels for their visual style and not for their semantic meaning. The navigation group (4.98% of the issues) included invalid markup on links, buttons, tabs, and menus, or divs and spans with scripting added. The Other category had 13.36% of the issues, and included a little bit of everything: extra paragraph elements used instead of CSS to create white space, deprecated elements, elements which were meant to be hidden, but showed up when a keyboard focused on them, and so on.

Why HTML matters for accessibility

People consume content in different ways, using different devices and different assistive tools. Web content, and its underlying structure, needs to retain its meaning when presented in these different formats. At Simply Accessible we check that the information presented by the website, and relationships between different parts of the website, can survive being transformed. We turn on high-contrast themes, we listen to the content using a screen reader, we resize the text, and we shove it into a variety of devices, because people might be using any sort of technology to view your project.

Luckily, browsers don’t just beam your site onto a screen—they also expose your carefully created HTML and content to an accessibility API. This can then be used by screen reader software to translate all of that information to speech, or by a Braille reader and keyboard to translate it to Braille.

When you use semantically correct HTML, you’re empowering people so they can find what they want faster and more easily.

When we write HTML, we have to let the browser know what type of content it’s dealing with and how that content relates to other content. By doing this, we let the browser and assistive technology like screen readers do their job: taking your content and giving it to anyone who’s interested in it, in any format they need. When software gets nothing but div soup, or elements used incorrectly, your page has no structure assistive technology can work with.

Screen reader software like JAWS or NVDA doesn’t just turn text into speech. It can use the information in the HTML to list all the headings on a page, so people can still skim ahead to find the section they want. Screen readers also give extra navigation controls to data tables, so people can review a row at a time, or jump to a single cell to get just the one bit of data they want. They announce how many items are in a list, so people can skip it if it’s not useful or search for the exact item they want.

Creating accessible information and relationships

My websites have semantic HTML as the base layer of everything I do. As Devon pointed out in her article about the accessibility stack, getting your HTML right makes the rest of your accessibility tasks so much easier. Let’s take a quick look at how to use HTML semantically so software doesn’t have to guess which parts of your content are important for your users and how they relate to one another.

Use container elements for layout only

Elements like divs and spans are for layout only. They’re semantically meaningless: divs create a display:block container and spans make a display:inline container, and that’s all they do. They don’t add any text styling, or have any size until you put more HTML inside them or add CSS. They don’t have keyboard or touch support in any browser, and they don’t communicate anything to the accessibility API. They just make a spot in your page where other things might happen. So, when divs and spans are used for headings or buttons (which both convey meaning and function), the browser can’t translate them into alternative formats with any functional purpose for someone using a different device to access your site.

Use other HTML elements the way they’re intended

All the other HTML elements should be used to tell the browser what functional purpose your content serves—not for layout:

  • Data goes in a table;
  • headings in h1 - h6 elements;
  • lists have list item (li) elements wrapped in ul or ol elements;
  • links (a) are for navigation, and buttons are for actions; and
  • inputs should only appear inside form elements, and should always have a label.

HTML elements provide meaning to the browser and assistive technology about what you’re saying on your website, so choose them based on what the content is, not how they look with slick graphics and CSS3 transitions. Old-timers might remember the CSS Zen Garden website: one page of HTML with hundreds of different looks thanks to user-submitted CSS. It demonstrates beautifully how content should be separated from presentation.

How much difference does proper HTML really make? Glad you asked!

Example: Heading will structure set you free

Say you need to scan the WCAG2 colour contrast guidelines and find out the proper contrast ratio for your brand colours. If you pop over and take a look at the W3C page, you’ll see it’s a pretty overwhelming wall of text. But a quick skim of the headings gets you to the right place in no time.

Screen reader software does exactly the same thing. It has a shortcut key which asks the browser to search the HTML for anything inside a h1 to h6 element. It sends that list back to the screen reader, which announces the headings, allowing a screen reader user to skim the page as quickly as you did, or even quicker if they’ve turned up the speaking speed to double-time.

A list of headings from a NVDA speech viewer for the WCAG page described.

If the W3C hadn’t used proper heading elements, you’d be stuck listening to stuff about pixel densities and ANSI standards for ages before you found what you needed. It might not seem like much, but using relevant HTML can make life so much easier for everyone.

Hide or do not hide: there is no try

When you remove something from the page, or disable it, make sure you’re really getting rid of it. Using CSS to grey it out, or make it transparent, leaves the element in the DOM and therefore available to the keyboard, touch devices, and assistive devices—even though you didn’t want anyone to use that control. To truly hide content, display:none is usually your best bet. I tend to put it in a helper class called hidden-all so I can apply it wherever I need it. And if you want to put in some visually hidden notes just for screen reader users, I like to make a class called hidden-visual. Those look something like this:


.hidden-all {
   display: none;
}

.hidden-visual {
   border: 0;
   clip: rect(0 0 0 0);
   height: 1px;
   width: 1px;
   margin: -1px;
   padding: 0;
   overflow: hidden;
   position: absolute;
}

If in doubt, check it out

Obviously, on the Internet we have some excellent resources on the HTML elements which form its backbone. The Mozilla Developer Network has a HTML reference with documentation, plus tutorials from beginner to advanced. Jeffrey Zeldman’s Designing With Web Standards is a classic on how to make the most of your HTML. Or you can ask your friendly accessibility expert!

In 2016, I’d love to see people who build the web make a commitment to becoming expert in HTML as well as the the newest frameworks and libraries.

If there’s any aspect of HTML accessibility you’d like to know more about, leave us a comment here and we’ll write a post about it. If you’re making one of those frameworks and libraries, please do make sure your HTML supports the structure of the content—you have the opportunity to set a good example for people who are just starting out in the wonderful world of the web.