Note: The video/audio of this presentation is now available thanks to Patricia Shaver from the University of Guelph.

I took a great opportunity to go to Guelph to both participate in and present to the 2011 Accessibility Conference. I was able to meet with a number of great accessibility professionals from Southern Ontario who were gathered for this event at the University of Guelph.  I missed the A11yCamp which Sean Yo organized and also to Derek Featherstone's HTML5/CSS3 training, but sent two of my team to it.

In thinking about what to present to this audience I had rethink a few things.  In presenting to Drupal audiences I had to go into depth about accessibility and work to educate the audience about the various ways that their sites are perceived & operated.  Many of the people in the audience had more experience in this area than I did so this wouldn't have been much of a benefit.  There were a surprising number of Drupal people in attendance as many universities in Ontario are now using it as their default CMS.  That being said, I didn't feel that there would be enough to justify a talk focusing on this one system.  

I decided to focus the presentation what can be learned from Drupal that can be applied to any system.  There are best practices in accessibility that have been defined in Drupal and that I do hope are adopted by other systems.  I figured it would be worth pulling out some of the highlights from Drupal 7's enhancements that I think still stand as best practices and that are generic enough that they could be emulated by others.  I wanted to use this session to talk about ways the ways that with greater collaboration we could take and improve these best practices for all systems.

I was hoping that the video would be available online right now, but for now I'll summarize my presentation notes & provide a link to the slides.

{C}

There's just so much great stuff going on with modern browsers, mobile devices and HTML5, so how does the Drupal community our our best to help innovation by encouraging IE6 users to upgrade to a modern browsing experience.  Now Drupal 7 (core) is still will be providing support for IE6, but we really don't want to have to support it for Drupal 8 (which could well be released before IE6 is finally laid to rest by Microsoft).   I've written a short note that we're using for our visitors to give them the tools that they need to finally make the move.  However, I thought I should document a nice way to do this in Drupal 7.  Much of this will be the same for Drupal 6.

Now there are ways to do browser detection with jQuery or other tools, but for Drupal 7 the easiest way seems to be to add a conditional CSS file to the header through the template.php file. The conditional statements work fine for IE 6 & 7, so they do the trick nicely:

I just updated the docs on drupal.org and discovered that D7 will take care of the permissions.

I was working on my first Drupal 5 to 7 migration earlier today and ran into an issue with the file system I hadn't needed to define previously. Drupal 7 has both a public and private file system path that you can define. This is great for security as you can easily divide what files you want available to the anonymous public and which they should be denied access. Drupal can be used to control delivery to users with appropriate permissions.

This is great, but there aren't enough active descriptions out there of how to do this yet. The DrupalHandbook of the Drupal 7 File System is pretty clear, "Files in the private directory are not accessible directly through the web server; when private files are listed, the links are Drupal path requests," is pretty clear, but doesn't provide a practical example.

I posed the question on Twitter, "if a Drupal 7's root is /home/drupal & the public files are in /home/drupal/sites/example.com/files where should the Private file system path be?" Following up by stating that from purely a backup perspective it would be nice if all client files were just in /home/drupal/sites/example.com/private and Apache is used to exclude access.

Following my previous post with examples about using invisible elements, this post includes further examples of how to use the template.php file to overwrite Drupal 6's default functions for greater accessibility. More details on how to use these functions are available from Drupal's documentation.

With many sites, the only forms that they have available is the search function. This is a more accessible rewrite of template_preprocess_search_result()

 function EXAMPLE_preprocess_search_result(&$variables) { $result = $variables['result']; $variables['url'] = check_url($result['link']); $variables['title'] = check_plain($result['title']); $info = array(); if (!empty($result['date'])) { $info['date'] = format_date($result['date'], 'small'); } if (isset($result['extra']) && is_array($result['extra'])) { $info = array_merge($info, $result['extra']); } // Check for existence. User search does not include snippets. $variables['snippet'] = isset($result['snippet']) ? $result['snippet'] : ''; // Provide separated and grouped meta information.. $variables['info_split'] = $info; $variables['info'] = implode(' - ', $info); // Provide alternate search result template. $variables['template_files'][] = 'search-result-'. $variables['type']; }