Re: WCAG 2.2 - tightened requirements approach

Hi All,

I share many of the same thoughts as Jon and Mike do. In particular, Jon's
comment "...that is why I think it is more clear to have different versions
of the SC that build on each other to help enforce that." - A huge +1

I've personally always seen "backward comparability" to also equal "we're
building on top of", and as Mike has illustrated, this isn't that un-common
for WCAG even at 2.0. in particular, he notes one SC that amply illustrates
what I envision here: "...*meet 1.2.8 and you meet 1.2.3..."*

JF

On Wed, Jul 10, 2019 at 2:51 PM Michael Gower <michael.gower@ca.ibm.com>
wrote:

> 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#*
> <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*
> <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-minimum.html>
>
>     *https://www.w3.org/WAI/WCAG21/Understanding/contrast-enhanced.html*
> <https://www.w3.org/WAI/WCAG21/Understanding/contrast-enhanced.html>
>
>
>
> --
>
>
>
> *www.nomensa.com* <http://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
>
>
>

-- 
*​John Foliot* | Principal Accessibility Strategist | W3C AC Representative
Deque Systems - Accessibility for Good
deque.com