Make WordPress Core

Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#19088 closed defect (bug) (fixed)

Accessibility for the admin bar

Reported by: azaozz's profile azaozz Owned by: azaozz's profile azaozz
Milestone: 3.3 Priority: normal
Severity: normal Version: 3.3
Component: Toolbar Keywords: ux-feedback
Focuses: Cc:

Description

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.

Attachments (4)

wpLogoFocus19088.diff (626 bytes) - added by pas5027 12 years ago.
fixed overridding of :focus on the wp logo, see screenshots, #19183 on
admin-bar.dev.js.patch (3.1 KB) - added by azaozz 12 years ago.
ARIA.menu.roles.patch (902 bytes) - added by DrewAPicture 12 years ago.
Adds navigation roles to admin bar and Dashboard menu
menu.roles.example.png (79.8 KB) - added by DrewAPicture 12 years ago.

Download all attachments as: .zip

Change History (48)

#1 @jane
12 years ago

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

#2 @toscho
12 years ago

  • Cc info@… added

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.

Last edited 12 years ago by toscho (previous) (diff)

#3 @koopersmith
12 years ago

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?

#4 @toscho
12 years ago

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.

#5 @jane
12 years ago

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

#6 @azaozz
12 years ago

  • Owner set to azaozz
  • Resolution set to fixed
  • Status changed from new to closed

In [19162]:

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

#7 follow-up: @koopersmith
12 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

#8 @koopersmith
12 years ago

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

#9 @toscho
12 years ago

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.

#10 in reply to: ↑ 7 @azaozz
12 years ago

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.

  1. 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).

  1. 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.

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

Yes, tabbing requires jQuery. See above.

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

See #1.

  1. 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.

  1. 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.

  1. 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.

#11 @scribu
12 years ago

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

#12 @ocean90
12 years ago

  • Cc ocean90 added

#13 follow-up: @nacin
12 years ago

  • Severity changed from normal to blocker

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
12 years ago

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

#14 @pas5027
12 years ago

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.

#15 @azaozz
12 years ago

In [19206]:

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

#16 @azaozz
12 years ago

In [19207]:

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

#17 in reply to: ↑ 13 @azaozz
12 years ago

  • Severity changed from blocker to normal

Replying to nacin:

Fixed, not a blocker then?

#18 @ryan
12 years ago

  • Component changed from Accessibility to Admin Bar

#19 @ocean90
12 years ago

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

#20 @koopersmith
12 years ago

In [19328]:

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

#21 @ocean90
12 years ago

  • Keywords needs-patch added

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

#22 @koopersmith
12 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In [19427]:

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

#23 follow-up: @johnbillion
12 years ago

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?

#24 follow-up: @johnbillion
12 years ago

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.

#25 in reply to: ↑ 24 @nacin
12 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

#26 in reply to: ↑ 23 @azaozz
12 years ago

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.

#27 follow-up: @azaozz
12 years ago

  • Keywords ux-feedback reporter-feedback added; needs-patch removed

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.

#28 @azaozz
12 years ago

  • Keywords reporter-feedback removed

@johnbillion any other ideas/opinions?

#29 in reply to: ↑ 27 ; follow-up: @johnbillion
12 years ago

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.

#30 in reply to: ↑ 29 ; follow-up: @azaozz
12 years ago

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.

Last edited 12 years ago by azaozz (previous) (diff)

#31 in reply to: ↑ 30 @johnbillion
12 years ago

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.

#32 @azaozz
12 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

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

#33 follow-up: @nacin
12 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

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

#34 in reply to: ↑ 33 ; follow-up: @jane
12 years ago

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.

#35 in reply to: ↑ 34 @jane
12 years ago

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.

#36 follow-ups: @toscho
12 years ago

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

#37 in reply to: ↑ 36 @jane
12 years ago

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.

#38 @jane
12 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

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

#39 in reply to: ↑ 36 ; follow-up: @azaozz
12 years ago

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.

Last edited 12 years ago by azaozz (previous) (diff)

#40 in reply to: ↑ 39 ; follow-up: @toscho
12 years ago

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. :)

#41 in reply to: ↑ 40 ; follow-up: @azaozz
12 years ago

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.

#42 in reply to: ↑ 41 ; follow-up: @toscho
12 years ago

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.

Last edited 12 years ago by toscho (previous) (diff)

#43 in reply to: ↑ 42 ; follow-up: @azaozz
12 years ago

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
12 years ago

Adds navigation roles to admin bar and Dashboard menu

#44 in reply to: ↑ 43 @DrewAPicture
12 years ago

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

Last edited 12 years ago by DrewAPicture (previous) (diff)
Note: See TracTickets for help on using tickets.