WCAG 3 Update
undefined
W
C
A
G
3
U
p
d
a
t
e
CSUN 2023
1
Speaker: Rachael Bradley Montgomery, PhD
●
Digital accessibility architect at the Library of Congress
●
Co-chair of the W3C Accessibility Guidelines Working
Group
●
Executive director of Accessible Community
●
Adjunct lecturer at University of Maryland’s College of
Information Studies (iSchool)
●
Affiliate faculty with the Trace Research and Development
Center
T
h
i
s
t
a
l
k
r
e
p
r
e
s
e
n
t
s
m
y
p
e
r
s
o
n
a
l
o
p
i
n
i
o
n
s
T
h
e
c
u
r
r
e
n
t
s
t
a
t
e
c
h
a
n
g
e
s
2
B
a
c
k
g
r
o
u
n
d
3
W
h
y
d
o
s
t
a
n
d
a
r
d
s
e
v
o
l
v
e
?
●
Standards evolve because they do not fully meet the needs
they were written to address
○
Technology changes
■
Mobile, touch screens, augmented reality, virtual reality
○
The need was not met fully in the first place
○
Experience and lessons learned over time help us develop a
more comprehensive standard
4
W
C
A
G
2
.
x
h
a
s
c
o
n
s
t
r
a
i
n
t
s
●
Testing occurs at the component or view level
○
Limited concepts of user process and “Set of
webpages”
●
Limited ability to test based on context (Example: English
vs. Hebrew)
●
Backward compatibility – Normative content is set
●
Limitation: “Everyone knows it when they see it” but
can’t test it within the 2.x framework
T
h
i
s
i
s
b
o
t
h
a
g
o
o
d
a
n
d
b
a
d
t
h
i
n
g
5
T
i
m
e
l
i
n
e
●
Late 2016/Early 2017: Silver Taskforce and Community Group Started
●
2017-2021
○
Research
○
Architecture Design
○
Requirements
○
Conformance Prototypes
○
Writing Process
●
First Public Working Draft Published January 2021
●
2021-2023 Revising approach based on feedback on draft
○
Increasing public review
○
Meet with regulators to get input on direction
●
2024 Approach to architecture, content, and conformance and schedule for completion
6
R
e
q
u
i
r
e
m
e
n
t
s
(
1
o
f
3
)
1
.
M
u
l
t
i
p
l
e
w
a
y
s
t
o
m
e
a
s
u
r
e
All WCAG 3.0 guidance has tests or procedures so that the results can be verified. In addition to
the current true/false success criteria, other ways of measuring (for example, rubrics, sliding scale,
task-completion, user research with people with disabilities, and more) can be used where
appropriate so that more needs of people with disabilities can be included.
2
.
F
l
e
x
i
b
l
e
m
a
i
n
t
e
n
a
n
c
e
a
n
d
e
x
t
e
n
s
i
b
i
l
i
t
y
Create a maintenance and extensibility model for guidelines that can better meet the needs of
people with disabilities using emerging technologies and interactions. The process of developing
the guidance includes experts in the technology.
3
.
M
u
l
t
i
p
l
e
w
a
y
s
t
o
d
i
s
p
l
a
y
Make the guidelines available in different accessible and usable ways or formats so the guidance
can be customized by and for different audiences. 703-777-5144
7
R
e
q
u
i
r
e
m
e
n
t
s
(
2
o
f
3
)
4
.
T
e
c
h
n
o
l
o
g
y
N
e
u
t
r
a
l
Guidance should be expressed in generic terms so that they may apply to more than one platform
or technology. The intent of technology-neutral wording is to provide the opportunity to apply the
core guidelines to current and emerging technology, even if specific technical advice doesn't yet
exist.
5
.
R
e
a
d
a
b
i
l
i
t
y
/
U
s
a
b
i
l
i
t
y
The core guidelines are understandable by a non-technical audience. Text and presentation are
usable and understandable through the use of plain language, structure, and design.
6
.
R
e
g
u
l
a
t
o
r
y
E
n
v
i
r
o
n
m
e
n
t
The Guidelines provide broad support, including:
▪
Structure, methodology, 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.
8
R
e
q
u
i
r
e
m
e
n
t
s
(
3
o
f
3
)
7
.
M
o
t
i
v
a
t
i
o
n
The Guidelines motivate organizations to go beyond minimal accessibility requirements by
providing a scoring system that rewards organizations which demonstrate a greater effort to
improve accessibility.
8
.
S
c
o
p
e
The guidelines provide guidance for people and organizations that produce digital assets and
technology of varying size and complexity. This includes large, dynamic, and complex websites.
Our intent is to provide guidance for a diverse group of stakeholders including content creators,
browsers, authoring tools, assistive technologies, and more.
9
H
o
w
t
o
P
a
r
t
i
c
i
p
a
t
e
i
n
t
h
e
W
C
A
G
3
P
r
o
c
e
s
s
10
E
d
i
t
o
r
’
s
v
s
.
W
o
r
k
i
n
g
D
r
a
f
t
s
●
The Working Draft is the draft used to request
comment from the public
●
The Editor’s Draft is the draft used for content that
is still being worked
●
Historically, there has been confusion about how
“final” content is within each of these drafts
11
M
a
t
u
r
i
t
y
L
e
v
e
l
s
1.
Placeholder:
Identify needs and possible directions
○
Likelihood to change:
Definite
○
Feedback Needed:
No feedback is needed on placeholder content
2.
Exploratory:
Document direction(s)
○
Likelihood to change:
Very likely
○
Feedback needed:
About the proposed direction
3.
Developing:
Work out details and address open questions
○
Likelihood to change:
Details likely to change, overall direction unlikely to change
○
Feedback needed: F
ocused on ensuring the sections are usable and reasonable in a broad sense.
4.
Refining:
Get wide stakeholder feedback
○
Likelihood to change:
Details may change, overall direction unlikely to change
○
Feedback needed:
Focused on the feasibility of testing and implementing
5.
Mature:
Refine and finalize
○
Likelihood to change:
Unlikely to change
○
Feedback needed:
Focused on edge case scenarios the working group may not have anticipated
At each step, the content
becomes increasingly
detailed and definite
12
W
a
y
s
t
o
G
i
v
e
F
e
e
d
b
a
c
k
●
File an issue in the W3C silver GitHub repository
○
https://github.com/w3c/silver/issues/new
●
Send email to
public-agwg-comments@w3.org
●
Please file one issue or send one email per change
●
This helps us to organize comments and respond more
effectively and quickly
13
B
e
c
o
m
i
n
g
a
W
o
r
k
i
n
g
G
r
o
u
p
P
a
r
t
i
c
i
p
a
n
t
●
If you work for a
W3C member company
, reach out to your
Advisory Committee (AC) representative
●
Becoming an invited expert
○
Contribute to a community group or through GitHub
○
We explore bringing in Invited Experts with a history of
contributions
●
Participate regularly through email, meetings and/or GitHub
14
D
i
r
e
c
t
i
o
n
w
e
a
r
e
E
x
p
l
o
r
i
n
g
(
C
o
n
t
e
n
t
a
f
t
e
r
t
h
i
s
i
s
n
o
t
f
i
n
a
l
)
15
F
u
n
c
t
i
o
n
a
l
N
e
e
d
s
i
n
W
C
A
G
3
●
A functional need is a statement that describes a specific gap in one’s
ability, or a specific mismatch between ability and the designed
environment or context
●
Early design identified need for functional needs
●
Aim is to ensure we provide coverage for more user groups
●
A subgroup of the silver task force documented the initial set of
functional needs and user needs
●
This year we moved that group to the APA working group
●
The Framework for Accessible Specification of Technologies (FAST) aims
to inform W3C technology development with the same set of needs
●
Editors’ draft of FAST
https://w3c.github.io/fast/
16
F
u
n
c
t
i
o
n
a
l
N
e
e
d
s
(
1
/
2
)
●
The functional needs are grouped
into major categories
○
Safety
○
Sensory
○
Physical
○
Cognitive
○
Independence
●
Most of these categories also
have sub groupings, shown in the
examples
●
Sensory
○
Vision and visual
○
Hearing and auditory
●
Cognitive
○
Attention
○
Language and communication
○
Learning
○
Executive
○
Mental health
●
Physical
○
Mobility
○
Motor
○
Speech
17
F
u
n
c
t
i
o
n
a
l
N
e
e
d
s
(
2
/
2
)
●
Each category lists needs that
need to be met for content to be
accessible
●
“Use without …” and “Use with
limited …” are common patterns
●
Intersections describe
requirements arising from a
combination of functional needs,
where those requirements aren’t
present for those needs in
isolation
●
Needs for vision and visual:
○
use without vision
○
use with limited vision
○
use with limited colour perception
○
use with limited depth perception
○
use with photosensitivity
●
Sensory intersections
○
Use without vision and hearing
○
Use with vestibular issues
○
Use without spatial auditory awareness or
perception
18
S
t
r
u
c
t
u
r
e
f
o
r
t
h
e
W
C
A
G
3
.
0
●
Guidelines - High-level, plain-language versions of content. (Informative)
○
Guidelines support one or more Functional Needs
●
Outcomes - written as testable criteria (Normative)
○
Outcomes support one or more Guidelines (ideally many to 1, but likely not possible)
○
Outcomes have an “And” between them (must meet all the outcomes)
●
Assertions - A formal claim of fact, attributed to a person or organization
●
Methods - technology specific ways to meet and test Outcomes (ideally many to 1)
○
Each method is sufficient
○
Methods include scope tested (component, view, user processes, aggregate)
○
Methods have an “Or” between them (choose the appropriate method)
●
Test Sets - Unique combination of tests that is sufficient to meet the Outcome
○
Test Sets may include different types of tests
○
Test Sets will include tests that pass, better, and exemplars
19
A
s
s
e
r
t
i
o
n
s
●
Attributable and documented statement of fact regarding
procedures practiced in the development and maintenance of the
content or product to improve accessibility
●
Tests that the assertion has been made correctly - not that any
desired result has occurred.
●
WCAG 3 would recommend supporting documentation that an
organization can use to improve or validate procedures and
assertions.
○
Conforming will not require this supporting documentation be made
public.
20
S
c
o
p
e
s
f
o
r
T
e
s
t
i
n
g
●
Items
○
Smallest testable unit
○
Interactive components (drop down menu, link, media player, etc.)
○
Content (word, phrase, label, error message, image, etc.)
●
Views
○
All content visually and programmatically available without a substantive change
○
Conceptually, views correspond to the definition of a web page as used in WCAG 2.X, but are not
restricted to content meeting that definition.
○
View could be considered a "screen" in a mobile app or a layer of web content (Modal)
●
User processes
○
Series of user actions, and views and items that support the actions
○
Each action is required in order to complete an activity
○
User process may include a subset of items in a view or a group of views
●
Aggregate
○
Combination of items, views, and user processes
21
G
u
i
d
e
l
i
n
e
L
i
s
t
(
P
l
a
c
e
h
o
l
d
e
r
)
●
The site or app aids navigation
●
Contents use sufficient contrast and do not rely
on color alone
●
User processes prevent users from making
mistakes
●
Users have ability to control audio, movement,
and auto updating
●
Views have structure that helps user orient and
navigate
●
Images and graphics have non-visual alternatives
●
Controls have correct semantic markup
●
Controls have clear purpose
●
Content uses clear language
●
On-screen motion does not cause harm
●
Video and audio have alternatives
●
Contents are programmatically and visually
ordered
22
●
The site or app supports the keyboard
●
Appearance of controls and focus support
keyboard and pointer use
●
The site or app supports mobile and pointer
inputs
●
The site or app minimizes the impact of
timing and interruptions
●
The site or app does not cause harm
●
User processes do not increase cognitive load
●
The site or app has a consistent design
●
Views are flexible
●
Controls notify users when making mistakes
●
Text uses appropriate layout and semantics
●
The site or app provides help
T
e
s
t
s
(
E
x
p
l
o
r
a
t
o
r
y
)
●
Quantifiable (Computational)
○
Tests where results will not vary based on the tester or approach.
○
Testing whether certain properties exist in the content or if they match a value specified by the
requirement.
○
Example
: Image has non-empty accessible name
●
Qualitative
○
Tests that rely on a qualitative evaluation based on existing criteria.
○
Test results may vary between testers who understand the criteria.
○
Evaluating the quality and applicability of certain properties of the content.
○
Example:
Image text alternative is equivalent
●
Conditions
○
Some tests only apply in certain situations.
○
Both Quantitative and Qualitative tests can be conditional
○
Example:
If content is in Hebrew, all diacritics and letters are included
23
L
e
v
e
l
s
a
n
d
P
e
r
c
e
n
t
a
g
e
s
(
E
x
p
l
o
r
a
t
o
r
y
)
●
Some Outcomes and Assertions are required
●
Other Outcomes and Assertions are optional
●
Bronze - Minimum level of conformance.
○
All required outcomes and assertions must be passed
●
Silver - More accessible
○
Bronze plus % of additional outcomes and assertions
●
Gold - exceptional efforts
○
Bronze plus larger % of additional outcomes and assertions
24
P
r
e
r
e
q
u
i
s
i
t
e
s
/
P
r
e
c
o
n
d
i
t
i
o
n
s
(
B
e
i
n
g
D
i
s
c
u
s
s
e
d
)
●
Tests or criteria recommended to implementers before assessing conformance
●
Use
○
Not a conformance level
○
Help implementers prepare for conformance testing
○
Assess readiness for an accessibility project.
○
Tool by implementers to assess tools or platforms they intend to use
●
Example 1: Video and audio have alternatives
○
Platform being tested has the ability to:
○
Generate captions
○
Display subtitles/captions when provided (i.e. can I upload an SRT file)
○
Attach a transcript
○
Support multiple audio tracks
●
Example 2: Images and graphics have non-visual alternatives
○
All non-text elements have an accessible name
25
M
a
t
r
i
x
M
o
d
e
l
(
B
e
i
n
g
D
i
s
c
u
s
s
e
d
)
A way to address changes in technology and evolve the standard systematically over time
As outcomes become more testable and achievable, they move from Gold to Bronze
26
O
t
h
e
r
C
o
n
c
e
p
t
s
B
e
i
n
g
D
i
s
c
u
s
s
e
d
●
Stackable Outcomes – Consolidating all related outcomes
in a single location to encourage adopt
●
Adjectival Ratings – Using a 1-5 scale instead of or in
addition to pass/fail
●
Issue Severity – Can issues be ranked less critical than
others?
27
T
a
k
e
A
w
a
y
s
●
WCAG 2.2 is almost out, WCAG 3 is in process
●
Continue using WCAG 2.x until WCAG 3 is complete
●
We want your feedback!
●
You can follow the newest work in the editor’s draft and the
more mature content in the working draft
●
Pay attention to the maturity level of material
●
Use GitHub or email to send us feedback
●
Slides will be available at whollyaccessible.org
28
The evolving WCAG 3.0 standards and their impact on digital accessibility. Learn about the reasons behind standards evolution, constraints of WCAG 2.x, timeline, requirements, and more.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
WCAG 3 Update WCAG 3 Update CSUN 2023 1
Speaker: Rachael Bradley Montgomery, PhD Digital accessibility architect at the Library of Congress Co-chair of the W3C Accessibility Guidelines Working Group Executive director of Accessible Community Adjunct lecturer at University of Maryland s College of Information Studies (iSchool) Affiliate faculty with the Trace Research and Development Center This talk represents my personal opinions The current state changes 2
Background Background 3
Why do standards evolve? Why do standards evolve? Standards evolve because they do not fully meet the needs they were written to address Technology changes Mobile, touch screens, augmented reality, virtual reality The need was not met fully in the first place Experience and lessons learned over time help us develop a more comprehensive standard 4
WCAG 2.x has constraints WCAG 2.x has constraints Testing occurs at the component or view level Limited concepts of user process and Set of webpages Limited ability to test based on context (Example: English vs. Hebrew) Backward compatibility Normative content is set Limitation: Everyone knows it when they see it but can t test it within the 2.x framework This is both a good and bad thing 5
Timeline Timeline Late 2016/Early 2017: Silver Taskforce and Community Group Started 2017-2021 Research Architecture Design Requirements Conformance Prototypes Writing Process First Public Working Draft Published January 2021 2021-2023 Revising approach based on feedback on draft Increasing public review Meet with regulators to get input on direction 2024 Approach to architecture, content, and conformance and schedule for completion 6
Requirements (1 of 3) Requirements (1 of 3) 1. Multiple ways to measure All WCAG 3.0 guidance has tests or procedures so that the results can be verified. In addition to the current true/false success criteria, other ways of measuring (for example, rubrics, sliding scale, task-completion, user research with people with disabilities, and more) can be used where appropriate so that more needs of people with disabilities can be included. 2. Flexible maintenance and extensibility Create a maintenance and extensibility model for guidelines that can better meet the needs of people with disabilities using emerging technologies and interactions. The process of developing the guidance includes experts in the technology. 3. Multiple ways to display Make the guidelines available in different accessible and usable ways or formats so the guidance can be customized by and for different audiences. 703-777-5144 7
Requirements (2 of 3) Requirements (2 of 3) 4. Technology Neutral Guidance should be expressed in generic terms so that they may apply to more than one platform or technology. The intent of technology-neutral wording is to provide the opportunity to apply the core guidelines to current and emerging technology, even if specific technical advice doesn't yet exist. 5. Readability/Usability The core guidelines are understandable by a non-technical audience. Text and presentation are usable and understandable through the use of plain language, structure, and design. 6. Regulatory Environment The Guidelines provide broad support, including: Structure, methodology, 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. 8
Requirements (3 of 3) Requirements (3 of 3) 7. Motivation The Guidelines motivate organizations to go beyond minimal accessibility requirements by providing a scoring system that rewards organizations which demonstrate a greater effort to improve accessibility. 8. Scope The guidelines provide guidance for people and organizations that produce digital assets and technology of varying size and complexity. This includes large, dynamic, and complex websites. Our intent is to provide guidance for a diverse group of stakeholders including content creators, browsers, authoring tools, assistive technologies, and more. 9
How to Participate in the WCAG 3 Process How to Participate in the WCAG 3 Process 10
Editors vs. Working Drafts Editor s vs. Working Drafts The Working Draft is the draft used to request comment from the public The Editor s Draft is the draft used for content that is still being worked Historically, there has been confusion about how final content is within each of these drafts 11
Maturity Levels Maturity Levels 1. Placeholder: Identify needs and possible directions At each step, the content becomes increasingly detailed and definite Likelihood to change: Definite Feedback Needed: No feedback is needed on placeholder content 2. Exploratory: Document direction(s) Likelihood to change: Very likely Feedback needed: About the proposed direction 3. Developing: Work out details and address open questions Likelihood to change: Details likely to change, overall direction unlikely to change Feedback needed: Focused on ensuring the sections are usable and reasonable in a broad sense. Refining: Get wide stakeholder feedback 4. Likelihood to change: Details may change, overall direction unlikely to change Feedback needed: Focused on the feasibility of testing and implementing Mature: Refine and finalize 5. Likelihood to change: Unlikely to change Feedback needed: Focused on edge case scenarios the working group may not have anticipated 12
Ways to Give Feedback Ways to Give Feedback File an issue in the W3C silver GitHub repository https://github.com/w3c/silver/issues/new Send email to public-agwg-comments@w3.org Please file one issue or send one email per change This helps us to organize comments and respond more effectively and quickly 13
Becoming a Working Group Participant Becoming a Working Group Participant If you work for a W3C member company, reach out to your Advisory Committee (AC) representative Becoming an invited expert Contribute to a community group or through GitHub We explore bringing in Invited Experts with a history of contributions Participate regularly through email, meetings and/or GitHub 14
Direction we are Exploring Direction we are Exploring (Content after this is not final) (Content after this is not final) 15
Functional Needs in WCAG 3 Functional Needs in WCAG 3 A functional need is a statement that describes a specific gap in one s ability, or a specific mismatch between ability and the designed environment or context Early design identified need for functional needs Aim is to ensure we provide coverage for more user groups A subgroup of the silver task force documented the initial set of functional needs and user needs This year we moved that group to the APA working group The Framework for Accessible Specification of Technologies (FAST) aims to inform W3C technology development with the same set of needs Editors draft of FAST https://w3c.github.io/fast/ 16
Functional Needs (1/2) Functional Needs (1/2) Sensory The functional needs are grouped into major categories Safety Sensory Physical Cognitive Independence Most of these categories also have sub groupings, shown in the examples Vision and visual Hearing and auditory Cognitive Attention Language and communication Learning Executive Mental health Physical Mobility Motor Speech 17
Functional Needs (2/2) Functional Needs (2/2) Each category lists needs that need to be met for content to be accessible Use without and Use with limited are common patterns Intersections describe requirements arising from a combination of functional needs, where those requirements aren t present for those needs in isolation Needs for vision and visual: use without vision use with limited vision use with limited colour perception use with limited depth perception use with photosensitivity Sensory intersections Use without vision and hearing Use with vestibular issues Use without spatial auditory awareness or perception 18
Structure for the WCAG 3.0 Structure for the WCAG 3.0 Guidelines - High-level, plain-language versions of content. (Informative) Guidelines support one or more Functional Needs Outcomes - written as testable criteria (Normative) Outcomes support one or more Guidelines (ideally many to 1, but likely not possible) Outcomes have an And between them (must meet all the outcomes) Assertions - A formal claim of fact, attributed to a person or organization Methods - technology specific ways to meet and test Outcomes (ideally many to 1) Each method is sufficient Methods include scope tested (component, view, user processes, aggregate) Methods have an Or between them (choose the appropriate method) Test Sets - Unique combination of tests that is sufficient to meet the Outcome Test Sets may include different types of tests Test Sets will include tests that pass, better, and exemplars 19
Assertions Assertions Attributable and documented statement of fact regarding procedures practiced in the development and maintenance of the content or product to improve accessibility Tests that the assertion has been made correctly - not that any desired result has occurred. WCAG 3 would recommend supporting documentation that an organization can use to improve or validate procedures and assertions. Conforming will not require this supporting documentation be made public. 20
Scopes for Testing Scopes for Testing Items Smallest testable unit Interactive components (drop down menu, link, media player, etc.) Content (word, phrase, label, error message, image, etc.) Views All content visually and programmatically available without a substantive change Conceptually, views correspond to the definition of a web page as used in WCAG 2.X, but are not restricted to content meeting that definition. View could be considered a "screen" in a mobile app or a layer of web content (Modal) User processes Series of user actions, and views and items that support the actions Each action is required in order to complete an activity User process may include a subset of items in a view or a group of views Aggregate Combination of items, views, and user processes 21
Guideline List (Placeholder) Guideline List (Placeholder) The site or app aids navigation Contents use sufficient contrast and do not rely on color alone User processes prevent users from making mistakes Users have ability to control audio, movement, and auto updating Views have structure that helps user orient and navigate Images and graphics have non-visual alternatives Controls have correct semantic markup Controls have clear purpose Content uses clear language On-screen motion does not cause harm Video and audio have alternatives Contents are programmatically and visually ordered The site or app supports the keyboard Appearance of controls and focus support keyboard and pointer use The site or app supports mobile and pointer inputs The site or app minimizes the impact of timing and interruptions The site or app does not cause harm User processes do not increase cognitive load The site or app has a consistent design Views are flexible Controls notify users when making mistakes Text uses appropriate layout and semantics The site or app provides help 22
Tests (Exploratory) Tests (Exploratory) Quantifiable (Computational) Tests where results will not vary based on the tester or approach. Testing whether certain properties exist in the content or if they match a value specified by the requirement. Example: Image has non-empty accessible name Qualitative Tests that rely on a qualitative evaluation based on existing criteria. Test results may vary between testers who understand the criteria. Evaluating the quality and applicability of certain properties of the content. Example: Image text alternative is equivalent Conditions Some tests only apply in certain situations. Both Quantitative and Qualitative tests can be conditional Example: If content is in Hebrew, all diacritics and letters are included 23
Levels and Percentages (Exploratory) Levels and Percentages (Exploratory) Some Outcomes and Assertions are required Other Outcomes and Assertions are optional Bronze - Minimum level of conformance. All required outcomes and assertions must be passed Silver - More accessible Bronze plus % of additional outcomes and assertions Gold - exceptional efforts Bronze plus larger % of additional outcomes and assertions 24
Prerequisites/ Preconditions (Being Discussed) Prerequisites/ Preconditions (Being Discussed) Tests or criteria recommended to implementers before assessing conformance Use Not a conformance level Help implementers prepare for conformance testing Assess readiness for an accessibility project. Tool by implementers to assess tools or platforms they intend to use Example 1: Video and audio have alternatives Platform being tested has the ability to: Generate captions Display subtitles/captions when provided (i.e. can I upload an SRT file) Attach a transcript Support multiple audio tracks Example 2: Images and graphics have non-visual alternatives All non-text elements have an accessible name 25
Matrix Model (Being Discussed) Matrix Model (Being Discussed) A way to address changes in technology and evolve the standard systematically over time As outcomes become more testable and achievable, they move from Gold to Bronze Testable Assertions Organizational Practices Easy to implement Bronze Some Bronze Some Silver Some Silver More difficult to implement Some Bronze Some Silver Some Bronze Some Silver Some Silver Some Gold Difficult or cost prohibitive to implement Gold Gold Gold 26
Other Concepts Being Discussed Other Concepts Being Discussed Stackable Outcomes Consolidating all related outcomes in a single location to encourage adopt Adjectival Ratings Using a 1-5 scale instead of or in addition to pass/fail Issue Severity Can issues be ranked less critical than others? 27
Take Aways Take Aways WCAG 2.2 is almost out, WCAG 3 is in process Continue using WCAG 2.x until WCAG 3 is complete We want your feedback! You can follow the newest work in the editor s draft and the more mature content in the working draft Pay attention to the maturity level of material Use GitHub or email to send us feedback Slides will be available at whollyaccessible.org 28
