Prelim Eval input: Smart analysis simplified

Smart analysis simplified (Basic web view)

(Contributed by Tom Jewett, Wayne Dick and the California State University Web Community of Practice)

This human-intelligence-based method can quickly determine if the most important elements of a web page can be used by most persons with disabilities. This checklist is no substitute for training, but once trained designers and developers can use this as they move from task to task. Used throughout the design and development process, this quick check will help to avoid accessibility errors that require major changes to the website's design or implementation.
{@@Note to EO: Techniques for testing these items are needed. Please think about structure and how to change the structure to include the testing protocols}

1. Validation check: HTML and CSS code should comply with W3C standards.
   
   • Always check with W3C HTML and CSS Validators
     
   • Check that the document language is declared
   
   
2. Visual check: Do each of the following common sense tests.
   
• All text should be easily legible to fully-sighted readers.
  
• When text-only enlargement is used in the browser, all text (except banner logos) should respond and nothing should overlap or be hidden.
  
• Make sure nothing is flickering or flashing unless this activity is necessary for the meaning of the content.
• Make sure the Title of the page (in the browser title bar) is descriptive of the content.
  
• Check to see that there is a clear luminosity difference between the background and text in the foreground. Be sure to test special states like hover for contrast problems. An easy way to test contrast is to reduce the luminosity of the monitor by about 40%. Foreground and background should still be distinct.
  
3. Dynamic Content: This category includes time based media, animations, and content management system content, and rich internet applications. You will only identify the most obvious barriers; most dynamic content will require specialized, detailed analysis to insure complete accessibility.
   
   • Visually, confirm access to captions and transcripts (when appropriate) for all time based media;
     
   • Do all testing with keyboard only.
   • Identify any time dependent responses.
   • Give all animation a quick Visual Check. Embedded text should be readable, enlargement capability should be present and effective, flashing and blinking should be confined to necessary semantic role, and test all states.
     
   • Treat CMS generated data just like normal web content, but try to separate template issues from local instance issues.
     
   • Check for WAI ARIA role, state and property presence in all ARIA widgets.
   • Check for WAI ARIA landmarks in all widgets.
   • Test every rich internet application with keyboard only.
4. Parallel Content: Frequently a page will require an alternative page to support accessibility. This is OK when required but check:
   
   • Is there an automatic mechanism to update both versions simultaneously? There should be.
     
   • Is the alternative as rich semantically. For example replacing structured HTML with plain text is not acceptable.
     
5. Color: Make sure that information is not conveyed by color alone. Verify that color contrast does not substitute for luminosity contrast.
   
6. Headings: Headings should match the actual semantic structure of the document and should be properly nested by level. Headings should also be used to identify and navigate between groups of related links. Proper use of headings is now more accessible than adding "skip navigation" links. For ARIA widgets, use landmarks as you would use headings for text based content.
   
7. Image maps: HTML still has a MAP element, but today image maps are also implemented with CSS, sprites, and live regions. All maps and map equivalents still need to provide alternative text equivalents and full keyboard access. All image map objects contain graphical regions with hot spots that contain links or controls. The same issues arise with all image map objects. So always check:
   
   •  Active graphical hot spots of an image map must have associated text alternatives to activate controls and links.
   • Keyboard traversal should be possible through the controls and links present in the map. This includes visual access for sighted users who want to tab through an image map visually.
     
8. Links: All links must have text; each link's text should describe its destination clearly; duplicate link text should not point to different destinations, but links that point to the same destination may have different text depending on context. If any link has "javascript" as the target, it is likely to be an accessibility barrier that will require additional evaluation. All links should be reachable and visible using only the Tab key.
9. Forms: 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.
10. Frames: Frames are deprecated and should never be used in new development. If your software maintenance cycle includes upgrading code that includes frames, it is time to remove them.
11. Iframes: This tool is necessary for multi server access. Content introduced through iframes should be tested like any content.
    
12. Images: With images replaced by their text equivalents, no information or navigation should be lost to any visitor to the page. Purely decorative images should have null (empty) text equivalents. All images should have text alternatives, content or explicit null.
13. Styles and layout: View the page with all style off. The semantic structure of the page content should be readily understandable from the browser's default rendering (of headings, lists, and so on) and navigable by assistive technologies. No content should appear that was made visible by CSS solely with mouse action (hover) or otherwise hidden from sighted readers. With layout tables removed, the page should read in logical order from top to bottom; use of layout tables should be kept to an absolute minimum.
14. Data Tables: Layout tables (those with no heading elements) should never be used to contain truly tabular data, and should never have summary attributes. True data tables should have each data cell associated with its column (and row, if appropriate) header or headers. Complex tables should have each data cell associated with all applicable heading levels.