Posts Tagged ‘WCAG’

Auto-play: a usability and accessibility failure

Tuesday, July 28th, 2009

My organisation recently published a number of videos on the public website (EDIT – have removed the link as the videos have been taken off now). Those videos started automatically as soon as the page loaded. The problems with this are:

  1. Automatically playing audio on a webpage is usually an action which the user will not expect. It is therefore, at the very least, an irritation, especially if the user is in an environment where this is not appropriate.
  2. At worst, though, the audio may conflict with other audio that the user is already listening to. That might be music, or perhaps another video. But far worse, it could be a blind user’s screen reader software, and the resulting conflict would make it very hard to browse that page to pause the video or mute the sound.

More about why autoplay is bad for usability and accessibility

Event review – Accessibility breakfast @ User Vision Edinburgh, 15th June 2009

Monday, June 15th, 2009

I’ve just come back from a very interesting breakfast event at the local office of User Experience consultants User Vision. Led by accessibility consultant Mark Palmer, the session looked at issues around testing with disabled users, and presented some of the surprising results from such testing.
More about the breakfast event

Considering users with multiple disabilities

Friday, February 27th, 2009

I was interested to read, on the RNIB website, that there are an estimated 2 million people with significant sight loss in the UK, 70% of whom have other disabilities or long term health problems in addition to their sight loss.

That’s a really interesting statistic, because it highlights the fact that when we try to take into account the needs of disabled users, we often aren’t talking about individuals with just one disability. People will often have a combination of needs, and we must respond by designing for this diversity, rather than taking a locked-down, ‘one-size fits all’ approach.

A good real world example of this was when I worked in a library. The library had an easy access PC terminal, offering the following features:

  • Raised desk to allow wheelchair users to get nearer the keyboard
  • Large-key keyboard
  • Trackball mouse
  • Screen reader software and headphones
  • Screen magnification software enabled by default

Although provision of these facilities was excellent, there was a problem in that often the combination of all of these features proved a barrier in itself. For example, a regular blind user found it difficult to use the large-key keyboard as they were used to a normal keyboard, the layout of which they were instinctively familiar with. Thus, the keyboard was great for users with impaired vision, but not so great for blind users, who had to ask for help finding the location of certain keys (in fact, many keys had been left off completely).

What we quickly realised was that people needed the ability to customise the set-up according to their needs. So we had a normal mouse and keyboard on standby for anyone who requested it, advertised by large-print and Braille posters next to the terminal and backed up by regularly monitoring the terminal to offer assistance. Not the ideal solution, but better than nothing.

This is just as true for web products – we can all too often be guilty of making assumptions about our users and designing solutions based on those assumptions, rather than thinking about real world users. A good example of this is skip links. We know that screen reader users like to utilise skip links, but too many sites hide these links, making them hard to find for sighted keyboard users (for example, those with limited motor skills meaning they can not easily use a mouse). Even worse, when skip links are visible, they are often presented as tiny text, presumably so as not to confuse or distract other users. But what about non-mouse users who have impaired vision and can not read tiny text?

WCAG 2.0 recognises the challenge that all this presents:

Note that even content that conforms at the highest level (AAA) will not be accessible to individuals with all types, degrees, or combinations of disability, particularly in the cognitive language and learning areas.

…and it is a reasonable caveat. However, that doesn’t stop us doing all we can to take into account as many different scenarios as possible, and not making assumptions which cause more harm than good. Offering the ability to customise the page in a variety of ways, or at least not blocking the user’s own browser preferences, is crucial. And, as always, user testing remains a vital ingredient.

I’ve probably raised more questions than I have given answers here, but I hope to do more research on this subject soon, so stay tuned.

ATAG – ignore it at your peril

Tuesday, February 24th, 2009

A brief history

Most web developers will have heard of the Web Content Accessibility Guidelines (WCAG), especially since the launch of version 2 in December 2008. Perhaps less well known, but just as important, are the Authoring Tool Accessibility Guidelines (ATAG).

The Authoring Tool Accessibility Guidelines (ATAG) documents define how authoring tools should help Web developers produce Web content that is accessible and conforms to the Web Content Accessibility Guidelines. The ATAG documents also explain how to make authoring tools accessible so that people with disabilities can use the tools.

ATAG Overview

Version 1 of ATAG was approved in 2000, so the guidelines are certainly in need of revision. Last week W3C announced a call for review of version 2 of the guidelines, with comments invited until 16th March.

There are two distinct parts to ATAG 2.0:

  • Part A: Making the authoring tool user interface accessible – which includes “principles and associated guidelines that are related to ensuring accessibility of the authoring tool user interface to authors with disabilities“.
  • Part B: Support the production of accessible content – which includes “principles and guidelines related to ensuring support by authoring tools for the creation of accessible Web content by any author (not just those with disabilities) to end users with disabilities“.

Why should we care about ATAG?

I’m currently trying to get my organisation to realise how important ATAG is when it procures a new web CMS later this year. There has been lots of lovely talk of WCAG but we really can’t afford to neglect ATAG in our specifications or we could end up with a product which prevents some of our own staff from publishing content. In such a scenario the cost of making reasonable adjustments later, in accordance with the Disability Discrimination Act (DDA), would be horrendous. We’d potentially be stuck with something that is not fit for purpose.

But there is a far wider significance, brought about by the rise of Web 2.0 which has given everyone the power to be an author. Sites such as Facebook, Twitter and WordPress are all examples of authoring tools – they allow the user to publish content. If such tools are developed in the spirit of ATAG, they will be far more accessible to users who wish to publish to these platforms. Equally, they will assist everyone else in making sure their content is accessible, regardless of their technical knowledge.

ATAG goes hand in hand with WCAG, and both are going to be crucial in the drive towards an inclusive web. ATAG may have once been of interest only to a small audience of software developers, but it now finds itself a vital ingredient in the brave new world of Web 2.0. As the importance of producing accessible content becomes ever clearer, those who ignore ATAG could well find that they are being shunned not only by certain disabled users, by but everyone else too.

Related links

WCAG 2.0 resources

Tuesday, February 10th, 2009

In December 2008 the World Wide Web consortium (W3C) declared that version 2 of the Web Content Accessibility Guidelines (WCAG 2.0) had finally been made a recommendation. Stating that websites which already met the WCAG 1.0 guidelines should need little or no adjustment to meet WCAG 2.0, the new standards offer an updated framework for developing accessible web content.

The following resources will help developers to appreciate the differences and ensure they are compliant with the new standards. I’ll continue to update this page as new resources become available (last updated March 2009). If you’ve got suggestions for this list please leave a comment!

General

Getting started

Obviously the best place to start is with W3C itself. The WCAG Overview provides links to the dcoument, along with techniques, FAQs, presentations and more.

Of particular interest is How to meet WCAG 2.0 – a customizable quick reference to Web Content Accessibility Guidelines 2.0 requirements (success criteria) and techniques. This excellent resource allows you to filter the relevant requirements, along with sufficient and advisory techniques, so that only those which apply to your project will be shown. For example, if you don’t have any Server-Side Scripting, you can untick that technology and all information relating to that will be hidden. This makes it far easier to swallow, especially if you’re working on a fairly simple project.

Also, the RNIB’s Web Access Centre blog has a good article entitled WCAG2.0 – where to start?, written by Henny Swan whilst she was working for the RNIB. It was written before WCAG 2.0 became a final recommendation, but it’s still very relevant.

WebAIM also have a handy WCAG 2.0 Checklist which presents the principles and techniques in a simplified, more user-friendly way.

WCAG 1.0 to WCAG 2.0 – a comparison

Roger Hudson has compiled an excellent table comparing WCAG 1.0 with WCAG 2.0. Although still a work in progress, this is a great way of visualising the differences.

The Web Standards Project (WASP) also has a list of WCAG 2.0 resources.

Colour contrast ratio

WCAG 2.0 has slightly different rules for colour contrast. Jo Dolson explores what this means on his blog. Also check out this Contrast Analyser, as well as W3C’s own list of tools to ensure sufficient contrast.

Forms

Whilst none of the WCAG 2.0 Success Criteria explicitly refer to forms, some of the checkpoints do have direct relevance. With this in mind, Roger Hudson, of Webusability.com.au, takes a look at creating Accessible Forms using WCAG 2.0.

Background

Jack Pickard has an interesting log of the development of WCAG 2.0, dating back to mid-2006. It is an engaging overview of the various phases leading up to the final recommendation, which also charts Jack’s changing attitudes to the document as the content evolves. In the latter stages he looks more closely at the levels of criteria.

My 2009 Web Resolutions

Wednesday, January 7th, 2009

OK, not so much resolutions as a list of to-dos. These are areas which I’ll be looking more into during 2009. If you’ve got similar goals, or think I should be looking at other things too, do leave a comment!

Upgrade my host

My main website is currently hosted for free at Awardspace. They have been fantastic – only a bit of downtime and lots of features. However, it’s time to upgrade to something a bit more professional, so I’m now looking around for the best paid options. I’ll need to be able to host a couple of blogs too (including this one after I found an interesting article on Why Your Business Blog Shouldn’t Be On BlogSpot.com). Edit – I’m now on WordPress

Complete a list of resources for implementing WCAG 2.0

There are lots of resources appearing, but there still isn’t a comprehensive source of everything you’ll need to design and test according to the new guidelines. I hope to bring together an ever-increasing collection of resources for this purpose, building on it with my own experiences as I work on new projects.

Figure out how to make the most of Twitter

I’ve only recently started using Twitter, and I’m still not entirely sure what purpose it is fulfilling. I’m sure that I should be on there; I’m just not sure why. So I’m going to follow more people, post more updates, promote my presence on there, and see what happens.

One situation where I think Twitter could help is within my organisation, as a tool for communicating to staff exactly what I’m up to on a day to day basis. For many, our website and online presence remains a bit of a mystery, and I want increase understanding amongst colleagues so that they understand what the web has to offer. By posting regular tweets about the projects that I’m working on and the latest things we’ve put online, people will hopefully get a better idea of the breadth of content we publish, the projects we’re supporting, and the process involved in getting things online. The brevity of Twitter lends itself to this far more than, for example, a traditional blog.

Publish more videos online

I really want to get to grips with Youtube and its peers this year, to get a solid idea of the functionality of these services and to kick-start some research on the possibilities and limitations of such platforms. The first obvious step is to get stuff on there – some will be basic footage of local events, others will be experimental projects (I’m very interested in time-lapse photography, for example).

One major project that I’m hoping our organisation will support later in the year is to get much of the content of our corporate website available online as British Sign Language video, with audio and captions. This will primarily benefit severely or profoundly deaf individuals for whom BSL is the first language (1500 of which are estimated to be living within our authority alone), but could also help other deaf users, individuals with low literacy, blind users, and many others.

Get up close and personal with WordPress

I’m also hoping to get to grips with self-installing and customising hosting WordPress, not just for my own blogs, but also as a platform for building CMS-driven websites. Worpress offers tremendous potential for very effective customisation, and I’ll write more about my experiences as I progress.

Be more secure

I think online security is going to continue to increase in importance in 2009, with more peolpe expecting higher standards of security and the penalties for poor security becoming ever harsher. I’ve already overhauled all my passwords, and will next be looking at beefing up my security practices across the board.

So that’s it – a few things which will be keeping me busy over the next 12 months. Stay tuned to see how I get on.

WCAG 2.0 gets the final thumbs up

Thursday, December 11th, 2008

Some exciting news…

Today W3C announced a new standard that will help Web designers and developers create sites that better meet the needs of users with disabilities and older users. Drawing on extensive experience and community feedback, the Web Content Accessibility Guidelines (WCAG) 2.0 improve upon W3C’s groundbreaking initial standard for accessible Web content, apply to more advanced technologies, and are more precisely testable.

It’s taken nearly 8 years, but we finally have a follow-up to the groundbreaking but desperately outdated first version of the international guidelines for creating accessible websites.

I’ve previously been in contact with the Central Office of Information to find out how quickly they’ll be recommending that public sector organisations start adopting the new guidelines. Now that WCAG 2.0 is finalised, we’ll hopefully see the Delivering Inclusive Websites document updated by mid-2009, but there’s nothing stopping organisations preempting this and indeed I’d hope most will already be doing just that.

We can now look forward to designers across the globe rolling up their sleeves and getting stuck into the new standards, and I’m sure the collaboration that will come from this will make it a smooth transition. A starter for ten can be found in the WCAG 2.0 resources over at the Web Standards Project.

Good luck!

Other excited people

WordPress and accessibility

Monday, December 1st, 2008

I’ll shortly be publishing an article on blogs in the public sector (edit: now available), but for now here’s a link to an interesting article on WordPress and accessibility. As author Mike Cherim points out, one of the sites named in the WCAG 2.0 implementation (and indeed reaching triple-A standard) was based on WordPress, suggesting that the platform can produce very accessible results. There are a couple of issues to be aware of, though, so if you’re developing sites with WordPress you’d better read this.

WCAG 2.0 and Delivering Inclusive Websites

Wednesday, November 12th, 2008

In June 2008 Central Office of Information (COI) produced the Delivering Inclusive Websites guidance:

These guidelines are for public sector website owners and digital media project managers wishing to deliver inclusive, accessible websites. This document sets out the minimum standard of accessibility for public sector web content and web authoring tools. It recommends a user-centred approach to accessibility, taking account of user needs in the planning and procurement phases of web design projects.

These guidelines currently make reference to WCAG 1.0, so I wanted to know what would happen once WCAG 2.0 is approved. There is a paragraph which refers to this, but it is a little vague:

At the time of writing, version 1.0 of the Web Content Accessibility Guidelines is the current standard for web accessibility. At such time that version 2.0 becomes a W3C Recommendation, this policy will be reviewed within six months. Consideration will be given to the adoption of version 2.0 as the minimum standard for public sector websites.

Our organisation is currently looking at options for a new web content management system. As such a procurement would be a long-term commitment, I’m keen to know that the goalposts are not going to move halfway through implementing a solution. Whilst it’s true that sites built to conform to WCAG 1.0 should meet WCAG 2.0 without too many problems, I feel it is crucial that the minimum standards are recorded in black and white in any requirements documentation.

I have therefore submitted the following enquiry to the COI:

With WCAG 2.0 currently at Proposed Recommendation stage, and due to be approved by Christmas, what plans are there to modify the information provided as part of the “Delivering inclusive websites” guidelines? What are the timescales involved i.e. how soon should the public sector be building websites according to WCAG 2.0 instead of WCAG 1.0?

and will post the reply here when received.

Update 16th Nov

Reply from COI:

We plan to review adoption of WCAG 2.0 with the public sector community. It is unclear at this stage whether doing so is in our best interests. For example, the new AA requirement for audio description and subtitles for every video would mean that we Level-A would be the only realistic option – and then the risk is that no-one implements the other Level-AA requirements.

We would also like to see what the European Commission thinks about the new standard. Anything we do would have to be in line with their thinking.

I don’t think there’s anything stopping people building to WCAG 2.0. Am I right in thinking that any website that’s AA according to version 2.0 is automatically v1.0 compliant?

An extract from my response is as follows:

Unfortunately I don’t think it is the case that WCAG 2.0 compliant sites will meet WCAG 1.0, at the equivalent conformance level, by default. There are many WCAG 1.0 checkpoints with the ‘until user agents’ caveat that WCAG 2.0 have now omitted, due to the conditions being met. Plus there are obvious changes such as no longer requiring Accesskeys or metadata to add semantic information to pages, or not being required to avoid deprecated features. If you therefore designed according to WCAG 2.0, I would imagine that you might fail against WCAG 1.0 on these sorts of points.

Regarding your point about unrealistic levels of compliance – I know it has been suggested elsewhere that a phased approach might be most appropriate, to account for the cost, time and expertise required to, for example, produce compliant time-based media. There may also be potential to describe the transitional approach in the conformance claim statement (which is required for any site claiming WCAG 2.0 conformance).

Hopefully we’ll see some new guidance soon.

WCAG 2.0 and WAI interview

Wednesday, October 22nd, 2008

There’s an interesting article in the latest e-access bulletin, produced by Headstar. As they haven’t yet updated their website with this bulletin, I’ve reproduced the article below. For more information about the bulletin see www.headstar.com/eab.

Global Standards Giant Gears Up For Battle
by Dan Jellinek.

With the long-awaited appearance of version 2 of the World Wide Web Consortium’s Web Content Accessibility Guidelines (WCAG) now expected in December, the spotlight is set to fall once more on the workings of this key international standards body.

The consortium, known as W3C, was founded in 1994 by the inventor of the web Tim Berners-Lee, who remains its director. It functions as a developer and repository of key technical standards and protocols that are needed to be shared by technology companies and users to ensure that the web remains open and universal.

With a current membership of more than 400 organisations, from large multinational technology companies to universities and charities, W3C has three main global bases: the European Research Consortium for Informatics and Mathematics (ERCIM) at the Sophia Antipolis technology park in the South of France; Massachusetts Institute of Technology’s Computer Science and Artificial Technology Laboratory; and Keio University in Japan.

The consortium has a core staff of around 70, with around 30 in Europe, 30 in the US and 10 Japan. But the actual headcount of those involved in its work is more than 500 if a tally is taken of everyone in the consortium’s working groups, interest groups, and the wider community.

The WCAG work falls under the auspices of W3C’s Web Accessibility Initiative (WAI), a programme that cuts across all the consortium’s other areas. In a UK visit last month, two WAI staff Shadi Abou-Zahra and Andrew Arch met E-Access Bulletin in London to explain their work programme.

“WAI is one of the consortium’s main work areas, and cuts across all the W3C’s global locations,” said Abou-Zahra. “One of our tasks is to cross-check all W3C’s work such as that on [the web's core protocol] HTML to check it supports accessibility, because if standards like HTML don’t support accessibility, you won’t have accessible websites.

“This is really one of the most important pieces of work we are doing, though it is the least visible to the outside world. What’s most well- known about WAI’s work is its development of three guidelines – WCAG, ATAG (Authoring Tool Accessibility Guidelines) and UAAG (User Agent Accessibility Guidelines).

Authoring tools guidelines relate to content management systems, and are aimed at ensuring these systems need to create accessible content, while user agents are tools like browsers and media players, Abou- Zahra says.

“Other areas of our work include education and outreach, which is really important, because most people who make inaccessible websites are often unaware of the issues for people with disabilities.”

One major new piece of work undertaken by WAI is the EC-funded WAI-AGE Project ( http://www.w3.org/WAI/WAI-AGE/ ), a look at the implications of an ageing population for web access, given the older people are more likely to have disabilities and may also be less familiar with new technologies.

“Demographics worldwide are dramatically changing at the moment,”
says Andrew Arch, who works with Abou-Zahra on WAI-AGE. “The proportions of older to younger people are changing as well as the numbers. We’re living longer, and we haven’t got the support behind us.

“Lots of things have got to change in governments and organisations – with an ageing workforce, you have to keep learning to stay accessible.”

The WAI-AGE project is partly aimed at finding out whether there are any significant new pieces of work needed to ensure web accessibility for an older population, Arch says.

“We’ve looked at what research and user observation has gone on over the decade. There is a pretty big overlap between older people and others with disabilities – sight starts to decline, motor dexterity – and individually these overlap. But with older people there is often a lack of recognition that there is a disability there. For example some people might just say they can’t remember so well, rather than that they have a cognitive impairment. Or people won’t see failing eye-sight as a disability, it’s just ‘part of growing old’. But they are disabilities, and often multiple disabilities.”

Having gained a grasp of current research the project returned to guidelines such as WCAG 2.0 to see if any changes might be needed.
“A large proportion of the needs of older people are met by the new guidelines, but other things might need to feed into the guidance we will issue on implementing the guidelines, for example guidance on how people prepare content for older people.,” said Arch.

“Many older people have not grown up with computers, and may not realise their capabilities, for example that you can magnify text in your browser.”

However as well as helping to address the problems of ageing it is also important to challenge myths and assumptions about older people such as none of them have any interest or expertise in using computers, says Abou-Zahra. “Social networking is an important part of ageing, for example. And making social networking sites more accessible for older users benefits everybody.”

This argument is a development of the age-old mantra from the accessibility sector that people with disabilities want to use the web in the same way as everybody else – “it is a human right recognised by the UN,” says Abou-Zahra. But he recognizes that businesses in particular will also be interested in the additional business benefits, especially in the current financial climate.

“With commercial organisations the return on investment is often an important argument. Well, a few years ago, companies might have said ‘how many older people are online?’ but with demographics changing they know the answer. And with the current surge in mobile phone use there is another incentive, since accessible sites work better on mobile phones.”

Other financial factors include helping to hold onto employees as their average age rises through making internal web systems more accessible, though more work is needed on in all these areas, he says.
“We know there are not enough numbers attached to these business cases, and we hope for more soon. There is a business case document for accessibility on the WAI website, and we are updating it to reflect new developments.”

For many, however, the key accessibility event of the year – assuming it does scrape into 2008 – will be the release of WCAG 2.0.

The WCAG working group held a face-to-face meeting in Boston at the beginning of October to examine the results of trial implementation of the draft guidelines on real websites, and now expects to finalise WCAG 2.0 as a fully-fledged W3C recommendation by December or at the latest by early next year, Abou-Zahra says.

The first version of the WCAG guidelines now dates back around a decade, and though it has proved a vital tool for raising awareness of accessibility issues it has long been seen as over-technical and complex and unclear in many situations.

Version 2.0 is set to address many of these problems by moving away from rigid technical ‘checkpoints’ to more flexible ‘success criteria.’

Another change of style will be a greater separation between the core guidelines and references to specific technologies such as Javascript or browser types, Abou-Zahra says.

“The work needs to be coupled to technologies, but how do we do that in such a way as to not make it outdated the moment it is released?
This is the complex issue,” he says.

“WCAG 1.0 was too technology-specific. Back then HTML was more dominant, and there was less use of multimedia, but today we have a flurry of technologies such as Ajax, so the first lesson we learned is don’t write for a specific technology. Also, in the days of WCAG 1.0 we had to exclude Javascript because it was not sufficiently standardised and assistive technology could not handle it consistently, but now that has largely changed so you need to include it, to look at how any technology should be accessible. The requirements – such as tagging images with text – needs to apply to any technology you are using.

“So WCAG is more decoupled – but having said that, no matter how much you decouple it from specific technologies, there still need to be points of contact with real technologies, places where the tyre hits the road. It is an issue the group is looking to resolve by updating implementation guidance.”

Another ongoing problem with the WAI web content guidelines is that they do not fully address the needs of people with cognitive disabilities, admits Abou-Zahra, though he says this is a challenging longer term issue that the organisation is working to resolve alongside the wider access community.

“We know it does not fully meet the needs of people with cognitive disabilities such as some forms of learning disabilities, we admit this up-front,” he says. “It is a longer term project, maybe one for WCAG 3.0. I feel this is an issue that the accessibility community as a whole needs to address, more research is needed.”

Beyond the publication of WCAG 2.0, W3C and WAI will continue to prioritise accessibility across all its areas of work, he says. “WAI’s work is often reduced to WCAG in the public eye, but it is a whole lot more than content, it is about making the web accessible in its broadest sense.”