Open jeanettetb opened 4 years ago
@dakahn Is this reproducible...? Thanks!
Can confirm. Batch actions toolbar is not announced. :|
Tested with JAWS 2020 on latest Firefox in Windows 10
@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!
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):
Please, at a minimum, remove the aria-label="data table toolbar"
from the section, as recommended above in https://github.com/carbon-design-system/carbon/issues/5242#issuecomment-599158364. This is causing an Accessibility Checker failure in our pages whenever there are multiple data tables on a page.
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:
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.role="toolbar"
.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.)<table>
element (this will be spoken as "[Author's title] table" when the user enters the table)<div id="table-updates" class="bx-assistive-text" aria-live="polite">
</div>
<div id="table-updates" class="bx-assistive-text" aria-live="polite">
<span>Batch actions toolbar available above table.</span>
</div>
<div id="table-updates" class="bx-assistive-text" aria-live="polite">
<span>1 item selected. Batch actions toolbar available above table.</span>
</div>
<div id="table-updates" class="bx-assistive-text" aria-live="polite">
<span>2 items selected.</span> <<< 3 items selected., etc
</div>
<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.
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:
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.
One thing I don't see addressed here in my quick read through is focus handling, both
This is an existing problem, not one introduced by her proposal.
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.
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.
Environment
Detailed description
Steps to reproduce the issue
https://codesandbox.io/s/tablebatchaction-not-announced-by-jaws-od5r6
Additional information