Accessibility for the admin bar

[azaozz]

The admin bar is currently not accessible when "tabbing" through any screen it's shown on. We need some sort of keyboard shortcuts or at least need to make the tab key work.

[jane]

We need to enable tabbing more than we need more bespoke keyboard shortcuts. Tabbing is how keyboard users expect to get around the screen.

[toscho]

Oh yes please. :)

The menus in the horizontal and vertical navigations and the Howdy dropdown are nearly inaccessible for keyboard users in 3.3. This is solved much better in 3.2.

Edit: Keyboard shortcuts are not a solution. Most single letter shortcuts are already taken in screen readers and customized browsers like Opera.

[koopersmith]

There appears to be no change in tabbing behavior between 3.2 and 3.3 (in either the admin menu or the admin bar). It could be better, though.

What would an ideal solution look like?

[toscho]

In 3.2 the submenus open on focus. In 3.3 they don’t. This problem is worse now because you cannot keep the most used menus open any longer.
A strong visual focus indicator is missing too. No problem in Opera – but in Firefox it is nearly impossible to tell where the current focus is.

[jane]

In Chrome as well. No focus indicator, and no subs via tabbing.

[azaozz]

In [19162]:

Support for "tabbing" through the admin bar and admin menu, fixes #19088

[koopersmith]

Looks like a good start. I've been testing in Chrome and found a few bugs:

1. Top-level tabs without children aren't highlighted.
2. Shift+tabbing causes menus to remain expanded.
3. Menus expanded by tabbing can be collapsed by mousing over the menu, but can leave the parent item focused.
4. No-JS: Top-level tabs with children are highlighted, but do not expand.
5. When the W menu is highlighted, the W logo is not visible.
6. It is possible to highlight your the name/username item in the account menu (which leads to nowhere) — I will fix this bug.
7. Right-aligned menu items are highlighted before/between left-aligned menu items — I will fix this bug.

[koopersmith]

8. Command + clicking on top-level items with children can cause menus to remain expanded and/or the item to remain focused.

[toscho]

Why the tabindex? It ​isn’t needed usually, and since the search field is visible on the front-end only it may interfere with the theme’s tabindex order.

[azaozz]

Replying to koopersmith:

I've been testing in Chrome and found a few bugs:

Unfortunately the admin bar was coded/styled without accessibility in mind. That makes it hard to get tabbing to work properly. As you see had to use JS to keep the drop-downs open. Also the "main" styling is on the <li> elements instead of the links and tabbing must highlight the links (so pressing Enter would follow them).

There are few things that can be done to make this (at least) look better. However it's too late in the dev. cycle to try and re-make it now.

1. Top-level tabs without children aren't highlighted.

Move the styling to the links.

2. Shift+tabbing causes menus to remain expanded.

This doesn't seem to happen in FF, IE and Chrome on Windows. Menus are closed after a short timeout whether you tab forward or backward (Shift + Tab).

3. Menus expanded by tabbing can be collapsed by mousing over the menu, but can leave the parent item focused.

I suppose that's expected behavior, closing the menu by mousing over it should leave the parent highlighted and allow tabbing to continue from there.

4. No-JS: Top-level tabs with children are highlighted, but do not expand.

Yes, tabbing requires jQuery. See above.

5. When the W menu is highlighted, the W logo is not visible.

See #1.

6. It is possible to highlight your the name/username item in the account menu (which leads to nowhere) — I will fix this bug.

Proper way to fix that would be to allow passing a tabindex var to the menu generating code and set that to -1.

7. Right-aligned menu items are highlighted before/between left-aligned menu items — I will fix this bug.

This depends on the order the HTML elements are outputted. Tabbing follows the HTML layout not the visual.

8. Command + clicking on top-level items with children can cause menus to remain expanded and/or the item to remain focused.

Any type of clicking would usually focus the item (link), that depends on the browser. Not sure we can do anything better with the JS for closing the menus (hovering over them and out actually closes them as you point out above).

We can make the JS there more complicated and add edge cases handling, however IMHO we should try to build/rebuild it with accessibility in mind instead of trying to "patch" it with JS.

Ideally the admin bar shouldn't need JS to be accessible similar to the admin menu.

[scribu]

Tabbing works ok, except for menus without children, i.e. 'Comments', 'Edit post' etc.

[nacin]

The tab indexes are going to cause a lot of problems.

In Chrome:

• Posts -> Add New
• Enter a title.
• Hit tab.

Expected:

• You end up in the content area.

Actual:

• The profile dropdown in the admin bar opens.

Whoops. :-)

[pas5027]

fixed overridding of :focus on the wp logo, see screenshots, #19183 on

[pas5027]

notice :focus state on WP logo was being override by another style. see screenshots on #19183 and attachment above. Comments :focus state still needs to be dealt with.

[azaozz]

In [19206]:

Fix tabbing from 'title' to 'content', see #19088

[azaozz]

In [19207]:

Fix a:focus styling and backwards tabbing, add tabindex arg for <a>, see #19088

[azaozz]

Replying to nacin:

Fixed, not a blocker then?

[ocean90]

Sub-submenus aren't accessible via tabbing, see my sites item.

[koopersmith]

In [19328]:

Allow linkless items in the admin bar. Improve non-jQuery admin bar tabbing. fixes #19277, #19149, #19164, #15519. see #18197, #19088.

[ocean90]

Sub-submenus aren't accessible via tabbing, see my sites item.

[koopersmith]

In [19427]:

Allow access to any admin bar menu level by tabbing. fixes #19088.

[johnbillion]

Tabbing behaviour in the admin toolbar differs between the admin area and the front end. In the admin area it opens up and cycles through every submenu, on the front end it doesn't. Is this intentional?

[johnbillion]

Shift-tabbing in the admin area also produces different behaviour to tabbing. Shift-tabbing only cycles over the top level menu items, whereas tabbing cycles over every submenu item.

[nacin]

Replying to johnbillion:

Shift-tabbing in the admin area also produces different behaviour to tabbing. Shift-tabbing only cycles over the top level menu items, whereas tabbing cycles over every submenu item.

[azaozz]

Replying to johnbillion:

Tabbing behaviour in the admin toolbar differs between the admin area and the front end.

Unfortunately tabbing is extended with jQuery so if the front-end doesn't load it, tabbing won't work the same as in the back end.

Shift-tabbing in the admin area also produces different behaviour to tabbing.

The JS "helper" for tabbing emulates the press-enter-to-open for the active menu. Currently the JS helper removes the "press-enter" bit and opens the submenu as soon as the user tabs to the top menu. Tabbing backwards (shift+tab) works in exactly the same way, it opens the submenu when the user tabs to the top menu.

Actually was testing full emulation of press-enter-to-open (i.e. the user will have to press Enter to open submenus, not opening them automatically) that would probably be more natural for tabbing.

[azaozz]

admin-bar.dev.js.patch changes the tabbing to behave as if the admin bar menus were click-to-open. When tabbing the user has to press Enter to open/close each submenu. This is better UX (imho) as it's identical to the standard browser behavior.

[azaozz]

@johnbillion any other ideas/opinions?

[johnbillion]

Replying to azaozz:

admin-bar.dev.js.patch changes the tabbing to behave as if the admin bar menus were click-to-open. When tabbing the user has to press Enter to open/close each submenu.

I prefer this behaviour, but it does make it impossible to select the top level menu item.

I was more concerned that the front end and back end tabbing behaviour is different (if jQuery isn't present), but actually it's not the end of the world because the user can hit enter on the admin link and then tab through all the menu items once they're in the admin area.

[azaozz]

Replying to johnbillion:

I prefer this behaviour, but it does make it impossible to select the top level menu item.

Yes, but the top level menu "action" is the same as the first submenu item, so nothing is lost (the JS doesn't touch top menus without a submenu).

I was more concerned that the front end and back end tabbing behaviour is different (if jQuery isn't present), but actually it's not the end of the world because the user can hit enter on the admin link and then tab through all the menu items once they're in the admin area.

Right. In irc we were talking about loading jQuery on the front end for logged in users (as the admin bar shows only for them). This has the potential to bring errors, break (old) JS in the theme that hasn't been updated to use jQuery 1.6+, etc. so decided to leave it for 3.4. We probably can try "lazy-loading" jQuery only if it hasn't been loaded already, etc.

[johnbillion]

Replying to azaozz:

Yes, but the top level menu "action" is the same as the first submenu item, so nothing is lost (the JS doesn't touch top menus without a submenu).

The exception to this is the My Sites menu.

[azaozz]

In [19458]:

Admin bar: change the tabbing to behave as if the admin bar menus were click-to-open (Tab to select, Enter to open/close), fixes #19088

[nacin]

Jane never indicated a preference here. Let's not rush.

[jane]

Replying to nacin:

Jane never indicated a preference here. Let's not rush.

I believe I said in IRC that my preference was for tabbing to cycle through all choices so enter would be equal to clicking an actual link, but that given our timing, we should do whatever was easiest that wouldn't screw anyone. Worth getting an opinion from people focused on accessibility, I think. Will post something.

[jane]

Replying to jane:

Will post something.

Posted at ​the make/accessibility blog to get feedback from experts in the field. Please, let's let the target demo be the talkers there and not have a migration of the people already on this ticket over that thread. Looking for NEW input there that we can bring over here. Devs already posting on this Trac ticket are asked to refrain from jumping in on the make/accessibility blog to keep the focus there on what that group has to say.

I know I said that twice, sorry. Just really want that space to be for accessibility people, the same way we work to keep wpdevel for devs.

[toscho]

Open on enter is counter-intuitive (for me), is feels … risky, because clicking enter opens a new page on all other sites.

[jane]

Replying to toscho:

Open on enter is counter-intuitive (for me), is feels … risky, because clicking enter opens a new page on all other sites.

That was my guiding principal as well, but waiting to see if the experts correct that assumption. Sadly non-experts (devs and designers who just have an opinion or gut instinct) are filing up the thread on the accessibility blog despite being asked to refrain, so today I will email some accessibility people directly and ask their opinions.

[jane]

Clear winner on the accessibility blog seems to be tab+enter. I stand corrected!
Closing as fixed.

[azaozz]

Replying to toscho:

Open on enter is counter-intuitive (for me), is feels … risky, because clicking enter opens a new page on all other sites.

Could you link some examples? In most menus I've seen Enter opens the sumbenu if any or "activates" the action if no submenu (like gmail). That's what we have at the moment.

Still thinking we can improve this: perhaps Shift+Enter to follow the link and of course adding ARIA as ​suggested on the accessibility blog. Both of these shouldn't take long to code once we decide to go ahead.

[toscho]

Replying to azaozz:

Replying to toscho:

Open on enter is counter-intuitive (for me), is feels … risky, because clicking enter opens a new page on all other sites.

Could you link some examples?

​http://delicious.com/

​http://www.adobe.com/

​http://www.redhat.com/

​http://www.whitehouse.gov/

​http://www.scientificamerican.com/

​http://www.msn.com/?st=1

​http://www.linkedin.com

​http://vimeo.com/

In most menus I've seen Enter opens the sumbenu if any or "activates" the action if no submenu (like gmail). That's what we have at the moment.

From my (not representative) experience it is often just not predictable. A menu that opens on focus is predictable – you don’t have to guess, because the effect is visible immediately. And it is one key stroke less.
An online survey or other statistics cannot beat that simple logic. :)

[azaozz]

Replying to toscho:

All nice sites... But only one (msn) has something similar to our old menu behavior (auto-open on tab then tab through the submenu, when tabbing backwards don't tab through the submenus). All the rest don't show submenus or deal in any other way with menu accessibility when tabbing, most have alternate navigation links in the footer.

[toscho]

Replying to azaozz:

My point was not to find sites with the same menu, but to illustrate how hard it is for a keyboard user to know how links work before clicking on them. I think, we should look at this in context: The other menus in the left hand navigation are harder to use in 3.3, because the user cannot control anymore which submenus will stay open and which will be closed. This is already frustrating enough, we shouldn’t add more clicks to this.

Plus, the submenus in the left navigation do not open on click, they force a page load. Making a click working different on the admin bar and on the left menu will raise the learning curve again.

Make the handling of all elements as simple as possible, remove any situation where the user has to guess and any additional key stroke.

[azaozz]

Replying to toscho:

...The other menus in the left hand navigation are harder to use in 3.3
...
Make the handling of all elements as simple as possible, remove any situation where the user has to guess and any additional key stroke.

Agreed, adding "flyouts" to the unfolded left menu made it harder for tabbing. Perhaps we should add the same JS helper there and make it behave like the top menu. That will also make that menu almost the same as in 3.2 when tabbing.

In any case thinking we should add some ARIA args to both menus. That will be big accessibility enhancement.

[DrewAPicture]

Adds navigation roles to admin bar and Dashboard menu

[DrewAPicture]

Replying to azaozz:

In any case thinking we should add some ARIA args to both menus. That will be big accessibility enhancement.

After chatting with @azaozz in IRC and reading up on ARIA landmarks and roles, it looks like it can be as simple as adding navigation roles to the admin bar and admin menu. According to ​this Landmark testing chart from August 2011, the navigation role should be supported on the major screen readers nearly across the board.

See attachment:ARIA.menu.roles.patch​ and attachment:menu.roles.example.png​