Accessibility Charter

From MemberWiki

Jump to: navigation, search

Contents

Introduction

This document contains the approved text for the charter for the Accessibility (A11y) Working Group. For more information on this WG, please refer to its home page, /member/wiki/Accessibility. This charter was developed in accordance with the OpenAjax Alliance Development Process and will be submitted to the OpenAjax Alliance members and Steering Committee for formal approval.

This wiki page should not be changed except via coordination with the Chair(s) (see below). The preferred approaches for feedback on this document are the A11y committee mailing list (accessibility@openajax.org), the public mailing list (public@openajax.org), or the discussion tab on this wiki page.

Creation Review

Projected schedule

  • Creation Review phone call
  • Member voting - concerns raised by Microsoft; voting to begin no later than one month after Creation Review call
  • Steering Committee voting - Will occur during the 1 week period following tabulation and reporting on Member voting

Initiating Member and Proposal Lead

The OpenAjax Alliance Development Process requires that the initiating Member identify its Proposal Lead:

  • Initiating Member: IBM
  • Proposal Lead: Michael Squillace <masquill (at)us.ibm.com>

(Note that the above single-person "Proposal Lead" is just to match what is expected from the Development Process during the Proposal Phase. Once the charter is approved, the co-chairs will be Richard Schwerdtfeger and Michael Squillace of IBM.)

Mission and Scope

Background

The growing adoption of Rich Internet Applications (RIAs) has prompted the development of standards for providing a way to measure the degree to which these applications are enabled for accessibility. For example, the W3C Web Content Accessibility Guidelines 2.0 (WCAG2) provides criteria that must be satisfied if an application or piece of web content is to be judged accessible. While WCAG2 provides criteria for more traditional accessibility concerns such as providing text equivalent for graphical content and ensuring intuitive navigability, it also improves upon W3C Web Content Accessibility Guidelines 1.0 by mandating criteria for more robust interoperability with assistive technologies, requiring, for example, that content supply accurate accessibility semantics to assistive technologies such as a user interface object's role, state, and value information as well as relationships between objects in a document or an application.

However, due to the necessarily abstract nature of the criteria in WCAG2 (and in most other guidelines), determining the correct logic or algorithm for gauging the satisfaction of a given criterion for a particular element of an application within a given technology can be difficult. The interpretation of exactly how a given criterion is to be satisfied is too frequently left to developers or accessibility tool vendors. This lack of direction, together with the problems posed by the more dynamic and interactive nature of RIAs in accessibility testing, has led to a significant want in accessibility tooling for such applications.

(For more on these and other issues regarding the accessibility testing of RIAs, see the A11y WG home page.)

Mission

The A11y Working Group has the mission of setting forth a specification for a format for expressing the algorithm or executable logic for determining the applicability of a specific criterion to a specific element of a document or application and, if applied, for determining whether or not that criterion is satisfied by that element. Executable logic or algorithms will be expressed as validation rules that are:

  1. readily-consumable- the rules can be processed as-is by commonly available mechanisms for parsing or interpreting text-based data and applied to content or applications within the scope of this charter by compliance or governance tools
  2. portable - the rules can be consumed and applied by any compliance or governance tool without regard to its requisite runtime environment
  3. reusable - validation rules can be re-purposed for different sets of guidelines or standards, in different design-time and run-time environments, and by tools throughout the content authoring and software life cycles.

The WG will also provide best practices for reporting violations of these validation rules and for the application of these rules to content or applications by compliance engines that support this format.

The specifications and supporting materials of this WG will center around accessibility compliance, but the WG is interested in the extent to which the developed rules format supports expressing rules for other types of compliance such as privacy, branding, and security.

Scope

The scope of the A11y WG is defined with reference to:

  1. the types of content and applications to which validation rules are applied
  2. the types of guidelines, specifications, standards, or regulations that are being applied

In particular, the WG will focus on the following combinations of accessibility guidelines and technologies:

  • WCAG 2.0 w/ HTML 4.01 + WAI-ARIA

At time of this writing, both HTML5 and WAI-ARIA as well as the U.S. Section 508 Refresh are in draft forms. It is expected that future recharters of the WG will address these technologies and guidelines, but the currrent charter is limited to the combination noted above.

Many of the validation rules developed by the WG will be based on current techniques that are part of WCAG2. However, many other rules, especially those concerned with WAI-ARIA compliance, will not have WCAG2 techniques associated with them. The WG will not be confined, then, to existing techniques, although new techniques may be written and submitted for consideration by the W3C.

The WG will pursue industry promotional activities to spur adoption of the WG's technologies.

The WG will continue to leverage work to date from the Accessibility Tools Task Force (/member/wiki/Accessibility).

The WG will manage open source reference implementations of its specifications.

This charter allows for the WG to define specifications and features as necessary without rechartering so long as those specifications and features are consistent with the mission and scope of the WG. On the other hand, if new features are proposed that go beyond this scope, a new or revised charter will be necessary.

Deliverables

Accessibility Rules Format 1.0 Specification

The WG will produce an Accessibility Rules Format 1.0 Specification that provides a rules format for codifying accessibility guideline criteria consistent with the Mission and Scope (see above) that will enable accessibility test tools to determine the applicability of these criteria to specific elements of content or applications and whether or not these criteria are satisfied by these elements. This specification will be normative.

Accessibility Reporting Best Practices 1.0 Note

The WG will produce an Accessibility Reporting Best Practices 1.0 Note that provides a set of best practices for reporting accessibility compliance violations consistent with the Mission and Scope (see above) that will guide accessibility test tool venders in the most effective way to report accessibility violations within different environments or reporting scenarios. This note will be non-normative.

Ruleset and Rules Repository

The WG will maintain, regularly update, and oversee contributions to a repository of validation rules and rulesets within the scope of this charter, which defines the technologies and types of accessibility guidelines for the rules in this repository. The WG will make this repository public so that accessibility tool venders and other applications may use the valaidation rules as-is and in order to promote the reuse of the technology set forth by the WG. The WG will also welcome contributions of validation rules from other organizations that follow a rules review process to be set forth by the WG.

Errata, Updates, and Revisions to the Deliverables

Depending on perceived industry need, the WG might produce updates to the Accessibility Rules Format 1.0 Specification (e.g. a version 1.1 specification), the Accessibility Reporting Best Practices 1.0 Note, and the rules repositories listed earlier. The updates might include minor feature additions and/or fixes in the same general technical areas as the previous documents.

Other Materials

The WG may produce other Materials, including Specifications, other relevant technical documents, tests, and sample applications, so long as they are consistent with the Working Group's mission and scope.

Coordination with other Working Groups and Task Forces

There are currently no requirements for coordination with other OpenAjax Alliance Working Groups or Task Forces.

If new OpenAjax activities are started during the duration of this WG, the WG will determine what coordination activities are required (if any) with the new activities.

Schedule

Duration

This WG will be chartered to run until June 30, 2011.

Revisions to this charter might shorten or extend the duration of this WG. In fact, extensions or recharterings are likely given that future work of this WG has dependencies upon legislation, guidelines, and specifications for technologies that are not complete at the time of this writing.

Milestones

The following milestones represent expected delivery dates, but the WG can use judgment to update delivery dates using its own discretion.

  • It is expected that an approved Accessibility Rules Format version 1.0 specification will be available by October 31, 2010.
  • It is expected that an initial set of validation rules for WCAG2 w/ HTML 4.01 + WAI-ARIA will be approved and available by October 31, 2010. Future updates to these validation rules and the corresponding rulesets will be approved and made available by January 31, 2011, April 30, 2011, and June 30, 2011.
  • It is expected that an approved and non-normative Accessibility Reporting Best Practices 1.0 Note will be available by June 30, 2011.

Communications mechanisms

Email

Email will occur on accessibility@openajax.org. This email list will be read-only to people who are not representatives of Members of OpenAjax Alliance. Public discussion will occur on public@openajax.org.

Phone

Phone calls will occur biweekly on Wednesdays at 09:00 CST, 14:00 UCT. See the WG's home page for up-to-date information on call-in logistics such as dial-in numbers and conference codes.

IRC

This WG uses IRC during its regular conference calls for minuting meetings and for other discussion related to the WG's work:

  • IRC Server: irc.mozilla.org
  • Channel: #oaa-accessibility

Chair(s), expected membership, and operational rules

Richard Schwerdtfeger of IBM and Jon Gunderson of the University of Illinois are the proposed co-chairs for the A11y WG. It is expected that the people who are currently involved in the existing A11y WG will participate in this WG. As of time of this writing, this includes the following organizations:

  • Deque
  • IBM
  • ParaSoft
  • University of Illinois

There will be a consensus decision process managed by the chairs that aligns with common practice in Web standards (e.g., W3C consensus process) and open source activities (e.g., Apache voting process), where a particular decision process used to resolve a particular issue is chosen by the chair(s) based on appropriateness to the given circumstance. This WG produces recommendations to the Membership and Steering Committee about activities and material to be published, in accordance with processes defined by the OpenAjax Alliance Members Agreement and the OpenAjax Alliance Development Process.

Personal tools