Re: Focus appearance

Hey Alastair,

> Did you notice the overall PR doesn’t change the adjacent bullet? I took
those comments from the survey on board.

You're right, I had not noticed that. Coming to think of it, the Chrome
text input default example passes the current wording too. Because of that
offset -1, the contrasting area is the outer 1px of that 2px focus
indicator, which is only adjacent to the inner pixels, and the background
around the component. So yeah, I guess that loophole exists regardless.

> This stems from what is included in a UIC. When you (and others) put on
the survey that UIC was the best approach, what was the answer to the card
question?

I think the UIC of a card component is whatever element has the link role.
4.1.2 requires all components to have an appropriate role. So unless
there's a 4.1.2 violation, a UIC is just any component with a widget role.
If we wanted to side step that problem, I suppose we could change this to
"all elements with the role of a user interface component". That can then
be done programmatically, and you're leaving the question of "what is
actually the link here" to be answered by 4.1.2.


On Thu, Feb 17, 2022 at 10:52 AM Alastair Campbell <acampbell@nomensa.com>
wrote:

> Hi Wilco,
>
>
>
> A few replies on that:
>
>
>
>
>
> > I'm not opposed to the change, but I did think it worth noting it
> creates a fairly significant loop hole in adjacent contrast.
>
>
>
> Did you notice the overall PR doesn’t change the adjacent bullet? I took
> those comments from the survey on board.
>
>
>
> > For example on a card with an image, is that image content?
>
>
>
> This stems from what is included in a UIC. When you (and others) put on
> the survey that UIC was the best approach, what was the answer to the card
> question?
>
>
>
>
> > I've asked and will continue to ask for evidence that a fading focus
> indicator is a substantial accessibility problem.
>
>
> The fading focus indicator is fairly new and not very well known yet.
> Apart from the people who created it (possibly), I doubt anyone else has
> had a chance to do research on it.
>
>
>
> What we do know is:
>
>    - (Without the accessibility option) A fading focus indicator means
>    it’s easy to lose where you were. The 2.4.7 understanding doc has language
>    to the effect it must be persistent for that reason, extending that to the
>    visibility of the indicator is logical.
>
>
>    - (Using the accessibility option) A fading focus indicator (on top of
>    poor authored indicators) isn’t effective for some people, partly due to
>    the fade, partly due to overlapping other content.
>
>
>
> That isn’t a criticism of the accessibility option, nothing works for
> everyone and it is a good thing to have done for the people whom it does
> benefit. It also leads onto the next point:
>
>
> > I think it's a fair assumption that browsers will never be able to solve
> this with a permanent focus indicator… to avoid permanently obscuring other
> content.
>
>
> A browser-based, forced indicator is a blunt instrument, there are quite a
> few scenarios where the author has an advantage. For example, in areas
> where an expansive indicator overlaps other content, it is easy to use a
> smaller, high contrast indicator. Or an internal one.
>
> I often run CSS to create a forced indicator, and it can get obscured by
> overlapping content as well.
>
>
>
> To me that’s a good argument for the SC, regardless of the potential
> accessibility options. My read of the general group opinion was that (like
> text contrast) the focus indicator was something that should have a
> reasonable baseline by default.
>
>
>
> However, I think Melanie had wanted to keep the conversation to the
> default indicator. Are you arguing that the authored or browser default
> indicators should be able to fade out?
>
>
>
> I had thought that the reason the accessibility option faded was due to
> the overlap issues rather than because it was a better approach overall?
>
>
>
> Kind regards,
>
>
>
> -Alastair
>
>
>


-- 
*Wilco Fiers*
Axe-core & Axe-linter product owner - WCAG 3 Project Manager - Facilitator
ACT Task Force

Received on Thursday, 17 February 2022 10:12:37 UTC