Feedback wanted: Keyboard and focus visibility accessibility audit

Developer Tools
#1

Hello everyone!

Firefox 70 includes a new audit checker in the Accessibility developer tool that allows you to check for common keyboard usability and focus styling problems. We would like your feedback on the issues it raises. This is true especially if you encounter combinations where you receive a false positive, like the claim that focus styling is missing when in fact, it is clearly visible.

Please try out the new tool in your projects, and comment ere, if possible, with links to CodePen etc. that we can use to reproduce the problem and adjust the checker accordingly.

Thanks!

Marco from Mozilla’s accessibility team

#2

Just tried it on a grid we’re building out and it seems like it’s throwing some false positives. (Or our grid is broken and I don’t yet see how.)

We haven’t thoroughly tested it yet (it’s not rolled out to any users) but the semantics seem to be right, and it seems like it should work for sighted keyboard users, and VO+Chrome/Safari users.

https://elastic.github.io/eui/#/tabular-content/data-grid

#3

Hi Michael, I have just given your grid a quick test. The issue I am seeing is that “focusable elements should be interactive”. For some reason, it does not recognize the keyboard handler for the grid or the active cell. Role “Grid” makes a grid interactive by default, so it is expected that the keyboard can be used to execute something on the cell, like pressing Enter or Space or such, for example to edit the contents. Is that the case? The semantics for the grid themselves look correct, and NVDA speaks the information as expected when arrowing around the grid. Have you implemented such functionality in the grid?

#4

Hia, I seem to get a couple of false positives for keyboard on https://alastairc.uk/

The ‘main’ has tabindex="-1" so the skip link works in Safari. This isn’t interactive, or intended to be, so I think that’s a false positive.

Also, there are 6 boxes on the page whcih have a fixed height and overflow-y: auto;.

Two of those (on my screen) have scrolling, and those are picked up as interactive. They have keyboard commands, in that up/down work, but I don’t think that’s an issue?

#5

So the way our grid’s designed to work is arrow keys to move between cells and pressing enter opens a dialog. As a component library, we’re not strictly dictating what happens inside that dialog. (In this example, the dialogs don’t do much though they are the only way to interact with the cells that have interactive content like the email and location columns.)

#6

It looks like <input type="number"> gives a false positive for the “Form elements must be labeled” warning. The label gets associated with the spinbutton role in the accessibility tree, leaving it’s child entry without a name.

Also, the native up/down pushbuttons inside the number input throw warnings for “Interactive elements must be focusable” and “Interactive elements must be labeled.”

EDIT: The spinbutton itself also has a “Interactive elements must be able to be activated using a keyboard” warning.

#7

Hopefully a lot of keyboard related false positives are going to be fixed with: https://bugzilla.mozilla.org/show_bug.cgi?id=1591409 . At least examples with negative tabindex and table/grid interactive semantics.