If you thought standards and specifications were something that would definitely not make you want to get up and dance - think again. This YouTube video about the new WCAG 2.0 will make you see it in a whole new light and may even have you tapping your toes.
It’s an innovative and fun way to promote a standard and maybe it’s something we at JISC CETIS could try!
After much deliberation, pulling of hair, and no doubt many sleepless nights, the W3C (World Wide Web Consortium) has finally officially published WCAG (Web Content Accessibility Guidelines) 2.0.
Yesterday’s press release from W3C states that trial implementations of the new standard have shown that most web sites which already “conformed to WCAG 1.0 did not need significant changes to meet WCAG 2.0″, so many developers may be breathing a sigh of relief. But it is also likely that there will be pressure for developers to ensure that their web content conforms to the new standard. Does this mean that what was “accessible” yesterday is not “accessible” today?
WCAG 2.0 is different in many aspects to WCAG 1.0, so for a while there may be a two-tier level of conformance (although the A, AA, and AAA conformance levels are still in place). Some of new aspects covered include:
* captchas;
* semantic markup using ARIA (Accessible Rich Internet Application) - once this specification has reached “recommendation” status;
* recommendation that an alternative is provided for any text that requires a reading ability more advanced than the lower secondary education level (how will online academic papers be dealt with?);
* etc.
However, WCAG 2.0 comes with several other resources to help with its implementation:
* WCAG 2.0 at a Glance;
* WCAG 2.0 Documents;
* How to Meet WCAG 2.0: A Customizable Quick Reference;
* Understanding WCAG 2.0;
* Techniques for WCAG 2.0;
* How to Update Your Web Site to WCAG 2.0.
The WAI (Web Accessibility Initiative) have tried hard to give developers as much information as possible to help with the implementation of WCAG 2.0. They have gone beyond simply defining what one can and can’t do, and include additional information around conformance, failure testing, conformance policies, etc. Perhaps this level of assistance with implementation should be considered by other standards bodies.
In any case, WCAG 2.0 is finally here. Whether developers and users will see it as a welcome Christmas present or something they’d rather take back to the shops in January remains to be seen. Let’s hope it helps rather than hinders.
There’s a lot going on over at the W3C WAI (World Wide Web Consortium Web Accessibility Initiative), with current guidelines being updated and new ones being developed. So here’s a brief overview of what’s happening.
* ATAG (Authoring Tool Accessibility Guidelines) 2.0 - These guidelines are currently at Working Draft level. ATAG 1.0 is still the stable version which should be used.
* EARL (Evaluation and Report Language) 1.0 - The public comment period for the “Representing Content in RDF” and “HTTP Vocabulary in RDF” companion documents has recently finished (29th September 2008). Once the comments have been addressed, these documents will be published as Notes rather than Recommendations. (EARL 1.0 is currently has the status of Working Draft.)
* Shared Web Experiences: Mobile and Accessibility Barriers - This draft document gives examples of how people with disabilities using computers and people without disabilities using mobile devices experience similar barriers when using the Web. Comments on this document closed on 20th August.
* UAAG (User Agent Accessibility Guidelines) 2.0 - This version is currently at Public Working Draft status and is at this stage for information only.
* WAI-AGE Addressing Accessibility Needs Due to Ageing - This project is currently at the literature review stage and aims to find out whether any new work is required to improve web accessibility for older people.
* WAI-ARIA (Web Accessibility Initiative Accessible Rich Internet Applications) - The Working Draft has recently been updated and comments on this update closed (3rd September).
* WCAG (Web Content Accessibility Guidelines) 2.0 - After a lot of to-ing and fro-ing, WCAG 2.0 finally looks as though it’s going to finalised for public use by the end of the year. Data from the implementation of trial WCAG 2.0 websites has been gathered and whilst the status is still “Candidate Recommendation”, this status is likely to be updated in November.
Virtual Hosting.com has drawn up a list of 25 Free Website Checkers, with a brief description of what each one does. The checkers are split into handy sections - General, Disability, and Usability - but automated checkers will only check the easy bits - e.g. colour contrast, HTML (HyperText Markup Language) and CSS (Cascading Style Sheet) code, etc - i.e. the bits for which an algorithm can be written.
However, whilst a website checker can check that alt text, for example, is used with an image and will tell you if it’s missing, it can’t actually tell you whether what that alt text actually makes sense. For example, alt text of “an image” or “asdfg” is not going be very useful to someone who doesn’t download images or for someone who uses tooltips to find out the relevance of the image (particularly where a description or title hasn’t been provided). So developers and content authors need a hefty dose of common sense to make sure that the aspects of a website that can’t automatically be checked by a computer are actually usable and accessible.
It’s often quoted (but I can’t remember by whom) that one could implement the whole of WCAG (Web Content Accessibility Guidelines) and still end up with an inaccessible site. Whilst an automated checker might find that the site is accessible based on a simple checklist, a human may find it unusable. Human involvement in checking accessibility is still necessary and as well as common sense, an understanding of accessibility issues and context is also required. For example, whilst a photo of Winston Churchill might have the alt text of “Photo of Winston Churchill”, if the photo is illustrating a particular point, it could be more relevant to say “Photo of Winston Churchill smoking a cigar” or “Photo of Winston Churchill in London in 1949″, depending on context.
So whilst automated web accessibility checkers have their uses, it’s important to remember that they generally don’t include an algorithm for common sense!
Headstar’s eAccess Bulletin has the scoop on Accessibility Ultimatum Proposed for UK Government Websites. Sources claim that government websites will be penalised by being stripped of their “gov.uk” domain names if they don’t meet the WCAG (Web Content Accessibility Guidelines) AA rating. At the moment, this is still only a draft proposal but if ratified, would mean that all existing government sites would need to have the AA rating by December 2008.
Whilst the government’s intentions are no doubt admirable, WCAG (and I’m assuming they’re talking about WCAG 1.0 here) is useful but still needs a lot of common sense in its implementation. I’m also assuming that government websites include national government, local government, public libraries, police, fire services, museums, art galleries, etc. But what about universities, schools, educational bodies, etc? Is this just the start of a British equivalent of America’s Section 508? And what happens when WCAG 2.0 is finally ratified?
Whilst the standards approach is useful and can provide a lot of guidance, actual enforcement may mean that alternative approaches to accessibility are not pursued and common sense is not taken into account. For example, an image with an alt tag will easily pass a Bobby check but what if that alt tag is completely meaningless - <alt=”gobbledygook”>? Innovative ways of tackling accessibility problems may not be thought about or explored - and in any case, it’s quite possible to be completely WCAG compliant and still be inaccessible.
So here are my somewhat Utopian ideas for an approach to accessibility:
1. Education, education, education - all design, web design and IT courses should automatically include a complusory accessibility and usability module.
2. Standards and guidelines - for “guiding” developers, not hitting them over the head with a big stick. However, they should remain as guidelines and recommendations and should not be forced on people, unless it has been proven without a doubt that a particular guideline is useful and can be successfully applied in all situations. This is not always the case. For example, anyone can add an alt tag to an image but does everyone know the best type of text to put in it?
3. Common sense and innovation - this is perhaps more wishful thinking on my part but we should all use our common sense and our understanding of the barriers in conjunction with guidelines and see if there are alternative, better ways of doing things, particularly as new technologies and approaches come to the fore.
4. User testing - by all types of users, from the “silver surfer” to the person with learning disabilities as well as the average person in the street. We all know what we should do but often time and resource constraints mean that lip-service is often only paid.
Whilst standards are great for things that can be set in stone, such as nuts and bolts, sizes of credit cards etc, they are not so successful for “fuzzy” applications (like users), who have many different needs and preferences depending on different contexts, situations and how they’re feeling at the time. Fuzzy applications (users) need fuzzy blended, complementary approaches so taking the big stick of standards enforcement to developers could be a bit of a backward step in the support and encouragement of accessibility.
