WCAG Next Steps Workshop


Designing WCAG 2.next: A Next Steps Workshop

This is material originally on the WCAG.Next wiki home page that belongs on an archived page.


The objective of the workshop is to propose at least two viable models for expanding/extending WCAG, from which the community can choose a direction forward.


We will use design thinking to define the problem and ideate and prototype solutions. We will use user-centered design to gather insights into the problem and test the viability of solutions.


  • Define: We will define the problem space.
  • Brainstorm: We will brainstorm solutions, and then choose at least two solutions to pursue.
  • Prototype: We will create prototype models.
  • Present: We will present the prototype models to the community.
  • Feedback: We will gather feedback from the community. We will also gather feedback on the prototype models from WCAG users.
  • Refine: We will refine the prototype models based on insights and feedback.

We will repeat the present/feedback/refine cycle until we have at least two viable models. We will deliver those to the WCAG WG.

Process Resources

Workshop Sessions


  1. Define the problem space
  2. Brainstorm solutions
  3. Make choices
  4. Create prototypes
  5. Share prototypes with WCAG community and WCAG users
  6. Refine prototypes based on insights from feedback (iterate 5–6)
  7. Deliver final models to WCAG WG

Define the problem space

Audience for WCAG

  1. The developer who is trying to incorporate new Guidelines and success criteria into their work. They want to adopt new success criteria into their work patterns.
  2. Conformance officers who need to verify that they are in conformance
  3. Toolmakers who make tools for conformance reporting
  4. Companies that make authoring tools: (e.g. Drupal, Wordpress, Adobe Dreamweaver, and many more) make their tools to allow authors to better meet WCAG.
  5. Policymakers - set accessibility policy for their organizations and countries
  6. Accessibility experts - advise organizations on WCAG. They probably know WCAG best after the WCAG WG working group because they work with WCAG all the time.
  7. People with disabilities - can use WCAG to file complaints
  8. Educators - educate people about the guidelines
  9. Quality Assurance - work with Conformance officer to file bugs for accessibility issues
  10. Others: Designers, Project Managers, Executives


  • WCAG 2.0 cannot change. Too many audiences depend on its stability
    • Policy and toolmakers would struggle with that.
    • Impact on laws and policy is huge. Time issue, and desire to have timely updates to WCAG 2.
  • Policymakers and conformance toolmakers want to have one standard
    • Changes to WCAG could be the difference between 2.1 and 3.0.


  • Can any part of WCAG 2.0 change in WCAG 2.1? Or can it only be added to? that is the key question needing discussion.
  • Task Forces are identifying areas where WCAG needs change. (e.g. color contrast example, changing keyboard trap -> to navigation trap)
  • Some definitions in WCAG are inadequate in modern technology (example def of web content requires http which precludes hybrid web apps)
  • How to handle conflicting requirements between task forces (e.g. color contrast requirements of Low Vision Task Force vs. the color contrast requirements of the Cognitive Accessibility Task Force)
  • Timely updates to address changing and new technologies vs. one monolithic standard
  • In the current Extension model, adding guidelines is ill defined
  • Could 2 projects (WCAG 2.1 and WCAG 3.0) be running in parallel?
  • Difficulty of describing the "Extension Model" to the world
  • Difficulty in establishing a conformance model with extensions
  • How to handle conflicting problems with task force and WCAG?
  • How and when to make the jump from WCAG 2.x to WCAG 3 (or whatever it is named)
  • we need a process to add to WCAG for disabilities not previously addressed
  • we need a process to add new technologies
  • How often can WCAG 2.x change? We must balance between need to accommodate new technologies vs. the need for stability.
  • How do we address errata for 2.0?

WCAG Next Possible Models

This early overview is developed in more detail in WCAG Next Possible Models

  1. (current) WCAG 2.0 plus extension 1, extension 2, extension 3, etc.
  2. WCAG 2.1 by Task Force: based on a WCAG 2.0 plus the work of an individual task force, (e.g. 2.1 = WCAG 2.0 plus extension 1, 2.2 = WCAG 2.1 plus extension 2, etc
  3. WCAG 2.1 by date (e.g. whatever work is done by a specific date)

WCAG 2.1 issues to resolve:

  • Additions to WCAG only
  • Could add new SC, and then deprecate the older ones later?
  • Anything that requires change to WCAG 2.0 would have to drop off until 3.0 is possible. (under discussion)
  • how to coordinate between the task forces and resolve conflicts.

WCAG 3.0 (or WAI 1.0, or TBD name) : - TBD - out of scope for this discussion

  • Keeps the POUR Principals but could allow renumbering
  • Could change structure
  • Would benefit from a design process

Suite of standards - TBD - out of scope

  • Core Principles and Guidelines from WCAG that are more technology neutral
  • Short, specific standards that can be written and adopted more quickly than a change to the Core (e.g. media player standard, hybrid app standard, webrtc standard, mind-reading standard)
  • Like the CSS model, applying to different technologies rather than different audiences.
  • (Criticism) Becomes a lot more complex for teaching, conformance, auditing.
  • (Criticism) Governments would end up choosing, and thus making the one standard, costly to support software builds that work to two different standards.