Draft: Introduction, Scope, Criteria for Inclusion, Criteria for Exclusion Objection (Privacy section TBA)

[JC: If you all like the direction of this text (based on the existing introduction), I'll work it into the main spec.]

Abstract

The Web Platform has a long history of features that developers can use to make their web content accessible to users with disabilities, from the alt attribute on images to the entirety of [WAI-ARIA]. Accessibility is used by a variety of assistive technologies, including screen readers and magnifiers for visually impaired users, and switch access software and speech-controlled software for motor-impaired users. Accessibility is also often used for automation, testing, and more.

However, the timelines of accessibility standardization and implementation often lag behind those of mainstream features of the Web Platform, sometimes by a number of years. Despite recommendations for best practices, accessibility-conscious web developers often find themselves retrofitting dubiously created sites that would require a full rewrite to make accessible. Increasingly, web developers taking full advantage of new web platform features, or those retrofitting the work of others, are finding it difficult or impossible to make their web apps accessible.

In particular, one of the biggest challenges happens when a web app uses custom event handling and scripting, not declarative markup, for a significant portion of its user interface — for example, building a portion of the interface using the HTML <canvas> element (both [2DCONTEXT] and [WEBGL]). Authors are often forced to create fake, invisible DOM elements that represent the accessible equivalent of onscreen UI. These hacks are cumbersome, limited, and ultimately bad for the platform. Authors also face challenges when crossing document boundaries (e.g. [SHADOW-DOM]), because it isn't possible to use IDREF relationships like aria-activedescendant or aria-labelledby when the target element is outside the current document.

The intention of this specification is to allow authors to make a web apps accessible using scripting, rather than requiring the only option being accessibility features of HTML markup. In the simplest use case, the author is able to programmatically modify the accessible representation of an existing DOM element. In a more complicated use case, the author is able to create new virtual accessible objects on the page that don't correspond to an HTML element at all, such as controls in a Canvas-based app.

Document Scope

The Accessibility Object Model spec is narrowly focused on the goal of creating a scripting API for web accessibility. It's intended to complement existing web accessibility APIs such as [WAI-ARIA], not replace them. In particular, this spec attempts to avoid proposing new roles, states, and properties an of accessible objects except where necessary. Otherwise, this spec merely defines a mechanism by which an accessible object with those same roles, states, and properties can be defined without necessarily being tied to the HTML DOM.

Criteria for Inclusion

The first version of this specification is not intended to be complete. It is currently impossible to make some web features accessible, so the primary goal is to resolve immediate needs quickly for existing, inaccessible web interfaces. The specification editors are purposefully deferring many useful ideas in order to maintain a realistic timeline for highest priority features.

In order for features to be considered within scope for 1.0, the following criteria must be met:

• The feature addresses a critical accessibility need that is either impossible to solve, or one whose solution is so tedious to implement that even accessibility-conscious developers avoid remediation. [Note: Some non-critical features may be included if they are side effects of, or trivial to implement because of, work included to support another critical feature.]
• The feature addresses the accessibility of a very commonly used technique or technology. Examples of the problematic usage should exist on major web applications or many other web sites.
• The feature has been considered for privacy impact. [Note: It is possible the spec will mandate that privacy considerations must be addressed before partial implementations ship in browsers.]
• The feature is considered critical for the 1.0 release by at least two of the Accessibility Object Model [AOM] editors, representing two browser manufacturers.

External contributors wishing to submit new features or ideas for consideration should include the following (create a new GitHub Issue?):

• Title and explanation of the problem
• Existing possibilities for remediation (if they exist)
• Demonstrable pain points caused by the lack of this feature, or by the currently available technique to address the problem this feature would solve.
• Optional, but desired: Complete or partial test cases, code examples, or browser user agent patches demonstrating implementability.

Criteria for Exclusion/Objection

Specification objections such as the following will be considered.

• Syntactical or other violations of Web API trends.
• Inability of a feature to be implemented in a particular browser, user agent, or assistive technology.
• Privacy violations or fingerprinting issues (e.g. inadvertent exposure of user details)
• Objections to any feature that would "Break The Web" or otherwise result in irreconcilable incompatibility with existing web APIs.

Specification objections that disregard the following core beliefs will not be entertained.

• All native features and custom user interfaces should be possible to make accessible to all users.
• All web specification authors should consider and account for the accessibility of new features, ideally prior to publishing the feature.
• Where possible, web authors should follow best practices, use natively accessible features first, and not resort to custom user interface elements or custom input handling.
• Finally, because there are times when best practices are ignored, or inaccessible features are used, web authors should have the ability to programmatically augment and override the accessibility of existing mainstream user interfaces.