Tutorial #47
Web Accessibility Background   2014-01-29


Fundamental to the Web is the wonderful idea that anyone who can get on the Internet can access and view any web site that is out there, regardless of who they are or where they live.

But for some people with disabilities the reality can be very different. The clever JavaScript interactions and animations that we enjoy creating can make it impossible for Screen Reader software to navigate properly. Subtle color schemes that look great to a designer can be unreadable for people with poor eyesight. Touch screen gestures can effectively block out certain users with hand tremors.

Building hardware and software that support Universal Access is a very difficult problem but it is a goal that we all need to work towards. Hardware companies help with good design of input and display devices. Operating System and Web Browser developers support custom settings for font size, screen color schemes, mouse click sensitivity, etc. and create new technologies like Speech Recognition, Speech Synthesis, Webcam video input, etc.

But ultimately what matters if the Web Content which designers and developers like us create. We have to take responsibility for that and ensure our sites are accessible by as many people as possible.

In this Background Tutorial I want to discuss some of the issues surrounding Web Accessibility, show how we can audit our sites and describe some simple steps that we all use in our work Today.

Your site doesn't have to be perfect... but every little step helps... and it's easy...

Why should we care about Accessibility?

Paying careful attention to Web Accessibility involves effort and, most likely, changes to your web sites and style of coding. So not surprisingly some people are going to resist the idea and will ask the question 'Why do we care about this?'.

1: It's the Right Thing to do

Obvious, really...

2: Self Interest

I want to be using the web until the day I die. Chances are that I will have to deal with some combination of poor eyesight, hearing loss, arthritis and maybe something serious like stroke all of which make using the Web that we have today very difficult.

By working to improve Accessibility for everyone now we can help make it a best practice that will become the default over time.

3: Business Interest

People with disabilities buy things and use services. If they have a choice between a site that accommodates their needs and one that doesn't, where do you think they will spend their money?

4: It's the Law

In many countries there are regulations that apply to web accessibility. In the USA the Section 508 Amendment to the Rehabilitation Act of 1973 requires that all all Federal information that is accessible electronically must be accessible for those with disabilities. Alongside this is the Americans with Disabilities Act which, if anything, has more legal 'muscle' behind it than Section 508

The Web Accessibility Initiative has a full list of National Policies and Regulations

To date there have not been a lot of legal cases brought that involve web accessibility, but that does not diminish the importance of these regulations. If you are working on a government site, or one as part of a government contract, then you need to do your homework on the requirements.

OK, but...

... disabled people don't use our site

How do you know that? I can't look at my usage stats and figure that out.

You might make an assumption that your site for a car dealership, for example, does not have users that are blind. But blind people have spouses and family who buy cars. Beware of making assumptions about users

In many cases it may be true that people with certain disabilites do not use your site. But you have to ask if that is because your site is difficult for them to navigate? It's a 'Chicken and Egg' situation.

... we can't make our content accessible

It is certainly true that some types of data and graphics are very difficult, and perhaps impossible, to make fully accessible to all users.

Examples might include making an interactive map, like Google Maps, accessible and useful to someone with very poor vision. A Screen Reader has no, or little text, to read to the user. I work with complex alignments of DNA and protein sequences. A Screen Reader could output that content but it would be meaningless in that form.

So in practice, not everything can be made accessible to all users. But even here we can see if we can make it easier for a subset of users with disabilites. For example, changing the colors and contrast in a map might make a big difference to someone with poor vision.

... we can't afford to make our site accessible

Many, perhaps most, web sites have little or no funding and many commercial sites have very tight development budgets. Asking for time and effort to add features that impact a subset of potential users can be a hard sell and a very legitmate concern.

The good news is that you can do a great deal to improve accessibility with simple design and coding choices that take just as much effort as the code you are already writing.

How do I know if my site is Accessible?

There are several tools available that can help you pinpoint problems with a site and suggest solutions.

WAVE (WebAIM web accessibility evaluation tool) is a useful first start. You give it the URL of a page and it renders it in a frame along with annotation that highlights issues. Here is a screen shot of the tool using the The Guardian front page as its target.

Image 1 for this tutorial

Clicking on an icon displays a popup with more information.

Image 2 for this tutorial

Here is the left hand panel in close up giving a summary of the errors and warnings.

Image 3 for this tutorial

Google's Accessibility group has developed the Accessibility Developer Tools

extension for the Chrome web browser. Install this, open up the Developer Tools panel in Chrome and look under the Audits tab. When you select the Accessibility audit and run it on your target page you will see output similar to this (run on the Guardian home page):

Image 4 for this tutorial

Each Error or Warning can be expanded to show the problem with a link to the relevant section of the Accessibility Developer Tools.

Image 5 for this tutorial

Image 6 for this tutorial

I find these audits to be very useful and a very nice addition to the excellent Chrome developer tools.

In addition to these tools there are companies and organizations, such as WebAIM who will perform comprehensive audits for you.

But audits can only take you so far. Ideally you would have several people with different disabilities who would evaluate your site for you but that would require considerable effort and expense.

One step that you can take is to put youself in the shoes of someone with poor vision and see how your site appears to a user of Screen Reader software, which extracts the text and outputs it using Speech Synthesis.

ChromeVox is Google's Screen Reader extension for the Chrome Browser. It is well worth installing this, enabling it in the Chrome Extensions page and then going to your target page. Keyboard navigation in ChromVox is pretty complicated, which seems counter-intuitive for a screen reader - take a look at ChromeVox Keyboard Shortcuts. On MacOSX you use Ctrl + Cmd as the ChromeVox prefix key.

I find this a very sobering experience as you will quickly see how frustrating it is to read a page in this way. Regular text is not too bad but try reading a block of code. Here is an audio clip of some regular text as I step through each block with Chrome Vox:

How can I make my Site more Accessible?

The good news is that it's not that difficult. There are a number of simple design and coding choices that can make a big difference to the accessibility of your site which take no more effort than what you do today.

Use Semantic Markup

The basic idea behind CSS and HTML is the separation of content and style. You should be doing this on your pages anyway, but in terms of accessibility it really matters.

Semantic Markup is jargon for tags that tell you about the structure of your document, such a h1, h2, etc. that indicate a heirarchy, as opposed to div which is a generic tag that could mean anything.

Many of us, including myself, will use tags like div class="header", along with a CSS class, instead of using h1 and overriding the default h1 styles in CSS. Use h1, h2, etc. - these tell a screen reader the basic structure of your document, allowing the user to jump between sections more easily.

HTML5 adds a number of semantic tags that indicate document structure more clearly. These include header, nav, section, footer, and article. Think about using these in new sites that you create.

Use Descriptive alt text with all images

Screen readers rely on the alt attibute in img tags to tell the user what the image represents, so it is important to make this descriptive. Something short like photo of dog really isn't enough - something like Photo of a dog wearing a santa claus hat tells you so much more.
(Yes, I know I'm failing at that with the screen shots on this site... working on it...)

Include labels with all form fields

Every input in a form will likely have some descriptive label next to it, but this isn't enough. Instead use an explicit label tag pair around that text.

Think carefully about color combinations

Color Blindness is a complex subject in which the most common form, Red-Green, affects up to 10% of males. Choosing the wrong combination of colors for you web site can cause problems for a large number of your users.

Beyond this you need to think about Color Contrast. Subtle combinations, such as light gray text on a white background, are commonly used to demphasize some text relative to others (I do that on this site). But that can be be difficult for some users to see. The Google tool can help you find combinations that have 'enough' contrast to avoid this problem.

For a good article on color selection take a look at this article from Microsoft.

Provide guidance on form navigation

The tabindex attribute is a really useful way to quickly guide a user through the elements of a page. Typically they have been used in forms to speed up data entry, but in HTML5 they can be applied to any element. For users with poor vison as well as those with, say, wrist problems they can help navigate a page with a minimum of mouse movements.

Similarly, it is helpful to all users, to set the focus the first input field in a form without them having to move to and click. Previously you would do this with a snippet of JavaScript but with HTML5 you can add the autofocus attribute to an input, just by itself, to accomplish the same thing.

Include ARIA attributes in new web sites

The basic changes shown above, and those like them, only get us so far with accessibility. They don't help much when we use JavaScript functions to control navigation, to display dialog windows, manipulate forms, etc. WAI-ARIA (Accessible Rich Internet Applications) specifies a number of new attributes that can be added to existing HTML tags to help guide screen readers in complex pages. Mozilla have a good Introductory Tutorial on the topic. ARIA does require some investment of time to learn and implement it correctly but it does represent the way forward.

We can all do something to improve the accessibility of our sites. Even small steps can make a big difference... we just need to take those steps...

More Information

WebAIM - Web Accessibility in Mind, Utah State University

Google Accessibility Developer Tools

ChromeVox - Screen reader

WAI - Web Accessibility Initiative

WAI-ARIA - Accessible Rich Internet Applications Suite

US Government Section 508 site

Google Accessibility

Euan's Guide - a good example of a site designed with good accessibility in mind

BBC Accessibility Help

Share this tutorial

Comment on this Tutorial

comments powered by Disqus