DRAFT Accessibility Guidelines Working Group Charter
The mission of the Accessibility Guidelines Working Group is to develop specifications to support making implementations of web technologies accessible for people with disabilities, and to develop and maintain implementation support materials.
This proposed charter is available on GitHub. Feel free to raise issues.
Charter Status | See the group status page and detailed change history. |
---|---|
Start date | [dd monthname yyyy] (date of the "Call for Participation", when the charter is approved) |
End date | [dd monthname yyyy] (Start date + 2 years) |
Chairs |
|
Team Contacts |
|
Meeting Schedule |
Teleconferences: weekly In-person: we will meet during the W3C's annual Technical Plenary week; additional in-person meetings may be scheduled by consent of the participants, usually no more than 3 per year. |
Motivation and Background
Web accessibility means that websites, tools, and technologies are designed and developed so that people with disabilities can use them. Web accessibility encompasses all disabilities that affect access to the Web, and also benefits older users and people without disabilities. Accessible design improves overall user experience and satisfaction, especially in a variety of situations, and across different devices. It is essential that several different components of web development and interaction work together in order for the web to be accessible to people with disabilities. These components include content technologies, web content, web browsers and media players, assistive technology, users, developers, authoring tools, and evaluation tools. Groups in the Web Accessibility Initiative work together to address accessibility for all the components.
The Accessibility Guidelines Working Group describes the characteristics of accessible web content, in the form of guidance to content developers. It also describes support from other components needed for its advice to work, such as technologies, user agents, and authoring tools. Guidelines from this Working Group are widely used by developers and implementers, referenced in industry policy, and benefit all web users.
Focus
Is this needed for this charter, or would Scope be sufficient?
Scope
What exactly is in scope, and out of scope. For legal review. Be brief.
Out of Scope
The following features are out of scope, and will not be addressed by this Working group.
- The AG WG is not, and does not aspire to be, the central repository for accessibility support data.
- The AG WG does not perform conformance evaluations and reviews.
- The AG WG does not provide normative guidance on non-web technologies; however, informational guidance may include examples outside the scope of the web.
- The AG WG is not currently working on the Authoring Tool Accessibility Guidelines or the User Agent Accessibility Guidelines specifications, except to maintain errata, though some content may be relevant to and included in WCAG 3.
Deliverables
Updated document status is available on the group publication status page. [or link to a page this group prefers to use]
Draft state indicates the state of the deliverable at the time of the charter approval. Choose one: Expected completion indicates when the deliverable is projected to become a Recommendation, or otherwise reach a stable state The Working Group intends to publish the latest state of their work as Candidate Recommendation (with Snapshots) and does not intend to advance their documents to Recommendation.
Normative Specifications
The Working Group will deliver the following W3C normative specifications:
Consider making a second list for existing specifications that the group will maintain.
- [new spec name]
-
This specification will define [concrete description].
Draft state: [No draft | Use Cases and Requirements | Editor's Draft | Member Submission]
Expected completion: [Q1–4 yyyy]
If this is a new technical report that will start as a copy of a different TR:
Initial Text: The title, stable URL, and publication date of the existing technical report which will serve as the initial text of the deliverable.
Otherwise, if there is an existing Exclusion Draft, use the [current spec name] template below instead.
- [current spec name]
-
This specification defines [concrete description].
Draft state: [Adopted from WG/CG Foo | Working Draft]
Expected completion: [Q1–4 yyyy]
Per 5.2.6, for every Recommendation Track deliverable that continues work on a Working Draft (WD) published under any other Charter (including a predecessor group of the same name), for which there is an existing Exclusion Draft:
Adopted Draft: The title, stable URL, and publication date of the Adopted Draft which will serve to continue the work on the deliverable. If the draft is not a continuation of an existing draft (such as renaming the new draft by using a new version number), the Adopted Draft field must not used (as well as "Exclusion Draft" and "Exclusion Draft Charter" below) (see also Council recommendation and FAQ #41).
Exclusion Draft: The title, stable URL, and publication date of the most recent Exclusion Draft. Exclusion period began; Exclusion period ended. (this charter assistant helps in producing the list. use the proper wgid)
Exclusion Draft Charter: The stable URL of the Working Group charter under which the most recent Exclusion Draft was published.
Tentative Deliverables
Depending on the incubation progress, interest from multiple implementers, and the consensus of the Group participants, the Working Group may adopt the following documents as Rec-track specifications:
- Web [spec name]
-
This specification defines [concrete description].
Draft state: Proposal in [other name] Community Group
Other Deliverables
Other non-normative documents may be created such as:
- Use case and requirement documents;
- Test suite and implementation report for the specification;
- Primer or Best Practice documents to support web developers when designing applications.
Timeline
Put here a timeline view of all deliverables.
- Month YYYY: First teleconference
- Month YYYY: First face-to-face meeting
- Month YYYY: Requirements and Use Cases for FooML
- Month YYYY: FPWD for FooML
- Month YYYY: Requirements and Use Cases for BarML
- Month YYYY: FPWD FooML Primer
Coordination
For all specifications, this Working Group will seek horizontal review for accessibility, internationalization, 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
- Accessible Platform Architectures Working Group
- Provide input into other W3C groups on accessibility requirements, and coordinate on development and adoption of functional needs and maturity model.
- ARIA Working Group
- Review and help develop WCAG 2.x Techniques for WAI-ARIA.
- Cascading Style Sheets Working Group
- Advise on WCAG conformance interpretations of CSS features.
- Internationalization Working Group
- Ensure that references to internationalization techniques are correct, and to ensure that language can be translated successfully.
- WAI Interest Group
- Provide input on group deliverables and explore ideas for consideration and further development.
External Organizations
This section is a non-exclusive list of organizations that may take up WAI guidelines into policies. The Working Group seeks to develop standards that can be incorporated into policies globally and expects to accomplish this through broad review and involvement. AG WG will liaise with these organizations at key stages but recommends direct participation in the Working Group where possible.
- U.S. Access Board
- Review of specification
- Canadian Accessibility Standards Development Organization which may administer C-81 the Accessible Canada Act
- Review of specification
- European Telecommunications Standards Institute (ETSI)
- Establish liaison with the ETSI Human Factors Technical Committee for collaboration and specification review.
- European Committee for Standardization (CEN)
- Review of specification
- European Commission
- Review of specification
- National Information Society Agency (NIA)
- Review of specification
- RERC for the Advancement of Cognitive Technologies
- Review of specification
- RERC on Universal Interface and Information Technology Access
- Review of specification
- Chinese Disabled People's Federation (CDPF)
- Review of specification
- Japanese Industry Standards Organization (JIS)
- Review of specification
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.
Key implementers of WCAG (desktop and non-desktop environments) include Web content developers (page authors, site designers, etc.), Web authoring tool developers, Web accessibility evaluation tool developers, user agent tool developers, and people with disabilities.
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 make technical contributions for ongoing work, provided they agree to the terms of the W3C Patent Policy.
Participants in the group are required (by the W3C Process) to follow the W3C Code of 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.
Information about the group (including details about deliverables, issues, actions, status, participants, and meetings) will be available from the Accessibility Guidelines Working Group home page.
This group conducts discussion on the public mailing list w3c-wai-gl@w3.org (archive) and in the WCAG 3 and WCAG 2 Github repositories. Task forces and sub-groups may use additional lists or other communication mechanisms documented on their home pages. Discussion of issues for specific deliverables generally takes place in the GitHub repository identified for the deliverable. 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 [pick a duration within:] one week to 10 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.
Note: The AG WG has maintained a supplemental decision policy to support the review needed for decisions that can impact regulatory content. A recent update preserves this for stable content while reducing procedural requirements for content that is still under development. The scope of this charter combines maintenance of the mature WCAG 2.x with innovation of WCAG 3. Because of this complex scope, the WG chairs view the decision policy changes as essential to WG success. The updated decision policy should be reviewed together with this draft charter.
This charter is written in accordance with the W3C Process Document (Section 5.2.3, Deciding by Vote) and includes no voting procedures beyond what the Process Document requires.
[Keep 'Patent Policy' for a Working Group, 'Patent Disclosures' for an Interest Group]
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 licensing information.
Patent Disclosures
The Interest Group provides an opportunity to share perspectives on the topic addressed by this charter. W3C reminds Interest Group participants of their obligation to comply with patent disclosure obligations as set out in Section 6 of the W3C Patent Policy. While the Interest Group does not produce Recommendation-track documents, when Interest Group participants review Recommendation-track specifications from Working Groups, the patent disclosure obligations do apply. For more information about disclosure obligations for this group, please see the licensing information.
Licensing
This Working Group will use the W3C Software and Document license for all its deliverables.
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 | 6 October 1997 | <not set> | Develop Understanding Web Access Issues, later named Web Content Accessibility Guidelines 1.0; document supporting quicklists. |
Rechartered 2001 | 18 June 2001 | May 2002, extended to June 2004 | Add WCAG 2.0 and supporting techniques to its deliverables. |
Rechartered 2005 | 1 January 2005 | 31 December 2006; extended to 30 April 2007, 31 December 2007, 30 June 2008, 31 December 2008, 30 June 2009, 9 August 2009 | Incorporation of Quality Assurance (QA) Framework into its mission; updated descriptions of supporting deliverables for WCAG 2.0, especially including test suites and implementation reports; updated dependency statements; updated language where necessary to align with June 2003 W3C Process Document. |
Rechartered 2010 | 14 September 2010 | 30 June 2013; extended to 30 September 2013, 18 May 2015, 15 July 2015, and 24 September 2015 | Transitioned to maintain support resources for WCAG 2.0. |
Rechartered 2015 | 24 September 2015 | 31 July 2018 | Added recommendation-track work in the form of extensions to WCAG 2.0; increased focus on work to address needs related to mobile devices, cognitive impairments and learning disabilities, digital learning materials, and low vision; more work on accessibility support documentation and testing. |
Rechartered 2017 | 27 January 2017 | 31 October 2019, extended to 31 December 2019 | Changing from publishing normative extensions for multiple topics to a consolidated WCAG 2.1 and adding new publication for Accessibility Conformance Testing Framework 1.0. |
New Co-Chair | 27 February 2018 | Alastair Campbell joins Andrew Kirkpatrick as co-chair; Joshue O Connor steps down as co-chair. | |
Rechartered 2019 | 19 December 2019 | 31 October 2022 | Added WCAG 2.2 and moved previously incubated Silver to Recommendation Track. |
New Co-Chairs | 4 March 2020 | Chuck Adams and Rachael Montgomery join Alastair Campbell as co-chairs; Andrew Kirkpatrick steps down as co-chair. | |
Chair Affiliation | 24 September 2021 | Rachael Montgomery re-appointed as group chair after affiliation changed. | |
Charter Extension | 28 October 2022 | 31 October 2023 | Charter extended until 30 April 2023. Charter extended until 31st October 2023. |
Rechartered 2023 | 3 November 2023 | 31 October 2025 | Shift in focus to WCAG 3 and ongoing updates of non-normative resources for WCAG 2.x |
Rechartered 2025 | dd MMM 2025 | dd MMM 2027 | Continue work on WCAG 3 and ongoing updates of non-normative resources for WCAG 2.x |
Change log
Changes to this document are documented in this section.