Heading doesn't describe its section

What is this issue?

A heading element has non-empty text content, but that text carries no specific information about the section beneath it, commonly a single generic word (“More,” “Info,” “Details,” “Overview,” “Section”) that could apply equally to any part of any page. The heading is structurally present and technically announced correctly; the failure is in the wording, not the markup.

This is distinct from an empty heading, which has no text at all. A vague heading has real, readable text (a screen reader announces it without any silence or gap), but the words themselves fail to identify what the reader is about to encounter.

Why does this matter?

Screen reader users often build a mental map of a page by pulling up a list of every heading at once: NVDA and JAWS can generate an on-screen list of headings, and VoiceOver’s Rotor does the same on macOS and iOS. When several headings on that list read “More,” “Details,” and “More” again, the list gives no way to choose where to go. A sighted user scanning the same page visually can lean on font size, position, and surrounding imagery to guess what each section covers; a heading list strips all of that away and leaves only the words.

The cost is time and confidence. Instead of jumping straight to the section they need, a user with three identically vague headings has to open each one, read into the body text to figure out what it actually contains, and back out if it’s the wrong one, repeating a process that a single well-chosen heading word would have made instant.

Who is affected?

• Screen reader users: see identical or near-identical entries in a heading list and can’t distinguish sections without opening each one and reading further to check.
• Cognitive disabilities: users who rely on headings to reduce how much text they need to process lose that shortcut when every heading requires reading the paragraph underneath to understand what it’s for.

What users experience

Owen uses JAWS on Windows to research a warranty policy on a retailer’s support page. He opens JAWS’s headings list (Insert+F6) expecting to jump straight to the right section, but three entries in a row read “Details,” “Details,” and “More”: one for shipping, one for returns, one for the warranty itself, with no wording to tell them apart. He has to close the list, tab into each section in turn, and read the first line of body text under each heading before he finds the one about warranties, turning a two-second jump into a several-minute search.

How do I fix it?

Rewrite the heading to name what the section actually contains, using words specific enough that the heading alone tells a reader whether to continue into that section. This works because a heading’s entire value to a navigating user comes from distinguishing one section from every other section on the page; generic words provide zero distinguishing information no matter how grammatically correct they are.

Write the replacement heading the way you’d label a tab or a table of contents entry: short, specific, and meaningful without the surrounding paragraph. If a generic word like “Overview” or “Details” is unavoidable because of a design pattern, pair it with the specific subject it covers (“Warranty overview” instead of bare “Overview”) so the heading still stands on its own in a list of headings pulled from the whole page.

Code Examples

<h2>More</h2>
<p>Browse extended warranty options, return windows, and shipping rates for this item.</p>

<h2>Shipping and returns</h2>
<p>Browse extended warranty options, return windows, and shipping rates for this item.</p>

The body text didn’t change; only the heading did. “Shipping and returns” tells a screen reader user exactly what to expect before they commit to reading further, where “More” gave them no basis for that decision at all.

Common Mistakes

Mistake: “The heading makes sense once you read the paragraph under it, so it’s fine.” That’s true for a sighted user scrolling in order, but it defeats the entire point of heading navigation, which exists so a screen reader user doesn’t have to read every paragraph to find the right section. A heading has to work as a standalone label, not a label that only becomes meaningful in hindsight.

Mistake: “Vague headings are a wording nitpick, not a real accessibility bug.” A vague heading doesn’t break anything programmatically (the markup is valid, the text is announced correctly), but WCAG 2.4.6 specifically requires headings to describe their topic, precisely because heading navigation is a core assistive-technology workflow. Treating this as cosmetic ignores that the entire mechanism screen reader users rely on to scan a page depends on heading wording being informative.

Mistake: “Automated scanners will catch any vague heading, so I don’t need to review this by hand.” Automated tools check heading text against a limited list of known generic words. A heading that’s vague in a novel way (an internal codename, an unexplained acronym, a marketing phrase with no clear referent) won’t match that list and will pass automated scanning while still failing a real reader trying to navigate by it.

How RedFlag Detects This

Automated: axe-core rule, runs on every scan. RedFlag calls axe-core’s heading-vague rule as part of every scan, restricted to the WCAG 2.0/2.1/2.2 A and AA rule set. The rule checks a heading’s accessible name against a known list of generic, non-descriptive terms axe-core maintains (words and short phrases like “more,” “details,” “info,” and “click here”), flagging an exact or near-exact match.

False negative: axe-core only recognizes wording on its own known-vague list: a heading that’s equally uninformative in a way not on that list, such as “Section 3,” an internal team’s jargon term, or a lone unexplained acronym, passes the automated check even though it gives a screen reader user no real information. False positive: a heading that legitimately matches a listed generic word as an intentional proper noun (a loyalty program literally branded “More Rewards,” for example) can be flagged even though the word is accurate content, not vague filler. Manual step: read every heading on the page in isolation, without the surrounding paragraph, and ask whether it alone tells you what the section covers; rewrite any that don’t, regardless of whether the automated check flagged them.

Manual Testing

1. Open the page in Chrome or Firefox with NVDA or JAWS running on Windows.
2. Open the screen reader’s heading list (NVDA: Insert+F7, then filter to Headings; JAWS: Insert+F6) to see every heading on the page at once, out of context.
3. Read through the list as if you had no other information about the page. For each entry, ask whether the word or phrase alone tells you what that section covers.
4. On macOS or iOS, repeat the check with VoiceOver’s Rotor set to Headings, since wording that reads fine visually can still sound flat and indistinguishable when read aloud in a list.
5. Any heading you can’t distinguish from at least one other heading on the list, or that gives you no real expectation of the section’s content, fails.

Related WCAG Success Criteria

2.4.6 Headings and Labels: Headings and labels must describe their topic or purpose. A vague heading is a direct failure of this criterion: the heading exists and is structurally valid, but it doesn’t describe the topic the way the criterion requires.

Related Issues

Heading is empty or contains only whitespace is the more severe version of the same navigation problem: no text at all, rather than text that’s merely too generic to be useful.

Heading levels are skipped covers the structural side of heading navigation: the wording can be perfect, but if the level sequence jumps, the hierarchy those headings describe is still broken.

Element has ambiguous or unclear accessible name and Element label lacks sufficient context are the same “present but unhelpful” naming failure applied to links, buttons, and form fields instead of headings.

References

• W3C Understanding 2.4.6: Headings and Labels
• WebAIM: Semantic Structure - Headings
• W3C WAI Tutorials: Page Structure - Headings