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.

Objective

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.

Methods

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.

Process

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

IDEO.org Design Kit Brainstorming Rules

Workshop Sessions

Framework

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

Define the problem space

Audience for WCAG

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.
Conformance officers who need to verify that they are in conformance
Toolmakers who make tools for conformance reporting
Companies that make authoring tools: (e.g. Drupal, Wordpress, Adobe Dreamweaver, and many more) make their tools to allow authors to better meet WCAG.
Policymakers - set accessibility policy for their organizations and countries
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.
People with disabilities - can use WCAG to file complaints
Educators - educate people about the guidelines
Quality Assurance - work with Conformance officer to file bugs for accessibility issues
Others: Designers, Project Managers, Executives

Constraints

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.

Problems

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

(current) WCAG 2.0 plus extension 1, extension 2, extension 3, etc.
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
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.