Archived Work on PreLimEval

From Education & Outreach

Nav: EOWG wiki main page > Evaluation Pages
Old page on WAI website: Prelim Eval
Related: Preliminary Eval - old notes
See also: Eval Analysis for tasks, example user cases with audience, and focus for this and related documents.

Note:

Preliminary Review|Evaluation: Checking the Accessibility of a Web Page

Introduction

Comment: Good start. I think we can trim it down quite a bit. Also, what about a less formal and more direct style? ~Shawn

Web accessibility auditing is often perceived as a rigorous, complex, technical process that can only be conducted by expert resources who are well-versed in the Web Content Accessibility Guidelines 2.0. But when the goal simply consists of determining whether a page meets the most basic requirements and there are no experts around, a less formal approach may be all you really need.

A preliminary review is a method meant to quickly identify basic accessibility problems on a Web site. It does not check every accessibility issues and will not catch all of the problems. Rather, it focuses on key issues that are commonly agreed upon as being the most recurrent problems encountered by people with disabilities on the Web. It is meant to give a general appreciation of the level of accessibility, based on a few simple tests that can be conducted by anyone, without technical knowledge or prior understanding of Web accessibility. As such, the method described in this page is not sufficient to determine if a Web site conforms to Web accessibility guidelines, but it is sufficient to catch the most common pitfalls.

A preliminary review combines some manual checking of representative pages on a Web site, along with the use of several semi-automatic accessibility evaluation tools that are commonly available. Reviewers do not need to know Web mark-up languages, but should have the credentials to install a few browser add-ons on their computer. Reviewers who are looking for a more formal methodology are invited to look at the Website Accessibility Conformance Evaluation Methodology 1.0 (WCAG-EM for short). Other pages in this Evaluation Resource Suite address conformance evaluation and related evaluation topics (links?).

Alternative Introduction

Testing and evaluating a web site for accessibility may seem intimidating but it need not be. There are simple ways to check on some basic features that do not require special skills or tools beyond your browser controls. Here you will find two approaches to doing Preliminary Evaluation of your pages. The first is a Quick Check - a list of 5 things you can do in 5 minutes. The second, while still a relatively "light" evaluation, may require more knowledge of accessibility principles and a few testing tools. [~Sharron 10/18/2012]

Quick Checks

Here are 5 things you can do to quickly check for accessibility barriers on a web page:

  1. Use your browser controls to turn off images. View text alternatives and determine if they are equivalent.
  2. Enter the URL of your test page into one or more free, online accessibility one-page checkers. {— Perhaps link to or expand to include links to checkers ~ Sharron}
  3. Tab through the page - is focus visible, is the order logical, and can all content be reached and operated?
  4. Examine the links, are they evident and do they clearly describe the link target or function?
  5. Look for the page title displayed at the top of the browser - does it accurately reflect the page content and purpose?

Once you have taken this quick dip into accessibility 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.

More Checks

{Comment: Please feel free to change this list — I just stuck Denis' list in here to have something to look at. ~Shawn}

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.

  1. Load your tool kit. (List tools that can be freely accessed and/or installed in browser, or link to Complete list of Web Accessibility Evaluation Tools and Web AIM's Review of Free, Online Accessibility Tools)
  2. Choose or create a reporting template (Introduce Evaluation Templates from WAI)
  3. select a representative page sample (Introduce and link to WAI Conformance Evaluation Page
  4. Using your chosen template as a guide, examine the following features of the web page(s) you are evaluating: (Note to EO: Here is where we can describe testing procedures for each of these - and likely additional ones. Please suggest structure and additional content)

Text equivalents for non-text content

Content structure and semantics

Use of color and contrast

Form fields and labels

Keyboard navigation

Significant hyperlinks

Language identification

Common use cases for a preliminary evaluation

Comment: What is the purpose of this section? Is it needed? If it is helpful, can it be at the bottom so people don't have to wade through it if they don't want to? ~Shawn

Vendor is commissioned to develop an accessible website

Client X commissions Vendor A to develop an accessible website that needs to comply with local or international guidelines. Accessibility requirement are clearly stated as a technical requirement in the Project's contract agreement. Vendor A delivers said website and claims it totally meets fore-mentioned requirements. Being under legal pressure, but lacking the expertise to really tell if the website is compliant with the requirements, Client X uses the Preliminary Evaluation process to check for basic things like alt attributes, keyboard navigation and headings levels on random pages. Client X determines if the website passes those acid tests or not, based on the results. If the website passes, then Client X designates a technical person to dig further with a more formal process. If the website fails, then Client X refuses the Project deliverable and requires that Vendor A meets the technical requirements mentioned in their contract agreement.

Project Manager X wants to validate Developer A's work

Project Manager X is responsible for quality control in the Web agency. Developer A has been tasked with delivering an accessible website for a client who's under legal pressure to launch a Section508 compliant website. As Web accessibility is not a strong skill in the agency, Developer A is at a loss with what needs to be done. Manager X discovers the Preliminary Evaluation process and decides to share that information with Developer A, so the most basic requirements are properly covered. Once Developer A manages to successfully cover the basics, Manager X calls in an external Web accessibility expert to help the team go further. Having discovered how easy it is to cover accessibility basics, Developer A integrates these best practices to his already long list of development best practices. Manager A is then in a better position to grab market shares from organizations who insist on Web accessibility as a technical requirement.

End-User X wants to know if Organization A's website is accessible

End-User X visits Organization A's website with a screen reader and finds himself struggling with the site's contents and structure. Lacking the technical skills required to really tell why the website is inaccessible. Using the Preliminary Evaluation process, End-User X is suddenly empowered to do so and decides to check for basic things like alt attributes, keyboard navigation and headings levels on random pages. End-User X determines if the website passes those acid tests or not, based on the results. End-User X decides to contact Organization A to tell them about the accessibility barriers found and invites Organization A to fix the problems. Organization A receives the email, realizes they may get in trouble if they don't fix those problems and decides to "do-the-right-thing". Once everything is in order, End-User X has access to the information provided on the website like any other citizen would.

Select a representative page sample

Comment: How about keeping this page simple and not even covering this here? Instead point to it on the Conformance Evaluation page. ~Shawn

From the Web site to be reviewed, select a representative sampling of pages that match the following criteria:

  • Include all pages on which people are more likely to enter your site ("welcome page", etc.).
  • Include a variety of pages with different layouts and functionality, for example:
    • Web pages with tables, forms, or dynamically generated results;
    • Web pages with informative images such as diagrams or graphs;
    • Web pages with scripts or applications that perform functionality.

Note: there are special considerations for web sites with database driven dynamically generated web content.

More Thorough Evaluation

@@ point to Conformance Evaluation page and WCAG-EM.

Preliminary Review|Evaluation: Archived from omitted / changed materials 7 December 2012

Check text descriptions for images [15: yes] [drafted, needs simplifying]

EOWG notes - 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.

Text alternatives convey the purpose of an image or function to provide an equivalent user experience for a user who may not see the images. For instance, a text alternative for a search button is "search".

What to do

  1. Disable images in the browser
  2. Turn off CSS in the browser
  3. Use free checking tools to list the text alternatives (or lack of them) for all graphic elements
  4. If content is multimedia, see also

What to look for

Turning off the CSS in a standard browser will allow you to determine if image content is delivered as HTML (an img element) or as background CSS. If it is a background image, ensure that all information and function remains available when CSS is turned off. If it is HTML, you may restore the CSS and perform the following checks:

  • Ensure that every HTML img element has an alt attribute - alt="xxx" - with specific content according to the following best practices:
    • If image contributes meaning to the page content, that meaning must be fully explained in the brief alt text.
    • If image is a link or control of dynamic activity, the alt attribute associates the image with the link target. Alt text should say what image does or where it links, not how it looks
    • AT recognizes image links and buttons - ensure that “Button” or “Link” is not part of the alt text.
    • If image contains text, ensure that the very same text is included as an alt attribute.
    • If image has a function that is decorative, redundant or generally conveys no information, then ensure that alt=”” (also known as empty alt text.)
    • Ensure that no linked images use empty alt text UNLESS onscreen text is wrapped in the same anchor tag.
    • If image contains complex information, such as charts and graphs ensure that equivalent information is provided as a long description and/or on screen explanatory text

References

Notes

  • Text that is actually an image.
  • Important image should have alt text that provides adequate alternative of the image for people who cannot see it...
  • Image that doesn't convey important information...
  • @@ Some guidance on not saying things like "this is an image..." or "this is a link..."

Comments 2012-Nov-30

Sylvie: It is complicated, because you have to read a lot first and then do the tests Vicki, Suzette, Sharron: agree it should be simplified Shawn: Include in 15 minute check, but simplify

Check headings and other semantic structure [15: yes] [some parts drafted]

EOWG notes - 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.

... @@ brief summary of why & what to check for ... See also:

What you're looking for: @@

  • Does the page have any headings?
  • Are the things that look like headings that aren't marked up as heading?
  • Are there things that are marked up as headings that aren't really headings?

Checking with WAVE

  1. Open WAVE
  2. Enter the web page:
    • If the website is online: Enter a web site address and click the "WAVE the page!" button.
    • ... Upload a file...
    • ... Check HTML code...
  3. Check headings:
    • ...
  4. Check lists:
    • ...

Checking headings with HTML Validator

  1. Open the W3C HTML Validator (The W3C Markup Validation Service).
  2. Select the appropriate tab and input the page:
    • If the web page is online, leave the Validate by URI tab selected.
      In the Address field, type the URI (e.g., www.w3.org).
    • If the web page is on your local computer, click the Validate by File Upload tab.
      In the File field, select "Choose..." and find the file on your computer.
    • If you will paste the HTML code/markup, Validate by Direct Input tab.
      Paste your HTML in the Enter the Markup to validate: field.
  3. Click the More Options link.
  4. Select the Outline checkbox.
  5. Click the Check button.
  6. In the results page at the top, click the Outline link.
  7. Compare the Document Outline to the visual rendering of the page.
    • Are the things that look like headings listed in the Document Outline?
    • Are there things in the Document Outline that aren't really headings?

Comments 2012-Nov-30

Sharron: It should be included, but to make it easy you should use a tool to show you the headings Shawn: You can do this with W3 validator, WAVE, and others, without installing software Sylvie: There are other tools that will tell you when you have missed heading levels Shawn: Clear yes to include

Check keyboard access [15: yes] [some drafted, needs work to merge]

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

OPEN: Try merging into this one: visible focus, content order, and including relevant info on forms.

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.

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.

(see also Forms)

(see also Visible Focus)

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

References

Notes

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

Visible focus [try merging with keyboard access]

EOWG notes.
5min: probably not (unless merged with keyboard access)
15min: probably
Without visual rendering: Cannot test

NOTE: Should this be merged with the keyboard access?

Use keyboard only navigation to ensure that a user who relies on the keyboard will be able to know which element among multiple elements has the keyboard focus. This is an important element in facilitating success for keyboard users to operate the page, by letting them visually determine the component on which keyboard operations will interact at any point in time. People with attention limitations, short term memory limitations, or limitations in executive processes benefit by being able to discover where the focus is located.

What to do

  1. Use the keyboard to set the focus to all focusable elements on the page.

What to look for

  1. Visually examine progress through elements and verify that the focus indicator is visible.
  2. 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.
  3. Verify that any visual changes that occur with mouse hover also are triggered with keyboard focus

References

Comments 2012-Nov-30

Suzette: This is not easy to check. Might be easier to check if it's a pass, but not if it's a failure Sharron, Ian: Think this is quick and easy Anna-Belle: If you give people a reason why they should do this I think they'll get it Shawn: Some people feel it's difficult, other think it is easy, so this is a maybe.

Check the page title [15: probably] [mostly drafted]

EOWG notes - 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

@@ add image showing only a few words with multiple tabs in browser...

Page titles are the first information read by a screen reader; useful for when users have multiple web pages opens, e.g., on different tabs and go between different windows. (Also good for adding to bookmarks & also search engine results.)

What to do

  1. Look at the browser's window title bar.
  2. Look at titles of other pages within the site.

What to look for

  • Verify that the title indicates the specific page and website and distinguishes the current page from others in the set of pages.
  • Make sure that every page in the site does not have the same title.
  • Check that the specific page title is listed BEFORE the name of the website. (for example, About Us - Our Long Web Site Name)

References

Notes

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

Comments 2012-Nov-30

Sharron: Yes, quick and easy Suzette: Some browsers don't display the title

Check link text [15: probably not] [partly drafted]

EOWG notes.
5min: maybe not.
15min: maybe. complicated to determine pass or fail. e.g., visible "more" links could have additional information and indeed pass; therefore, risk for false-fails.
Without visual rendering: Visual rendering may be different to actual content

Wording the text that is linked to indicate clearly where the link goes or what the link does. Some people use a list of links where they don't see the text around it. See also:

Check this

  • @@
    • @@

Common failures:

  • Link text is something like "Click here" or "More" without any additional clarifying text.

Notes:

  • List links (Can't find this in regular Firefox but easy in Opera where you can get a list of links from the standard tools menu, showing both title and url)
  • Issue - titles... (Ian P says never use titles on links, Sylvie agrees.)

Comments 2012-Nov-30

30 Nov minutes

  • Vicki: +1
  • Ian: This might be complicated to determine pass or fail, styling might hide content offscreen or link text might be the alt attribute of an image, making it harder to test
  • Sharron: Does everything need to be a definite yes or no?
  • Ian: Additionally,
  • Shawn: There can be complicated criteria for succcess, we want to avoid false positives / negatives.

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

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:

  1. Does text enlarge;
  2. 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.

Check color contrast [15: yes] [drafted]

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.

<insert from Wayne Dick>

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

Check color coding and shape coding [15: no] [drafted]

EOWG notes.
5min: no
15min: maybe not.
Without visual rendering: Cannot be tested

[Notes: refers specifically to: 1.4.1 Use of Color: Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

NB. consider if other sensory characteristics [such as shape, size, visual location, orientation, or sound] sould be combined here. See 1.3.3 Sensory Characteristics: Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation, or sound.]

Colour, shape and location are often used as a code or visual cue to help people to identify important information or actions on a busy web page.

These visual cues are not always available – someone who is colour blind may find it difficult to distinguish some or all colour combinations. And in addition, people using some types of assistive technology such as a screen reader, Braille or other alternative display systems will not ‘see’ the cue.

It helps to use both colour and a symbol together – for example a red asterisk, provides both a colour and shape code. Alt text on any symbols or icons should make the functional meaning obvious. Any text instructions should allow for someone who cannot see the visual cue.

What to do

Inspect the page carefully to identify any instances of visual cues:

  • Colour - either coloured text or tinted backgrounds and including in-text links.
  • Shape - including icons and symbols, and glyphs such as a smiley face or no entry symbol, or a graphic X to draw attention to removing an item in a shopping list.
  • Location - positioning a symbol or instruction at the top, bottom or side of the main text
  • Text descriptions or instructions - inspect the text for instructions that refer to colour, shape or location such as the button on the left, or the red square.

Common failures

  • In a form, colour used to indicate a required field, or as part of an error messages when a required field is not completed and there is no additional cue such as a colour coded symbol?
  • Text links - colour used alone to indicate links in a paragraph of text, and, there is no additional cue such as underlining?
  • Text instructions, the instruction does not make sense if you can't see the colour, shape or the location of a control button described.
  • Providing alternative text for symbols and icons - in general these need to refer to the function and not the visual appearance. For example if ‘red square’ is the button for the function ‘stop’, then the alt text should say ‘stop’ and not 'red square'.

References

Use of colour: Understanding success criteria 1.4.1 (Level A) {http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-without-color.html}

Sensory Characteristics: Understanding success criteria 1.3.3 (Level A) { http://www.w3.org/TR/UNDERSTANDING-WCAG20/content-structure-separation-understanding.html}

See also: Non-text equivalent 1.1.1 (A) for appropriate text equivalents for any symbols, icons or glyphs and Contrast 1.4.3 (AA) for colour contrast.

Notes for discussion

I put colour, shape and location together because functionally they are about visual coding – is this too big a step?

Also - should the common failures be descriptive, suggest a solution or ask a question? I got a bit confused here :(

Comments 2012-Nov-30

Suzette: It can be done with a quick check, but it can get complicated Sharron: No, because it might be a challenge to explain what it is Shawn: A maybe not, but great work so we need to find somewhere for it to go

Content order [merge with keyboard access]

EOWG notes.
5min: no.
15min: maybe.

NOTE: Should this be merged with the keyboard access check?

Comments 2012-Nov-30

Shawn: see if it fits in with keyboard access before drafting

Video, Sound, (multimedia) [15: yes] [partly drafted, Sharron updating]

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

  1. Play the audio content
  2. Play the video content
  3. Toggle closed captions on (if available)
  4. Toggle audio description on (if available)

What to look for

  • Captions:
    • Verify that they synchronized to the spoken content
    • Ensure they are accurate and complete (not missing any content)?
    • Verify that they are properly formed? (correct spelling, sentence structure, punctuation)
    • Make sure that audio content other than dialogue is inlcuded (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 keyboard access for player controls)

(see also text alternatives for graphic content)

References

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.

Forms [15: maybe not] [drafted, Suzette try to pull out easy parts]

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.

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

{BROWSER TYPE - are some browsers more helpful than others when tabbing through forms and do you need to set any preferences about tabbing?- SK}

Using Browser based testing tools to examine form detail (as per Sharron’s orginal

Original from Sharron:

What to do

Evaluating the accessibility of form controls is one area in which a testing tool comes in very handy. Free web developer tools and accessibility checkers can be downloaded and installed in various browsers and having one installed will make this process much easier. SR Note: Do we recommend a tool? Link to the testing tools section of the WAI pages?

  1. Visually examine the forms
  2. Put the mouse aside and tab through form controls
  3. Turn images off in the browser and examine submit buttons and other controls
  4. Turn off CSS in the browser
  5. Enter data in form input fields
  6. Deliberately enter an error and then submit form
  7. Use browser based testing tools to examine form detail

What to look for

Each form control must have an associated label that describes its purpose. Tab order between form controls must match the order in which a user would normally complete them. Complex forms benefit from grouping controls with the FIELDSET element. The form title is optional if the purpose of the form can be determined from context. "Placeholder" text inside text boxes is no longer needed for screen readers; it is redundant in a properly-labeled form. Many forms will also have to be evaluated separately for dynamic behavior such as error response. Listed below are some things that you will look for.

When visually reviewing the form, note the following:

  • if required fields are indicated by use of color cues, ensure that additional, redundant methods are also used.
  • ensure that related form controls are logically grouped together (perhaps using fieldset and legend, see the section below with testing tools)

When tabbing through form inputs:

  • ensure that focus moves logically between the fields.
  • ensure that focus is visible on all form controls, including inputs, submit mechanisms, and check boxes and radio buttons.
  • if form control is check box or radio button, ensure that focus indication includes form label as well as the actual control
  • if form control is 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.

With images and/or background images turned off in the browser:

  • ensure that form controls remain evident and operable
  • ensure that any "required" status indicators remain evident

When entering data:

  • ensure that focus does not automatically advance to the next field, but requires user input to advance

  • if a certain response triggers presentation of new content,that content is exposed to the keyboard as well.

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.

If browser-based testing tool is in use:

  • check for form labels
  • ensure mutual association and matching of the "for" attribute of the "label" element to the "id" attribute of the "form" element
  • if feildset and legend are used, ensure they are properly formed

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:

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.

Tables [15: probably not] [Ian drafting]

EOWG notes.
5min: no, too complex.
15min: probably not, but need to see it rough ideas to determine ...

Comments 2012-Nov-30

Probably not for inclusion, Ian to write quick draft to see if it is testable

Check flickering, flashing, blinking [15: no]

EOWG notes.
5min: no.
15min: maybe not. ...

Comments 2012-Nov-30

Ian: Difficult to test if flickering is made by interacting with the page Shawn: Don't include this

WAI-ARIA [15: no]

EOWG notes.
5min: no.
15min: no.

Checking ARIA interactively is not part of a preliminary or ongoing test. It should be left for an formal audit.

There is lexical testing available through plugins in some browsers. These programs show elements using ARIA parameters and delineate the values. For a preliminary or interim accessibility test, this is enough. Without a plugin one can search code for ARIA parameters manually, but this is tedious and can miss problems.

SC. 4.1.2 (Name, Role, Value) applies here. It is Level A. ARIA testing is required whenever AJAX or other rich internet applications are used.

Note: not a requirement for accessibility and WAI-ARIA is not finalized yet, so probably won't include WAI-ARIA in the 15 minute check.

Comments 2012-Nov-30

Not for inclusion

Time-dependent responses [15: no]

EOWG notes.
5min: no.
15min: no. too hard to check and not vital to many users. ...

Comments 2012-Nov-30

Not for inclusion

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

Validate HTML & CSS [15: no]

EOWG notes.
5min: no
15min: WCAG requirement issue too complex. ...

Note: Validation not WCAG requirement...

  • ...
  • Check that the document language is declared

Comments 2012-Nov-30

Not for inclusion

Check usable without CSS, javascript [15: no]

EOWG notes.
5min: no.
15min: not as a separate item. maybe integrated as a technique to check other points.

NOTE: Shadi notes this is not a WCAG requirement

The ability to remove the author's style is not a WCAG requirement, but it is a good tool to help diagnose many accessibility errors. When the page without style can enlarge text-only with grace, and the page with style cannot then the page structure probably inhibits conformance with SC 1.4.4 (Resize text). When items like button disappear without author style, then there may be a text alternative issue (SC 1.1.1). Often, generated content from CSS includes pictures to indicate the position active regions. These images have no alternative text. One can detect when the page logical order does not match visual reading order by turning off author style. This is a test for SC 1.3.1 (Information and relationships) and and SC 2.4.3 (Focus Order). In general a page that does not make sense without style violates some success criterion.

There are some false issues. Often meaningless or context sensitive content is given a display value of "none". All of this data shows up without author style, and can make the page appear to be filed confusing garbage. This type of data is usually so clearly inappropriate that one can safely ignore it.

Comments 2012-Nov-30

Not for inclusion as a specific check. Might include as a techniques for other checks.

Use an evaluation tool [15: no]

EOWG notes.
5min: no.
15min: not as a separate item. use of tools will be integrated in specific checks. generally running a tool gives too complicated results for a quick check.

  • Use one-page auto checker

EOWG discussion:

  • There are a number of simple tools where you just put in the URL of the page of interest and the results are returned automatically eg WAVE and TAW. The results aren't necessarily so easy to interpret if you are a newbie to accessibility. Perhaps we should put this after the top 5 easy checks - and add a paragraph to confirm the benefits and limitations, or discuss some of the common types of problem found {Suzette}



Retrieved from "https://www.w3.org/WAI/EO/wiki/index.php?title=Archived_Work_on_PreLimEval&oldid=3181"