First, a bit of good news, we got another accessibility feature into core - http://drupal.org/node/356359
Still have a lot to do before this list is addressed though - http://drupal.org/node/364629
Next, over the weekend I ran a good friend of mine through a quick usability test of Drupal 7. He was a good enough sport to let me tape it - http://www.youtube.com/watch?v=NyIHtNHYroM
Main thing that came up there was how long it took him to tab through to create an account and how hard it was to see what was the element in focus. Lots of people have mobility restrictions and tab through websites, so how do we improve this in Drupal Core?
For links, I think it's a matter of improving the use of a:focus, a:hover, a:active
I think that I'd like to see this piece of the system.css enhanced
ul.primary li a:hover {
background-color: #eee;
border-color: #ccc;
border-bottom-color: #eee;
}Likewise, I'd also like to see it in the forms. Now the colour combinations are a bit stark, but something like this would help everyone know where they were clicking.
input:focus, select:focus, textarea:focus {
background:red;
color:white;
}Not sure where the best place to insert this would be, probably right in the system.css too.
I do think it should go there rather than in Garland so that it needs to be over-written by other themes if they want to adjust the colors/effects.
Thoughts? Comments? Concerns?
Some background posts on this subject:
http://www.skillsforaccess.org.uk/howto.php?id=96
http://grantbroome.blogspot.com/2007/01/importance-of-link-highlighting....
http://www.webaim.org/projects/whitepaper.htm
http://www.webstandards.org/learn/tutorials/accessible-forms/advanced/
Comments
Good usability session, Mike
This is a case where one test is all that we need to recognize a significant issue: Because the tab order goes through the full set of navigation options before getting to the "meat" of the page, a person with mobility impairments must struggle to get into the page.
So often we focus on solving accessibility issues for the blind and forget that there are a whole host of other impairments to deal with. A fully blind person using a screen reader would no doubt here a "skip nav" link announced at the beginning of the page. But unless we also do something to make that "skip nav" link obvious to people who can see but can't easily manipulate the keyboard, it won't do them any good. That's what happened in this test: It took four and a half minutes for your friend to get to the "Create account" field, enter his username, and click "submit."
How many of us would tolerate a site that forced us to take that long to register? Why should people with mobility impairments have to, especially when we can use CSS intelligently in our themes to put content first in the tab order — before the navigation and other framing elements?
Yes, that's a little more work for us. Yes, it's an adjustment for us to recognize as we maintain a page that the first thing we see in its html will be the guts — the important stuff, the unique stuff — and not the first thing we see on the displayed page.
But look at the difference it would make for a person who has to expend more energy to achieve a single click than I had to expend to get to this discussion and post this reply.
Yes, we need to improve the focus, too. But let's not forget that removing unnecessary clicks is also an important step to reducing barriers to accessibility.
Thanks, Mike, for coordinating this video, adding the informative pop-up notes, and posting it. I'm going to use this at work to impress upon people the importance of making sure that sitewide navigation doesn't detour anyone from the page content.
Glad you liked it
It's also been proposed that moving around the layout would help address some issues with semantics & SEO too.
http://drupal.org/node/44072
Nice when there is some overlap for sure.
Also, gotta get support to get this into core:
http://drupal.org/node/386462
Mike
OpenConcept | CLF 2.0 | Podcasting
--
OpenConcept | Twitter @mgifford | Drupal Security Guide
I Added in Form Focus
I created a patch here - http://drupal.org/node/418306 - to address form focus and address one of the usability issues mentioned in the video.
Mike
OpenConcept | CLF 2.0 | Podcasting
--
OpenConcept | Twitter @mgifford | Drupal Security Guide
Examle Issues of Needing Focus for Form Elements
I could use some examples of why (if it's really a good idea) input:focus is useful for people with either visual disabilities or mobility limitations.
Most testing is done with a mouse so people generally know which form element they are using. Can we get some folks to test the usability here (I was being more restrictive, of this URL, but think it would be useful for more folks to actually see):
http://drupal7.dev.openconcept.ca/
I'd like to know if folks see this form focus as an enhancement for usability or accessibility.
Mike
OpenConcept | CLF 2.0 | Podcasting
--
OpenConcept | Twitter @mgifford | Drupal Security Guide
screen magnifiers, mobility limitations
Hi Mike,
Apart from the general screen reader uses of input:focus, the largest benefit I've observed tend to be for mobility limitations that require sip-and-puff controls or head wands for getting to the fields, so testing is done without a mouse. As the major limitations make it difficult to jump around on a website, visual cues provided by on-focus can be terrific to help the user get to where s/he needs to be on a page on the first try, without missing the focus event a few times.
Another thing to think about is that some screen magnifiers can use focus to make objects larger in the magnifier window, however some of the more popular ones do not do this with inputs, therefore it is in the hands of the designer to make it abundantly clear which field the user is in.
For mouse-based testing, it may not be so useful as to be a necessity, but it is a nicety. Something to consider is the distraction factor for visually-impaired users. Pausing in the middle of filling out a form, s/he may lose mental focus (no pun intended :) ) on the breaking off point without a cue such as the one provided in your OpenConcept example. The focus action going in that example seems to me to be subtle enough not to be intrusive for any user experience but seems like it would be helpful to disabled users for the reasons above.
All in all, like so many compliance guidelines, the level of compliance definitely depends on the site or form audience.
Needs & Wants
Thanks for this Kate,
It's great to have some more details here of people, places where input:focus may be useful.
Of course this can be dealt with at a theme level. However, I'd like to encourage this community to think big.
I really appreciate sites that take the time to add that additional focus to the form I'm using. Firefox does an alright job, I could always build an extension for firefox to customize all forms, but I won't (and most other folks won't bother either).
But if we're trying to envision what we'd want to be the default level of accessibility for Drupal out of the box, what would it look like? Given how standards compliant Drupal Core is, it was shocking to see how many validation errors the W3C produces on Recovery.gov. However, it takes a really badly tested theme to do that with Drupal. Normally it is pretty simple to just tweak the theme and eliminate the stray validation issues that may work there way in when customizing a standard theme.
The same thing should apply to Drupal 7 I think. It should be work to make it less accessible. The initial release should raise the bar for everyone and allow both content readers and content creators to participate more effectively.
So what's the best practice that we should be pushing for? Is this one that matters? Seems like it would be for some people. If we're including folks with mental disabilities (and frankly this is a high portion of the population), then it's probably a much higher percentage than we'd think.
Mike
OpenConcept | CLF 2.0 | Podcasting
--
OpenConcept | Twitter @mgifford | Drupal Security Guide