Ensure that we have parity with the current accessibility of the new tab in Release and the upcoming "discovery stream" new tab in Nightly.

Marco, is this something you can assist us with? Thanks!

Gavin, is this still needed? I was out on sick leave until now, as my Bugzilla also indicated. Please NI me again if yes, and provide info on how I can test this new experience. Note that I won't be able to provide a full audit, since all of the visuals are not accessible to me, being totally blind.

Hi Marco. Yes, as much of an audit as you can provide would be very helpful for us.

Do you have access to a Nightly build? We are basically looking for accessibility feedback on the rebuilt new tab experience. Thank you!

PS: If you need a custom build I can create one. Just let me know!

Yes, I do have a nightly build running. Here are my findings so far, and they should probably all be turned into separate actionable bugs:

1. Every main section heading has an extra tabstop on a span element with role "button" and a class of "click-target". The heading itself also has a tabstop, so there are two tabstops for each heading, plus the one on the menu button for that section. And in the case of Pocket, for the "How it works" link. That extra span with class click-target has no label, so it is not clear what the purpose of that is. So, either
   • Remove that tabindex and make the span presentational (role presentation instead of button), thus removing that extraneous tabstop. Or
   • Give the button a label if its purpose is something defined.
2. The menu for a section has several problems:
   1. When pressing Space on the Open Menu button, focus lands on a span with role "menu". From here, up and down arrows don't work. I have to press Tab once to get focus to the first menu item, and from there can press up and down arrows. This is similar to the new about:logins menu that Jamie described in bug 1566321.
   2. Focus should move to the first menu item instead of the menu container.
   3. Markup should be changed as follows:
      • The menu role should move from the span to the child ul element.
      • The li elements should get a role of "presentation" or "none".
      • The button children of the li elements should get a role of "menuitem". In WAI-ARIA, accessible children of a role "menu" must either be menuitem, menuitemradio, or menuitemcheckbox, but nothing else.
3. All the above is also true for the context menu for a single item like @google or @amazon. Only that here, the mnuitem role is on the li, when it should be on the button, and the button should be the menuitem. And the ul should be the menu as above. Also, the span inside the li that shows the separator should get a role of separator and should not get a tabindex attribute, so it is not focusable and skipped, but still separates the menu items in an accessible manner.

If some of the work to fix these happens in Github pull requests, feel free to CC me @MarcoZehe there as well.

Some of these have been partially addressed by existing PRs (like this one for managing the menu focus) but not everything is covered. I'm going to open another PR to address everything in one place.

EDIT: Here it is.

https://hg.mozilla.org/mozilla-central/rev/4274af431ede

I have verified this issue with the latest Firefox Nightly (70.0a1 Build ID - 20190808214929) installed, on Windows 10 x64, Arch Linux and Mac 10.14.5. Now, I can confirm the following:

• Verified that the "about:newtab" page is keyboard accessible.
• Verified that the elements from the "about:newtab" page can be accessed using the "NVDA Reader Mode".
• Verified that the main sections no longer have an extra tabstop.
• Verified that when opening an "Open Menu" with the keyboard the focus lands on a menu item and the other menu items can be focused using the "Up" and "Down" arrows.
• Verified that the "Separator" line from the context menu no longer has a li role and has a separator role.
• Verified that the menu items from the "@amazon" and "@youtube" have the menu items, while the menu items from other top site cards have the role of "text leaf". (Previously they had the "pushbutton" role).
• Verified that the ul class from the context menus now has a "menu" role and the li has a "presentation" role.