Note that our screen reader support is limited to Edge + Narrator. Issues that do not reproduce in Edge + Narrator, and aren't caused by obvious invalid aria values, should be filed with the respective screen reading software, not the Fabric repo.
List items don't announce where they are in the set. E.g. "2 of 10".
Narrator doesn't announce the list items position in the set.
If you look at it's aria attributes, these details are not set.
The list item that has focus should announce its position in the set. E.g. "2 of 10".
Something I noticed, if you use narrator commands (e.g. CAPS + RIGHT) to navigate the UI you'll ultimately get to a point that announces the correct information. If you only use keyboard commands (e.g. UP or DOWN), though, that information is no longer announced.
My understanding is that screen reader users generally use keyboard commands more frequently than Narrator commands.
@bcoard Thanks for the report. Will dig into this issue this week.
Looking at the example for List, I do believe we are setting the proper list and listitem roles. (See screenshots below).
I can confirm that I am seeing inconsistent behavior (I suspect it is due to our focus zone), but when I put narrator into scan mode I find that the arrow keys narrate the position in set correctly.
Are you finding this behavior with scan mode off or on?


Thanks JD. We're expecting the user to mainly use keyboard commands (e.g. TAB, arrow keys, ENTER, etc.) to move around the UI, not Narrator commands (e.g. CAPS + RIGHT, CAPS + ENTER, etc). This has been our baseline for screen reader passes, even in win32.
When we do try using Narrator commands though, we default to scan mode off. This goes for win32 as well.
Makes sense.
In web, list items are not focusable elements (by default). That's why they don't trigger under typical navigation. Scan mode is required to actually focus on the list element.
I'm not sure I follow. Do we not expect users to be able to arrow through the list items? Even with Narrator off I'd expect the user to be able to arrow through the list items. If they can arrow through the items, they should also hear the right information when they get to those items.
@jdhuntington any update here? Let me know if you'd prefer to sync offline about my concerns.
@bcoard Sorry about the delayed followup; lost track of this issue. After looking at it further, I think you're right and there is something amiss here. I believe there's something that should be fixed; I will look and see how expensive it will be.
I think we should reconcile what behavior is expected from components with ARIA list role.
It appears there's quite a bit of variation in how browser and screen readers behave with ARIA list implementations. Quickly glancing at this link seems to indicate this could be an issue with MS Edge.
For non-virtualized scenarios, we shouldn't have to duplicate information already present in the DOM in ARIA attributes. The browser already has the information it needs to properly narrate. No ARIA is better than bad ARIA.
Ultimately I wonder if List is actually the correct component to use in this example. It seems to imply a scenario that would allow user navigation and selection, but doesn't. I wonder if this is more of an ARIA grid role scenario with the added focus, keyboard navigation, and accessibility behavior such a component would bring.
Closing this out and opening new, separate, bugs to track this issue.
Details List: Narrator doesn't announce level of list item Needs: Triage 馃攳
@khmakoto
Details List: List items don't announce position in set Needs: Triage 馃攳
@khmakoto
Details List: Group header doesn't announce number of children Needs: Triage 馃攳
@khmakoto
Details List: Group headers do not announce position in set Needs: Triage 馃攳
@khmakoto
Details List: Group header doesn't announce Expand/Collapse state Needs: Triage 馃攳
@khmakoto