This page helps you start to assess the accessibility of a web page. With these simple steps, you can get an idea whether or not accessibility is addressed in even the most basic way. Video: Easy Checks Overview
These checks cover just a few accessibility issues and are designed to be quick and easy, rather than definitive. A web page could seem to pass these checks, yet still have significant accessibility barriers. More robust assessment is needed to evaluate accessibility comprehensively. This page provides checks for the following specific aspects of a web page. It also provides guidance on Next Steps and links to more evaluation resources. Checks on this page:
This video is also available on a W3C server: Video: Easy Checks Overview (file format: MP4, file size: 29MB). Text Transcript with Description of Visuals
Using these Easy ChecksClick headings with [+] buttons to get hidden informationSome sections of this page might not apply to your situation, for example, they are for a browser you don't have, or you only need to read them once. These sections are hidden by default so they don't clutter the page. You can expand them to see the information. The headings of hidden sections have a plus button [+] before them. Screen readers will say something like: "+ Section title, button collapsed". To get the hidden information, click the button or click anywhere on the heading. The sections below all have hidden information under expandable headings. The first time you read this page, we recommend that you expand the headings of these five sections and read them.
These checks are based on the Web Content Accessibility Guidelines (WCAG). The main points in WCAG are called "Success Criteria". In the "Learn more from" sections of this page, there are links to pages that explain the relevant success criteria in the "Understanding WCAG" document. Please see the WCAG Overview for an introduction to WCAG.
The Before and After Demonstration (BAD) from W3C WAI shows an inaccessible website and a retrofitted version of this same website with the accessibility barriers fixed. You can use the BAD pages to learn how to do these checks. For example, first, do the check on an accessible version of a page to see what it should look like. Then, do the check on the corresponding inaccessible page to see what it looks like when there are accessibility barriers. The BAD pages have annotations that are notes on what is accessible and not accessible in the demo pages. To turn on annotations, click "Show Annotations" in the yellow box near the top, middle of the page; then click a number and a box titled "Note ##" will open with the explanation.
These checks are designed for anyone who can use the web. You don't need much knowledge or skill. Some of the checks require seeing the web page or hearing the audio. However, there are many things that anyone can check. Here are some things to know that will help you understand the brief explanations throughout this page:
To learn more, see:
Some of the keyboard instructions are different for Windows and Mac; for example, "Ctrl" versus "cmd" in:
To reduce clutter, these are listed as:
For such instructions, Windows users press the Ctrl key, and Mac users press the cmd key. Page titlePage titles are:
(In the web page markup they are the <title> within the <head>.) The image below shows the page title "Easy Checks - A First Review of Web Accessibility" in the title bar, and the titles of 4 pages in the tabs. Note that in the tabs, only the first part of the page title is shown. Figure: Firefox browser with full title in the title bar and partial titles in the tabs.Good page titles are particularly important for orientation — to help people know where they are and move between pages open in their browser. The first thing screen readers say when the user goes to a different web page is the page title.
Page title checks
(Some versions of IE have the title bar so you can just look there, you don't need to do the steps below.)
Image text alternatives ("alt text")Text alternatives ("alt text") convey the purpose of an image, including pictures, illustrations, charts, etc. Text alternatives are used by people who do not see the image. (For example, people who are blind and use screen readers can hear the alt text read out; and people who have turned off images to speed download or save bandwidth can see the alt text.) The text should be functional and provide an equivalent user experience, not necessarily describe the image. (For example, appropriate text alternative for a search button would be "search", not "magnifying glass".)You don't usually see the alt text on a web page, it is in the web page markup (like this:
Automated tests can tell you if alt is missing. To determine if the alternative text is appropriate, you need to see the image and judge it in context.
TipsAppropriate alternative text is not an exact science. Some people prefer most images to have more detailed description; and others prefer much less description.
In HTML (which is web page code, called markup), alt is an attribute of the image element, and other elements. (So "alt tag" is technically incorrect; the correct terminology is "alt attribute", or you can say "alt text".) It looks like this in markup: <img alt="WAI logo" src="/wai/logo.png"> Alt text checksThere are three options to check alt text listed below. The first one is the easiest, if you have the IE WAT toolbar. If you don't have any toolbars, there is a check at the end for any browser.
With one of the checks above, use the inaccessible home page www.w3.org/WAI/demos/bad/before/home
Web pages often have sections of information separated by visual headings, for example, heading text is bigger and bold (like "Headings" right above this sentence :-). To make these work for everyone, the headings need to be marked up. 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. Heading levels should have a meaningful hierarchy, e.g.:
Headings checksThe checks below provide instructions with different browsers for how to get an outline from headings or headings markup in a page. Headings outline: an outline of the headings that are marked up on page, for example: Figure: Outline of headings.Headings markup in page: a view of the page with the heading markup shown, for example: Figure: Heading markup in page.
Contrast ratio ("color contrast")Some people cannot read text if there is not sufficient contrast between the text and background, for example, light gray text on a light background. High contrast (for example, dark text on light background or bright text on dark background) is required by some people with visual impairments, including many older people who lose contrast sensitivity from ageing. Figure: Dark text on light background, and yellow text on black background. While some people need high contrast, for others — including some people with reading disabilities such as dyslexia — bright colors (high luminance) are not readable. They need low luminance. Figure: Brown text on dark background, and dark text on medium brown background.Web browsers should allow people to change the color of text and background, and web pages need to work when people change colors. (This accessibility requirement is sometimes called sufficient "color contrast"; however, that is incorrect — technically it's "luminance contrast". On this page we use "contrast ratio" as short for "luminance contrast ratio" because it's less jargony.) There is much more to know about contrast; we've just introduced the basics here. Web pages should also have a minimum contrast by default: a contrast ratio of at least 4.5:1 for normal-size text. There are basically three ways to check contrast, each with strengths and weaknesses.
Contrast checksBelow are instructions for checking contrast with IE WAT; a list of other contrast analyzer tools is in the Related Resources section of Understanding Success Criterion 1.4.3.
Here's how to do the three checks for sufficient contrast described above.
There is not an easy way to check contrast with the WebDev toolbar. There is a Juicy Studio Accessibility Toolbar add-on that provides the same information as IE WAT above and works with Firefox. Resize textSome people need to enlarge web content in order to read it. Some need to change other aspects of text display: font, space between lines, and more. Most browsers allow users to change text size through:
When pages are not designed properly, they can be unusable when the text size is changed, especially when it is changed through text-only zoom or text settings. Sometimes columns and sections overlap, the space between lines disappears, lines of text become too long, or text disappears. Figure: Two screen captures show that when text size is increased, the heading overlaps the main text, the main text overlaps the sidebar text; and the sidebar text is cut off at the bottom.When text size is increased, sometimes part of the sentences are not visible and users have to scroll horizontally to read a sentence, as shown in the third example below. Most people cannot effectively read text that requires horizontal scrolling, and some disabilities make this impossible. Figure: The first image shows normal-size text. In the second image, the larger text "wraps" to fit the width. In the third image, some of the larger text is not visible without scrolling horizontally.
Resize text checksThe instructions below are for text-only zoom. You can also change the text size settings, for example, through Tools > Options or Preferences. To keep this simple, we don't include instructions for changing those settings. We also don't include instructions for page zoom because it does not usually reveal the accessibility barriers described above. For Chrome, you need an extention to get text-only zoom. Instructions for Firefox, Safari, and IE are below.
If you don't have a menubar, one of these may work to display it, depending on your version:
Keyboard access and visual focusMany people cannot use a mouse and rely on the keyboard to interact with the Web. People who are blind and some sighted people with mobility impairments rely on the keyboard or on assistive technologies and strategies that rely on keyboard commands, such as voice input. Accessible websites enable people to access all content and functionality — links, forms, media controls, etc. — through a keyboard. Keyboard focus should be visible and should follow a logical order through the page elements. Visible keyboard focus could be a border or highlight, as shown below, that moves as you tab through the web page. Figure: Dotted border on middle link. Figure: Name field is highlighted red. In a browser that supports keyboard navigation with the Tab key (for example, Firefox, IE, Chrome, and Safari; not Opera):
Open the accessible Survey page: www.w3.org/WAI/demos/bad/after/survey
Forms, labels, and errorsNote: This section is more complex than the others. If it's too complicated, consider skipping it for now and proceeding through the remaining checks. Labels, keyboard access, clear instructions, and effective error handling are important for forms accessibility. Form fields and other form controls usually have visible labels, such as "E-mail Address:" as the label for a text field. When these labels are marked up correctly, people can interact with them using only the keyboard, using voice input, and using screen readers. Also, the label itself becomes clickable, increasing the target area and making it easier to select small radio buttons or checkboxes. Find any forms on the page. A form could be a single text box, such as Search, or could be a complex form with text fields, radio buttons, checkboxes, drop-down lists, and buttons. Keyboard access
Labels
Required fields and other instructions
Error handlingSome simple forms, such as a single search field, might not have any errors. If you think the form(s) on the page you are checking might have error messages, try leaving required fields blank or entering incorrectly-formatted information (such as telephone number or e-mail address), then submitting the form. If you get errors:
Labels checksNote: These instructions help you check if labels are marked up with 'label', 'for', and 'id'; they do not check if form controls are identified in other ways. Therefore, even if a form does not pass these checks, it might still meet WCAG.
There is not an easy way to check form control labels with the WebDev toolbar. There is a Form Labels favelet that provides the same information as IE WAT above and works with Firefox. It requires installation.
Moving, Flashing, or Blinking ContentMoving, flashing, or blinking content includes carousels (example carousel), ads, videos, auto-updating stock tickers, scrolling news feeds, and more. Users need to be able to control moving content, especially some people with attention deficit disorder or visual processing disorders. Potential accessibility problems with moving, flashing, or blinking content include:
Additionally, flashing or blinking content can cause seizures in people with photosensitive epilepsy, particularly if it:
Information in podcasts or other audio is not available to people who are deaf or some people who are hard of hearing, unless it is provided in an alternative format such as captions and text transcripts. Visual information in videos is not available to people who are blind or some people what have low vision, unless it is provided in an alternative format such as audio or text. (Text can be read by a screen reader or Braille display, or enlarged and reformatted for people with low vision.) (Remember these easy checks are not comprehensive or definitive.) Keyboard accessFollow the steps above for keyboard access to ensure that the media player controls are labeled and keyboard accessible. Auto-start controlIt is best if audio (including background noise and video with sound) does not start automatically when a web page opens. If it does start automatically, it should either:
Captions(Captions are known as "subtitles" in some areas.) Most video on the web that provides captions has "closed captions" that can be turned on and off. ("Open captions" are always shown.) For example, in YouTube, you turn on captions with the CC button (no known keyboard access). If there is not a CC button, there are no captions available for that video.Automatic captions are not sufficient for accessibility because they are not accurate enough. For example, in YouTube, if only "automatic captions" are listed, there are no sufficient captions and the video is not accessible. Captions in the specific language need to be listed. Figure: Captions listed: French (automatic captions), Norwegian.If there are captions, you can check that:
TranscriptIt is best practice to provide both captions and transcripts, although not always required; providing transcripts has many benefits — both to people with disabilities and to website owners. Transcripts should be easy to find near the audio/video itself and any links to the audio/video. Check that transcripts include all audio information, including dialogue with the speakers identified, and all important sound — e.g., footsteps approaching, doors closing, glass breaking. A transcript for a video could provide all the audio and all the visual information, so that a person can get all the content of the video by reading the text. Audio descriptionAudio description (sometimes known as described video, video description, or visual interpretation) is description of important visual information in a video, in order to make it accessible to people who cannot see. For example, some videos start out with a title in text, have speaker names in text, and have illustrations. That visual information needs to be provided to people who cannot see the video. It can be provided through:
Basic structure checkWhile the other checks on this page focus on specific success criteria in WCAG, this check is more broad. It helps you understand how some people "see" the web page differently. For this basic structure check, you look at the web page without images, styles, and layout. Web pages are often designed with multiple columns, sections, colors, and other visual aspects that help organize information for people who see the page in its default display. However, some people do not see the page this way. People who are blind listen to the page with a screen reader or read it from a Braille display. Some people with low vision and others change the way the page is displayed so they can read it; for example, change from multiple columns to one column, change the text size, and more. An important issue is how the web page works when it is "linearized" into one column and the presentation is changed, as shown in the images below. Images showing linearized and changed display (click to show images)
The images below illustrate how a web page is displayed in 3 columns by default and how it can be changed. Figure A shows the default display of three columns, with the navigation at the left. Figure A.Figure B shows the page linearized into one column, with the navigation at the top. Figure C shows the page linearized, with the navigation at the bottom. The order of the sections (e.g., navigation at top or bottom or elsewhere) depends on how the web page is developed — the user usually cannot control the order. Figure B. Figure C. Figure D shows the page linearized and with styles turned off. When you follow the Basic structure checks steps below, your page will look like something like this: Figure D.Figure E shows the page changed by a person with low vision to make it more readable, for example, the main text is big, the footer text is very small, and the headings are a different color. Figure E.While it is useful to have an experienced screen reader user check web pages, anyone can get an initial idea of potential accessibility barriers for screen reader users and others who change the way the page is presented. The steps below show you how to disable images, disable styles for how the page is usually displayed, and linearize the page to check the page structure. Notes:
What to do:Get a basic structure view of the page by following the instructions under Basic structure checks below to:
What to check for:
Basic structure checks
Most browsers provide the option to turn off images and disable CSS from the menus. For example:
Next stepsNow that you have an idea of the accessibility issues on a web page, two things you can do:
Share your findingsContacting Organizations about Inaccessible Websites has guidance on reporting accessibility problems. It is focused for people who do not work for the organization that owns the website, yet also has some useful information if you do work for the organization — particularly the Introduction, Consider Your Approach, and Sources for More Information sections. Encourage thorough accessibility evaluationThe checks on this page are not definitive; a web page could seem to pass these checks, yet still have significant accessibility barriers. This page covers just a few accessibility issues. There are other accessibility issues not covered in these easy checks, for example: links, data table markup, reliance on color, and much more. More robust assessment is needed to evaluate accessibility comprehensively. Guidance is available from: Back to Top
Note about video description: The video on this page does not include synchronized audio description because the visuals only illustrate the audio and do not provide additional information. In this case, audio description would be more distracting than useful to most people, including people who cannot see the visuals. Description of visual information is integrated in the Text Transcript with Description of Visuals (“descriptive transcript”). Date: Main content updated 22 December 2017. Intro video added 28 April 2020. [changelog] Editor: Shawn Lawton Henry. Contributors: Sharron Rush, Caleb Watson, Suzette Keith, Anna Belle Leiserson, Andrew Arch, Wayne Dick, Vicki Menezes Miller, Jennifer Sutton, Ian Pouncey, Denis Boudreau, Tom Jewett, and EOWG Participants. Developed by the Education and Outreach Working Group (EOWG). Video developed with support from the WAI-Guide project funded by the European Commission (EC) under the Horizon 2020 program (Grant Agreement 822245). Acknowledgments for video. |