Like many government agencies, the Government of Canada has a mandate to address accessibility issues. The Common Look & Feel presently is based on the 1999 accessibility standard WCAG 1.0 and will shortly require WCAG 2.0 compliance.  This falls within the Management Accountability Framework, which is an incentive based system for management. Internal audits are presently being used to evaluate accessibility improvements over time. 

As I noted in my last blog Accessibility Tips for Management even with this regulation, how is management supposed to know when their site is accessible or not.  Despite the Donna Jodhan ruling of 2010, I do not think that there is a clear sense from within management of how accessible their present sites are.

I decided to go through some government departments to look for accessibility problems.  Now there are over 100 Government of Canada departments and I didn't have the time to approach this in a very scientific way, but I was able to easily see that there is a great deal of work that still needs to be done on accessibility in the federal government.  As per my blog post I used the WAVE Toolbar to run through a quick analysis of knowable problems.  

{C}

No automated tool can tell you that your site is accessible or not.  However, if an automated tool tells you that there are accessibility problems, it's most often the case.  These tools continue to improve, but they must be used in conjunction with awareness of the Web Accessibility Initiative's standards and with user testing.  

Unfortunately, most sites that I tested had accessibility problems.  It was predictable to find the problematic areas of most of the websites, so I was able to find errors quite quickly in most.  I'm going to summarize some of the common problems that I ran into and would encourage people to add to this list.

Search Forms

I found that I could almost always find problems with the search forms.  WCAG 2.0 requires that every input form has an associated labels or titles it was really surprising how few did.  Now whether this is a barrier to accessibility is another issue, if you've already clicked on a search link, you'd expect if there was only one form on a page that it would be the search box even if there was no other indication that this was the case.  However, why not just do HTML forms right and meet the requirements checklist?

Having a blank label doesn't count either. The labels must be meaningful (like alt texts) on images. The automated tools can tell you if there is blank text, but it often cant find if a developer has inserted a useless label.  There are several central search engines that the Government of Canada uses and these should be given extra attention for accessibility.  In the departments that directed me to another site for search, I didn't find that it was any better and was also surprised that there was no way to easily go back to where I was. This is just a basic usability issue.

If the main search form on a page didn't raise problems it was very common that the advanced search did.  Sometimes departments brought the search bar onto a sidebar so that it was easier for folks to access, this was also usually poorly implemented.  

Broken Skip Link

Skip links are added to ensure that keyboard only users can skip past the navigation of a site easily & early in the process of tabbing through a site's links.  Given that many sites may have dozens of links before a user gets down to the main content of a site, this is an important feature in an accessible site.  In my understanding I think that many theme developers just take a template (like the one provided by Treasury Board) and then hack at it to fit their needs.  Quite often they left the hidden links from the header but didn't check to see that they were actually paired with an anchor in the body of the site.  This breaks accessibility for keyboard only users, I don't know if there's a WCAG 2.0 guideline on this, but it's just bad form.  

WAVE highlighted a surprising number of sites that had broken skip links.  

Heading Tags

Screen reader users often navigate websites using the document structure provided by the HTML heading tags.  Although there is some disagreement within the accessibility community about how to best apply this, everyone agrees that every page needs to have a H1 tag associated with it.  That heading tag can be made made invisible if it shouldn't be displayed to a user, but it really needs to be visible to screen reader users.  With adoption of WAI-ARIA, headings will be less important for accessibility because there will be more accurate ways to provide that navigational information.  However, a clear document structure will still be important for search engines & other machines.

Images Need Alt Text

This is the most basic element of most accessibility efforts and yet I found government websites where images were without alt text.  More commonly I found images where spaces were used or useless descriptions like "image" or "alt" neither of which add any value.  Images often should be updated to highlight new content on a site or help make it more engaging to it's users.  However, any user generated content can affect a site's accessibility.  Having simple systems in place to double check a site after new content has been added can help a great deal.  These can be as simple as making sure that on a monthly basis web development teams are using a tool like the Functional Accessibility Evaluator to look for things that might have been missed.  It could also mean that if teams are using a Content Management System to update a site's content, that it be incorporated with a system like quail-lib that can run some automated tests on content before it is published.  Accessibility efforts should add context & value to your site making your site richer for everyone. 

Miscellaneous Issues

• There are times that it is appropriate to hide content with display:none; but this isn't always the case.  There were places where content was hidden for everyone that should have been visible to screen readers.  Management may not know what is hidden or why, but it's certainly something to look for to see if hiding this content does present a barrier to people; 

• Flash is Almost Always Inaccessible.  There are examples of Flash sites out there that are accessible, but most have problems associated with them. Often there is no support for keyboard only users;

• More sites are using Javascript sliders.  Some do not have alt texts for the images and many have not be tested for keyboard navigation;

• Input forms are often grouped into fields and often these have not been implemented.

At the time I wrote this report, the sites below were the only ones where WAVE didn't find some errors.  I didn't visit every government site or page, but I just found 13 where a quick WAVE evaluation wouldn't have helped make it more accessible:

• Environment Canada
• Public Works & Governmnet Services Canada
• PWGSC's Buy and Sell
• Canadian Grain Commision
• Canadian Forces Grievance Board

• Ombudsman National Defence and Canadian Forces

• Canadian Transportation Agency
• Transport, Infrastructure and Communities Portfolio
• Government of Canada Publications
• Office of the Commissioner of Lobbying of Canada
• Leader of Government in the House of Commons
• Privy Council Office
• Status of Women Canada

For full disclosure we were quite involved in the development of the Buy and Sell site and so took a bit of extra time to evaluate it's accessibility.  Some of the navigation isn't accessible to keyboard only users so I reported a bug.  Hopefully this gets resolved soon, however WAVE did not report this as a problem.  Automated tools are an imperfect solution, but they can very easily identify some barriers for accessibility to Canadians and should be used as part of a broader approach to accessibility.

Image by @edvolunteers for European Disaster Volunteers.