| Definition |
Widget roles must be removed until the ARIA properties, states, focus management and keyboard support for widgets is fully understood by the developer. |
| Purpose |
- Developers who are new to ARIA and do not completely understand how ARIA technologies can enhancing accessibility may.
- The improper use of ARIA roles leads to less accessibility due to conflicting accessibility information being represented in the accessibility APIs.
- The intention of the rule to discourage web developers form using widget roles until they fully understand how to use ARIA roles, properties, states, focus management and keyboard support.
- Once a developer is confident they understand how to implement ARIA enabled widgets that should use the WCAG + ARIA ruleset to evaluate the accessibility of their pages.
|
| Mappings |
none
|
| WCAG 2.0 Success Criteria |
4.1.2 Name, Role, Value (Level A, Primary Success Criterion)
Other Related Success Criterion:
|
| Rule Category |
Widgets/Scripting |
| Scope |
Element |
| Target Resources |
Elements widget roles
|
| Techniques |
- Remove widget roles from elements, until the developer fully understands who to create accessibility widgets with ARIA roles, properties, states, focus management and keyboard support.
- Widget from javascript libraries that claim to support ARIA should be tested for correct use of ARIA roles, properties, states, focus management and keyboard support, since many javascript libraries using ARIA may be using it incorrectly, or updated to previously accessible libraries may have broken accessibility features.
|
| Informational Links |
|