PROPOSED Accessible Platform Architectures Working Group Charter

The mission of the Accessible Platform Architectures Working Group is to ensure W3C specifications provide support for accessibility to people with disabilities. The group advances this mission through review of W3C specifications, development of new specifications and technical support materials, collaboration with other Working Groups, and coordination of harmonized accessibility strategies within W3C, including monitoring and participatation in W3C Security, Privacy, and Internationalization activities.

Join the Accessible Platform Architectures Working Group.

This proposed charter is available on GitHub. Feel free to raise issues.

Start date	[1 Aug 2025 (expected)] (date of the "Call for Participation", when the charter is approved)
End date	[31 July 2027]
Chairs	Matthew Atkinson (Samsung Electronics Co., Ltd.) Janina Sajka (Invited Expert)
Team Contacts	Ruoxi Ran (0.5 FTE Primary TC)
Meeting Schedule	Teleconferences: The Working Group and its Task Forces generally each hold weekly teleconferences, but this may vary over time according to agenda and preferences. Face-to-face: The Working Group generally meets during the W3C's annual Technical Plenary week; additional face-to-face meetings may be scheduled by consent of the participants, usually no more than 3 per year.

Motivation and Background

Ensuring that web technology is accessible to users with disabilities requires a dedicated group to identify issues and help develop solutions. The APA Working Group complements the other WAI Working Groups by providing accessibility horizontal review of W3C publications. It also explores emerging accessibility issues and publishes its findings to help guide the community. Where accessibility gaps are found that are not addressed by current technologies, the group also incubates technical solutions.

Scope

Support W3C Working Groups, and external organizations collaborating on web technologies as time allows, to create technical specifications that provide features needed for accessibility to people with disabilities via review of documents as part of the horizontal review process, participation in architecture decisions, and by direct interaction with Working Groups as needed.
Develop and publish information about accessibility of web technology, including guidance for technology developers, accessibility user requirements for technologies, and information about accessibility principles in general.
Research accessibility risks and solutions for emerging web-enabled devices and web technologies, such as (but not limited to) artificial intelligence, authentication, automotive interfaces, digital publications, graphics and media, mobile communications devices, payments, tablets, virtual and augmented and mixed reality, Web-enabled television, Web of Things, etc.;
Develop technological accessibility solutions as stand-alone technologies or as components of other web technologies that could become W3C Recommendations, including but not limited to WAI-Adapt features and automated pronunciation guidance.

Out of Scope

The following features are out of scope, and will not be addressed by this Working group.

Engineering accessibility solutions for technologies in scope of other W3C groups.
Addressing accessibility of technologies that do not interact with web content.

Deliverables

this section need to update.

More detailed milestones and updated publication schedules are available on the group publication status page.

Draft state indicates the state of the deliverable at the time of the charter approval. Expected completion indicates when the deliverable is projected to become a Recommendation, or otherwise reach a stable state.

Horizontal Reviews

This Working Group performs horizontal review to help ensure web technologies meet the needs of users with disabilities. The Working Group also produces the following materials as part of horizontal review:

FAST checklist;
Reviews of web technology specifications sent to maintaining entities; and
Comments to other groups about accessibility needs for their deliverables, in the form of overall reviews of specifications, input on specific issues, joint meetings, etc.

Engagement in horizontal review activity is tracked in:

a11y-request repository to request overall specification review from APA,
a11y-review repository and associated dashboard to track APA interactions on specific issues raised by groups,
list of specifications reviewed by APA with links to history, and
charters for new and renewing groups.

Normative Specifications

The Working Group will deliver the following W3C normative specifications:

WAI-Adapt: Symbols Module

This specification supports annotating web content with AAC symbols enabling user agents to augment or adapt content to various user scenarios based on the user's configured preferences. Symbols were previously included in the the earlier Personalization Semantics Content Module 1.0. The specification was renamed to WAI-Adapt: Symbols Module when the Task Force producing the specification was renamed. Additional attributes from the earlier Personalization Semantics Content Module 1.0 will be included in a new WAI-Adapt Complexity Semantics Module, expected FPWD on Q1 2024.

Draft state: Candidate Recommendation

Expected completion: Q2 2024

Adopted Working Draft: WAI-Adapt: Content Module, https://www.w3.org/TR/2022/WD-adapt-content-20220609/, 09 July 2022

Exclusion Draft: The W3C exclusion requirement was satisfied while this Task Force was operating under its former name. Personalization Semantics Content Module 1.0, https://www.w3.org/TR/2018/WD-personalization-semantics-content-1.0-20180316/, 16 March 2018. Exclusion period began 13 February 2018; Exclusion period ended 16 July 2018.

Produced under Working Group Charter: https://www.w3.org/2015/10/aria-charter.html. This deliverable was initially published by the Accessible Rich Internet Applications Working Group and is being moved to the Accessible Platform Architectures Working Group.

WAI-Adapt: Help and Support Module

This specification was previously named Personalization Help and Support 1.0, and was renamed to WAI-Adapt: Help and Support, it will provide use cases and a vocabulary of terms that can be used to enhance alternative or supportive content that may be useful for people with disabilities.

Draft state: Working Draft

Expected completion: Q4 2024 (CR)

Adopted Working Draft: WAI-Adapt: Help and Support Module, https://www.w3.org/TR/2022/WD-adapt-help-20220609/, 09 June 2022

Exclusion Draft: The W3C exclusion requirement was satisfied while this Task Force was operating under its former name. Personalization Help and Support 1.0, https://www.w3.org/TR/2018/WD-personalization-semantics-help-1.0-20181018/, 18 October 2018. Exclusion period began 18 October 2018; Exclusion period ended 18 March 2019.

The Working Group may publish additional WAI-Adapt modules during the course of this charter, and may work with other groups to incorporate adapt features into the native features of web technologies, instead of or in addition to the above work.

Specification for Spoken Presentation in HTML

This specification will provide for proper pronunciation in HTML content when using text to speech (TTS) synthesis and define a standard mechanism to allow content authors to include spoken presentation guidance in HTML content.

Draft state: Working Draft

Expected completion: Q1 2025

Adopted Working Draft: Specification for Spoken Presentation in HTML, https://www.w3.org/TR/2021/WD-spoken-html-20210923/, 23 September 2021

Exclusion Draft: Specification for Spoken Presentation in HTML, https://www.w3.org/TR/2021/WD-spoken-html-20210518/, 18 May 2021. Exclusion period began 18 May 2018; Exclusion period ended 18 January 2022.

Other Deliverables

Other non-normative documents may be created such as:

Supporting documents for WAI-Adapt such as WAI-Adapt Explainer and Requirements for WAI-Adapt, etc.;
Supporting documents for Pronunciation such as Explainer: Improving Spoken Presentation, Pronunciation Gap analysis and use cases, Pronunciation User Scenarios, best practices, etc.;
Supporting resources for Specification Review such as Framework for Accessible Specification of Technologies and FAST checklist, Reviews of web technology specifications sent to maintaining entities, and Working Group Notes to formalize accessibility knowledge on specific topics as the need arises;
Supporting documents for Maturity Model such as W3C Accessibility Maturity Model and others;
Accessibility User Requirements such as Media Accessibility User Requirements and others;
Information about accessibility needs of specific user groups, such as Making content usable for people with cognitive and learning disabilities;
Research reports addressing, as needed, gaps identified during accessibility reviews of draft specifications, and/or technical questions emerging through other aspects of accessibility reviews;
Test suite and implementation reports for normative specifications.

Timeline

Detailed milestones and updated publication schedules are available on the group publication status page.

December 2023: PR of WAI-Adapt: Symbols Module
July 2024: Rec of WAI-Adapt: Symbols Module
July 2024: CR of WAI-Adapt: Help and Support Module
December 2023: CR of Pronunciation Technical Approach

Success Criteria

In order to advance to Proposed Recommendation, each normative specification is expected to have at least two independent interoperable implementations of every feature defined in the specification, where interoperability can be verified by passing open test suites, and two or more implementations interoperating with each other. In order to advance to Proposed Recommendation, each normative specification must have an open test suite of every feature defined in the specification.

There should be testing plans for each specification, starting from the earliest drafts. To promote interoperability, all changes made to specifications in Candidate Recommendation or to features that have deployed implementations should have tests.

Each specification should contain separate sections detailing all known security and privacy implications for implementers, Web authors, and end users. Each specification should contain a section on accessibility that describes the benefits and impacts, including ways specification features can be used to address them, and recommendations for maximising accessibility in implementations.

This Working Group expects to follow the TAG Web Platform Design Principles.

Additional success criteria:

Advancement of WAI-Adapt support on the web via specifications published by this group and features incorporated into other work.
Improved accessibility of web technologies as measured by the activity of accessibility proponents in coordination with APA, accepted comments on specifications, and other tracked Working Group dialog;
Release of Framework for Accessible Specifications as Working Group Note and indications of its use by other Working Groups;
Documentation of new accessibility issues and solutions, potentially with spin-off work begun;
Record of active and sustained coordination between APA and other stakeholders.

Coordination

For all specifications, this Working Group will seek horizontal review for accessibility, internationalization, performance, privacy, and security with the relevant Working and Interest Groups, and with the TAG. Invitation for review must be issued during each major standards-track document transition, including FPWD. The Working Group is encouraged to engage collaboratively with the horizontal review groups throughout development of each specification. The Working Group is advised to seek a review at least 3 months before first entering CR and is encouraged to proactively notify the horizontal review groups when major changes occur in a specification following a review.

Additional technical coordination with the following Groups will be made, per the W3C Process Document:

W3C Groups

Accessibility Guidelines (AG) Working Group: Coordinate on development of techniques and general content accessibility issues.
ARIA Working Group: Coordinate on resolution of architectural issues identified by ARIA and meeting user needs identified by APA.
CSS Working Group: Coordinate on general CSS accessibility topics.
Publishing Maintenance Working Group: Coordinate on accessibility in digital publishing.
HTML Working Group: Coordinate on general HTML and web API accessibility topics.
Internationalization Working Group: Coordinate how to address accessibility and internationalization in W3C specs.
SVG Working Group: Coordinate on general graphics accessibility topics.
Timed Text Working Group: Ensure Media Accessibility User Requirements are met in TTML and WebVTT.
Privacy Interest Group: Coordinate on how to address accessibility and privacy in W3C specs.
WAI Interest Group: Engage in specification review and research activity.
Web Real-Time Communications Working Group: Ensure Media Accessibility User Requirements are met in WebRTC.
Web Payments Working Group: Coordinate on accessibility of payments.

External Organizations

We work with external organizations as needed. Here is a representative list of recent and current partner organizations.

IETF: Coordinate on protocols that impact accessibility of web content.
ISO/IEC JTC 1/SC 35 User interfaces: Coordinate user interface requirements and applicability to web content.
ITU (International Telecommunications Union): Coordinate accessibility of real-time communications.
WHATWG: Coordinate on accessibility of web technologies.
BCI (Blissymbolics Communication International): Coordinate on accessibility of WAI-Adapt: Symbols Module and W3C Alternative and Augmented Communication (AAC) Symbol Registry.

Participation

To be successful, this Working Group is expected to have 6 or more active participants for its duration, including representatives from the key implementors of this specification, and active Editors and Test Leads for each specification. The Chairs, specification Editors, and Test Leads are expected to contribute half of a working day per week towards the Working Group. There is no minimum requirement for other Participants.

The group encourages questions, comments and issues on its public mailing lists and document repositories, as described in Communication.

The group also welcomes non-Members to contribute technical submissions for consideration upon their agreement to the terms of the W3C Patent Policy.

Participants in the group are required (by the W3C Process) to follow the W3C Code of Ethics and Professional Conduct.

Communication

Technical discussions for this Working Group are conducted in public: the meeting minutes from teleconference and face-to-face meetings will be archived for public review, and technical discussions and issue tracking will be conducted in a manner that can be both read and written to by the general public. Working Drafts and Editor's Drafts of specifications will be developed in public repositories and may permit direct public contribution requests. The meetings themselves are not open to public participation, however, except by explicit one-time invitation from the chair(s).

Information about the group (including details about deliverables, issues, actions, status, participants, and meetings) will be available from the Accessible Platform Architectures Working Group home page.

This group primarily conducts its technical work public-apa@w3.org (archive) and GitHub. Additional communication channels are also used. The public is invited to review, discuss and contribute to this work.

The group may use a Member-confidential mailing list for administrative purposes and, at the discretion of the Chairs and members of the group, for member-only discussions in special cases when a participant requests such a discussion.

Decision Policy

This group will seek to make decisions through consensus and due process, per the W3C Process Document (section 5.2.1, Consensus). Typically, an editor or other participant makes an initial proposal, which is then refined in discussion with members of the group and other reviewers, and consensus emerges with little formal voting being required.

However, if a decision is necessary for timely progress and consensus is not achieved after careful consideration of the range of views presented, the Chairs may call for a group vote and record a decision along with any objections.

To afford asynchronous decisions and organizational deliberation, any resolution (including publication decisions) taken in a face-to-face meeting or teleconference will be considered provisional. A call for consensus (CfC) will be issued for all resolutions (for example, via email, GitHub issue or web-based survey), with a response period from 2 to 7 working days, depending on the chair's evaluation of the group consensus on the issue. If no objections are raised by the end of the response period, the resolution will be considered to have consensus as a resolution of the Working Group.

All decisions made by the group should be considered resolved unless and until new information becomes available or unless reopened at the discretion of the Chairs or the Director.

The Working Group maintains specific procedures to establish and measure consensus and address objections in the Accessible Platform Architectures Working Group Decision Policy. All decisions made by the group should be considered resolved unless and until new information becomes available or unless reopened at the discretion of the Chairs or the Director.

This charter is written in accordance with the W3C Process Document (Section 3.4, Votes) and includes no voting procedures beyond what the Process Document requires.

Patent Policy

This Working Group operates under the W3C Patent Policy (Version of 15 September 2020). To promote the widest adoption of Web standards, W3C seeks to issue Web specifications 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.

Licensing

This Working Group will use the W3C Document license for Recommendation-track deliverables and the W3C Software and Document license for Note-track deliverables and licensed non-TR publications.

About this Charter

This charter has been created according to section 3.4 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.

Charter History

The following table lists details of all changes from the initial charter, per the W3C Process Document (section 4.3, Advisory Committee Review of a Charter):

Charter Period	Start Date	End Date	Changes
Initial Charter	22 October 2015	31 July 2018	none
Rechartered	08 August 2018	31 July 2021	Changes from the previous charter (diff from previous charter): Added Personalization Semantics as a Rec-track deliverable, transferred from the ARIA Working Group; Increased work on non-normative resources to support accessibility horizontal review; Clarified participation and communication procedures; Added licensing section to specify the W3C Document license for Recommendation-track deliverables and the W3C Software and Document license for others; Increased staff effort from .4 FTE to .7 FTE to provide additional support for Research Questions Task Force and accessibility horizontal review, and because of the new Personalization Semantics deliverable.
Staff change	19 April 2019		Joshue O Connor replaced Shadi Abou-Zahra with .05 FTE staff support.
New Co-Chair	25 June 2020		Becky Gibson joined Janina Sajka as co-chair of the Working Group.
Rechartered	11 August 2021	31 July 2023	Changes from the previous charter (diff from previous charter): Added Pronunciation as an explicit deliverable; Simplified Scope; Updated Process and Patent Policy versions.
Chairs change	4 January 2022		Matthew Atkinson is appointed as new co-Chair of the Working Group; Becky Gibson stepped down as co-Chair.
Staff change	11 March 2022		Ruoxi Ran take the primary Team Contact of the Working Group.
Rechartered	1 Aug 2023	31 July 2025	Changes from the previous charter (diff from previous charter): Added Maturity Model as a Note track deliverable.
Rechartered	1 Aug 2025	31 July 2027	Changes from the previous charter (diff from previous charter): to be added.

Work in the scope of this group was, before the previous charter, carried out by the Protocols and Formats Working Group.