Opened 13 years ago
Closed 13 years ago
#19394 closed task (blessed) (fixed)
Add ARIA attributes to the menus in the admin
Reported by: | azaozz | Owned by: | azaozz |
---|---|---|---|
Milestone: | 3.3 | Priority: | normal |
Severity: | normal | Version: | 3.3 |
Component: | Accessibility | Keywords: | has-patch commit |
Focuses: | Cc: |
Description
Support for screen readers can be (significantly) enhanced by adding few ARIA related attributes to the HTML tags in our menus. The role="navigation"
is a must, perhaps some explanatory text for top level menus as well.
Attachments (5)
Change History (26)
@
13 years ago
Adds navigatoin roles and first effort at menubar and menu/menuitem trees to Admin Bar
#8
@
13 years ago
#9
follow-up:
↓ 10
@
13 years ago
- Keywords dev-feedback added
I got some insight from an accessibility specialist in our Access Center at the college this morning. He offered up a couple of points on the tabbing behavior and ARIA role setting:
- He applauds any efforts we're making to improve usability for people using adaptive technologies like screen readers.
- He mentioned tabbing may not be as popular today as it once was (Due in part to the advancement of adaptive technologies).
- The actual action of tabbing through the menus was straightforward and helpful, with the reader reading out the proper menu names as we went, but one thing that became immediately obvious was that the ability to simultaneously have multiple menus open wreaks havoc because opening a menu via enter essentially inserts items between top level items into the tabindex.
Example Index: Dashboard >> Home >> Updates > Posts > Media
Can become: Dashboard >> Home >> Updates > Posts >> All Posts >> Add New >> Categories >> Tags > Media
See attachment:tabbed-menu-overlap.png
I think we may need to tackle how to enforce having single menus open at once, if possible. Hope that helps.
#10
in reply to:
↑ 9
@
13 years ago
Replying to DrewAPicture:
...
I think we may need to tackle how to enforce having single menus open at once, if possible. Hope that helps.
Thinking we can close any open submenus on pressing Enter to open another submenu. That would still leave the "old" submenu open unless the user presses Esc or opens another one.
#13
@
13 years ago
- Milestone changed from Future Release to 3.3
- Resolution set to fixed
- Status changed from new to closed
This should be completed for now. For any bugs please open new tickets.
#14
@
13 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
Spoke too soon :)
Seems we cannot use role=menu and role=menuitem without having arrows keys navigation. Attaching a patch to remove these for now.
#15
@
13 years ago
19394-4.patch doesn't seem to revert all of our aria stuff. Is that intentional?
#16
@
13 years ago
@nacin:
We can leave the role="navigation" attributes in because they're just ARIA landmarks and don't demand arrow key navigation. The more specific menu and menuitem attributes are what can't go in without arrow key navigation functionality.
#18
in reply to:
↑ 17
@
13 years ago
Replying to nacin:
Okay. Is there a reason why role=navigation shifted elements?
Yessir. Because of the expected hierarchy of using menubar, menu and menuitem child roles we compensated by moving the navigation landmark up a level to adminmenuwrap
. Since the menu and menuitem roles have been reverted, it looks like @azaozz decided to move the navigation role back down a level to adminmenu
where it should've been anyway.
http://core.trac.wordpress.org/attachment/ticket/19088/ARIA.menu.roles.patch is a good start. Thinking the next step should be to have
aria.menu
,aria.menuitem
, etc. and some text.