One of the baseline principles of web accessibility is that all functionality of a site should be available via keyboard navigation alone. It's an important baseline to accommodate those with muscular difficulties or those who are blind (and would rely on a screen reader), who would be unable to use a mouse.
Users reliant on a keyboard cannot navigate the post flag dialog. There are some systemic issues preventing navigation through the flag process. For most users, especially blind users, flagging a post via the keyboard alone will be prohibitively difficult or impossible.
The following are some of the issues (missing features or problems) with the keyboard-only flag flow.
The flag button is described as a link. It should be described as a button, because it is not a link: it does not navigate us anywhere.
Focus management is missing: On activating the flag button, focus does not transfer into the dialog. The user has to tab additional times to bring focus into the dialog. Further, the user can tab out of the dialog: in fact a blind user will have no idea where the dialog begins or ends so will have trouble knowing if/when they've successfully entered it or when they've left it. When moving between dialogs within the flag flow, focus is also not placed in subsequent dialogs.
Navigating through options changes the dialog, making some flags prohibitively difficult to reach. This usually means the user gets stuck in the "duplicate" or "off topic" dialogs with no way to get back out of them (described in the next issue), making it difficult for them to access most flag reasons, including the custom flag reason.
Once I tab into the radio buttons, my first instinct as a blind user would be to hit ↓ to explore other options. However, halfway through this selects the duplicate option which moves the dialog onto that reason. I cannot move back to the previous dialog.
Let's say I arrive in the "should be closed" section instead and get the radio buttons focused somehow. Hitting ↓ selects off topic which transports me to the off topic dialog.
Can't move backwards through the flag dialogs via keyboard. As visual users we can see the breadcrumbs at the top left of the dialog, and as mouse users we can click them:
Blind users are not made aware of these breadcrumbs. Keyboard-only users cannot tab to them to move backwards through the dialogs.
The duplicate flag dialog is, itself, difficult or impossible to navigate if you wind up there, which considering it is one of the first places you might wind up is an issue.
- A blind user won't understand the duplicate dialog. Once their focus arrives in the dialog (if they get it there at all) they're just told to "search, or enter a question link or numeric id". They are not read any other instructions that we as visual users can see and read.
- Changing an option is impossible: once I pick a question I think I want to submit as the duplicate candidate, the < back to similar questions link is impossible to navigate to via keyboard.
- When I do pick an option, focus is transferred to the "vote to close" button. Tabbing back from there if I do want to change the option I chose means tabbing through every single link in the question pane given to me. (Which could be dozens of links!) This could do with some skip links back to the top of the pane.
Good features are ESC closes the dialog and Enter submits my flag. This behaviour should be retained.
What to do to fix it
The flag button (and all other buttons beneath the post: share, edit, close, delete, flag, mod) should be annotated as buttons. They should all have role="button" or be implemented as actual <button type="button"> elements. If you choose the second route, their appearance can remain identical to what it is now: remove the button border and padding and give it a transparent background.
I suggest implementing the WAI-ARIA Authoring Practices modal dialog design pattern for the post flag dialog. It advises you on the ARIA attributes to set and the keyboard interaction pattern users should experience. This includes auto-transfer of focus into the dialog, tab trapping, plus reading out the dialog heading. The accessibility update to the comment flag dialog implements this pattern very well. Focus management will need to be implemented for moving back and forth through the flag process.
Merely selecting a radio button option should not progress the flag dialog. Clicking on one, or pressing enter when one is selected, can/should progress the dialog however. That "clicking on one" thing means there will be no functional change for a mouse user for how the dialog behaves.
The duplicate dialog requires some rethinking/redesign from an accessibility POV.
The breadcrumbs and associated information about a dialog should be read out to the user and keyboard navigable.
All interactive controls inside the flag dialogs should be keyboard focusable. All the buttons should be annotated as buttons like in the first paragraph in this section.
This post is a follow-up on Keyboard-only users cannot flag comments in the new comment flag dialog by request of the developer who worked on it.
