[DRAFT] Accessible Platform Architectures Working Group Charter
Note: There is a request to split the APA WG into two WGs, a spec review group and a spec development group. However, it is not certain if this split will happen. Therefore, this charter is for the non-split group. Separate split group charter drafts are available for the spec review group and the spec development group.
Note: The draft ARIA charter has updated deliverables, timelines, and dependencies that are not reflected here. If the group does not split, those will need to be moved into this charter.
The mission of the Accessible Platform Architectures Working Group (APA WG, formerly the Protocols and Formats Working Group), part of the WAI Technical Activity, is to ensure W3C specifications provide support for accessibility to people with disabilities. The group advances this mission through review of W3C specifications, technical support materials, and specifications that bridge known gaps.
This mission is complementary to the work of other Web
Accessibility Initiative (WAI) groups within the WAI
Technical Activity and the WAI
International Program Office Activity. The APA WG is part of
the WAI Technical Activity.
| End date | 31 May 2018 |
|---|---|
| Confidentiality | Proceedings are public. |
| Initial Chairs | Janina Sajka |
| Initial Team Contacts (FTE %: 45) |
Michael Cooper |
| Usual Meeting Schedule | Teleconferences: Weekly Face-to-face: approximately 2 per year |
Scope
- Support accessibility of W3C technologies:
- Provide expertise to the W3C about the needs of users with disabilities, including both serving as a resource base and providing educational in-reach to the W3C community as needed;
- Review W3C requirements and specifications as needed to identify accessibility issues and make recommendations to the appropriate Working Group, particularly at the First Public Working Draft and Last Call or Candidate Recommendation stages and when explicit milestone review readiness is signaled;
- Coordinate with accessibility proponents in W3C technical groups to help ensure accessibility solutions are developed in a consistent manner across technologies and to ensure that accessibility needs are addressed at an appropriate part of the technology stack;
- Work closely with Working Groups when needed to help them architect their specifications to support, and not unknowingly interfere with, accessibility;
- Identify gaps in the technical foundation of W3C technologies and propose solutions with other Working Groups or via new technical work;
- Provide concrete guidance about how to ensure technical specifications appropriately support accessibility;
- Advocate creation and reuse of common implementations of functions that are required by accessibility;
- Collect information about technology features, implementation, and usage patterns to institutionalize W3C knowledge about present-day accessibility problems, including for emerging technologies such as social networking, real-time communications, Web-based television viewing, etc.;
- Review non-W3C technologies that impact the accessibility of W3C technologies;
- Determine accessibility considerations for new devices and technologies, such as e-books, mobile communications devices, tablets, automotive interfaces, Web-enabled television, etc.;
- Strategize solutions within W3C and via liaisons with external organizations.
- Develop accessibility-specific technical specifications:
- Create technology extensions to address accessibility issues in already deployed technologies;
- Build and execute test suites for normative deliverables;
- Help create WCAG 2.0 techniques for technologies that APA WG helps to develop;
- Determine features needed in future versions of ARIA and publish requirements.
Success Criteria
- Other W3C specifications have improved accessibility;
- Release of WAI-ARIA 1.1 and supporting specifications as a W3C Recommendation;
- Release of Web Technology Accessibility Guidelines as Working Group Note;
- Begin work on future versions of WAI-ARIA and supporting specification modules;
- Demonstrate successful implementation of WAI-ARIA and the improved accessibility of Rich Web (Web 2.0) content in a broad range of user agents.
Out of Scope
Education and evangelization outside of the W3C.
Deliverables
The following deliverables would be published as W3C Technical Reports and supporting resources. Accessibility API Mapping Guides fill the role previously filled by WAI-ARIA 1.0 User Agent Implementation Guide, modularized and developed on separate timelines to address multiple host languages.
- Accessible Rich Internet Applications (WAI-ARIA) modules
(Recommendation) versions 1.1 and later including but not limited
to:
- Accessible Rich Internet Applications (WAI-ARIA) core module,
- Digital Publishing Roles module,
- Graphics Roles module;
- Accessibility API Mapping modules (Recommendation) versions 1.0
and later including but not limited to:
- Core Accessibility API Mappings,
- Accessible Name and Description: Computation and API Mappings,
- HTML Accessibility API Mappings (jointly with the HTML Working Group),
- SVG Accessibility API Mappings (jointly with the SVG Working Group),
- Digital Publishing Accessibility API Mappings (jointly with the Digital Publishing Interest Group);
- User Context Properties (Recommendation) versions 1.0 and later (formerly developed by the IndieUI Working Group as IndieUI: User Context);
- WAI-ARIA Authoring Practices (Note);
- Inaccessibility of CAPTCHA (Note);
- Web Technology Accessibility Guidelines (Note);
- Media Accessibility User Requirements (Note);
- Working Group Notes to formalize accessibility knowledge on specific topics as the need arises (Note);
- Joint deliverables with the HTML Working Group prepared by the HTML Accessibiity Task Force. At charter time, these include:
- Test suites for technical specifications.
- DTDs, schemata, and other resources to support automated validation of content that uses WAI-ARIA.
Other Deliverables
- Feedback to W3C specification developers;
- Requirements for normative deliverables including future WAI-ARIA versions;
- WAI-ARIA samples;
- WAI-ARIA 2.0 Roadmap;
- Contribute to WCAG 2.0 Techniques specific techniques for HTML 5 and ARIA (jointly produced with the Web Content Accessibility Guidelines Working Group);
- Gap analysis and roadmap for inclusion of people with cognitive disabilities.
Milestones
| Note: The group will document significant changes from this initial schedule on the group home page. | ||||
| Specification | FPWD | CR | PR | Rec |
|---|---|---|---|---|
| WAI-ARIA 1.1 | Jul 2015 | Jan 2016 | Mar 2016 | |
| Digital Publishing Roles module | Apr 2015 | Dec 2016 | Jun 2017 | Aug 2017 |
| Graphics Roles module | Sep 2015 | Jan 2016 | Oct 2016 | Dec 2016 |
| Core Accessibility API Mappings | Jul 2015 | Jan 2016 | Mar 2016 | |
| Accessible Name Accessibility API Mappings | Jul 2015 | Jan 2016 | Mar 2016 | |
| HTML Accessibility API Mappings | Dec 2015 | Jun 2017 | Aug 2017 | |
| SVG Accessibility API Mappings | Jan 2016 | Oct 2016 | Dec 2016 | |
| Digital Publishing Accessibility API Mappings | Sep 2015 | Dec 2016 | Jun 2017 | Aug 2017 |
| User Context Properties | Sep 2015 | May 2016 | Nov 2016 | Jan 2017 |
A detailed plan to achieve these milestones, and known deviations from these initially chartered milestones, is documented in the APA WG Project Management Plan.
Dependencies
Dependencies on W3C Groups
- CSS Working Group
- Coordinate media queries support for context awareness. Provide requirements for future WAI-ARIA support. Coordinate on general CSS accessibiity topics.
- Digital Publishing Interest Group
- Coordinate development of digital publishing roles.
- Internationalization Activity
- Coordinate how to address accessibility and internationalization in W3C specs.
- HTML Working Group
- Implementation of ARIA and HTML Accessibility API Mappings, and work on other joint deliverables.
- Privacy Interest Group
- Identify and resolve privacy implications of features of the technology that capture user environment information, particularly specific assistive technology being used, in order to customize the user experience.
- SVG Working Group
- Develop graphics role module and SVG Accessibility API Mappings..
- Timed Text Working Group
- Ensure Media Accessibility User Requirements are met in TTML.
- Web Applications Working Group
- Coordinate development of APIs that address accessibility use case.
- Web Content Accessibility Guidelines (WCAG) Working Group
- Work on HTML 5 and ARIA Techniques for WCAG 2.0.
- Web Real-Time Communications Working Group
- Ensure Media Accessibility User Requirements are met in WebRTC.
Furthermore, Accessible Platform Architectures Working Group expects to follow these W3C Recommendations:
Liaisons to External Groups
APA WG does not maintain formal liaisons to external groups, but does coordinate on an as-needed basis on topics of mutual relevance. At charter time, these organizations include:
Participation
To be successful, the Accessible Platform Architectures Working Group is expected to have 10 or more active participants for its duration, with participation where possible including representation from industry including browser and assistive technology implementers, disability communities, and accessibility research. Effective participation in the Accessible Platform Architectures Working Group is expected to consume four to eight hours per week for each participant; twice as much per week for chairs and editors. The Accessible Platform Architectures Working Group will allocate also the necessary resources for building Test Suites for each specification.
Participants are reminded of the Good Standing requirements of the W3C Process.
Communication
The Working Group communicates by regular teleconferences, email, IRC, Web-Based Survey, issue tracker comments, and occasional face to face meetings. At charter time, the group uses the following mailing lists:
- public-pfwg@w3.org (likely to be moved to public-apa@w3.org): ordinary Working Group discussion;
- public-pfwg-comments@w3.org (likely to be moved to public-apa-comments@w3.org): public comments on non-technical publications;
- public-aria@w3.org: ARIA-specific discussion and public comments;
- wai-xtech@w3.org: Working Group discussions involving a wider audience than the WG membership, and where specification review announcements and submissions are copied;
- w3c-wai-ig@w3.org: announcements of Working Group activities including publications, key events, and specification reviews.
Details about available communication mechanisms, as well as other information about the group (deliverables, participants, face-to-face meetings, teleconferences, etc.) is available from the Accessible Platform Architectures Working Group home page as well as the WAI home page.
This group coordinates with other WAI groups to ensure a common approach to addressing accessibility requirements.
Decision Policy
As explained in the Process Document (section 3.3), this group will seek to make decisions when there is consensus. Consensus may be reached and ascertained in any Working Group forum, but the decision must be ratified by an email or Web-Based Survey Call for Consensus or Call for Objection. Specific procedures to measure consensus are detailed in the @@Accessible Platform Architecture Decision Policy. This policy may be updated occasionally as the needs of the group evolve; updates are ratified using the version of the policy then in effect.
When the Chair puts a question and observes dissent, after due consideration of different opinions, the Chair should record a decision (possibly after a formal vote) and any objections, and move on. When the Chair conducts a formal vote to reach a decision on a substantive technical issue, eligible voters may vote on a proposal one of three ways: for a proposal, against a proposal, or abstain. For the proposal to pass there must be more votes for the proposal than against. In case of a tie, the Chair will decide the outcome of the proposal.
This charter is written in accordance with Section 3.4, Votes of the W3C Process Document and includes no voting procedures beyond what the Process Document requires.
Patent Policy
This Working Group operates under the W3C Patent Policy (5 February 2004 Version). To promote the widest adoption of Web standards, W3C seeks to issue Recommendations that can be implemented, according to this policy, on a Royalty-Free basis.
For more information about disclosure obligations for this group, please see the W3C Patent Policy Implementation.
About this Charter
This charter for the Accessible Platform Architectures Working Group has been created according to section 6.2 of the Process Document. In the event of a conflict between this document or the provisions of any charter and the W3C Process, the W3C Process shall take precedence.
Please also see the previous charter for this group. A @@diff version between this charter and the previous charter is available. Primary changes in this charter:
- Added WAI-ARIA 1.1 and Accessibility API Mappings as a normative deliverable.
- Added specific roles modules and Accessibility API Mappings for HTML, SVG, and digital publishing
- Added requirements and roadmap for WAI-ARIA 2.0.
- Moved Web Technology Accessibility Guidelines from Recommendation track to Note track.
- Explicitly called out existing Note-track efforts on Inaccessibility of CAPTCHA and Media Accessibility User Requirements; retained option to create new Note-track deliverables as needed when in scope.
- Expanded scope information about specification review and coordination of accessibility efforts across Working Groups.
- Existing projects will be moved to public space, though legacy resources (old minutes, issue tracking, etc.) cannot be moved due to confidentiality change restrictions.
Michael Cooper, APA WG Team Contact
Janina Sajka, APA WG Chair
Copyright © 2015 W3C ® (MIT , ERCIM , Keio, Beihang), All Rights Reserved.
$Date: 2015/05/13 19:23:49 $