Accessibility Field Notes

We have spoken many times to many people about the overlap between sites that are great for accessibility and great for Google. To prove just how close the disciplines can be, I have co-written a business book with our long-time Google-obsessive colleague, Steve Johnston (when not accessifying websites, Paul and I have plied our services as Google consultants via Steve’s team at Search:Johnston for some years now). 50 ways to make Google Love your website (or, as we have taken to calling it in the office, Google Love) is our attempt to explain a complicated yet beautiful thing through some easy to grasp fundamental principles, together with a detailed (yet readable) look at how Google works. This is for ordinary website owners and business people, not techies (though I would hope that the more technical will get plenty out of the book as well), and came about from our frustration with the oversimplified approach favoured by most other books on the subject, and the myths cheerfully recycled by too many in our industry.

So if you fancy an enjoyable, often light hearted, yet always intellectually rigorous voyage around the finer points of Google Love, then you could do worse than buy a copy.

As always, come and tell us what you thought (or leave a review on Amazon, of course).

The W3C Web accessibility Initiative recently published “Contacting Organizations about Inaccessible Websites“. It walks through steps, provides lots of tips, and includes sample e-mails. We like it very much.

A draft of the document was available in August last year, so we asked a friendly web user to follow the guidance and report back on how it went. He got back to us a few days ago, with the following tale of woe:

MoreActive4Life [www.moreactive4life.co.uk]

MoreActive4Life is a campaign in the UK that took place over the Summer of 2009. It was the Fitness Industry Association [FIA] contribution to the wider run Government programme known as Change4Life.

Where Change4Life is a broader approach to improving health across different age groups, lifestyles and backgrounds of both individuals and families, with a particular focus on providing balanced dietary advice under the remit of the Government’s Food Standards Agency [FSA] and National Health Service [NHS], the MoreActive4Life’s focus was on enabling users to specifically incorporate more physical activity into their lives with particular emphasis on encouraging engagement of locally available facilities and services.

Although using the same branding and design elements of the Change4Life website which sits under the umbrella of NHS service pages [http://www.nhs.uk/change4life/], the MoreActive4Life site did not share the same layout and construction, consequently providing a different user experience in terms of accessibility.

This is an account of a user’s difficulty in using the MoreActive4Life site and their continued difficulty in trying to report this to the FIA.

[NB: It should be noted that the user's journey in making their report initially took them through agencies within the NHS before coming into contact with the FIA, and these parts of the process are included in this account to give context to the difficulty that an indirect or improperly structured feedback procedure can give to users.]

The User

First contact was initiated in mid-August 2009 by a user favouring keyboard navigation on their laptop due to repetitive strain injury that made use of a touchpad or external mouse uncomfortable. The MoreActive4Life site did not offer any contact details for the FIA under their ‘About FIA’ page [http://www.moreactive4life.co.uk/aboutfia] instead directing enquiries to Change4Life’s website and contact telephone number.

First Contact – Change4Life

The user informed the telephone agent for Change4Life that they were having difficulty navigating across the site as a keyboard user, and was advised that technical problems needed to be reported via the NHS Choices website [http://www.nhs.uk/]. The agent then proceeded to guide the user through this site to the Contact form. Although having already stated that they were a keyboard user, the user was repeatedly told to ‘click’ on links by the agent, who then had to wait for the user to tab through the menu options to reach the required link.

This process took the user through two pages of navigation (which was similarly not optimised for keyboard users), to a contact form which asked them to state the nature of their enquiry. With no option relating to the MoreActive4Life site in the enquiry categories offered, the user was forced to submit their comment as a technical problem with the NHS Choices site.

Second Contact – NHS Choices

The Reported Problem:

Dear Sir/Madam,

I was visiting the website [http://www.moreactive4life.co.uk/] today and found it extremely difficult to find my way around the site. I primarily navigate with a keyboard as I cannot use a mouse because of a repetitive strain injury, but when I press the tab key to select a link there is no highlight of my selected option. Hitting return does take me to a new page but it is not possible to tell which one and I cannot tell in which order I am tabbing through the links.

I am browsing with Firefox version 3 on a Windows laptop computer using the built in keyboard – I have tried to use Internet Explorer version 7 instead on the same computer but the problem persisted. Please can you look into this matter as even finding the telephone number that guided me to this contact form was very difficult and I would appreciate being contacted if or when the matter is fixed. If you require more detail about the difficulty I experienced site then you can contact me by telephone on  ***********, or by email [***********],

Yours sincerely,
***** *****

As per the quoted response time of 24 hrs the user promptly received an automated email reply informing that that their query had been forwarded to the appropriate team at the NHS Choices Helpdesk, who quickly responded with:

Dear *****

This site is not a Department of Health site, it is just using the Change4Life branding. I have included them in this response so your message is passed onto them. If you need the central Change4Life site you can find it at www.nhs.uk/Change4life.

I hope you hear back from the fitness association.

Regards
******

At this point the user received no further communication. The MoreActive4Life closed on 31^st August 2009, and having made what could be arguably called the standard efforts required for reporting a problem with the site, the user was as such prevented from accessing the site and its services.

Third Contact – FIA

With contact details for the FIA not included on the MoreActive4Life site, the user made independent investigation and emailed them directly [www.fia.org.uk].

Dear Sir/Madam,

Last month I used the contact form on moreactive4life.co.uk to inform you of the difficulty I experienced in the navigation of your site (attached), and was promptly informed that my query was being passed on to yourselves.

I have since then received no response either by email or telephone regarding the matter and am disappointed to have recently visited the site again to see that the campaign has ended. Upon attempting to take a further look around the site for more information on the campaign for results or feedback, I see that the problems I experienced in navigating still persist.

Please can a member of your team contact me about this as I find it quite unsatisfactory for my query to have been seemingly ignored, and I wonder how many other people in my position might have been similarly left without acknowledgement of our interest,

Regards,
***** *****

Tel: ***********
Email:***********

After four days an agent at the FIA contacted the user by telephone to discuss the matter, but at a time when the user was unable to take the call. A time was arranged to revisit the following week at which point an email was received by the user citing that when taking down the number again over the phone it was incorrectly transcribed. Presumably the agent for the FIA still has the email with correct details in their records for cross-referencing at this point but clearly did not otherwise they would have been able to call the user back as agreed.

The user responded with the telephone number again and suggested times they would be available to receive a call and discuss the matter. This email on the 29^th September 2009 receives no call back and it is not until the user takes it upon themselves to email again on 12^th October 2009 that they are finally contacted the following morning and able to fully discuss the problem originally initiated in August.

Response to Fifth Contact – FIA

Summary from telephone conversation:

The FIA’s agent informed the user that he and his colleagues did not find the problems navigating the moreactive4life site that had been reported in the original email, making particular reference to them having successfully used the keyboard to tab from link to link and access each one’s destination.The user pointed out that unlike the FIA’s internal staff (who would presumably have a simpler time of doing this having a certain familiarity with the site), that the average member of the public would not, and in the case of the user themselves, definitely did not have the same inherent ease in navigation from first attempt.

The agent asked if the user did not see the destination of whichever link was highlighted when tabbing around on the site via the status bar on Internet Explorer [IE]. The user had to remind him that, as per the initial email explaining the technology being employed, the user was primarily a Firefox browser and that when alternatively trying IE as the user had done, and it was inappropriate to assume that all other users would employ the same browser software.

The agent assured that this method of navigation would work and the user had to remind him that the status bar tool is a visibility option not mandatorily displayed as part of the IE interface, but only when selected as a custom viewing option, so only worked for users who had opted in to a visible status bar within their browser settings.

The FIA agent informed the user that this was the only occasion on which they had received a complaint regarding the site, and asked what they might suggest as a solution.The user explained that the addition of highlighting links selected by keyboard focus would make it much easier to know where they were within any page on the site, and that it was a reasonably standard mechanism employed by many websites. The user also took this opportunity to mention that the lack of timely response or support from the FIA was disappointing since their responses to the enquiry had come long after the campaign had expired.The agent informed that the campaign would recommence in January 2010, but when asked if they intended to make any changes to the website given the difficulty in navigation that the user had articulated to them, was told this was not likely since it would be costly to make changes based on a single complainant when they had tested the site and none of their users had found the difficulties reported.The user asked whether they had employed any testers who were primarily keyboard navigators, and if not then would they consider testing with such users in advance of the January campaign?The agent said he would discuss the matter with his colleagues and let the user know about this and further details of the January campaign by telephone on Friday 16th October.

The user received no further contact by email or telephone on or beyond this date.

Since the 31^st of August 2009, the homepage for the MoreActive4Life site has continued to display the following message:

The moreactive4life campaign ended August 31, but watch this space for upcoming activities!

In Summary

The main problems of the case were a failure to implement suitable procedure for feedback or develop a mechanism for improvement beyond a campaigns’ go-live date; a poor understanding by customer contact staff of the problems faced by their service’s disabled users.

While there is little likelihood that such a drawn out and exhaustively unfruitful user journey for making a complaint (or presumably a comment of any kind by way of feedback) is at all intentional, it would appear that any testing carried out prior to the campaigns launch was seen as definitive and therefore not giving scope or consideration for further feedback and improvement.

Our new case studies are available from the W3C! They seek to demonstrate the business case for accessibility, taking Legal & General, Tesco, CNET and others as examples.

These case studies draw together a number of authoritative sources together into a single place, in a format that demonstrates clear business returns.

• Legal & General Accessibility Case Study
• Tesco Accessibility Case Study
• Target Corporation Accessibility Case Study
• Sydney Olympics Accessibility Case Study

Happy New Year!

Accessibility is a critical component of websites…

Opening line of Google for Webmasters Tutorial: Crawling and Indexing

Having been prodded (gently, but insistently) by Shawn Henry over at the W3C’s web accessibility initiative, I am now hesitantly putting together this article on the overlap between the charms of web accessibility and the dark arts of SEO. The overlap is hard to miss if you work in the field of accessibility - I first became interested in SEO around five years ago, when I started to investigate the reason for the increased visits we saw whenever we improved the accessibility of a website. The main referrer of these extra visitors turned out to be Google. The skills we had developed in the field of web accessibility were, it seemed, directly applicable to many of the search engine optimisation (SEO) challenges that face search specialists every day.

We first started working in the field of SEO a year or so later due to our reputation as accessibility experts… a well-respected Google consultant had a knotty visibility problem, and he came to us for advice. Ever since, when Paul and I are not engaged in solving people’s accessibility problems, we are frequently to be found working for the Search:Johnston Google Consultancy, run by the estimable Steve Johnston, SEO guru of the ‘white hat’ variety (try Googling for ‘Google Consultant’). We work to improve the visibility of websites to Google, the relevancy of their content to the vocabulary used in search queries, and the reputation of their sites – both real and algorithmically determined – that make them rank better than other, less respected sources of information.

Google has a couple of things it wants to determine for each web page in its index (although my own specialism is Google, this all applies to Yahoo, Bing, Ask and the others.). Firstly, it has to be able to determine its relevance to a search query. To do this, it must be able to read the web page; it also has to understand what it is reading. It is in this area – making web content perceivable, and understandable – where the overlap with accessibility is most apparent. Secondly, it has to determine the reputation of the web page. This is a bit more complicated, and the overlap is more subtle (but important!), but we’ll come to that later. Let’s start with reading and understanding part.

Firstly: read it, understand it

If Googlebot can’t get to a page, it’s not going to be indexed. Simple as that. Even when it finds it, the more context a page author can give about the relative importance of different information on the page, the better. Google is blind. Google doesn’t use a mouse. Google sometimes has trouble with javascript. Like a blind person using screenreader software, Google relies on structural cues in the content – denoting headings, paragraphs, lists and more – to make more sense of the page.

(Please note that the ‘blind user using screen reader software’ is by no means the only kind of user with a disability who appreciates an accessible website. But quite a few of the accessibility guidelines are aimed at accessibility to screenreaders, and it is, by and large, where the overlap lies).

The accessibility guidelines relating to perceivability and operability are directly applicable to the problem of Google visibility. Google and screen-reader users want to know fairly similar things: Can you read it in the first place? Is it navigable? Are scripts or other complications getting in the way? Can you get to everything without needing a mouse? Without needing special tech such as scripts or embedded players? Are there headings, subheadings, titles, paragraphs? What are they? Do they tell you about the content of the page? Where is a word or phrase located in the text? Near the beginning? Near the end? Let’s have a look at a few WCAG 2.0 guidelines and success criteria in more detail.

Text text text text text

Google only sees text. It’s working on better ways of indexing images, video and audio, but it’s a long way off yet. If you are presenting non-text content, unless you provide text alternatives or transcripts, it’s never going to rank. You are exhorted to do this very thing by both WCAG 2.0, 1.1: Provide text alternatives for any non-text content and WCAG 2.0, 1.2: Provide alternatives for time-based media There’s also good old WCAG 2.0, 1.4.5: If the technologies being used can achieve the visual presentation, text is used to convey information rather than images of text….

From Google’s point of view, using text instead of images thereof makes content easier to index. Neat use of alt attributes can mitigate this, but to be kind to Googlebot, keep to text (especially for headings!) wherever possible.

If you build it, they will come

HTML, used carefully, can give a lot of clues as to the relationships and relative importance of the text on a page, using structures such as Titles, Divs, Headings, Paragraphs and Lists – to name but a few. The better structured your mark-up, the easier it is for Googlebot to understand. Google wants to know what the important sections of a page are, and what topics each covers. Providing this information is just what you need to do to pass WCAG 2.0, 1.3.1: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text; WCAG 2.4.6: Headings and labels describe topic or purpose; and WCAG2.0 2.4.10: Section headings are used to organize the content.

We don’ need no steenkin’ mice

If you can’t reach it with your keyboard, chances are Google can’t either. In fact, Google’s advice to webmasters often suggests using Lynx (a text-only browser) to check how your site might appear to Googlebot. You would be amazed how often sites – especially big ones – mess this up. Javascript-only links are the typical culprit. If you follow the guideline laid out in WCAG 2.0, 2.1: Make all functionality available from a keyboard, you won’t go far wrong.

What the heck just happened?

Do not autorefresh. Top SEO tip. Happily, this won’t be a problem if you stick to WCAG2.0, 2.2: Provide users enough time to read and use content. Ensure that important content is not time-dependent. Do not autorefresh.

Navigation’s what you need

Key vocabulary in navigation labels, along with structural relationships (nested lists can be used for menu structure, for example), is a great help to Googlebot. Following the advice in WCAG 2.0, 2.4: Provide ways to help users navigate, find content, and determine where they are will get you a fair way down the road to Google-friendly navigation.

What’s in a name?

Titles are probably the single most important piece of text relating to a page. SEO books devote whole chapters to how best to construct them. They are important for screenreaders users too – it’s the first piece of text you arrive at. The W3C resources to support WCAG 2.0 2.4.2: Web pages have titles that describe topic or purpose include a reference to ‘Writing Better Web Page Titles How to write titles for Web pages that will enhance search engine effectiveness’.

More meat

Googlebot’s appetite is limited, so SEO guidance ususally emphasises the importance of aiming for maximum content, minimum cruft. Hone mark-up for simplicity. Separate layout, styling and scripts into an external file wherever reasonable to do so. This is less important, accessibility-wise, than it used to be, but keeping those file-sizes low is good for everyone, especially those on slow connections (mobile phone users, anyone?).

Secondly: rate it, rank it

WCAG 2.0, 2.4.9: The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general.
How does Google determine the reputation of each web page in its index? It does it using what I like to think of as Google’s Big Bag of Love.

(This is my own twist on the elegant explanation laid out in “PageRank and Beyond”, by Amy Langville and Carl Meyer. My version uses more metaphor and less matrix maths).

To begin, Google shares out all the love from its bag between all the pages it has found on the web. The amount of love received by each page in this initial love-share might depend on the form and length of anchor text pointing to the page, the location of links to the page in the pages pointing to it, and the similarity of the content between linkers and linkees. (Another powerful way of refining the initial shares would be to know where real people go on web pages… and adjust the shares depending on the shares of visitors. This may be why Google Analytics is both free and rather good). Then Google blows a big Google whistle (in my head, anyway), and every page gives all the love it has to all the pages it links out to, and then turns to receive love from all the pages that link in to it.

Google, if it’s still doing it like Amy and Carl suggest, gets around 15 in every hundred pages a bit drunk, a bit giggly, so they run around joyfully handing out their love to complete stranger pages (in what are, I suppose, random acts of love), rather than to those they link to. This probably isn’t a great way of sustaining your own relationships at parties, but in Googleworld it stops love piling up with pages who do not pass it along; it keeps things interesting, and ensures elegance. Google will blow its big Google whistle a fair few times, each time watching all the pages run around, passing love out, and receiving it in. Google gets bored after around 142 (specific, no?) blasts of the big Google whistle. By this time, all the pages have calmed down a bit, and each new step in the crazy love-sharing, they seem to end up with pretty much the same amount of love in their bag as they began the step with. The love held by each page is recorded in, well, I suppose it would be the list of love.

So how does all this relate to accessibility? One of the key ways a screenreader user navigates a website is by listing the links on the page. They are listed out of context – just the link text. It’s an extremely effective way of moving through a site – experienced screenreader users can be faster at using the web than a mundane sighted user! But it only works if the phrases in the link text make sense when read on their own. So, best practice for accessible web pages is that the text of a link (the bit that gets underlined or highlighted) should make sense when read out on its own – the purpose of the link should be apparent. ‘Click here’ is no good – you have no idea what clicking there might do. This is just perfect for Google. When Google is making its decisions about the form or content of anchor text pointing to the page, anchors with useful, relevant text are going to result in better performance of that page in the, uh, love-sharing (I’m beginning to regret this metaphor).

What does Google say?

You don’t have to take my word for all this. I’m going to leave you with a few quotes from the good folks at Google about the benefits of accessible pages (I would have happily included quotes from the equivalent folks at Yahoo, Bing or Ask/Teoma, but I couldn’t find anything as good, apart from some general advice to use well formed HTML).

Why should you take the time to make your site more accessible? In addition to the service you’ll be doing for the visually-impaired community, accessible sites are more easily crawled, which is a first step in your site’s ability to appear in search results.
T.V. Raman, Google Research Scientist, Official Google Webmaster Central Blog

Consider accessibility. Not all users may have JavaScript enabled in their browsers. In addition, technologies such as Flash and ActiveX may not render well (or at all) in every browser. We recommend following our guidelines for using Flash and other rich media, and testing your site in a text-only browser such as Lynx. As a bonus, providing text-only alternatives to rich-media content and functionality will make it easier for search engines to crawl and index your site, and also make your site more accessible to users who use alternative technologies such as screenreaders.
Browser compatibility, Google Webmasters/Site Owners Help Pages

Images: Use the alt attribute to provide descriptive text. In addition, we recommend using a human-readable caption and descriptive text around the image. Javascript: Place the same content from the Javascript in a no script tag. If you use this method, ensure the contents are exactly same as what is contained in the Javascript and that this content is shown to visitors who do not have Javascript enabled in their browser. Videos: Include descriptive text about the video in HTML. You might also consider providing transcripts.
Hidden text and links, Google Webmasters/Site Owners Help Pages

[On javascript reliance] …When you’re designing your AJAX site, think about the needs of your users, including those who may not be using a JavaScript-capable browser (for example, people who use screen readers or mobile devices). One of the easiest ways to test your site’s accessibility is to preview it in your browser with JavaScript turned off, or to view it in a text-only browser such as Lynx. Viewing a site as text-only can also help you identify other content which may be hard for Googlebot to see… [On iFrames] …Avoid iFrames – or link to their content separately…” [On progressive enhancement] …If you’re starting from scratch, a good approach is to build your site’s structure and navigation using only HTML. Then, once you have the site’s pages, links, and content in place, you can spice up the appearance and interface with AJAX. Googlebot will be happy looking at the HTML, while users with modern browsers can enjoy your AJAX bonuses…When creating your links, format them so they’ll offer a static link as well as calling a JavaScript function. That way you’ll have the AJAX functionality for JavaScript users, while non-JavaScript users can ignore the script and follow the link… using HTML links remains a strong way to help us (as well as other search engines, mobile devices and users) better understand your site’s structure.
AJAX, Google Webmasters/Site Owners Help Pages

There are a lot of changes between Web Content Accessibility Guidelines (WCAG) v1 and WCAG v2. One of the most important additions is guidance on making sites easier to navigate for keyboard-only users who have good vision.

Most sighted keyboard only users are using either Internet Explorer or Firefox, both of which use the TAB key to move through the active parts of the page (links and form controls) one by one. Hitting the Enter key when a link is focused activates the link – simple! However, one of the main bits of feedback we get from keyboard-only users when testing websites is that the keyboard focus is difficult to see. If they cannot see the keyboard focus they have to use a pointing device instead (difficult or impossible for some users) or give up on the site altogether.

If the website designer does not make any effort in their code to make the keyboard focus visible, all the keyboard-only user has to rely on in Firefox and Internet Explorer is a thin, dotted rectangle showing where the keyboard focus is. This is tricky to see even on a white background and can be impossible to spot on other coloured backgrounds.

WCAG v2 Success Criterion 2.4.7 (Focus Visible: Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible. (Level AA)) recognises this problem and will hopefully mean that developers start to take more notice of this issue. Currently it is the case that although most sites manage to provide link styling for mouse users using the :hover pseudo-class, many make no provision for keyboard-only users (using the :focus and :active pseudo-classes). Worse, some sites deliberately suppress the default dotted rectangle, making the site impossible to use for a sighted keyboard-only user.

Check out our code example for good keyboard visibility, and we’ve also put together an example of really bad keyboard visibility to show you what not to do.

Any comments, leave ‘em below – we’re particularly interested in building up a list of good (like http://www.studentinvestor.org/) and bad (like http://news.bbc.co.uk/) example sites if you have any suggestions.

Skip links are a way to allow a keyboard user to get to the main content on a web page quickly, without having to read through or tab through a whole bunch of menu items every time that they load that page.  Given current technology, they are a level A requirement of WCAG v2 (Success Criterion 2.4.1 Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages).

As you might have seen from our previous posts on the matter (The search for the perfect skip link and Skip links: the saga continues) creating a skiplink that works across a number of browsers and is actually usable to the end user is not a simple task. Spurred on by new functionality in some later browsers, the launch of Google’s Chrome browser and some feedback we had regarding using skip links on a Mac, we thought we would re-examine skiplinks and present you with our latest thoughts.

The impatient amongst you can go and look at the example skip link code straight away. Those who want a bit more background, read on…

The requirements

• Skip links need to be ‘visible’ to all keyboard users (not just screenreader users) (see )
• Skip links should not confuse a fully sighted mouse user
• Skip links need to provide enough information to the keyboard user to explain what they do
• The skip link needs to work on a wide a range of current browsers as possible

Some issues

• WebKit browsers (Safari and Chrome) deal with page fragments in a very odd way. If you follow an in-page link on one of the browsers (one that ends in #somethingorother) the viewport of the browser moves, but the keyboard focus doesn’t
• Earlier versions of Internet Explorer will only move the keyboard focus is certain circumstances (to do with hasLayout), otherwise it behaves in a manner similar to WebKit.
• Making the skiplink visible to keyboard users but hidden from mouse users can be difficult to acheive cross-browser

So what did we do?

Our latest version of the skip link code targets WebKit browsers using javascript (not ideal, but the best solution currently available) and uses a specific combination of HTML and CSS to ensure that it works for Internet Explorer 5.5, 6 and 7. IE 8 thankfully seems to be a bit more sensible than its predecessors and behaves somewhat more like a proper browser.

The result can be found on the example skip link code page – take a look and let us know what you think!

A word about WAI-ARIA

WAI-ARIA is an upcoming standard that specifies a bunch of ways to make rich internet content accessible. Part of the standard defines something called Landmark Roles, and although this is only a draft support for this is already implemented in a number of modern browsers. Landmark roles provide a way of marking what each part of your webpage is about (e.g. which bit is main content, which bit is navigation, which bit is complementary content, etc.). The Pacielleo Group has a great blog post on landmark roles that explains what they are and how they work. Where supported (e.g. in the screenreader JAWS 10), these roles provide a fantastic way of navigating around the page, far superior to using skip links. Hence we now recommend that WAI-ARIA roles are implemented on your page as well as skip links, to provide the best possible experience for as many users as possible. And before you tell us, we know they don’t validate, but in line with WCAG 2 we take a flexible view on such matters… (see Success Criterion 4.1.1: Parsing)

Anyway, that’s enough waffle from us. If you haven’t got bored and gone there already then head on over to the example skip link code page and have a look. Post any comments back here, we’d love to hear from you!

Now that WCAG2.0 is out there and being used day-to-day, time to update all your links.

To refer to and link to the latest completed version that is the recommended Web Standard, do not include a number, for example:

Authoring Tool Accessibility Guidelines (ATAG) http://www.w3.org/TR/ATAG/
User Agent Accessibility Guidelines (UAAG) http://www.w3.org/TR/UAAG/
Web Content Accessibility Guidelines (WCAG) http://www.w3.org/TR/WCAG/
Accessible Rich Internet Applications (WAI-ARIA): http://www.w3.org/TR/wai-aria/

Only include the numbering (e.g. http://www.w3.org/TR/WCAG20/) if you need to link to a specific version, and not to superseding versions.

Most references to WCAG should link readers through to the WCAG overview, rather than dumping straight into the technical specification. The overview is at www.w3.org/WAI/intro/wcag

We get asked this question a lot. shouldiusetablesforlayout.com seems to sum up the general view of both SEO and accessibility specialists.

The Priority Trust gives physically disabled children and young people greater independence by funding mobility equipment and sharing experiences; helping them to participate in society as independent, mature and responsible individuals and achieve their potential.

Communis are very pleased to have been chosen to develop their new web site, which can now be seen at www.prioritytrust.org. Please take the time to pay a visit.

WCAG2.0 has arrived! The bouncing baby new de facto accessibility standard arrived into the world yesterday – December the 11th, 2008.

Being the accessibility obsessives we are, we eagerly tore open the metaphorical wrapping paper and started to play with it without reading the instructions. Unlike previous versions released, this is the stable standard and can be referenced with confidence. It’s not going to change again for a long time.

So, first impressions… I’m very pleased to see how thoroughly and extensively the W3C have consulted with the web community about this document – I was also pleased at how the contributions from developers (like us) and ordinary users (like lots of people we know) have been integrated and treated with as much care and respect as if they had come from Microsoft or Mozilla. This is not imposed from on high, this has emerged, flower-like from the contributions of the community as a whole. As a concrete example, we thought the previous ‘beta’ version was not the easiest to read. So we suggested an alternative. They responded with some thoughtful and constructive criticism, which we acted on, and then the improvements to the styling were gracefully implemented. A second example. I wrote in at one point a few months ago querying one of the requirements that asked for ‘liquid’ site designs. I disagreed. One of the team working on the document responded, disagreed right back, but very gracefully, and I amended my criticism to take into account some of the good arguments they raised. The result? The language around that checkpoint is now clearer takes into account my concerns. Again, I am very impressed by the development process.

WCAG2.0 is best thought of as a set of 4 mutually supporting documents – the first is main WCAG 2.0 document, containing the guidelines in a form that would be useful for technical specification, legal requirements etc. The second is the Understanding Wcag2.0 document, which goes into more detail about each checkpoint. It explains, in fairly straightforward language, the intended effect of the checkpoint, the benefits of implementing it, and gives some concrete example situations in which it should be applied. When you consider what was available for WCAG1.0, the improvement is immense, especially when considered alongside the Techniques document that gives more examples including mark-up to support them. One tiny niggle is that the styling breaks down slightly in Google Chrome, but this will doubtless soon be resolved.

The piece de resistance is undoubtably the customisable quick reference, billed as a ‘a key resource for designers and developers using WCAG 2.0′. I have to agree . This is a shorthand set of all guidelines and references that can be customised to display only those that apply to you site. If you aren’t using any rich internet apps (RIAs) then just switch off the WAI-ARIA applicable guidance. Couldn’t care less about SMIL? Then strip those references out with the click of a mouse. Or, this being WCAG, the prod of a key. Or the wave of a head-wand. Improvements could be made – for example, I’d like to kill all audio/video references if I’m not using them, but otherwise, a great effort.

A valiant attempt has been made at WCAG2.0 Documents to show how they fit together.

All very well, you may say, but what is it like to use in practice? I threw it at a wireframe I was building, and it was very interesting. Firstly, it’s less prescriptive… and the result is that it makes you think more. Techniques are referred to as ‘sufficient’ – in other words, you could meet the success criterion by doing this, but if you can come up with a better way? Why, go right ahead. There’s enough information there about the intent and benefits of meeting that criterion that allows you to make a clear cut decision about whether your alternative method is a reasonable substitute.

The AAA guidelines – always a contentious subject in WCAG1 (did anyone ever use access keys without messing up the functionality for some users, somewhere?), are far more sensible. For example,

Contrast (Enhanced):
1.4.6 The visual presentation of text and images of text has a contrast ratio of at least 7:1, except for the following:

Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 4.5:1;

Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.

Logotypes: Text that is part of a logo or brand name has no minimum contrast requirement.

Firstly, this is very easy to see whether you have passed or failed. Secondly, it’s a similar but stricter version of the AA requirement. Thirdly, it gives you a get-out clause for branding/logos. If part of the brand value is ‘extremely subtle’, then you can keep that pale grey on white logo. But that body text had better be readable.

All in all, looks great. I look forward to applying it to many projects to come.