[EARLY ROUGH DRAFT] WAI-ARIA FAQ's
Note: This document is a draft and should not be referenced or quoted under any circumstances.
- Where should I start to learn more about WAI-ARIA?
- What is WAI-ARIA intended to do?
- What is the "widget" that WAI-ARIA documents refer to?
- What does WAI-ARIA offer to improve the accessibility of widgets?
- How do web developers use WAI-ARIA?
- Is WAI-ARIA available now?
- How complex is the development process using WAI-ARIA?
- What is the relationship of WAI-ARIA to current browsers?
- Who supports WAI-ARIA?
- Does WAI-ARIA significantly increase the expense of development and the amount of widget code?
- Is there a JavaScript toolkit which provides built-in WAI-ARIA support?
- Where can I learn more about WAI-ARIA?
- 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.
2. What is WAI-ARIA intended to do?
Accessibility should not hold web authors back from innovating. Several basic Javascript widgets are well-known and commonly used and yet conspicuously missing from HTML 4 today. Accessibility need not lag behind such innovations. The problem is not that JavaScript is bad for accessibility, as some have claimed, but that there is no mechanism to describe what the script is visually portraying to a user. The ARIA initiative seeks to make accessibility possible for such JavaScript widgets.
3. What is the "widget" that WAI-ARIA documents refer 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, expandable menus and sliders, 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, Flash, or Javascript programming languages.
4. 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.
5. How do web developers use WAI-ARIA?
JavaScript is how industry is developing compelling Web 2.0 applications today, and these applications often need to be made accessible. ARIA provides a mechanism for describing the JavaScript widgets and could be useful in many current development situations. A couple of examples are:
- A web developer or team has developed one or more JavaScript widgets, and accessibility is part of the project requirements. The team can use the ARIA properties to provide the basic type, state and changes of their JavaScript widgets. They use available documentation and examples on the web and test the results for screen readers and other assistive technologies using free testing tools. If the team needs help, they sign up for the wai-xtech mailing list and ask questions there.
- A web developer uses widgets from an existing JavaScript toolkit, and needs his or her web application to be accessible. If the toolkit already has ARIA support built in, the author can simply use the accessible JavaScript toolkit without understanding ARIA.
6. Is WAI-ARIA available now?
ARIA is being developed under the W3C Process, more thoroughly discussed elsewhere. The process is ongoing and is intended to reflect the diverse needs of a broad community, including industry, disability organizations, accessibility researchers, government, and others interested in Web accessibility.<.p>
In the meantime, however many ARIA techniques have been released, have been implemented in a number of JavaScript toolkits, and are increasingly supported by Firefox and other browsers and assistive technologies. Additionally, the public is invited to comment on ARIa work and to participate in the implementation and dissemination of these techniques.
7. How complex is the development process using WAI-ARIA ?
ARIA is no more complex than developing cross-browser, custom JavaScript widgets. That is not a small undertaking, and not a task for the average web developer. Yes, ARIA support adds another layer of complexity. However, even without ARIA many authors will be running JavaScript toolkits with powerful pre-built widgets. ARIA support should be - and is - being added to these toolkits, which authors can then reuse.
While it is not extremely likely for an individual author to use ARIA directly, it is reasonable to expect that an array of organizations require web applications to be accessible. Individual web authors can benefit from ARIA integration in any open source JavaScript toolkits that these organizations build, just as they already benefit from the debugged cross-browser support in these toolkits.
In addition, testing tools are being developed as are examples and "best practices" documents, to guide web authors who want to use ARIA.
8. What is the relationship of WAI-ARIA to current browsers?
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 - including Firefox and Opera - 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.
9. Which browsers and assistive technologies support WAI-ARIA?
ARIA support is widespread and growing. [Discuss what detail to add]
10. Does WAI-ARIA significantly increase the expense of development and the amount of widget code?
br>No, and here's why. First, ARIA techniques line up nicely with how accessibility APIs work. It's mostly a matter of adding a table of role and properties to API support. Second, unlike natural widgets, it does not require code to be added to the core browser -- only to the module that implements accessibility proxy objects. The accessibility module simply passes the roles, states and state changes on through the APIs they already support, and this can be done on the base accessibility object class. The entire Firefox implementation of ARIA was essentially coded by one person, in addition to much other accessibility work. Documentation on mapping ARIA to desktop accessibility APIs is provided to assist other developers of other browsers. So no, ARIA is not expensive to implement. In fact it is significantly easier and less costly to implement in a browser than other widgets.
11. Is there a JavaScript toolkit which provides built-in WAI-ARIA support?
Authors want both cross-browser compatibility and accessibility via easy-to-use, pre-built widgets. They may not care whether the underlying technology is HTML 5 or via JavaScript. But authors do care that it's fast and is compatible with the majority of web browsers in use at that moment.
A number of JavaScript toolkits, such as Dojo, GWT, YUI and Scriptaculous, are quickly evolving powerful sets of widgets. Most of the leaders seem to be both free (cost) as well as free (source code license).
JavaScript toolkits integrating ARIA will make the technology practical for individual authors. By using popular toolkits, developers will be able to get any keyboard and assistive technology support already built-in. This is already happening: for example, the Dojo toolkit already has significant amounts of ARIA support.
12. Where can I learn more about WAI-ARIA?
Discuss
13. 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.