This is an old archive of Easy Checks

Easy Checks - A First Look at Web Accessibility

title ideas

#Introduction - updated 23 Jan
#Check image text alternatives ("alt text") - updated 23 Jan
#Check headings - updated 23 Jan
#Check keyboard access, labels, content order, visual focus - Sharron & Suzette updating
#Check page title - updated 23 Jan
#Check color contrast - Anna Belle & Sharron updating
#Check video, sound, (multimedia) - Sharron updating
#Check forms - Suzette & Sharron consider if most moves to keyboard access, etc. section and what if anything is left here. SK: see email for update 11pm UK, 23 Jan.
#Check zoom, enlarge, resize ? - Ian refining draft to help us determine if want to include this or not
#Next Steps
#Contributors

Introduction

[previous wording drafts: Intro text from 22 January, Introduction from 17 January.]

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 was addressed in even the most rudimentary way.

These checks are designed to be quick and easy, rather than definitive. A web page could seem to pass these checks, yet still have accessibility barriers.

These checks cover just a few accessibility issues. More robust evaluation would be needed to check all issues comprehensively. However, these easy checks will give you a good idea if the page has [@@ significant accessibility barriers], and find some things that need to be fixed.

@@ notes:

@@ with last sentences, was trying to end positively -- but maybe it's too repetitive
@@ try combining middle two paragraphs

Using this page

Tools

Most of these checks you can do with any browser, that is, you do not need to download anything.

However, some checks are easier if you can download tools. To keep it simple, we've included instructions for just one tool - the Firefox Developer Toolbar, which is free. (Note that we're not endorsing that tool over others.) There are other useful tools to help with evaluation.

To learn how to do these checks with other tools, see [TBD either Web Platform Docs -or- WAI-Engage wiki].

FF Toolbar

[@@ how to download Firefox browser, then the Firefox Web Developer Toolbar...]

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|References" sections of this page, there are links to pages that explain the relevant success criteria in the "Understanding WCAG 2.0" document.

Visual and Non-Visual Checks

Some checks require you to be able to see the visual rendering of the page. These are marked [visual]. We've indicated checks that do not require seeing the page with [non-visual].

Practicing with BAD, the Before-After Demo

The Before and After Demonstration (BAD) shows an inaccessible website and a retrofitted version of this same website. You can use the BAD pages to learn how to do these checks. [@@maybe delete this if we have the instructions in each section] First, do the check on a good demo page ("after") to see what it should look like if accessibility is handled well. Then, do the check on the corresponding bad demo page ("before") to see what it looks like when accessibility is not handled well.[@@end delete]

Little Background

These checks are designed for anyone who knows how to use websites. You don't need much knowledge or skill. There are a couple things to know that will help you understand the explanations in the checks:

Screen readers read aloud the information in a web page. They are used by people who are blind and by some people with reading disabilities.
Some people use voice input instead of a keyboard and mouse. For example, ...@@
[@@anything else needed?]

If you want to learn more, see:

EOWG Comments on the Introduction

@@ comment {name}

Quick Checks

Here are 5 things you can do to quickly check for accessibility barriers on a web page:
{EOWG note: Let's work on the longer section first, then decide what we can move up to the quick checks section later.

First thing.
Second thing.
Third thing.
Fourth thing.
Fifth thing.

Once you have taken this quick dip you may be ready to dive a bit deeper. The next section provides more context and additional things you can do to check for accessibility barriers.

A Deeper Look

If you are interested in a more comprehensive look at the page(s), here more tests that require a little more time, skills, and/or tools.

Check image text alternatives ("alt text")

[updated 24 January]

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.)

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 ([/WAI/images/search-icon.png]) 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="").

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:

Important images have appropriate text alternatives.

To check if any images are missing alt text with the W3C Validator: [non-visual]

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 Check button.
The results page appears (with title starting either [Valid] or [Invalid]).
Search for "required attribute "alt" not specified". If you find any, that means there are images without alt text.

[@@ will give line number - however, need to figure out what the image is - whether it's an important image of something like spacer gif - to determine severity of barrier...]

[+/-] To check if alt text is appropriate - with FF toolbar: [visual]

Open the web page you are checking.
In the toolbar, select "Images", then "Display Alt Attributes". [image] Or, with the keyboard: [@@keyboard shortcut]
The alt text will be displayed before the images.
[@@ no indication of missing alt?]
Before the images it shows the alt text as white letters on a red background. See if that text adequately conveys the information in the image it is next to, per the Tips below.

[+/-] To check if alt text is appropriate - with any browser: [visual]

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.
Look for the red icon [image]. It is next to any image that is missing alt text.
Look for the green alt icon [image]. Next to it is text on a light blue background; the alt text is inbetween the asterisks (*). See if that text adequately conveys the information in the image it is next to, per the Tips below.

Tips:

@@ see Suzette's 25 Jan email - also think about splitting up the info

What is appropriate alt text?
- Appropriate alt text is not an exact science. Some people prefer more description of more images; and others prefer less description. [@@ what else to say here?]
- @@ really important/functional images - e.g., images that initiate actions (like submit), navigation, linked images... images of text that is essential for understanding... alt text that is functional equivalent
- The text conveys 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. Appropriate alt text depends on the 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, for the same image that is just decorative on a dog park website, the image might not need any text at all (null alt).)
- @@ linked images
- If the image is not important — for example, it is just decoration — it should have null alt (alt="").
- If the image is sufficiently described in the text — for example, a simple diagram illustrating what's written in the web page text — it does not need additional alt text.
- The alt text does not need to include "button", "link", or "image of".
- If there is text in the image — for example, it is an ad with a picture — the text from the image should 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.
In HTML: Alt is an attribute of the image tag, and other tags. (So "alt tag" is technically incorrect; it's "alt attribute", or you can say "alt text".) It looks like this in markup: <img alt="WAI logo" src="/wai/logo.png">

[+/-] To try checking the alt text in BAD:

Checking if any images are missing alt text in BAD: [non-visual]

Follow the instructions for "To check if any images are missing alt text" above and use the bad ("before") home page: www.w3.org/WAI/demos/bad/before/home. Notice there are lots of images without alt text. (Many of these are just decorative and should have null alt text, per the Tips above.)

Checking if alt text is appropriate in BAD: [visual]

With one of the "To check if alt text is appropriate" checks above, use the inaccessible ("before") home page www.w3.org/WAI/demos/bad/before/home Notice:

Missing alt: 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 good ("after") 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 from:

Text alternatives for non-text content is an easy introduction with links to more details
Non-text Content - Understanding Success Criteria 1.1.1 for WCAG 2.0 (Level A)

EOWG Notes on alt text

importance: HIGH.
5min: yes, at least the easy part.
15min: yes. might want additional checks here.
Without visual rendering: can check that description exist, can check that they are not too verbose, can check that they are appropriate to the general content of the page, but not necessarily appropriate to a specific image.

Would like to be able to use FF Toolbar select "Images", then "View Image Information" to check for missing alt, but null alt is not listed; therefore, you cannot use it to check for missing alt...

17 Jan 2013 draft of Check text descriptions for images

[done] [JS on 23 Jan.: Do we want to use "alt text" throughout? Isn't alt attribute more correct? I understand the idea of using the word alt, as short for alternative, but . . . Maybe this is just a personal pet peeve of mine, but based on the Twittersphere, I'm not the only one.] [Shawn: ah, yes, "alt tag" is wrong and we want to avoid it! (which is why I put that Tip, but maybe it was too subtle -- I just updated it) I think "alt attribute" is unnecessarily specific. "alt text" should be OK.]
[done] [SK about the null alt tag/text maybe for a literal minded newbie and skim readers we need to be clear that all images need something, either a context relevant text or a null attribute. There are a couple of places above that I think could be clarified][Shawn: Agree. I clarified it in a couple of places. Any more needed?][Much better, but also needs this one I think: "dog park website, the image might not need any alt text at all".] [done ~Shawn][Thank-you - See email, I have tried out changing the order of the tips to put the do's first and the don't's second, and then numbered them to help discussion. 'Good' alt text seems to involve a judgement call on the part of the evaluator on the importance of the image. Maybe the best test is first to determine the consequence of removing the image and asking does the page still make sense.SK]
[Bim on 25/01/2013] Within the tips should we specifically mention linked images and the importance of alt text describing the destination of the link rather than the visual aspect of the image? We have made it clear that alt text should give a functional description, but poor alt text on linked images is so common, and the target audience so inexperienced, we may need to be more specific.

Check headings

[updated 23 Jan]

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" 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 2 <h2>

What to check for:

Are there headings marked up?
Is the hierarchy meaningful? (Ideally the page starts with an "h1" — which is usually similar to the page title — and does not skip levels; however, this is not an absolute requirement.)
Is there text that looks like headings but is not marked up as a heading?
Is there text that is marked up as headings that is not really a section heading?

To check headings outline with the W3C Validator: [non-visual & visual]

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?

@@ in FF toolbar: Information -> View Document Outline @@

[+/-] To check heading markup is appropriate - with FF toolbar: [visual]

Open the web page you are checking.
In the toolbar, select "Outline", then "Show Element Tags Names When Outlining". [image] Or, with the keyboard: [@@keyboard shortcut]
In the toolbar, select "Outline", then "Outline Headings". [image] Or, with the keyboard: [@@keyboard shortcut]
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 heading markup is appropriate - with any browser: [visual]

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 try checking headings in BAD:

OPEN: Does BAD have example of text that is marked up as a heading but should not be?

OPEN: [@@ can we find an appropriate example of a web page with no headings at all? to show what you get in the Validator outline]

Checking headings outline with the W3C Validator in BAD [non-visual]

Follow the instructions under "To check headings outline with the W3C Validator" above and use the good ("after") News page: www.w3.org/WAI/demos/bad/after/news. Notice there is a nice hierarchical outline.
Next, follow the instructions under "To check headings outline with the W3C Validator" above and use the after ("before") News page: www.w3.org/WAI/demos/bad/before/news. (The "Check" button might now say "Revalidate".) Notice there is just one heading.

Checking heading markup is appropriate in BAD [visual]

Start by visually looking at the BAD news page. 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 "To check heading markup is appropriate" above on the good ("after") 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. Follow one of the instructions for "To check heading markup is appropriate" above on the bad ("before") 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 from:

@@ 1.3.1 ? (Level A) ... F:43
Headings and Labels - Understanding Success Criteria 2.4.6 for WCAG 2.0 (Level AA)
Section Headings - Understanding Success Criteria 2.4.10 for WCAG 2.0 (Level AAA)
@@ Techniques G130, G141, H42, H69, ... (some linked from those Understanding pages, some not0 [@@ suggest to WCAG the be added]
[@@how screen reader users navigate with headings... not much detail in accessibility principles ... ]

EOWG Notes on Headings

importance: HIGH.
5min: maybe. fairly easy to check if there are at least some headings.
15min: yes.
Without visual rendereing: can check headings exist and make sense, but can't tell that all headings are styled appropriately or that text styled as a heading is marked up as one.

title was: Check headings and other semantic structure

17 Jan draft of Check headings and other semantic structure

Check keyboard access, labels, content order, visual focus

EOWG notes - importance: HIGH.
5min: maybe.
15min: yes, at least part of it.
Without visual rendering: @@

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.

What To Do

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

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)?
Does the tab order follow the logical reading order, top to bottom, left to right in sequence?
Does the focus get stuck anywhere - that is, you can tab into a control but not out? (called a "keyboard trap")?
Does the order that items get focus make sense to sighted users? (e.g., you don't jump around the page out of order logically)
Can you tab right through to the bottom of the page and then resume again from the top? (e.g. you don't get stuck anywhere and can't move on)
If there is a drop-down box (for example, for navigating to a different page): If you tab into the drop-down box, can you use the down/up arrow keys to move through the options, and @@use 'tab' to the following item@@? (Make sure it doesn't automatically select the first item.)
Visually examine progress through elements and verify that the focus indicator is clearly visible (i.e. you can see where you've 'tabbed' to).
Common failures occur when the default focus indicator is turned off in CSS or when the element is styled with borders that occlude the focus indicator.
Verify that any visual changes that occur with mouse hover also are triggered with keyboard focus

References

Functionality is available from a keyboard
Browsing the Web by Keyboard section in Better Web Browsing: Tips for Customizing Your Computer
Focus Visible - Understanding Success Criteria 2.4.7 (Level A)
Focus Order - Understanding Success Criteria 2.4.3
Example: web page template that does not enable keyboard access from the WAI Before and After Demo (BAD)

Notes

Mac browsers by default only tab through forms, will need to turn on...
not work easily in Opera...
...

Check page title

[updated 23 January 2013]

[image: top of browser showing full title of current page, and multiple page tabs showing truncated titles.]

Good page titles are particularly useful when people have multiple web pages open at the same time (as shown in the above image). [@@ shown in browser tab] They 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. [@@ importance for orientation]

What to do [non-visual]

Choose a browser that displays page titles. Most do by default, except Chrome and IE #. [@@ to see full title - can hover or bookmark....]
Look at the browser's window title bar (or with a screen reader, listen to it).
Look at titles of other pages within the website.

What to look for [non-visual]

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

[@@front-end loaded]

There is some flexibility on what makes a good page title. Some guidance is linked from the Related Resources section of Understanding Success Criteria 2.4.2.
A common mistake is to put the website name first and then the specific page title, for example:
- Poor titles:
  - Acme Web Solutions, Inc. - About Us
  - Acme Web Solutions, Inc. - Contact Us
  - Acme Web Solutions, Inc. - History
- Better page titles:
  - About Acme Web Solutions
  - Contact Acme Web Solutions
  - History of Acme Web Solutions
Consider how the page title will be used in context; for example, the title of a page in the middle of a multi-step process probably does not need the website name in the title. [@@ maybe it's not worth the clutter to include this point?]
In HTML: The page title is near the top of the web page markup ("code"), in the <head> area. It looks like this in markup: <title>Acme Web Solutions home page</title>

BAD Example

In BAD, all of the bad ("before") pages have the title "Welcome to CityLights!" (plus a description in brackets that is necessary for people using them demo). The page titles are not unique. Whereas, the good ("after") pages are titled: Welcome to CityLights!, Citylights News, Citylights Tickets, and Citylights Survey.

References

Page Titled - Understanding Success Criteria 2.4.2 for WCAG 2.0 (Level A)

EOWG Notes on Page Title

importance: medium.
5min: maybe not. it is easy to check, but a little more complicated to explain what makes a good title. Also not the most vital to lots of users.
15min: probably.
Without visual rendering: can check

IMPORTANT! - Some browsers don't show title in browser title bar (Chrome, IE) {does this mean it doesn't meet our criteria for including in the 5 min list?}

17 Jan draft of Check the page title

Check color contrast

EOWG notes.
5min: maybe.
15min: yes.
Without visual rendering: yes, with tools

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.

Remember that not all users will have high resolution screens and subtle colour combinations may not be rendered properly if the user is using a reduced colour set.

Screen reader users will hear the text even if the contrast is poor, or deliberately hidden as white on white or black on black!

First stage: What to do

Inspect the text in the main content, menu tabs, links and selected links and in buttons, labels and captions.

Common failures

Look out for instances of pale text that might blend into the background eg grey on the default off-white background. Other common combinations are light green, yellow or blue text on the default background or a background that is a slightly darker shade of the same colour.
Look for instances of dark colours on a dark background eg purple, red or dark blue on black
Any suspect instances need to be investigated further.

Second stage: What to do

A number of on-line tools can be used to compare the exact ratio of text and background. There are two types:

A lexical tool can test the declared colour values set in the style sheet and provide a report on contrast. This is useful for checking across the whole website
- list named tools
A live online colour analyser allows you to select samples of the text and background colours for analysis. Use zoom to increase the font size and follow the tool instructions to pick up a sample of the text colour and a sample of the background colour. If the background is patterned take a sample at different points.
- list named tools

Common failures

The contrast ratio for normal sized text is less than the minimum recommendation of 4.5:1
The contrast ration for large, bold text such as a page heading level set at 150% (1.5ems) is less than the minimum recommendation of 3:1

References

Contrast (minimum) Understanding success criteria 1.4.3 (AA) http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html

Contrast (enhanced) Understanding success criteria 1.4.6 (AAA).

BAD example: http://www.w3.org/WAI/demos/bad/before/annotated/tickets.html Note 6, text in some rows is set dark grey on a light grey background.

Notes

There are some exceptions such as large text passing at 3:1 ratio, and special requirements to achieve full conformance. The understanding document contains detailed information on text size that would be useful in understanding text resize.

There are two types of color contrast testers: The first type, a lexical evaluator, looks at styles in web page code and computes color contrasts based on coded values. The second type, run time tester, simply allows the user to sample what is on the screen and computes contrast based on samples.

The lexical evaluator examines what the author declares. It gives a full page report based color contrasts declared by the programmer. These tests are quick and efficient. They break down when run time values change due to actions taken by active content.

The run time tester requires more hands on work. The evaluator can take samples as the web site runs and determine actual contrasts. The problem here is that as contrasts change over time the tester must sample many states of the page.

Both types of test are important. If any active content changes color during run time then WAI advises run time testing. Lexical testing can be very useful and save time with items with static color.

<end Wayne's insert>{thanks-you, Suzette}

[Yesterday's version First pass - I'm working on this:

Good colour contrast between the text and background is very important to people with visual impairements. Some users may chose to vary your colour choice by using their own preferred style sheet.

Screen reader users will hear the text even if the contrast is poor, or deliberately hidden as white on white or black on black!

First stage - look out for instances of pale text that might blend into the background eg grey on the default off-white background. Other common combinations are pale green, yellow or blue text on a background of a slightly darker shade of the same colour. Check the text in the main content, menu tabs, links and selected links and in buttons, labels and captions. Any suspect instances need to be investigated.

Remember that not all users will have high resolution screens and subtle colour combinations may not be rendered properly if the user is using a reduced colour set.

Second stage - a number of on-line tools can be used to compare the exact ratio of text and background. Use zoom to increase the font size and follow the tool instructions to pick up a sample of the text colour and a sample of the background colour. If the background is patterned take a sample at different points. The minimum contrast (level AA) is 4.5:1.]

Comments 2012-Nov-30

Shawn: Definite yes

Video, Sound, (multimedia)

EOWG notes.
5min: maybe. vital for some uses, through maybe not really easy to check thoroughly
15min: yes.
Without visual rendering: can check for presense of alt content, but not quality

What to do

Follow the steps for keyboard access to ensure that the media player controls are labeled and operable by all users.
Play the audio content
Play the video content
Toggle closed captions on (if available)
Toggle audio description on (if available)
If no captions or audio description options are provided, check page for transcript or link to transcript

What to look for

Captions:
- Verify that captions are synchronized to the spoken content
- Ensure they are accurate and complete and that no content is omitted.
- Verify that they are properly formed with correct spelling, sentence structure, and punctuation.
- Make sure that audio content other than dialogue is included (music, relevant ambient sounds, etc)
Audio Description
- (Judgement call) Watch the video content to verify that audio description is needed for complete understanding.
- If needed, verify that they are provided in a separate track that can be toggled on and that they provide context for those who do not see the video.
Transcript: As a fall-back when captions and audio descriptions are not provided, check to see if there is text-based content that contains dialogue, any other audio content, and any necessary description of video content. Check for spelling and accuracy.

(see also text alternatives for graphic content)

References

Multi Media FAQs from the W3C
Understanding WCAG SC 1.2.2 Captions(Level A)
Understanding 1.2.5 Audio Description(Level A)

Notes

[can be internal notes for now or maybe will be included in final doc]

...

Comments 2012-Nov-30

Shawn: Vital that transcripts are available, so should be included. Rewrite to simplify checks based on presences of alt content rather than checking quality. Leave this for complex check.

Check forms

[15: maybe not]

[drafted, edited, needs review - move keyboard access, visual focus, content order with other section ?Sharron ?Suzette]

EOWG notes.
5min: no, too complicated.
15min: not sure

Note: Some aspects will be integrated with keyboard access, visual focus, content order.

Forms are everywhere on the web and successful user interaction relies on clear, understandable, and accessible form controls. Several principles of accessibility should be kept in mind when testing forms. Labels for form controls, input, and other user interface components must be provided. Many people 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. Forms may be confusing or difficult to use for many people, and, as a result, they may be more likely to make mistakes. Clear recovery mechanisms must be provided.

Forms - simplified

[Edited by Suzette, is this sufficiently simplified?]

Note: Some aspects of Forms will be integrated with keyboard access, visual focus, content order. {SK - Also have removed references to colour coding and graphics/non text content and CAPTCHA.}

Forms are everywhere on the web and successful user interaction relies on clear, understandable, and accessible form controls. Forms are complex and need in depth assessment.

Some critical elements which 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.

The following visual checks can identify some common problems which are particularly important when testing forms.

{There 10 Success criteria references are included to help editorial choices – is this too many? SK}

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 needs to be in a logical order which is followed when tabbing 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 examples of forms.

What to look for:

- Forms 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 essential?
- Are there text labels (before/after?) the input fields that describe what to do and if any elements are essential
- {Exclude? If required fields are indicated by use of color cues, 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.

{SK: recommend refering to Keyboard access (above) and delete the rest of this section}

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, ensure that focus indication includes form label as well as the actual control (SK –can you do this visually?)
- 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. (SK – can you do the second part of this visually?)

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

{SK: recommend refering to Keyboard access (above)}

Use the keyboard to enter data into the text field.

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 (SK – is this easy or advanced, what success criteria?)
- 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
- Ensure that focus moves to the error message
- Ensure that guidance is provided to help user understand and fix the error.

{SK: recommend referring to Keyboard access (above) but would suggest keeping this practical suggestion to try filling in the form, especially with correct and incorrect information that will trigger error messages}

References

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:

Non-text Content: Understanding Success Criteria 1.1.1 (Level A)
Keyboard: Understanding Success Criteria 2.1.1 (Level A)
Focus Order: Understanding Success Criteria 2.4.3 (Level A)
Headings and Labels: Understanding Success Criteria 2.4.6 (Level AA)
Visible Focus: Understanding Success Criteria 2.4.7 (Level AA)
Predictable: Understanding Guideline 3.2 (Level A and AA)
Input Assistance: Understanding Guideline 3.3 (Level A and AA)
Name, Role, Value: Understanding Success Criteria 4.1.2 (level A)

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

Notes

[can be internal notes for now or maybe will be included in final doc]

...
Is it possible to have a 'first glance' option to identify potential trouble spots and very common problems, which can then be examined in more depth? {Suzette}
I have noticed some developers having trouble with single fields such as search boxes or login details, or simple little contact forms - perhaps we could expand the opening description to suggest looking for these. It is not just dedicated forms such as membership details, job applications, tax returns, travel booking and shopping etc.{Suzette}

Comments 2012-Nov-30

Shawn: Maybe, a couple of things are easy, some are complex. We could use the nice writeup somewhere else if not used here. Suzette: I can try and pick the easy bits out of Sharron's content to see if we can get this in. Shawn: Or add notes on forms to Keyboard Access and Visible Focus sections.

Check zoom, enlarge, resize

OLD DRAFT: Check usable with page zoomed and text enlarged [15 min: maybe] [Ian to try write up of simple approach to address related issues]

EOWG notes.
5min: no
15min: maybe not. maybe too complex? some conflicting perspectives in forums.
Without visual rendering: cannot be tested

Zoom to 200%
Text-only enlargement... (e.g., text actually changes in IE)

People with mild to moderate visual impairments may need to enlarge text 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.

The text should be resizable up to 200% without losing information, using a standard browse. Additionally any images of text should also be resizable or replaced with actual text.

Most modern browsers now offer a zoom function which enlarges both text and other content together. Some older browsers do not resize text if it was set using fixed units – such as points or pixels.

What to do

Open your preferred browsers. Internet Explorer, Firefox, Chrome and Opera all offer zoom as a function of View or Function menus, or as a keyboard shortcut (usually, Control +, or for Mac Command +).
Set the screen window to full width
Use the zoom function or keyboard shortcut repeatedly to step up to a 200% increase.
Look at the main content, buttons, tabs and text entry fields and field labels.
Repeat with a different browser.

Common failures

Is the default body text unusually small?
Does the main heading and body text increase in size?
Has any text that is part of a control, button, menu item or label increased in size?
Does any text overflow its space – for example, the text is too big for the button or menu tab, or width or depth of the column?
Can you read to the end of the line, or does some text disappear off the screen so that you have to scroll right to the end of the line?

Note

Some browsers can expand the text beyond 200% - this is not covered by the resize requirement as it is recognised that this will cause some of the failures described. It is also accepted that some horizontal scrolling may be necessary but see also 1.4.8 which is a AAA requirement. Users with more severe visual impairments who need larger text are likely to use screen magnifiers to increase text size above 200%.

References

link to {appropriate section in Accessibility Requirements page http://www.w3.org/WAI/intro/people-use-web/principles#distinguishable} (doesn’t have a lot to say)
Guideline 1.4 Distinguishable: Make it easier for users to see and hear content including separating foreground from background.
Resize text: Understanding Success Criteria 1.4.4 (Level AA) {http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-scale.html}
Images of Text: Understanding Success Criteria 1.4.5 (Level AA) http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-text-presentation.html
Visual Presentation: Understanding Success Criteria 1.4.8 (Level AAA)http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-visual-presentation.html
link to {BAD example} No specific BAD examples – some reference to Text as image in relation to the phone number, and column width.

OLD DRAFT: Window resize [15: probably not] [Ian to consider]

EOWG notes.
5min: no.
15min: no. probably too complex an issue from preliminary eval ...

Comments 2012-Nov-30

Ian to look into including this with the zoom one

Notes for discussion

Scrolling: see Visual Presentation: Understanding Success Criteria 1.4.8 (Level AAA) includes:
- Text can be resized without assistive technology up to 200 percent in a way that does not require the user to scroll horizontally to read a line of text on a full-screen window.
Do we need to spell out the difference between zooming and resizing? Is resizing still important for people who use style sheets?
Do we still need to worry about IE6 which didn’t resize fixed font sizes?
Browsers are now hiding their menus – eg under the cogwheel icon, which is making it harder to know where to find the zoom option, however they seem to be reasonably consistent on keyboard shortcuts. Other options include pinch and zoom on trackpad or intellimouse

Comments 2012-Nov-30

There are two things to test:

Does text enlarge;
Don't controls remain accessible and content not overlap;

Shawn: This is a maybe, conflicting views in forums and a hot topic, might be complicated to test.

Next Steps

@@ What to do with what you find -- point to Contacting Organizations about Inaccessible Websites overall and even if internal reporting, see Describe the Problem section

@@ Doing more thorough evaluation -- point to WCAG-EM Overview (coming soon)

Contributors

Thanks to:

Those who edited in December and January: Suzette, Sharron, Shawn, ...
Those who drafted checks 16-28 November:
- Sharron for drafting {list sections!}
- Suzette for drafting : Check usable with page zoomed and text enlarged, Check color contrast, Check color coding and shape coding, {?other sections}
- Wayne for drafting {list sections!}
- {name} for drafting {section}
Andrew & Shawn for editing the keyboard access & visual focus section in early Nov.
Ian, Suzette, Vicki, Sylvie, Helle, Shawn for working on an early draft at the f2f in Nov.
Sharron for help making all the drafts and versions less confusing.
Wayne and Ian for sharing colleagues' related work.
Denis for edits to the old page content.

Important Note: For this draft we have some tool-specific guidance. However, there are potential issues with vendor-neutraility and we might need to address this a different way — for example, moving tool-specific guidance to WebPlatform Docs or the WAI-Engage wiki where people can easily add other tools.

Easy Checks - A First Look at Web Accessibility

Contents

Introduction

Using this page

Tools

FF Toolbar

WCAG Links

Visual and Non-Visual Checks

Practicing with BAD, the Before-After Demo

Little Background

EOWG Comments on the Introduction

Quick Checks

A Deeper Look

Check image text alternatives ("alt text")

To check if any images are missing alt text with the W3C Validator: [non-visual]

[+/-] To check if alt text is appropriate - with FF toolbar: [visual]

[+/-] To check if alt text is appropriate - with any browser: [visual]

Tips:

[+/-] To try checking the alt text in BAD:

Checking if any images are missing alt text in BAD: [non-visual]

Checking if alt text is appropriate in BAD: [visual]

Learn more from:

EOWG Notes on alt text

Check headings

To check headings outline with the W3C Validator: [non-visual & visual]

[+/-] To check heading markup is appropriate - with FF toolbar: [visual]

[+/-] To check heading markup is appropriate - with any browser: [visual]

[+/-] To try checking headings in BAD:

Checking headings outline with the W3C Validator in BAD [non-visual]

Checking heading markup is appropriate in BAD [visual]

Learn more from:

EOWG Notes on Headings

Check keyboard access, labels, content order, visual focus

What To Do

What To Look For

References

Notes

Check page title

What to do [non-visual]

What to look for [non-visual]

Tips

BAD Example

References

EOWG Notes on Page Title

Check color contrast

First stage: What to do

Common failures

Second stage: What to do

Common failures

References

Notes

Comments 2012-Nov-30

Video, Sound, (multimedia)

What to do

What to look for

References

Notes

Comments 2012-Nov-30

Check forms

Forms - simplified

Are there any forms

Visually examine the instructions for the form and input fields

Keyboard access

Logical sequence

Use the keyboard to enter data into the text field.

References

Notes

Comments 2012-Nov-30

Check zoom, enlarge, resize

What to do

Common failures

Note

References

Comments 2012-Nov-30

Notes for discussion

Comments 2012-Nov-30

Next Steps

Contributors