W3C home > Mailing lists > Public > public-html@w3.org > July 2007

Opening thoughts on WAI-ARIA in HTML5

From: Al Gilman <Alfred.S.Gilman@IEEE.org>
Date: Wed, 18 Jul 2007 16:45:59 -0400
Message-Id: <p06110440c2c42a69449d@[]>
To: public-html@w3.org


This is high level, but we thought we should say _something_.
We continue to work on some more concrete ideas.

None of this is cast in concrete.  But this gives you an idea
where we are coming from.

/chair, PFWG


                We look forward to working with the HTML working group
on ensuring accessibility support for rich internet applications in

We are finding that developers, are creating countless custom
controls in their Web 2.0 applications which require the use of ARIA.
ARIA is starting to be incorporated in Web 2.0 applications and
widget libraries. Early adopters like IBM, AOL, and SAP are
developing ARIA supporting widget libraries like Dojo. ARIA provides
needed semantics to enable a user agent to support platform
accessibility APIs, allowing for full interoperability with assistive
technologies. Furthermore, ARIA addresses keyboard gaps in HTML
needed to make these applications accessible. For these reasons it is
essential that HTML 5 provide for backward compatability. Vehicles
for supporting ARIA states and properties, such as namespaces or a
data dictionary linked through the html:html.profile attribute are on
the table for discussion.

The working group likes the idea of having built in semantics in HTML
and in particular would prefer to have common document elements, such
as widgets built in to the markup. This reduces download size and the
effort required to make a web page accessible. For these reasons, we
would promote the use of such markup over the ARIA approach. That
said, we do believe that HTML 5 will not incorporate document
elements for all those included in the ARIA role taxonomy nor will it
include all the states and properties. For these reasons, backward
compatability for the ARIA specifications is a must.

Outside of ARIA we would like HTML 5 to support the XHTML access
element. The access element supports badly needed semantics for
access key navigation but without the need for device dependency
restrictions. Additionally, if accessibility features are being
removed from HTML 4.01, such as longdesc or alt text, we need to make
sure that the base markup supports the appropriate equivalent
functionality in terms of interoperability with assistive
technologies. For example, ARIA provides a describedby property which
establishes a relationship to descriptive text on the page (prose or
text shown in response to a user action) which may be an appropriate

To summarize, our goals for HTML 5 are as follow:

+ Support for issues highlighted in Table: 1 of the ARIA Roadmap
+ Backward compatability to ARIA, including the role attribute.
+ Allow for full interoperability with assistive technologies
+ A preference for access to accessibility information via the DOM
+ Reduced efforts by authors to support assistive technologies
+ Support for the access element or a version of it.
+ Maintain equivalent or improved accessibility features of HTML 4.01
Received on Wednesday, 18 July 2007 20:46:11 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:17 UTC