JAWS does not announce popup after column selection

[jeanettetb]

Environment

Operating system
Windows 10

Browser
Firefox ESR 60.8.0esr

Automated testing tool and ruleset

Assistive technology used to verify
JAWS Version 2019.1906.10 ILM

Detailed description

What version of the Carbon Design System are you using?
"carbon-components": "^10.7.3",
"carbon-components-react": "^7.7.3",

What did you expect to happen?
When a table row is selected and the batch action bar is shown or updated, I expect JAWS to aler the user that the batch action bar is shown/updated. I also expect JAWS to indicate that the table row selection checkbox controls the batch action bar (allowing a JAWS user to jump to it using JAWSKEY+ALT+M)

What happened instead?
JAWS did not announce the batch action bar; The user could not jump from the row selection checkbox to the batch action bar

What WCAG 2.1 checkpoint does the issue violate?
4.1.3 Status Messages(AA) ???

Steps to reproduce the issue

1. Select a data table row that will show, hide, or update the batch action bar

https://codesandbox.io/s/tablebatchaction-not-announced-by-jaws-od5r6

Additional information

• Screenshots or code
• Notes

[asudoh]

@dakahn Is this reproducible...? Thanks!

[dakahn]

Can confirm. Batch actions toolbar is not announced. :|

Tested with JAWS 2020 on latest Firefox in Windows 10

[asudoh]

@carmacleod Just in case you have some insights... Does ARIA have a notion of "contextual action bar", where an action bar appears only in certain context? Thanks!

[carmacleod]

Does ARIA have a notion of "contextual action bar", where an action bar appears only in certain context?

ARIA can be used to indicate that an input like a button or checkbox controls the visibility of a container element. See the spec for aria-expanded. So if each checkbox has aria-expanded="true/false" and uses aria-controls to point to the id of the section element, then that should be helpful.

I have some other suggestions as well (based on the code sandbox example):

• when the section is not visible, make sure the div.bx--action-list has css visibility:hidden so that keyboard users and screen reader users can't accidentally focus those buttons (and it goes without saying that when the section is visible, div.bx--action-list needs to have visibility:visible).
• remove the aria-live="polite" from the tbody. It's not really meant to be used on parts of tables, so could confuse some screen readers. (What was it being used for? Are table rows being added or removed independent of user add/remove actions?)
  • if you want the "n items selected" announced when the user selects or deselects, then aria-live="polite" could go on the div.bx--batch-summary.
• you may want to delete the aria-label="data table toolbar" from the section, because adding an accessible label to a section element has the side effect of turning it into a landmark. Screen readers have special keys to navigate to landmarks, but if there are too many landmark regions on a page then a user wouldn't bother using them. (Also, it's a bit complicated having a landmark appear and disappear.) So I think a component library generally wouldn't add landmarks. The app can decide on the semantic structure of the page.

[carmacleod]

Please, at a minimum, remove the aria-label="data table toolbar" from the section, as recommended above in #5242 (comment). This is causing an Accessibility Checker failure in our pages whenever there are multiple data tables on a page.

[carmacleod]

Ok, this is "Take two", because my original suggestion (aria-expanded & aria-controls on the checkboxes) would have resulted in a very chatty and confusing experience for screen reader users so I asked for it not to be merged. For example navigating to and checking the first 2 checkboxes would have resulted in the following:

row 2  check box  not checked  collapsed  <<< pretty noisy
Unselect row  checked  expanded  <<< pretty confusing
checked  expanded
row 3  check box  not checked  collapsed  
2 items selected 
Unselect row  checked  expanded
check box  checked  expanded  

New list of suggestions:

• If possible, please use display:flex / display:none or visibility:visible / visibility:hidden to show / hide the div.bx--toolbar-content and div.bx--batch-actions toolbars instead of aria-hidden="false" / "true". Screen readers can still give focus to the aria-hidden buttons in the toolbar, which can be pretty confusing to the user. I was able to do this in JAWS just by using up arrow from the top of the table.
• Remove the aria-live="polite" from the tbody. It's a bit extreme to use aria-live in a table, so would confuse some screen readers. In the case of this table, when the user checks the "Select all" checkbox, every checkbox label is changed from "Select row" to "Unselect row", so the screen reader says: "Unselect row, Unselect row, Unselect row, Unselect row, ..." which is obviously confusing and suboptimal.
• The checkbox labels should not change. Please just use "Select row". The checkbox state takes care of telling the user whether "Select row" is checked or not. i.e. "Select row checked" means the row is selected, and "Select row not checked" means it is not selected.
• Give div.bx--toolbar-content and div.bx--batch-actions role="toolbar".
• Give div.bx--toolbar-content an aria-label="General" (or similar), and give div.bx--batch-actions an aria-label="Batch actions".
• Change the section.bx--table-toolbar to a div and give it role="region". (long story. section elements need to be stand-alone areas so they can go into the html outline, which doesn't exist, but may some day.)
• Make the default aria-label for the div.bx--table-toolbar be aria-label="Data table" (i.e. remove "toolbar" from the aria-label, because the "toolbar" role will be spoken for the visible toolbar and we don't need it to be spoken twice).
• If the author has provided a title prop for the TableContainer (definitely recommended - can Carbon make the title prop required?), then please incorporate that into the label for the table and the toolbar as follows:
  • give the h4.bx--data-table-header__title a unique id (say, for example, id="table-title-1")
  • use aria-labelledby="table-title-1" on the <table> element (this will be spoken as "[Author's title] table" when the user enters the table)
  • use aria-labelledby="table-title-1" on the div.bx--table-toolbar and do not use the aria-label="Data table". This will be spoken as "[Author's title] [General / Batch actions] toolbar" when the user enters the toolbar.
• If the title prop is required, then (depending on the design) authors might need a boolean "titleVisible" prop to hide it offscreen.
• Now we're ready to address this issue by adding a new live region and moving it offscreen. Keep the live region permanently in the DOM so that the screen reader knows it's there. Something like this:

  <div id="table-updates" class="bx-assistive-text" aria-live="polite">
  </div>
  

  • and then when the user selects the first item, add a span containing the new info, something like:

  <div id="table-updates" class="bx-assistive-text" aria-live="polite">
    <span>Batch actions toolbar available above table.</span>
  </div>
  

  • maybe also update the number of items selected (which would be a duplicate string to the visible one in the toolbar, but it's probably nice to know), e.g.:

  <div id="table-updates" class="bx-assistive-text" aria-live="polite">
    <span>1 item selected. Batch actions toolbar available above table.</span>
  </div>
  

  • you might want to remove the "Batch actions toolbar available..." part on subsequent updates to the number of items selected so that it is not repeated, e.g.:

  <div id="table-updates" class="bx-assistive-text" aria-live="polite">
    <span>2 items selected.</span>  <<< 3 items selected., etc
  </div>
  

  • when 0 items become selected, maybe something like:

  <div id="table-updates" class="bx-assistive-text" aria-live="polite">
    <span>0 items selected. Batch actions toolbar hidden.</span>
  </div>
  

With the above markup, screen reader users will be able to navigate to the toolbar using landmark navigation (shift+R in JAWS, shift+D in NVDA, control+option+U for VO rotor), or, if a title prop was given for the TableContainer, then a simple shift+H will go to the h4, and Tab key will go to the toolbar (if you can guarantee that the title prop is there - even if it's offscreen - please let me know, because I might change the markup a bit to remove the region). Alternatively, if there are multiple tables on the page, the next table/previous table keystrokes (T and shift+T) will take them to the top of the table, and then they can type shift+tab to go to the toolbar. JAWS has a keystroke for "go to first cell in table" (from which shift+tab goes to the toolbar), but other screen readers don't have that, and it's pretty esoteric, so even JAWS users might not know it.

Unfortunately, keyboard users will still have to use shift+tab multiple times to go back to the toolbar. The only way around that is to give them a keyboard shortcut for "go to toolbar" and make sure it's discoverable in doc, and maybe also in live region, i.e. "Batch actions toolbar available, type [keys] to focus." I guess keyboard users could also use the landmarks plugin to navigate quickly to the toolbar region.

Before someone starts working on this issue, I would like to run this by a few folks to see if they agree with these suggestions. I will report back here after that.

[mbgower]

Many of the things @carmacleod is suggesting gel with prior work I did on operable tables and thoughts I had when considering how to have a good experience of batch controls that appear On Input, above the focal point, including:

• messaging
• focus handling
• operation and
• labelling.

The checkbox labels should not change. Please just use "Select row". The checkbox state takes care of telling the user whether "Select row" is checked or not. i.e. "Select row checked" means the row is selected, and "Select row not checked" means it is not selected.

I do have some thoughts about ways to improve the default label for row selection inputs (be they radio buttons or checkboxes). Effectively, make the first cell in the row that doesn't contain the input into the label (or part of the label or described by) for the input. You could also make the label cell a knob setting, for a situation where the first cell is NOT the best row header option.
I've done this many times on custom tables. The big question is what percentage of the time is this design decision going to improve on a generic "select row" message.
We'd have to do some testing to see what unanticipated outcomes we encounter.

[mbgower]

One thing I don't see addressed here in my quick read through is focus handling, both

1. after a delete function, when the row with focus ceases to exist, or
2. when a batch action is cancelled, which causes a significant change of context with no consistently available point for focus to be put.

This is an existing problem, not one introduced by her proposal.

[mbgower]

Now we're ready to address this issue by adding a new live region and moving it offscreen. Keep the live region permanently in the DOM so that the screen reader knows it's there. Something like this:

<div id="table-updates" class="bx-assistive-text" aria-live="polite">
</div>

and then when the user selects the first item, add a span containing the new info, something like:

<div id="table-updates" class="bx-assistive-text" aria-live="polite">
  <span>Batch actions toolbar available above table.</span>
</div>

maybe also update the number of items selected (which would be a duplicate string to the visible one in the toolbar, but it's probably nice to know), e.g.:

<div id="table-updates" class="bx-assistive-text" aria-live="polite">
  <span>1 item selected. Batch actions toolbar available above table.</span>
</div>

---

BTW, I would like to see some consideration of a design that allows both filtering function and batch selection status messages to appear in a consistent location.

Surfacing batch action messages to a screen reader is pretty straightforward. I think we could be taking more advantage of the messages that appear in the table header, as with "1 item selected". I don't see any reason we couldn't just have a message about the toolbar appearing as a one off, and just treat this area as a live region.

The filtering results are a much harder nut to crack, because the screen reader is unaware of anything happening in the row results and no text is displayed. This seems orthogonal to this issue, but my sense is a decent design solution might be able to address them both.
I can elaborate.

[carmacleod]

Good point about focus handling. In Outlook Mail, for example, if you delete a message focus goes to the next item. If there is no next item, focus goes to the previous item. This makes sense to me.

The next focus handling point above is tricky. Currently, after the cancel button is pressed, focus stays on the cancel button. (I presume that if a Cancel dialog was opened, e.g. to say "Are you sure?", then focus would return to the cancel button.)

This seems ok, because tab forward now goes to the next focusable item after the (invisible) Cancel button, i.e. the next row checkbox, and shift+tab goes to whatever focusable element is before the invisible Cancel button in the tab order.

The weird part is that because the Cancel button is invisible, there's no focus ring anywhere. Not sure what to do about that.

[carbon-bot]

Hi there! 👋 You may have seen that v10 reached it's end of support on September 30, 2024. In the interest of keeping a tidy issue queue, issues flagged as relating to v10 will be closed.

If this issue is still relevant, please open a new issue with a link to this issue and a reproduction that uses v11.

Thanks again for your participation and contributions to this issue and the Carbon ecosystem! 💙