You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
In highly repetitive contexts, screen reader users lose orientation while using the NVDA element list when the elements have the same title or label. Attached a link to an example by the W3C: https://www.w3.org/WAI/ARIA/apg/patterns/feed/examples/feed/
• Navigate to the example
• Press CapsLock+F7
• In the opening dialog, under the “Element List”, select “Button” as type.
Common Examples:
1) Groups with buttons
These groups display various restaurants. Each group has a bookmark button. When accessing the groups with NVDA, the context determined by the speech output makes it clear to which group each button belongs.
But when opening the Element List, the dialog displays 10 times the title “Bookmark” for all buttons on the page and screen reader users don’t know which button belongs to which group.
2) Groups with more elements
It is getting worse when such groups have more form like elements such as links.
This list of restaurants also provides a link to the menus and a link to google maps. Both are only displayed with their text.
3) Forms requiring name and address for two or more different contexts:
Here the Element List displays the labels of the input fields without their context.
4) Groups with text snippets that can be revealed by “show more” links:
“Show More” links are a very common means to abbreviate news articles. Here both show more links and edit buttons are marked up as buttons. The Element List displays only their labels.
5) Using Checkboxes to implement selectable list items:
Here we use checkboxes to implement selectable items as in the Windows file explorer. Checkboxes and item text is correctly announced through the speech output of NVDA. But this context is no longer present in the Element List.
Describe the solution you'd like
Screen readers should know the context of the mark-up. JAWS, for example, announces the whole context of an item list when repetitive elements are within a container with the role “dialog” from its own Element List but does not display these relations in its element list. NVDA is not doing both.
On this backdrop, NVDA should do the following:
Groups
For repetitive elements within groups, it should display the respective links, buttons or input fields along with the title of the group.
Lists
Where selectable elements are assigned to lists and these elements are announced along with the text of the list item, the selectable elements should appear along with the same text in the Element List of NVDA.
Describe alternatives you've considered
A relation between repetitive elements and their context can be achieved with aria-means such as labelledBy. But this leads to a higher speech output. The more repetitive elements, as in example 2 and 4, the higher the speech load, which poses an unpleasant effect to screen reader users.
Additional context
The text was updated successfully, but these errors were encountered:
I agree the elements list should improve in this regard, I also experience lots of examples where I don't really know what a "show more button" is exactly for when accessing it from the elements list.
cc: @jcsteh not sure whether this is feasible though, maybe you have some suggestoins here.
Is your feature request related to a problem? Please describe.
In highly repetitive contexts, screen reader users lose orientation while using the NVDA element list when the elements have the same title or label. Attached a link to an example by the W3C: https://www.w3.org/WAI/ARIA/apg/patterns/feed/examples/feed/
• Navigate to the example
• Press CapsLock+F7
• In the opening dialog, under the “Element List”, select “Button” as type.
Common Examples:
1) Groups with buttons
These groups display various restaurants. Each group has a bookmark button. When accessing the groups with NVDA, the context determined by the speech output makes it clear to which group each button belongs.
But when opening the Element List, the dialog displays 10 times the title “Bookmark” for all buttons on the page and screen reader users don’t know which button belongs to which group.
2) Groups with more elements
It is getting worse when such groups have more form like elements such as links.
This list of restaurants also provides a link to the menus and a link to google maps. Both are only displayed with their text.
3) Forms requiring name and address for two or more different contexts:
Here the Element List displays the labels of the input fields without their context.
4) Groups with text snippets that can be revealed by “show more” links:
“Show More” links are a very common means to abbreviate news articles. Here both show more links and edit buttons are marked up as buttons. The Element List displays only their labels.
5) Using Checkboxes to implement selectable list items:
Here we use checkboxes to implement selectable items as in the Windows file explorer. Checkboxes and item text is correctly announced through the speech output of NVDA. But this context is no longer present in the Element List.
Describe the solution you'd like
Screen readers should know the context of the mark-up. JAWS, for example, announces the whole context of an item list when repetitive elements are within a container with the role “dialog” from its own Element List but does not display these relations in its element list. NVDA is not doing both.
On this backdrop, NVDA should do the following:
Groups
For repetitive elements within groups, it should display the respective links, buttons or input fields along with the title of the group.
Lists
Where selectable elements are assigned to lists and these elements are announced along with the text of the list item, the selectable elements should appear along with the same text in the Element List of NVDA.
Describe alternatives you've considered
A relation between repetitive elements and their context can be achieved with aria-means such as labelledBy. But this leads to a higher speech output. The more repetitive elements, as in example 2 and 4, the higher the speech load, which poses an unpleasant effect to screen reader users.
Additional context
The text was updated successfully, but these errors were encountered: