Re: WCAG 2.2 status - Visual indicators

That's a very good reason and is reassuring! :)

The desirability for some level of conistency is also missing.

How does the behaviour of browsers with standard controls (UAAG) fit here?

Steve

On 14/01/2020 15:38, Alastair Campbell wrote:
> Hi Steve,
> 
>     > This is completely non prescriptive and shows the ability to interact,
>     > so why can we not copy this level of detail for this SC?
> 
> The reason we have another focus-visible SC in development is because that was inadequate.
> 
> Anything qualified. You could have a 1 pixel square as a focus indicator and it would pass.
> 
> See the update for a far more prescriptive version:  https://docs.google.com/document/d/1g9_WBgfhViWAaRFIWWt10CP5rBsEVIWm3vT1vWqrHvI/edit
> 
> We've learned a few lessons with non-text contrast as well. We tested 100s of examples for that, and it is narrower scope than a Visual Indicators SC.
> 
> Cheers,
> 
> -Alastair
> 
> 
> On 13/01/2020, 15:54, "Steve Lee" <stevelee@w3.org> wrote:
> 
>      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 Tuesday, 14 January 2020 17:24:07 UTC