SC2-4-6-descriptive-labels

[DagfinnRomen]

---

name: Label is descriptive
test_type: atomic

description: |
This rule checks that labels describe the purpose of the interface components.

success_criterion:

• 2.4.6 # Headings and labels

test_aspects:

• DOM Tree
• Accessibility Tree

authors:

• Dagfinn Rømen
• Geir Sindre Fossøy

---

Test Procedure

Applicability

This rule applies to

• <label> elements and
• elements that are connected to a second element with the use of the aria labelledby attributt
• that are visible and included in the accessibility tree.

Note: This rule is only applies to (...markup equivalent to semantic role of label...). Thus, it is a partial check for WCAG 2.0 success criterion 2.4.6, which applies to all labels. "Label" is used in its general sense and includes text or other components with a text alternative that is presented to a user to identify a component within Web content.

Note: A label is presented to all users whereas the name may be hidden and only exposed by assistive technology. In many (but not all) cases the name and the label are the same.

Expectation

Each target element describes the purpose of the element its a caption for.

Note: Labels do not need to be lengthy. A word, or even a single character, may suffice.

Assumptions

There are currently no assumptions.

Accessibility support

There are no major accessibility support issues known for this rule.

Background

• Understanding Success Criterion 2.4.6: Headings and Labels
• G131: Providing descriptive labels

Test Cases

Passed

Passed example 1

Label that is coded with the <label> element and describes the purpose of the associated element.

<label for ="fname">First name:</label>
<input id="fname" type="text" name="fname"/>

Failed

Failed example 1

Description...

<!-- code -->

Inapplicable

Inapplicable example 1

Description...

<!-- code -->

[WilcoFiers]

I have a few concerns with the applicability:

All labels that identify specific components on the web page.

1. How do you define "label"? The WCAG 2.0 definition is not objective, so that's something you're going to have to redefine.
2. What is a "specific component"? Can you define that somehow?

[DagfinnRomen]

We have based our interpretation on the WCAG 2.0 definition. Is "label" a term that is used in other test rules? Maybe we could reuse an existing definition.

[EmmaJP]

Can you identify any example of a label element that this would not apply to?
Can you identify other elements that this does apply to?

How much would be covered by tests for 2.4.4 or 3.3.2?

[cpandhi]

Can we use the applicability section to clearly specify which label elements this rule would apply to?

[ShadowBB]

Suggestion for the applicability:

All DOM elements that have an accessible name (computated with the "Accessible name computation" method outlined on the following page: https://www.w3.org/TR/2014/REC-wai-aria-implementation-20140320/#mapping_additional_nd_te)

Question: Can we reference such methods or should they be copied into the rule? And if we copy it, should we use the current draft instead? (https://www.w3.org/TR/accname-1.1/#mapping_additional_nd_te)

[DagfinnRomen]

Updated with new test rule format and rewritten applicability section.

This test rule should be consistent with https://github.com/auto-wcag/auto-wcag/blob/master/_rules/SC2-5-3-label-content-name-mismatch.md

[geirsf]

From WCAG 2.0
label

text, image, or sound that is presented to a user to identify a component within Web content

[annethyme]

I would suggest aligning with this rule: https://auto-wcag.github.io/auto-wcag/rules/SC3-3-2-form-field-has-name.html

I have tried giving it a shot. Don't know if something like this could work (if it was cleaned up):

Applicability

This rule applies to

• non-empty accessible names for form field roles in the list further down, if the element is included in the accessibility tree, or focusable, and
• visible HTML label elements connected to HTML elements that have one of the form field roles in the list further down.

The form field semantic roles to be considered for this rule are: checkbox, combobox (select elements), listbox, menuitemcheckbox, menuitemradio, radio, searchbox, slider, spinbutton, switch and textbox.

Note: The list of roles is derived by taking all the ARIA 1.1 roles that:

• have a semantic roles that inherits from the abstract input or select role, and
• does not have a required context role that itself inherits from one of those roles.
• The option role is not part of the list of applicable roles, because it does not meet the definition of a User interface component. This means WCAG 2.1 does not require it to have an accessible name.

Expectations

Each target element describes the element it is an accessible name or HTML label for.

[annethyme]

If we want to move on with the above, I would definitely suggest we create a definition for the form field roles and just link to that instead of listing it in the rule.
Then we can also link to it from https://auto-wcag.github.io/auto-wcag/rules/SC3-3-2-form-field-has-name.html, making that one less bulky.