Re: Mode of operation text

> I do not read it as an “if” statement.

hmmm....

IF its a keyboard operable interface it needs a mode with visible focus,
ELSE it fails 2.1.1

but perhaps that is splitting hairs... I think we are saying the same thing.

Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*

Tel:  613-806-9005

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

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 Thu, May 7, 2020 at 10:08 AM Jonathan Avila <jon.avila@levelaccess.com>
wrote:

> 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
>
>
>
> *Can**Adapt* *Solutions Inc.*
>
> Tel:  613-806-9005
>
> LinkedIn
> <http://www.linkedin.com/in/davidmacdonald100>
>
> 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>
> 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
>
>