From 6fc9553f79a184d797bfb8b32e12f52d563517cb Mon Sep 17 00:00:00 2001 From: "Patrick H. Lauke" Date: Mon, 11 Mar 2024 16:23:36 +0000 Subject: [PATCH] 2.5.3 - control with label but no accname (understanding note + new failure technique) (#2057) Also cleans-up 2.5.3 understanding document markup/structure - adds new F111 Control with visible label text but no accname (improperly numbered F109 initially) - add failure technique in Understanding document - added notes in Understanding about UI components with visible text and no name failing both 4.1.2 and 2.5.3 - removed direct reference to WCAG 2.1 - resolved discussion with ACT on where to report some of the failure examples Closes #2045 --------- Co-authored-by: Alastair Campbell Co-authored-by: Mike Gower Co-authored-by: Scott O'Hara Co-authored-by: Dan Bjorge --- techniques/failures/F111.html | 83 ++++++++++++++++++ techniques/failures/F96.html | 1 + understanding/21/label-in-name.html | 128 +++++++++++++++------------- 3 files changed, 153 insertions(+), 59 deletions(-) create mode 100644 techniques/failures/F111.html diff --git a/techniques/failures/F111.html b/techniques/failures/F111.html new file mode 100644 index 0000000000..d2a73fc8ba --- /dev/null +++ b/techniques/failures/F111.html @@ -0,0 +1,83 @@ + + + + Failure of Success Criteria 1.3.1, 2.5.3, and 4.1.2 due to a control with visible label text but no accessible name + + + +

Failure of Success Criteria 1.3.1, 2.5.3, and 4.1.2 due to a control with visible label text but no accessible name

+
+

Metadata

+

+

general

+

failure

+
+ +
+

When to Use

+

All technologies that include interactive controls (such as links or form inputs).

+
+ +
+

Description

+

The objective of this Failure is to describe situations where speech input users cannot reliably speak the name of a control because although it has a visible label, it lacks an accessible name.

+

When speech input users interact with a web page, they usually speak a command followed by the reference to some visible label (like the text in a button or a link, or the text labelling some input). If the control lacks an accessible name, speech users won't be able to activate the control using its visible label.

+
+ +
+

Examples

+ +
+

A text input with a visible label, but without an accessible name

+

The text input is preceded by a visible text label "Enter name", but the text is not marked up as a <label> for the input, and there is no alternative way (e.g., aria-label) to provide the input with an accessible name at all.

+ 

+					<p>Enter name</p>
+					<input type="text">
+
+
+ +
+

A text input with a visible label and aria-labelledby pointing to a non-existent id

+

The text input is preceded by a visible text label "Enter name". The text's container has an id of nameEntry, but the input has an aria-labelledby referencing a non-existent name-entry id. As a result, the input lacks an accessible name altogether.

+ 

+					<p id="nameEntry">Enter name</p>
+					<input type="text" aria-labelledby="name-entry" >
+
+
+
+ +
+

Tests

+
+

Procedure

+

For all controls with a visible label (e.g., link text, button text, programmatically linked label, images in links or buttons with text, etc.), check that:

+
    +
  1. The control has a visible text label.
    2. +
  2. The control has an accessible name.
    3. +
  3. The accessible name contains the text that appears as the visible label.
    4. +
+
+
+

Expected Results

+
    +
  • If check #1 is false, the Success Criterion does not apply.
    • +
  • If check #1 is true, but checks #2 and/or #3 are false, the content fails the Success Criterion.
    • +
  • If all checks are true, the content passes the Success Criterion.
    • +
+
+
+ + + diff --git a/techniques/failures/F96.html b/techniques/failures/F96.html index 8bee496760..b853408bd9 100644 --- a/techniques/failures/F96.html +++ b/techniques/failures/F96.html @@ -71,6 +71,7 @@

Expected Results

- - -
-

Benefits

+

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:

+

Such textual information may constitute part of the component's description. So from both a programmatic viewpoint, and from the conservative tactic of only considering a label to be "adjacent text," neither headings, instructions, nor group 'labels' should normally be considered labels for the purpose of this Success Criterion.

+

It is important to note that the specification allows authors to override the name calculated through native semantics. Both aria-label and aria-labelledby take precedence in the name calculation, overriding the visible text as the accessible name even when the visible text label is programmatically associated with the control. For this reason, when a visible label already exists, aria-label should be avoided or used carefully, and aria-labelledby should be used as a supplement with care.

+

Finally, aria-describedby is not included in the Accessible Name computation (instead it is part of the Accessible Description computation). By convention, text associated with a control through aria-describedby is announced immediately after the accessible name by screen readers. Therefore, the context of headings, instructions, and group labels can be provided through the accessible description to assist users of screen readers without affecting the experience of those who navigate using speech recognition software.

+ + +
+

Benefits

+ +

Examples

@@ -108,25 +120,23 @@

Techniques

Sufficient Techniques

Advisory Techniques

-

Although not required for conformance, the following additional techniques should - be considered in order to make content more accessible. Not all techniques can be - used or would be effective in all situations. -

+

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

Failure Techniques