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<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