Clarification on the requirement for unique accessible names for elements with same role within a page

[anuvenkatesh1]

I would like a clarification on in which instances elements with the same role on a page require unique accessible names. I was reading through this documentation https://www.w3.org/WAI/ARIA/apg/practices/names-and-descriptions/ where it says Create unique names for elements with the same role unless the elements are actually identical

Below are some of the common scenarios where we encounter this conundrum of whether each accessible name should be made unique. 1) We have multiple accordions where the accordion icons are made buttons that expand and collapse the panels. Now do each icon button reference its corresponding panel title in its accessible name? For example in the reference below, the icons are the actual buttons that are going to expand and collapse. Should the accessible names be "expand panel with header text", "expand custom toolbar with a header text", associating the titles in their accessible names to make them unique? While this would make the accessible names unique in the buttons list, it will also result in repetition in VPC mode as the user navigates from the button to panel title.

2) Let's say we have a grid with each row having an edit/delete button. When viewing the JAWS buttons list, the accessible names of these buttons would be repetitive unless we associate some other value from the row in the accessible names so that they are unique. Is this necessary? Though this will make the accessible names unique and non-repetitive in the JAWS buttons list, this may also result in verbose announcements.

3) Another example, where we have a snippets of content followed by "more" button for every paragraph. How can we make the accessible names of these "more" buttons unique?

4) Cards with More actions ellipsis buttons - should each button within each card associate the card title in their accessible names?

A clarification on this topic would be very helpful.

Thank you

[JAWS-test]

Example 1: The button should not be the icon, but the header. Then the name is automatically correct. The purpose of the button (to show or hide an area) is not transmitted in text form, but via aria-expanded. See https://www.w3.org/WAI/ARIA/apg/patterns/accordion/examples/accordion/

[JAWS-test]

Example 3+4: It would be good if the buttons are not named "More" or "More action", but refer to the heading of the card (here e.g. the name of the person).

It is more difficult when there is no heading. Names should not be too descriptive, but also short. It is not a solution to include the entire card content in the name. In this case it could be a solution that the name is only "More" and parts of the card content are transmitted as description.

See https://www.w3.org/WAI/tips/writing/#make-link-text-meaningful

[JAWS-test]

Example 2: Is the most difficult example, because the purpose of the buttons is determined by the context. The context in a table are the row and column headings. So in any case, it is important that the table has meaningful row headings. Now, when I navigate the table with the screen reader, I hear the button label and the row heading, which is sufficient. However, when I use the screen reader's element overview, I only see "Delete" and "Edit". I can also label the buttons directly with the respective row header, but then I get the row header 2x when navigating the table.

[mcking65]

In example 2, it is almost always best to let row and column headings do their jobs. The exception is typically mobile where it is best to avoid tables.

When you are adding words to a label, such as a more button, it is very important to think about which words to put at the beginning of the label. Please refer to this point from the section on Composing Effective and User-friendly Accessible Names:

Put the most distinguishing and important words first. Often, for interactive elements that perform an action, this means a verb is the first word. For instance, if a list of contacts displays “Edit” , “Delete”, and “Actions” buttons for each contact, then “Edit John Doe”, “Delete John Doe”, and “Actions for John Doe” would be better accessible names than “John Doe edit”, “John Doe delete”, and “John Doe actions”. By placing the verb first in the name, screen reader users can more easily and quickly distinguish the buttons from one another as well as from the element that opens the contact card for John Doe.

[mcking65]

Thanks @JAWS-test for the helpful responses!

@anuvenkatesh1 Closing as answered. If your question is not sufficiently answered, please feel free to re-open.

[stes-acc]

I really doubt that example 2 is answered in a way every author can successfully address.

First, this forces all authors around the world for millions of tables to auto-create unique labels for repetitive subcontent such as like buttons, links or graphics.

Second, no normative scheme for labelling is given for doing so. This will lead to ambiguity all over the place.

Third, this naming scheme should be part of WCAG best practices for labelling as a normative regulation and not be topic of a APG thread that is declared as being resolved leaving the rest of the world in the dark.

Fourth, it need to be clarified why the burden for labelling in closed context should be put on the shoulders of web authors or web control developers and not on the user agent or assistive technology (auto-labelling). Assistive technologies are very aware of the context they consume from platform accessibility trees and could provide in their speech output by extended element info triggered by a special key or in their virtual overview dialogs means to identify the very position of e.g. a link in a table cell with row/col position and header information. You just have to define that assistive technology HAS to DO that. This will keep a handful of devs around the globe busy for some weeks but then its done. Otherwise all web authors have to do the job until hell freezes over, which is not a sustainable approach to follow.

[GerganaKremenska]

Hello,

There is another use case that we have to consider. Having a labelled list with listitems and buttons inside: Example