2.4.6 Headings and Labels - note regarding 1.3.1

[jidaikobo-shibata]

2.4.6's criterion's note says:

Headings and labels must be programmatically determined, per Success Criterion 1.3.1 .
https://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-descriptive.html#navigation-mechanisms-descriptive-techniques-head

But 1.3.1 allows text solution not just programmatically determination.

so, 2.4.6's note might be a misguiding of 1.3.1.

please consider about this. thanks.

[cstrobbe]

The note "Headings and labels must be programmatically determined, per Success Criterion 1.3.1 ." is not really "misguiding".

When applied to headings and labels, the phrase "or are available in text" in SC 1.3.1 strictly speaking only applies to formats that don't support programmatically determinable headings or labels. See the part of Understanding SC 1.3.1 that begins as follows:

Some technologies do not provide a means to programmatically determine some types of information and relationships.

In most formats that I have used, headings can be marked up in a way that allows them to be programmatically determinable. The only exception I am aware of is plain text (real plain text, not something like MarkDown, which is meant to be rendered as HTML or another format).

Labels are a bit trickier. In HTML, labels can be coded in a way that makes them programmatically determinable. However, neither Word nor PDF allow programmatic relationships between the visible label and a form field. Instead, the author is required to add an invisible label (typically repeating the same text as in the visible label) in a way that is similar to alt text for images. But at least those invisible "labels" are programmatically determinable.

[GreggVan]

+1 Even plain text headers can be detected if plain text standards are followed. (e.g. two blank lines before a header. One line of text. No period. Or if Headers are on separate line - ALL CAP - two blank lines before But there are still problems when pages have more complex formats as noted below. We should - in Understanding WCAG docs - make it clear each time there is a (widespread) misunderstanding of something — to keep evaluators and evaluations from going all over the place. We can update the Understanding WCAG docs at any time and should do so more often. Gregg Vanderheiden ***@***.***

…

On Jul 22, 2022, at 6:40 PM, cstrobbe ***@***.***> wrote: The note "Headings and labels must be programmatically determined, per Success Criterion 1.3.1 <https://www.w3.org/WAI/WCAG21/Understanding/info-and-relationships>." is not really "misguiding". When applied to headings and labels, the phrase "or are available in text" in SC 1.3.1 strictly speaking only applies to formats that don't support programmatically determinable headings or labels. See the part of Understanding SC 1.3.1 <https://www.w3.org/WAI/WCAG21/Understanding/info-and-relationships.html> that begins as follows: Some technologies do not provide a means to programmatically determine some types of information and relationships. In most formats that I have used, headings can be marked up in a way that allows them to be programmatically determinable. The only exception I am aware of is plain text (real plain text, not something like MarkDown, which is meant to be rendered as HTML or another format). Labels are a bit trickier. In HTML, labels can be coded in a way that makes them programmatically determinable. However, neither Word nor PDF allow programmatic relationships between the visible label and a form field. Instead, the author is required to add an invisible label (typically repeating the same text as in the visible label) in a way that is similar to alt text for images. But at least those invisible "labels" are programmatically determinable. — Reply to this email directly, view it on GitHub <#315 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXQK33ACAW6HD4KNJUDVVNEQHANCNFSM4EP57WKQ>. You are receiving this because you are subscribed to this thread.

[patrickhlauke]

Even plain text headers can be detected if plain text standards are followed. (e.g. two blank lines before a header. One line of text. No period.

there's a lot of things that can be detected programmatically, but browsers/AT aren't doing it.

for instance, there was a whole discussion about 2.4.4 Link Purpose (In Context) and whether or not a preceding heading counts as context. it would be trivial for browsers/AT to programmatically find the previous heading that a link falls under (just walk the DOM tree backwards to find the closest preceding heading), but no browser/AT does it/exposes this. so it's the difference between "theoretically can be programmatically determined" versus "has actual support in the real world". #1097 #819 #1821