Skip to content

Clarification requested for 3.2.4 Consistent Identification #4216

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
jamieherrera opened this issue Feb 6, 2025 · 10 comments
Open

Clarification requested for 3.2.4 Consistent Identification #4216

jamieherrera opened this issue Feb 6, 2025 · 10 comments

Comments

@jamieherrera
Copy link

Please confirm, Is 3.2.4 intended to be specifically about consistent identification for screen reader users and the non-visual experience, or also include the visual experience of functional components?

Much of the language of the Understanding Document linked below, including Examples and Sufficient Techniques, center around the accessible name and text alternatives. The In Brief section, however, and the Predictive Guideline this SC, more broadly provide examples of where this guideline and what "consistent" means in a broader sense, could apply to people with cognitive, low vision, and motor disabilities.

I do see that the first paragraph of the Intent section includes cognitive and screen reader considerations, but would suggest to include more language in the Understanding document to support this messaging.

3.2.4 Consistent Identification:

Components that have the same functionality within a set of Web pages are identified consistently.

@A11yTea
Copy link

A11yTea commented Feb 7, 2025

I think their use of the word "label" implies the visual label because in this phrase: "If identical functions have different labels (or, more generally, a different accessible name) on different Web pages, the site will be considerably more difficult to use." They go broader "more generally a different accessible name".

And their example: "Example 7: Example of a Failure
A submit "search" button on one Web page and a "find" button on another Web page both have a field to enter a term and list topics in the Web site related to the term submitted. In this case, the buttons have the same functionality but are not labeled consistently." is about the visual label.

I think the word to focus on for this criteria is the word "identified". So start with how a component is "identified" and then check if its consistent.

@JAWS-test
Copy link

I have always understood the SC to mean both the visual labeling and the programmatic labeling (accessible name).

Incidentally, I think the phrase “more generally” is wrong in the sentence:

If identical functions have different labels (or, more generally, a different accessible name) on different Web pages

@jamieherrera
Copy link
Author

both the visual labeling and the programmatic labeling (accessible name).

The term "accessible name" is not equivalent to "programmatic labeling"; it includes the programmatic label. See Accessible name definition.

To go back to my original question,
"Is 3.2.4 intended to ... include the visual experience of functional components?"

What I'm asking goes beyond labels. I am asking if 3.2.4 should also apply to using visual cues consistently (which are also identifiers). example: using a chevron consistently on a tile component that has the same function. This type of consistent identification is separate from its "name".
The SC normative text does not limit the consistency to labels, but the Understanding document seems to lean heavily on labels.

@detlevhfischer
Copy link
Contributor

Hi @jamieherrera
I can’t see the term “programmatic labelling” in the definition of Accessible name you point to above. I have treated the terms as synonymous so far. Can you explain?

@jamieherrera
Copy link
Author

@detlevhfischer I was quoting @JAWS-test not WCAG.

I would like to get some sort of clarification through actionable change: if 3.2.4 should be limited to the way a component is labeled that needs to be stated. If it extends to non-text visual identification as well, that should be clearer. The normative text does not explicitly mention the label, just that the component is identified consistently.

@jamieherrera
Copy link
Author

jamieherrera commented Apr 4, 2025

so... is Consistent Identification intended or not intended to include consistency in a visual design other than text?
In the example I am thinking of, using a chevron on an interactive component with other shared visual characteristics like outlining, background color, etc; is used to indicate it is interactive; if there are other components in a site or app where everything is the same except the chevron, is that inconsistent?

@jamieherrera
Copy link
Author

jamieherrera commented Apr 29, 2025

Just checking in... maybe @detlevhfischer or @JAWS-test or @A11yTea can move this forward in any upcoming conversations with the larger group? A carat or symbol in this case is part of a particular kind of visual component/ action card/ tile indicating it is interactive, so the question is whether Consistent Identification means that this particular component, which. is used across a website or app, should consistently have the same visual symbol of the carat (or consistently not have it in all instances of the component) to be considered passing 3.2.4?

@detlevhfischer
Copy link
Contributor

detlevhfischer commented Apr 29, 2025

@jamieherrera I think it is pretty clear that this SC is not specifically about consistent identification for screen reader users and the non-visual experience. Besides text links and button text, the understanding talks about the consistency of icons as much as abut that of alternative texts. It also has examples where the same icon may have different alt to reflect different functions - ok if that maps correctly onto the respective function.

So I think the argument could be made that the consistent use of a visual identifier of function like the chevron you mention would fall under this SC. Since there is no defined failure for inconsistent use of visual indicators, and the indicator may by some be considered redundant (since alignment of tiles or other cues may visually signify that entries are buttons) I believe this is not a clear-cut case of a failure. As so often, it will depend on the context of use. If you have a view with some tiles that have a chevron and others that don't and that use does not line up with whether or not these are interactive, a case could be made that this is inconsistent. If use differs between views but is consistent within one view, the case would be weaker.

I don't think solving this with a proposed working group answer will bring more clarity than "it depends"..

@A11yTea
Copy link

A11yTea commented May 1, 2025

Please confirm, Is 3.2.4 intended to be specifically about consistent identification for screen reader users and the non-visual experience, or also include the visual experience of functional components?

Sorry, I think I missed the point of your question. Yes, I believe that the "visual experience of functional components" is included. In the "Benefits" section it states:

When non-text content is used in a consistent way to identify components with the same functionality, people with difficulty reading text or detecting text alternatives can interact with the web without depending on text alternatives.
So this phrase is explicitly about non-text content and not dependent on the text alternative.

However, the difficult thing here is to define what does identification mean for non-text content. Is the chevron an identification? So let's say we have a dropdown menu that uses a chevron to indicate it is expandable on one page and then it uses a plus icon on another page. Is this a failure? Let's see what the others think.

@TestPartners
Copy link

The WCAG definition of a label is "text or other component with a text alternative that is presented to a user to identify a component". A supplementary note says "A label is presented to all users". In my view, icons such as chevrons are therefore an identification and must be consistent.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants
@detlevhfischer @TestPartners @jamieherrera @JAWS-test @A11yTea and others