10 things you should know about web accessibility

by Ben Allen on August 16, 2010

The diversity of information on the web is only matched by the diversity of people using it. For me, that’s what makes the digital user experience profession so fascinating – trying to understand all users of the web and how they engage with it so that you can provide a top quality experience & produce a satisfied consumer.

One audience which is often forgotten by our profession are those users who live life with some form of disability. How do we make the web usable for these users? That’s the question which feeds my passion for web accessibility.

New to web accessibility?

“What is web accessibility?” I hear you cry. If you’re new to web accessibility I highly recommend WebAIM’s excellent introduction to the topic and the Web Accessibility Initiative’s “what is web accessibility?” guide. Once you get the principle of accessibility – read on. I want to address some common issues I’ve often faced when I’m quizzed on web accessibility. A list of common questions & issues and what I consider to be a good response based on my research over the years.

10 things you need to know

My list covers a range of familiarity with web accessibility and a range of skill sets. Hopefully they’ll be a little something for all readers.

1. I don’t want to break the law. What guidelines do I need to follow in order for my site to be accessible?

Sounds like an obvious question. The answer is a little complex as there is a difference between international guidelines that you should follow and legal requirements that you need to follow.

First, let’s look at the guidelines. The World Wide Web Consortium (W3C) have a Web Accessibility Initiative (WAI). The WAI develops guidelines widely regarded as the international standard for Web accessibility. The guidelines which address web content are suitably named the Web Content Accessibility Guidelines (WCAG). These guidelines have 3 levels of compliance: level A, level AA and level AAA.

The WAI suggests that all websites must comply with level A success criteria. If you’re site does not meet this minimum standard then it’s likely that your site is completely impossible for disabled users to use. The WAI suggests that web sites should comply with level AA success criteria so to ensure most disabled users enjoy a good experience. In the professional circles I belong to level AA is seen as a good standard of accessibility.

I mention the guidelines first as some laws use these guidelines as a basis for judging accessibility. The law that applies to your site will depend on where you’re doing business. In the UK web accessibility is covered by the Disability Discrimination Act (DDA). In the USA web accessibility for Federal Agencies is covered in Section 508. Other businesses in the US will have to consider State law too. Target.com being one famous example where State laws were discussed.

In the case of UK law and in general, where strict accessibility law is in place, the best way to understand whether you meet appropriate legal criteria is to test your site with disabled users. In the UK charities exist which will help test your site. AbilityNet, for example, is one I have worked with. In the USA non-profits like WebAIM provide a similar service. For most businesses this level of commitment might be too much and in this case I would strongly recommend that you hire a web agency who understands how to design and develop accessible websites (like the agency I work for) and put level AA accessibility in your requirements. If your responsible for designing and building your site yourself I would suggest that you get familiar with WCAG and build a site that meets level AA success criteria.

Remember WAI guidelines don’t guarantee that your site is accessible. Ultimately testing is the best method because your end goal should be making your site easy to use for disabled users and not simply meeting guidelines.

Related links:

2. Can I get a piece of software to test my site against accessibility criteria?

There are tools which can give you some indication of how accessible your site is. Automatic tools are great at helping with a preliminary review of your site and helping manual evaluators identify possible problems. The guidelines produced by the WAI need more than an automated check to ensure you do a proper evaluation as there are guidelines which automatic tools simply cannot test. The tool which I use the most in my preliminary tests is WedAIM’s WAVE toolbar for Firefox. Loads of other tools exist and I strongly suggest you read the WAI’s guide on selecting tools before you go too tool crazy.

3. Is accessibility all about making my site work for blind users?

In a word – no. Blind users are just one segment of the disabled community. There can be a lot of emphasis given to making sites work with screen readers but accessibility means more than just “good in screen readers”. Users may live with different types of disability such as visual (blindness, low vision, colour-blindness), hearing (deaf), motor (inability to use a mouse, slow response time, limited fine motor control), cognitive (learning disabilities, distractibility, inability to remember or focus on large amounts of information). WebAIM do a great job explaining different considerations for these different communities.

4. Does accessibility mean that I cannot use JavaScript on my site?

No. It’s considered best practice to make your site content and functionality available to users with and without JavaScript. It’s a fallacy that disabled users don’t use software which makes use of JavaScript. Modern screen readers, for example, do a great job interacting with well written web sites that include JavaScript.

The WAI have been working on some great guidelines, called the Accessible Rich Internet Applications Suite, which:

“defines a way to make Web content and Web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies”

These guidelines are a great basis for making complex web applications which make use of the latest JavaScript techniques more accessible. There are lots of cool companies doing great things with ARIA already. Yahoo does have some nice, well documented, examples.

5. Can I use site overlays and still be accessible?

Site overlays, like Lightbox, are difficult to make accessible but not impossible. The overlay, user interface component, can be useful for numerous reasons and they can be used in many circumstances. So many in fact that it would be really hard for me to right up guidelines in just this post. Perhaps an idea for another day!

Things to consider when trying to make an overlay accessible would be:

  • will users expect an overlay? Can you distinguish links & buttons in a site which will open an overlay? For example – can you use visible text or text hidden with CSS or title text or icons to help users understand that an overlay is about to be launched?
  • is the overlay code positioned well within the HTML? Should the HTML for the overlay be next to the link or button that launched it?
  • where does focus go when the overlay is opened?
  • how do you close the overlay?
  • is the overlay and it’s contents keyboard accessible?
  • where does focus go when the overlay is closed?

6. Does my site have to have a liquid layout to be accessible?

A liquid or fluid layout refers to a site which changes it’s layout based on the width of a user’s browser. The logic goes that liquid layouts are a good thing because it makes full use of the user’s screen real estate – no matter how big or how small. There are lots of sites out there that have liquid layouts – useit.com, Amazon to name a couple of popular sites.

Rather literal interpretations of the conformance guidelines suggest that you need to test a site using numerous screen resolutions “to verify that horizontal scrolling is not required”. Some people interpret this to mean that every site must use a liquid layout. In my opinion this point of view is complete rubbish. None of the WCAG guidelines suggest horizontal scrolling make a site inaccessible and this is despite a direct mention of liquid layouts in the “techniques” section of the WCAG guidelines. This technique is documented as a method to help users read a web site when they want to resize text. Loads of alternative techniques are also suggested – techniques which do not require liquid layouts.

If that’s not proof enough consider this – the page where the conformance guideline is written will eventually lead to horizontal scrolling if you resize the window to a small enough size. My interpretation of this experiment suggests that the WAI were not suggesting “horizontal scrolling is bad for every screen width”.

My advice to you would be to use a fixed width site. Make a decision on page width based on the users who are coming to your site. If the vast majority, I’m thinking greater than 90%, use a particular resolution or greater then you should optimise for that number. For example 98% of visitors to this site use a screen resolution of 1024×768 or greater. About 18% are at exactly 1024×768 and that is why this site is optimised for that size. I don’t really fancy optimising for 1280×800 (the next size up) if I’m likely to annoy 1 in 5 of my readers!

I would also suggest making a mobile optimised version of your site. While iPhones and other smart phones do a really good job of resizing web sites and the text within them usability studies suggest that your users will get more done if your site is optimised for the smaller screen. If you use WordPress – this is super easy to do with mobile themes!

7. Do I have to add text resizing controls to my site to make it accessible?

Text resizing controls, as seen on AbilityNet’s site in the top right hand corner, is a technique for meeting the resize text guidelines within WCAG 2. It is one way of meeting the success criteria. Plenty of other methods exist. It is not necessary to have text resize controls to make your site accessible. If you don’t believe me – try to find the resize controls on the WAI site. Good luck!

8.  The guidelines are not written in “plain-English”. Are there any cheat sheets available?

There are no short cuts to creating an accessible web site. If you’re committed to creating accessible content then someone in your team needs to know the guidelines inside and out… public service announcement over.

Sometimes it is handy to have a quick reference providing you know it’s just that and not a substitute for the full guidelines. I use a couple from WebAIM:

9. What are the business benefits of accessibility? Is accessibility worth the effort?

I love this question. If you don’t subscribe to the point of view “do accessibility because it’s the right thing to do” what else can you get out of an accessible web site? Here are a couple of great benefits I always talk about:

  1. You get access to more customers! If you’re site is accessible more people can access your site and help improve whatever conversion rate you hold dear. If your site is more accessible than your competitors, all other things being equal, you will have a better shot of reaching your goals because lots of different types of user will be able to access your site.
  2. Search engines love accessible sites. A friend told me once that he was at an SEO workshop and the instructor said “the DDA was the best thing that could have happened in the SEO industry”. What did he mean? Well… accessibility is about making web content accessible to your users. WCAG guidelines help make your site better by making it easier for software to interpret the content on your site. Guess what? The robots used by search engines to crawl the web is software too. Software which is trying to make sense of your content. Investing in accessibility will mean you’re making a massive investment in SEO too.

10. Who do I need in my team to get an accessible site?

I’d suggest that accessibility is a team game. Here’s why:

  • Project sponsors & Project Managers: need to be bought into accessibility. They need to empower the team to get the job done right
  • Information Architects & Graphical Designers: need to design a site which can be made into an accessible solution. It is possible to design a site which is very hard or impossible to make accessible
  • Developers: need to write solid, standards compliant code which can be easily interpreted by screen readers and other forms of assistive technology
  • Testers: need to make sure everybody did their job!

Breaks in any piece of the chain will lead to a bad solution.

Final thoughts

I love businesses that are obsessed by the quality of their customer experience. I find this kind of attitude inspiring. These kind of companies ooze a sense of “don’t worry we will take care of you. You cannot go wrong with our product or service”. Isn’t that the greatness projection of any brand? If you’re serious about quality on the web and delivering the potential of the web to all it’s users I’d suggest you need to take accessibility very seriously indeed.

Over to you

Feedback is always welcome!

  • what has your experience been like with web accessibility?
  • do you work for a company that takes accessibility seriously?
  • what other common questions arise when web accessibility is being discussed?
  • have you worked on any projects which utilise ARIA? How have they gone?
  • what do you think of the questions & issues above? Can you relate to them?
Share and Enjoy:
  • Twitter
  • del.icio.us
  • Reddit
  • Digg
  • Sphinn
  • Google Bookmarks
  • FriendFeed
  • LinkedIn
  • StumbleUpon
  • Facebook
  • Technorati

Leave a Comment

Previous post:

Next post: