IITAA Web Application Accessibility Compliance Template
Web Technology Requirements Checklist
1Priority
Priority distinguishes a required feature from a feature that is highly desired.
- D: Desirable feature
- R: Required feature
2Response Code
The following table of codes must be used in responding to this checklist:
- A: Standard
- B: Requires minor code modification, no cost
- C: Requires minor code modification, estimated cost $$
- D: Requires major code modification, estimated cost $$
- E: Avail. In Release xx.xx expected mm/yyyy
- F: Can't be met
3Comments
Comments should be used provide more detailed description of accessibility
features for the each requirement.
Checklist
| Reference |
Priority1
|
Response Code2
|
Comments3
|
1. Coding |
| 1.1
Use valid, standard web programming code. |
R |
|
|
| 1.2
Use appropriate markup to convey document structure. |
R |
|
|
| 1.3
Provide meaningful page titles. |
R |
|
|
| 1.4
Use headings to introduce sections and sub-sections, and use them in the
correct order. |
R |
|
|
| 1.5
Use lists to identify series of related items, including navigation
menus. |
R |
|
|
2. Text |
| 2.1
Use text to display text, unless formatting that cannot be achieved with CSS is
required. |
R |
|
|
| 2.2
Use relative sizes for fonts. |
R |
|
|
| 2.3
Identify the language of text. |
R |
|
|
| 2.4
Use images instead of "ASCII art." |
R |
|
|
3. Colors |
| 3.1
Do not convey information with color alone. |
R |
|
|
| 3.2
Use contrasting foreground and background colors. |
R |
|
|
4. Images |
| 4.1
Provide "alternate text" for all images. |
R |
|
|
| 4.2
Provide full descriptions for graphs, diagrams, and other meaningful images.
|
R |
|
|
5. Image Maps |
| 5.1
Provide alternate text for each area in client-side image maps. |
R |
|
|
| 5.2
Use client-side image maps instead of server-side image maps unless areas
cannot be defined with available shapes. |
R |
|
|
6. Sounds |
| 6.1
Do not convey information with sound alone. |
R |
|
|
| 6.2
Do not automatically play audio. |
R |
|
|
| 6.3
Provide text transcripts for audio containing speech when it is provided to the
public and/or required to be viewed by employees. |
R |
|
|
7. Multiple |
| 7.1
Provide synchronized captions for all multimedia that contains essential
auditory information when it is provided to the public and/or required to be
viewed by employees. |
R |
|
|
| 7.2
Provide audio descriptions for all multimedia that contains essential visual
information when it is provided to the public and/or required to be viewed by
employees. |
R |
|
|
8. Animation |
| 8.1
Provide a means of pausing any moving, blinking, scrolling, or auto-updating
information. |
R |
|
|
| 8.2
Do not include content that flashes faster than 3 times per second. |
R |
|
|
9. Links |
| 9.1
Make sure that links are understandable out of context. |
R |
|
|
| 9.2
Provide a means of skipping past repetitive navigation links. |
R |
|
|
| 9.3
Avoid using small links. |
R |
|
|
| 9.4
Ensure that same-page links move keyboard focus as well as screen focus.
|
R |
|
|
10. Forms |
| 10.1
Provide labels or titles for all form fields. |
R |
|
|
| 10.2
Provide legends for groups of form fields. |
R |
|
|
| 10.3
Ensure that form fields are in a logical tab order. |
R |
|
|
| 10.4
Avoid placing non-focusable text between form fields. |
R |
|
|
| 10.5
Ensure that text in form fields can be enlarged. |
R |
|
|
11. Tables |
| 11.1
Identify a header cell for each column and row in simple data
tables. |
R |
|
|
| 11.2
Identify relationships in complex data tables using id and headers
attributes. |
R |
|
|
| 11.3
Provide summary attributes for data tables. |
R |
|
|
12. Frames |
| 12.1
Provide concise, unique, and understandable titles for frames. |
R |
|
|
| 12.2
Avoid using hidden, empty, or non-essential frames. |
R |
|
|
13. Scripts |
| 13.1
Ensure that scripted functions are usable with assistive
technologies. |
R |
|
|
| 13.2
Ensure that significant interactions can be performed with both keyboard and
mouse. |
R |
|
|
| 13.3
Avoid changing focus unexpectedly. |
R |
|
|
| 13.4
Avoid changing content unexpectedly. |
R |
|
|
14. Embedded Objects |
| 14.1
Use accessible embedded objects whenever possible. |
R |
|
|
| 14.2
If an inaccessible object, applet, or plug-in must be used, provide an
accessible alternative that includes the same content and functionality.
|
R |
|
|
15. Downloadable Documents |
| 15.1
Provide natively accessible downloadable documents whenever possible.
|
R |
|
|
| 15.2
If a downloadable document cannot be made natively accessible, provide an
accessible alternative that includes the same content and
functionality. |
R |
|
|
16. Timing |
| 16.1
Notify users of time limits and provide a means to extend time if
possible. |
R |
|
|
| 16.2
Do not automatically refresh the current page. |
R |
|
|
17. Page Layout |
| 17.1
When using tables for layout, ensure that reading order is logical.
|
R |
|
|
| 17.2
When using style sheets for layout, ensure that reading order is
logical. |
R |
|
|
| 17.3
Avoid horizontal scrolling. |
R |
|
|
18. Alternative Accessible Versions |
| 18.1
Use separate accssible versions only as a last resort. |
R |
|
|
Functional Testing Checklist
Testing web resources with assistive technologies and/or people with disabilities witth skills in assistive technology use are important information a vendor can provide to validate that their design is usable by people with disabilities.
4Priority
Priority distinguishes a required feature from a feature that is highly desired.
- D: Desirable feature
- R: Required feature
5Response Code
The following table of codes must be used in responding to this checklist:
- A: All features functionally accessible
- B: Most important features functionally accessible
- C: Some features functionally accessible
- D: Features are not functionally accessible
- E: Did not test
- X: Does not apply
6Assistive Technologies
List assistive technologies and their version used during testing. If none, state "none".
7Comments
Comments should be used provide more detailed description of accessibility
features for the each requirement.
Checklist
| Reference |
Priority4
|
Response Code5
|
Assistive Technologies6
|
Comments7
|
|
People with Limited Vision
Usability and/or accessibiliy testing has been conducted with individuals who operate information technology visually, but require magnification and/or color enhancement using operating system magnification and contrast styling features, AISquared Zoomtext or Freedom Scientific Magic assistive technologies.
|
D |
|
|
|
|
People who are Blind
Usability and/or accessibiliy testing has been conducted with individuals who cannot effectively see visually-displayed information, including individuals who do not have eyes, and must use alternate interface modes such as speech and/or tactile interfaces like the Freedom Scientific JAWS or GW-Micro Window-Eyescreen reader.
|
D |
|
|
|
|
People with Hearing Loss
Usability and/or accessibiliy testing has been conducted with individuals who have reduced ability to hear sounds and/or speech and require amplification or other assistive technology.
|
D |
|
|
|
|
People who are Deaf
Usability and/or accessibiliy testing has been conducted with individuals who cannot discriminate and/or process auditory sounds and speech and rely on auxiliary aids such as captioning and/or sign language.
|
D |
|
|
|
|
People with Limited Speech
Usability and/or accessibiliy testing has been conducted with individuals with mild to moderate speech impairments who can speak but may not be able to effectively operate speech recognition systems.
|
D |
|
|
|
|
People with No Speech
Usability and/or accessibiliy testing has been conducted with individuals with no ability to speak who cannot effectively operate sound recognition systems and who must use alternate forms of expressive communication.
|
D |
|
|
|
|
People with Limited Reach, Strength, or Manipulation
Usability and/or accessibiliy testing has been conducted with individuals with limited fine motor control, reach, or strength, who have difficulty operating standard input devices and must use modified input devices.
|
D |
|
|
|
|
People with No Reach or Touch
Usability and/or accessibiliy testing has been conducted with individuals with no effective use of their hands who cannot use hands/fingers to operate physical input devices and must use alternate interface modes such as head movement or speech.
|
D |
|
|
|