Accessibility and Access Keys

Skip to Content

How to make PDFs WCAG2.0 compliant

13th July 2011 by Liam McGee

A recent email about PDFs from Wayne Dick, W3C working-group buddy, got me thinking about WCAG2.0, PDFs and whether W3C missed a trick in not pushing hard enough for a formal separation of styling (look and feel) from content (text, and informational relationships between text (such as headings)).

The W3C has always been somewhat hamstrung when it comes to offering guidance on making particular proprietary technologies accessible because of their (very sensible and understandable) restrictions around vendor neutrality. We at Communis would certainly support a e-publishing-specific set of best practice (a bit like the mobile web best practice), which could cover PDF, as well as e-book formats such as ePub (the latter especially, as it has the advantage of being free, open source and quite well supported by hardware vendors), and perhaps we’ll prod the working group about it.

But onto Wayne’s specific point about PDF, namely, that a PDF can claim WCAG2.0 compliance while still being inaccessible to Low-Vision users. Wayne’s point was that you can’t set your own user preferences for font face, colour, and so on. this is really important for many low vision users. As Wayne says:

The most important barriers for visual readers with low vision are typographic. The visual style preferences of people with full sight shut readers with low vision out of reading most text. Font sizes, visually confusing font faces like Times New Roman, kerning, single spaced lines and disorienting color schemes like the standard black print on white background are just a few factors of presentation that combine to impair perception of text.

The difficult problem is that each visual reader with low vision experiences a different combination of typographic factors as barriers to reading. Some prefer normal font size. Others need large font. Some require high contrast. Others need low contrast. Low vision is not just one disability; it is a cluster of disabilities. The typographic solution for this group is to give each person a custom choice of typography, a typographic prescription.

The thing is, there is a separation of style from content, at least in the underlying code (assuming that the PDF is produced with accessibility in mind – so far, so much like web pages). The ability to change the font is part of the PDF technology, it’s just that the Adobe Reader tools to make use of that are a bit ropey. Reader already allows the user to set a default foreground/background colour scheme (Edit>Preferences>Accessibility – Replace Document Colors). So all that is left is the ability to change the font face… If you have Adobe Acrobat, for example, rather than plain ol’ Reader, the Tools>Advanced Editing>TouchUp Text Tool allows you to change the font face (and style) and fill colour of selected text. A hook into this capability would be technically feasible (LiveCycle, for example, turned on bits of Acrobat in Reader), one that would allow wholesale edits to font face/style (e.g. replace all fonts with verdana).

So… PDF content, could cheerfully comply with WCAG2.0 1.3.1 (Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.), and 1.4.8 (Foreground and background colors can be selected by the user).

All we need now is for someone to fund us to develop it. Anyone?

2010 Equality Act and Accessibility

1st October 2010 by Liam McGee

The new Equality Act comes into force today, the 1st October 2010. It draws together a raft of legislation previously scattered throughout a variety of other acts, including the Disability Discrimination Act (DDA).

The full text of the act can be found at the snappily titled, and a little digging has unearthed the following items of interest to website owners and website developers.

  1. The act applies to websites: SCHEDULE 25: Information society services
  2. The act defines reasonable adjustments: SCHEDULE 2: Services and public functions: reasonable adjustments
  3. The act is in part a response to the Directive on electronic commerce
  4. The duty to make adjustments includes:
    • a requirement “where a provision, criterion or practice… puts a disabled person at a substantial disadvantage in relation to a relevant matter in comparison with persons who are not disabled, to take such steps as it is reasonable to have to take to avoid the disadvantage”.
    • a requirement “where a disabled person would, but for the provision of an auxiliary aid, be put at a substantial disadvantage in relation to a relevant matter in comparison with persons who are not disabled, to take such steps as it is reasonable to have to take to provide the auxiliary aid.”
  5. Regulations may make provision as to “things which are, or which are not, to be treated as physical features”; “things which are, or which are not, to be treated as alterations of physical features”; “things which are, or which are not, to be treated as auxiliary aids” (Section 22)
  6. “A person (A) discriminates against a disabled person (B) if— A treats B unfavourably because of something arising in consequence of B’s disability, and A cannot show that the treatment is a proportionate means of achieving a legitimate aim… (Section 19)

More when we get a moment to plough through the detail. Or, if anyone would like to have a go themselves in the meantime and comment…?

Google Love

19th May 2010 by Liam McGee

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

How to complain about inaccessible websites

2nd February 2010 by Liam McGee

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

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 [], 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 [] 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 []. 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 [] 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

I hope you hear back from the fitness association.


At this point the user received no further communication. The MoreActive4Life closed on 31st 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 [].

Dear Sir/Madam,

Last month I used the contact form on 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,

***** *****

Tel: ***********

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 29th September 2009 receives no call back and it is not until the user takes it upon themselves to email again on 12th 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 31st 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.

Ouch. Sorry about all that, friendly web user. Any one else out there with similar experiences?

Business Case for Accessibility

4th January 2010 by Liam McGee

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.

Happy New Year!

SEO and Accessibility Overlap

6th August 2009 by Liam McGee

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

Visibility of the Keyboard Focus: Good and Bad

9th June 2009 by Paul Ratcliffe

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 and bad (like example sites if you have any suggestions.

Skip links: Chrome, Safari and Added WAI-ARIA

2nd June 2009 by Paul Ratcliffe

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!

Referencing W3C Accessibility Guidelines

6th March 2009 by Liam McGee

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)
User Agent Accessibility Guidelines (UAAG)
Web Content Accessibility Guidelines (WCAG)
Accessible Rich Internet Applications (WAI-ARIA):

Only include the numbering (e.g. 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

Should I use tables for layout?

17th February 2009 by Liam McGee

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