View source for 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)

<p>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.<br />
{@@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}</p>

<ol>
<li id="temp"><strong>Validation check:</strong> HTML and CSS code should comply with W3C standards. <br>
<ul>
<li>Always check with W3C HTML and CSS Validators <br>
</li>
<li>Check that the document language is declared</li>
</ul><br>
</li>
<li id="visual"><strong>Visual check:</strong> Do each of the following common sense tests.<br>
</li>
<ul>
<li id="visual">All text should be easily legible to fully-sighted readers. <br>
</li>
<li id="visual">When text-only enlargement is used in the
browser, all text (except banner logos) should respond and nothing
should overlap or be hidden. <br>
</li>
<li id="visual">Make sure nothing is flickering or flashing unless this activity is necessary for the meaning of the content.</li>
<li id="visual">Make sure the Title of the page (in the browser title bar) is descriptive of the content. <br>
</li>
<li id="visual">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. <br>
</li>
</ul>
<li id="dynamic"><strong>Dynamic Content:</strong> 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. <br>
<ul>
<li>Visually, confirm access to captions and transcripts (when appropriate) for all time based media; <br>
</li>
<li>Do all testing with keyboard only.</li>
<li>Identify any time dependent responses.</li>
<li>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. <br>
</li>
<li>Treat CMS generated data just like normal web content, but try to separate template issues from local instance issues. <br>
</li>
<li>Check for WAI ARIA role, state and property presence in all ARIA widgets.</li>
<li>Check for WAI ARIA landmarks in all widgets.</li>
<li>Test every rich internet application with keyboard only.</li>
</ul>
</li>
<li id="text"><strong>Parallel Content:</strong> Frequently a page will require an alternative page to support accessibility. This is OK when required but check: <br>
<ul>
<li>Is there an automatic mechanism to update both versions simultaneously? There should be.<br>
</li>
<li>Is the alternative as rich semantically. For example replacing structured HTML with plain text is not acceptable. <br>
</li>
</ul>
</li>
<li id="headings"><strong>Color:</strong> Make sure that
information is not conveyed by color alone. Verify that color contrast
does not substitute for luminosity contrast. <br>
</li>
<li id="headings"><strong>Headings:</strong> 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.<br>
</li>
<li><strong>Image maps:</strong> 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: <br>
<ul>
<li>&nbsp;Active graphical hot spots of an image map must have associated text alternatives to activate controls and links.</li>
<li>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.<br>
</li>
</ul>
</li>
<li id="links"><strong>Links:</strong> 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. </li>
<li id="forms"><strong>Forms:</strong> 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. </li>
<li id="frames"><strong>Frames:</strong> 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.</li>
<li id="frames"><strong>I</strong><strong>frames:</strong> This tool is necessary for multi server access. Content introduced through iframes should be tested like any content.<br>
</li>
<li id="images"><strong>Images:</strong> 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. </li>
<li id="styles"><strong>Styles and layout:</strong> 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. </li>
<li id="tables"><strong>Data Tables:</strong> 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. </li>
</ol>