Criteria for Inclusion

The first version of the Accessibility Object Model 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 as 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 or 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 there are gaps in web platform APIs, 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.