Simple steps towards building an accessible site: part 2

By Henny Swan

Alternative content

Not all types of content can be accessed by all of people, hardware or software so alternative formats are needed.


Images can’t be seen by people with sight problems and are not supported by older mobile handsets or text-only browsers such as Lynx. An alt attribute must always be provided as an alternative ie alt="Short image description". This text is then read by a screen reader (software used by blind users to read the content of a web page), or is rendered by the mobile or text-based browsers as an alternative to the image.

An image with alt text shown as a tooltip

If the image is decorative you simply give it a null alt attribute – alt="", – and the image will be ignored altogether. Complex images should be given a longer description (elsewhere on the page, or linked to from the image).


Video is not available to people with sight problems, some mobiles and devices, and people on low bandwidth. Ideally you should provide captions, audio description and sign-language versions, and if not, at the very least a text transcript and brief description of the video. Google this week announced they will be supporting automated captioning for YouTube video’s and you can check out my article making video accessible, localised, mobile and searchable by captioning for tips and tricks.


Audio also needs text alternatives in the form of transcripts. The added bonus of this is that they can be indexed by search engines and boost your web page rankings. In fact, much of what you do to make pages accessible helps with SEO (Google is often referred to as the biggest blind user on the web.)

Device Independence

Many people don’t have the ability to use a mouse, including users with mobility problems, RSI, Parkinson’s disease, Multiple Sclerosis, sight problems and other dexterity related illnesses. In addition to this many mobiles and devices have small, fiddly keyboards and no mouse alternative.

All content must be keyboard accessible for users who can only use the keyboard. This means that all content and functionality must be available via the keyboard. Having informative text contained within title text or a fly-out JavaScript menu can be problematic so always ensure key information is available within in the page itself or via the keyboard.

Tab order

Tab order is very important for keyboard-only users who want to be able to cycle through related links and grouped form elements in a way that is fast, efficient and logical. Often you have to do nothing more than code content in a logical order with important links and information presented at the start of page content.

Tabindex should be avoided as it is difficult to maintain and easy to break. Simply having content coded in a logical order will address any tab-order issues so always make sure you focus on a logical flow of content there. The big exception is using negative tab orders as outlined in WAI-ARIA. This is used to give keyboard focus to dynamic widgets in a page such as sliders, tree menus, progress meters and so on.

Highlighting elements

Linked to tab order is highlighting elements within a page so you need can track visually where you are in a page. Many browsers, such as Opera, highlight links and form elements that have focus automatically however some designers choose to suppress this for aesthetic reasons – this is not advised.

As a general rule it is good to ensure that links are highlighted when they have received focus, are active or have been visited. This can all be done using the :focus pseudo-class in your CSS:

a:link { color: blue; }
a:visited { color: purple; }
a:hover { color: magenta; }
a:focus { color: magenta; }
a:active { color: red; }

Note the order of the above; certain browsers need these pseudo-classes in a specific order to stop one pseudo-class overriding the styles of another. The LoVe HAte meme should help you remember the order they should be in.

The importance of good copy

Well written, clear copy goes a long way to making content easier to read, as well as easily digestible by search engines. There are some very simple, easy to implement rules to follow if you want to do the right thing:

Link text

Link text should always be short and descriptive. Avoid putting links on your pages that say “click here”, “download”, “more”, “download” etc., and use words that describe the target page. This helps users when visually skimming a page including screen reader users who may access a list of the links on your page, navigating them out of context.

Good alternatives to “more” on a news website for example would be linking the heading name. Descriptive file names (including file type and size) are always preferable to “download” as well. Descriptive link text will also boost your search engine optimisation.

Be careful to avoid repeating the same link text, and linking it to different target pages. This can be a problem for voice input trying to activate a specific one of these links – they may not activate the link they want.

Headings and page titles

As with link text headings and page titles should also be short and descriptive for the same reasons. Just about anyone will find this helpful but especially people with reading problems, people who speak English as a second language and blind users.


Keep paragraphs of text short and to the point, ideally with one idea per paragraph. Don’t be afraid to reinforce meaning with good use of colour, layout and images. This helps deaf users, people whose first language may not be English and people with learning / reading difficulties, anyone else who struggles to read a lot of text on the screen – that’s most of us.

Remember that people rarely read web content from top to bottom and they generally skim read so lengthy text is not a good choice. Additionally use proper English throughout and avoid idioms and slang.


You will also want to choose readable fonts and set font sizes so they are flexible using em or %. This gives the user flexibility to scale text up or down to suit their reading needs although modern browsers tend to include in-build page zooms.

In addition to this you want to select fonts that are as easy to read on screen as possible. Typically these include fonts such as Ariel and Verdana. Chunks of italic or underlined text – that is not a link – are also best avoided. Not only are they hard to read on screen for many people mobile handsets have differing levels of support which can impact on your design.


Never rely on colour alone to convey information as some people can’t see colour – such as blind, low-vision of colour blind users – and others may be using a device that doesn’t support colour. On the flipside it;s good to use colour to reinforce meaning to help users read the page. An example of this is using alternative colours on rows of a data-table or colour to reinforce layout.

Always test your colour to ensure you have sufficient contrast too. This is one of the main accessibility problems on the web today. There are many tools available to help with this, Roger Johansson has a list of ten colour testing tools that are all very useful.

A useful book to read to give more depth to writing good copy is Steve Krug’s Don’t Make me Think!.

To wrap up

If you follow the above advice, you’ll be going a long way to producing websites that are accessible, viewable on mobile, localised and cross-browser compatible. To help you further, check out the Opera Web Standards Curriculum, which walks you through all the fundamentals you need to know about HTML, CSS, JavaScript, accessibility, colour, copy and more.

The costs of ignoring universal access is too high. In many countries – including the UK, United States and most of Europe – it is illegal to have an inaccessible website which means you could be taken to court. While this is unlikely to happen to a small website it is important to remember that court action not only costs money in legal fees but also in terms of your reputation and trust in your product.

Beautifully carved artificial legs

It is always better to build in accessibility from the start of a project too. You’re building web pages anyway so you may as well do it right from the outset, that way you don’t need to think about costly retrofits later on to bring the site up to standard. Some web site and web applications are so vast and complex that retrofitting for accessibility can run into millions. If built in from the outset however you stand to reap the benefits of additional customers and users at little or no additional cost.

On today’s web it is madness to not consider universal access and accessibility. By building sites with accessibility in mind you open your doors to the widest possible audience while creating a website or web application that is easier to scale, maintain and is future proofed as browsers (on desktop, mobile and devices) as well as assistive technologies evolve.

Henny Swan

Simple steps towards building an accessible site: part 2

I'm a web standards and web accessibility geek working at Opera. I also love kickboxing and cooking Chinese food having lived there for a number of years.

Always looking to hear from people interested in accessibility so drop me a line or check out my blog