Native semantics vs baking ARIA

The question has come up about whether ARIA is a bridging technology to be used only until host languages build native features, vs just baking ARIA in as the preferred accessibility solution. This is a review of the pros and cons of each approach.

	Native Semantics	Baking ARIA
Pro	Host language is complete with respect to accessibility Accessibility approaches are self-consistent within the language	Accessibility specialists have more direct control over features User agent / AT mapping of ARIA features portable across host languages Potential to address new accessibility issues faster than host language maintenance timeframe Accessibility user interface semantics are in a different layer from host language semantics
Con	Requires much more direct work between language developers and accessibility specialists Different specifications for similar use cases more difficult for UAs	Ghettoizes accessibility solutions into "that ARIA stuff" with aria-* attributes Accessibility solutions developed separately from the main work Assumption among language developers that they don't need to address accessibility, just count on ARIA Requires extensibility mechanism from host language, or a baking in approach in the spec Accessibility gets limited to the features of ARIA and new opportunities in new technologies can be overlooked / delayed

Proposal: Encourage native semantics and focus on ARIA as gap-fill

[Submitted by Michael Cooper]

Accessibility is best supported by designing it into a content language from the beginning. Each content language is designed to meet particular use cases. New content languages are generally intended to meet new use cases, which are likely to have new types of accessibility considerations. Accessibility solutions of the past may not be applicable to the new use cases. Relying on existing accessibility solutions provides inferior effectiveness to designing appropriate solutions from the beginning.

One problem with this approach that has emerged is that new uses of technologies evolve in the wild. Some technologies are specifically intended to support this, but even ones that aren't can be put to surprising uses. These uses create severe accessibility problems because they were not accounted for in the original design of the technology, because they often represent new types of content for which generally accepted accessibility solutions do not yet exist, and because the defined semantics of the technology are altered to accommodate the new use.

The existence of this problem has led to the creation of WAI-ARIA. ARIA allows the application of accessibility semantics to markup languages. These semantics instruct user agents how to represent content in accessibility APIs, regardless of the (misused) defined semantics of the content. This provides an "accessibility correction" layer that represents common accessibility solutions.

ARIA was originally created in order to provide a faster accessibility solution than was possible by completely redesigning the markup language to accommodate the new use cases, and one that adapted to the "altered semantics" approach to creating new content types. It was originally applicable to HTML 4, though originally designed for XHTML 1.1 in an attempt to keep the ARIA layer completely separate from the host language. Due to lack of user agent support for XHTML 1.1, and later due to lack of support from the HTML 5 Working Group for a distributed extensibility mechanism, ARIA was redesigned as a set of attributes that could be added to a host language by spec or by fiat (user agents recognize the ARIA attributes regardless of whether they are valid in the host language).

This change in the model of ARIA started a trend towards viewing ARIA as a general-purpose accessibility solution for markup languages. This has had a number of effects:

The development of ARIA was slowed down by the need to coordinate with host languages;
The ability of ARIA to respond quickly to new accessibility challenges was compromised;
Host language developers offset the full responsibility of accessibility onto ARIA and failed to design the host language in an optimal manner;
Using ARIA as a map to existing accessibility APIs has increased reliance on those APIs even when they are seen as not fully evolved or the best accessibility approach for all cases.

Defining ARIA as the preferred approach for accessibility would have the effect of continuing and strengthening those trends. The advantage would be increasing support for existing accessibility solutions, at the cost of optimal support for future problems.

Instead, ARIA should continue to be viewed as a stop-gap accessibility measure. It should be returned to a rapid turnaround model that can respond quickly to new accessibility problems. Primary accessibility efforts should be focused on building accessibility natively into host languages. Accessibility requirements would be based on a common knowledge base, expanded as new use cases emerge, to which ARIA defines a mapping. However, ARIA would necessarily define approaches for known accessibility problems and solutions, and therefore could not be at the very forefront of state of the art. Each new or updated host language should reflect the state of the art at time of publication. ARIA would provide bridging access for technologies not under active maintenance.

Proposal: Define ARIA as the accessibility layer for markup languages going forward

[Submitted by Janina Sajka]

ARIA provides a widely accepted approach for supporting the alternative access requirements to common user interface elements for web users who utilize assistive technologies. To the extent these UI elements are adopted by any W3C specification, accessibility benefits from adopting ARIA for those UI elements. In this way more developer time can be made available for working on accessibility to those aspects of emerging W3C specifications which are unique.