Accessibility-insights-web: Card from report doesn't respond to NVDA / Narrator table commands when reached via 'tab'

Created on 4 Dec 2019 · 8Comments · Source: microsoft/accessibility-insights-web

Describe the bug

This issue was created from this comment. When a user tabs to a card in the report, the row contents are not read by NVDA or Narrator.

To Reproduce
Steps to reproduce the behavior:

Run a fastpass on this website
Export a report
Open NVDA on the report
Pressing "tab" to get to the card leads to focus on the card. Pressing any arrow key or shortcut key from this point does not lead to the content of the card being read (only the first card row, which gets read by default when first focused on the card. The CTRL+ALT+arrow combinations also do not lead to any cell
Before tabbing to the card, NVDA does recognize a "T" to get to the table. At this point arrow keys work properly to navigate through each table
Pressing "T" while focused on the card (after getting there from tabbing) does not go to the table
If focused on something other than the card, pressing down and up arrows reads through all the content in the card as well (similar to browse mode)

It seems like being focused on the card disallows arrow key & 'T' input from NVDA.

Expected behavior

Are there benefits to this table being in the tab order - am I missing a common/canonical keystroke to read the contents?

Context (please complete the following information)

OS Name & Version: Windows 1903
AI-Web Version & Environment: 2.10.3 production, 2.11.0 insider
Browser Version: Version 78.0.3904.108 (Official Build) (64-bit)

Did you search for similar existing issues?

This issue was separated from https://github.com/microsoft/accessibility-insights-web/issues/1494, which was auto-closed; we may want to add more details to that issue for closure.

bug resolved

Source

karanbirsingh

All 8 comments

This issue has been marked as ready for team triage; we will triage it in our weekly review and update the issue. Thank you for contributing to Accessibility Insights!

msft-github-bot on 5 Dec 2019

This issue requires additional investigation by the Accessibility Insights team. When the issue is ready to be triaged again, we will update the issue with the investigation result and add "status: ready for triage". Thank you for contributing to Accessibility Insights!

msft-github-bot on 5 Dec 2019

@iamrafan could you please take a look at this?

ferBonnin on 5 Dec 2019

Per conversation with Peter, moving to active and assigning to @waabid since you are working on it too

ferBonnin on 6 Jan 2020

Moving back to Ready for Work since this is not actively being worked on.

peterdur on 21 May 2020

It seems to have to do with the use of <div> tags that are then given the role of table instead of semantic tables. The functionality of the table role greatly depends on the screen reader / browser combination. For example, I was able to navigate the tables in the card using the NVDA keyboard shortcuts when using NVDA with Firefox, but not using NVDA with Chrome or the Chromium based Edge. Looking to see if there are any fixes that can be used for this short of it being changed to a semantic table.

Some references I used to come to this conclusion include:

CorgiDev on 24 Sep 2020

❤1

We see the problem as being the current UI is confusing to a screen reader user because we have an unexpected control type which receives focus, and it causes NVDA’s focus mode to be activated automatically. The user could always press escape to get out of focus mode; they just aren’t given the right context to understand that’s what they should do.

An additional problem is that in the report UI, the highlights can't be turned on or off by the card UI, rendering the need to focus on the cards moot. We should make it so that no focusable elements controlling failure instance highlighting are present in the report.

The proposed solution is

Remove the aria tags from the “table”, just as corgidev has done.
a. This will keep focus from landing on a control the user doesn’t understand and focus mode from automatically coming on. The user will still be able to use their quick nav keys.
Create an offscreen toggle button (which controls highlighting) in the dom for each card. These buttons will be invisible to sighted users but focusable and detectable by screen reader users.
a. When focus lands on a (visually hidden) highlight button, the card will be styled so that it appears to have the keyboard focus. In that way, sighted keyboard users will be able to know when they can select cards with the keyboard.

If it works technically, this should leave the current visual UI unchanged, while providing a control screen reader users know how to interact with. This has the added benefit of being more clear to screen reader users how to toggle highlights.