Design Guideline |
Physical |
RSI |
Low Vision |
Blind |
Hearing |
Provide keyboard access to all application features |
X
|
X
|
X
|
X
|
|
Use a logical tab order (left to right, top to bottom, or as appropriate
for locale) |
X
|
|
|
X
|
|
Follow key mapping guidelines for the local environment |
X
|
X
|
X
|
X
|
|
Avoid conflicts with keyboard accessibility features |
X
|
|
|
X
|
|
Where possible, provide more than one method to perform keyboard tasks |
X
|
X
|
|
|
|
Where possible, provide both keyboard and mouse access to functions |
X
|
X
|
X
|
X
|
|
Avoid requiring long reaches on frequently performed keyboard operations
for people using one hand |
X
|
X
|
|
|
|
Avoid requiring repetitive use of chorded keypresses |
X
|
X
|
|
|
|
Avoid placing frequently used functions deep in a menu structure |
X
|
X
|
X
|
X
|
|
Do not hard code application colors |
|
|
X
|
|
|
Do not hard code graphic attributes such as line, border, and shadow
thickness |
|
|
X
|
|
|
Do not hard code font sizes and styles |
|
|
X
|
|
|
Provide descriptive names for all interface components and any object
using graphics instead of text (e.g., palette item or icon) |
|
|
|
X
|
|
Do not design interactions to depend upon the assumption that a user
will hear audio information |
|
|
|
|
X
|
Provide visual information that is redundant with audible information |
|
|
|
|
X
|
Allow users to configure frequency and volume of audible cues |
|
|
X
|
X
|
X
|