[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?
- Is WAI-ARIA available and supported now?
- What happens in current and older browsers if WAI-ARIA is implemented?
- What types of widgets does WAI ARIA apply to?
- What does WAI-ARIA offer to improve the accessibility of widgets?
- How do web developers use WAI-ARIA?
- How complex is the development process using 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. Is WAI-ARIA available and supported 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.
ARIA support is widespread and is growing. [Include list here - from PF]
4. What happens in current and older browsers if 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.
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.
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.
7. 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.
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 terems of time effort and skill might be the creation of customized style sheets.
However, even without ARIA most authors choose 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 reuse existing widgets without having to program the 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.
9. 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 most accessibility interfaces already work, simply adding a description of the role and properties to assistive technologies. Also, ARIA techniques do not require code to be added to the core browser -- only to the module that implements accessibility. The accessibility module simply passes roles, states and state changes along through the already supported interfaces. So no, ARIA is not expensive to implement and in fact is significantly easier and less costly to implement in a browser than other widgets.
10. 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.
11. Where can I learn more about WAI-ARIA?
Discuss
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.