Accessible HTML Heading Markup

Do headings introduced to meet SC 2.4.10 (AAA) need to be marked up With an h<n> tag too?

On this page, HTML heading markup h<n> tags are used for the titles of each scenario I / Ii / III and for each of the two ARIA1 and ARIA2 techniques. This is good enough to comply with SC 1.3.1 (A) for the three scenarios illustrated below. In Scenario I, these are the only headings.

In Scenario II and III, every subsection of the technique ARIA1 and ARIA2 additionally has a title (in text): “Applicability”, “User Agent and Assistive Technology Support Notes” and “Description”. These are numbered A / B / C respectively.

Note that the presentation style (text font, size) of every subsection title is not distinctive and yet they serve as headings. These titles aid comprehension for all and benefit screen reader users as well. So merely introducing these headings helps the content conform with SC 2.4.10 (AAA).

2.4.10 Section Headings: Section headings are used to organize the content. (Level AAA)

SC 2.4.10 (AAA) clarifies that, “heading” is used in its general sense and includes titles and other ways to add a heading to different types of content. WCAG2 does not define the term “heading” or “section heading”.

Do these titles expose structure and information relationships as required by SC 1.3.1 (A) as well?

1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)

The subsection titles are not styled distinctively and so do not fail F2: using changes in text presentation to convey information without using the appropriate markup or text. So they do satisfy SC 1.3.1 (A).

In Scenario III, every subsection titles “Applicability”, “User Agent and Assistive Technology Support Notes” and “Description” is a list item and hence exposes info relationships and structure programmatically. In Scenario II too, they are within the P-tag of the related content and hence do satisfy SC 1.3.1.

Of course, it is the content author’s prerogative to determine if the subsection titles should be styled distinctively or not. If they are distinctive, they should not fail F2.

ARIA role=”heading” to the rescue:

The subsection titles appear the same visually for both ARIA1 and ARIA2, yet they are different for screen reader users. Just for demonstration, the titles under ARIA2 are marked up with ARIA role=”heading”. Even without an aria-level these headings help screen reader users to discover content and navigate efficiently. JAWS ascribes a heading level to these too (incorrectly it appears in this case), while NVDA and VoiceOver (in iOS) merely expose them as headings. (Freedom Scientific has been alerted of this).

Scenario I: Content for each technique presented without visible headings

ARIA1: Using the aria-describedby property to provide a descriptive label for user interface controls

This technique applies to:

• SC 1.3.1: Info and relationships
• SC 3.3.2: Labels or instructions

See User Agent Support Notes for ARIA1.

The purpose of this technique is to demonstrate how to use the WAI-ARIA aria-describedby property to provide programmatically determined, descriptive information about a user interface element. The aria-describedby property may be used to…

ARIA2: Identifying a required field with the aria-required property

This technique applies to:

• SC 1.3.1: Info and relationships

See User Agent Support Notes for ARIA2.

The objective of this technique is to indicate in a programmatically determined way that the completion of a user input field is mandatory for successful submission of a form when there is a visual cue to this effect. The fact that the element is required is often visually presented (via a text or non-text symbol, or text indicating input is required or color / styling) …

Scenario II: Content for each technique within aP-element and visible headings to pass SC 2.4.4

ARIA1: Using the aria-describedby property to provide a descriptive label for user interface controls

A. Applicability:
This technique applies to:

• SC 1.3.1: Info and relationships
• SC 3.3.2: Labels or instructions

B. User Agent and Assistive Technology Support Notes:
See User Agent Support Notes for ARIA1.

C. Description:
The purpose of this technique is to demonstrate how to use the WAI-ARIA aria-describedby property to provide programmatically determined, descriptive information about a user interface element. The aria-describedby property may be used to…

ARIA2: Identifying a required field with the aria-required property

A. Applicability:
This technique applies to:

• SC 1.3.1: Info and relationships

B. User Agent and Assistive Technology Support Notes:
See User Agent Support Notes for ARIA2.

C. Description:
The objective of this technique is to indicate in a programmatically determined way that the completion of a user input field is mandatory for successful submission of a form when there is a visual cue to this effect. The fact that the element is required is often visually presented (via a text or non-text symbol, or text indicating input is required or color / styling) …

Scenario III: Content for each technique within a list and visible headings to pass SC 2.4.10

ARIA1: Using the aria-describedby property to provide a descriptive label for user interface controls

1. Applicability
   This technique applies to:
   • SC 1.3.1: Info and relationships
   • SC 3.3.2: Labels or instructions
2. User Agent and Assistive Technology Support Notes
   See User Agent Support Notes for ARIA1.
3. Description
   The purpose of this technique is to demonstrate how to use the WAI-ARIA aria-describedby property to provide programmatically determined, descriptive information about a user interface element. The aria-describedby property may be used to…

ARIA2: Identifying a required field with the aria-required property

1. Applicability
   This technique applies to:
   • SC 1.3.1: Info and relationships
2. User Agent and Assistive Technology Support Notes
   See User Agent Support Notes for ARIA2.
3. Description
   
   The objective of this technique is to indicate in a programmatically determined way that the completion of a user input field is mandatory for successful submission of a form when there is a visual cue to this effect. The fact that the element is required is often visually presented (via a text or non-text symbol, or text indicating input is required or color / styling) …