Important note: This Wiki page is edited by participants of the EOWG. It does not necessarily represent consensus and it may have incorrect information or information that is not supported by other Working Group participants, WAI, or W3C. It may also have some very useful information.

Easy Checks Flow option 2 draft

From Education & Outreach
Jump to: navigation, search

This page is an idea for an outline. Feel free to edit the headings.
Put any content edits in the main Easy Checks wiki page.

Easy Checks - Possible reflow

We already have criteria about the tests being important and easy/quick to do. I propose a criteria for the flow which reflects the testers point of view - looking at and interacting with designed elements that make up the web page.

The aim of this reflow option is to demonstrate how we could present a coherent story of the process of evaluating accessibility compliance by focussing on some common and critical design elements present on the web page. (We still need to make it clear that this is 'preliminary' and not a comprehensive audit)

For the purpose of demonstration I include the proposed title and opening paragraph from the Easy Checks document as updated at 4th February 2013. {Suzette}

Summary of web page elements

  • Page identity: Wherever there is a new page it should have unique page title
  • Pictures: Wherever pictures are used there should be alternative text
  • Text - sections: Wherever there are sections of text they should be organised with headings
  • Text - colour contrast: Wherever colour is used the colour contrast needs to be clear
  • Text - size: Wherever there is text the user should be able to change the font size
  • Links and navigation: Wherever links are provided they should be accessible by keyboard only, labelled and in a logical order
  • Audio and video: Wherever pre-recorded audio or video content is provided there should be captions and labels on the controls
  • Forms and text entry boxes: Wherever there are forms: see links, text and colour


[Updated 1 February]

These easy checks guide non-experts to gauge the accessibility temperature of a web page. With these few simple steps, you can get an idea whether or not accessibility is addressed in even the most basic way.

  • Text as agreed


Page identity - Check page title

[updated 4 February]

Good page titles are particularly useful when people have multiple web pages open at the same time. The first part of the title is shown in browser tabs, as in the above image. Titles are also used for bookmarks/favorites and in search engine results. The first thing screen readers say when the user goes to a different web page is the page title. Page titles are important for orientation — to help users know where they are and move between pages.

  • Text as agreed

Pictures and images: Check image text alternatives

[updated 4 February]

Text alternatives ("alt text") convey the purpose of an image. They are used by people who cannot see the image. (For example, people who are blind and use screen readers can hear the alt text read out; people who have turned off images to speed download or save bandwidth can see the alt text.)

  • Text as agreed

Text sections: Check headings

[updated 4 Feb]

Web pages often have sections of information separated by visual headings, for example, heading text is bigger and bold (like "Check headings" right above this sentence :-). To make these work for all users, the headings need to be "marked up" properly in the web page "code" (e.g., HTML). That way people can navigate to the headings — including people who cannot use a mouse and use only the keyboard, and people who use a screen reader.

  • Text as agreed

Text: Check color contrast

Good contrast between the text and background is very important to people with visual impairments and older people who experience loss of contrast sensitivity. This includes the default black text on white background as well as colour combinations. Some users may have requirements for very high or very low contrast, or a particular colour combination and they may choose to vary your colour choice by using their own preferred style sheet.

  • Text as agreed

Text size: Check text and zoom

People with mild to moderate visual impairments may need to enlarge content in order to read it, or read it without straining. This simple requirement is mostly achieved by the functionality of the browser and ensuring that the page design supports that functionality.

  • Text as agreed

Links and navigation: Check for keyboard access, content order, visual focus

Many people do not use the mouse and rely on the keyboard to interact with the Web. This requires keyboard access to all functionality, including links, form controls, input, and other user interface components. While screen reader users rely on the keyboard, they are not the only ones. In addition, sighted users with mobility impairments may rely on the keyboard or have assistive technologies that are controlled through keyboard actions. Therefore, key components of effective keyboard access include visible focus indication and a logical tab order. Here are some quick ways to check on the accessibility of links and navigation:

  • Click in the address bar, then put your mouse aside and don't use it.
  • Press the 'tab' key to move around the page.
  • Use the keyboard to set the focus to all focusable elements on the page.


What to look for:

  • Is there a clear visual indication of which text is a link to another page or section? Is the link status indicated by a feature other than simply its color?
  • Does the link text itself uniquely identify where the link goes, what it does? (If not, this MAY be a failure but not definitively, so it is an item for further investigation).

Keyboard access

What to look for:

  • Can you tab to all the elements, including links, form fields, buttons, and media player controls? Are there any actions you can't get to (e.g., if they are only available on mouse hover and click)?
  • Does the focus get stuck anywhere - that is, you can tab into a control but not out? (called a "keyboard trap")?
  • Are there drop-down mechanisms? (for example, for navigating to a different page): If you tab into the drop-down menu, can you use the down/up arrow keys to move through the new options, and still use tab to navigate the higher menu level? (Make sure it doesn't automatically select the first item when accessed using the arrow key.)

Visible focus indication

What to look for:

  • Is there a clear visible focus when tabbing? Visually examine progress through elements and verify that the focus indicator is clearly visible (i.e. you can see where you've 'tabbed' to).
  • If there are dynamic visual effects triggered by mouse-hover, do those effects also occur on tab focus?

Content order

What to look for:

  • Does the order that items get focus make sense to sighted users? (e.g., you don't jump around the page in seemingly illogical, random order)
  • Does the tab order follow the logical reading order, top to bottom, left to right in sequence?
  • Can you tab right through to the bottom of the page and then resume again from the top?

Learn more about Links and Navigation Accessibility

Video, Sound, (multimedia) - Check alternatives

Follow the steps for keyboard access to ensure that the media player controls are labeled and operable by all users.

  • Text as agreed – needs as improved opening paragraph


Forms are everywhere on the web and successful user interaction relies on clear, understandable, and accessible form controls. Forms are complex and are likely to require additional, in-depth assessment.

Some critical elements that can affect screen reader users are much easier to detect using an automatic tool to check the HTML and CSS, or as a user trial with an experienced screen reader user.

With that in mind, the following are common barriers that can be somewhat more easily identified and are particularly important when using forms in a web page.

  • Labels for form controls, input, and other user interface components must be provided. (Labels and Instructions 3.3.2 A)
  • Keyboard access for people who do not use the mouse and rely on the keyboard to interact with the Web. This requires visible keyboard access to all functionality, including form controls. (Keyboard 2.1.1 A, No keyboard trap 2.1.2 A, Focus visible 2.4.7 AA)
  • Information presented in a logical order which is followed when using the tab function to move through the input fields. (Meaningful sequence 1.3.2 A, Focus order 2.4.3 A)
  • Error correction: Forms may be confusing or difficult to use for many people, and, as a result, they may need more time and be more likely to make mistakes. Clear recovery mechanisms must be provided. (Error identification 3.3.1 A, Error suggestion 3.3.3.AA, Error prevention (legal, financial, data) 3.3.4 AA. Timing 2.2.1 A)

Are there any forms?

Check through the web pages to look for the presence of forms.

What to look for:

  • Forms may include registration forms, contact forms, booking and purchase details which include text entry fields, radio buttons, dropdown boxes and submit buttons and also single text entry boxes such as login or search box.

Visually examine the instructions for the form and input fields

Check over each form.

What to look for:

  • Are there text instructions at the beginning of the form including if any elements are required?
  • Are there text labels (before/after?) the input fields that describe what to do and if any elements are required for successful completion?
  • Are required fields indicated by use of color cues, such as the message "Required fields are in red"? If so, ensure that additional, alternative methods are also used (Use of colour 1.4.1 A)

Keyboard access

Use the Tab key to move through form controls, text boxes, radio buttons, drop down box and submit button. (Use shift tab to go back). Use the cursor (arrow) keys to access selection box content.

What to look for:

  • Is the focus visible on all form controls, including inputs, submit mechanisms, and check boxes and radio buttons?
  • If the form control is a check box or radio button, does focus indication include form label as well as the actual control?
  • If the form control is a select box, ensure that arrow keys can move focus between select options and that selection is made by user action and not by default focus.

Using only the keyboard to move among inputs, enter data into the text fields.

Enter correct and incorrect data – eg incorrectly formatted telephone numbers and email addresses.

What to look for:

  • Ensure that focus does not automatically advance to the next field, but requires user input to advance
  • When erroneous data is entered and form submitted:
    • Ensure that error message is clear and specific about the nature of the error and the field in which it was made.
    • Does focus move to the error message so it would be the next item in the reading order?
    • Ensure that guidance is provided to help user understand and fix the error.

Logical sequence

Compare the sequence of information presented visually with the tab through order.

What to look for:

  • Ensure that focus moves logically between the fields.
  • Enter correct and false data in form input fields

Learn more about Forms accessibility

Several Accessibility Principles are relevant to the accessibility of forms, including these:

WCAG2 Guidelines and Success Criteria that may be applied to determining the accessibility of forms include these:

WAI's Before and After Demo (BAD)includes examples of forms that have been made accessible: