UPDATE: I started at http://drupal.org/project/accessible - Johnbarclay
I use a simple little module I wrote called accessibile to help with accessibility. I'm attaching it and looking for feedback on the general approach as well as the details of it. Here is the gist of the module:
==================================================
This is a helper module to make creating accessible websites easier. It is intended to:
- add functionality to allow authors to class block headings as "offscreen"
- fix accessibility issues in other modules via hooks. the sole example included is google_cse module
The method of the module is to try to fix as many accessiblilty issues as possible within the module,
so the work doesn't have to be done over and over again in the theming layer.
Ultimately these fixes should be integrated into core or other modules, so this module will have a moving
target.
Much of accessiblity is on the theming layer, so example .tpl and template.php overrides
are included in the examples section.
The tool I use to test for accessiblity is the functional accessibility evaluator
===================================================
The module is at:
http://staff.ed.uiuc.edu/jbarclay/accessible/accessible.zip
I use the module along with some fck editor tweaks. I'll post the talk I gave recently on this also as I'm looking for feedback on those fck tweaks also.
Comments
Interesting Initiative
Thanks for this John. Ok, I'm game, I've installed your module.
Would be great to see this up on Drupal.org as an official project. It's also listed in the group - College of Education - when it should be probably in one on Accessibility.
I was trying to understand the nature of the changes you were making to garland so I did a diff, but would be great if you had a proper patch that we could compare with the existing site. Spaces are off so it doesn't quite work:
mike@dev:~/dm6/sites/all/modules/accessible/examples/garland$ diff -b /home/dm6/themes/garland/block.tpl.php block.tpl.php2a3
> // modified from original garland drupal 6 block.tpl.php
5,7c6,7
<
< <?php if (!empty($block->subject)): ?>
< <h2><?php print $block->subject ?></h2>
---
> <?php if (!empty($block->subject) && $block->module != 'menu'): ?>
> <h2 <?php if ($block->offscreen){ print 'class="offscreen"';}?>><?php print $block->subject ?></h2>
10c10,12
< <div class="content"><?php print $block->content ?></div>
---
> <div class="content"><?php if ($block->module == 'menu' && !empty($block->subject)): ?>
> <h2 <?php if ($block->offscreen){ print 'class="offscreen"';}?> ><?php print $block->subject ?></h2>
> <?php endif;?><?php print $block->content ?></div>
mike@dev:~/dm6/sites/all/modules/accessible/examples/garland$ diff -b /home/dm6/themes/garland/page.tpl.php page.tpl.php
15c15
< <body<?php print phptemplate_body_class($left, $right); ?>>
---
> <body<?php print phptemplate_body_class($left, $right); ?>">
41c41
< print '<h1><a href="'. check_url($front_page) .'" title="'. $site_title .'">';
---
> print '<div id="sitename"><a href="'. check_url($front_page) .'" title="'. $site_title .'">';
45c45
< print $site_html .'</a></h1>';
---
> print $site_html .'</a></div>';
70c70
< <?php if ($title): print '<h2'. ($tabs ? ' class="with-tabs"' : '') .'>'. $title .'</h2>'; endif; ?>
---
> <?php print '<h1'. ($tabs ? ' class="with-tabs"' : '') .'>'; if($title) {print $title;} else {print $head_title;} print '</h1>'; ?>
Most of the changes seem to be about hiding the titles for the blocks with CSS.
In looking at your example I decided to extend my testing of Drupal 6 themes by applying the FAE & WAVE tests. Ran into a best practice that Drupal isn't following around lists and navigation headers:
Note: Navigation menus should be preceded by headings of the appropriate level (usually
<h2>).Not sure if this is still the case or not.
Thanks for posting this!
OpenConcept | CLF 2.0 | Podcasting
--
OpenConcept | Twitter @mgifford | Drupal Security Guide
Thanks
Just looking for more feedback at this point. If it shapes up and there is interest I'll get it in CVS. I'll need some co-maintainers and a sense of interest because the module won't be too useful unless there are examples of its implementation in the .tpl files
I found the same problem with the built in search form as with the google_cse. In the next zip, I'll add that in. Basically its the same fix as the google_cse fix.
I'll take the College of Education group out and add diffs to the examples part in the next phase.
Just pull that whole line out of the .info file or replace it with
package = AccessibilityYeah most of the fixes are around headers. Below is a more readable summary of the .tpl changes. These are primarily in the theming layer, but the module adds a column to the blocks table and add a checkbox on the block form. These two changes and the additional css allow the author to position the header off screen. I need to add some t() functions in for translations in the code below.
block.tpl.php
- added check for offscreen css enabled by accessibility module
- put h2s directly above menus (after block div)
<div id="block-<?php print $block->module .'-'. $block->delta; ?>" class="clear-block block block-<?php print $block->module ?>">
<?php if (!empty($block->subject) && $block->module != 'menu'): ?>
<h2 <?php if ($block->offscreen){ print 'class="offscreen"';}?>><?php print $block->subject ?></h2>
<?php endif;?>
<div class="content"><?php if ($block->module == 'menu' && !empty($block->subject)): ?>
<h2 <?php if ($block->offscreen){ print 'class="offscreen"';}?> ><?php print $block->subject ?></h2>
<?php endif;?><?php print $block->content ?></div>
</div>
node.tpl.php
put some h2s in:
line 9:<h2><a href="<?php print $node_url ?>" title="<?php print $title ?>"><?php print $title ?></a></h2>
line 23:
<div class="terms"><h2 class="offscreen">related terms</h2><?php print $terms; ?></div>
line 28
<div class="links"><h2 class="offscreen">related pages</h2><?php print $links; ?></div>
page.tpl.php
line 41 print '<h2><a href="'. check_url($front_page) .'" title="'. $site_title .'">';line 45 print $site_html .'</a></h2>';
line 71 <?php if ($title): print '<h2'. ($tabs ? ' class="with-tabs"' : '') .'>'. $title .'</h2>'; endif; ?>
I could see the need for h2s on the next 2 lines also, but haven't tested a page with tabs:
<?php if ($tabs): print '<h2 class="offscreen">'. t('Primary Tasks') .'</h2><ul class="tabs primary">'. $tabs .'</ul></div>'; endif; ?><?php if ($tabs2): print ' <h2 class="offscreen">'. t('Secondary Tasks') .'</h2><ul class="tabs secondary">'. $tabs2 .'</ul>'; endif; ?>
www.johnbarclay.com
For those stumbling across
For those stumbling across the discussion and wondering where the tabs theme is: theme_menu_local_tasks
Lobby for Change Within Modules/Themes
I'm of the perspective that it's better to lobby for overall enhancements in the project than it is to set up a new module that overwrites the accessibility shortfalls within Drupal, it's contributed modules and themes. We need to know that the Drupal community is working to raise the bar of modules and themes that are available to the community. W3C Validation is a simple enough goal for any theme and one that everyone should support, but it isn't something we always test for.
I'm not exactly sure how to deal with the blocks. I do wonder if there might be some other way to approach it though. Something whereby if the 'Block title' is blank that the 'Block description' is displayed, but hidden. That would probably result in a number of problems though. I thought that your module would allow me to see the checkbox on the block list, but after configuring the block I can see it within the 'User specific visibility settings' grouping. Not sure what the most elegant way to do this is.
Would make sense to put the hidden
<h2>'s in by default into the themes provided in Drupal 7's page.tpl.php & node.tpl.php. Can you give me some more solid links about the rationale for doing this? I've run into it from the University of Illinois' Functional Accessibility Evaluator, but not really sure where this recommendation comes from or what type of improvements it will give to screen readers. Right now it just appears as a warning, not an error.The question here is how do we establish this as a best practice within Drupal? I'd like to see some standardized way to hide content through css. A class="offscreen" or class="hide" would be nice. Could use it to hide other elements too.
Mike
OpenConcept | CLF 2.0 | Government
--
OpenConcept | Twitter @mgifford | Drupal Security Guide
Agree on lobbying for change in modules and themes
The main rationale for the offscreen classing is for elements who's function is obvious in a visual context. A long list of links visually appears to be navigation. But to screen reader it may not be obvious. And the headings are needed for header navigation.
The headings are part of all the accessibility guidelines. Allowing authors to hide them in certain situations is an accomodation of designers/authors who don't like the look of them...so I don't know where to offer them.
Drupal 7.
I don't expect any changes in themes in D6. Most changes would break people's aesthetics. So for D6 a clone of Garland or other core themes that was accessible would be helpful to current users and maybe would get into D7 as a D7 theme. I haven't worked with D7 yet.
I think the ability to class something as offscreen needs to be in the block forms. It could be done with an optional core module that could be turned off.
There should only be 1 h1 tag on a page, and the next set of h tags should be h2s. This is problematic in some themes.
Aria stuff is pretty far along (http://test.cita.uiuc.edu/aria/) and could inform D7.
I like offscreen, rather than hidden because in css hidden and none are different than positioning offscreen and neither is appropriate for screen readers.
Here are my references in general:
http://html.cita.uiuc.edu/
http://www.dhs.state.il.us/IITAA/IITAAWebImplementationGuidelines.html
http://www.w3.org/TR/WAI-WEBCONTENT/
www.johnbarclay.com
Small Patch Submitted
Realize that your module is more than this, but I've submitted a patch to Garland, based on this thread.
I focused on adding the H2's and offscreen css. It makes sense to me that there'd be 1 H1 & multiple other headings, but think that's for another patch. Really should begin a discussion about this outside of the Accessibility group with the best practices theming folks. The recent Semantic theme guide page here looks good.
Accessibility guidelines probably should be based on WCAG 2.0 since it's been finalized. I found some references that are reasonable. Not sure how far outside of Illinois the other criterion goes. You've introduced me to a lot of this which I hadn't really stumbled upon before. It looks good.
Generally patches are submitted to the next version of Drupal. Getting these changes in core will serve as a strong model for the rest of the community. If there are just a few marginalized themes which have accessibility as a priority, then never going to be the default. I haven't proposed any aesthetic changes to Garland at this point. Although H1 -> H2 would affect folks' modifications for sure.
From your ARIA link, there's the A List Apart article on Accessible Web 2.0 Applications.
Mike
OpenConcept | CLF 2.0 | Podcasting
--
OpenConcept | Twitter @mgifford | Drupal Security Guide
Thanks. Will include diffs in the future
Thanks. I'll inlcude diffs in any themes I have in the examples page in the future both to make proposing patches to core and understanding the differences.
www.johnbarclay.com
+1 on Patches
Always good if there is an accessibility change that we want to promote if we can demonstrate that by +1ing it.
I'd really like to see some other feedback from others interested in Accessibility about these changes. There are 198 members in this group, would be good to have a few more view points on the implications of these changes.
Mike
OpenConcept | CLF 2.0 | Podcasting
--
OpenConcept | Twitter @mgifford | Drupal Security Guide
How do we want this to be displayed?
There's a thread here on H1 tags we should be looking at a bit more:
http://drupal.org/node/169912#comment-1361936
Would be nice to provide a diff of what we'd want. Anyone up for the job? Any sample code we'd like to offer up? I've got the latest running in my D7 accessibility sandbox if folks want to check it out. (Just email me if you need the URL).
Mike
OpenConcept | CLF 2.0 | Podcasting
--
OpenConcept | Twitter @mgifford | Drupal Security Guide
http://drupal.org/project/accessible
I started the module page at:
http://drupal.org/project/accessible
www.johnbarclay.com
Thanks!
Good to see it there John!
OpenConcept | CLF 2.0 | Podcasting
--
OpenConcept | Twitter @mgifford | Drupal Security Guide
ARIA and Drupal
Hi John and Mike,
I just want ot echo the thoughts on ARIA. ARIA is very nearly a standard (just coming up to last call) and it would be magic when combined with the quality of the Drupal core. For more have a look at the following, especially CodeTalks which is one of the best resources on WAI ARIA on the web.
Cheers
Josh
[1] http://codetalks.org/
[2] http://www.w3.org/TR/wai-aria/
Best Practices and Coding Standards
I agree, for this to get anywhere, we are going to need implementation best practices and coding standards, rather than discussion on what are best practices are. Not only are the discussion time consuming, but they don't hold much weight when proposing patches to core. And inconistent best practices works against accessibility.
I would suggest using the following 3 rulesets as a starting point of reference.
w3c validation
ARIA: http://www.w3.org/TR/wai-aria-practices/
CITA HTML Best Practices: http://html.cita.uiuc.edu/ ( or another best practices for html. I like this one because it has a helpful testing tool with it... http://fae.cita.illinois.edu)
I'm going to start referencing these 2 in any code/documentation in the accessibility module I'm working on.
http://test.cita.uiuc.edu/aria/
http://www.w3.org/TR/xhtml2/mod-roleAttribute.html
www.johnbarclay.com