One of the baseline principles of web accessibility is that all functionality of a site should be available via keyboard navigation alone. (That's guideline 2.1 from WCAG 2.1.)
The new comment flag dialog is inaccessible via keyboard navigation.
Keyboard support is important. Many people with muscular difficulties, and basically anyone who's blind and using a screen reader, may be unable to use a mouse and fully reliant on a keyboard.
There's two problems here.
1. The comment flag button cannot be reached by keyboard alone
It's an anchor element (not a
<button>) with no href and no tabindex value set. Because of this by default this element is not in tab order and cannot be reached via the tab key. The only way to access that element is by clicking on it.
This also means blind users will be entirely unable to flag comments.
(The same is also true for the comment upvote button, mentioned here: Keyboard-only users cannot upvote/downvote posts or comments.)
2. The comment flag options are not navigable to via keyboard.
If you manage to open the dialog (issue #1 gets fixed and it's in tab order) then you cannot reach the options within it purely via keyboard. Try it, click on a comment flag button:
- try pressing up or down: the page scrolls.
- try pressing tab a few times: you'll just tab through links behind the dialog.
There is one way to reach the flag dialog: Eventually if you hold tab for long enough you'll move past every link further along on the page, past the footer, and then reach the comment flag dialog. Whilst that's better than nothing, it's something many non-techy people usually wouldn't even think to try—they'll give up and hit Esc to get rid of the dialog stuck on their screen.
What should happen?
Make the comment flag button (and the upvote button above it) either
<button type="button"> or
<a tabindex="0" role="button">. ARIA guidelines would suggest use the button element, but if it must stay an anchor element, you want to give it the button role because it isn't a link or anchor, it's a button. (Tabindex of 0 means put it in tab order based on its relative location on the page, i.e., the normal behaviour for anything tabbable.)
I suggest implementing the WAI-ARIA Authoring Practices modal dialog design pattern for the comment flag dialog, as well as the regular post flag dialog (which is still reachable within a tab press or two, but doesn't do all the things it should). It advises you on the ARIA attributes to set and the keyboard interaction pattern users should experience.
<button>. A challenge I'm facing is that just tabbing through things absent of any other accessibility technology doesn't appear to advance the focus from the button to the dialog even with
aria-modal=truein play. I think in this specific case, I would need to explicitly focus something a control when the dialog appears.
js-focus-firstclass and put focus on that. For the report dialogs that would (should) be the radio buttons. Note you'll also need to implement a tab trap within the dialog to keep focus from moving out of it. (google "accessible dialog tab trap") When the dialog closes you'll put focus back onto the button that opened it.