Drupal

Recognia provides technical analysis products (interpreted chart recognition) to large brokerage firms worldwide. They help the brokerage firms attract, retain and engage traders by providing actionable research tools. 

Recognia came to OpenConcept because they were trying to enhance their web presence with a new website that is more engaging to users, clearly defines the company mandate and product offerings and enables their internal team to take control of content entry.

Yesterday was the third Drupal 7 accessibility taskforce meeting, and the final meeting before code freeze. With September 1 just around the corner the Drupal accessibility community would like to reach out the the broader community for some additional help during this busy time to get as many accessibility improvements into Drupal 7 core as possible.

Introduction

I have been encouraged by the increased participation in the Drupal 7 accessibility issue queue in the past few weeks. There are still a number of outstanding issues that are fundamental to improving the accessibility of Drupal 7. Some of these issues can be dealt with after code freeze, others need to be dealt with before.

I believe that Drupal accessibility has to be adopted and fostered at the grassroots level.  Hopefully after code freeze some additional accessibility documentation can be added to Drupal.org and the documentation that is currently on the site can be reordered to make it more useful.  I believe that clear and thorough documentation will lower the barrier for entry into the Drupal accessibility arena, making it easier for community members to get involved who currently don't know where to start.

This morning I had the opportunity to evaluate the accessibility of the d7ux administration theme (Information Architecture) "Seven". My evaluation was not intended to be thorough, or to identify every web accessibility conformance problem, but to get a feel for what the theme will be like for screen-reader users, and what broad accessibility issues need to be addressed.

I must say that from the perspective of a Drupal administrator and screen-reader user that I believe that the theme will be seen as a useful and welcome addition to Drupal 7 by many users. Although there are clearly many accessibility issues to tidy up before Seven is truly accessible, I was surprised at how easy it was to get accustomed to using the iframe "Overlay" panel which appears at the bottom of the page, (if navigated in DOM order).

We use multi-site installations pretty much exclusively. Moving sites around (from development to production, say) can be a pain, especially when there are a large number of modules in sites/all/modules, relatively few of which are used by a given subsite.

I recently turned my hand to using drush to pick out just the enabled modules for a given subsite to make for easy migration. This is my proof of concept script; there is lots of room for improvement.

Recognizing the need to unify the presentation of governmental information on the web, the Government of Canada has developed CLF 2.0 (Common Look and Feel for the Internet 2.0). Part 2 of CLF 2.0 is the Standard on the Accessibility, Interoperability and Usability of Web Sites. The context for the CLF accessibility standard is that:

Canadians have the right to obtain information and services from Government of Canada Web sites regardless of the technologies they use. The key to effective implementation of universal accessibility lies in designing sites to serve the widest possible audience and the broadest possible range of hardware and software platforms, from adaptive technologies to emerging technologies. (CLF 2.0 Part 2)

This code is now dated because of a release of Nodewords which includes DublinCore Metadata. It's also worth reviewing Smiffy's article on Extensible Metadata for Your CMS

We've been doing a lot of work recently about the Common Look and Feel for the federal government here in Canada.  One of the requirements of the CLF has been that documents are created with Dublin Core meta data to allow for it to be more machine readable.  This is a great step, and it is nice to be working with an international standard like this.  Unfortunately, there didn't seem to be any easy way to produce this meta data with existing modules.

Several people have started developing Dublin Core modules in the Drupal community, but none have finished it.  The Meta tags module probably comes the closest as it is designed to produce meta tags for search engine optimization.   Unfortunately extending the Meta tag output to allow for a much wider range values isn't presently allowed. 

I think there are a number of ways that Drupal 7 could be much more accessible out of the box than it is right now. I've spent a bit of time working on a few items to improve and document some accessibility enhancements. Spent some time going through WCAG 2.0 documentation & comparing it with Drupal Core. And have been making patches and proposing best practices enhancements for a number of projects.

I'm definitely much more of a PHP/MySQL developer, but the complexity of finding a neat solution that works for SEO, across all major browsers, and also with several screen readers is pretty intense.  Since more and more websites are needing to comply with accessibility regulations this is going to be a larger problem for all of us.  Having a few good best practices outlined and tested in Drupal core will help all of us just implement more accessible websites by default.

OpenConcept is a Silver sponsor for FLOSS Summer Camp 2009 and will be presenting on accessibility issues and getting open source into Government. There are some other great speakers too, so please consider signing up.

The sessions I've proposed are:

Getting open source in Government (focusing on LAMP + Drupal)

 

Setting up the CiviMail return channel is a notorious pain in the ass. The return channel is the mechanism by which email is passed back into the CiviMail system. It's necessary to allow replies and bounces to be handled by CiviCRM, making it fairly essential to the successful use of CiviMail.

The official way of setting things up is unfortunate in a couple of respects: it requires the installation of a customized version of the amavisd-new content-filtering daemon*, and it cannot handle multi-site installs. The "alternative" return channel implementation, although rumoured to not scale as well, requires no additional software, and can be easily adapted for servers hosting multiple domains that use CiviMail.