WAI-ARIA
-
Defines a way to make Web content and Web applications more accessible for people with disabilities.
- Created with the idea to make accessible dynamic content and advanced user interface controls.
- Works well in the world of Ajax, HTML5 and JavaScript.
- Tries to help even with advanced user interactions as Drag&Drop, or updating regions of a page on the fly.
WAI-ARIA
The idea
The Web Authors should describe the page structure, the widgets used on the page, and the dynamic content flow using simple attributes.
Then, the screen reader will provide this information to the disabled users.
WAI-ARIA
Roles and properties
- Roles to describe the structure of the Web page, such as headings, regions, and tables (grids).
- Roles to describe the type of widget presented. These could be "menu", "treeitem", "slider".
- Properties to describe the state widgets are in, such as "checked" for a check box.
- Properties to define live regions of a page, those which present dynamic content updates.
- Properties for describing drag sources and drop targets.
WAI-ARIA
The Aria Plugin from AlloyUI - aui-aria
- Sets one or more ARIA roles to a widget's Role Node (by default this is the boundingBox).
- Sets one or more attributes to Attributes Node (by default this is the boundingBox).
WAI-ARIA
The challenges
- It is an additional effort - it is not easy to convince some developers and managers that it is worth.
- May add additional overhead - additional DOM interactions, additional attached events.
- Sometimes may restrict the developer, since the screen readers are limited.
- (May be) difficult to be achieved for all devices - phones, tablets, phablets, Desktop.
- The imagination of sighted user/developer might be completely different than the reality.
WAI-ARIA
Best practices
- Do not create the widget or the entire page and then try to define the Roles and properties. Instead, keep accessibility it in mind when developing and designing.
-
As sighted user, do not assume you understand the problems of the disabled users. If possible, check with real uses the current state of the application during the process of development.
- If possible, separate the different accessibility techniques when makes sense. For example, do not load code, which provides keyboard access to devices without keyboard.
- Do not accept the page is accessible if the user can read and interact with the primary content. Do "continuous accessibility" - notify properly the user when the content updates.
- Do not create the widget or the entire page and then try to define the Roles and properties. Instead, keep accessibility it in mind when developing and designing.
- As sighted user, do not assume you understand the problems of the disabled users. If possible, check with real uses the current state of the application during the process of development.
- If possible, separate the different accessibility techniques when makes sense. For example, do not load code, which provides keyboard access to devices without keyboard.
- Do not accept the page is accessible if the user can read and interact with the primary content. Do "continuous accessibility" - notify properly the user when the content updates.
WAI-ARIA
WAI-ARIA
By ipeychev
WAI-ARIA
- 962
