I've been looking at what we've done here on Accessibility - http://drupal.org/node/394094 - it's a good intro, particularly for Drupal developers on accessibility. However, it isn't written in a manner that's general, or strong enough to be meaningful to others at this point. I thought it was worth while thinking about (and later drafting in a wiki) an accessibility statement.
I'm not sure we're in the position where we can get Drupal developers to sign onto something as strong as what TypoLight claims:
TYPOlight does not treat accessibility as just an additional feature and generates accessible XHTML strict output that meets the W3C/WAI requirements in the front end and the back end. The system degrades gracefully if JavaScript is not available or not enabled.
I don't like that Plone used Access Keys, but do like how clear they are in their validation process:
We have used XHTML 1.0 and CSS that conforms to specification, as laid out by the W3C because we believe that usability and accessibility must have a solid foundation. If anything on this web site does not validate correctly, please contact the Site Administration, and not the Plone Team.
We have also endeavoured to achieve AA accessibility as measured against version 1.0 of the WCAG. We are aware however, that a number of the checkpoints of the WCAG are subjective — and although we are sure that we have met them squarely, there may be instances where interpretation may vary.
I'd hope that we're using xHTML 1.0 Strict, CSS 2.1 & WCAG 2.0, and we'd want to be clear what versions of Drupal we're referring to.
Moodle's got a great example in that their main accessibility page provides a strong statement about how accessibility efforts help everyone:
Websites built with accessibility in mind are flexible in meeting different user needs, preferences and situations. Though these methods can increase usability for everyone who uses the web they are often legally required to be implemented in a specific effort to prevent discrimination against people with disabilities.
But they've also got a link to a much more comprehensive Accessibility Specifications. This is a list of lots of known issues.
The Wordpress Accessibility page is written not to techies but to communications folks who might want to read an overview of why they should care about the issue. Not a lot of links for more information, or for that matter info about what comes built into WordPress. And like Plone they are using Access Keys (which are an outdated concept).
Joomla's Accessibility page is the only one that distinguishes between front end, back end and their main site. We've been focusing on accessibility of D7, but should also think about changes we might want to make in http://drupal.org and even http://groups.drupal.org. It's pretty vague, "capable of delivering accessible websites" could apply to any open source CMS. It is good though that they are apologizing here for things not being as good as they'd like and making a public commitment to make it better.
Comments
Great idea, now where does it go?
Mike,
This is a great idea! For the Drupal 7 product itself, do you know where we say what standards it supports? I hope that the final product is valid XHTML and CSS and we would say that in writing somewhere.
I'm not sure that we can yet claim that the front-end or the back-end meet W3C WCAG 2, ATAG, Section 508 or other standards. I believe it would take one of us performing a full validation to justify those claims. Do you think D7 has met any of those to date?
Separately from that, I think a statement about our commitment as a community to accessibility would be great. I also suggest we set more concrete goals for planning Drupal 8 from the ground up to support certain standards like WCAG, ATAG, or Section 508.
Brandon
www.pixotech.com
Great idea, now where does it go?
Mike,
This is a great idea! For the Drupal 7 product itself, do you know where we say what standards it supports? I hope that the final product is valid XHTML and CSS and we would say that in writing somewhere.
I'm not sure that we can yet claim that the front-end or the back-end meet W3C WCAG 2, ATAG, Section 508 or other standards. I believe it would take one of us performing a full validation to justify those claims. Do you think D7 has met any of those to date?
Separately from that, I think a statement about our commitment as a community to accessibility would be great. I also suggest we set more concrete goals for planning Drupal 8 from the ground up to support certain standards like WCAG, ATAG, or Section 508.
Brandon
www.pixotech.com
Where does it go and how does it look?
I'd like to see the following alias' filled with information like:
I don't think we can claim that D7 meets any specific sets of standards yet. I think we can claim that we are striving for WCAG 2.0 and ATAG 2.0 compliance and that if there are any deviations that they should be clearly identified to the web accessibility committee or even better posting an issue on the D7 issue queue. I'd like to have D7 reviewed for WCAG 2.0 when it is released, but not sure how we're going to get the resources to do that.
Agreed on work towards Drupal 8. Would have to talk with the core developers more to see if we could get a commitment to work towards a specific standard.
--
OpenConcept | Twitter @mgifford | Drupal Security Guide
WCAG standards can't be our target
By that I mean that the site developer's actions ultimately determine whether a site complies with WCAG 2.0.
We can make Drupal prompt them for meaningful alternative text for all illustrations, but we can't be sure that they provide the alt text only when the illustration is informative and that the alt text they do provide is meaningful and useful. We can develop tools to make it easier to choose colors for appropriate contrast, but we can't be sure that anyone will use those tools to choose accessible color pairs. The best we can say is that we have designed Drupal to support the development of sites that comply with WCAG 2.0.
ATAG 2.0 is another matter. We can and should see what degree of compliance with ATAG 2.0 we can claim.
Drupal's Very Flexible
This is a double edged sword. Any number of modules or themes could remove any accessibility changes that we have worked to introduced.
However, with both WCAG 2.0 & ATAG 2.0 we can do our best to get the core code to comply and to educate the community about the importance of accessibility.
Hopefully out of the box we'll have basic compliance for both, know where there are areas for enhancements and have some modules to extend and enhance Drupal 7's accessibility.
"Drupal 7 has been designed to support the development of sites that comply with WCAG 2.0 & ATAG 2.0" is a good statement.
I've added it here - http://groups.drupal.org/node/39732 - but really need more suggestions of content.
--
OpenConcept | Twitter @mgifford | Drupal Security Guide
Good Examples with CKEditor
I like the new FCKeditor (CKEditor) accessibility statement.
They have a WCAG 1.0 review as well as an IBM Accessibility review online as well.
Nice that they have it broken down into headings so people can quickly scan to find the information they need:
* 1 Basic Navigation
* 2 Navigating Toolbar
* 3 Navigating Dialogs
* 4 Navigating Context Menus
* 5 Navigating Style Combo Boxes
* 6 Navigating Color Selection Boxes
* 7 Editor Hotkeys
* 8 JAWS
Having an accessibility statement is an important piece of a mature software which has grappled with trying to ensure universal access. Would be great to have more input on this from others in teh community.
--
OpenConcept | Twitter @mgifford | Drupal Security Guide
Just Replaced Installed the Latest CKeditor module
I just installed the latest module. I like the way it looks. It looks a lot better than the old FCK editor module.
AT-specificity and/or universal access?
aloha! i agree whole heartedly that quote Having an accessibility statement is an important piece of a mature software which has grappled with trying to ensure universal access. unquote
however, i'm a bit confused by the inclusion of "JAWS" as a bullet point the list contained in your comment -- while it is important that developers know what keys may conflict with the best-selling commercial screen reader, it is essential that developers remember that JAWS is but one of many screen access solutions, and Drupal, as an open source project, should ascertain what open source solutions are not only feasible, but actually used, such as NVDA on the windows platform and Orca and GOK (GNOME On-Screen Keyboard) in the GNOME desktop... universal access is achieved not through tailoring one's solution to a particular assistive technology, no matter how persistent that technology, as there are not only multiple options available to individual users, but most assistive technology that is worthy of the name allows for extensive user-customization, so even if one attempts to cater to assistive text X, one cannot ever be sure of hitting the mark in the way the content developer "intended" (boy, am i glad i didn't have to distill that sentence down to 140 characters!)
it is also essential that developers are made aware -- and made to consider -- potential conflicts (including, but not limited to, key conflicts) by 1) Accessibility Platform (e.g. MSAA, IA2, AT-SPI, etc.); 2) specific operating system platform default keybindings; 3) specific user agent default keybindings; all of which have a major impact on the utility of pre-defined "optimizations"
the developer of content should ALWAYS be reminded that what the content developer considers "important" and "useful" may or may not be useful or apparent to the user of an assistive technology, and that what appears self-evident to the content developer are in reality only "strong suggestions" which SHOULD take a back seat in key cascade order, first precendence being given to the user's assistive technology, second to the operating system's keybindings, and third the user agent's keybindings -- author-defined keybindings MUST be accorded a lesser precedence, so that users of assistive technology are not suddenly thrust into a universe where the most instinctive keyboard commands execute strange and unknown instructions, rather than performing the action the end-user intended to invoke by that particular key-press...
all of the above are considerations that need to be built-into any sort of accessibility statement / declaration of first principles...
Clarifications
Hey Oedipus, thanks for commenting.
I was just copying directly from the headers in CKEditor's Accessibility Statement in my bulleted list. It's a great point though that there are many excellent ones out there including VoiceOver for Mac folks. I'm always happier when folks are using open source, and of course NVDA & Orca should be mentioned. I'd missed Gok, thanks for pointing it out. It's easy to get lazy & just refer to the big ones.
It's good to point to resources, but this is more than the vast majority of developers will ever have the time to consider. It's difficult just getting folks to implement WCAG 2.0 standards let alone understanding protocols for accessibility that are essentially under the hood.
1) I don't know what the best references are, but these look useful to the Accessibility Platform reference you made: https://developer.mozilla.org/en/Accessibility/AT-APIs & http://www.w3.org/WAI/PF/aria-implementation/
2) so by this you're referring to problems with access keys? Need some practical examples here.
3) I'm really not sure which optimizations you are referring to or what the impacts are.
You've got to simplify this a whole lot if it's going to be useful for the broader community.
Can you give an example of a good accessibility statement that addresses your concern for what seems like a system wide approach to accessibility?
I'm really not sure how one would even begin to put this into something that people would read. Does the Linux Foundation Working Group have any examples to share?
--
OpenConcept | Twitter @mgifford | Drupal Security Guide
audio captcha ate my reply (THRICE!) [was re: clarfications]
i drafted what i considered a thoughtful, yet quick, reply to your comments, but my comment was identified as possible spam, so i was required to take a CAPTCHA test in order to authenticate my comment, but when i attempted to use the audio captcha, the page refreshed, completely wiping out the past 15-to-20 minutes of work i had put into my response...
i will return to reply in detail when the gods of computing smile upon me again -- right now, i'm being punished for using a proprietary operating system, user agent, and assistive technology, a not at all uncommon experience for those of us who still regularly end up as roadkill on the information superhighway...
my basic point in my disappearing post was that while this all may not matter from the content developer side, it certainly impacts anyone working on addressing core accessibility issues with the Drupal toolkit...
i cannot add a list of the resources to which i wanted to point you, as any attempt to do so on my part leads to a "CAPTCHA challange", which i cannot surmount...
comments on audio captcha:
1) when a user selects "play audio CAPTCHA", focus should be placed inside the input field into which the user has to type the CAPTCHA;
2) it is not clear if one is supposed to type in the alphabetic value for each enunciated mnemonic, or whether one is supposed to type in natural language phrases;
3) there is no explicit "submit" mechanism for the CAPTCHA challange; one should be added, otherwise, one gets into a loop between the CAPTCHA challange and the reply form's "Save" or "Preview" button; are the 2 submission mechanisms separate? if so, there needs to be an explicit CAPTCHA challange submission button
4) the audio captcha utiilizes a browser plug-in for control of playback of the audio captcha, yet such embedded controls are often inaccessible to users of assistive technology -- it would be better to have an actual form control that initiated a replay of the captcha
Trying to prevent road kill
Ya, the CAPTCHA here has been a problem here for a bunch of us. Particularly a problem for those using AT.
It hasn't caused me grief for a while, but not sure why that is.
In the Accessibility Statement Draft Wiki there is a section for each of the community sites. It would be important to have a public statement that the community can refer to when there are problems in the site like this.
I tried to trigger it and record mollom on a screen-cast, but can't seem to get it to kick in.
Ultimately it needs to be brought up here - http://groups.drupal.org/groups-drupal-org
--
OpenConcept | Twitter @mgifford | Drupal Security Guide