Accurate subheadings make your content much more useful for everyone — but when you’re creating your website, you’ll need to make sure that your headings are both visual and programmatically determinable.
Fortunately, that’s not as complicated as you might think. A visual heading is exactly what it sounds like: A subheading that can be identified through visual presentation alone. Subheadings are programmatically determinable when software (such as web browsers and screen readers) can identify them.
Below, we’ll discuss how to create subheadings that fulfill the requirements of the Web Content Accessibility Guidelines (WCAG), the international standards for digital accessibility.
A Basic Introduction to Subheadings and Accessibility
Subheadings break your content into more digestible “chunks,” which makes them more understandable and useful. Without subheadings, your website would be a wall of text — and few people would read every word.
Two WCAG Success Criteria (SC) apply to subheadings:
- WCAG 2.1 SC 2.4.6, “Headings and Labels,” requires subheadings to provide clear, descriptive information, which enables users to understand the relationship between different parts of the content.
- WCAG 2.1 SC 1.3.1, “Info and Relationships,” requires that information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.
In most situations, you’ll use native HTML to identify headings programmatically. Your website’s CSS (Cascading Style Sheets) will identify the headings visually.
How Visual Subheadings Might Affect Users with Disabilities
To explain why subheadings must be both visual and programmatically determinable, let’s consider a quick example.
A website uses subheading tags (such as <h2> and <h3>) to structure its content. When a screen reader user accesses the website, they can “scan" the text using the subheading tags to find the information they want.
However, the text within the subheading tags looks the same as the other text on the page. People who do not use screen readers or other assistive technologies (AT) cannot quickly identify the headings — in order to find information, they’ll need to read through blocks of text.
This is an uncommon accessibility barrier. More often, developers make a different type of mistake: They’ll use CSS to visually present a heading, but they’ll forget to use accurate HTML — the headings don’t contain <h2>, <h3>, or other HTML subheading tags. This prevents people who cannot perceive content visually from identifying the subheadings.
The bottom line: To create an accessible website, you’ll need to use visual headings with appropriate semantic HTML. The best way to do this is to HTML to structure your page, then use CSS to style the content visually.
Related: Plain Old Semantic HTML: A Perfect Basis for Accessibility
Writing Accessible Subheadings with HTML
HTML heading tags should appear in sequential order and provide people with enough information to understand your content. For example:
<h1>Types of Cars</h1>
On this page, we’ll list cars from different manufacturers…
<h2>Ford Cars</h2>
Ford manufactures cars and trucks…
<h3>Ford Focus</h3>
The Ford Focus is a compact car introduced in 1998…
Ideally, the visual appearance of your subheadings should reflect their order. In other words, the <h1> heading should be visually larger than the <h2> subheading, which should be visually larger than the <h3> subheading.
Related: Is Going from H1 to H3 Okay for WCAG Conformance?
When to Use ARIA’s role=heading Attribute
What if your website contains visual headings, but you can’t use native HTML?
This can occur if your site contains scripts that depend on a certain hierarchy or if you have a large number of heading levels (HTML only supports headings through level 6).
Both situations are extremely rare. If you’re using heading levels past <h6>, there’s a good chance that your content should use a simpler structure. Likewise, if your website depends on a legacy hierarchy, the best practice is usually to recreate your scripts — while this can be expensive, it’s generally better as a long-term solution.
In other words, if you can use native HTML for headings, you should always do so. However, that’s not possible on every website. When this is the case, WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) can help.
WAI-ARIA’s role=heading instructs assistive technologies to treat elements as headings. If your site has visual headings that are not identified as headings in native HTML — and you’re absolutely sure that you cannot use HTML — use role=heading.
Here’s a quick example of role=heading in practice:
<h1>Types of Dogs</h1>
…
<h6>Types of Malamutes</h6>
<div role="heading" aria-level="7">Malamute Mixes</div>
For more guidance on the correct usage of this role, read the W3C’s page on role=heading.
Quick Tips for Writing Subheadings
When you structure your website correctly, you provide all users with a better experience. Unfortunately, subheadings are often misused — designers may use HTML headings to style their pages, and content writers may create headings that aren’t descriptive or useful.
Here are a few tips to keep in mind when creating your content:
- Keep subheadings concise and descriptive. For example, “More Information" doesn’t say much, but “More Information About the 2000 Ford Focus" is much more useful.
- Always use HTML subheadings in sequential order.
- Use other semantic HTML attributes to identify header menus, footer menus, and other content that is repeated on multiple pages.
- Test your website’s structure. A simple test: Use your keyboard’s Tab and Shift-Tab commands to navigate through the page. Does your focus move in a predictable way?
- Only use WAI-ARIA for subheadings if you’re absolutely sure that it’s necessary. Remember, ARIA is not a replacement for semantic HTML.
To make sure your website follows WCAG, you’ll need to audit your content regularly. Automated tools like the Bureau of Internet Accessibility’s Free WCAG 2.1 Level AA Compliance Summary can identify many structural issues that lead to accessibility barriers, but for long-term conformance, we recommend combining automated tests with manual reviews performed by individuals with disabilities.
For more information or for guidance with a specific website, send us a direct message to connect with our subject matter experts.
