Prelim Eval 2013-Feb-08
This is an old archive of Easy Checks
Easy Checks - A First Look at Web Accessibility
Contents
- #Introduction - updated 8 Feb
- #Page title - updated 8 Feb
- #Image text alternatives ("alt text") - updated 4 Feb
- #Headings - updated 4 Feb
- #Color contrast -
- #Zoom and text size -
- #Keyboard access, labels, content order, visual focus -
- #Multimedia (video, audio) alternatives - updated 7 February
- #Forms -
- #Next Steps - updated 8 February
[Thanks to #Contributors!]
Introduction
[Updated 8 February]
These easy checks guide non-experts to gauge the accessibility temperature of a web page. With these few simple steps, you can get an idea whether or not accessibility is addressed in even the most basic way.
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 would be needed to check all issues comprehensively.
Using this page
Checks are provide for specific aspects of a web page:
- Page title
- Images (pictures, illustrations, charts, etc.)
- Related to text:
- Headings
- Color contrast
- Zoom and text size
- Interaction: Keyboard access, labels, content order, visual focus
- Multimedia
- Forms
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 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 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].
(If you can't download these tools, that's OK; you can still do the checks indicated "with any browser".)
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.
Little 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) is software or hardware that people with disabilities use to improve interaction with the web.
- 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.
- voice input is using speech instead of a keyboard and mouse.
If you want to learn more, see:
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. For an introduction to WCAG, see the WCAG Overview.
EOWG Comments on the Introduction
[previous wording drafts: 1 Feb, 23/24 January version, 22 January, 17 January.]
- [done] this introduction is very clear. In the paragraph on FF toolbar, what about indicating that this tool is not only free but also available in many languages? {Sylvie}
- [done] It is not clear to me if the section about using bad should be deleted or not. If it remains, what about telling the reader that it comes from wai and giving the link to it? {Sylvie}
- [done] Maybe add "Assistive Technology" to "Little Background" if we use this term? {Anna Belle}
- comment {name}
Page title
[updated 8 February]
[image: top of browser showing full title of current page, and multiple page tabs showing truncated titles. AND page title in window title bar at the top]
Good page titles are particularly useful when people have multiple web pages open at the same time. The first part of the title is shown in browser tabs, as in the above image. Titles are also used for bookmarks/favorites and in search engine results. The first thing screen readers say when the user goes to a different web page is the page title. Page titles are important for orientation — to help users know where they are and move between pages.
What to do
- If possible, use a browser that displays the page title in the window title bar, like this: [image].
Most browsers have a window title bar by default, except Chrome and IE 9 and later. In those browsers, and most others, you can see the full page title by hovering over the tab, like this: [image]. [@@keyboard way to do this?] - 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. Some guidance is linked from the Related Resources section of Understanding Success Criteria 2.4.2.
- Titles should be "front-loaded", meaning the important and unique identifying information is first.
- 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
- Poor titles:
[+/-] To check page title - with IE WAT:
- Open the web page you are checking.
- In the toolbar, select "Structure", then "Heading structure". Or, with the keyboard: [@@keyboard shortcut]
A new page opens. - The page title is shown after "Title:".
Learn more about page titles from:
- Page Titled - Understanding Success Criteria 2.4.2 for WCAG 2.0 (Level A)
EOWG Notes on Page Title
- [done]This section really boggles my mind. It is visually so complex about a seemingly straight forward question - does the page have a title that clearly and succinctly describes its content and purpose? is there a compelling need for bracketed [non-visual] designation? It seems to me to be confusing and distracting. Might this be a case where the nested lists of what makes a good page title is also too much information for an Easy Check, since making those judgement calls result in a check that is less "easy"? {Sharron}
[reply - I added specific questions for 8 Feb agenda & removed the brackets & deleted 2 tips {Shawn}]
- [done] The bracketed [non-visual] is confusing e.g. the instructions state "Look" and the title indicates "non-visual". I would remove the square bracketed bits in the title. The "Tips" part is well explained. Perhaps, expand on IE WAT. For beginners, they may not understand what "WAT" is. {Vicki}
[reply: IE WAT is explained in the intro. since we'll probably use it and FF Toolbar repeatedly, probably don't want to explain them each time {Shawn}
- [done] I deleted two tips: {shawn}
- "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.
- 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>
- [done] I deleted the BAD Example because 1. you don't really need to see an example of how to check this. 2. The good titles aren't totally frontloaded like our tips. {shawn}
It was: In BAD, all of the inaccessible 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 accessible pages are titled: Welcome to CityLights!, Citylights News, Citylights Tickets, and Citylights Survey.
- ...comment {name}
Image text alternatives ("alt text")
[updated 4 February]
Text alternatives ("alt text") convey the purpose of an image. They are used by people who cannot see the image. (For example, people who are blind and use screen readers can hear the alt text read out; people who have turned off images to speed download or save bandwidth can see the alt text.)
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=""
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 more description of more images; and others prefer 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 content. 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.)
- If the image is not important for understanding the content — for example, it is just decoration or "eye candy" — it should have null alt (
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; it's "alt attribute", or you can say "alt text".) It looks like this in markup: <img alt="WAI logo" src="/wai/logo.png">
There are three options for checks listed below. The first one is easiest of you have the WAT toolbar. If you don't have any toolbars, there is a check at the end for any browser.
[+/-] To check alt text - with WAT: [non-visual & visual]
- Open the web page you are checking.
- In the toolbar, select "Images", then "Show Images". [image] Or, with the keyboard: [@@keyboard shortcut]
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 tan 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: [visual]
For each image, see if the alt text adequately conveys the information in the image it is next to, per the Tips below.
[+/-] 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 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.
With the FF Toolbar, there is no explicit indication if images are missing alt, so you probably want to do one of the other checks if you want to catch all missing alt. [@@ OPEN: is this true? if so, this sentence could use editing. OR should we just leave this FF check out all together? Andrew: The FF Toolbar does enable a display of images with missing alt-text - select "images" then "outline images" then "outline images without alt attributes"]
[+/-] To check if alt text - with any browser: [non-visual & visual]
- 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: [visual]
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 above.
[+/-] To try checking the 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 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)
- [when published, A simple alt text decision tree ]
EOWG Notes on alt text
- [done] The alt text decision tree gives clear guidance on deciding what type of alt text to add. Could it be referenced? http://dev.w3.org/html5/alt-techniques/#tree {Vicki}
[reply: not really until it's published, but that might happen soon. - [done] 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=""
). [@@ maybe, add (no space between the inverted commas) {Vicki}].
- What about the decorative image included via CSS - no alt-text exists and isn't required. Too confusing for beginners? (E.g. the background images used for email, RSS and Facebook on http://treasury.gov.au/){Andrew} [Shawn agrees it's beyond Easy Check]
- One way of advising what should be in the alt-text is to suggest they pretend they are reading the page to someone over the telephone - what would they say about the image? Would they even mention it? {Andrew} [Shawn: right. we have "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?" Should we change that to phone?]
- [done] In the toolbar, select "Images", then "Toggle Img/Alt". [image][@@AnnaBelle- I don't see "Toggle Img/Alt", but rather "Show Images". Andrew: I think earlier version had the 'toggle' Shawn: yup, i have a very old version :-) I changed it]
[Previous comments archived in 1 Feb snapshot ]
Headings
[updated 4 Feb]
Web pages often have sections of information separated by visual headings, for example, heading text is bigger and bold (like "Check headings" right above this sentence :-). To make these work for all users, the headings need to be "marked up" 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. @@ Headings aren't just for navigation - they are also for context, as implied in the opening sentence {Andrew}
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:
- 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 IE WAT: [non-visual & visual]
- Open the web page you are checking.
- In the toolbar, select "Structure", then "Heading Structure". Or, with the keyboard: [@@keyboard shortcut]
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?
[+/-] To check headings outline - with FF toolbar: [non-visual & visual]
- Open the web page you are checking.
- In the toolbar, select "Information", then "View Document Outline". [image] Or, with the keyboard: [@@keyboard shortcut]
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?
To check headings outline - in any browser: [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?
[+/-] To show heading markup in the page - with IE WAT: [visual]
- Open the web page you are checking.
- In the toolbar, select "Structure", then "Headings". Or, with the keyboard: [@@keyboard shortcut]
Headings will be surrounded with <h1>, <h2>, etc. icons in purple text on tan background. @@perhaps avoid indicating colors. This can change with updates and it's hard to keep track of. The indication of <h1> will certainly remain in future versions.
- 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 show heading markup in the page - with FF toolbar: [visual]
- Open the web page you are checking.
- In the toolbar, select "Outline", then "Show Element Tags Names When Outlining". Or, with the keyboard: [@@keyboard shortcut]
- In the toolbar, select "Outline", then "Outline Headings". 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 show heading markup in the page - 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:
To check headings outline: [non-visual]
- Follow the one of the instructions under "To check 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.
To show heading markup in the page: [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 show 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 from:
- Info and Relationships - Understanding Success Criteria 1.3.1 for WCAG 2.0 (Level A)
- 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 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
- [@@Do we want to point to a resources that shows how screen reader users navigate with headings? There's not much detail in accessibility principles ... ]
EOWG Notes on Headings
- comment {name}
low priority:
- do we want to find an appropriate example of text that is marked up as a heading but it not really a heading?
- Here is one from University of Washington's Accessible University 2.0, fictional pages to teach web accessibility. The Security Check is the only thing marked as a heading. Not sure it fits what we need, and will keep looking. {Sharron}
- do we want to find an appropriate example of a web page with no headings at all? to show what you get in the Validator outline?
Color contrast
[Anna Belle and Sharron are editing this section. Here is the previous 1 February draft of color contrast with lots of text.]
Zoom and text size
People with mild to moderate visual impairments may need to enlarge content in order to read it, or read it without straining. This simple requirement is mostly achieved by the functionality of the browser and ensuring that the page design supports that functionality.
Most browsers offer two ways of enlarging content: page zoom and text resize. Page zoom works by scaling up the page content, so that text, images, and buttons are all increased or decreased in size, and the integrity of the layout is maintained. Text resize only affects text, although implementation techniques can be used to also change the widths and heights of containers, margins, padding, and other aspects of the design.
Not all browsers offer both choices, and some browsers will not resize text if it has been set using fixed units such as pixels.
- In browsers that support zoom, increase zoom level to 200% or maximum zoom if smaller than 200%
- In browsers that support text resizing, increase text size to 200% or maximum size if smaller than 200%
What to do
For each browser to be tested:
- Set the screen window to full width
- 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 +).
- In browsers that support page zoom, enable this option and use the appropriate control to increase zoom level to 200% or maximum zoom.
- In browsers that support text resizing, enable this option and use the appropriate control to increase text size to 200% or maximum size.
What you will see
- For page zoom layout should remain approximately the same for fixed width designs, and will reflow in the same way as resizing the window would at small sizes.
- For text resize most aspects of the design will not change and layout will probably not increase in size. Content will reflow appropriately within the same available space as text increases in size.
What to check for
- Text should increase in size in both cases, addionally with page zoom all elements on the page should increase in size.
- No content should overlap.
- All controls must be clickable.
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.
EOWG notes on zoom and enlarge
[See e-mail thread on zoom & resize ]
[done - 1 Feb agreed to include it] We previously thought we wouldn't include this in the easy checks. One of the issues was conflicting perspectives in forums and critiques that 200% is too hard to meet. Ian has re-drafted this section.
Please comment on reasons to include it or not. Feel free to edit the main text as well.
- @@comment {name}
- @@comment {Vicki} I would include this as it's well explained and sounds simple :) Often, this is a check which is quite difficult to understand but as it's explained quite clearly here, I would include it. One comment: at the end of the first section (just before "What to do"), there are two bullet points on the browsers and zooming. Shouldn't this be removed and left (as currently duplicated) in the "What to do" section?
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. @@ need to explain 'visible focus indicator' and 'logical tab order' - we can't just use these phrases and expect folk to understand {Andrew}
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. @@ Alternative: Press the 'tab' key to move through the interactive elements on the page. {Andrew}
- Use the keyboard to set the focus to all focusable elements on the page. @@ Huh?? What does this mean in comparison to previous bullet? {Andrew}
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 or click)?
- 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) @@ Covered in point 2? {Andrew}
- 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). @@ swap bracket for phrase before to reduce jargon? {Andrew}
- 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...
- ...
Multimedia (video, audio) alternatives
[Updated 7 February]
Check multimedia elements to ensure that visual and audio content includes equivalent alternatives and that the media player is fully accessible.
What to do
These steps will give you a quick and easy first look. They will identify that alternatives for media content have been considered and attempted. A more comprehensive testing process will be needed to verify the quality of the alternatives provided.
- Follow the steps for keyboard access to ensure that the media player controls are labeled and operable by all users.
- Play a short piece of the audio content
- Play a short segment of the video content
- Toggle closed captions on (if available) {@@ need some guidance on how to do this?}
- Toggle audio description on (if available) {@@ need some guidance on how to do this?}
- If no captions or audio description options are provided, check page for transcript or link to transcript
What to look for
Captions
- Are captions provided?
- Are they synchronized to the spoken content? {@@ not sure this is necessary for easy check?}
- Has important audio content other than dialogue been included? (music, relevant ambient sounds, etc) {@@ need to say more and maybe give examples, or is that beyond easy check?}
Audio Description
{@@ think most people have no idea what this is and we need a brief explanation? Andrew: agree}
- Is an audio description track provided? {@@ could be a separate file, not a track}
Transcript
- If captions and audio descriptions are not provided, look for a link to a text-based script containing dialogue and other audio content and description of video needed for understanding.
- Check for spelling and accuracy. {@@ I think spelling and accuracy is beyond quick check}
Learn more about providing alternatives for media content
- Multimedia Accessibility FAQ
- Captions Understanding Success Criteria 1.2.2 for WCAG 2.0 (Level A)
- Audio Description or Media Alternative Understanding Success Criteria 1.2.3 for WCAG 2.0 (Level A)
EOWG Notes on Multimedia
- Generally, we aren't addressing the levels; however, this one is complicated. Time-based Media: Understanding Guideline 1.2 has 9 success criteria, including A, AA, AAA -- eek! Ideas on how to address this? {Shawn}
- comment {name}
- vision and hearing needed for checks:
- To check if there are captions, need to be able to see. [visual]
- To check if the captions are synched, need to be able to hear. [auditory]
- To check if audio description is provided, need to be able to see? hear?
- other?
- [OPEN - add back in] Auto play - it is easy to test whether the audio starts automatically. {Suzette}
- Audio contrast - mightn't be able to say yes/no, but might be able to say 'could be a problem' {Andrew}
- comment {name}
Forms
SK: see email for update 11pm UK, 23 Jan.
[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:
- Text alternatives to non-text content
- Functionality is available from a keyboard
- Users can easily navigate, find content, and determine where they are
- Content appears and operates in predictable ways
- Users are helped to avoid and correct mistakes
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.
Next Steps
So, you've spent a little time getting a sense of the accessibility issues that need to be addressed, but what do you do next? How can you flag the problems and solutions, while being sure that the information reaches those who can make the changes happen?
If you have a bug-tracking/helpdesk system, you might use that. Or you might decide it would be more effective to write a report in which you group problems and solutions in terms of people's roles and responsibilities. [@@ JS: maybe link to WAI-Engage, even though it's in progress?]
What works best will depend on your circumstances. Regardless, you'll want to describe the issues clearly. For examples of recommendations we have developed to guide site visitors who experience difficulty accessing a web site, see a section of [Contacting Organizations about Inaccessible Websites http://www.w3.org/WAI/users/inaccessible] called "Describe the Problem." In addition, these Sources for More Information will help your colleagues familiarize themselves with additional information.
When you're ready to conduct a more thorough evaluation,either internally or by hiring a qualified contractor, the [WCAG- Evaluation Methodology Overview] (coming soon) and accompanying documents will help you develop your plans as you continue your efforts to provide a more accessible web for all.
EOWG Notes on Next Steps
- We currently say "group problems and solutions in terms of people's roles and responsibilities" - I wonder if "solutions" is too much to expect for newcomers and also knowing who to assign the problem too. As they're only looking a small number of issues, I'd suggest they just report their findings by page to the content owner or maybe the web publishing team. However, maybe they could suggest 'potential' solutions to some of the problems such as alt-text or page-title. {Andrew}
- This seems focused for an internal review. Need to also address an external reviewer. {Shawn}
- also point to more resources? {Shawn}