RE: Mode of operation text

Mode of operation allow for situations like iOS where you can turn on or off full keyboard access or situations where a keyboard interface can be coupled with the device or not, etc.   I don’t see any harm in keeping it.     It’s similar to our mechanism language in other criteria.  I do not read it as an “if” statement.

Jonathan

From: David MacDonald <david100@sympatico.ca>
Sent: Thursday, May 7, 2020 8:38 AM
To: Alastair Campbell <acampbell@nomensa.com>
Cc: John Foliot <john.foliot@deque.com>; WCAG list (w3c-wai-gl@w3.org) <w3c-wai-gl@w3.org>
Subject: Re: Mode of operation text

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

HI Alastair

> does anyone remember why that phrasing was used originally?

 I think the phrase "mode of operation" originated from an article that we referenced in 2000 ... was it that long ago :0  ?
https://lists.w3.org/Archives/Public/w3c-wai-gl/2000AprJun/0277.html


In the SC 2.4.7 it means that if the interface is keyboard operable, there is some way (mode of operation) to ensure that the focus is always visible.

It was first used in the TEITAC in about 1996-1998 which was the foundational document for Section 508.
Here it is referenced in the 508 Subpart C,1194.31 (a)
https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-section-508-standards/section-508-standards#subpart_c

"Products must provide at least one mode that allows access necessary to operate all functionality of the product without requiring any physical contact with the product beyond initial connection and setup of a special interface device."

If we need to get more on it  we could reach out to Gregg, who I'm guessing coined the phrase as he was involved in TEITAC and the 508.


Cheers,
David MacDonald



CanAdapt Solutions Inc.

Tel:  613-806-9005

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd<http://twitter.com/davidmacd>

GitHub<https://github.com/DavidMacDonald>

www.Can-Adapt.com<http://www.can-adapt.com/>



  Adapting the web to all users
            Including those with disabilities

If you are not the intended recipient, please review our privacy policy<http://www.davidmacd.com/disclaimer.html>


On Wed, May 6, 2020 at 6:58 PM Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>> wrote:
Hi John,

I’m struggling to see how one can be an ‘if’ statement and not the other?

After an identical start:

  *   One ends “where the keyboard focus indicator is visible”.
  *   The other “where the keyboard focus indicator meets all of the following”.

I’m not seeing how you can read 2.4.7 differently from the new one.

> when and where will content that does not meet SC 2.4.7 none-the-less still be governed by this requirement

The intent (see the conversation: https://github.com/w3c/wcag/issues/1067) was to line them up, as the wording in the FPWD would have instances where you could have no visible focus; passing the new one but failing 2.4.7.


> As for the "minor addition" to the Understanding Document (non-normative), do we have a record of a vote to approve that "minor" update?

That was part of the focus-visible enhanced changes so came under that CFC that accepted this PR:
https://github.com/w3c/wcag/pull/936/files#diff-c66748f70227fe77ffcbde28768a5f6f


However, at the time I added that I thought we’d have separate documents for 2.2 (you can see the “wcag22” class in the code), but it turns out we can’t separate the understanding docs between versions, so it did go live before I’d intended.  I’ll re-open the issue and get it in a survey.


> More importantly however, do we have evidence of ANY "...platforms which may not always show a focus indicator."?

So there are two things here:

  1.  What was the original intent? It’s before my time, does anyone remember why that phrasing was used originally?  It isn’t explained in the understanding doc, which is why the issue came up!
https://github.com/w3c/wcag/issues/301

  2.  Does the use of :focus-visible contravene 2.4.7? I.e. is letting the browser decide when to show the focus indicator ok?

The addition helps with the second, but whether we bring that into the normative wording really depends on what it originally meant.

For the modified second option, I think we need to keep the new SC lined up with 2.4.7, so I’d like to get to the bottom of where that original wording came from in order to change it.

For the 1st bullet on sizing, adding the 2 CSS px along one edge is redundant. The area of a 1px border around all edges is greater than 2px along one edge. The con in the doc was more for things like a background change or icon/block indicator. To solve that in the text we’d have to add a list of things it could be, or something else.

Cheers,
-Alastair