Hello all. I am a new face around here, with a background in accessibility compliance and testing. I thought I would pitch in to help make Drupal as accessible as possible.
I am starting by looking at the Accessibility Guidelines for Drupal 7: WCAG 2.0 & ATAG 1.0, but if anyone knows of an area with a more critical need for attention, please let me know.
Under the section "1.4.1 Use of Color (Level A)", there is an item with the following:
Color is not used as the sole method of conveying content or distinguishing visual elements. - Red * for mandatory fields
This should be in compliance, as color is not the sole method of conveying the content.
- Content: Indicate the field is required.
- Primary method: A * indicates that the field is required. This is used consistently, and is an accepted web convention.
- Secondary method: The * is red, in order to reinforce the required nature.
The contrast ratio may be questionable (I haven't tested it yet) however, that should be addressed within the guideline covering minimum contrast.
Is this the kind of testing that is necessary, and how do I proceed once identifying/testing/resolving an issue?
Comments
Welcome Aboard!
Hey jbehen,
Glad you're contributing. First, I posted the wiki about Accessibility Guidelines for Drupal 7 and I'm glad to see them evolve. It will be even more useful to edit this when this site is upgraded to Drupal 6 and we can have versioning.
I personally think the most important think at this point is to review and validate the issues (and patches) identified in the Drupal core improvements for Accessibility. In many cases it's a matter of installing Drupal 7, applying a patch and letting us know if it makes Drupal 7 more accessible (or has any unforeseen effects). There's actually a patch for color contrast that's been added just recently that needs more consideration.
It is useful to have this type of review. I think that the use of a red * for mandatory fields is standard in core. Are there places where you know there might be problems? If there are then we should be submitting bug reports. It would be useful to review how WCAG 2.0 wants error messages.
Guess a couple issues. Do you have a CVS version of Drupal 7 you can work with to apply the patches? That's really useful. Next do you know how to install/create a patch? There's some good documentation on that I can point you to if needed.
Even just creating bug reports in Drupal.org is useful. Might be helpful for us to know what your background is. Sometimes finding a solution is easy and finding the best solution is very difficult.
Mike
OpenConcept | CLF 2.0 | Podcasting
--
OpenConcept | Twitter @mgifford | Drupal Security Guide
Thanks for the welcome
Thanks for the welcome. Here is a little of my background.
I currently work for a non-profit agency providing support and employment to individuals with disabilities, as well as freelance development and usability/accessibility consulting.
On the development side of things, I have been involved with web development since 1996, with the last 7 years focused on my preferred language of PHP. I would say I am fairly skilled, but certainly not at the guru level.
I have been active in the accessibility arena for about 5 years. Historically, my focus has been on WCAG accessibility, but my recent clients have had a greater need for Section 508 compliance. My experience has included compliance testing (both automated and manual), conversion, development and accessibility education, in both the commercial and federal sectors.
I do not currently have a D7 image installed, but that will be rectified tomorrow on a fresh test box. My experience with Drupal is fairly limited, which is what brought me here in the first place. Any pointers in the right direction would be appreciated.
I hadn't looked at the current issues you posted. Those will be a good location to work from. I had been looking at the initial wiki you had posted, and thought that...
Color is not used as the sole method of conveying content or distinguishing visual elements. - Red * for mandatory fields
...indicated there might be an accessibility issue, due to the color of the star. I was offering clarification that a red star is perfectly acceptable. While the red itself may/may not be of sufficient contrast, that is an issue regarding contrast, not one concerning color being a sole indicator. The red is a secondary indicator to the initial presence of the star.
Thanks again for the welcome, and I think I will dig into testing the core issues you linked!
~John
Great to have more expertise onboard
Thanks for the introduction. Great that you've got a lot of experience about WCAG. There are a few folks on this list who are much more experienced with this than I am. I am trying to collaborate more with a team here in Ottawa, the folks behind the WCAG 2.0 Theme song who are now interested in Drupal. There's a pretty high level of knowledge in this group and so the challenge is in coordinating it so that we are able to come to agreement on what we want changed and how we want to do that.
Not sure how familiar you are with CVS, but this is probably the right place to begin - http://drupal.org/node/320
Information on applying patches - http://drupal.org/node/60108
Info on creating patches - http://drupal.org/node/22568
They have gone a lot more quickly since the simpletest was integrated.
However, all of the patches submitted need to have a bunch of people review them and give a +1 on them to ensure that they are implemented right, will not cause problems with the rest of Drupal and will enhance accessibility for everyone.
Thanks for the clarification on the mandatory fields.
Mike
OpenConcept | CLF 2.0 | Podcasting
--
OpenConcept | Twitter @mgifford | Drupal Security Guide
Juice Studio Plugin Color Contrast Plugin
Just thought I'd add in here that the Juice Studio Mozilla extension has an interesting color contrast checker that is worth checking out.
Mike
OpenConcept | CLF 2.0 | Podcasting
--
OpenConcept | Twitter @mgifford | Drupal Security Guide
Vision Australia has such a tool, too
Vision Australia also has a free standalone application, Colour Contrast Analyser, which works in Windows. (I wish there was another for Macs so I could use it at home.)
Because it's a standalone application, you can use it to examine color contrast in any application or setting— PhotoShop, Acrobat, PowerPoint, Word, your desktop, and so on. But the Juicy Studio extension gives the same result, so if you have FireFox you can use it to assess contrast in anything you can view in the browser.
Vision Australia's is available in many different languages, too.
More recent version of the Colour Contrast Analyser
I believe the most recent version of the Colour Contrast Analyser tool is now hosted at the Paciello Group site. Refer to Contrast Analyser, Version 2.2. Note that they've also included a Mac version.
Mac Colour Contrast Analyser most unMaclike
Thanks for the tip, BBC. I've installed the Mac CCA at home and have made good use of it.
(削除) Unfortunately, its interface is less Maclike than is the Windows version's interface! (削除ここまで)It still gives good data. It's just weird that the PC version would have a smooth drag-and-drop interface and the Mac version wouldn't.
Oh, well. I should be glad it's available at all.
On further use, its interface is quite Maclike and elegant. (I just didn't recognize Mac's native color picker at first.) The only thing it doesn't do is color simulations, but Sim Daltonism does.
These are great tools. Support open source projects!
Cliff
Color Contrast Evaluators and Colorblindness Simulators
I recently found this comprehensive review of color tools. Even though it is a couple of years old, it has every tool I am familiar with plus one for Mac that was new to me: Color Oracle.
I have not done an exhaustive review of Drupal themes, but the few I have checked have significant problems with ensuring enough contrast when their original color schemes are used. (I guess I should cross post this to the Themers and IAs group. I shall.)