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 accessibility APIs.
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 188.8.131.52, IE7 + Adobe 3.03 SVG plugin
- 2 All browsers which treat XHTML as XML
- 3 Firefox 184.108.40.206 (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 summarised above.
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
ariaprefix and may not (i.e. in some browsers) correctly set the
namespaceURIproperty 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 mixed 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.