http://blog.rrwd.nl/2012/03/23/how-accessible-is-the-wordpress-cms-for-a-blind-content-manager/
Recent Updates RSS Toggle Comment Threads | Keyboard Shortcuts
-
esmi
-
esmi
Some interesting issues brought up by a blind user on the wordpress,org support forums: http://wordpress.org/support/topic/plugin-dantotube-some-accessibility-fix-suggestions
-
esmi
I’ve only just realised that Admin Bar links contain tabindexes. That’s bad enough but they’re not really in an intuitive/logical order. Can they be removed in a future version?
-
esmi
Has anyone tested the accesskeys in the HTML editor whilst using AT software such as JAWS? I’m really concerned about all of those non-numeric shortcut keys.
-
Franco
-
esmi
What did you test with?
-
-
Jane Wells
If you’ll be at SXSW this year, RSVP to come to the WordPress party on the 12th! Snacks, booze, WordPress people, what more could you ask for? No SXSW required, just an RSVP.
Also, if anyone wants to volunteer at the booth to help people with their sites/answer questions, get in touch with Rose, who is coordinating the booth.
-
carinato
What about keyboard navigation on primary menu with dropdown submenu ? I think this is a primary issue for accesibilty. I’m testing wp 3.4-alpha-20205, but there isn’t any enachment on main menu.
In my opinion css cannot use display:none for submenus because also screen readers don’t read submenus in this way
my 2 cents-
Boaz Sasson
Kind of late getting here, but would also like to be a part of the WP accessibility initiative. Background in SEO and started doing WCAG 2.0 accessibility consulting over the past year.
-
-
-
Jane Wells
Hey @esmi et al With the new plugin…
Hey @esmi et al: With the new plugin page headers (see http://wordpress.org/extend/plugins/buddypress/ http://wordpress.org/extend/plugins/bbpress/ http://wordpress.org/extend/plugins/login-logo/ for examples), what if anything should we be doing around alt tags for those images?
-
Graham Armfield
Hi Jane, happy new year.
In the examples you quote the images are mainly decorative – certainly in the case of BuddyPress and bbPress – so they should have an alt attribute set as empty string – eg alt=”".
In the case of the Login Logo one, the image contains more information (although it’s available elsewhere) so perhaps the alternate text should contain more. But it’s not a good idea to stuff the alt attribute with a long string.
As a general rule, alt text should describe what the image shows or represents. If an image is a link then the alt text should describe the link destination. If the image is purely decorative then the alt text should be an empty string.
Images should never be presented without the alt attribute as this will cause some screen readers to voice the entire path to the image – often a verbose, obscure or meaningless experience.
So to determine what the alt text should be for these header images, whoever is supplying them should also supply appropriate alt text to go with them.
Hope that helps
-
asdjqwueqwep
Good job Sven.
Now, insert this function:void ht1632_clear()for (int i=1; i<=4; i++)
ht1632_clear(i);
and leave the #define cls ht1632_clear in place, together will all calls to cls.
Basically, we re-defined the old ht1632_clear (with no parameters) function.(As before, I did not test this.)
-
-
Jane Wells
WordPress 3.3 is coming up on RC1 (meaning it’s close to launch). We tried to catch as many accessibility issues as we could, but chances are we missed things. If anyone would be willing to run 3.3 beta through the paces and report back on how it does/what fixes need to be made, that would be great. If you’re not set up with an svn install, you can download the beta tester plugin to put the beta on a test site.
-
Andrew Nacin
Test.
-
Graham Armfield
Are you primarily thinking back end or front end or both, and should we reply here – or elsewhere?
-
Jane Wells
Mainly the dashboard, since that’s where the changes are in 3.3. Responses in comments on this thread.
-
-
Graham Armfield
Not accessibility I know but not sure where to put this…. It seems impossible to switch comments off at the individual page level.
General settings are to allow comments. I edit a page and uncheck Allow comments and then Update the page. I’m returned to the edit page again and the comments checkbox is checked again. Not sure if it’s theme dependant but it happens on both twentyten and twentyeleven.
-
Jane Wells
Hi Graham. Please don’t use this blog for non-accessibility bugs, feature requests, etc. Try the support forums for troubleshooting. http://wordpress.org/support
-
Graham Armfield
Hi Jane. Understand that I’ve missed the boat on accessibility updates for 3.3. So looking forward to 3.4, please can you outline the correct route for people like myself to suggest accessibility enhancements. In order to get accessibility as right as possible I believe it’s important to design it in as early as possible.
Thanks
Graham
-
-
-
-
Jane Wells
Changed a couple of settings:
- Must fill in name and email, but removed the ‘must have previously approved’ setting so now comments go live immediately instead of waiting to be moderated.
- Close comments on posts older than 14 days old. Comments go unnoticed, and no action gets taken. Hopefully discussions can get to agreement within 2 weeks (well before, if we’re lucky) and the resolution can make its way over to the appropriate trac ticket.
-
Graham Armfield
I’d like to get involved with making WordPress more accessible. Where do I sign up?
-
Jane Wells
Right here (and welcome!). Can you weigh in on the tabbing issue below?
-
Graham Armfield
Have done already Jane. Thanks. How would I start a thread?
-
-
-
Jane Wells
Do people think it is better for the dashboard menus down the left side to work as described in A, B, or C:
- A. Tabbing goes from top-level item to its subs and cycles through them, then proceeds to the next top-level item, etc., and hitting Enter/Return acts as clicking on the link to whatever item you’ve tabbed to; or
- B. Tabbing goes from top-level item to top-level item, and hitting Enter/Return ‘opens’ the subs and then you can tab through them?
- C. A more accessible suggestion that we haven’t thought of?
Please leave your vote/suggestion/comments in a reply to this post IF you work professionally in the accessibility field OR you need to access WordPress without a mouse/trackpad/rollerbar/other mouse-like input device (generally due to disability). If you don’t fit in one of these categories: while your opinion is valuable, it’s not the one we’re looking for at this particular time. So regular designers, developers, and users, please don’t distract from the pros and the target population on this thread. If you are an accessibility pro and have not introduced yourself on this blog before, or a keyboard access/screen reader user, please add a note about your qualifications/experience (for pros) or your typical setup/environment (for users — which screen reader, do you use keyboard shortcuts in addition to tabbing etc) so that we can put your suggestions in context. Thanks.
P.S. Please don’t derail the conversation by using this thread to suggest other features.
-
Steveorevo
B – hitting enter twice would then activate the given top level
P.S. Support for touch ala mobile devices in widget drag n’ drop would be nice, but hiring me would be nicer!
-
Jane Wells
Can you let us know your experience with accessibility so we have some context for your participation? Thanks.
P.S. This is not the place for feature requests. The regular forums have a whole section for that, and this blog is very specifically focused on accessibility.
-
Steveorevo
Sorry about the request here Jane. Noted.
I’m afraid I don’t have the accessibility background, however my “related field” is UI, specifically simulation, and formerly 3D gaming engines along with some early telephony APIs (E911, etc.). This means catering UI systems to humans visually, audibly, and sometimes tactile. I guess that is a far cry from accessibility. WordPress is now my passion.
I’d agree with Chris that K (below) that ‘B’ proposes a feel for structured hierarchy. Although you pointed out that this is strictly accessibility, part of accessibility (as in Section 508) is catering to individuals with visual and cognitive disabilities. Cognitive would relate to the acquiring of knowledge and the experience of a laid out UI. I would imagine the perception and grouping (and acting on that grouping with ‘Enter’) would influence accessibility. My reasoning behind choosing B. The implication for screen readers would reflect this as well, not unlike the structured top-level menus one would hear when navigating a voice assisted phone system.
-
Jane Wells
The UI group is where we focus on issues of hierarchy, design, etc. Most of our designers and developers (myself included) are not particularly experienced with screen readers and keyboard access rules/guidelines, which is why this separate blog exists and really is meant to be kept specific. If you are interested in more general UI stuff, you may want to follow/join in at http://make.wordpress.org/ui
-
Steveorevo
Noted. Thank you Jane!
-
-
-
-
-
Chris Kankiewicz
B
From a usability standpoint this would give the navigation a structured feel of hierarchy. I’m not sure what implications this would have on screen readers.
-
Jane Wells
We’re looking strictly for accessibility (as in Section 508) feedback here, not general usability.
Can you let us know what your background with accessibility includes so we have some context for your participation? Thanks.
-
Gooitzen van der Ent
Hello Jane,
A bit difficult to jump in on a conversation somewhere. Read you were looking for people to help out.
Made an inventory of accessibility within WordPress. Sure it can be improved. Feel free to use it where you can. Hope it helps.
-
Gooitzen van der Ent
Of course adding the link to the blog post might help…. :duh::
Blog post title: Accessibility & WordPress
Blog post link: http://ecodelphinus.com/2012/01/07/accessibility-and-wordpress/I have multiple years experience designing for accessibility. However, at the moment a bit stretched for time and means to do any testing and take on volunteer jobs at the moment. Will try to keep an eye on things, and help where possible.
Would like to add or see added a, clearly marked, accessible and WCAG 2.0 theme to WordPress.com if possible. Seems to be missing at the moment.
-
-
-
-
Larry Thacker Jr.
Not all screen readers are very good at handling dynamic content, so the simpler the better. Thus I prefer the first option. I am not an accomplished web coder, but perhaps using heading levels would help a screen reader user approximate the second option by heading level navigation, which all screen readers I know of can do.
-
SG
C. I think a mix of A and B would be more efficient, as explained below:
Most admins keep their most-used top-level items expanded most of the time. Tabbing should work as described in B, jumping from top-level to top-level, and hitting enter expands any non-expanded groups. When tabbing arrives at an already-expanded group, it should work as described in A, and tab to each sub-level element. Hitting enter on an expanded element should collapse it.
My 2 cents.
-
Jane Wells
In 3.3, there’s no more click to expand/keep expanded… everything is done with flyouts (unless you don’t have javascript enabled) so that everything is (for mouse users) one click away.
-
Steveorevo
Forgot about that in the latest beta sounds like B would even be more to the point as A would entail excessively long tabbing operations.
-
SG
Jane, in that case A does work better, but I still think it could be augmented.
How about when tabbing over the top-level items, the currently selected item is automatically expanded (to show what’s inside). If the user wants to go down, they hit enter, if not, they keep hitting tab to traverse the remaining top-level elements. Naturally each auto-expanded item is then auto-collapsed upon tabbing away from it.
Have you thought about allowing the use of arrow-keys once the user has ‘tabbed’ into the menu area? Down to jump down to the next element within the current hierarchy (eg. top-level items), right to go down into sub-elements, and left to go back up to the top-level parent.
-
-
-
Peter Bossley
I am a screen reader reliant user of Word Press and I believe option B is preferable, assuming that you can make this function properly with a wide range of screen readers which might be difficult, but possible. Heading navigation would be good in this context since screen reader users are used to navigating by headings to skip to the next set of controls, etc. While keyboard shortcuts are nice to haves, because of screen readers heavy use of keyboard hooks for quick navigation mode they are somewhat less useful for screen reader reliant users out of the box. In other words they have to know the shortcuts are there and then activate bipass mode to pass the keystrokes directly to the browser.
-
Graham Armfield
My gut feel is for A as tabbing is surely the lowest common denominator of keyboard accessing links etc on a page.
B sounds appealing but how do you intend to convey to keyboard users (both sighted and non-sighted) how the menu functionality works before they come across it? If that can be squared successfully then I’d probably favour B.
Another technique I’ve experienced is using the space key to open menus, but I guess that’s less useful these days with touch screens.
-
Everett Zufelt
I think that B would be the easiest to use, provided that you can provide some type of affordance to educate users about the functionality. The common paradigm, as I currently experience it, is that tabbing cycles through all items in a superfish style of menu. That being said, the assistive tech / keyboard only user that is tabbing through a page is * incredibly * inefficient.
I think he problem should be ‘How can we provide an affordance to indicate to users that the top level menu items, when activated, expose a sub-menu?’. Once the menu is exposed I would think that the ability to tab through the sub-menu items would be expected by most users.
Drupal Core Accessibility Maintainer, 7 years experience using screen-readers.
-
Léonie Watson
Option B would be the preferable default solution IMHO. To offer a really good experience, give people the option to enable option A if they wish though.
ARIA could be used to build in the affordance needed to make option B really usable, for recent screen readers at least. Check out the menu, menubar and menuitem roles:
http://www.w3.org/TR/wai-aria/roles#role_definitionsHeadings really shouldn’t be used to represent the menu hierarchy. It’s semantically incorrect for one thing, and it negates the usefulness of headings as a navigation mechanism within the content of the page for another.
-
Graham Armfield
Hi Léonie, do you have an example site that uses option B and ARIA to ‘build the affordance’ that you would consider to be accessible. I’d be really interested to analyse that.
Graham
-
-
Bob Easton
previously: consultant for IBM’s Accessibility Center – now: recently retired
Many of us favor B because the function feels right. Screen reader users (blind and low vision) are the most difficult to accommodate. Implementing choice B with conventional HTML, and even with script supplemented HTML is not only difficult to do well, but leaves us with the problem several have noted: how is the visitor informed of how the structure behaves.
Léonie’s answer is the best because ARIA does exactly what is needed. ARIA was designed specifically for bring accessibility to dynamic implementations. The key is the “role” attribute. Just as screen readers (can, if enabled) announce HTML elements, they can announce ARIA roles. And THERE is how the visitor learns of the behavior. The screen reader will announce to the visitor that the top level is a menu, and that lower elements are menuitems.
Graham: many examples can be found with a Google search for “aria menu example.”
For anyone else not familiar with ARIA, the WAI-ARIA Overview at W3C is very helpful.
-
Graham Armfield
Bob, thanks for the suggestion – obvious really. And yes I’ve found some examples.
-
-
Sharron Rush
+1 for Leonie’s suggestion. B is the best of those offered. Consider adding a level of access to the sub-menus that is operated using arrow keys. So you tab through the top, main navigation level and then use the down arrow to open and explore sub-items. You can see this type of navigation in action on our web site http://www.knowbility.org. And congratulations WordPress on providing these accessibility options!
Sharron Rush
co-author, Maximum Accessibility
Executive Director, Knowbility, Inc-
Graham Armfield
Thanks for the link Sharron. I’ve had a look at the navigation and it works as you say. But I’m wondering how you’re informing people that they need to use the up/down keys when the flyout menus appear?
I’ve also tried with NVDA and JAWS in Firefox but I’m not getting any audio prompt to indicate that a submenu is there.
-
Bob Easton
Do you hear “menu” spoken? That should be the clue. Once the visitor hears that word, they should know there are menuitems reached by arrow keys. Unfortunately the blind have to know a lot more about how things work than most of us. Hearing an ARIA role announced, they learn / know to take the right action.
-
-
-
esmi
I’ve already argued strongly against option A and for option B on the wordpress.org support forums as I think A would create significant problems for keyboard navigators. I do like Leonie’s suggestion of using ARIA as an enhancement – just as long as there is no reliance on this additional functionality. Not all non-mouse users will be using screen reading software.
-
Jane Wells
Looks like B is the clear winner, which is handy since that’s what went into core over the weekend. We’re at the end of beta, pre-RC right now in the 3.3 dev cycle. We tried to catch as many things like this as possible, but there were a lot of changes with the admin menus and admin bac/toolbar, so we may have missed something. If anyone would be willing to put the 3.3 beta through its accessibility paces, if we missed other things we can try to hit them before we get to RC. Will start new thread for that, though.
-
Everett Zufelt
@Jane
You say that B went in over the weekend. Can you say how you’ve addressed the requirement for there to be an affordance to assist sighted and visually impaired users about the functionality of the top level menu links?
-
sam C
D. I think the WordPress admin menu should work the same way the Fluency Admin plugin (http://wordpress.org/extend/plugins/fluency-admin/) works it. Because when user clicks a link, it doesn’t take em back to the top.
-
Jane Wells
The point of this thread is to deal with non-click situations, when there is no mouse or equivalent input device.
-
Sam C
Jane.
Thanks for that clarification. I was alluding to the fact that, that mention plugin has short-cut keys. But when you said “Tabbing”, I first thought of the Tabs or buttons in general, but I now know you actually mean the “Tab” Key on my keyboard. In my UX experience when developing AIR applications (that’s, of course, when I’m not developing WordPress sites. ) it seems to be standard that the tabbing on menus that have sub-menus go as choice “B”, but the “spacebar” key usually expands the parent tab just like in the [+] to [-] show/hide links does on many sites. However the “Enter” key is what executes the selected item.Thanks Sam
-
-
-
Everett Zufelt
Since option B has been implemented, I am curious if anyone has tested it? In particular, I am curious about what affordances are available to indicate the functionality of the link?
-
Andrew Ozz
The full “first run” version went in yesterday evening. It implements role=menu, role=menuitem and aria-haspopup on both the top menubar and the left-side menu.
The functionality is still enhanced with JS: Tab to select, Enter to open submenus that have role=menu, Tab to go through submenu items when opened (visible) , Esc to close the submenu and return to the top menu (and select it), then Tab to go to the next top menu item.
As always we would appreciate more testing of this, especially by people that work in that field or by screenreader users.
-
Jane Wells
Bearing in mind that today is RC, so no more enhancements. Only addressing blocker bugs that are bad enough for enough people to prevent moving forward for the rest of 3.3 (less than 2 weeks).
Any enhancements at this point will go in the dot release or 3.4.
-
-
-
Everett Zufelt
I don’t rally have time, but if someone can provide me with credentials to a installation to test I will test these menus. My intuition tells me that you will have some confused users. Particularly since menu and menuitem are ‘widget’ roles (interactive), and can cause screen-readers to work in a way that some users may find disorienting.
The menu / menuitem roles are really designed to mimic a menu in a desktop application (think the ‘File, Edit, View, etc.’ menus in Google Docs).
-
Jane Wells
We don’t generally set up test installations for volunteers to QA on, as the main point is to see how things work on real setups (vs our own protected/quirky environment). The beta tester plugin can turn any WP installation into a test site running trunk: http://wordpress.org/extend/plugins/wordpress-beta-tester/
If the Aria stuff is likely to confuse people we can delay release to pull it out, but it was added at the suggestion of comments on this thread. We released RC early this morning and are not supposed to still be making changes, so I would say either make a very specific suggestion that you think will address the problems you’re anticipating and provide a link that will explain the how-to so @azaozz can look into it, or hop into IRC today to discuss real-time. irc.freenode.net #wordpress-dev Thanks.
-
-
Everett Zufelt
@westi on #wordpress-dev setup a test environment for me. I tested with FF 8.0 / JAWS 13.
1. I logged into the site.
2. I was taken to the Dashboard.
3. There was nothing identified as ‘menu’
4. There was a ‘list of 14 items’ near the top of the DOM.
5. The first item ‘Index’ had a sub-list of 2 items, but they had no content (no words / links / anything).
6. Activating another item in the first list (Users) took me to a new page.
7. @westi told me that ‘Posts’ is one of he top level menus, JAWS (control + f) could not find ‘Posts’ on the Dashboard page.
I hope this feedback helps.
-
esmi
Franco are discussing. 
We have done some testing but in the end we preferred to install ckeditor