Accessibility

Keyboard accessibility is one of the most important aspects of web accessibility. There are a whole host of reasons why certain users will find mouse usage difficult or impossible. Some users may have no use or limited use of their hands or arms and rely on the keyboard or alternative input devices to navigate websites. Blind people using screen reading software almost exclusively rely on keyboard navigation.

Recently, in my role of auditing websites for accessibility, I have come across a number of websites that make keyboard navigation impossible, because critical sign-posting allowing users to see where they are on the page are missing.

When keyboard users navigate websites, they jump from link to link using the tab key. They can see where they are on the page because the link with the focus has a dotted border around it. These borders should be visible by default, like they are on the BBC website but on a number of websites I have visited, they have been removed. Maybe the web designer considered them ‘ugly’ and removed them (this can be done by setting the physical appearance of the ‘outline-style’ property to ‘none’) because they spoilt his or her design of the page, not realising the huge impact this has on users with disabilities.

Dotted borders on the BBC website appear
around links that have the current keyboard focus.

The simplest way to ensure that a visual indicator is present is to do nothing and let the dotted borders appear by default. However, these dotted borders are not always easy to see, especially if background colours are being used. To make them obvious, CSS techniques can be used to display a different background colour when the link receives the focus. This is a great technique and can be seen in action on the Easy Slideshare website.

Links with the current keyboard focus can be made
more obvious by adding a different background colour. 

A clear and distinct visual indicator is essential for sighted users that rely on keyboard navigation. Without them, websites become impossible to use as users are not able to see where they are on a page.

When you read the accessibility policies on some websites, you get the feeling that the site owners are making a statement about how clever they are, and not about how committed they are to helping their visitors. All the stuff about WCAG and compliance levels is of no interest at all to site visitors, even those who use assistive devices, and the average site visitor cares even less about how you’ve marked up your tables or tested the site.

The lack of attention to user needs is shown above all in the way that that sites use ‘accessibility’ as a link title, when any user experiencing a problem is more likely to be looking for ‘site help’.

It is important to publish an accessibility statement, but it must be focused on the user’s needs. A few lines, such as those used by Lloyds TSB, are enough to assert your commitment to accessibility. After that, you should consider your accessibility policy to be more of an instruction manual for the site than a guide to how it was coded.

You should include instructions for any features you have introduced to improve accessibility, including, for example, details of any access keys you’ve configured or any on-screen buttons for increasing font size. Many users will be unaware of browser features they can use to improve their experience, but there’s a limit to how much information you can be expected to provide. Rather than reinventing the wheel, you can link to the BBC’s My Web My Way website, which has detailed instructions for using the accessibility features in popular browsers and operating systems.

You should be candid about any limits on your site’s accessibility, too. Tell your visitors about any sections that will require Javascript, or where a new window will open without warning. Let them know what plans you have to address these shortfalls, and about any workarounds that can make that content accessible.

Accessibility is a journey, and you should invite your visitors to travel with you. Provide a feedback mechanism so you can find out what problems your users experience and what fixes they can suggest.

If you’re looking for inspiration, try Legal & General, Radio Times, Tesco, and Lloyds TSB. They don’t all get everything right, but they do put the user at the heart of their accessibility policy.

In a consultation document entitled ‘Delivering Inclusive Websites‘, the UK government has threatened to withdraw the .gov.uk domain name from any websites that do not meet its minimum accessibility standards.

The problem is that the new consultation document could encourage box-ticking over true accessibility. On the plus side, ‘Delivering Inclusive Websites’ acknowledges the role of user testing and endorses the PAS 78 guidelines for commissioning accessible websites, which were co-authored by the Disability Rights Commission. But the consultation document defines an accessible website as one that satisfies the Level AA requirements of the Web Content Accessibility Guidelines. As we reported last issue, many of these are obsolete and some can be counter-productive. There’s no indication of which version of the guidelines the UK government wants to enforce, either.

Websites have until December 2008 to become accessible or face the chop. At least, that’s the theory. There is already a rule that .gov.uk domain names that point to inaccessible sites might be pulled, but it’s never been enforced. And if it were, it would mean denying many people access to government services because a minority of people cannot access them as designed. The solution is to make the sites accessible for everyone, not to give up on them altogether.

The government’s strategy is to cut the number of websites it operates, which should make it easier to enforce consistently good design. But it’s important that it focuses on usable accessibility, and doesn’t confuse the WAI checkpoints with a ‘to do’ list. As the government defines accessibility for vital services like the NHS and Inland Revenue, it is important that it writes guidelines that can evolve with technology, and that can provide everyone with equal access to information and services.

Ajax has been called ‘rollerskates for the web’. It’s a fitting description because it makes things go faster, there’s the risk of doing some serious damage and a lot of people don’t know how to stop.

Even if you don’t know the jargon, you’ll know the effect: When an ecommerce site updates the shopping cart in the corner, or Gmail opens an email without clearing the screen, that’s Ajax. It’s about changing a webpage without refreshing all of it. The technique can create a more fluid user experience, with less of the stop-start associated with having a page refresh for every action. But it does bring problems of its own.

Because the browser’s history stack is not being used, the back button usually fails. Clicking it could take the user several steps back in a transaction funnel, or could undo several actions when the user only wanted to rewind one step. Site designers should ensure that page refreshes occur at points where the user might want to ’save’ their progress. Software back buttons can be added within the webpage, but users will still instinctively reach for the browser’s back button and will be frustrated if they lose too much work.

Ajax can also prove confusing, particularly for users of assistive devices like screenreaders or magnifiers which concentrate on part of the page at a time. If updates are made to parts the user isn’t viewing, feedback will be missed. Some have joked that Ajax stands for ‘accessibility just ain’t exciting’ and it is still hotly debated whether you can use Ajax and still have an accessible website (Ajax actually stands for ‘asynchronous JavaScript and XML’ - see, you’re pleased you asked now). Standards campaigner Jeremy Keith has developed a methodology called Hijax which is based on standard web navigation and form features, and uses JavaScript to hijack them when available.

The latest versions of the Jaws screenreader (version 7.1 and higher) can notify users of updates to parts of the page. Screen reader vendors are updating their technologies to keep up with changes, but it’s expensive to upgrade and many users will already have an older version that doesn’t support Ajax.

There is a role for Ajax: it is particularly strong when used for form validation or for updating shopping baskets, and it can be accessible when Hijax techniques are used. Features like drag and drop (which are more difficult to make accessible, and which will never be accessible to some people, including those who cannot see the screen) can enable new online activities that ten years ago would have been unthinkable on the web. But it is essential that Ajax sites are fully tested with a wide range of users to ensure that they are accessible to everyone.

By Lis Angle

Email is the most personal bulk communication medium, but any attempts to customise your content will look clunky if the message template is inaccessible.

When creating HTML emails, you need to follow the W3C guidelines for accessible websites as closely as possible. Email won’t allow external stylesheets, so you’ll need to embed inline styles, but most principles apply equally to websites and emails.

Here are our top tips for creating accessible HTML emails:

• Don’t use absolute font sizes. Use percentages and relative sizing so that the user can easily adjust the text size on their screen.
• Use logical headings, marking up your top level heading with a H1 tag, and subheadings beneath it as H2 (and sub-subheadings as H3 if you have them). Don’t use structural mark-up for aesthetic purposes, or fiddle with fonts to create titles that should be structural headings.
• Structure your content logically too: have one idea per paragraph. To make it easy to follow, particularly when it’s read aloud, use the simplest language that will convey your meaning.
• Make your newsletter’s top heading (H1) the same as the email subject line.
• Make sure link text is meaningful. Users of assistive devices will often summarise a page by its links.
• Provide alternative text for all images. This has benefits beyond accessibility because many standard email clients will block images by default as a security measure.

You should accompany your HTML email with a plain text version, so that users can choose which version they prefer. Plain text is not inherently accessible - you need to create it with some care. The Text Email Newsletter standard suggests that you, for example, should include a contents section at the start and should not use visual formatting such as italics to convey tone or information. It also suggests numbering each story item and warns against using lines of symbols such as asterisks to divide up sections. If you do that, screenreaders will annoyingly read every symbol out loud.

Screenreader users might prefer HTML over plain text, so they can more easily search for headings and links thanks to the additional markup. As with all accessible interfaces, the secret is to provide enough redundancy for users to access information how it is most convenient for them.

Not only are accessible emails easier for users of assistive devices, but they will also degrade more gracefully on mobile platforms. As more and more people surf using BlackBerrys and smartphones, an accessible email template will help ensure your message gets across.