Re: WCAG 2.2 - tightened requirements approach

An important consideration is to look at how things happen in WCAG 2.0 
right now, which unfortunately is not consistent.
One thing that is clear is that where a requirement builds directly upon 
another, in ALL situations they are at different levels. That's why I 
think that considering moving Focus Visible to level A is advisable. It 
maintains this stratification. Moving an SC from AA to A has some impacts 
to tools, but they don't seem that heavy, and for users it is simple 
because they already test for it.

In regard to the argument around one SC effectively rendering another a 
moot point, we have many such subset SCs in place today. Again, they are 
ALWAYS differentiated by their levels.

Subset examples:

1.3.5 Identify Input Purpose AA is a subset of 1.3.6 Identify Purpose AAA. 
Meet 1.3.6 and you meet 1.3.5
1.4.3 Contrast (Minimum) AA is a subset of 1.4.6 Contrast (Enhanced) AAA. 
Meet 1.4.6 and you meet 1.4.3
1.4.5 Images of Text AA is a subset of 1.4.9 Images of Text (No Exception) 
AAA. Meet 1.4.9 and you meet 1.4.5, etc
2.1.1 Keyboard A is a subset of 2.1.3 Keyboard (No Exception) AAA
2.3.1 Three Flashes or Below Threshold A is a subset of 2.3.2 Three 
Flashes AAA
2.4.4 Link Purpose (In Context) A is a subset of 2.4.9 Link Purpose (Link 
Only) AAA
3.3.4 Error Prevention (Legal, Financial, Data) AA to 3.3.6 Error 
Prevention (All) AAA

Note that all of the above involve level AAA enhancements.

Slightly messier is:
1.2.3 Audio Description or Media Alternative A is a subset of 1.2.5 Audio 
Description AA, but only for the audio description part. Meet 1.2.5 and 
you meet 1.2.3
1.2.3 is also in some contexts ALREADY meeting 1.2.8 AAA (for the 
alternative part). Still, meet 1.2.8 and you meet 1.2.3

Non-subset increments include:
1.2.5 Audio Description AA to 1.2.7 Extended Audio Description. While the 
inference is there that it is a subset, it is arguably a different feature 
depending on a prerequisite.
1.2.2 Captions (Prerecorded) A to 1.2.4 Captions (Live) AA. Different 
circumstance for captioning.
1.2.4 Captions (Live) AA to Audio-only (Live) AAA. Different medium 
(synchronized media versus audio-only).
3.1.1 Language of Page A to 3.1.2 Language of Parts AA. Cover different 
parts of content, although inference is that language of page is a 
prerequisite
3.3.1 Error Identification A to 3.3.3 Error Suggestion AA. Additional 
function, based on same need to automatically detect error.


It's tough to tackle this entirely in an email, so my feeling is it would 
be useful to have a focused discussion on aspects of this. I share 
previously expressed sentiments that backwards compatibility does not mean 
identical. You can enhance prior requirements. No matter how we slice 
this, if we are adding a new requirement (whether as a new SC or as an 
altered SC) there's going to need to be additional analysis or testing in 
the case where someone fails the latest version and wants to see if they 
still meet the prior one.

Michael Gower
Senior Consultant in Accessibility
IBM Design


1803 Douglas Street, Victoria, BC  V8T 5C3
gowerm@ca.ibm.com
cellular: (250) 661-0098 *  fax: (250) 220-8034



From:   Alastair Campbell <acampbell@nomensa.com>
To:     WCAG list <w3c-wai-gl@w3.org>
Date:   2019-06-28 07:42 AM
Subject:        [EXTERNAL] WCAG 2.2 - tightened requirements approach



Hi everyone,
 
The question I ask at the end of this email is: “Given such a clean 
addition of requirements for an SC, what is the downside to modifying the 
current SC?” The rest is explanation:
 
Whilst working on the focus “more” visible SC for WCAG 2.2, there have 
been some survey comments on how it fits with the current 2.4.7 [1].
 
Suggestions included:
1.      Add a separate SC at level AA (e.g. Enhanced keyboard focus);
2.      Add a separate SC at level AA (e.g. Enhanced keyboard focus), and 
move 2.4.7 to level A;
3.      Modify 2.4.7 to include the new requirements (removing 2.4.7 and 
replacing it with this would be the same thing).
 
In this case it is a straightforward extension on 2.4.7,  so all the 
options maintain backwards compatibility. This email is about how to do 
it.
 
# Option 1 & 2, a separate new SC
 
We’d have the current SC, either at level AA or changed to A:
2.4.7 Focus Visible (level A or AA)
Any keyboard operable user interface has a mode of operation where the 
keyboard focus indicator is visible. 
 
2.4.8 … (level AAA)
2.4.9 … (level AAA)
2.4.10 … (level AAA)
 
2.4.11 Enhanced keyboard focus (level AA)
The keyboard focus indicator must:
Have a size equivalent to at least a 1 CSS pixel line along the longest 
side, and
have a contrast ratio of at least 3:1 for the change of color contrast.
 
 
 
# Option 3, modify the SC
 
In this scenario the current 2.4.7 would be updated to something like this 
draft:
2.4.7 Focus Visible (level A or AA)
Any keyboard operable user interface has a mode of operation where the 
keyboard focus indicator is visible. 
The visible change that indicates keyboard focus must:
Have a size equivalent to at least a 1 CSS pixel line along the longest 
side, and
have a contrast ratio of at least 3:1 for the change of color contrast.
 
 
The new part is appended to the end, the original SC text is un-touched.
 
All the options seem reasonable for the SC text, where I’m struggling is 
the understanding document.
 
I’ve drafted that as an update here:
https://docs.google.com/document/d/1g9_WBgfhViWAaRFIWWt10CP5rBsEVIWm3vT1vWqrHvI/edit?ts=5d124fb5# 

 
The original understanding doc becomes redundant, both the content and the 
techniques attached to it are a sub-set of the new SC.
 
Of course, we have SCs like Contrast min and contrast enhanced [2], but in 
that case the Understanding doc is virtually identical, even the 
techniques are the identical. (I’m curious if the group at the time 
thought of just pointing in a pointer from one to the other, rather than 
duplicating the text?)
 
In this case there would be conflicting advice between the two 
understanding docs, as the current 2.4.7 allows for default indicators and 
blinking cursors as focus-indicators. That would then be overridden at 
level AA by the new SC. Also, technique G156 (default focus indicators) 
would be valid for 2.4.7, but not for the new one.
 
If you remove the conflicting advice from the current 2.4.7 Understanding 
doc there wouldn’t by much left, and everything else would be covered the 
new SC. 
 
In the case of separate SCs I would be inclined to basically have an 
almost blank Understanding doc and just point to the new SC. Which seems 
messy & odd.
 
Given such a clean addition of requirements for an SC, what is the 
downside to modifying the current SC? 
 
Having an updated 2.4.7 wouldn’t impact my work at all (compared to a new 
separate SC), what am I missing?
 
Kind regards,
 
-Alastair
 
1] https://www.w3.org/2002/09/wbs/35422/wcag22reviews/results#xq4 
2] https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum.html 
    https://www.w3.org/WAI/WCAG21/Understanding/contrast-enhanced.html 
 
-- 
 
www.nomensa.com
tel: +44 (0)117 929 7333 / 07970 879 653
follow us: @we_are_nomensa or me: @alastc
Nomensa Ltd. King William House, 13 Queen Square, Bristol BS1 4NT
 
Company number: 4214477 | UK VAT registration: GB 771727411