Success Criterion 2.5.3: Label in Name (Level A)

[devchan4188]

From Success Criterion 2.5.3:

For user interface components with labels that include text or images of text, the name contains the text that is presented visually.

NOTE
A best practice is to have the text of the label at the start of the name.

Additional Guidance When Applying Success Criterion 2.5.3 to Non-Web Documents and Software:

This applies directly as written, and as described in Intent from Understanding Success Criterion 2.5.3 (also provided below).

Note: for Non-Web Documents and Software the Accessible Name and Description Computation specification depends on the attributes provided by the specific platform APIs.

[maryjom]

@devchan4188 I think this might also need the standard pointer text to the closed product section:

Note: See also the discussion on Closed Functionality.

and in the section Success Criteria Problematic for Closed Functionality a bullet needs to be added:

• 2.5.3 Label in Name —requires information in a programmatically determinable form; specifically, the programmatic name contains the text of the visual label;

[mitchellevan]

For the record, iOS has not just an accessible name, but also the possibility of a list of voice control labels. That said, I would not include this detail in our current scope for WCAG2ICT. It would make more sense somewhere in Understanding and Techniques, not in our current work plan. It doesn't change 2.5.3 anyway, just enhances it.

@cookiecrook am I saying this right?

[mitchellevan]

Note: for Non-Web Documents and Software the Accessible Name and Description Computation specification depends on the attributes provided by the specific platform APIs.

Nits:

• use more lowercase
• omit "description" and "specification"

I would not add this note to the criterion, but rather merge it into the following draft note for the glossary definition of "name":

NOTE “AccessibleName” (or whatever it is called in different APIs) of the Accessibility API of the platform is an example of such a name.

Proposed updated note for the "name" definition (with examples borrowed from core-aam):

Note: for non-web documents and software, the accessible name computation depends on object properties in accessibility APIs provided by the platform. "Name" and "AXTitle" are examples of such object properties.

[loicmn]

I agree with @mitchellevan proposal:

1. Don't have a note in 2.5.3, but have it in the definition of "name"
2. Replacing the current note in "name" by his proposal

[maryjom]

Incorporating all of the changes suggested so far into a full draft (to help others who haven't reviewed/commented yet):
From Success Criterion 2.5.3:

For user interface components with labels that include text or images of text, the name contains the text that is presented visually.

NOTE
A best practice is to have the text of the label at the start of the name.

Additional Guidance When Applying Success Criterion 2.5.3 to Non-Web Documents and Software:

This applies directly as written, and as described in Intent from Understanding Success Criterion 2.5.3 (also provided below).

Note: See also the discussion on Closed Functionality.

---

In the section Success Criteria Problematic for Closed Functionality a bullet needs to be added:

• 2.5.3 Label in Name —requires information in a programmatically determinable form; specifically, the programmatic name contains the text of the visual label;

---

In the "Comments on Definitions in WCAG 2.2 Glossary" section, the WCAG2ICT guidance sub-section for the term "name" would read:

Guidance When Applying “name” to Non-Web Documents and Software

This applies directly as written and as described in the WCAG 2.2 glossary, replacing “Web content” with “content” and adding “or by accessibility features of software” after “assistive technology” in Note 1.

With this substitution, it would read:

name

text by which software can identify a component within [content] to the user

NOTE
The name may be hidden and only exposed by assistive technology [or by accessibility features of software], whereas a label is presented to all users. In many (but not all) cases, the label and the name are the same.

NOTE
This is unrelated to the name attribute in HTML.

NOTE
For non-web documents and software, the accessible name computation depends on object properties in accessibility APIs provided by the platform. "Name" and "AXTitle" are examples of such object properties.

[maryjom]

One thing to note: IF we change this note on "name", a similar statement to "“AccessibleName” (or whatever it is called in different APIs) of the Accessibility API of the platform is an example of such a name." already exists in the WCAG2ICT interpretations for "role" and "structure". That statement is:

“AccessibleRole” (or however it is called in different APIs) of the Accessibility API of the platform is an example of such a role.

So if we change this note, we should use consistent language elsewhere.

Perhaps the "role" note could read:

The user agent or platform software computes the role from object properties set by the non-web document or software and exposes the role to assistive technology via the platform accessibility API.

and the "name" note could read:

The user agent or platform software computes the accessible name from object properties set by the non-web document or software and exposes the name to assistive technology via the platform accessibility API.

[cookiecrook]

For the record, iOS has not just an accessible name, but also the possibility of a list of voice control labels. […] @cookiecrook am I saying this right?

Yes, the proposed Web API for that is ARIA Issue #1038 and PR #174

[mitchellevan]

For the record, iOS has not just an accessible name, but also the possibility of a list of voice control labels. […] @cookiecrook am I saying this right?

Yes, the proposed Web API for that is ARIA Issue #1038 and PR #174

Excellent. Correcting the issue link: w3c/aria#1038

[maryjom]

Approved by the AG WG on 11 April.