Syntax for ARIA: Cost-benefit analysis
Table of Contents
6.1. Implementation cost
This analysis is intended to be neutral with respect to ideology,
history and constituency. For a useful overview of how we got here, see WAI-ARIA Implementation Concerns (member-only link) by Michael Cooper.
The W3C’s WAI PF Working Group recently published the first
public working draft of the Accessible Rich Internet Applications (WAI-ARIA) specification, which “describes mappings of user interface controls and navigation to accessibility APIs”.
The ARIA spec. defines roles, states and properties to manage the interface
between rich web documents and assistive technologies. The primary expression
of roles, states and properties in markup languages is via attributes. Since
ARIA is meant to augment web applications across a range of languages and user
agents, ARIA has to specify how its vocabulary of attributes and values can be
integrated into both existing and future languages.
In preparing this analysis, I have reviewed the available concrete evidence
bearing on the matter, and have carried out a considerable amount of work to
replicate and, in some cases, correct or extend, testing which has been done in the
past. The details are available in a report entitled Some test results concerning ARIA attribute syntax.
ARIA is useful only if it is widely supported. It therefore needs to
integrate cleanly into existing and future languages as easily as possible. Before looking at possible answers to the spelling question, we need to consider
exactly what supporting ARIA means.
We can distinguish two levels of support for ARIA on the part of user
agents, which I’ll call ‘passive’ and ‘active’ support. By passive support, I
mean that documents with ARIA-conformant markup are not rejected by the agent,
and the markup is available in the same way any other markup is, e.g. via a DOM
API or for matching by CSS selectors. By ‘active’ support
I mean the user agents actually implement their part of ARIA semantics, that is, reflecting changes to ARIA-defined states and properties via
Although already deployed implementations cannot offer active support, an
optimal answer to the spelling question would maximise passive support from
existing languages, as well as encouraging active support from subsequent implementations.
There are in principle three possible approachs to the spelling question:
- land-grab Just use ‘role’ and the names of the properties (e.g.
‘checked’, ‘hidden’) as attribute names.
- colon Use ‘aria:’ as a distinguishing prefix, giving e.g. ‘aria:role’,
‘aria:checked’ as attribute names.
- dash Use ‘aria’ plus some other punctuation character, e.g.
dash, as a distinguishing prefix, giving e.g. ‘aria-role’,
‘aria-checked’ as attribute names.
The land-grab approach is pretty clearly unacceptable, because
of clashes with existing vocabularies and the likelihood
of clashes with future ones, and will not be considered further.
ARIA WD specifies a combination of the colon and
dash approachs, with the colon being specified for use
languages, with the necessary additional requirement that ‘aria’ is bound to
the ARIA namespace in the usual way, i.e.
xmlns:aria="http://www.w3.org/2005/07/aaa", and the
dash approach being specified for use with non-XML languages. We’ll
call this the mixed approach hereafter.
My understanding is that as of the date of this note, the WAI PF working
group have indicated that their intention is that the next draft of
the ARIA specs will move to the dash appropach.
Choosing an approach is made complicated by the landscape of language
and infrastructure standards it has to fit in to, and by the fact that these are
moving targets. We therefor have to distinguish between what is currently
in place, what we have reason to expect in the near future, and what we can
foresee in the longer term. Furthermore, for existing languages we have
two categories: XML-based languages, with more or less explict provision for
extensibility in general, typically namespace-based, and non-XML languages,
which for the purposes of this analysis we will take to be HTML 4.01 and nothing else.
As noted above, the best we can expect from deployed user agents is passive
support. The table below sets out the extent of passive support which is
available for the colon and dash approaches for each
of three host languages, which exemplify the major relevant categories: HTML
4.01 (for the non-XML languages), XHTML (an XML language, but not always treated
as such, so we actually get two columns for it below) and SVG (only an XML language).
- 0 This column applies to the IE family, and to other browsers
whenever treating XHTML as HTML
- 1 Firefox 184.108.40.206, IE7 + Adobe 3.03 SVG plugin
- 2 All browsers which treat XHTML as XML
- 3 Firefox 220.127.116.11 (unable to test IE+plugin so far)
- 4 Except IE family
- 5 If attribute selectors supported at all, i.e. not IE5, IE6
It should be noted that some of the entries above disagree with assertions
made in the past about browser behaviour. At least some of those assertions
were based on flawed test materials—see the discussion
of experiments 1 and 2 in my testing report for details on the information
A number of browser implementors have responded positively to the ARIA
initiative and have included experimental active support for ARIA in pre-release
versions of their products. Most of the test materials and implementation
information I can find suggests that only the dash approach, and only
HTML or XHTML, are currently being implemented.
With regard to improving passive support, it seems very possible that
IE8 will support attribute selectors of the form
which would remove the qualification recorded in the table above by footnote 4.
The situation with respect to HTML5 is complicated. As it
currently stands, the HTML5 draft
specification supports namespaces internally, and all HTML elements are
parsed into the DOM nodes in the HTML namespace, regardless of whether they are
parsed “as HTML” or “as XML”. But when parsing documents “as HTML”, no
other namespaces are recognised. Unless this changes before HTML5
is completed, the HTML/”XHTML (as if HTML)” columns above will apply to
HTML5-conformant user agents in at least some cases.
On the basis of the above survey, there follows below an attempt at a
cost-benefit analysis with respect to the colon and
dash approaches, as well as the mixed
approach as currently specced in the ARIA working draft and a fourth approach, as proposed by me in
message to www-tag, which I’ll call the xcolon approach.
The xcolon approach attempts to address some of the problems
revealed in the passive support table by defining a
DOM, and giving a design pattern for duplicated CSS selectors (one using
[aria\:xxx] and the other
- 1 HTML5′s provision for extensibility, whether compatible with
XML namespaces or not, is an open area of discussion at the moment.
- 2 That is, it requires the use of a fixed
and may not (i.e. in some browsers) correctly set the
property even when targetting an XML DOM.
- 3 That is, in the IE family, only (putatively) IE8 and successors
- 4 See discussion of re-implementation cost below
- 5 See discussion of XML extensibility below
- 6 That is, adds the concept of a fixed, dash-delimited, prefix as
a way of managing distinct symbol spaces to the existing non-fixed, colon-delimited
prefix for the same purpose.
- 7 That is, requires all embedding languages to explicitly allow
and manage an inventory of fixed prefixes and, possibly, their vocabularies.
6.1. Implementation cost
For wholly commendable reasons, development of the ARIA spec. and pilot
implementation work have proceeded in parallel. Most if not all existing
implementations support only the dash approach. What is the likely
cost for those implementations of any decision to adopt any other approach? My
conclusion, having examined one implementation in some detail, is that the cost is
likely to be very modest.
Michael Cooper, WAI PF staff contact, captured the reason for this very
well, albeit unintentionally:
“The ARIA roles and properties are conceptually simple enough, but
they are designed to provide a bridge between HTML and desktop accessibility APIs,
a bridge which is exploited by the operating system, user agent, and assistive
technology all working together. There’s a complex set of interdependencies there
and the feasibility and details of many of the ARIA features could only be worked
out by testing in deployed systems, and therefore doing early implementation.”
The complexity referred to above is fundamentally one of architecture, both
static and dynamic. Not surprisingly, therefore, syntactic concerns account for a
tiny fraction of the code needed to implement ARIA as it stands. Furthermore, and
again not surprisingly, as it’s what sound software engineering practice requires,
the details of the concrete syntax are isolated, and the vast bulk of
the code I looked at refers to it only indirectly. The consequence of all this is
that the changes necessary to manage any change away from the dash
approach will be very straightforward. For more details, see the discussion
of experiment 3 in my testing report.
Many existing XML languages make explicit, generic, provision for
extensibility by including in their formal schemas and/or spec. prose allowance for
any namespace-qualified elements and attributes from namespaces other than those
which make up the language itself. Tools such as NVDL and, to a lesser extent, W3C
XML Schema and RelaxNG, make it possible to combine the schemas for multiple XML
languages to give a complete characterisation of mixed-language documents.
One particularly important example of this approach is SVG. ARIA
integration into SVG is clean and straightforward under the colon or
approaches, but will require amending the spec. under the dash approach.
In trying to weigh the tradeoffs which must of necessity be considered when
confronted by the information given above, the matter of timescale is particular
hard to address. Any assertion about how things will look five, or even two, years
hence can always be countered with a contrary assertion. None-the-less, the
centrality of the HTML languages for the Web, and the fundamental importance of
accessibility for all of us, suggest that we must take the long-term
impact of this decision seriously, and be prepared to discount some short-term
discomfort in return for long-term stability and simplicity.