Re: Focus appearance

Hi Wilco,

>  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.

So the change of contrast would pass because there is blue to white change outside the component, but that contrasting area is not contrasting with the adjacent area of the component (which is now also blue?), and it’s only 1px thick. I don’t think that would pass?


> 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.

That works for me in most cases. I think where a component is visually ambiguous such as a card, there need to be fall-back indicators such as role, but perhaps also what the focus indicator is associated with. I know that seems circular, but if something passes 2.4.7 it must have an indicator, therefore that can be a signal of what the interactive thing is. Also target area could be a signal.

It’s probably a useful example to add to the understanding – if the link is the thing with a role of link, just because the card’s whole area is clickable doesn’t make that the component.

> I suppose we could change this to "all elements with the role of a user interface component".

I’d rather not, Scott & Adrian provided quite a few realistic examples which show that the actual element (regardless of role) can be wildly different from what you think it is.
For example, hidden inputs: https://cdpn.io/pen/debug/mdByQJm,

https://codepen.io/scottohara/pen/ZEaXjQw


That’s what really turned me off the approach of using the underlying element.

-Alastair