Re: Fwd: Re: WCAG 2.2 status - Visual indicators

On further thought, if we look at 2.4.7 Focus Visible Level AA

"Any keyboard operable user interface has a mode of operation where the 
keyboard focus indicator is visible."

for the understanding doc:

"Note that a keyboard focus indicator can take different forms. "
and
"Examples

     * When text fields receive focus, a vertical bar is displayed in 
the field, indicating that the user can insert text, OR all of the text 
is highlighted, indicating that the user can type over the text.
     * When a user interface control receives focus, a visible border is 
displayed around it."


This is completely non prescriptive and shows the ability to interact, 
so why can we not copy this level of detail for this SC?

Also I have just noticed it says "has a mode of operation" which could 
be supplied via personalisation, AT, an option provided by the site 
itself or for standard controls, by the browser.

Is there any reason all this should not apply for this SC without the 
need for extra specification?

What am I missing?

Steve

On 13/01/2020 13:10, Steve Lee wrote:
> Thanks Rachael
> 
> For those wanting to explore this more the SC proposal is here
> 
> https://docs.google.com/document/d/1WhZAbswvPHs7A3stfqM_ATsaBHPeGbHtARcmaKMck1U/edit?usp=sharing 
> 
> 
> and the text is
> 
> "Each active user interface component provides a visual indicator which 
> conveys its purpose. Where the visual indicator is a underline or an 
> outline shape, the visual indicator has a contrast ratio of 3:1 with at 
> least one adjacent color."
> 
> This is certainly an important cognitive accessibility concern and 
> overlaps with [at least] these Patterns
> 
> * Make it clear what are controls and how they should be used
> * Support personalization of symbols and controls
> 
> But as Alastair points out
> 
> "we would have to be able
> to answer the question “What is an appropriate visual indicator?” for
> any user-interface control."
> 
> The tension is in ensuring we can define suitable indicators that are 
> clear to everyone and yet allowing designers free choice that does not 
> limit the required accessibility. If we are too prescriptive we will get 
> a lot of push back and miss the intent. If we are to relaxed there is a 
> danger the intent of the SC is subverted. Tricky.
> 
> This question is somewhat an open ended and general across Patterns and 
> cognitive SCs as they impact content design. Another broad question is 
> what should be explicitly covered by an SC and what is best moved to 
> personalisation, perhaps with an outline in SC itself. This uncertainty 
> is raised in this SC text.
> 
> These questions are likely to require significant discussion before 
> distillation into an firm SC. We may need a lot of examples to ensure we 
> have all cases covered if we cannot find a simple way to define for all 
> controls.
> 
> So unless we can easily answer Alastair's question or avoid it by 
> invoking personalisation with some clearly defined limits for this SC I 
> think the 2.2 timescales is going to be very hard to meet.
> 
> Can anyone think of a way to resolve this?
> 
> Steve
> 
> On 13/01/2020 12:25, Rachael Montgomery wrote:
>> Hello,
>>
>> I am sending this thread from the main WCAG mailing list because it 
>> relates to an SC that COGA has been supporting. The SC was not in the 
>> original set that we proposed but came up as an important gap during 
>> conversations.
>>
>> Please weigh in on Alistair’s point about moving it out of 2.2 for 
>> continued discussion.  You can respond on the COGA list and I’ll 
>> aggregate responses. You can also respond directly on the AG email chain.
>>
>> Rachael
>>
>>
>> ---------- Forwarded message ----------
>> *From:* Alastair Campbell <acampbell@nomensa.com>
>> *Date:* Jan 13, 2020, 5:05 AM -0500
>> *To:* WCAG list <w3c-wai-gl@w3.org>
>> *Cc:* Newton, Brooks (TR Product) <Brooks.Newton@thomsonreuters.com>
>> *Subject:* Re: WCAG 2.2 status - Visual indicators
>>
>>> Hi Everyone,
>>>
>>> Brooks left  a comment on the examples doc 
>>> <https://docs.google.com/document/d/1fw8C-uHkPzI9IH4wWXdzjRmyfxTHNIYX3vk62Xsph4M/edit#heading=h.ck57f2kxzytg> 
>>> for visual indicators that I thought worth discussing more widely:
>>>
>>> > “I don't like being forced to judge the efficacy of the visual 
>>> indication, based on whether or not the control passes the current 
>>> wording of the draft SC. I think we need to spend a lot more time 
>>> discussing the issues at play with a broad range of interface 
>>> controls that working group members identify as having problematic 
>>> visual affordances.
>>>
>>> > Let's do that example gathering and review, before we create draft 
>>> SC text to frame up the issues that surface through the review. I 
>>> have already provided a number of very good examples, which I 
>>> distributed to the working group through email. Having to re-enter 
>>> those examples into this format which forces a false examination 
>>> against draft SC text that was written without consideration of the 
>>> examples in mind doesn't make sense to me.”
>>>
>>> If others feel similarly, then this is an indicator we should take 
>>> this SC out of the WCAG 2.2 slot.
>>>
>>> We do need examples, and this is a very worthwhile exercise, but if 
>>> we are not at the stage of refining SC wording then it is not an 
>>> exercise that will fit in the WCAG 2.2 timeline.
>>>
>>> In any guidelines scenario (including Silver) we would have to be 
>>> able to answer the question “What is an appropriate visual 
>>> indicator?” for any user-interface control. If we cannot reliably 
>>> answer that, then I suggest we put this as a research topic to tackle 
>>> after WCAG 2.2, probably on the Silver timeline:
>>>
>>> https://www.w3.org/WAI/GL/wiki/Research_needed
>>>
>>> Kind regards,
>>>
>>> -Alastair
>>>

Received on Monday, 13 January 2020 15:53:51 UTC