- Low vision;
- Motor impairments; and
- Cognitive impairments.
- All non-text content has a text equivalent
- Visual information should have a text equivalent.
- Interactive content should have a descriptive label.
- All functionality is operable with the keyboard
- Use the most device-independent event available.
- Pair mouse actions with equivalent keyboard actions.
- Information and structure can be programmatically determined
- Use standard DOM functions to create scripted content.
- Do not use scripting to emulate native functionality (such as using onclick on a SPAN instead a proper link href).
- Timed activity can be controlled
- Provide user control over time-limits.
- Provide a pause functionality for animated content.
- A logical focus order is always maintained
- Insert dynamic content into the DOM directly after its trigger.
- Add multiple interactive components in a logical order.
- Elements that only trigger scripting should themselves be added by scripting.
- Use progressive enhancement to trigger popups from normal links.
- Binding functionality to existing interactive components, such as links, buttons and text fields
Assistive technologies can derive information from their attributes and text; for example, a dynamic menu would be made using links organised into nested lists, in which the menu levels are denoted by the hierarchy, and by the use of structural labels around each top-level link.
- Non-interactive functionality that presents information
- Creating custom components that are both interactive and informative
These components must be implemented using elements that are already understood by assistive technologies, so that their content and interactions can be programmatically determined; for example, a calendar widget would have a LABEL to describe it and a button to trigger it, while the calendar itself would be made using TABLE markup, which assistive technologies can understand and interpret as structured text.