Posts Tagged ‘W3C’

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 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

WCAG 2.0 and I

Tuesday, October 14th, 2008

The Web Content Accessibility Guidelines (WCAG) are a collection of guidelines intended to make web content accessible to all users (regardless of technology, disability etc). They were first published by the World Wide Web Consortium (W3C) in 1999. Over the past few years there has been an effort to update these guidelines with a second version – WCAG 2.0.

WCAG 2.0 Candidate Recommendation

Earlier this year I was involved in the Candidate Recommendation stage of WCAG 2.0. This was essentially a chance for web developers and designers to ‘test-drive’ the guidelines to ensure they are usable in real-life scenarios. With a number of the guidelines up for review as potentially unworkable, this stage of the process was vital.

I submitted a proposal to re-design www.prettysimple.co.uk and this was chosen as one of the implementation sites in June 2008.

Implementation experience

On submitting my site re-design for the WCAG 2.0 Candidate Recommendation, I was asked to provide feedback on all relevant areas of comformance – detailing how I met each guideline. My feedback was as follows:

1.1.1: Non-text Content (A)

Alt descriptions for images with relevant content. Null alt attributes for decorative images.

1.3.1: Info and Relationships (A)

Semantic elements used to structure page and convey information. Includes using navigation lists and page headings, and using CSS for layout and formatting.

1.4.1: Use of Color (A)

Colours not used to convey meaning.

1.4.3: Contrast (Minimum) (AA)

High contrast for test achieved using a span background colour.

1.4.4: Resize text (AA)

All text can be resized by user agents, by at least 200%.

1.4.5: Images of Text (AA)

Non essential text appearing as images given very large font size and alternative attributes.

2.1.1: Keyboard (A)

All aspects of the site can be navigated and accessed by keyboard. Use of skip links.

2.1.2: No Keyboard Trap (A)

No keyboard traps present.

2.4.1: Bypass Blocks (A)

No keyboard traps present.

2.4.2: Page Titled (A)

Appropriate titles given to all pages.

2.4.3: Focus Order (A)

All elements appear in the correct order in the source code.

2.4.4: Link Purpose (In Context) (A)

Link text sufficiently descriptive to be obvious when read alone.

2.4.5: Multiple Ways (AA)

Main navigation links are supplemented by relevant contextual links within main content.

2.4.6: Headings and Labels (AA)

Heading used to highlight subsections of each page, where appropriate.

2.4.7: Focus Visible (AA)

All links have a highly visible link, visited, focus, hover and active state.

3.1.1: Language of Page (A)

Default language defined on every page.

3.2.1: On Focus (A)

Links do not open in new window.

3.2.2: On Input (A)

Links do not open in new window.

3.2.3: Consistent Navigation (AA)

Navigation is consistent on every page.

3.2.4: Consistent Identification (AA)

All functionality is consistent across every page.

4.1.1: Parsing (A)

All XHTML and CSS validated accordingly to formal grammars.

Acceptance e-mail and amendments

On Wednesday September 24th I received an e-mail from Loretta Guarino Reid, co-chair of the WCAG Working Group, telling me that my site had been evaluated and found to conform to level AA of WCAG 2.0, with just a couple of exceptions. These were:

Insufficient contrast for the main menu

This came about from a change in the rules for colour contrasts. I had used algorithms relevant to WCAG 1.0, due to a lack of many good tools for testing against WCAG 2.0. However, after a bit of searching I found the WAT-C Luminosity Contrast Ratio Analyser 1.1 and used this to bring the colours into conformity.

Use of color

It was noticed that some links could only be identified as such by their colour. By making all links Bold as well, this was resolved. This was in line with the advice given as part of the notes accompanying F73: Failure of Success Criterion 1.4.1.

Implementation report

I’m now hoping that my site will be included in the final report, which the working group hopes to publish by Christmas 2008.

PS: For an excellent account of implementing WCAG 2.0, from a fellow implementor, see Mike Cherim’s article My WCAG 2.0 AAA Implementation.