1 of 34

Silver Status Update �March 2019

goo.gl/6YKVH2

Shawn Lauriat & Jeanne Spellman

2 of 34

Silver

Content

Easier to use
Easier to reference
Easier to understand
Expanded scope
Inclusive of more disabilities
Inclusive of more perspectives
Inclusive of more technologies
Useful for more people

Process & Structure

Based on evidence and data
Broadly communicate our efforts
Clear project milestones
Inclusive communication paths
Inclusive of more perspectives
Involve more stakeholders
Easier to maintain and update
Clearer update path

3 of 34

Silver Plan

1 Research� Structure� Content

2 Analysis

3 Solutions

4 Prototypes

5 Writing Silver

Q1 Q2 Q3 Q4

2017

Q3 Q4

2016

Q1 Q2 Q3 Q4

2018

Q1 Q2 Q3 Q4

2019

Q1 Q2 Q3 Q4

2020

2021

4 of 34

Milestones and Reports completed

Milestone	Date
Project Proposed to the Accessibility Guidelines Working Group	Oct 2016
Research with partners in academia and industry - 16 months Identify Stakeholders Create Stakeholder Job Stories Research Summary Report on Structural Issues for Silver	Nov 2016- Feb 2018
Silver Design Sprint	Mar 2018
Prototype Development	May 2018- today

5 of 34

Proposed Timeline to completion

Milestone	Date
Move existing WCAG content into the new structure	Q1-Q4 2019
Face to Face Meeting at CSUN to train and write content	Mar 2019
Develop new Silver content	Q1-Q3 2020
On-going maintenance begins for Silver x.1	Q3 2021
AGWG publishes Silver Recommendation	Q4 2021

6 of 34

Silver is not a �Silver Bullet

-John Kirkwood 2018

7 of 34

Draft Requirements: Design Principles

The Silver Design Principles are based on the requirements of WCAG 2.0 and build on those requirements to meet needs identified in the Silver research.

Silver Requirements Draft

8 of 34

Design Principles

Accessibility guidelines should:

Support the needs of the widest range of people with disabilities and recognize that people with disabilities have individual and intersectional needs.
Support a measurement and conformance structure that can include guidance for a broad range of disabilities, including low vision and cognitive accessibility needs.
Be flexible enough to support the needs of people with disabilities using emerging technologies.
Follow accessibility guidance.
Be written in plain language, as easy as possible to understand.

9 of 34

Design Principles

The creation process for the guidelines should:

Include people with disabilities and recognize that they are important contributors to accessibility standards and solutions.
Have global participation and feedback.
Strive to be data-informed and evidence-based.

10 of 34

Draft Requirements

Readability/Usability

Regulatory Environment

Motivation

Scope

Multiple ways to measure

Flexible structure

Multiple ways to display

Technology Neutral

3.1 Multiple ways to measure

Different guidance has potential for different measurement beyond a simple true false success criterion so that more needs of people with disabilities can be included.

3.2 Flexible structure

Create a structure for guidelines that can better meet the needs of people in unanticipated technologies and interactions.

3.3 Multiple ways to display

Make the guidelines available in different accessible and usable ways so the guidance can be customized by different audiences.

3.4 Technology Neutral

Guidelines are worded to apply across varied technologies and avoid being technology-specific. The intent of technology-neutral wording is to provide the opportunity to apply guidelines to current and emerging technology, even if the technical advice doesn't yet exist. Technical details are discoverable in the document structure but are not required to understand guidelines.

3.5 Readability/Usability

The guidelines are understandable by non-technical audience. Text and presentation are usable and understandable through the use of simple language, structure and design.

3.6 Regulatory Environment

The Guidelines provide broad support, including

structure and content that facilitates adoption into law, regulation, or policy, and
clear intent and transparency as to purpose and goals, to assist when there are questions or controversy.

3.7 Motivation

The use of the guidelines supports and motivates organizations to acknowledge gaps and strive to be more inclusive. The intent is to give organizations a path toward greater accessibility.

3.8 Scope

The guidelines provide guidance for content, authoring tools, user agents and browsers, and assistive technologies.

EDITOR'S NOTE

The group consensus was to avoid over-loaded terms like "content", "authoring tool" and "user agent". Given the understanding that AGWG has of these terms, we also agreed they were clear in a W3C context. We will look for better terms, but we can agree on the concepts.

11 of 34

Prototypes

Information Architecture

Plain Language

Conformance

Meaningful Involvement

12 of 34

What are we working on today?

Diversity of tools the Silver contributors can use. (It’s not all in Github)

Silver wiki has the latest links

Since May, we have worked on:

Requirements
Information Architecture
Plain Language
Conformance
Meaningful Involvement

13 of 34

Revolutionary Structure

Evolutionary Content

14 of 34

Information Architecture - goals

Usability

Organize the data in small snippets that can be coded and categorized so they can be assembled dynamically to meet the needs of the person looking for information.

Create a comprehensive view for W3C Technical Report purposes, and for those who need to view the total document.

Create a solution that addresses the needs of people to find information by role, problem, by disability, and by platform. How can people discover what they need to know?

Maintenance

Develop a core of rarely-changing requirements (normative) with modules of platform oriented advice, examples, tests, and support materials that can be updated as technology changes.

Develop a way for accessibility experts to contribute new content, such as design patterns, codes and tests, where the experts vote material up and down without waiting for working group approval.

Keep a changelog of all changes to the spec so it is easy for reviewers to find the changes.

15 of 34

Information Architecture

We aren’t losing content, we are restructuring
Flattening the overall structure

From Principle, Guidelines, Success Criteria and Techniques
To Guidelines and Methods

Guidelines are general information and intent written in plain language
Methods are specific examples, instructions, and tests with more technical information
We are adding a tagging engine to make it easier for people to find information.
There will be an API so people can extract the data to use for their own purposes.

16 of 34

How WCAG content moves to Silver

Principles -> tags. It allows us to add Principles, if appropriate
Guidelines and technology neutral Success Criteria -> Guidelines
Technology specific Success Criteria and Techniques -> Methods
Understanding becomes part of the long description of Guidelines or Methods. It will be broken up. Example: Use of Color would go toward a Guideline, but the examples are technology specific and would go to a Method.
Levels (A, AA, AAA) are deleted. Silver conformance levels will be overall for the product/project, not by Success Criteria.
Success Criteria numbers are deleted. Guidance will be known by a unique handle, so that Silver scales for new guidance. We will tag Guidelines and Methods with the WCAG 2.1 number, so it can easily be found.

17 of 34

Example of Success Criteria moving to Silver

Example: WCAG success criterion of Language of Page

3.1.1 becomes “Identify the human language of the environment for assistive technology.”

Example: WCAG success criterion of Parsing

4.1.1 moves to Methods, because it is markup-specific

18 of 34

Example of Principles becoming tags

Example: WCAG 2.1 guideline of Predictable would also be tagged under Perceivable and Operable because different Principles may apply to its Methods

Success Criterion 3.2.2 On Input

Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component.

Associated Tags: Perceivable, Operable, Understandable

19 of 34

Beyond Existing Web Content

Add new guidance

that was not able to be included in WCAG 2.1
In response to new technology (ex. Home automation)

Silver is not restricted to web content (so it needs a new name)
Silver will include advice for:

Browsers and user agents
Authoring tools and development frameworks
Assistive technology

That advice will probably be in the Methods.

20 of 34

Plain Language

21 of 34

Plain Language - goals

Usability

Take existing WCAG 2.1 guidance and rewrite it in plain language using editors with simple language or plain language experience. The existing success criteria may need to be updated, but most of WCAG 2.1 guidance is still valid. It needs more clarity, ease of reading and ease of translation.

Organize the data in small snippets that can be coded and categorized so they can be assembled dynamically to meet the needs of the person looking for information.

22 of 34

Plain Language

Experiment with 4 WCAG SCs - a number of plain language experts or editors were asked to rewrite 4 existing WCAG SCs. This is the raw results of that experiment.

Prototype with tabs to organize information - a prototype taking the most popular features of the different experiments with plain language. Keep in mind that some Success Criteria will become Methods and the levels are going away, which means that some Success Criteria can be combined. There will not be an exact one-to-one with the existing WCAG 2.1.

Style Guide - common rules for writing plain language adapted to writing for Silver.

23 of 34

Plain Language Example

Original

4.1.2 Name, Role, Value: For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies. (Level A)

Note: This success criterion is primarily for Web authors who develop or script their own user interface components. For example, standard HTML controls already meet this success criterion when used according to specification.

Translation

Name, Role, Value: Make interface semantics and actions accessible for assistive technology (formerly WCAG 4.1.2)

Summary

All interface semantics - annotations that help assistive technology know how to interact with your website or application - must be accessible for assistive technology by using Accessibility API conventions.

24 of 34

What this could look like in action

This prototype for plain language is the result of comparing the examples from the original plain language experiment and devising a format that includes and expands on the WCAG Understanding document.

25 of 34

Scoring & Conformance

How do I know I did it right? What’s my score?

26 of 34

Teasing Apart Conformance

Back when WCAG 2 was being conceived, W3C had strict conformance requirements for specifications. WCAG 2 has a conformance structure that combines W3C Conformance and regulatory needs.

Today, the W3C Conformance requirements are much more flexible, even optional. This gives the opportunity to design a new structure that allows more accessibility guidance to be included. We can focus on user and regulatory needs without being constrained by old W3C conformance requirements.

27 of 34

Conformance - goals

Design a conformance structure and style guides that shift emphasis from “testability” to “measureability”. Include guidance that is not conducive to a true/false test. True/ false tests can be included, but they are not the only way to measure conformance.

Develop a point and ranking system that will allow more nuanced measurement of the content or product: e.g. a bronze, silver, gold, platinum rating where the bronze rating represents the minimal conformance (roughly equivalent to meeting WCAG 2 AA), and increasing ranks include inclusive design principles, task-based assessment, and usability testing.

Develop scorecard or rubric measures for testing task accomplishment, instead of technical page conformance.

Include a definition and concept for “substantially meets” so people are not excessively penalized for bugs that may not have a large impact on the experience of people with disabilities.

Remove “accessibility supported” as an author responsibility and provide advice to authoring tools, browsers and assistive technology developers of the expected behaviors of their products.

Develop a more flexible method of claiming conformance that is better suited to accommodate dynamic or more regularly updated content.

28 of 34

Conformance Prototype

Allows for greater flexibility to reward desirable behavior for different types of products or projects.

Allows for tests that are more flexible than whether a Success Criteria passes/fails, like task completion tests, or testing with people with disabilities.

Removes levels from individual Success Criteria and allows for an overall measure of the product or project.

Point scoring works with the methods to assign points for achievement

29 of 34

User needs -> tests -> methods -> guidelines

Example of Language of Page (WCAG 3.1.1)

User need: People can use assistive technology in the language of the content or application.

Test Rules: (from Auto-WCAG)

HTML has lang attribute
HTML Lang And Xml:lang Match
Validity Of HTML Lang Attribute
Specified language matches reality�(to be written)

Methods

HTML tag has lang attribute
HTTP Response Header specifies language
VR environment has language specified
Content management system / Authoring Tool provides way of setting language

Guideline: Language of environment

Identify the human language of the environment for assistive technology.

This example shows a prototype of creating a new guideline from existing WCAG content. Language of Page is technically for a static web page in HTML, but could be rewritten as a new Guideline for Silver.

Generally, WCAG was written from the top down. We propose to build Silver from the ground up. We start with user needs, then figure out how to test it. We will use test rules standard to write both automated and manual tests. Once we have the tests, we can write the specific methods for each type of technology or platform. Once we have the Methods we can write the Guideline. It makes the guidelines more accurate and clear, and it may even reduce some of the testing costs by making it easier to create automated tests.

HTTP Response Header currently not supported by the User Agents. So this is an example of how we could provide guidance for User Agents.

30 of 34

Silver Conformance COULD look like...

WCAG & New

Task-based

Overall

True/False tests

Automated tests

Usability tests

Evaluation

Other metrics

Point Scoring System

Gold

Silver

Bronze�WCAG 2.x AA ?

Grade

Methods

Guidelines

31 of 34

People Game Systems

Human beings are good at “gaming” any system. People game WCAG. WCAG does not have transparent definitions of why something is in level A, level AA or level AAA. So how can we set up Silver to reduce the ability to “game the system” without making it too difficult to use? The point system is particularly vulnerable to pressure and influence. Silver will have a transparent “back end” to the point system to do the scoring. We have a group working on the scoring system formulas. Even though most people will never be interested in seeing it, it will be available to the public. It will be available and useful for legal purposes.

The following slides show how we can reduce people “gaming” the system to score points to support easier disabilities to serve and ignoring the needs of other disabilities because they are harder to accomplish.

32 of 34

Require Points in User Needs Categories

Usage without vision

Usage with limited vision

Usage without perception of colour

Usage without hearing

Usage with limited hearing

Usage without vocal capability

Usage with limited manipulation or strength

Usage with limited reach

Minimize photosensitive seizure triggers

Usage with limited cognition

Example taken from Mandate 376 Functional Performance Statements

33 of 34

Example: Point System with user needs

Category of User Need	Bronze Minimum	Silver Minimum	Gold Minimum
Usage without vision	30 pts	50 pts	100 pts
Usage with limited vision	35 pts	50 pts	75 pts
Usage without perception of color	10 pts	25 pts	30 pts
… Usage with limited cognition	30 pts	50 pts	100 pts

This is just a rough proposal. We think the lowest category determines the overall score, but we are still discussing it. The numbers are completely fictional to give an idea of how we think it would work. The numbers are different for each functional need area because we want the system to be flexible for future expansion. You score points in each area by the Methods you use. You add up the Methods in each category to see whether you meet Bronze, Silver or Gold level. Some members of the group are currently in favor of having minimum requirements, but allowing people to score a higher level with enough points. There isn’t strong consensus, however.

Potential issues we may need to address:

The more complex the website, the more difficult it is to do well (bias against complex websites?)
Highly specialized websites/apps/etc may inherently require people to have certain abilities that could be at odds with the standards (i.e., pilot training software that requires vision, Ph.D. coursework in filmmaking that requires color perception, professional websites that require certain levels of cognition) I can envision a lot of push-back from some entities that there is an unfair bias against them.
Cutting edge technology use - if the tech isn’t well supported yet, can it still be used without getting hurt in the point system? And does this hurt new development or somehow end up weakening the argument for accessibility? (bias against new tech?)

34 of 34

Questions?

goo.gl/6YKVH2

Shawn Lauriat & Jeanne Spellman