Quick Check for Developers

Tom and I did this when we worked on the CSU Accessible Technology
Initiative at California State University System (San Diego, San
Marcos, Fullerton, San Bernadine, Pomona, Long Beach, Domingus Hills,
Los Angeles, Northridge, Bakersfield, Chanel Islands, Fresno, San
Louis Obispo, Monterrey Bay, Maritime AcademySacramento, East Bay, San
Francisco, Stanislaus, Sonoma, Chico, and Humboldt)

I cut out all the specific software we used for testing.  I also tried
to update whenever possible.  This was geared to Section 508 extension
of the 1973 Rehabilitation Act.  I did not have time to tie each step
to WCAG 2.0.  But I'll do that later.

Wayne

Smart analysis simplified (Basic web view)

This human-intelligence-based method can quickly determine if the most
important elements of a web page can be used by most persons with
visual, cognitive, and other disabilities. We can train your
developers and vendors to use this and other methods, in much more
detail than it's possible to present here.

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

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

Dynamic Content: This include 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 as in (2). 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.

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?
Is the alternative as rich semantically.  For example replacing
structured HTML with plain text is not acceptable.

Color: Make sure that information is not conveyed by color alone.
Verify that color contrast does not substitute for luminosity
contrast.

Headings: (quick check) 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.

Image maps: This should be obsolete, but it is not.  With CSS,
sprites, live regions, and the canvas, image maps equivalents exist
only in different form.  There are still graphical regions with hot
spots filled with links or controls.  The same issues arise as with
old HTML image maps. So always check:   Each active area of an image
map must have associated text for controls and links. Keyboard
traversal should be possible through the controls and links present in
the map.

Links: (quick check) 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.

Forms: (quick check) 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.

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.

Iframes: This tool is nessary for multi-server access.  Content
introduced through iframes should be tested like any content.

Images: (quick check) 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.

Styles and layout: (quick check) With 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.

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.

Received on Wednesday, 24 October 2012 21:40:08 UTC