Edit meta-pattern Edit layout

Accessibility

Imagine accidentally sitting on your glasses. Could you work without them? Would you be able to find and read information on the web? Now imagine breaking your arm: could you do everything you need to on your computer without a mouse or keyboard? Finally, imagine waking up tomorrow to discover you're blind: could you still do your job? Web accessibility is about making sure that we can all use websites and web applications, regardless of our abilities.

On this page

Loading...

How do I improve the accessibility of my service?

To improve accessibility your site needs:

  • clear content, straightforward language and a clear, simple layout
  • good navigation and the ability to know where you are within a site
  • meaningful and clear hyperlinks

Accessibility is not a bolt-on activity or after-thought, but a core part of our design activities. The way to achieve accessibility objectives is through a process of inclusive design: Inclusive Design is neither a new genre of design, nor a separate specialism.

The following guidelines are grouped according to the 3 main phases of the design life cycle:

  1. Research
  2. Design
  3. Evaluation

The design requirements are summarised as an Accessibility infographic (see also here http://webaim.org/resources/designers/)

1. Research

  • Define the target audiences
    • The needs of target audiences ought to take precedence over the needs of other audiences. Defining a number of target audiences does not mean that everyone else is excluded; it just means that the requirements, design and testing activities will focus on these user groups as the most likely users of the web product.
  • Analyse the needs of the target audiences
    • Desk research into the general needs of the the website's or application's target audiences, taking special note of the general needs of disabled and older people.

2. Design

Provide appropriate alternative text

  • Every non-text element needs a text alternative (alt text) that provides an equivalent to the image content.
  • Alt text should present the content and function, not necessarily a description, of an image.
  • If an image has no relevant content or function, is decorative, or the alternative text is provided in nearby text, then the image should have an empty alternative text value (alt="").
  • If an image is a link (or hotspot), the alt text must describe the link's function.
  • Avoid words like "picture of," "image of," or "link to."
  • Use the fewest number of words necessary.
  • See: http://webaim.org/techniques/alttext/

Ensure content is well structured and clearly written

  • Use the simplest language appropriate for your content.
  • Organize your content using true headings (e.g. <h1> and <ul> lists).
  • Use empty (white) space to improve readability.
  • Use illustrations, icons, etc. to supplement text.
  • Check spelling, grammar and readability.

Help users navigate to relevant content

Provide headers for data tables

  • Identify all data table headers using the <th> element.
  • Provide an appropriate scope attribute: <th scope="col"> for column headers or <th scope="row"> for row headers.
  • If appropriate, add a table <caption> for the data table.
  • See: http://webaim.org/techniques/tables/

Do not rely on colour alone to convey meaning

  • The use of colour can enhance comprehension, but do not use colour alone to convey information. Be especially cautious of red/green colour combinations.
  • Make sure that colour contrast is strong, especially between text and background.
  • See: http://www.webaim.org/articles/visual/colorblind/

Ensure users can complete and submit all forms

  • Put form labels adjacent to or near their controls, so the labels are associated visually.
  • Use the <label> element to associate labels and controls.
  • Group similar elements (such as checkboxes or radio buttons) together using <fieldset>.
  • Clearly identify required form elements. Don't make a field required if it is not necessary. Ensure all directions and cues are readily accessible.
  • If there are errors in a form that has been submitted, alert the user in an accessible way (especially to a screen reader user) and make it easy to fix the incorrect information and resubmit the form.
  • See: http://webaim.org/techniques/forms/
  • Avoid phrases like "Click here", "Here", "More", "More information", "Read more", and "Continue."
  • URLs as link text should usually be avoided, unless the URL is relevant content. In terms of bioinformatics, we can interpret this as link on names, not accession numbers. For example, "Protein binding (GO:0005515)" is better than "GO:0005515 (Protein binding)" for:
  • Screen readers: hearing "protein binding" is more informative than hearing "GO:0005515" for people who are blind, partially-sighted or dyslexic
  • Search engines: Google, Bing and other search engines give extra weight to the words used in links, so people searching for "protein binding" or "binding" will be more likely to find your page
  • Training courses: it's easier and less error-prone to say "click protein binding" than "click go-colon-zero-zero-zero-five-five-one-five".

Other accessibility checks

  • Ensure that the page is readable and usable when fonts are enlarged 200-300%.
  • Provide a descriptive page <title>.
  • When using scripting, ensure events are available with both mouse and keyboard. Make all scripted content and page updates/changes available to screen readers.
  • Limit pop-up windows and notify users when pop-ups are used.
  • Provide a descriptive title for all frames (e.g., <frame title="navigation">).
  • Follow HTML and CSS coding standards.
Ensure accessibility of non-HTML content
  • HTML content will almost always be more accessible than content in any other format.
  • PDF, Microsoft Word and PowerPoint files, OpenOffice.org, and Adobe Flash provide basic accessibility features.
  • Provide accessible alternatives when non-HTML content cannot be made fully accessible.
  • Test the accessibility of non-HTML content in assistive technologies.
Caption and/or provide transcripts for media
  • Videos and live audio must have captions and a transcript. A transcript is sufficient for archived audio.
  • Captions should be synchronized, equivalent and accessible.
  • See: http://webaim.org/techniques/captions/

3. Evaluation

WAVE web accessibility evaluation too;

Disable styles and linearise tables

  • Styles can be disabled with the "Web Developer toolbar" extension for Firefox.
  • Ensure the reading order is logical.
  • Ensure content is still understandable and usable.

Check alternative text

  • Ensure alt text is succinct, but accurate and useful.
  • Using the Firefox Web Developer toolbar, select
    • "Display Alt Attributes." Is the alt text equivalent?
    • "Replace Images With Alt Attributes." Does the alternative text make sense?

Verify color and contrast

Test content scaling

  • Enlarge the font in your web browser to 200-300%. Is the page readable and usable? Is horizontal scrolling minimized?
  • Zoom the web page in your browser (enlarge fonts and images). Is text in images readable? Is contrast sufficient?

Check keyboard accessibility

  • Navigate the site using only the keyboard (Tab, Shift + Tab, Enter, etc.). Is all functionality available?
  • Is a "skip navigation" link available? (see webaim.org/techniques/skipnav/)
  • Make sure the navigation order is logical.
  • Is keyboard focus apparent?

Form accessibility and usability

  • Click on the form label. If the field gains focus, it is properly labeled.
  • Ensure that you can complete all forms without a mouse.
  • Are error recovery mechanisms present and easy-to-use? [Source: http://webaim.org/resources/evalquickref/]
  • Screen reader testing: focus on navigation, forms, and dynamic content. See the WebAIM tutorials on JAWS, the most popular screen reader (http://webaim.org/articles/jaws/), and NVDA, a free and open-source screen reader http://webaim.org/articles/nvda/
  • Cognitive walkthrough on early designs or prototypes (to identify any potential accessibility problems with the visual or interaction design) and finished code (to identify any potential accessibility problems with the coding of those designs), using the same assistive technologies, browser settings and operating system settings as your target audiences.
  • User testing with representative users from the website or application's disabled and older target audiences attempting to achieve tasks based on user goals. This should be conducted on early designs or prototypes, and finished code.
  • Manual validation against the WCAG 2.0 checklist (http://webaim.org/standards/wcag/checklist/)
  • Automatic validation of HTML (http://validator.w3.org) and CSS (http://jigsaw.w3.org/css-validator)

To learn more about accessibility

Downloads

Accessibility infographic (see also at http://webaim.org/resources/designers/)

See the Code