Syntax for ARIA: Cost-benefit analysis

Syntax for ARIA: Cost-benefit analysis

Henry S. Thompson

7 May 2008

Table of Contents

• 1. Introduction
• 2. The core issue: How should the ARIA attributes be spelled?
• 3. Possible approaches: land-grab, colon or dash
• 4. The status quo: languages and implementations
• 5. The near future
• 5.1. HTML5
• 6. Cost-benefit analysis
• 6.1. Implementation cost
• 6.2. XML extensibility and SVG
• 6.3. Short- vs. long-range considerations

1. Introduction

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.

2. The core issue: How should the ARIA attributes be spelled?

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.

3. Possible approaches: land-grab, colon or dash

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.

The current ARIA WD specifies a combination of the colon and dash approachs, with the colon being specified for use with XML-based 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.

4. The status quo: languages and implementations

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).

Passive support	HTML 4.01	XHTML (as if HTML)0	XHTML (as XML)	SVG
Allowed at all	colon: Yes, by 'should ignore' advice dash: Yes, by 'should ignore' advice	colon: Yes, by 'should ignore' advice dash: Yes, by 'should ignore' advice	colon: Yes, by 'must ignore' rule dash: Yes, by 'must ignore' rule	colon: Yes, by 'must ignore' rule dash: In principle,no in practice1, yes
Available via DOM	colon: Yes, via GetAttribute dash: Yes, via GetAttribute	colon: Yes, via GetAttribute dash: Yes, via GetAttribute	colon: Yes2, via GetAttributeNS and GetAttribute dash: Yes2, via GetAttribute	colon: Yes3, via GetAttributeNS and GetAttribute dash: Yes3, via GetAttribute
Matches CSS selector	colon: Yes4, using [aria:attr] dash: Yes5	colon: Yes4, using [aria:attr] dash: Yes5	colon: Yes, using [aria|attr] dash: Yes5	colon: No dash: No

Notes:

• 0  This column applies to the IE family, and to other browsers whenever treating XHTML as HTML
• 1  Firefox 2.0.0.14, IE7 + Adobe 3.03 SVG plugin
• 2  All browsers which treat XHTML as XML
• 3  Firefox 2.0.0.14 (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.

5. The near future

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 [aaa:checked], which would remove the qualification recorded in the table above by footnote 4.

5.1. HTML5

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.

6. Cost-benefit analysis

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 a 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 pair of getter/setter Javascript functions for access to ARIA information in the DOM, and giving a design pattern for duplicated CSS selectors (one using [aria:xxx] and the other [aria|xxx]).

	Benefits	Costs
colon	Consistency for page authors; Uniform DOM access (using Get/SetAttribute); Orthogonal in XML languages; consistent with namespace-based extensibility for XML (and for HTML5?1)	Uniform DOM access ignores namespace2; no uniform CSS selector; no CSS selector at all for IE legacy3; modest re-implementation cost4
dash	Consistency for page authors; uniform DOM access; uniform CSS selector	Inconsistent with XML namespace-based extensibility5; new paradigm for 'namespace'6; scope creep7
mixed	Orthogonal in XML languages; consistent with namespace-based extensibility for XML (and for HTML5?1)	Confusing for authors; no uniform DOM access; no uniform CSS selector; uncertainty wrt XHTML; new paradigm for 'namespace'6; scope creep7
xcolon	Consistency for page authors; orthogonal for XML languages; consistent with namespace-based extensibility for XML (and for HTML5?1); uniform DOM access; uniform CSS selector	Requires indirection through accessor functions for DOM access; requires duplicate CSS selectors; no uniform DOM representation; no CSS selector at all for IE legacy3; modest re-implementation cost4

• 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 aria prefix and may not (i.e. in some browsers) correctly set the namespaceURI property even when targetting an XML DOM.
• 3  That is, in the IE family, only (putatively) IE8 and successors will recognize [aria:...] selectors
• 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.

6.2. XML extensibility and SVG

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.

6.3. Short- vs. long-range considerations

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.