From e633525931d92ba8935041e3da255e51053c3ce8 Mon Sep 17 00:00:00 2001 From: Momdo Nakamura Date: Fri, 11 Apr 2025 10:03:55 +0900 Subject: [PATCH 1/2] Some editorial updates to Understanding SC 2.5.3 - Update HTML Standard link and quotation - Update and add Understanding success criterion links - Remove mismatching parenthesis --- understanding/21/label-in-name.html | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/understanding/21/label-in-name.html b/understanding/21/label-in-name.html index b07d31400e..2bec2ec96e 100644 --- a/understanding/21/label-in-name.html +++ b/understanding/21/label-in-name.html @@ -37,13 +37,13 @@

Identifying label text for components

The rationale for some of these conventions is explained in G162: Positioning labels to maximize predictability of relationships.

It is important to bias towards treating only the adjacent text as a label because liberal interpretations of what constitutes a text label can jeopardize the value of this success criterion (SC) by lessening predictability. Isolating the label to the single string in close proximity to the component makes it easier for developers, testers, and end users to identify the label targeted for evaluation in this SC. Predictable interpretation of labeling allows users of speech recognition technologies to interact with the element via its conventionally positioned label, and allows users of screen reading technologies to enjoy consistency between the nearby visible label and the announced name of the component.

-

Note that placeholder text within an input field is not considered an appropriate means of providing a label. The HTML5 specification states The placeholder attribute should not be used as an alternative to a <label>. However, it is worth noting that "label" in that HTML5 statement is in code brackets and links to the label element. For the purposes of this Label in Name Success Criterion, "label" is not used in such a programmatic sense but is simply referring to a text string in close visual proximity to a component. As such, in the absence of any other nearby text string (as described in the preceding list), if an input contains placeholder text, such text may be a candidate for Label in Name. This is supported both through the accessible name calculation (discussed later) and from the practical sense that where a visible label is not otherwise provided, it is likely that a speech-input user may attempt to use the placeholder text value as a means of interacting with the input.

+

Note that placeholder text within an input field is not considered an appropriate means of providing a label. The HTML Standard states The placeholder attribute should not be used as an alternative to a label. However, it is worth noting that "label" in that HTML5 statement is in code brackets and links to the label element. For the purposes of this Label in Name Success Criterion, "label" is not used in such a programmatic sense but is simply referring to a text string in close visual proximity to a component. As such, in the absence of any other nearby text string (as described in the preceding list), if an input contains placeholder text, such text may be a candidate for Label in Name. This is supported both through the accessible name calculation (discussed later) and from the practical sense that where a visible label is not otherwise provided, it is likely that a speech-input user may attempt to use the placeholder text value as a means of interacting with the input.

Text labels "express something in human language"

Symbolic text characters

-

For the purposes of this SC, text should not be considered a visible label if it is used in a symbolic manner, rather than directly expressing something in human language as per the definition of text in WCAG. For example, 1.4.5 Images of Text describes considerations for "symbolic text characters." In the images of text example "B", "I", and "ABC" appear on icons in a text editor, where they are meant to symbolize the functions for Bold, Italics, and Spelling, respectively. In such a case, the accessible name should be the function the button serves (e.g., "Spell check" or "Check spelling"), not the visible symbolic characters. A similar text editor is shown in the figure below.

+

For the purposes of this SC, text should not be considered a visible label if it is used in a symbolic manner, rather than directly expressing something in human language as per the definition of text in WCAG. For example, 1.4.5 Images of Text describes considerations for "symbolic text characters." In the images of text example "B", "I", and "ABC" appear on icons in a text editor, where they are meant to symbolize the functions for Bold, Italics, and Spelling, respectively. In such a case, the accessible name should be the function the button serves (e.g., "Spell check" or "Check spelling"), not the visible symbolic characters. A similar text editor is shown in the figure below.

Icons for transforming text, including heading, bold, italic, quote, code, and link, along with icons for ordered and unordered lists and other controls
A detail of the rich text editor in Github, showing a variety of unlabeled icons, including icons resembling text characters.
@@ -75,7 +75,7 @@

Mathematical expressions and formulae

Accessible Name and Description Computation specification

It is important to understand how the accessible name is derived. The Accessible Name and Description Computation 1.1 and the HTML Accessibility API Mappings 1.0 describe how the accessible name is computed, including which attributes are considered in its calculation, and in what order of preference. If a component has multiple possible attribute values that could be used for its accessible name, only the most preferred of those values will be computed. None of the other, less preferred values will be part of the name. For the most part, existing established programmatic relationships between labels and controls are reinforced by the specification.

-

Other text displayed on the screen that is correctly coded to meet 1.3.1: Info and Relationships is not normally factored into the calculation for the accessible name of a UI component without author intervention (via ARIA labeling techniques). The most common of these are:

+

Other text displayed on the screen that is correctly coded to meet 1.3.1 Info and Relationships is not normally factored into the calculation for the accessible name of a UI component without author intervention (via ARIA labeling techniques). The most common of these are:

  • headings and instructions
  • group labels for sets of components (i.e., used with legend/fieldset or with role of group or radiogroup)
    • @@ -88,7 +88,7 @@

    Text in parentheses

    Note: The term "parenthetical" in this section is describing text that literally appears within a set of round brackets (). It is not used in the more abstract sense of "information related to".

    It is important to mention parenthetical text in labels in the context of accessible name versus description. In common usage, text in parentheses is considered secondary but relevant to meaning. Users of speech recognition would not typically announce text in parentheses as part of the input name. For that reason, parenthetical text may be optionally considered a description and left out of the accessible name.

    -

    However, where parenthetical information provides important context, such as indication of a required field or limitations on what is allowed for input, this information must be provided programmatically in some other way to the user if that information is not included as part of the accessible name. For example, "Name (required)" and "Date (YYYY-MM-DD)" could accept "Name" and "Date" as the accessible names. However, in order to pass 1.3.1 Info & Relationships, authors would need to programmatically surface both the required state and the limit on the allowed data formatting (in this example, eight integers fitting the YYYY-MM-DD pattern). The "required" state could be surfaced through the HTML required attribute or by using aria-required="true". The allowed data formatting could be surfaced by being referenced using the aria-describedby) attribute.

    +

    However, where parenthetical information provides important context, such as indication of a required field or limitations on what is allowed for input, this information must be provided programmatically in some other way to the user if that information is not included as part of the accessible name. For example, "Name (required)" and "Date (YYYY-MM-DD)" could accept "Name" and "Date" as the accessible names. However, in order to pass 1.3.1 Info and Relationships, authors would need to programmatically surface both the required state and the limit on the allowed data formatting (in this example, eight integers fitting the YYYY-MM-DD pattern). The "required" state could be surfaced through the HTML required attribute or by using aria-required="true". The allowed data formatting could be surfaced by being referenced using the aria-describedby attribute.

From 41d3bfec2c7ac429337fe244d3e65b73b0f4f801 Mon Sep 17 00:00:00 2001 From: Momdo Nakamura Date: Sat, 19 Apr 2025 10:19:55 +0900 Subject: [PATCH 2/2] Update understanding/21/label-in-name.html Co-authored-by: Mike Gower --- understanding/21/label-in-name.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/understanding/21/label-in-name.html b/understanding/21/label-in-name.html index 2bec2ec96e..d0f4f30512 100644 --- a/understanding/21/label-in-name.html +++ b/understanding/21/label-in-name.html @@ -37,7 +37,7 @@

Identifying label text for components

The rationale for some of these conventions is explained in G162: Positioning labels to maximize predictability of relationships.

It is important to bias towards treating only the adjacent text as a label because liberal interpretations of what constitutes a text label can jeopardize the value of this success criterion (SC) by lessening predictability. Isolating the label to the single string in close proximity to the component makes it easier for developers, testers, and end users to identify the label targeted for evaluation in this SC. Predictable interpretation of labeling allows users of speech recognition technologies to interact with the element via its conventionally positioned label, and allows users of screen reading technologies to enjoy consistency between the nearby visible label and the announced name of the component.

-

Note that placeholder text within an input field is not considered an appropriate means of providing a label. The HTML Standard states The placeholder attribute should not be used as an alternative to a label. However, it is worth noting that "label" in that HTML5 statement is in code brackets and links to the label element. For the purposes of this Label in Name Success Criterion, "label" is not used in such a programmatic sense but is simply referring to a text string in close visual proximity to a component. As such, in the absence of any other nearby text string (as described in the preceding list), if an input contains placeholder text, such text may be a candidate for Label in Name. This is supported both through the accessible name calculation (discussed later) and from the practical sense that where a visible label is not otherwise provided, it is likely that a speech-input user may attempt to use the placeholder text value as a means of interacting with the input.

+

Note that placeholder text within an input field is not considered an appropriate means of providing a label. The HTML Standard states The placeholder attribute should not be used as an alternative to a label. However, it is worth noting that "label" in that statement is in code brackets and links to the label element. For the purposes of this Label in Name Success Criterion, "label" is not used in such a programmatic sense but is simply referring to a text string in close visual proximity to a component. As such, in the absence of any other nearby text string (as described in the preceding list), if an input contains placeholder text, such text may be a candidate for Label in Name. This is supported both through the accessible name calculation (discussed later) and from the practical sense that where a visible label is not otherwise provided, it is likely that a speech-input user may attempt to use the placeholder text value as a means of interacting with the input.

Text labels "express something in human language"