Web Content Accessibility Guidelines (WAG) 2.0

For designers concerned about Web Accessibility, you may want to peruse the Web Content Accessibility Guidelines (WAG) 2.0 document that is currently in W3C Proposed Recommendation status, but could soon move to "Recommendation" status. Also, don't forget that you can test your current site to see if it meets accessibility standards at the Cynthia Says Portal.

Thanks for giving us an updated on the WAG accessibility guidelines. There's a good discussion here that gives some background on WAG, the history of this latest recommendation, and also ways of making more Web 2.0 features on your site accessible.

I know there are different levels of compliance on accessibility guidelines. What compliance level should you have your organization's site up to? It seems like it's much easier to make sites accessible when you're starting from scratch, but a much more daunting process when you're looking at trying to improve an existing site.

Hi Megan,

Yes, you are quite right when you say that it's a daunting task to make an existing Web site accessible. In the past, I've usually approached such a project by working with the client to identify which Web pages take priority (usually those with the highest traffic). I usually develop a hierarchy of 3 priority levels (more if the site is huge) into which Web pages are categorized. Pages that fall into the priority one category would receive attention first, then priority 2 and so on. I've found that by breaking the site down into categories and working on pages one section at a time, that the project doesn't seem as intimidating. By the way, Google Analytics is a great tool to use to identify Web pages that get the most traffic. This helps me prioritize pages.

In regards to what level of accessibility compliance to shoot for, I think this depends a lot on the client's target audience, the size of the client organization and how much traffic the client site receives. For example, the target audience for one client I had was the visually impaired population, so naturally they wanted the highest level of compliance. Another client I had was a national organization and so they wanted to shoot for a "middle-of-the-road" compliance level. There are different variables that can affect what compliance level to shoot for.

Does anyone know why there are different compliance levels instead of having one standard?

Afraid I don't agree with it being a "daunting task" to make a web site accessible. I "retrofit" non-profit web sites to meet 508+ as a volunteer and train their volunteers in the basics of keeping the site compliant. The points are clear and easy to do.

It's this fear of a big project, lots of time and money that keep many businesses from doing the right thing and in reality, meeting Section 508 is actually pretty easy to do. Even volunteers using WYSIWYG's can be taught how to consider and implement basic 508, or Priority I (A) of the current web accessibility guidelines.

Like lots of standards outside the web, priorities are musts, shoulds and coulds.

Priority 1 or 'A' – which is described as things that must be done
Priority 2 or 'AA' – things which should be done
Priority 3 or 'AA'’ – things that may be done

HTH

I suppose the term "daunting" is subjective. Obviously not every project is daunting and the term "daunting" doesn't apply to all projects. A 20 page Web site with less than 100 images without descriptive alt tags certainly isn't as daunting as a 300 page site with hundreds of images without alt tags (just an example). I think the size of the Web site and what level of compliance the site is trying to meet is what determines whether or not the project is "daunting". I think WYSIWYGs make the process easier, but it certainly doesn't automate it 100%.

Section 508 (US Rehabilitation Act) along with the national Acts and Standards of many countries are inward/outward facing and apply to a lot more than just web accessibilities. 508 stipulates requirements for a wide range of workplace scenarios including assistive technologies and other hardware, software and operating systems, processes, procedures and supportive documentation etc. etc. 508 impacts on all organisational ICT's (information and communications systems).

W3C guidelines and RFC's (requests for comment) are just that - guides prepared to assist people perhaps new to these technologies and wishing to comply with an adopted set of standards and practices for an outward facing web site.

W3C recommendations are not enforceable. Section 58 (and other national/international) statues) are enforceable albeit more often than not by the method of subjective suit – i.e. a claim for discrimination is made against an organisation for non-compliance.

Several of the orgs I work with have webs designed to inform and engage community's on contentious environmental issues. These webs are widely marketed and form part of much larger outreach strategies. Web accessibility is vitally important and extends to a lot more than just web design - these webs must also be accessible through all measure of technological barriers (corporate firewalls etc.) meaning the type of code and scripting used is just as important as design considerations for human access. E.g. A web blocked by a firewall or a browser for containing tracking cookies, information requiring a popup window, or java script etc. can be just as restrictive to potential visitors as a web with a too small font or too many graphics - arguably much more so! Nonetheless, even though these orgs are aware of the range of potential barriers, I still find a lot of them fail to follow good practice with regard to outward-facing web accessibility.

In my experience good accessibility is more a cultural facet of organisations to be developed as part of overriding management strategies... The way we get organisations to 'organically' provide accessible outward-facing webs is to ensure the organisation firstly applies the same design principles to all facets of internal staff and customer relations – Organisations where internal documents and Intranets meet these criteria don’t have an issue applying the same criteria to outward facing webs. Conversely we really can't expect orgs to provide widely accessible outward-facing webs if the orgs (much larger and more complex) internal Intranet lacks the same standards of design.

Legislation and guides like those provided by the W3C help, but I think it’s only a start…