• Skip to content
• | Change text size or colors

WAI: Strategies, guidelines, resources to make the Web accessible to people with disabilities

Site Navigation

W3C Home

Web Accessibility Initiative (WAI) Home

1. Introducing Accessibility
2. Guidelines & Techniques
3. Managing Accessibility
4. Evaluating Accessibility
   1. Evaluating Overview
   2. Preliminary Reviews
   3. Conformance Evaluations
   4. ?Including Users
   5. [Special Considerations]
   6. Selecting Tools
   7. Existing Tools
   8. Review Teams
   9. Reporting Template
5. WAI Groups
6. About WAI

[EARLY ROUGH DRAFT] WAI-ARIA FAQ's

Note: This document is a draft and should not be referenced or quoted under any circumstances.

1. Where should I start to learn more about WAI-ARIA?
2. What is WAI-ARIA intended to do?
3. Is WAI-ARIA available and supported now?
4. What happens in current and older browsers if WAI-ARIA is implemented?
5. What types of widgets does WAI ARIA apply to?
6. What does WAI-ARIA offer to improve the accessibility of widgets?
7. How can web developers implement WAI-ARIA?
8. How complex is the development process using WAI-ARIA?
9. Does WAI-ARIA significantly increase the expense of development and the amount of widget code?
10. Are there JavaScript toolkits that provide built-in WAI-ARIA support?
11. Where can I learn more about WAI-ARIA?
12. Where can I ask more questions about WAI-ARIA?

1. Where should I start to learn more about WAI-ARIA?

The best place to start learning about ARIA and to get the latest information about it is the Accessible Rich Internet Applications Suite (WAI-ARIA) Overview. The Overview provides a guide to the entire suite of ARIA documents with suggestions for how to approach them, depending on the focus of your interest in the topic.

Back to Top

2. What is WAI-ARIA intended to do?

The ARIA initiative seeks to make accessibility possible for web devices - often referred to as "widgets" - that are developed with Ajax, DHTML, and other current technologies. Several basic Javascript widgets are well-known, commonly used, and yet conspicuously missing from HTML 4 today. To ensure that accessibility not be a barrier to innovation, the ARIA intiative is working to incorporate accessibility into these newer presentation techniques.

Back to Top

3. Is WAI-ARIA available and supported now?

Yes. A number of ARIA techniques have already been released, have been implemented in open source JavaScript toolkits, and are increasingly supported by browsers and assistive technologies. ARIA is being developed under the W3C Process, more thoroughly discussed elsewhere. The process is ongoing and is intended to address the diverse needs of a broad community, including industry, disability organizations, accessibility researchers, government, and others interested in Web accessibility. As a result, ARIA is already widely supported and support for it is growing. The public is invited to comment on ARIa work and to participate in the implementation and dissemination of ARIA techniques.

[Another question here? - do we want to include a modified list of specific supporters? will PF provide]

Back to Top

4. What happens in current and older browsers when WAI-ARIA is implemented?

ARIA techniques have no impact on browser function other than how the page interacts with assistive technologies -- it does not affect how mainstream users interact with the page. It also does not affect how the page works on legacy browsers at all. It only improves accessibility for previously inaccessible widgets and web pages. Browsers that support ARIA techniques allow access to widget function for assistive technologies. On browsers that do not yet support ARIA, the widgets will simply continue to work as they currently do in those browsers. In such circumstances, the widgets will function for sighted mouse users, etc., but will not be accessible on those browsers. People using assistive technology will therefore use the browsers that support their needed tools. So there is basically no effect except the positive one for users with disabilities using modern software. There is no need to wait for full browser support therefore and ARIA can be used now.

Back to Top

5. What types of widgets does WAI ARIA apply to?

In graphical user interfaces (GUIs), a widget is an element that allows input or manipulation by the user. Common widgets include buttons, dropdown lists, and expandable menus, among others. On the web, interaction with a widget can change the content and visual presentation of a page. Web widgets are often achieved using portable pieces of executable code from DHTML or Javascript.

Back to Top

6. What does WAI-ARIA offer to improve the accessibility of widgets?

ARIA provides authors with the following:

• roles to describe the type of widget presented, such as "menu", "treeitem", "slider" or "progressmeter" -- elements which do not exist in current HTML 4.01.
• roles to describe the structure of a web page
• properties to describe the state widgets are in. Examples include valuenow="50%", required="true", expanded="true" etc.
• properties to define live regions of a page that are likely to get updates (such as stock quotes), as well as an interruption policy for those updates.
• properties describing drag sources and drop targets
• a way to provide keyboard navigation for JavaScript widgets in HTML.

Back to Top

7. How can web developers implement WAI-ARIA?

Developers can implement techniques described in the ARIA documents or they can use existing toolkits that incorporate ARIA techniques. In either case, developers will find that ARIA provides useful mechanisms for describing the activities of JavaScript widgets that will help them meet current development requirements. The approach will vary according to the skills and interests of the development situation. Scenarios might include

1. A web developer or team has developed one or more JavaScript widgets, and accessibility is a project requirement. The team will use the ARIA properties to provide basic type, state and change information for their JavaScript widgets and will use available documentation and examples on the web. They will test the results using screen readers, other assistive technologies, and free testing tools. If the team needs help, its members can sign up for the wai-xtech mailing list and ask questions there.
2. A web developer is looking for specific widgets functions within existing JavaScript toolkits, and needs his or her web application to be accessible. If the toolkit has ARIA support built in, the author will choose it and simply use the accessible JavaScript toolkit without the need to understand ARIA techniques.

Back to Top

8. How complex is the development process using WAI-ARIA ?

Developing cross-browser, custom JavaScript widgets is already a complex undertaking, not a task for the beginning web developer. Including ARIA support adds another layer of complexity, but is itself no more difficult than the basic task of successful widget programming. A useful comparison in terms of time, effort, and skill might be the creation of customized style sheets.

However, even without ARIA, most web authors choose not to code from scratch, but to use JavaScript toolkits with powerful pre-built applications. As ARIA support is included in these toolkits, it will further simplify the task, allowing authors to re-use existing widgets without having to program ARIA support themselves.

As ARIA becomes more well known and supported, authors will expect built-in ARIA features just as they currently benefit from the debugged cross-browser support in existing JavaScript toolkits. Additional support is available and is in development to mediate the complexity of implementing ARIA. Among these are testing tools, open source examples, and "best practices" documents.

Back to Top

9. Does WAI-ARIA significantly increase the expense of development and the amount of widget code?

No, in fact ARIA enabled widgets can be significantly easier and less costly to implement in a browser than other widgets. Here's why: ARIA techniques line up quite nicely with how most accessibility interfaces already work. ARIA simply adds a description of the role and properties - descriptions that provide information to assistive technologies. Also, ARIA requires only that code be added to the module that implements accessibility, not to the core browser. It is the accessibility module that then passes information about role, state, and changes in state through already supported interfaces.

Back to Top

10. Are there JavaScript toolkits that provide built-in WAI-ARIA support?

There are some, and the number is growing. Several JavaScript toolkits, such as Dojo, GWT, YUI and Scriptaculous, are quickly evolving powerful sets of widgets. Accessibility requirements will continue to influence which toolkit web authors will choose. JavaScript toolkits that integrate ARIA techniques will make the technology increasingly practical for individual authors. By using these popular toolkits, developers will be able to benefit from keyboard and assistive technology support that is already built-in. And this is happening: for example, the Dojo toolkit already has significant ARIA support.

Back to Top

11. Where can I learn more about WAI-ARIA?

Discuss what to include...a map of WAI-ARIA documents?

Back to Top

12. Where can I ask more questions about WAI-ARIA?

The WAI-XTech list is where anyone interested in ARIA may discuss technical issues.

To subscribe to the WAI-XTech list, please follow the instructions in Participation in the Protocols and Formats Working Group.

Back to Top

Document Information

Version: EARLY ROUGH DRAFT 2007/11/29
Editor: Sharron Rush with The Education and Outreach Working Group (EOWG) of the WAI and The Protocols and Formats Working Group (PFWG)of the W3C

[Contacting WAI] Feedback welcome to wai-eo-editors@w3.org (a publicly archived list).