[DRAFT] WAI-ARIA FAQ's
Note: This
document is a draft and should not be referenced or quoted under any
circumstances.
14.1.
[need to update questions list
with new wording]
The best place to start learning
about WAI-ARIA
and to get the latest information about it is the Accessible
Rich Internet Applications Suite (WAI-ARIA) Overview. The
Overview introduces
how Web site developers can make advanced features
in provides a guide to the entire suite of WAI-ARIA
suitedocuments with
suggestions for how to approach them, depending on the focus of your interest
in the topic.
The WAI-ARIA
increases
the accessibility of initiative seeks to make accessibility possible for
wWeb
objects - often referred to as "widgets" - that are developed with current technologies.
Web widgets are often achieved using portable pieces
of executable code, in from DHTML, or JavaSscript, and such.
Several
basic Javascript widgets are well-known,
commonly used, and yet missing from HTML 4.[I don’t think widgets would ever
be considered for HTML – they are different
things. (but I’m not sure on that J) The ARIA
intiative is working to incorporate accessibility into these newer presentation
techniques in order to ensure that accessibility not be a barrier to
innovation. [this is missing the other
aspect of ARIA, as is provided in the Roles]
WAI-ARIA is being developed
under the
W3C Process, which is introduced in How WAI Develops Accessibility
Guidelines through the W3C Processmore thoroughly discussed
elsewhere. The public is invited to comment on ARIA work and to
participate in the implementation and dissemination of ARIA techniques [@@ hesitant
to use “techniques” here (and throughout) because might be
confused with the Techniques documents available with WCAG, UAAG, & ATAG].
WAI-ARIA
is already being implemented in A a number
of browsers,
assistive technologies, and open source JavaScript
toolkits
already implement ARIA techniques, and support by browsers and assistive
technologies is increasing. WAI will be collecting and publishing
a list of WAI-ARIA implementations in the
coming months; some of this information is already available on other Web sites.A list of ARIA implementations
is available - where ?-
WAI-ARIA techniques
apply to commonly
used widgets including such as buttons,
drop-down
lists, calendar functions, tree controls (for example, expandable
menus)
and others. [most of the other WAI
Resources use a comma before a conjunction; however, not all do and that’s not
a har requirement, so feel free to do whichever you
prefer.]
[this
question seems redundant with the Overview. perhaps delete here? or, related
more closely with the info in the Overview so one is clearly related to the
other?]
Barriers to understanding may
occur as page content changes and new content is not communicated to everyone.
On the web, interaction with a widget can change the actual content and visual
presentation of a page. This can happen without the knowledge of a user who
does not see the screen, thereby causing him or her to lose new content.
Barriers to page function may occur when central activities depend on one mode
of input. Currently, much widget functionality - such as the drag and drop
convenience of many web calendar and search interfaces - is probably not
available to a user who depends on a screenreader or
who navigates with a keyboard rather than a mouse. ARIA techniques address
these and other common barriers.
6. What does
WAI-ARIA offer to improve theWeb accessibility of widgets? [some below are not widget related]
To improve widget accessibility,
WAI-ARIA
provides web authors with the following:
roles
to describe the type of widget presented, such as "menu", "treeitem", "slider" and
or
"progressmeter" -- elements which do not exist in
current HTML 4.
roles
to describe the structure of the web page, such as @@
properties
to describe the state widgets are in, such as @@
.
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, that is [@@ explanation needed?]
.
properties
for
drag-an-drop that describe
ing drag sources and
drop targets
a way to provide keyboard navigation for
JavaScript widgets in HTML
. [is naming JavaScript and HTML here too
specific? should it be more broad?]
[can you
tighten up this answer? Some ideas
below on cutting out extraneous info, but I think
you can probably tighten even more. I think the answer is
almost as simple as: “Nothing”! :]
WAI-ARIA techniques have no impact on
browser function other than how the page interacts with assistive technologies --— it does not affect how other users
interact with the page.[hum… are you sure? will this always be the case? what
if a browser wants to take advantage of WAI-ARIA stuff to enhance usability for
all users, not just users of AT?] ARIA techniques
have no affect on how the page renders on legacy[is there a
reason to use “legacy” instead of “older”?] browsers. ARIA only
improves accessibility for previously inaccessible widgets and web pages. Browsers that
support ARIA techniques enable 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.
[perhaps
this answer is for browsers and AT, not Web sites? if so, need to
clarify (and probably more down since that is a smaller audience)] No,
in fact ARIA-enabled widgets can be significantly easier and less costly [really?!?] 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. [I don’t see how this makes it easier and
less costly. If make that statement, I think need to support it, since many
people will be skeptical.]
9. How
complex is the development process using WAI-ARIA ?[it doesn’t change the process, does it? just some of the code?]
Developing cross-browser, custom
JavaScript widgets is a complex undertaking and not one
for a beginning web developer. While including WAI-ARIA support
does add a layer of complexity, the task of implementing ARIA is
itself no more difficult than that of successful widget programming. A useful
comparison in terms of time, effort, and skill [they are very different skills]
might be the creation of customized style sheets. [I don’t get it. It takes the
same effort to add ARIA as it does to develop a style sheet? hum – that’s seems too variable to
me.]
Yes, 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. [W3C wouldn’t say that because of
vendor neutrality] 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.
[not really sure of your point above. could you clarify, and maybe
tighten]
1.Web developers
can implement WAI-ARIA techniques in two ways: They can implement techniques described in the
ARIA documents or they can u[suggest putting the easiest (and
probably more common) one first :]
1. Use existing toolkits that incorporate WAI-ARIA techniques. In this case, you
don’t need to understand much about WAI-ARIA since it’s already
built in. [confirm this is true (taken from deleted #2 below)]
2. Include WAI-ARIA techniques in your custom widgets and …
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 these:A web developer or team has developed one or more
JavaScript widgets, and accessibility is a project requirement. The team will
use the When developing custom widgets, add ARIA
properties to provide basic type, state and change information. for their
JavaScript widgets and will use available dDocumentation and
examples
will be available in 2008. on the web. They will You should
test the results using screen readers, other assistive technologies, and free testing
tools,
some of which are available free. If you the team needs
help, you
its members can sign up
for the wai-xtech mailing list and ask
questions there.
2.1.A web developer
is looking for a specific widget or function within existing JavaScript
toolkits, and needs the 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.
[this
still only covers part of ARIA, yes? missing the roles part again, I think]
[wonder if this one
should be moved up?] Watch for new documents in early
2008. The WAI-ARIA Best
Practices Guide is being developed to provide guidance for Web content
developers and authoring tool developers on implementing ARIA in Web sites,
applications, and tools. A Public Working Draft of the WAI-ARIA
Best Practices Guide may be available in early 2008. Some techniques for using
ARIA technologies are already available in the ARIA Techniques section of
Techniques for WCAG 2.0.
13.
Where can I learn more about WAI-ARIA? [this seems redundant with
the first question. can you just delete it?]
Several documents are currently available
and more are in being developedment.
These are outlined within the WAI-ARIA
Suite section of the ARIA Overview page.
The WAI-XTech
e-mail
list is where available for anyone
interested
in ARIA may to discuss technical
issues on
WAI-ARIA.
To subscribe to the WAI-XTech list, please follow the instructions in Participation in
the Protocols and Formats Working Group.