Fabric_NavTree : Screen reader is not narrating the position of menu items

v-vasud commented 5 years ago

Environment Information

OS: Windows 10 Version: 1809(OS Build 18298.1000) Browser: Microsoft Edge (44.18298.1000.0) Screen Reader: Narrator

Reproduction of the bug:

User Experience:

Users who rely on screen reader are getting affected as narrator is not announcing position of menu items.

Reproduction Steps:

1) Turn on Narrator 2) Open https://uifabric-prod.azurewebsites.net/?example=jhkjhkj#/components/nav#Implementation URL in Edge browser 3) "Nav Implementation" page will be displayed 4) Navigate to menu items and observe whether screen reader is narrating the position of menu item.

Actual behavior:

Narrator is not announcing the position of menu items.

Expected behavior:

Narrator should read the position of menu items as “Home menu in list 7 items, 1 of 7”.

Priorities and help requested:

Requested priority: (Normal)

Products/sites affected: M365 Security and compliance

Impacted bugs due to this fabric issue Bug 1 : Narrator is not announcing the position of menu items.

JasonGore commented 5 years ago

@v-vasud Please note that this repo is public facing and that you have posted Microsoft internal links and screenshots. Consider editing or removing this issue. Thanks.

KevinTCoughlin commented 5 years ago

@v-vasud I inspected the DOM highlighted above. Similar to https://github.com/OfficeDev/office-ui-fabric-react/issues/8310 those controls are not OUFR and therefore out of scope of this repository. They are Angular-based custom controls from what I can tell.

KevinTCoughlin commented 5 years ago

@v-vasud. none of the following official W3 ARIA navigation examples announce menu item position when used as navigational elements. Findings below:

Example 1: Expandable Nav Menus

W3 ARIA Example: https://www.w3.org/TR/wai-aria-practices/examples/menu-button/menu-button-links.html

In the above W3 ARIA example, a navigation menu is shown upon interaction of a button. This deviates from the example mentioned in the issue repro, however it demonstrates a navigation pattern advocated by W3 ARIA.

Note that in this case, only the following is announced which we would match and consider ARIA compliant.

Narrator Output

WAI-ARIA Quick Links, button expanded,
W3C Home Page, menu item,
Tooltip, https://www.w3.org/.
W3C Web Accessibility Initiative, menu item,
Accessible Rich Internet Application Specification, menu item,
WAI-ARIA Authoring Practices, menu item,
WAI-ARIA Implementation Guide, menu item,
Accessible Name and Description, menu item,

Note that position is not specified nor mentioned at all in this example.

Example 2: Static Navigation with Expandable Sub-menus

W3 ARIA Example: https://www.w3.org/TR/wai-aria-practices/examples/menubar/menubar-1/menubar-1.html#

In this example, we have a static nav element that opens sub-navigation elements. Note that at no point is the menu item position announced in this W3 ARIA official example.

Narrator Output

Mythical University, About, collapsed, menu item,
Admissions, collapsed, menu item,
Academics, collapsed, menu item,
Space
Colleges &amp; Schools, menu item,
Tooltip, https://www.w3.org/TR/wai-aria-practices/examples/menubar/menubar-1/mb-academics.html#colleges.
Programs of Study, menu item,
Honors Programs, menu item,
Online Courses, menu item,
Course Explorer, menu item,
Academics, collapsed, menu item,

Note that position in set is not mentioned here either.

Conclusion

I cannot find anywhere in the W3 ARIA spec nor W3 ARIA examples that position is required for navigation elements and sub-elements.

Unless we can find an official navigation example or W3 ARIA spec line that specifies position as required for navigation elements, I do not think we should add support for this in the default case.

Follow-up

@v-vasud can you provide part of the W3 ARIA spec that notes position within a navigation element as required? You can access the document at https://www.w3.org/TR/wai-aria-1.1/.

KevinTCoughlin commented 5 years ago

Also note that W3 ARIA's spec for role=navigation does not list any positional element as required or inherited, see https://www.w3.org/TR/wai-aria-1.1/#navigation.

Neither does role=menu, see https://www.w3.org/TR/wai-aria-1.1/#menu.

I see that role=menu can own type of role=menuitem. Subsequently role=menuitem has the optional properties aria-posinset and aria-setsize, see https://www.w3.org/TR/wai-aria-1.1/#menuitem.

However, our navigation elements do not specify either of the above roles so the position in set does not apply.

@v-vasud are you proposing that all Fabric navigation elements be composed of menu roles? I'm not sure that is correct nor necessary. Do you have validation errors or W3 ARIA spec references to backup that change?

KevinTCoughlin commented 5 years ago

Our navigation uses role=navigation" and the nav element not menus. Note how the W3 ARIA examples for role="navigation" do not specify aria-posinset nor aria-setsize, see https://www.w3.org/TR/wai-aria-practices/examples/landmarks/navigation.html.

KevinTCoughlin commented 5 years ago

Also worth noting that aria-posinset and aria-setsize are not required if all elements are present in the DOM, see:

Not required if all elements in the set are present in the DOM. See related aria-setsize.

https://www.w3.org/TR/wai-aria-1.1/#aria-posinset

KevinTCoughlin commented 5 years ago

After speaking with @v-vasud on Friday, we came to the conclusion that the Nav with accessibility issues was related to the wrapper component within the Dashboards package. Adding the appropriate folks to triage cc: @Raghurk.

If this turns out to be OUFR Nav feel free to re-engage me.

msft-github-bot commented 5 years ago

This issue has been automatically marked as stale because it has marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment. Thank you for your contributions to Fabric React!

microsoft / fluentui