I am working on developing an accessibility checking module. Mostly this effort is to learn more about module development, but I am hoping that te module is helpful to others. The overview is that the module will provide a block with a list of links to good online accessibility testing sites. When a user clicks a link from any page on the site it will take them to the web-site of the testing tool they have selected. If the page being tested can be accessed by anonymous users then the report for the page should automatically be loaded, if the page cannot be accessed by anonymous users then they will be prompted to copy the page source for pasting into one of the tools.
Any suggestions or comments welcome, and I would love recommendations of good accessibility testing tools to include in the list.
Somewhat related, it is quite crazy how complicated it is to test a Drupal system path to determine if it can be accessed anonymously.
Comments
Not just a module, but education
Everett, I'm working on finding as many free accessibility checkers as I can and in a few minutes I'll finish a post pointing to them, but, as I've pointed out elsewhere, there are limits to what automated accessibility checkers can do. One glaring weakness is that they cannot be used to assess the accessibility of ARIA-based interfaces. Still, people learn to do at least some checking of their own work.
I started out trying to use automated checkers and found myself spending more time reading reports telling me to confirm whether images needed alternative text than it took to check the pages manually with tools such as WebAIM's WAVE and WAVE toolbar for Firefox. So rather than create what can be perceived as a crystal ball to tell you whether your site is accessible, I would rather we focus on teaching developers how much they need to test, how to test it, and where to go for more help or information when they need it.
For example, among the resources offered by Jim Thatcher on his site, JimThatcher.com, is an explanation of what can be tested. For each testable issue, Jim explains how much of that testing can be done automatically through some algorithm and how much requires human judgment. It's a good overview of the general problem.
Another of Jim's resources is a comparison of six commercial accessibility testing tools ranging in price from $69 to $1795. These commercial products should be better than what you can do for free, right? Some are, but not all. It's illuminating to read Jim's test and critique of their performance in assessing the accessibility of 70 html files.
Our educational materials can draw from and point to sources like WebAIM and Jim Thatcher's site. The right place for that content is the accessibility portion Drupal.org. Assuming you proceed with creating this module, the module should encourage people to get that education before doing any testing, or at least before interpreting the results of tests. And you probably should continue work on this module, because you are learning a lot, we probably need a proof of concept, and even if the ultimate result is a disproof of concept, the general approach can probably be extended to other kinds of performance testing.
508 Usability Testing: A Different Approach to Alt Tag Checking
In reading all the work that we are doing on the Alt Tag checking problem, another approach occurred to me that I wanted to suggest.
Instead of checking AFTER a site is built, why not do so AS THE SITE IS BUILT and AS CONTENT IS ADDED. If occured to me that given the structure of Drupal, there is one very easy way to do this.
Let's create a module (AltTagChecker) that when enabled, will NOT accept the upload of a graphic file UNLESS there is a non-blank Alt Tag entered as well. We could even allow the user to configure a minimal number of words (default at 2) that would be accepted.
This way the discipline can be imposed by the administrator on all the content contributors.
This does'nt solve ALL the accessability issues, but it does solve the one that accounts for the vast majority of the problems. It seems easy to do, but I am not a module developer. Any thoughts about this?
Sometimes the alt attribute is supposed to be blank!
When an image is not meaningful, or when it simply duplicates information already available in the text, it is at least acceptable and to many people preferable for that image to have an empty alt attribute.
Including the empty attribute (
alt="") is a signal that the developer or contributor did not forget about alt text, but they considered the image to convey no information not found elsewhere.That said, the best way to start an interminable discussion in the accessibility community is to mention a specific kind of image with a specific role — for example, my photo next to my name on this post — and ask whether alt text is necessary. The answers will be all over the map. It's a judgment call; each developer or contributor just needs to at least make an informed judgment.
Great question, @leigen! Thanks!
Many, Many Tools Available for WCAG
The W3C's Web Accessibility Initiative has a working group focused on accessibility checking tools. They have posted a complete list of all tools known to the WAI. Right off the bat, I know of at least two tools not on this list:
Still, a particularly neat thing about the WAI's complete list is that it includes checkers in many different languages. It also gives a description of and brief, but important, details on each tool listed — when it was last updated, whether it is based on WCAG 1.0 or WCAG 2.0, and so on.
I don't know of any online tools for checking against even version 1.0 of the Authoring Tool Accessibility Guidelines (ATAG), which in many ways will be more relevant to not only module developers but also developers of Drupal core. (My link here points to the version 2.0 draft because it is synched with WCAG 2.0, which is complete.)
For checking if an anonymous
For checking if an anonymous user has access to a node, you could try:
<?php$user = new stdClass();
$user->uid = 0;
$user->name = 'anonymous';
$user->roles = array(1 => 'anonymous');
node_access('view', $node, $user);
?>
This just creates an anonymous user and then tests whether or not they can view a particular node. Of course, if you have weird CCK content per-field permissions, what a logged in user would see is different than an anonymous user, but at least you can prevent 403s.
On another note, it would be great to support sensing the user agents of these tools and only render the page with the content wrapped in a plain html and body tag so users don't get false positives in the theme which authors have no control over.
But does that give access to admin views?
@kevee, Everett is trying to set up a way to use these online accessibility checkers to examine the administrative interface of a Drupal installation. Those checkers can participate only as anonymous users, so there is really no way for them to access that interface, right?
Correct, you would have to
Correct, you would have to give admin access to anonymous users in order for external checkers to see the admin interface (generally a Bad Idea).
This could be the time where I make a shameless plug for the Accessible Content module, which has a sub-module called Accessible Content Themer which does check the entire interface with a toggled on/off switch kinda like the Devel module's Themer functionality.
But if I wasn't making a shameless plug, I would recommend building some sort of bridge for an external site to test where, for example, you use an ob_start() at a hook_init() and an ob_get_flush() at the end to store the entire interface for an admin screen, then render it out for an anonymous user. This would make the UI look the same, but the form elements would stop working because they would no longer be tied to a FAPI key. Something like:
example.com/admin/build/modules => example.com/check/admin/build/modules
Which would then trigger off a call with no access check to build the module page and spit it out for an anonymous user.
Another option is to use the web service component of AChecker http://www.achecker.ca/checker/index.php to send content directly to the checker itself using a service call; however, I'm a little concerned about the long-term stability of that project seeing as the previous version just dropped out of sight and the current project is really slow.
Maybe it's time to revisit Accessible Content
@kevee, months ago I reviewed all modules and themes that seemed to be related to accessibility (as I recall, at least one or two that said they were actually turned out not to be), and about all I remember about Accessible Content at this point (pardon my laziness here, but my dog is really needing a walk) is that it seemed sound.
If you think it would address this problem, by all means let's go for it!
Yes, Accessible Content just
Yes, Accessible Content just went to Beta, but there hasn't been enough community feedback for me to be comfortable to roll out a full version release. Most of the issue queue has been really notes to myself, so I'm a little nervous about it. However, adoption has increased in the few weeks.
The slower end of the module is the QUAIL library, which is a big bear of a library. While old school DOM checks are all pretty complete, the CSS rendering model needed to check color contrast and layout is still only passing about 70% of W3Cs tests.
I think the module can go forward without this component of the library as content creators have less control over CSS; however, for themers and developers, color contrast info is very helpful.
Good point: One "size" does not fit all.
As you say, content creators have less control over CSS; themers have little if any control over content; module developers might have no control over either one, depending on what the module does.
Rather than one all-encompassing tool, should we build tools and support for folks to do their own tests? For example,
My point is that, rather than hit people with all aspects of accessibility, maybe our tools and support should help them figure out what's under their control in their current role and then check that. After all, I don't know if Cynthia Says still does this, but I quit using it after figuring out that most of what it was doing was to call things to my attention simply because someone needed to look at it to decide. There were three problems with that:
Don't we need to be sure that our tools and support don't give themers, developers, and content contributors similarly overwhelming and, to them in their specific role, useless bits of data?
And I'm not necessarily talking about Accessible Content, because I still haven't played with it in a while. I'm just thinking strategically.
Default role and overriding role
Ideally, the default check would be for things fixable by one's own role (content creator, themer, administrator, site developer, module developer), but that the user could override it to check the work of other roles or all roles.
What would be wonderful in terms of not overwhelming would be a way to check off that I had checked something needing human checking and not have it nag me again about that particular item as long as the content is not changed. (And what would be the scope of the content? The field containing whatever triggered the message? Or only the specific content triggering the message?) That, of course, would necessitate making entries in a database.
What would also be wonderful in those terms would be being able to make content or theme edits while viewing the accessibliity check messages.
Alas, those last two paragraphs might be requesting luxury items that make the module unfeasible.
Charles Belov
Webmaster
San Francisco Municipal Transportation Agency (SFMTA)
On the issue of not having to
On the issue of not having to revisit the same string - the way I did it in Accessible Content is that the override is stored not as "test 1 is overriden on this page" but instead I made a MD5 hash of the actual code that generated the error and store that for the future. This ensures that only once that piece of text changes would it require another manual review.
On making theme edits - I think the answer would be to use a tool along with the Devel themer (total inaccessible, I know) module to see where the problem is.
Clarification
Wow, a lot of good discussion here, thanks.
Just to clarify, I really don't see this module as being incredibly useful to people who really are committed to accessibility. I much prefer the Accessible Content module approach (still haven't tested it). But, I think that this is some pretty low hanging fruit that may be used by some to get a sense, or introduction, to what accessibility is all about. I would envision this module as the two bedroom starter home that admins can enable while they are considering moving into the Accessible Content module mansion ;)
Accessibility Consultant & Web Developer - Zufelt.ca
@ezufelt on Twitter | LinkedIn profile
OK, now I get the
OK, now I get the scope!
Well, perhaps then it should be a collection of both resources and some stuff built upon the Advanced Help module. You know, some best practices, guidelines, etc. Also, you could have the block do contextual stuff like see if a form is set on the page show links to resources or help pages about accessible forms, while a regular node page would be more tuned towards writing and creating content for accessibility.
Now *that* would be cool!
That's a great idea, @kevee. If I understand you correctly, it would make the module a sort of instant search utility for directly related documentation we will have created to support accessibility. That would really be powerful!
In other words, we would be doing what is usually done not very well when the topic accessibility: Offering instructions at the point of need. In my experience, when we can do that, we help people understand how easy it is to take many of the steps that provide basic accessibility.
Accessible Helper Module
If I can help at all, let me know. I am happy to look at the module and suggest approaches. Or if you have certain things you want to do, I can skeleton out the code. I have more experience with drupal coding, than accessiblilty work.
If it can be integrated into the accessibility helper module (http://drupal.org/project/accessible) that is fine also. The module isn't doing much.
Kat3 had a patch for it to leverage hook_help and reference standards. I never got around to adding the patch, but will get it in there soon. Here is her patch:
http://drupal.org/files/issues/accessible-369477-1.patch
The feature queue is where I thought the module might go:
http://drupal.org/project/issues/accessible?categories=All
regarding anonymous paths. You might simply use the php curl library to check for anonymous access to a page. It will either get a header giving errors or page not founds; or get the content that is available. That is you can see not only what pages are available, but which blocks and node content on those page are available...though you won't be able to discern which blocks or nodes they are.
www.johnbarclay.com