Skip to content

ACT 2.4.6 atomic rule Update #2425

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
grifare wants to merge 28 commits into
base: develop
Choose a base branch
from
Draft

ACT 2.4.6 atomic rule Update #2425

Changes from 26 commits
Commits
Show all changes
28 commits
Select commit Hold shift + click to select a range
84f4a8b
Update WCAG 2.4.6 atomic rule draft
grifare Jun 29, 2026
1d6fe02
Clarify heading relevance rule description and applicability
grifare Jun 29, 2026
d2ad7da
Update acknowledgments and refine rule scope
grifare Jun 29, 2026
816bc57
Refine heading relevance rule description and context
grifare Jun 29, 2026
4974e86
Refine heading rule by removing duplicates and clarifying scope
grifare Jun 29, 2026
edcaf8a
Revise heading examples and add new passed cases
grifare Jun 29, 2026
4d002c0
Fix link formatting for section headings resource
grifare Jun 29, 2026
bca3157
Refine heading examples in descriptive rules
grifare Jun 29, 2026
94c8e82
Major update
grifare Jun 30, 2026
640c92b
Examples added until Passed (Situation E)
grifare Jun 30, 2026
28e978d
Ends at Failed example 9
grifare Jun 30, 2026
5a978e0
Until Failed Example 12
grifare Jun 30, 2026
227b7d5
ends at #### Failed Example 12
grifare Jun 30, 2026
ed200e1
Minor edits in Background
grifare Jun 30, 2026
c12e930
Minor language edits and reorganised sections
grifare Jul 1, 2026
c2637a5
Changes in the "None of the following is within this rule's scope" se…
grifare Jul 1, 2026
eee1e6b
Changes in "Expectations"
grifare Jul 1, 2026
0bb437d
Delete mistakenly pasted portion from the old file
grifare Jul 1, 2026
57e2265
Changes in the "Background" section
grifare Jul 1, 2026
d97d76d
Merge branch 'develop' into grifare-patch-1
grifare Jul 1, 2026
460da79
Entire act rule content drafted
grifare Jul 9, 2026
ed0ff54
Fix typos
grifare Jul 9, 2026
384c3bc
Fix formatting issues in heading examples
grifare Jul 9, 2026
f63baf3
Self-reviewing starts
grifare Jul 10, 2026
44fc44d
Update rules for empty heading elements
grifare Jul 12, 2026
af2645e
The work will be divided into 2 separate parts, this section is the f…
grifare Jul 30, 2026
50e204d
Update _rules/heading-descriptive-b49b2e.md
grifare Aug 7, 2026
22fd9bb
Changes made based on feedback, more changes to come
grifare Aug 7, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
206 changes: 18 additions & 188 deletions _rules/heading-descriptive-b49b2e.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,10 +1,10 @@
---
id: b49b2e
name: Heading is descriptive
name: Heading is relevant
rules_format: 1.1
rule_type: atomic
description: |
This rule checks that headings describe the topic or purpose of the content.
description:
This rule checks that headings are relevant to a specific topic, purpose or page.
accessibility_requirements:
wcag20:2.4.6: # Headings and labels (AA)
forConformance: true
Expand All @@ -13,11 +13,11 @@ accessibility_requirements:
inapplicable: further testing needed
input_aspects:
- Accessibility Tree
- DOM Tree
- CSS Styling
- Language
acknowledgments:
authors:
- Armağan Tekdöner
- Carlos Duarte
- Dagfinn Rømen
- Geir Sindre Fossøy
Expand All @@ -27,203 +27,33 @@ acknowledgments:
---

## Applicability
This rule applies to semantic heading elements that are [included in the accessibility tree](included-in-the-accessibility-tree "Definition of included in the accessibility tree"), as well as to any HTML element that is styled as a heading. Elements that are styled as a heading may include features such as a larger font-size than nearby text, bolding or changing of the font, or the use of whitespace or shapes that visually distinguish the element text, as well as an image of text such as a text banner displayed like a heading as the first visible element on the page.

@WilcoFiers WilcoFiers Aug 7, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This new applicability is ambiguous. That's not allowed in the rules format. You're not defining when a bold or large text is a heading and when it isn't. As I mentioned before, I think that's a problem we should leave for another rule. Many rules we wrote rely on other rules to address gaps. That way we keep a rule atomic and understandable. Instead of making this one rule do both jobs of determining which things should be headings, and which headings are then descriptive, we're better off separating those.

The way I'd break that down is to write three rules:

  1. Things that look like headings have heading markup (1.3.1)
  2. Elements with heading markup is only used to convey page structure (1.3.1)
  3. Elements with heading markup describe their section (2.4.6, this rule)

That covers the full spectrum of testing needed for headings, giving each rule a specific task. I think we should keep the applicability as it is today. This follows the suggestion of the rules format to put subjective and objective applicability into separate rules. Rule 1 would have a subjective applicability, the rest wouldn't need it because it can build on rule 1.

@grifare grifare Aug 7, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with you that using bold style as an example without defining when to consider it as a heading will be ambiguous and puzzling for testers. It can have many adverse effects. (I copied that text from your feedback.)

However, if we keep the applicability as it is today, I think it will be incorrect. The current text explicitly refers to the semantic headings only. According to the current wording, <p class="h1">Non-semantic heading</p> is out of scope, am I mistaken?
https://www.w3.org/WAI/standards-guidelines/act/rules/b49b2e/proposed/#applicability

Unless we clearly say this rule applies to all elements that can be perceived as headings as well as the real headings, we will not be accurate. I don't think there is no way to describe something as subjective as this criterion unambiguously in one sentence or two. That is what examples are for.

Therefore, in addition to the existing test, I insist that something like this should be present:

Applicability

This rule applies to any semantic heading element that is included in the accessibility tree and has a non-empty "" accessible name. It also applies to other elements that are not semantically heading elements, but that are presented as headings.

For now, I made the change as shown above, but I am 100% open to any edits you would suggest there. "Presented" could be "perceived" or there are lots of other alternatives. I just want to underscore the difference of 2.4.6 from others, which is evaluating plain text, not the inspected code or not what screen readers announce.

@JennChadwick JennChadwick Sep 2, 2026 •
edited
Loading

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the invitation to review the comments and feedback, @grifare and @WilcoFiers.

I agree and support these three rules to remain unambiguous about the purpose of headings on a page and semantic application with HTML < H > .

  • Things that look like headings have heading markup (1.3.1)
  • Elements with heading markup is only used to convey page structure (1.3.1)
  • Elements with heading markup describe their section (2.4.6, this rule)

@grifare @WilcoFiers I would defer to someone with more coding skills, but for my understanding as well, a < p > with a class of "heading" would still announce by screen reader as a paragraph, and that is a CSS class for presentation only. So it doesn't fit the rule.

@grifare what are your thoughts?


This rule applies to any [semantic][semantic role] `heading` element that is [included in the accessibility tree][] and has a non-empty (`””`) [accessible name][].
### Applicability Type Designation:
Rule contains subjective applicability, depending on whether the element evaluated as a heading by implementers should be considered a heading.

@WilcoFiers WilcoFiers Aug 7, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't need this.

Suggested change
### Applicability Type Designation:
Rule contains subjective applicability, depending on whether the element evaluated as a heading by implementers should be considered a heading.

@grifare grifare Aug 7, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand why this option exists at all, if it will not be used even here.

Rules can optionally include an applicability type identifier signifying whether the rule contains an objective or a subjective applicability. This identifier is intended to benefit rule readers and implementers by clearly stating the rule author’s intention of the applicability and reducing confusion due to different reader and implementer interpretations.

https://www.w3.org/TR/act-rules-format-1.1/#applicability-type-designation-atomic-optional

I can see that we are trying to avoid the word "subjective", but if there is one rule that word applies to, it is this rule. If AI will decide what headings humans should write using the "accessibility" card, that will be yet another step towards ending human creativity.

I suggest we discuss this with others. I am keeping it for now with some simplification. It can easily be deleted if others do not want it.


## Expectation

Each target element describes the topic or purpose of the first [perceivable content][] after the test target that is not [decorative][]. The order of elements is determined by the [flat tree][].

**Note:** Headings do not need to be lengthy. A word, or even a single character, may be sufficient.
## Expectations
Comment thread
grifare marked this conversation as resolved.
Each heading is relevant to the specific page or section where it appears and it is sufficiently intelligible.

@WilcoFiers WilcoFiers Aug 7, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems fairly ambiguous. Here are the questions I had about it:

  1. What does it mean for a heading to be relevant to a section?
  2. If the heading is relevant to the page, does it not need to be relevant to any section?
  3. What are sections?
  4. How do I know which heading goes with which section?
  5. Can a heading belong to multiple sections?
  6. What does it mean for a heading to be intelligible?
  7. How do I know if a heading is sufficiently intelligible?

Having read through understanding docs, and some other people's writing about 2.4.6 I no longer think we should change "descriptive" to "relevant". If a heading is irrelevant to the section its in, than I think its either in the wrong section, or it shouldn't be a heading at all. Either one is a failures of 1.3.1. Where 2.4.6 comes in is when headings are relevant, but insufficiently descriptive. On a recipe page using "Recipe 1" instead of "Vegetarian lasagna" for example is a heading not being relevant.

I'd recommend doing a few things with this expectation:

  1. Create a new definition for "section". Something like "A visually distinct region of the page" Sections are separated through visual clues, including changes in background, borders, dividing lines or images, a change in width, a change in column numbers, or a starting heading. Sections may contain sub-sections.
  2. Create a section heading definition, that builds on the section definition. Something like: A section heading is the first semantic heading of the section.
  3. I think we'll want an inline definition of "descriptive". So after this first sentence of the expectation, you could say something like: "A heading is descriptive when ..."
  4. I don't think intelligible is needed here. Make that part of the inline definition of descriptive.

@grifare grifare Aug 7, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Descriptive versus relevant

Replacing "descriptive" with "relevant" was my proposal right from the start and we began working on this assignment after you accepted it. I also proposed "meaningful" but then we removed it upon your request, as you were right in the sense that anything could be considered meaningful by itself.

But I still think the devil is in the word "descriptive". A tester can fail anything using that. Here is what reports will be reading: "this is not descriptive enough because, that is not descriptive enough because". To avoid that, the "first perceivable content" term was introduced, but then the rule became an artificial requirement of writing 2 sentences that repeat each other.
Replacing any proposal not existing before with the existing text may be not be a very meaningful study.

On a recipe page using "Recipe 1" instead of "Vegetarian lasagna" for example is a heading not being relevant.

I assume you provided the example above as a "PASS" example, right?

That is why I created situations in examples. (I will remove all situations to use the existing format, no doubt about it. I am pasting it here for now just to make my point.)

Passed (Situation B)

Headings that serve as structural or sequential identifiers, which are inherently compliant regardless of the specific content that follows.

Passed Example 4

This h1 element provides a sequential identifier for a major document section. The content that follows makes no difference to the outcome of this test.

<h1>Chapter 4</h1>

I also had a section like this, which was not using the format. However, I think it is helpful section and it could be used elsewhere, as you would suggest.

### None of the following is within this rule's scope:
- The sequential order of heading levels, such as evaluating whether a heading skips levels in the hierarchy (e.g., moving from an `h2` directly to an `h5`)
- Coding or parsing errors in headings (assuming that the heading is visible or exposed to assistive technologies), such as mismatched tags like `<h2>Meaningful and relevant heading</h3>` which browsers automatically correct in the DOM
- Factual accuracy of headings, such as the verification of historical dates, including names, locations, technical facts
- Technical mistakes related to numeration or ordering in headings, such as skipped numbers, sequencing or arithmetical mistakes, chronological validity, incorrect ordering of section headers
- Objective truth in headings, such as editorial biases, opinions, or controversial theories
- Grammar or spelling errors in headings (unless they render the text entirely unintelligible), such as common typos or minor translation mistakes like "Command your food" instead of "Order your food"
- Headings of highly specialized or technical domains consisting of advanced scientific, technical, or academic material, where evaluating the relevance of the terminology requires domain-specific expertise
- Headings of abstract or creative content consisting of literary works, poetry, or avant-garde text where relevance is interpretive or non-linear rather than purely informational
- Headings of legally mandated or standardized statements, documents, or user interfaces where their heading text and structure are rigidly dictated by statutory, regulatory, or legal mandates (e.g., standardized privacy disclosures) that should not be altered by the author
- Compliance with other WCAG success criteria applicable to headings that are evaluated independently

##Comments about recommendations

Item 1, "Create a new definition for 'section'"

Very good idea, but it will take time if I am to do this, as it may become a back-and-forth discussion topic. I am eager to copy-paste whatever you would suggest for this (or directly commit here).

Item 2, "Create a section heading definition"

Not sure if it is needed. It will be very much ambiguous no matter what you describe, especially when the description of the heading is not clear yet.

Item 3, "we'll want an inline definition of 'descriptive'"

Respectfully I disagree. That is going back to square one. The vast majority of the existing headings of the most prominent institutions all around the world will suddenly become non-complaint with WCAG. All that I listed under the "None of the following is within this rule's scope" above will be failed by testers.

Item 4, "intelligible"

I am also not 100% sure about it.
If you think these hypothetical situations I wrote are not encountered in the real world, just tell me to remove it, I will remove all examples that include such cases as well.

Headings containing errors due to copy-pasting, forgotten placeholder text along with the actual heading, or left-over markup code that should not be visible. These headings are considered failing if the text no longer remains meaningful and relevant, introducing a risk for user misunderstanding

Failed Example

This h3 element contains fragmented, truncated text resulting from a catastrophic copy-paste error. It fails this rule because the remaining text fragment fails to convey any meaningful topic, leaving it entirely irrelevant to the underlying content.

<h3>ortcontact Custo</h3>

@JennChadwick JennChadwick Sep 2, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have read the suggestions, feedback and back and forth so far on

Each heading is relevant to the specific page or section where it appears and it is sufficiently intelligible.

@grifare regarding your responses to @WilcoFiers for Items 1 and 2:

  • Item 1, "Create a new definition for 'section'"

I can help write this or agree to cut and paste something that @WilcoFiers has in mind.

  • Item 2, "Create a section heading definition"

I would like to try writing this for your reviews.

  • Item 3, "we'll want an inline definition of 'descriptive'"

I don't agree with @grifare here, in that we have to be too prescriptive. I'd like to try again to write a definition for your review.

"Respectfully I disagree. That is going back to square one. The vast majority of the existing headings of the most prominent institutions all around the world will suddenly become non-complaint with WCAG. All that I listed under the "None of the following is within this rule's scope" above will be failed by testers."

Item 4, "intelligible"

@grifare what do you think about @WilcoFiers suggestion to roll a description of "intelligible" into the general definition of description? Happy to get your thoughts on this in a meeting together. Thanks!


## Background
Headings are normally marked as semantic headings using `<h1>` to `<h6>` elements or using generic elements with correct ARIA roles that convert them into semantic headings. On the other hand, on websites that are not adhering to HTML5 semantic coding practices, or that are intended to apply semantics in the code while containing errors in the usage of ARIA roles for example, other elements can be observed that function as headings. Sometimes a heading is a list item, sometimes a figcaption, sometimes a table caption, sometimes another element that is not normally a heading.

Headings that are visible but not in the accessibility tree are a failure of [Success Criterion 1.3.1 Info and Relationships][sc131]. These are not tested by this rule but they can still fail [Success Criterion 2.4.6 Headings and Labels][sc246].
Under this rule, "content" refers to any textual or non-textual element presented on the web page, including sections, paragraphs, forms, user interface components, media galleries, lists, or hyperlinks.

Testing tools treat empty headings `<h1></h1>` or `div role="heading" aria-level="1"></div>` differently. Some report that empty headings fail under 1.3.1 Info and Relationships or 2.4.6 Labels or Instructions. Other tools report that these headings pass because they are ignored by most assistive technologies and cause no accessibility barriers at all. This rule does not include examples of empty headings because there is currently no harmonized approach for testing them.
To pass, a heading must be relevant to its associated content. (Headings consisting of placeholder text or uninformative character strings fail this rule inherently.)

### Assumptions
This rule assumes that testers evaluating the content possess the necessary language proficiency and contextual comprehension required to assess the relationship between the headings and their associated content. Web pages containing content in multiple languages (e.g., a heading in one language preceding content in another) where the tester does not possess professional working proficiency in all languages present is a limitation.

@WilcoFiers WilcoFiers Aug 7, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Assumptions are about the content, not about the tester. This is more like an input aspect, although I'm not sure that we should make this an actual aspect. That might be worth a discussion in the group.

@grifare grifare Aug 7, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please see the following comment.

Live, dynamic content fields (e.g., streaming data feeds, live social walls, or active chat interfaces) where the content updates at a rate that prevents static evaluation against its structural headings or content that is highly specialized, academic, or artistic are exceptions when the evaluator does not posess the necessary know-how to determine whether the heading is relevant.

@WilcoFiers WilcoFiers Aug 7, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As above, assumptions should be about the content. If a tester is unable test something, that's there problem to figure out. it's not an exception to the accessibility requirement. Testers always have the option of reporting a test as incomplete because they were insufficiently confident.

@grifare grifare Aug 7, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Testers always have the option of reporting a test as incomplete because they were insufficiently confident.

You are the rule writers, we testers are the rule getters.
Perhaps you don't interact with testers daily anymore. As a tester, let me tell you the truth: testers are all too confident at all times and they love to record "errors" force-fitting anything they dislike in one WCAG criterion or another. One reason I volunteered for this job was that a tester started to fail any heading that did not repeat the next paragraph relying on this page I am trying to rewrite.

I believe the official ACT page should include these somehow, somewhere:

  • Subjectivity must be mentioned
  • Limitations should be listed
  • Test-to-pass versus test-to-fail concept, which will reduce false positives

Perhaps "Assumptions" was not the right section or what I wrote was not the right way to point these out.

  • It could be re-worded so that similar points can be made while referring to content rather than the testers?
  • Issues could be called "limitations" within this section?

For now, I made the following changes:

  • Removed language-related clause, as it is almost obvious that one would not evaluate a language they have no clue about.
  • Changed a few words.

@JennChadwick JennChadwick Sep 2, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree @grifare to be more precise for testers not to be too subjective when it comes to content.


This rule assumes that the [flat tree][] order is close to the reading order as elements are rendered on the page. Due to positioning, it is possible to render a document in an order that greatly differs from the tree order, in which case the content which is visually associated with a heading might not be the content following it in tree order and this rule might fail while [Success Criterion 2.4.6 Headings and Labels][sc246] is still satisfied.

This rule also assumes that the content the heading is intended to describe is [visible][] and not hidden from assistive technologies. Otherwise, cases such as expandable content using a heading might fail this rule while [Success Criterion 2.4.6 Headings and Labels][sc246] is still satisfied.
This rule is designed as a test-to-pass evaluation and failures should be reserved for exceptional cases. Testers should default to a passing or not applicable result when in doubt.

@WilcoFiers WilcoFiers Aug 7, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above. This seems like it belongs in a testing methodology (such as Trusted Tester). That's not the purpose of an ACT rule. Different testers can handle this differently, it is not up to us to prescribe these kinds of things.


### Accessibility Support

Implementation of [Presentational Roles Conflict Resolution][] varies from one browser or assistive technology to another. Depending on this, some [semantic][semantic role] `heading` elements can fail this rule with some technology but users of other technologies would not experience any accessibility issue.
This rule does not rely on the support for particular accessibility features by different assistive technologies and user agents.

@WilcoFiers WilcoFiers Aug 7, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you use the default phrase from the template: https://github.com/act-rules/act-rules.github.io/blob/develop/pages/design/atomic-template-empty.md

@grifare grifare Aug 7, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Like this? Done.

Accessibility Support

There are no accessibility support issues known.


### Other Resources

- [Understanding Success Criterion 1.3.1: Info and Relationships](https://www.w3.org/WAI/WCAG22/Understanding/info-and-relationships.html)
- [Understanding Success Criterion 2.4.6: Headings and Labels](https://www.w3.org/WAI/WCAG22/Understanding/headings-and-labels.html)
- [G130: Providing descriptive headings](https://www.w3.org/WAI/WCAG22/Techniques/general/G130)
- [H42: Using h1-h6 to identify headings](https://www.w3.org/WAI/WCAG22/Techniques/html/H42)
- [ARIA12: Using role=heading to identify headings](https://www.w3.org/WAI/WCAG22/Techniques/aria/ARIA12)
- [Understanding Success Criterion 2.4.10 Section Headings](https://www.w3.org/WAI/WCAG21/Understanding/section-headings)
- [Use headings to convey meaning and structure](https://www.w3.org/WAI/tips/writing/#use-headings-to-convey-meaning-and-structure)
- [HTML Specification - Heading content](https://html.spec.whatwg.org/#heading-content)

## Examples

@WilcoFiers WilcoFiers Aug 7, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know why you deleted the examples. We'll need those.

@grifare grifare Aug 7, 2026 •
edited
Loading

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have all the examples locally saved as an md file.
I temporarily removed them from GitHub in order to:

  • Make required format changes to comply with the official format, such as removing the HTML comments I used and including the case in the description
  • Add or remove examples depending on how this section proceeds, what feedback you will provide
  • To repost all examples as one commit, once this intro section is fixed

I am now waiting for your approval of the format I should use for examples. Will the examples' format be okay like this? (No situations list whatsoever.)
#2425 (comment)


### Passed

#### Passed Example 1

This `h1` heading element describes the topic of the following paragraph.

```html
<html lang="en">
<h1>Opening Hours</h1>
<p>We are open Monday through Friday from 10 to 16</p>
</html>
```

#### Passed Example 2

This heading marked up with an [explicit role][] of `heading` describes the topic of the following paragraph.

```html
<html lang="en">
<span role="heading" aria-level="1">Opening Hours</span>
<p>We are open Monday through Friday from 10 to 16</p>
</html>
```

#### Passed Example 3

This `h1` heading element with an image describes the topic of the following paragraph.

```html
<html lang="en">
<h1>
<img src="/test-assets/descriptive-heading-b49b2e/opening_hours_icon.png" alt="Opening hours" />
</h1>
<p>We are open Monday through Friday from 10 to 16</p>
</html>
```

#### Passed Example 4

This `h1` heading element has a single character text that describes the topic of the following description list.

```html
<html lang="en">
<h1>A</h1>
<dl>
<dt>airplane</dt>
<dd>
a powered flying vehicle with fixed wings and a weight greater than that of the air it displaces.
</dd>
<dt>apple</dt>
<dd>
the round fruit of a tree of the rose family, which typically has thin green or red skin and crisp flesh.
</dd>
</dl>
</html>
```

#### Passed Example 5

This heading marked up with an [explicit role][] of `heading` describes the topic of the following paragraph. The heading is positioned off screen but is [included in the accessibility tree][].

```html
<html lang="en">
<span role="heading" aria-level="1" style="position: absolute; top: -9999px; left: -9999px;">Opening Hours</span>
<p>
We are open Monday through Friday from 10 to 16
</p>
</html>
```

#### Passed Example 6

This heading describes the first [perceivable content][] after it (the first `p` element). The next [perceivable content][] (the second `p` element) is not considered by this rule.

```html
<html lang="en">
<h1>Opening Hours</h1>
<p>We are open Monday through Friday from 10 to 16</p>
<p>We are open Saturday from 10 to 13</p>
</html>
```

### Failed

#### Failed Example 1

This `h1` heading element does not describes the topic of the following paragraph.

```html
<html lang="en">
<h1>Weather</h1>
<p>We are open Monday through Friday from 10 to 16</p>
</html>
```

#### Failed Example 2

This heading marked up with an [explicit role][] of `heading` does not describe the topic of the following paragraph.

```html
<html lang="en">
<span role="heading" aria-level="1">Weather</span>
<p>We are open Monday through Friday from 10 to 16</p>
</html>
```

#### Failed Example 3

This heading marked up with an [explicit role][] of `heading` does not describe the topic of the following paragraph. The heading is positioned off screen but is [included in the accessibility tree][].

```html
<html lang="en">
<span role="heading" aria-level="1" style="position: absolute; top: -9999px; left: -9999px;">Weather</span>
<p>
We are open Monday through Friday from 10 to 16
</p>
</html>
```

#### Failed Example 4

This `h1` heading element does not describe the first [perceivable content][] after it (the first `p` element). The next [perceivable content][] (the second `p` element) is not considered by this rule.

```html
<html lang="en">
<h1>Weather</h1>
<p>We are open Monday through Friday from 10 to 16</p>
<p>It is going to rain tomorrow</p>
</html>
```

### Inapplicable

#### Inapplicable Example 1

There is no heading.

```html
<html lang="en">
<p>We are open Monday through Friday from 10 to 16</p>
</html>
```

#### Inapplicable Example 2

This `h1` heading element is not [included in the accessibility tree][].

```html
<html lang="en">
<h1 hidden>Opening Hours</h1>
<p>We are open Monday through Friday from 10 to 16</p>
</html>
```

[decorative]: https://www.w3.org/TR/WCAG22/#dfn-pure-decoration 'WCAG definition of Pure decoration'
[flat tree]: https://drafts.csswg.org/css-scoping/#flat-tree 'Definition of flat tree'
[included in the accessibility tree]: #included-in-the-accessibility-tree 'Definition of included in the accessibility tree'
[presentational roles conflict resolution]: https://www.w3.org/TR/wai-aria-1.2/#conflict_resolution_presentation_none 'Presentational Roles Conflict Resolution'
[sc131]: https://www.w3.org/TR/WCAG22/#info-and-relationships ' Success Criterion 1.3.1 Info and Relationships'
[sc246]: https://www.w3.org/TR/WCAG22/#headings-and-labels 'Success Criterion 2.4.6 Headings and Labels'
[semantic role]: #semantic-role 'Definition of semantic role'
[visible]: #visible 'Definition of visible'
[accessible name]: #accessible-name 'Definition of accessible name'
[perceivable content]: #perceivable-content 'Definition of perceivable content'