Add accessibility information to Theming Guide

Lee, I'm working on it, I have some stuff prepared, just finding time to get it sorted and reviewed by at least on external reviewer (a field expert).

I'll cross post to accessibility group on gdo and see if we can get something more going, agreed its important to be looking forward.

We have this page as a guide in the getting started section:

Accessibility and Drupal- http://drupal.org/node/394094

Cross posted to the accessibility group for discussion - http://groups.drupal.org/node/22226

I'll be glad to review/contribute on this as well. I'm currently contributing on the Accessible Helper Module which seems to go along well with this: http://drupal.org/project/accessible

Also posted expressing interest in the Accessibility Group discussion regarding this:
http://groups.drupal.org/node/22226#comment-76874

Great to see the quick responses here. I'm just subscribing mostly, but think that there is a great opportunity to educate people about accessibility issues in the theme that this documentation initiative will help with.

I have made start (quite a big start actually).

http://drupal.org/node/464472

There are four three stub pages (not good I know...):

# Images and Media
# Color and Contrast
# Fonts
# JavaScript and AJAX

I can work on the Fonts page but it would be great is someone could step and do the others, especially the JavaScript page. I'll crack on with all of it but please claim these pages if you have time.

@Lee, I have some reservations about the other content in the Tools, Best Practices section, some of them are out of place:

# Theming the Drupal 6 maintenance page
# Adding your theme to Drupal.org
# Creating a screenshot for the administration page

Two of those should probably be moved to the Contributed Themes section and "Theming the Drupal 6 maintenance page" should be moved to "Theme HowTos".

I realise this is separate issue, can we do it or is this subject to the IA review?

Ok, this is a very impressive start! I've found a few places to insert more information, but you've presented this in a very good manner!

I can't edit this page - http://drupal.org/node/464494 - but just wanted to add that Juicy Studio Accessibility Toolbar was a Firefox plugin. It might also be useful to mention Fangs as a JAWS emulator - http://www.standards-schmandards.com/projects/fangs/

Wondered on the Semantics page - http://drupal.org/node/464802 - if it might make sense to talk a bit about the content, even though it isn't really a theme level issue. There are module level changes where some of the content can be evaluated and then there are user level issues where really you need to have people learn to write better, see http://www.plainlanguage.gov/

It's not tied to theming though, but perhaps it could be elsewhere. So much of the WCAG 2.0 requirements are about content though and not really on the CMS layer. But then what you do to check that content can be controlled a lot too - http://groups.drupal.org/node/22278

I do wonder about the need to highlight the theming elements of Accessibility 11 Point Checklist. 4. Ensure links make sense out of context, 7. Allow users to skip repetitive elements on the page, 8. Do not rely on color alone to convey meaning, 10. Make JavaScript accessible, & 11. Design to standards, are all very closely tied to theming, but not the others. Not that the whole list shouldn't be presented, but wonder how to highlight what it is that the person designing the theme can do if they aren't the same person writing the content.

I'll try to add more to the stubs you've inserted, but you've set the bar pretty high. Thanks!

Ok, Fangs should be added, and probably NVDA as well, and link to the tutorial mentioned here http://groups.drupal.org/node/21860

I'm not sure about adding information on content, if it can be somehow tied to theming that thats better certainly, however if its an accessibility issue then slipping something in doesn't hurt in my opinion.

Regarding the 11 point checklist. Actually most of theme are tied to theming in one way or another:

1. Provide alternative text
Drupal can add and remove attributes anywhere, for example using jQuery. I also wanted to make the point that repetitive alt text on decorative images such as list bullets was not a good idea.

2. Provide headings for data tables
I was thinking along the lines that tables can be generated via the Views module, and the output can be overridden. I should be possible to add captions to views-view-grid.tpl.php. Certainly I can generate tables using a function in template.php, so in many ways this is tied very closely with the theme layer.

3. Ensure users can complete and submit all forms
hook_form_alter is one way to change forms, however its entirely possible to use hook_theme in template.php. Of course we have the jQuery factor as well.

9. Make sure content is clearly written and easy to read
This is about fonts and font sizing.

5 and 6 were added more for completedness and are really "accessibility trojan horses", meaning if this is the only document someone ever reads on accessibility better get the information to them now:)

There's so much that can be ultimately controlled with enough PHP in the theme layer if you needed to. Not that it's the right layer to deal with things, but it's possible. I just wanted to make sure that if there is some way to highlight the stuff that themers are particularly responsible for, we should do that. I don't think there's anything you've written I'd remove.

I added a basic Color Contrast page and also one for Images & Media. They do still need a lot of work, but there's a bit more of a structure to fill out now.

I do like your examples above for the 11 point checklist. Makes more sense. They should probably be worked into the page.

Looking good Mike, good information there in the pages you added. I'll try to work those examples into the Checklist, hopefully have some time this weekend although the Drupalcamp Copenhagen is this weekend so we'll see ;)

I added some content on the "Audio & Video" section. I'll add some to the "Interactive" section and the "Color and Contrast" section as well.

Thanks! I do think it's coming along now. Javascript & AJAX is the only one that remains a stub at this point.

sub

Jeff, I can't believe I haven't looked at this before. Tonight I had time to go only as far as the page on Navigation, but I am highly impressed with what I have read so far. A few small points:

• The section on meaningful link text (http://drupal.org/node/464492#meaningful-link-text) oversimplifies the situation. In particular, the automatically generated links on many Drupal pages — "Read more"; "11 comments"; and so forth — are not a problem for anyone who uses the page structure for navigation. (This point is under discussion in the Accessibility forum.) My concern is that the current wording might get some themers to try to fix problems that don't really exist, and those "fixes" might actually add new, real problems.
• I would like to revise the section about accessibility "validators" (http://drupal.org/node/464494#accessibility-validation). They're actually evaluation tools, not validators. The difference is important. A validator can affirm that a page is accessible. An evaluation tool can only say, "This page has none of the accessibility problems I am able to identify." Because of the nature of accessibility issues, it's impossible to develop a validator. So my revisions would be to change the heading for that section to "Accessibility Evaluation Tools," change the page title to "Validation and Evaluation," rewrite the introduction accordingly, and add a sentence after the list of tools to point out that they cannot confirm that a page is accessible — they can only confirm that, if there is a barrier to accessibility, they have not been able to find it.
• Finally, at least so far as I have read, we seem to be addressing accessibility from the standpoint of visual disability only. That is important, but mobility impairment and cognitive disabilities are also to be considered when evaluating accessibility. I don't have well-formed thoughts on this right now, but it seems to me that a theme might trigger issues for either or both of those. I'll continue reading your fine work as I have time and will see if I can develop something on these points.

These are really small problems compared to the great strides you have made to put accessibility before themers in an understandable way. Great job!

--Cliff

Go for it Cliff, I agree with all points you have made.

I've been following the discussions in the Accessibility forum, although not engaging due to time constraints and I think you have made compelling arguments in http://groups.drupal.org/node/17627

I too balked at calling them validation tools, but at the time I suppose I was in the flow of writing and didn't revise it, so yes, go for it and change that page.

On the 3rd point, well I have very aware of this also, especially since the whole reason I got interested in Accessibility is my association with a disabled user who is not blind but rather has CP and cannot control the use of her hands, so she uses a head prong. We do need to address this, something we all need to think about and contribute towards.

@jmburnz

In another issue it was suggested that we add more to the Theming Guide about proper use of headings and about when it is appropriate to hide information.

Please review this draft contribution:
http://ojctech.com/blog/headings-and-visibility-drupal-theming-guide

Unless you or others have concerns or suggest an alternative, I will go ahead and work this material into the sections on Heading Structure and Hiding Content. I'm thinking I might pull the Heading information into its own page since it's a lot to squeeze into the Structure page.

I'd appreciate any input and direction.

@brandonojc

I would put the actual CSS for the various classes in the article, and make it clear those classes are Drupal 7 and you will need to copy/paste the CSS to your theme or module if using Drupal 6.

I would put everything about hiding headings in one section, and everything about using display:none in its own section, at the moment its spread throughout the document which means mental effort to carry concepts from one section to another.

We should get the text pretty good before creating or changing any pages, because someone with the right permissions will need to add the video and that will cut me out from any changes and many others - actually I think it might be better to link to the video rather than embedding it, so others can make changes without having to through a Drupal webmaster.

Good work!

@jmburnz

Thanks for the feedback! I'll cook up a revised version....

Jeff, I have some new thoughts on improving the Color and Contrast page. I won't elaborate here, but check the revision notes and you'll see where I'm headed. I've mentioned this to Mike, but I can't believe the cases of poor contrast in Drupal themes. For example, in Drupal Gardens (http://drupalgardens.com/) the color contrast between the blue of "Drupal Gardens" and the sky behind the words is only 2.0:1. And the contrast of "Follow us on Twitter" to the grass behind the words is better, but still not good enough: 2.5:1.

Anyway, I hope to have the new content in place by early next week.