Multi-tasking: Screwing everything up simultaneously.

13 Tips For An Accessible Site

Filed under: Accessibility, Markup

There are quite few “Top 10 Tips” around but I don’t seem to be able to get my favourite accessible design tips below 13. So here, for a change, is a baker’s dozen of tips to keep in mind when creating an accessible site or page.

  1. Be consistent

    If you are going to abbreviate standard words e.g. “Tel” for telepahone), do so in the same manner across the site. If the abbreviation is uncommon, or may be new to your readers, expand it in the first instance (e.g. “European Development Fund (EDF)” and use the ABBR tag thereafter. If your main site navigation is normally on the left hand side, keep it there right across the site. Don’t chop and change.

  2. Write content considerately

    Provide content that also reads well for those who will listen to it as well as those who see it. Be informative but concise. Remember that all users tend to skim page text rather than actually reading it, so keep the flowery or technical language to a minimum if you want to get your message across effectively.

  3. Be kind to keyboard navigators

    Provide visible skip links. Not all keyboard navigators have a visual impairment. Give sighted keyboard navigators the same opportunity to move around a page as you might offer to non-sighted users. Add link focus highlighting on all links so that sighted keyboard navigators do not become lost once they have tabbed into a page.

  4. Don’t alter the expected tab order

    Users will expect consistent tab ordering that follows the natural reading direction for their language. Don’t use tabindex to reverse it because you think it “works better that way“. The site isn’t for you. It’s for your visitors. Don’t give priority to form controls over, and above, the links that receive the initial focus on every other page of the site. You have no idea whether visitors to your form page will actually want to complete your form. Those who don’t may have to tab through the entire form to get back to the site navigation menu (which, visually, may be higher up the page). The end result is confusing and very frustrating.

  5. Provide form labels

    Unless each of your form inputs is explicitly associated a corresponding label, many users won’t be able to understand the form – let alone complete it. Avoid tabling forms if you can – it potentially adds another barrier that users may have to contend with. And bear in mind that any text that is not enclosed in, or associated with, a form control will be ignored by JAWS in Forms Mode. So some users many never be aware of any additional supporting text (e.g. “Enter dates in the format dd/mm/yyy“)

  6. Avoid extreme colour contrasts

    Too low a contrast between background and text will create problems for some dyslexic and visually-impaired users who won’t be able to read your content. Too high a contrast and different users from the same two groups may suffer. A brightness threshold of 125 – 200 and a colour threshold between 400 -500 seems to offer the best compromise.

  7. Ban pop-ups

    Popups, and new windows that appear without warning, can confuse and disorientate some users because their focus may be moved without them being aware of it. Others (e.g. switch users) may be aware of the changed focus but can find themselves stranded and unable to move back to the original window. If you do have an overwhelming need to provide links that open in a new window, place a clear warning within the link text.

  8. Provide suitable image descriptions

    Omitting the alt attribute means that screen reader users are forced to listen to image filenames. Over-using the alt attribute means that the same users have to listen to long rambling descriptions which can be just as tedious. If an image contains text, replicate it within the alt attribute. Consider how, or even if, you would describe the image if reading the page out to someone over the phone. If the image is purely decorative, provide a null alt attribute (e.g. alt=""). If it’s an image of a chart or table, offer a detailed summary on a separate page. Otherwise, provide an appropriate brief description. Remember it’s just a graphic – not the Mona Lisa [1].

  9. Create meaningful links

    Screen readers offer link lists and these lists are a common method of navigation amongst screen reader users. A whole list of “click here” links is not going to make any sense. Nor will it do much for your Page Rank. Remember, Google is “blind” too.

  10. Use markup – don’t abuse it

    Don’t use blockquote tags to indent text as it can mislead some assistive software users into believing that they’re being provided with a quotation. Don’t over-use heading tags for SEO or formatting purposes. Since some users skim through a page by navigating its headings, it is important to use headings appropriately. Don’t use paragraphs and styling to create visual pseudo-lists. There is list markup available. Use it.

  11. Don’t used timed events

    Dynamic content that alters with time without the user being informed of the alteration – including pages with automatic forwarding – creates confusion. Perform redirects via the server – not the page. If dynamic page content changes (e.g. an error message relating to a form submission) , ensure that the user is aware of the changed content by adding the new content near the top of the page. Don’t refresh pages automatically. Not everyone can read at the same rate that you do. In fact, when was the last time that you actually stopped and read one of your own pages properly?

  12. Be considerate with movement and sound

    Avoid movement in pages unless users can stop the movement via their browser. Be aware that flashing images can cause photo-epileptic fits. Don’t play sound as soon as a page loads. It will interfere with the output from screen reader software. Allow users to control when, or even if, sound is played.

  13. Avoid CAPTCHAs

    Don’t make users jump through unnecessary hoops to contact you or login to your site’s services. Visual CAPTCHAs create significant barriers for some user groups. Visual CAPTCHAs create barriers for all users. The more complex the CAPTCHA, the more likely that all site visitors will have problems and will abandon your form or service.

[1] Although, if it is the Mona Lisa, you may want to provide a more detailed description on a separate page.

Published: July 10th 2008


  1. Blair Millen

    Excellent list. As you say Mel, keeping the list down to ten (even thirteen) is tough, but I have to say you’ve covered, rather comprehensively, every important aspect one should consider when trying to make their site accessible.

    A good reference point for any web designer whatever level of expertise they claim.

  2. Stevie D

    Re: point 5
    Be as flexible as you can when requesting data in form fields.

    For example, I have seen some sites that require you to enter the date in the form dd/mm/yyyy, and won’t accept d/m/yy.
    By contrast, there’s another site that will read and parse the date in whatever format you write it (eg UK or ISO), including “11th July”, “tomorrow”, “next Thursday”.
    If one hobbyist site can do this, why are some huge professional sites so finicky?

    Similarly, any site that requires telephone numbers or addresses to be entered in a particular format is likely to be difficult/impossible for overseas users, as well as putting up considerable accessibility barriers to “local” users.

  3. JackP

    I don’t necessarily see ‘a completely automated test to tell computers and humans apart’ as a bad thing. What is a bad thing is having ‘a completely automated test which will block all blind users and about 80% of spam bots’. If you’re going to have a CAPTCHA, use some form of logic CAPTCHA (but it needs to be relatively simple, and with an element of randomness). Don’t just use the standard ‘distorted text’ business.

    …admittedly, even if you do that, your site will not be usable to people with certain cognitive disabilities, but if you pitch it so that the difficulty of the question is no more difficult than the complexity of the site content, that ought to ease that problem slightly…

    [other than that, top list!]

  4. Stevie D

    I know that it is not right to discriminate against anyone, but realistically, if someone has such poor English skills, or such severe cognitive disabilities, that they can’t answer the question “Is fire hot or cold?”, you have to ask how much value they will be getting out of your website. It’s a serious question – if someone can’t answer a simple question like that, are they really likely to be reading and commenting on your blog?

  5. Black Widow

    @Stevie D: I appreciate your point but then they’re not the kind of CAPTCHAs I meant when I used the term “visual CAPTCHAs”. I’d class them as text based. it’s the standard distorted characters on patterned backgrounds that I think have to be avoided at all costs. I failed such a CAPTCHA 4 times the other week. And I was wearing my glasses! So what chance does someone with a significant visual impairment or dyslexia have?

    Yes, the text based CAPTCHAs have their own problems – not least of which is the fact that they depend completely on what kind of question is used. Standard I.Q. tests are often criticised for being culturally biased and I think there is a risk that the questions used in text CAPTCHAs can be, quite unconsciously, similarly biased in a way that has nothing to do with language skills or cognitive abilities.

    Ideally, I’d like to see all forms of CAPTCHA abandoned (sooner rather than later) in favour of security methods that don’t make users jump through hoops but I freely admit that I don’t have any solutions myself. For now, I think text-based CAPTCHAs are the best of a bad lot providing they’re implemented as sympathetically as possible.