bwinton
Accessibility review of Snooze Tabs design/panel nav
Need to review the accessibility of this feature, design/colour-wise as well as keyboard navigation wise.
Here are some more obvious things (I will try to take a better look shortly):
-
Panel header (snooze this tab, manage snooze tabs, pick date time) font contrast is a little low (you can see this tool to check how well the font color works with the background - http://webaim.org/resources/contrastchecker/)
-
^ Same goes for the right column within the snooze times list
-
Calendar widget seems to have low contrast as well in a few places.
-
Keyboard navigation possible improvements (probably needs a separate issue). Initial focus is correct - the whole panel is focused. Consequent focus should go to the list of possible snooze options. And after that to the bottom menu bar. Next TAB should blur the panel completely and go to the next widget in the browser. I would suggest the following interactions:
- Current active element should always be visible to the user.
- When the panel has a list of options or a list of snoozed tabs user should navigate the list with up and down arrows and the focus should be maintained on the list container. Pressing enter should do the same things as clicking on the list item. (when on the manage panel, this will help with automatically showing delete button when list item is selected with a keyboard). Delete should have a keyboard shortcut when delete button is pressed.
- Calendar widget should maintain keyboard focus on grid container and internal navigation (within the grid) should happen via arrow keys.
-
Visibility. Based on the fact that I can tab from main panel to calendar widget I suspect that the panels are not exclusively visible. At any point in time only physically visible panel should be visible and the others should be hidden with visibility, display CSS properties or hidden attribute.
-
Semantics. I haven't looked at the actual markup but just some pointers. Ideally semantic native elements should be used and in places where they are not enough, ARIA should be used. So for panels:
- Top level header should ideally be
<h1>tag - footer should have an aria role="menu" (https://www.w3.org/TR/wai-aria/roles#menu).
- Middle section should have an aria role="listbox" (https://www.w3.org/TR/wai-aria/roles#listbox) since it's a list of interactive items. Each item should then have a role="option" https://www.w3.org/TR/wai-aria/roles#option
- aria-activedescendant should be used for the list container to indicate which item in the list is currently active. Let me know if you have any questions about how to use it
- ^ All these provide a number of affordances to screen reader such as size and internal position in the list.
- Top level header should ideally be
I think this is already a pretty long list, I'll try to dive in deeper at some point or can wait for the next iteration after some stuff above is addressed. Cheers
Once I get Sevaan's fixes in in can ping @yzen to look at a new version for us
@lmorchard i made a pr earlier today, and immediately found a small glitch that I should be able to repair tomorrow (obscured panels still respond to css psuedo-selectors).