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.

#8

Iā€™d like to report a false positive.

Disclaimer: link is a WIP site on my dev VM. It will be down often and I also regularly change things. I tried to reproduce the issue in a codepen, yet failed at it. Iā€™ll remove the link once you had a look at it.

[ā€¦]

On this page are a button (Sign in) and 2 links that look like a button, the Google and Facebook icon buttons.

All 3 are reported for not having :focus styles, yet they clearly do. This can be verified visually as well as by inspecting the CSS rules.

#9

Yeah that particular part of the keyboard audit related to focus styling is not 100% guaranteed to be accurate (it is pretty hard to reliable tell if focus styling is present). This is why the message says that focus styling may be missing and is a warning. This is however a bug where thereā€™s some sort of race happening when we check focus styling. Iā€™ll file, thanks!

1 Like
#10
#11

Thanks for checking! During my own investigation I figured it might be a race condition and tried to isolate it into a codepen, yet failed to extract the exact conditions triggering this.

Unfortunately, I do have to take down my link, yet I see in your bug report youā€™re linking back to here, that might be a problem?

#12

I think I will try to create a test case with two concurrent keyboard checks running in the accessibility panel. Iā€™ll update here in case the test case work or otherwise, if maybe there might be a need to get a set of CSS properties that you set for :focus rule. In case you have it, itā€™d be super helpful if you could just post the rule here so I could try it in the test. Also, important to note, there might be (and in all likelyhood will be) additional issues with the check if there are CSS transitions.