Introducing WCAG 2.2

Bill Tyler
Principal Digital Accessibility Engineer
UXDS Accessibility Center of Excellence, Optum Digital
A11y TC Meetup
July 26, 2021
1
Introducing WCAG 2.2

Agenda
Overview
• Current status
• Goals
• Changes
Meet the new criteria
• Overview
• Actual text
What next?
• WCAG 2.2 steps
• What should you do?
Confidential property of Optum. Do not distribute or reproduce without express permission from Optum. 2

WCAG 2.2 status
Second update of WCAG 2.0 (December 2008)
• First update: WCAG 2.1 (June 2018)
Became Official W3C Recommendation: November 2020, June 2021
• Should be released: September 2021, November 2021?
Latest working draft: May 21, 2021
• Latest editor’s draft: July 16, 2021

WCAG 2.2 goals
Address gaps in WCAG 2.0 2.1
Specifically in the areas of:
• Mobile devices
• Cognitive
• Low vision
• Mobility

WCAG 2.2 changes – in latest working draft
9 new success criteria
• 4 Level A
• 4 Level AA
• 1 Level AAA
One success criterion promoted from Level AA to A
Mostly stable, but still subject to change
• Criteria may be withdrawn/removed
• Levels may change
• Details may change
− Criteria text
− Understanding Documents

Implications of new criteria
Several are confusing to interpret as currently written
Some will not apply to most sites or pages
Overall, they should not be of great concern if reviewed and planning made for adoption

Role ownership of A and AA criteria
5 User Experience (UX) Designer
2 Visual Designer
1 Content Author
• A couple may have significant business implications

9 new WCAG 2.2 success criteria
SC2.4.11 Focus Appearance (Minimum) (Level AA)
SC2.4.12 Focus Appearance (Enhanced) (Level AAA)
SC2.4.13 Page Break Navigation (Level A)
SC2.5.7 Dragging Movements (Level AA)
SC2.5.8 Target Size (Minimum) (Level AA)
SC3.2.6 Consistent Help (Level A)
SC3.2.7 Visible Controls (Level AA)
SC3.3.7 Accessible Authentication (Level A)
SC3.3.8 Redundant Entry (Level A)

The other change: SC2.4.7 Visible Focus promoted to Level A
Was Currently is AA
• Making room for more keyboard focus success criteria
Core success criteria unchanged from WCAG 2.0
• Number
• Criterion text
Understanding document may have minimal changes
• May add references to new visible focus criteria

SC2.4.11 Focus Appearance (Minimum) (Level AA)
Addresses major omissions related to keyboard focus
• WCAG 2.0 / SC2.4.7 Visible Focus: Only needed to be “visible”
• WCAG 2.1 / SC1.4.11 Non-text Contrast : Added contrast requirement
• Still didn’t provide clear requirements on how it should be made visible
Analysis suggested visible focus influenced by
1. Change of color or contrast from original presentation
2. Size and/or thickness of the change
3. Difference of the color or contrast from surrounding colors
These appear in the new criteria requirements and options

SC2.4.11 Focus Appearance (Minimum) (Level AA) Continued…
3:1 Contrast for
• Element in both focus and unfocused states
• Adjacent to element in focused component, or is at least 2 CSS pixels thick
Minimum area/size of focus
• Outline Area: 1 CSS pixel thick perimeter, or
• Shape requirements
− Minimum 4 CSS pixel thick line on shortest side of minimum bounding box (unfocused)
− No thinner than 2 CSS pixels
Not fully obscured by author-created content (such sticky header or footer cases)
Understanding document also covers
• Unusual shapes
• Gradients

SC2.4.11 Focus Appearance (Minimum) (Level AA) continued again…
Yes, it is rather complicated
• Implementation may be best handled by specifying simple outline with good contrast for
all focusable elements
• SC2.4.12 does make it simpler
Roles to involve
• Primary owner: Visual Designer
• Others?: UX Designer

SC2.4.11 Focus Appearance (Minimum) (Level AA) – Working Draft
W3C® is a trademark (registered in numerous countries) of
the World Wide Web Consortium; marks of W3C are
registered and held by its host institutions MIT, ERCIM, Keio,
and Beihang.
When user interface components receive keyboard focus, all of the following are true:
• [SC2.4.11rA] Contrasting area: There is an area of the focus indicator that has a contrast ratio of at
least 3:1 between the colors in the focused and unfocused states.
• [SC2.4.11rB] Minimum area: The contrasting area is at least as large as:
• [SC2.4.11o1] Outline: the area of a 1 CSS pixel thick perimeter of the unfocused component, or
• [SC2.4.11o2] Shape: the area of a 4 CSS pixel thick line along the shortest side of a minimum
bounding box of the unfocused component, and no thinner than 2 CSS pixels.
• [SC2.4.11rC] Adjacent contrast: The contrasting area also has [SC2.4.11o3] a contrast ratio of least
3:1 against adjacent colors in the focused component, or [SC2.4.11o4] the contrasting area has a
thickness of at least 2 CSS pixels.
• [SC2.4.11rD] Not fully obscured: The item with focus is not entirely hidden by author-created
content.
Notes
• A keyboard focus indicator which has a pattern or gradient may have parts that do not meet the 3:1
contrast ratio for the change of contrast, as long as an area equal to the minimum does meet the
contrast ratio.
• If the component has a visible boundary smaller than the hit area, or the size of the component is not
available, the minimum area can be taken from the visible boundary.
Source: WCAG 2.2 Working Draft 5/21/2021: https://www.w3.org/WAI/WCAG22/Understanding/focus-appearance-minimum.html

SC2.4.12 Focus Appearance (Enhanced) (Level AAA)
SC2.4.12 is SC2.4.11 upgraded
• Contrast levels increased to 4.5:1
− Similar to SC1.4.3 Contrast (Minimum) without large text exception
• Double the area of a 1-pixel perimeter
• Not obscured
• Adjacent contrast follows SC2.4.11 (AA)
Understanding document not as complete as SC2.4.11
At Level AAA it will be generally ignored
Roles to involve

SC2.4.12 Focus Appearance (Enhanced) (Level AAA)– Working Draft
When user interface components have keyboard focus, all of the
following are true:
• [SC2.4.12rA] Contrasting area: There is an area of the focus
indicator that has a contrast ratio of at least 4.5:1 between the
colors in the focused and unfocused states.
• [SC2.4.12rB] Minimum area: The contrasting area is at least
double the area of a 1 CSS pixel perimeter of the unfocused
component;
• [SC2.4.12rC] Not obscured: No part of the focus indicator is
hidden by author-created content.
Source: WCAG 2.2 Working Draft 5/21/2021: https://www.w3.org/WAI/WCAG22/Understanding/focus-appearance-enhanced.html

SC2.4.13 Page Break Navigation (Level A)
Intended to ensure page number references are available for AT users
Complicated by the WCAG-ese term “page break locators”
programmatic markers that are arranged in a meaningful sequence to determine the location of a page in
relation to others in the set.
Requires page navigation if content is based on pages
• Essentially visible page numbers you can navigate to
Mainly for ePubs and PDFs
• Not typically applicable to web pages
Will mostly impact online versions of physical documents
Roles to involve
• Primary owner: Content Author
• Others?: UX Designer (especially for web), any roles to involve creating ePubs, PDFs

SC2.4.13 Page Break Navigation (Level A) – Working Draft
For web content with page break locators, a mechanism is available
to navigate to each locator.
Source: WCAG 2.2 Working Draft 5/21/2021: https://www.w3.org/WAI/WCAG22/Understanding/page-break-navigation.html

SC2.5.7 Dragging Movements (Level AA)
Addresses long-standing gap in WCAG 2.0 – and 2.1
• Explicitly requires dragging have single pointer alternative
Simple criterion similar to those added in WCAG 2.1
• Treats dragging like other gestures
− Building on SC2.5.1 Pointer Gestures (A)
Roles to involve
• Primary owner: UX Designer
• Others?: Developer, Visual Designer

SC2.5.7 Dragging Movements (Level AA) – Working Draft
All functionality that uses a dragging movement for operation can be
achieved by a single pointer without dragging, [SC2.5.7xA] unless
dragging is essential.
Notes
• This requirement applies to web content that interprets pointer
actions (i.e. this does not apply to actions that are required to
operate the user agent or assistive technology).
Source: WCAG 2.2 Working Draft 5/21/2021: https://www.w3.org/WAI/WCAG22/Understanding/dragging-movements.html

SC2.5.8 Target Size (Minimum) (Level AA)
Addresses gap in WCAG 2.1
• SC2.5.5 Target Size (last minute) change to AAA
− Due to input about tight editing controls and lost content on zoomed screens
Awkward addition
• SC2.5.5 “Target Size” renamed “Target Size (Enhanced)”
• SC2.5.8 “minimum” follows its “enhanced” sibling
Went through many rewrites
Essentially “junior” 24px version of SC2.5.5
• SC2.5.5 leveraged common mobile touch-based UX standards
• SC2.5.8 may be new compromise for mouse-based UX

SC2.5.8 Target Size (Minimum) (Level AA) continued…
Details may become design arguments
• 24x24px in size and/or spacing (target offsets)
− Meaning smaller icons spaced in 24px grid [SC2.5.8xA]
• Inline text links get exception [SC2.5.8xB]
• No equivalent (secondary) target exception [SC2.5.5x1]
• Menus and lists (bulleted and numbered) do not!
• Essential exception (such as map pins) [SC2.5.8xC]
Roles to involve

SC2.5.8 Target Size (Minimum) (Level AA) – Working Draft
Targets have an area of at least 24 by 24 CSS pixels, except where:
• [SC2.5.8xA] Spacing: The target offset is at least 24 CSS pixels
to every adjacent target;
• [SC2.5.8xB] Inline: The target is in a sentence or block of text;
• [SC2.5.8xC] Essential: A particular presentation of the target is
essential to the information being conveyed.
Notes
• Targets that allow for values to be selected spatially based on
position within the target are considered one target for the
purpose of the success criterion. Examples include sliders with
granular values, color pickers displaying a gradient of colors, or
editable areas where you position the cursor.
Source: WCAG 2.2 Working Draft 5/21/2021: https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html

SC3.2.6 Consistent Help (Level A)
Intended to ensure that when help is available for completing complex tasks it is in the
same location
Builds/extends SC3.2.3 Consistent Navigation to help features that may not be present on
all pages
Allows for repositioning on responsive layouts
• Mobile location does not have to match desktop or tablet
Understanding document suggests, but does not require, help be provided on website
Roles to involve
• Other?: Visual Designer

SC3.2.6 Consistent Help (Level A) – Working Draft
For each web page within a set of web pages that provides one or
more of the following ways of finding help, access to at least one
form of help is included in the same relative order on each page:
• [SC3.2.6oA] Human contact details;
• [SC3.2.6oB] Human contact mechanism;
• [SC3.2.6oC] Self-help option;
• [SC3.2.6oD] A fully automated contact mechanism.
Notes
• Access to help mechanisms may be provided directly on the page,
or may be provided via a direct link to a different page containing
the information.
Source: WCAG 2.2 Working Draft 5/21/2021: https://www.w3.org/WAI/WCAG22/Understanding/consistent-help.html

SC3.2.7 Visible Controls (Level AA)
Addresses gap in SC1.4.13 Content on Hover or Focus
Extends it to interactive controls like menus and toolbars
• May be off-screen when magnified
• May not require hover
Unlike SC1.4.13 has exceptions for controls
• Equivalent visible control on page [SC3.2.7xA]
• Keyboard navigation, such as skip links [SC3.2.7xB]
• Can be made persistent [SC3.2.7xC]
• Essential, such as required for game [SC3.2.7xD]

SC3.2.7 Visible Controls (Level AA) continued…
Likely only to affect rich applications
Roles to involve
• Others?: Visual Designer

SC3.2.7 Visible Controls (Level AA) – Working Draft
Where receiving pointer hover or keyboard focus triggers user interface components
to be visible, information needed to identify that user interface components are
available is visible, except when:
• [SC3.2.7xA] The information needed to identify the user interface components is
available through an equivalent component that is visible on the same page or on
a different step in a multi-step process without requiring pointer hover or keyboard
focus;
• [SC3.2.7xB] The component is provided specifically to enhance the experience for
keyboard navigation;
• [SC3.2.7xC] A mechanism is available to make the information persistently
visible;
• [SC3.2.7xD] Hiding the information needed to identify the component is essential.
Notes
• User interface components can be available through other visible components such
as sub-menus, edit buttons, tabs, or thumbnails of media.
Source: WCAG 2.2 Working Draft 5/21/2021: https://www.w3.org/WAI/WCAG22/Understanding/visible-controls.html

SC3.3.7 Accessible Authentication (Level A)
Potentially troublesome criterion for secure sites
Explicitly lists remembering usernames and passwords as cognitive function test
“Loophole:” Meeting criterion may reduce to NOT disabling copy/paste or preventing
password managers
• Inherent expectation that password management is a COGA standard approach
Other methods include WebAuthn (device-based), OAuth, and YubiKey
Final recommendation and understanding documents will need to preserve “loophole”
Roles to involve
• Others?: Possibly Developer, Business Owner

SC3.3.7 Accessible Authentication (Level A) – Working Draft
For each step in an authentication process that relies on a cognitive
function test, [SC3.3.7oA] at least one other authentication
method is available that does not rely on a cognitive function test, or
[SC3.3.7oB] a mechanism is available to assist the user in
completing the cognitive function test.
Notes
Examples of mechanisms include:
1. support for password entry by password managers to address
the memorization cognitive function test, and
2. copy and paste to help address transcription cognitive function
test.
Source: WCAG 2.2 Working Draft 5/21/2021: https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication.html

SC3.3.8 Redundant Entry (Level A)
All about re-entering data a second time in a process, if done at all
Should not significantly impact most web applications
Primary options
• Leverage auto-population and auto-fill [SC3.3.8oA]
Duplicating SC1.3.5 Identify Input Purpose
• Re-selection [SC3.3.8oB]
Exceptions cover most common cases
• Content security [SC3.3.8xB]
• Outdated or invalid data [SC3.3.8xC]
• Essential re-entry [SC3.3.8xA]
Roles to involve
• Others?: Business owner

SC3.3.8 Redundant Entry (Level A) – Working Draft
Information previously entered by or provided to the user that is
required to be entered again in the same process and in the same
user-session is either:
• [SC3.3.8oA] auto-populated, or
• [SC3.3.8oB] available for the user to select.
Except when:
• [SC3.3.8xA] re-entering the information is essential,
• [SC3.3.8xB] the information is required to ensure the security of
the content, or
• [SC3.3.8xC] previously entered information is no longer valid.
Source: WCAG 2.2 Working Draft 5/21/2021: https://www.w3.org/WAI/WCAG22/Understanding/redundant-entry.html

What’s next?
The W3C working group has to make WCAG 2.2 an official recommendation
• You can make comments
• Otherwise it’s still a work in progress and not actionable
The recommendation should come this fall
• September is the latest plan
• November is a possibility

When it becomes a recommendation, what happens?
Lessons from WCAG 2.1 release
WCAG 2.1 in laws and regulations
• Little or nothing: not currently required in US Sect. 508
• Eventually required: EU EN 301 549 phased WCAG 2.1 in over past few years
• Immediate: Update might be considered “implicit” as Sect. 1557 of Affordable Care Act
WCAG 2.1 in litigation and lawsuits
• Now the common standard in most new accessibility lawsuits (after a few years)
WCAG 2.1 impact on future standards
• WCAG 2.1 was step to WCAG 2.2
• WCAG 2.2 will be in WCAG 3.0

What should I do?
Plan, based upon your current response to WCAG 2.1
Start assessing potential impacts to your websites and applications
• If appropriate become more familiar with new level A and AA success criteria, now
Watch for official recommendation this fall
• Look for changes to confirm
Were some removed?
Did any become AAA?
Were there any significant final edits to the criteria text?
• Review the understanding documents
NOTE: These may not be “final,” though the criteria are will be.
Your current WCAG 2.1 requirements and standards may guide you on how to manage WCAG 2.2

Thank you.
Contact information:
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Bill Tyler
Principal Digital Accessibility Engineer
https://www.linkedin.com/in/billtyler/
btyler@optum.com

Introducing WCAG 2.2

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Introducing WCAG 2.2

Similar to Introducing WCAG 2.2 (20)

More from Bill Tyler

More from Bill Tyler (11)

Recently uploaded

Recently uploaded (20)

Introducing WCAG 2.2