Heading elements (h1, h2, h3, etc.) help to break up the content of the page into related “chunks” of information. They are incredibly important for people who use assistive technology. If headings and HTML landmarks are used correctly, the user understands the meaning of a page or view and has a better experience.
Quick example
To illustrate the point, I want to show two examples:
Imagine that we have:
💡 A simple website, where visually we can distinguish the "blocks" of content, with headings, images and we clearly see the overall hierarchy.
We don't know yet whether the code behind it actually using h1, h2 and so on, but visually it's clear where the titles are and what is in front of us.
This is the same website with no heading structure and no hierarchy. For the users with assistive technology, it creates overall confusion since there is no way to know where to navigate.
This is how it looks for the users that use a screen reader.
And here is how the website looks for them, when we - developers - code the correct document structure and respect heading order.
By the way, I'm taking the images example from A11ycasts#18 video with Rob Dondson, that I highly recommend watching 👉 A11ycasts episode on Youtube
"But I want to do it the right way. Where can I start?" 👩🏼💻
First, understand that users who use the keyboard and screen reader must be able to skip the content, navigate the web and get an equally good experience from the start.
Secondly, let's answer some of the questions with accessibility in mind:
Does your website makes sense if you view it after having turned off JS/CSS?
DOM order matches the visual order?
Can you navigate with the normal flow?
Do users have the ability to jump to any section of the document and get to the information quickly?
As you may know, screen reader users use heading to navigate through the page.
✨VoiceOver Keyboard Shortcuts✨
VO+H(Control+Option+H) to navigate
Control + Option + U to open rotor
Can you see how users can immediately benefit from the correct HTML tag and order?
Consider the example:
<h1>Title of the Page</h1><p>Here's a little bit of information before we get started</p><h2>Hey you, heading 2</h2><p>Here's a little bit of info about the second heading</p><h2>Here's another heading for testing purposes</h2><p>Here's a little bit of info about the second heading</p>
WCAG failures:
Heading-like text that isn’t marked up as headings (Level A)
❌
<pclass="title">Introduction</p><divclass="subtitle">Looks like a subtitle</div>
Illogical heading order (<h2> is not followed directly by an <h4>) (Level A)
❌
<h3>Bacon and mushroom risotto</h3><p>To cook a perfect risotto, it is essential to […] </p><h2>Instructions</h2>
❌
<h2class="card-subheading">Subheading</h2><h4class="card-heading">Heading</h4>
Nondescriptive headings (Level AA)
<h2>Recipe</h2><p>To cook a perfect risotto, it is essential to […] </p><h2>Recipe</h2><p>A coq au vin is a classic French stew in which […] </p>
Bad scenarios 🤨:
Not every issue counts as a WCAG failure, but they all potentially cause some confusion and pose potential barriers for people with disabilities. Such as:
A lack of headings (unless you’re striving for Level AAA)
Missing <h1>
More than one <h1> per page
Do not select heading levels based on their appearance (font-size). Select the appropriate heading rank in your hierarchy.
Using headings that don’t appropriately describe their related content does represent a failure of 2.4.6 Headings and Labels.
Headings should not be used as subheadings, subtitles, alternative titles, taglines, or slogans. In such cases, it is best to use a
tag.
Best practices (common sense)✅:
Headings are ranked <h1> through <h6>.
<h1> representing the most important idea on the page
sub-sections organized with <h2> level headings. Those sub-sections can themselves be divided with <h3> level headings, and so on.
Heading levels should increase by one h1 > h2 > h3 > h4 > h5 > h6
❌
<h1>Title</h1><h3>Some text that's not a heading, but we want "bigger" text</h3>
✅
<h1>Title</h1><h2>Chapter1</h2><h3>Some subsection</h3><h2>Chapter2</h2><h3>Some subsection</h3>
The beginning of the main content should start with <h1>
<h1> representing the most important idea on the page. At the same time, hero h1 does not necessarily represent the page, but it's just a slogan.
#### What if the design doesn't have a heading?
Or it's not always can be present, but the page still should have the h1 heading to give the user context.
<body><header>logo - navigation</header><main><h1class="sr-only">Showcase page or another heading name</h1></main></body>
Specs
Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)
Screen readers allow users to navigate by headings, so headings are an effective way to bypass blocks of content, as required by WCAG 2.4.1 (Level A)
Headings MUST be accurate and informative, as labels for the sections of text they describe. (Level AA)
Section headings are used to organize the content. (Level AAA)
Alternatives
If a scenario arises where you can’t make changes to existing elements’ hierarchy, there is an alternative method that you can use to provide semantics: using Accessible Rich Internet Applications (ARIA).
role="heading" can be placed on an element to assign it a role of heading.aria-level needs to be placed on the same element as role="heading" to assign the element’s heading level.
HTML5 outline
Sadly, heading algorithm was never really picked up by any browser or screen reader, and the HTML 5.2 draft advises against using it any further.
Real-world example
Here is a snippet from React library (linked in resources below) that implemented accessible <Heading/> and <Section/> components.
A collection of inclusive components for React created with styled-components worth your attention if you want to quickly improve #a11y of the app 👩🏼💻
Inclusive components for React, created with styled-components. Based on Heydon Pickering's book, Inclusive Components
react-inclusive-components
Inclusive components for React. Based on Heydon
Pickering's book, Inclusive Components.
The library does not include React, it's just a collection of components to make the development of accessible apps easeir.
It has a minimum stylings that ensures that these elements are behaving properly and avoid different pitfalls (e.g. hiding an element from user but still making it accessible by the screen reader).
These components are not stateful and as abstract as possible to not interfere with any development that you are doing.
You can submit issues or Pull Requests at the GitHub repo.
Enjoy.
Usage
Button
Accessible button component. Can be of several types:
submit — Regular form submit button
button — Regular button that can handle various events
toggle — A toggle button for handling the 'on/off' state of various
interface elements. Automatically adds aria-pressed attribute with the
passed values.
1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)
Guess how many heading I used in order to structure this post?
I kept getting back and forth in between "code" and preview in order to make my markdown match the visual structure. Can we do the same with our webs?
Remember:
✨The more you do it, the less of the effort it takes✨
If you like this article and the information that I have put together for you this time, please, share it with your colleague and reach out to me on Twitter, whether you liked it or have suggestions 💚