Headings for the Visually Inclined

#a11y #webdev #beginners #html

This is the first of a series of articles focused on accessibility for sighted users, Accessibility for the Visually Inclined.

Chances are, you, the reader of this article, have two eyes that you use to read the content of a web site, whether with or without some corrective lenses.

While not all people fall into this category of sighted people — in fact, hundreds of millions aren’t a part of this group¹ — this article is statistically written for you.

When you open a new web page, you probably scan it visually for the content you need. Maybe you’re looking for a specific forum post, so you skim for visible Links and/or title text. Maybe you’re looking for another page, so you search for a navigation bar.

But how do people who don’t see scan the page for content?

Back in ye olden days of the internet, before our sites were made beautiful by CSS², web sites were just text, links, and images with some tables sprinkled here and there. We relied entirely on the semantics of the page to convey contextual meaning. The heading of your page had to use an <h1> element, tables had to use <table> elements, etc., or if not, you settled for unformatted content.

Now that we’ve left the dark ages and we can style our pages in whatever way we see fit, we don’t always need to use semantics to convey contextual meaning visually. We can make that first line of text of our article the BIGGEST without using an <h1>. We can use font sizes and weights and colors, and maybe italics or small caps or whatever beautiful design you can imagine (as long as it’s supported by most browsers). While this gives us the freedom we’ve all been itching for, we can become entirely reliant on that sweet-sweet cascading sheet to create our user experience and forget about our users who interact with our page differently.

Let’s take an example:

You can tell I’m not a designer.

In the above scribble, you can see a mock website with a page-level heading “The Hubbosphere”, secondary headings for the different sections of content: “Top Stories” and “Recent Activity”, and lower-level headings under those sections, including “Mona is Cool”, “A Very Hot Topic”, and “Something Monumental”.

We flesh out this design in a Codepen you can play with below.

If this design was put into the wrong hands, the visual output of the page may look fine, but something is amiss. When you click the buttons in the top toolbar of this Codepen, whether you show correct or incorrect Semantics, the styling of the page remains the same.

However, if we remove the styling, you can see all content blends together, whether heading or not.

All the headings and paragraphs look identical, simulating the experience of a screen reader user

If we use <h1>, <h2>, and <h3> before applying our visual styles, the page maintains its proper hierarchical structure, even if styles are turned off:

The highest-level heading is the biggest now, the secondary headings are the second-largest, and the third-level headings are the third largest. This simulates the experience of a screen reader user when semantics are used.
Thanks to default browser styles, we can visualize that the page has proper headings now.

Now you, an observant reader, may notice that the end result of this web page has “Recent Posts” as a smaller heading than the sections below it. Here’s the crux of it: Regardless of the design, we should use the headings in the right order first, and apply styling second.

Another way to say it:

Use Heading levels for their hierarchy and organization FIRST, and their styling second.

This extends to designs that may put higher headings in a smaller font than their child sections, such as “Recent Activity”.

Why does this help people with vision disabilities interpret the page? Their Assistive Technology relies on Semantics to convey contextual meaning. In fact, about 68% of people using screen readers³ navigate the page using Semantic Headings.

“Ok I use headings though, so I’m good right? It’s not that hard to use semantics.”

Sure, I hear you. In my next article, let’s talk about an accessibility need that semantics can’t cover then: Button Context.

This article looked at Headings, which is only one aspect of Semantics. If you want to learn more about Semantics and how to use them correctly, check out: WebAIM’s thorough article on Semantic Structure.