Prelim Eval 2013-Feb-21

From Education & Outreach
This is an old archive of Easy Checks


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

title ideas

Contents

[Thanks to #Contributors!]

Introduction

Introduction in WAI draft page

EOWG Comments on the Introduction

  • [done - changed] editor's discretion:section tools.
    First sentence:
    "Most of these checks you can do with any browser, that is, you do not need to download anything."
    Are the words in the right order in this sentence or should it be:
    "You can do most of these checks with any browser, that is, you do not need to download anything"? {Sylvie}
  • [done - this was from the wiki to HTMl conversion -- it added title to all links with the URI. I've removed them. good catch!]Clarity of links:
    It is not easy for the readers to read the links to the different tools as http text. May be the name of the tool/browser would be more useful?
    Example: Link text:
    "http://www.mozilla.org/en-US/firefox/new/".
    Or:
    "https://addons.mozilla.org/en-US/firefox/addon/web-developer/add-on."
    The link text questions seems to concern all the documents linked on this page. {Sylvie}
  • comment {name}

Page title

Page title in WAI draft page

EOWG Notes on Page Title

  • [done] the shortcut with the WAT toolbar is no direct one:
    You first have to press ctrl+alt+6, then press down arrow key once or type the first menu letter, maybe H for the English version of the toolbar? {Sylvie} [Thanks, Sylvie! I added it. {Shawn}]
  • [add to wish list for later] The text says: "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 open pages."
    Would it be useful to have a sound clip of the screen reader going through page titles? Low priority, but maybe neat for people who don't know screen readers? {Shawn}
  • [done? edited to simplify] The text says: "Most browsers have a window title bar by default, except Chrome and IE versions 9 and later. In those browsers, and most others, you can see the full page title by hovering over the tab".
    Suggested text: "Many browsers have a window title bar and tabs, whereas others, such as Chrome and IE versions 9 and above, use tabs only to display the page title. For browsers with tabs only hover over the tab to view the full page title" {Vicki}.
  • [open] Suggest the alt-text on screen grabs include the browser name and version {Andrew}
    reply: I think it would add unnecessary clutter - lots of text and do people who cannot see the image care so much which browser & version? what do others think? {shawn}
  • [open] We should include FF web developer toolbar example too - 'Information' then 'View Page Information' opens a new window with the page title at the top {Andrew}
    why? the page title is shown in the window title bar so why would you need to use the develop toolbar to get it? {shawn}
  • comment {name}

Images for Page Title

  • To check page title - with IE WAT:
    <...image link here...>

Image text alternatives ("alt text")

alt text in WAI draft page

EOWG Notes on alt text

  • [done? "Some people prefer most images to have more detailed description; and others prefer much less description."] Text reads: "Some people prefer more description of more images; and others prefer less description."
    Suggested simplified wording: "Some people prefer more descriptive text, others prefer less". or "Some people prefer more description of images, others prefer less." I would remove the "more" of "more images" {Vicki}
    The issue is that for a given image, some people think there should be no alt at all, some think there should be brief alt, and some think there should be detailed alt. I think your re-wording misses that some people want some images to have no description at all, whereas others think those images should have some description. I tried another edit in between. :-) {shawn}
  • [done, with slight tweak.] Last paragraph. Text reads: (So "alt tag" is technically incorrect; it's "alt attribute", or you can say "alt text".)
    Minor editorial comment. Suggested text: (So "alt tag" is technically incorrect; "alt attribute" would be the correct term or you can say "alt text".) {Vicki}
  • [done] Editorial plus typo comment: Text reads: "The first one is easiest of you have the WAT toolbar." Corrected text: "The first one is the easiest if you have the WAT toolbar.". {Vicki}
  • [done] First check, point 2.: Guidance indicating color "...on a tan background." I think this might depend on the browser version and also the resolution. My version, for example, shows a pinkish background. Perhaps, you could say "... on a colored background". {Vicki}
  • [done] First check, point 4.: Editorial."... Tips below." The Tips are above. {Vicki}
  • [open EOWG] Finally, I'm mulling over the term "inappropriate alt text". Would that be the correct term? {Vicki}
    other ideas?
  • comment {name}

Keyboard Access {Andrew}

[done - add to WAI draft page 20 Feb {Shawn}]

  • To check alt text - with IE WAT {Andrew}
    • ctrl-alt-4, then arrow down to 'show images' which displays the alt-text adjacent to the image
  • To check alt text - with FF toolbar
    • Alt + 'T' for "Tools", then 'W' for "Web Developer Extension", then 'I' "Images", then 'O' for "Outline Images", then 'A' for "Outline Images Without Alt Attributes"
    • Alt + 'T' for "Tools", then 'W' for "Web Developer Extension", then 'I' "Images", then 'A' for "Display Alt Attributes"

Headings

Headings in WAI draft page

EOWG Notes on Headings

  • [done] heading h4: "To try checking headings in BAD"
    There seems to be one or two words too much:
    "Follow the one of the instructions under "To check headings outline" above"
    Suggestion:
    "Follow one of the instructions under "To check headings outline" above" {Sylvie}
  • comment {name}


Keyboard access {Andrew}:

[done - add to WAI draft page 20 Feb {Shawn}]

  • To check headings outline - with IE WAT
    • Ctrl + 6, then down arrow to "Heading Structure"
  • To check headings outline - with FF toolbar
    • Alt + T, then 'W' for "Web Developer Extension", then 'I' for "Information", then 'm' for "View Document Outline"
  • To show heading markup in the page - with IE WAT
    • Ctrl + 6, then down arrow to "Headings"
  • To show heading markup in the page - with FF toolbar
    • Alt + T for "Tools", then 'W' for "Web Developer Extension", then 'O' for "Outline", then 'S' for "Show Element Tags Names When Outlining"
    • Alt + T for "Tools", then 'W' for "Web Developer Extension", then 'O' for "Outline", then 'H' for "Outline Headings"

Color contrast

[Anna Belle and Sharron are editing this section. Here is the previous 1 February draft of color contrast with lots of text.]

Good contrast between 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. [@@Anna Belle question - What does this sentence mean? Maybe give an example, e.g. The standard black text on a white background is very high contrast, whereas a medium gray on a light gray back is low contrast.]

Some users have requirements for very high or very low contrast, or a particular colour combination and they may choose to vary a site's colour choices by using their own preferred style sheet.

In addition, there are users who have lower resolution screens that may not render subtle colour combinations properly.

Screen reader users will hear the text even if the contrast is poor, or deliberately hidden as white on white or black on black! [@@Anna Belle question - delete?]

What to do using a browser

  1. Inspect the text in the main content, menu tabs, links, selected links, buttons, labels and captions.
  2. Watch for instances of pale text that might blend into the background. Examples include grey, light green, yellow or (light?) blue text on an off-white background) or a background that is a slightly darker shade of the same colour.
  3. Watch for instances of dark colours on a dark background eg purple, red or dark blue on black.
  4. Investigate any suspect instances. [@@Anna Belle question - What does this mean?]

What to do using on-line tools

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

  • 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 [@@Anna Belle question - maybe just two?]
  • 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. [is this really an easy check?]
    • list named tools
  1. Watch for for normal sized text with a contrast ratio that is less than the minimum recommendation of 4.5:1.
  2. Watch for large, bold text such as a page heading level that has a contrast ration set at 150% (1.5 ems) less than the minimum recommendation of 3:1.

BAD example

Learn more about color contrast

back to Contents

Zoom and text size

23 Feb version

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.

What to do

For each browser to be tested:

  • Set the screen window to full width
  • Open your preferred browsers.
  • Internet Explorer 7 and above, 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 +).
  • Text resize controls vary by browser:
    • Firefox: Go to View > Zoom > Zoom Text Only, then use the same controls as for zoom
    • Chrome: In Settings, search for 'Font size', then select a size
    • Internet Explorer 7+: Go to Page > Text Size, then select a size
  • Test at up to 5 increases in zoom or text size, or the maximum size if the browser does not support incremental increases or cannot increase text that far

What to check for

  • Text should increase in size in both cases, additionally with page zoom all elements on the page should increase in size.
  • Horizontal scrolling should not be required to read long lines of text, although it is acceptable to need to scroll to bring different areas of the page in to view
  • 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


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.

  • 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? {Vicki}
  • comment {name}

back to contents


PREVIOUS VERSION

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


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.

  • 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? {Vicki}
  • comment {name}

back to contents

Keyboard access, 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. 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. This requires keyboard access to all functionality. Without using a mouse, a user must be able to make visible, logical progress through the page elements, including links, form inputs, media controls, and other user interface components.

What To Do

  • Click in the address bar, then put your mouse aside and don't use it.
  • Press the 'tab' key to move through the interactive elements on the page.
  • For subsequent movement within elements, such as select boxes or menu bars, press the arrow keys
  • To select a specific item within an element, press the Enter key or Space bar.

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?
  • Watch as you tab through the elements to verify that the focus indicator is clearly visible - that you can visually determine where the focus has currently landed. (Note that 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
  • Can you tab away from all elements that you can tab to and continue tabbing through to the end of the page, circling back again to the top? (e.g. you don't get stuck anywhere and can't move on - known as a "keyboard trap")
  • If there is a drop-down list (for example, for choosing from a select box or navigation to another menu-listed page)
    • When tabbing into the drop-down box, can you use the down/up arrow keys to move through the options?
    • When the listed content receives focus, are items indicated but not selected automatically? Selection should occur only when user signifies choice through additional keyboard action (usually Enter or Space bar)

References

Notes

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


back to contents

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.

  1. Ensure that media does not begin to play automatically or, if it does, that tit stops after 3 seconds.
  2. Follow the steps for keyboard access to ensure that the media player controls are labeled and operable by all users.
  3. Play a short piece of the audio content
  4. Play a short segment of the video content

What to look for

Captions

  • Toggle closed captions on (if available). Look in the control panel of the media player for the closed caption icon button. @@include logo image
    • Are captions provided?
    • Do captions seem in sync to the spoken content?
    • Are the people who are speaking identified when they speak?
    • Has important audio content other than dialogue been included? (music, door slamming, applause, noises that impact meaning of narrative, etc)

Audio Description

Audio description is a method of using the natural pauses in dialogue or between critical sound elements to insert narrative that translates visual image information into descriptive text, thereby making it accessible to blind members of an audience. On the web, audio description may be provided using a separate audio track or by means of a text description.

  • Toggle audio description on (if available). Look in the control panel of the media player for the audio description icon button. @@include logo image
    • Is an audio description track provided in the media itself?
    • If not, is an audio description provided as text?

Transcript

  • If no captions or audio description options are provided, check page for embedded transcript or a link to transcript page. Transcript should contain all dialogue and other meaningful audio content as well as a full description of visual content to the extent it is needed for understanding.

Learn more about providing alternatives for media content


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}
  • Order of alternatives - I'd suggest Transcripts ahead of Audio Description as easier to check for and much more common {Andrew}
  • comment {name}


back to contents

Forms, form labels, and error messages

[15: maybe not]

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

Forms are everywhere on the web and successful user interaction relies on clear, understandable, and accessible form controls. Even simple forms like log-in and search boxes can be problematic if not properly built. Some critical elements that can affect screen reader users are much easier to detect using an automatic tool to check the HTML and CSS, or within a user trial with an experienced screen reader user.

Review previous keyboard access checks to ensure that visible, logical access to form inputs is provided for those who don't use a mouse. Review text alternatives checks to ensure proper identification of any graphic buttons or other inputs.

Forms are complex and will likely require more in-depth assessment. In the meantime, these easy visual checks will help you identify some common problems.

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

Form labels

Use your mouse to check for labels explicitly tied to the form fields by clicking on the label - look to see if the cursor now appears in the associated text entry box or if the associated radio-button or check-box becomes selected.

You can also use a browser based testing tool to check the code for labels, the most reliable method for the provision of accessible forms.

What to look for:

  • In FF Toolbar > Navigation > Forms.
    [Keyboard - Alt + 'T' for "Tools", then 'W' for "Web Developer Extension", then 'F' for Forms, then 'O' for Outline Form Fields Without Labels]
    • Verify that each form has a unique associated label
  • In IE/WAT > Structure > FieldSet/Labels
    [Keyboard - Ctrl + Alt + 6 for "Structure", then arrow down to "FieldSet/Labels" and select]
    • Verify that form has a unique associated label

If forms are not provided in this conventional way, mark the form for further testing in the next, more comprehensive round.

Keyboard access and reading order

Use the Tab key and arrow keys 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 or drop-down menu content.

What to look for:

  • Compare the sequence of information presented visually with the tab through order.
  • Follow instructions to check for equivalent Keyboard Access in previous section.

Data input and error messages

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

What to look for: 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.

References

Several Accessibility Principles are relevant to the accessibility of forms, including those reviewed in the checks for Keyboard Access and Text alternatives. Also consider these:

  • Labels for form controls, input, and other user interface components must be provided. (Labels and Instructions 3.3.2 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)

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

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 what you've discovered, while being sure that the information reaches those who can make the changes happen?

If you're a site visitor who doesn't work for the organization but wants to report accessibility-related concerns, you will likely want to reach out by using the site's contact form or by sending email to a "Webmaster" address. Of course, if you have a specific point of contact in the organization, starting with that person can be beneificial.

On the other hand, if you work for the organization that operates the site you've looked at, you might use a bug-tracking/helpdesk system to report your findings. Or you might decide it would be more effective to write a report in which you group problems and possible solutions in a way that makes sense within the company's structure.

Whether or not you work for the company that runs the site you've checked, you'll want to describe the issues clearly, including identifying the browser and any other tools you used. Providing as much detail as you can will help others replicate the issue and identify approaches to resolve it. For examples of recommendations we have developed to guide site visitors who experience difficulty accessing a web site, see a section of [ http://www.w3.org/WAI/users/inaccessible Contacting Organizations about Inaccessible Websites] called "Describe the Problem." These Sources for More Information will help your colleagues familiarize themselves with additional references for more details about problems and solutions.   When it's time to conduct a more thorough evaluation,either internally or by hiring a qualified contractor, the [WCAG-EM Evaluation Methodology Overview] (coming soon) and accompanying documents will help you or others develop plans as we all work together to provide a more accessible web for all.

EOWG Notes on Next Steps

  • comment {name}


Contributors

Thanks to:

  • Those who edited in December and January: Suzette (forms, @@), Sharron (Intro, @@), Shawn (Intro, page titles, headings, alt text), Ian (zoom n text resize).
  • Those who commented in December and January: Sylvie, Wayne, Anna Belle, ...
  • 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!}
  • 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 early drafts and versions less confusing.
  • Wayne and Ian for sharing colleagues' related work.
  • Denis for edits to the old page content.

testing image: search-icon.png


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.

Retrieved from "https://www.w3.org/WAI/EO/wiki/index.php?title=Prelim_Eval_2013-Feb-21&oldid=4028"