This is an in-progress, unapproved draft. Please send any suggestions, edits, or comments to the publicly-archived list: wai-eo-editors@w3.org
(Updated $Date: 2013-06-12 21:42:14 $)
[Editors' Draft] Easy Checks - A First Review of Web Accessibility
(previously titled Preliminary Review)
Introduction
This page helps you 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.
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 accessibility barriers. More robust evaluation is needed to evaluate all issues comprehensively.
This page provides checks for specific aspects of a web page:
- Page title
- Image text alternatives ("alt text") (pictures, illustrations, charts, etc.)
- Text:
- Interaction:
- Multimedia (video, audio) alternatives
It also includes guidance on Next Steps.
Using these Easy Checks
Tools: FF Toolbar and IE WAT
You can do most of these checks with any browser, that is, you do not need to download special tools.
However, some checks are easier if you can download tools. To keep it simple, we've included instructions for just two tools - the Web Developer Toolbar for Firefox ("FF Toolbar") and the Web Accessibility Toolbar for IE ("IE WAT"). Both are free extensions/add-ons available in different languages.
- FF Toolbar - To do the checks that are indicated "with FF Toolbar", you'll need the Firefox browser and the Web Developer extension/add-on.
- IE WAT - To do the checks that are indicated "with IE WAT", you'll need the Internet Explorer (IE) browser and the Web Accessibility Toolbar.
Note that we're not endorsing these tools over others. There are many other useful tools to help with evaluation.
(If you can't download these tools, that's OK; you can still do the checks indicated "with any browser".)
WCAG Links
These checks are based on the Web Content Accessibility Guidelines (WCAG) 2.0. 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 2.0" document.
Please see the WCAG Overview for an introduction to WCAG.
Practicing with BAD, the Before-After Demo
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 title Note... will open with the explanation. Or, with the keyboard: [@@].
Background
These checks are designed for anyone who can use the web. You don't need much knowledge or skill. To check a couple details, you need to see the visual page or hear audio. However, there are lots of things that anyone can check.
Here are some things to know that will help you understand the brief explanations:
- assistive technologies (AT) are software or hardware that people with disabilities use to improve interaction with the web.
- screen readers are software that reads aloud the information in a web page. They are used by people who are blind and by some people with reading disabilities.
- voice input is using speech instead of a keyboard and mouse.
To learn more, see:
Page title
Page titles are:
- shown in the window title bar in some browsers
- shown in browsers tabs when there are multiple web pages open
- shown in search engine results
- used for browser bookmarks/favorites
- read by screen readers
(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.

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.
What to do:
If possible, use a browser that displays the page title in the window title bar. Currently Firefox, Safari, Opera and some other browsers show the title by default.
Chrome and some versions of IE do not have a title bar. In those browsers you can see the full page title by hovering over the tab [@@keyboard way to do this?], like this:
[@@ need to redo this image with a browser that does not have a title bar]
- Look at the page's title (or with a screen reader, listen to it).
- Look at titles of other pages within the website.
What to check for:
- Check that there is a title that adequately and briefly describes the content of the page.
- Check that the title is different from other pages on the website, and adequately distinguishes the page from other web pages.
Tips
- There is flexibility on what makes a good page title.
- Best practice is for titles to be "front-loaded" with the important and unique identifying information first.
For example:- Poor titles:
- Welcome to home page of Acme Web Solutions, Inc.
- Acme Web Solutions, Inc. | About Us
- Acme Web Solutions, Inc. | Contact Us
- Acme Web Solutions, Inc. | History
- Better page titles:
- Acme Web Solutions home page
- About Acme Web Solutions
- Contact Acme Web Solutions
- History of Acme Web Solutions
- Poor titles:
Page title checks
To check page title with Firefox and other browsers that have title bars
- If the title isn't displayed, turn it on.
- In Firefox, press Alt+V, T, M (or right-mouse click in the empty area after the tab and select Menu Bar).
To check page title with IE WAT
(Some versions of IE have the title bar so you can just look there, you don't need to do the steps below.)
- Open the web page you are checking.
- In the toolbar, select "Structure", then "Heading structure". Or, with the keyboard: Ctrl+Alt+6, then down arrow key to "Heading structure".
A new page opens.
The page title is shown after "Title:".
Learn more about page titles
- Page Titled - Understanding Success Criterion 2.4.2 for WCAG 2.0 (Level A)
Image text alternatives ("alt text")
Text alternatives ("alt text") convey the purpose of an image, including pictures, illustrations, charts, etc. 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.)
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".)
Alt text is in the web page markup ("code"); you don't usually see it in the browser. Every image should have alt defined. If an image conveys information useful for interacting with or understanding the web page content, then it needs alt text. If an image is just decorative and people don't need to know about the image, it should have null alt (which looks like this in the markup: alt="" with no space between the quotes).
Automated tests can tell you if alt text is missing. To determine if the alt text is appropriate, you need to see the image and judge it in context.
What to check for:
- Every image has appropriate alternative text.
Tips
Appropriate alt text is not an exact science. Some people prefer most images to have more detailed description; and others prefer much less description.
Appropriate alt text:
- The text needs to convey the same meaning as the image. That is, if someone cannot see the image, they get the important information from the image in the alt text.
- Alt text depends on context. For example, for an image of a dog on a kennel club website, the alt text might include the breed of the dog; however, the same image on a dog park website may be there just to make the page more attractive, and the image might not need any alt text (and should have null alt). One way to help think about appropriate alt text is: if you were helping someone read and interact with the web page and they cannot see it, what would you say about the image?
- Images that are functional — for example, images that initiate actions (like submit buttons) and linked images (like in navigation) — need alt text that is the functional equivalent.
- If there is text in the image — for example, in a logo — that text needs to be included in the alt text.
- If the image has complex information — such as charts or graphs — the image should have a short alt text, and then the detailed description of the information should be provided elsewhere.
What's not needed in alt text:
- If the image is not important for understanding the content — for example, it is just decoration or "eye candy" — it should have null alt (
alt=""). One way to help determine if an image should have null alt is to ask yourself: if the image was removed, would the user still get all the information from the page? - If the image is sufficiently described in the text — for example, a simple diagram illustrating what's written in the web page text — it can have brief alt text such as "Diagram of work flow as describe above."
- The alt text does not need to include the words "button", "link", or "image of". (Screen readers automatically provide that information.)
In HTML (which is web page "code" called markup), alt is an attribute of the image tag, and other tags. (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 checks
There are three options for checks 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.
To check alt text with IE WAT
- Open the web page you are checking.
- In the toolbar, select "Images", then "Show Images". Or, with the keyboard: Ctrl-Alt-4, then arrow down to "Show Images"

If there are any images missing alt, a dialog box appears with the number of images without alt attributes.
The alt text will be displayed before the images in quotes on a light background. - To check for missing alt: Look for the text "NoAlt!" (visually, or with find-in-page). If you find it, that means the following image is missing alt.
- To check if alt text is appropriate:
For each image, see if the alt text adequately conveys the information in the image it is next to, per the Tips above.
To check alt text with FF toolbar
- Open the web page you are checking.
- In the toolbar, select "Images", then "Outline Images", then "Outline Images Without Alt Attributes". Or, with the keyboard: Alt+T, W (to Web Developer Extension), I, O, A
[image]
Red boxes appear around any images missing alt. - Note images without any alt text.
- In the toolbar, select "Images", then "Display Alt Attributes". Or, with the keyboard: Alt+T, W (to Web Developer Extension), I, A

The alt text will be displayed before the images as white letters on a red background. - For each image, see if the alt text adequately conveys the information in the image it is next to, per the Tips above.
To check alt text with any browser
- Open WAVE web accessibility evaluation tool web page.
- Type the website address in the box after "Enter the URL of the web site you want to evaluate:"
- Click the "WAVE this page!" button.
Your web page will show up in the browser with lots of little icons on it. - To check for missing alt: Look for the red icon [image], or search for the alt text "ERROR: Missing alt text". If you find it, that means the following image is missing alt.
- To check if alt text is appropriate:
Look for the green alt icon [image]. Next to it is text on a light blue background; the alt text is in between the asterisks (*). See if that text adequately conveys the information in the image it is next to, per the Tips above.

To practice checking alt text in BAD
With one of the checks above, use the inaccessible home page www.w3.org/WAI/demos/bad/before/home
Notice:
- Missing alt:
- There are lots of images without alt text. (Many of these are just decorative and should have null alt text, per the Tips above.)
- The weather image of the cloud and sun is missing alt.
- Inappropriate alt text:
- Near the top, left, see the long alt text starting with "Red dot with...". That description is way too detailed and includes unimportant information. The appropriate alt text in the accessible page is: "Citylights: your access to the city."
- Near the bottom in the middle, see the image of text: "(1)269C-H-O-K-E". The alt is 123456789, which is not equivalent.
- Appropriate alt text:
- Near the top, see the W3C image; the alt text is: "W3C logo".
Learn more about alt text
- Text alternatives for non-text content is an easy introduction with links to more details
- Non-text Content - Understanding Success Criterion 1.1.1 for WCAG 2.0 (Level A)
- [when published, A simple alt text decision tree ]
Headings
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" 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.
Heading levels should have a meaningful hierarchy, e.g.:
- Heading Level 1 <h1>
- Heading Level 2 <h2>
- Heading Level 3 <h3>
- Heading Level 3 <h3>
- Heading Level 2 <h2>
- Heading Level 3 <h3>
- Heading Level 4 <h4>
- Heading Level 4 <h4>
- Heading Level 3 <h3>
- Heading Level 2 <h2>
- Heading Level 2 <h2>
What to check for:
- The page has a heading. In almost all pages there should be at least one heading.
- All text that looks like a heading is marked up as a heading.
- All text that is markup as a heading is really a conceptual section heading.
- The heading hierarchy is meaningful. Ideally the page starts with an "h1" — which is usually similar to the page title — and does not skip levels; however, these are not absolute requirements.
Headings checks
The checks below provide instructions with different browsers for how to get:
- an outline of the headings that are marked up on page — like the outline at the beginning of this section
- a view of the page with the heading markup shown, for example: [image]
To check headings with FF toolbar
Headings outline:
- Open the web page you are checking.
- In the toolbar, select "Information", then "View Document Outline".Or, with the keyboard: Alt+T, W (to Web Developer Extension), I, M
[image]
A new page opens with the outline - Non-visual checks:
- Are headings listed. If there are no headings marked up, it will say "0 headings".
- Does the outline start with [H1] and follow a meaningful hierarchy? (That's not required, but strongly suggested.)
- Visual checks: Compare the Document Outline to the visual rendering of the page.
- Are the things that look like headings on the page listed in the Document Outline?
- Are there things in the Document Outline that aren't really headings?
Heading markup in the page:
- Open the web page you are checking.
- In the toolbar, select "Outline", then "Show Element Tags Names When Outlining". Or, with the keyboard: Alt+T, W (to Web Developer Extension), O, S
- In the toolbar, select "Outline", then "Outline Headings". Or, with the keyboard: Alt+T, W (to Web Developer Extension), O, H
The headings will be outlined and <h1>, <h2>, etc. icons will be before the headings. - Anything that is a functional heading should have a heading icon before it.
- Anything that is a not functional heading should not have a heading icon before it.
To check headings with IE WAT
Headings outline:
- Open the web page you are checking.
- In the toolbar, select "Structure", then "Heading Structure". Or, with the keyboard: Ctrl+Alt+6, then down arrow to "Heading structure".
A new page opens with the outline. - Non-visual checks:
- Are headings listed? If there are no headings marked up, it will say "0 headings".
- Does the outline start with [H1] and follow a meaningful hierarchy? (That's not required, but strongly suggested.)
- Visual checks: Compare the Document Outline to the visual rendering of the page.
- Are the things that look like headings on the page listed in the Document Outline?
- Are there things in the Document Outline that aren't really headings?
Heading markup in the page:
- Open the web page you are checking.
- In the toolbar, select "Structure", then "Headings". Or, with the keyboard: Ctrl+Alt+6, then down arrow to "Headings".
Headings will be surrounded with <h1>, <h2>, etc. icons in purple text on a light background.
[image] - Anything that is a functional heading should have a heading icon before it.
- Anything that is a not functional heading should not have a heading icon before it.
To check headings in any browser
Headings outline:
- In any browser, open the W3C HTML Validator (The W3C Markup Validation Service).
- In the Address field, type the URI (e.g., www.w3.org).
- Click the More Options link.
- Select the Outline checkbox.
- Click the Check button.
The results page appears (with title starting either [Valid] or [Invalid]). - In the results page, near the top, at the end of the "Jump to:" line, click the Outline text link.
- Non-visual checks:
- Is there anything there? If there is no text between "Below is an outline for this document, automatically generated from the heading tags (<h1> through <h6>.)" and "If this does not look like a real outline..." it means there are no headings marked up on the page.
- Does the outline start with [H1] and follow a meaningful hierarchy? (That's not required, but strongly suggested.)
- Visual checks: Compare the Document Outline to the visual rendering of the page.
- Are the things that look like headings on the page listed in the Document Outline?
- Are there things in the Document Outline that aren't really headings?
Heading markup in the page:
- Open WAVE web accessibility evaluation tool.
- Type the website address in the box after "Enter the URL of the web site you want to evaluate:"
- Click the "WAVE this page!" button.
Your web page will show up in the browser with lots of little icons on it. - Anything that is a functional heading should have a heading icon ([image], [image], ...) before it.
- Anything that is a not functional heading should not have a heading icon before it.
To practice checking headings in BAD:
Headings outline:
- Follow one of the instructions under "Headings outline" above and use the accessible News page:
www.w3.org/WAI/demos/bad/after/news. Notice there is a nice hierarchical outline. - Next, use the inaccessible News page:
www.w3.org/WAI/demos/bad/before/news. (In HTML Validator, the "Check" button might now say "Revalidate".) Notice there is just one heading.
Heading markup in the page:
- Start by visually looking at the inaccessible BAD news page:
www.w3.org/WAI/demos/bad/before/news. What looks like headings? (Citylights News, Heat wave linked to temperatures, Man Gets Nine Months in Violin Case, ...) - Next, see how it should look. Follow one of the instructions for "Heading markup in the page" above on the accessible News page:
www.w3.org/WAI/demos/bad/after/home. Notice the headings have icons next to them. - Next, see what it looks like when headings are not marked up. Use the inaccessible News page:
www.w3.org/WAI/demos/bad/before/home. Notice there is text that visually looks like headings, but does not have headings icons next to it. (With WAVE, there are yellow icons with "h?" because it thinks these might be headings.)
Learn more about headings
- Info and Relationships - Understanding Success Criterion 1.3.1 for WCAG 2.0 (Level A)
- Headings and Labels - Understanding Success Criterion 2.4.6 for WCAG 2.0 (Level AA)
- Section Headings - Understanding Success Criterion 2.4.10 for WCAG 2.0 (Level AAA)
- [?EOWG: not list the techniques because they are already listed in the Understanding pages?] Techniques for WCAG 2.0:
- G130: Providing descriptive headings
- G141: Organizing a page using headings
- H42: Using h1-h6 to identify headings
- H69: Providing heading elements at the beginning of each section of content
- F2: Failure of Success Criterion 1.3.1 due to using changes in text presentation to convey information without using the appropriate markup or text
- F43: Failure of Success Criterion 1.3.1 due to using structural markup in a way that does not represent relationships in the content
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.

While some people need high contrast, for others — including people with some types of reading disabilities such as dyslexia — bright colors (high luminance) are not readable. They need low luminance.

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.
What to check for:
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 pros (strengths) and cons (weaknesses).
- Table with contrast ratio - The tool displays a table with all the possible contrast ratios in the web page. With some tools, you can click in the table and it will show where that color combination is in the web page.
- Pro: Comprehensive.
- Con: Can be inaccurate, specifically, it can show some color combinations that are not really in the displayed page.
- Eye-dropper to select colors - The tool lets you select a text color and a background color, then it shows you the contrast ratio.
- Pro: Accurate.
- Con: Can only test one item at a time. Need to be able to see and use a mouse.
- Turn off color. The tool shows the page in grayscale.
- Pro: Gives you direct experience.
- Con: Imprecise, does provide contrast ratio value.
Contrast checks
Below 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.
To check contrast with IE WAT
Here's how to do the three checks for sufficient contrast described above.
- Table with contrast ratio:
- In the toolbar, select Color > Juicy Studios Luminosity Analyser.
Or, with the
keyboard: Ctrl+Alt+5, then down arrow to "Juicy Studios Luminosity Analyser".

A new window opens titled Colour Contrast Analyser with the table of results. The last column is Luminosity Contrast Ratio. - [@@ how to show where it is on the page]
- In the toolbar, select Color > Juicy Studios Luminosity Analyser.
Or, with the
keyboard: Ctrl+Alt+5, then down arrow to "Juicy Studios Luminosity Analyser".
- Eye-dropper to select colors:
- In the toolbar, select: Color > Contrast Analyser [application]. Or, with the
keyboard: Ctrl+Alt+5, then down arrow to "Contrast Analyser [application]".
- An eyedropper window opens [?]
- Choose a sample from both the foreground color and background color. [more specific instructions?]
It will show either Pass or Fail status along with the contrast ratio.
- In the toolbar, select: Color > Contrast Analyser [application]. Or, with the
keyboard: Ctrl+Alt+5, then down arrow to "Contrast Analyser [application]".
- Turn off color:
- In the toolbar, select Color > Grey Scale. Or, with the keyboard: Ctrl+Alt+5, then down arrow to "Gray Scale".
To practice checking contrast with BAD
Open the inaccessible Tickets page: www.w3.org/WAI/demos/bad/before/ticketsUse one of the checks above. Notice:
- The text in some rows is dark gray on light gray with a contrast ratio of 3.76:1.
To learn more about contrast ratio
- Contrast (Minimum) - Understanding Success Criterion 1.4.3 for WCAG 2.0 (Level AA)
- Contrast (Enhanced) - Understanding Success Criterion 1.4.6 for WCAG 2.0 (Level AAA)
Zoom
Some 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.
Enlargement is generally provided by browser zoom functionality, and the web page needs to be designed to work when zoomed. All major browsers provide zoom functionality that zooms all of the page, including text, images, and buttons. Some browsers provide functionality to zoom only the text. (currently only Firefox and Safari, as far as we know) If possible, you should check zoom text only.
When pages are not designed well, they can be unusable when zoomed — sometimes columns and sections overlap, the space between lines disappears, lines of text become too long, or text disappears. Some people with disabilities cannot read text that requires horizontal scrolling.
(The images below show that when zoomed, the heading overlaps the main text, the main text overlaps the sidebar text; and the sidebar text is cut off at the bottom.)

What to check for:
- With zoom text only: All text gets bigger.
- With zoom page: Everything on the page gets bigger, including in any navigation, ads, etc.
- Text doesn't disappear or get cut off.
- Text, images, and other content doesn't overlap.
- All buttons, form fields, and other controls are visible and usable.
It's best practice that when a page is zoomed, lines of text don't go off the screen and require people to scroll horizontally to read a line of text. It's acceptable to have to scroll horizontally to get to different sections of a page.
Zoom checks
To check zoom text only
In Firefox or Safari (or other browser that provides it):
- From the menubar, select View > Zoom Text Only
or, View > Zoom > Zoom Text Only - Incrementally increase zoom:
- In Windows, press Ctrl+ (the control key and the + key at the same time) 4 times
- On Mac, press Command+ (the Command key and the + key at the same time) 4 times
To check zoom page
In most browsers:
- From the menubar, select View > Zoom > 200%
- Or, incrementally increase zoom:
- In Windows, press Ctrl+ (the control key and the + key at the same time) 4 times
- On Mac, press Command+ (the Command key and the + key at the same time) 4 times
To learn more about zoom
- Resize text - Understanding Success Criterion 1.4.4 for WCAG 2.0 (Level AA)
- Visual Presentation - Understanding Success Criterion 1.4.8 for WCAG 2.0 (Level AAA)
- Images of Text - Understanding Success Criterion 1.4.5 for WCAG 2.0 (Level AA)
Keyboard access and visual focus
Many 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. Websites need to enable people to access all content and functionality — links, forms, media controls, etc. — through a keyboard. Keyboard focus should be visible and logical through the page elements.
What to do:
In a browser that supports keyboard navigation (Firefox, Chrome, IE, and Safari; not Opera):
- Click in the address bar, then put your mouse aside and do not use it.
- Press the 'Tab' key to move through the elements on the page.
- To move within elements such as select boxes or menu bars, press the arrow keys.
- To select a specific item within an element such as a drop-down list, press the Enter key or Space bar. [@@ is this specific and clear enough?]
What to check for:
All elements and order:
- Check that you can tab to all the elements, including links, form fields, buttons, and media player controls. Make sure there are no actions or options that you cannot get to, for example, because they are only available on mouse hover or click.
- Check that you can tab away from all elements that you can tab into. (A common problem is the keyboard focus gets caught in media controls and you cannot get out; it's called the "keyboard trap".)
- Check that the tab order follows the logical reading order (for example, for right-to-left languages: top to bottom, left to right) in sequence.
- Check that at the end of the page the focus goes to the top of the page.
Visual focus:
- Check that the focus indicator is clearly visible as you tab through the elements, that is, you can tell which element has focus, for example, links have a gray outline around them or are highlighted. (A common problem is that the default focus indicator is turned off in CSS [@@ too jargony?] or elements are styled with borders that overlap or hide the focus indicator.)
- Check that all visible changes that are available with mouse hover, such as highlighting, also triggered with keyboard focus.
Drop-down lists and image links:
- Check that after you tab into a drop-down list box, you can use the arrow keys to move through all the options. (A common problem for drop-downs used for navigation is that as soon as you arrow down, it automatically selects the first item in the list and goes to a new page — you cannot get to other items in the list.)
- Check that when images are links, they have clear visual focus and can be activated using the keyboard.
To see visual focus with BAD
Open the accessible Survey page: www.w3.org/WAI/demos/bad/after/surveyTab through the page. Notice:
- Most things get a red background when they get focus.
- The other Survey pages get a dotted border and arrows.
- The radio buttons get a dotted border.
To learn more about keyboard access
- Functionality is available from a keyboard section in Accessibility Principles
- Browsing the Web by Keyboard section in Better Web Browsing: Tips for Customizing Your Computer
- Focus Order - Understanding Success Criterion 2.4.3 for WCAG 2.0 (Level A)
- Focus Visible - Understanding Success Criterion 2.4.7 for WCAG 2.0 (Level AA)
Forms and errors
[@@potential additional section]
Multimedia (video, audio) alternatives
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 text transcripts or captions. 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.)
What to check for:
Keyboard access
Follow the steps above for keyboard access to ensure that the media player controls are labeled and keyboard accessible.
Auto-start control
It 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:
- Stop after 3 seconds.
- Include controls to pause or stop the audio.
- Include controls to turn down the volume.
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 [@@ keyboard way to do this?]. If there is not a CC button, there are no captions available for that video.
[image] with only auto captions listed]
Automatic captions are not sufficient for accessibility because they are not accurate enough. For example, in YouTube, if only "automatic captions" are listed (as in the image above), there are no sufficient captions and the video is not accessible. Captions in the specific language need to be listed, e.g.: [image] with one language NOT English! listed]
If there are captions, you can check that:
- The captions seem in sync with the spoken content.
- The people who are speaking are identified when they speak.
- Important sound other than dialogue — e.g., door slamming, broken glass, [@@other examples of important noise, especially positive ones (instead of slamming and breaking:)] — is included.
Transcript
If there are captions, transcripts are not usually required; however providing transcripts in addition to captions has many benefits — both to people with disabilities and to website owners. [EOWG: OK to say??]
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 [repeat examples above or not?].
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 description
Audio 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:
- Audio description - where the audio track includes someone describing the important visuals. Audio description can be included in the main video, or it can be provided in a separate video.
- Text transcript - that includes description of meaningful visual information (so it's kind of like a screenplay).
Learn more about multimedia alternatives
- W3C Multimedia Accessibility FAQ
- Captions - Understanding Success Criterion 1.2.2 for WCAG 2.0 (Level A)
- Audio Description or Media Alternative - Understanding Success Criterion 1.2.3 for WCAG 2.0 (Level A)
- Audio Control - Understanding Success Criterion 1.4.2 for WCAG 2.0 (Level A)
- Media Alternative - Understanding Success Criterion 1.2.8 for WCAG 2.0 (Level AAA)
Next Steps
Now that you have an idea of the accessibility issues on a web page, two things you can do:
- Share your findings with someone who can fix accessibility barriers.
- Encourage thorough accessibility evaluation.
Share your findings
Contacting 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 evaluation
The checks on this page cover just a few accessibility issues. More robust evaluation is needed to evaluate all issues comprehensively. Guidance is available from: