Re: Focus-appearance flipped version

Hey Alastair,
Left some comments in the doc. As to your points. 1 and 2 I'm okay with.

> I think we’d run into objections from that, we had an issue come up where
an organisation expands the hit area well outside of the visible boundary
of a control, massively increasing the size requirement. That’s why we have
the current notes which says “If the component has a visible boundary
smaller than the hit area, the area measurement is taken from the visible
boundary.”


Fair, I realise target isn't ideal. On the other hand, then what is it?
There are lots of different shapes you can draw around a component that
represent something about it. Bounding box, border box, client box, client
rects, visible area, pointer-event area, etc. It isn't clear which one the
SC intends here. In ACT terms, this would be considered ambiguous; there is
more than one way to interpret this.

> I appreciate wanting to apply it to more shapes that the usual
rectangles, but how would you apply a diameter to a rectangle?  Would it be
better to say that if a shape doesn’t have sides you can’t use that
calculation, you need to use the perimeter.


Diameter is the distance between two opposite points on the perimeter of a
shape.

On Wed, Mar 24, 2021 at 2:31 PM Alastair Campbell <acampbell@nomensa.com>
wrote:

> Hi Wilco,
>
>
>
> I’ve replied in the document, but for the list:
>
>
>
>    1. You mentioned that the “no thinner than 2px” doesn’t belong in the
>    area sub-bullet.
>
>
>
> From a visual requirement point of view we need it, and it is related to
> that calculation. If people use that (potentially much smaller)
> calculation, we want a minimum thickness requirement on it to make up for
> the smaller size.
>
>
>
> If you have a look at the current survey, we are considering making that
> thicker!
>
>
>
>
>
>    1. The suggested “indicator contrast” bullet includes “continuous
>    area”.
>
>
>
> Would that be a problem for split indicators? Where you have two areas,
> one on each side (like some Deque buttons).
>
>
>
>    1. You suggested we use ‘target’ to define the size of the component.
>
>
>
> I think we’d run into objections from that, we had an issue come up where
> an organisation expands the hit area well outside of the visible boundary
> of a control, massively increasing the size requirement. That’s why we have
> the current notes which says “If the component has a visible boundary
> smaller than the hit area, the area measurement is taken from the visible
> boundary.”
>
>
>
>    1. You replaced “shortest side” with “shortest diameter”.
>
>
>
> I appreciate wanting to apply it to more shapes that the usual rectangles,
> but how would you apply a diameter to a rectangle?  Would it be better to
> say that if a shape doesn’t have sides you can’t use that calculation, you
> need to use the perimeter.
>
>
>
> Cheers,
>
>
>
> -Alastair
>
>
>
>
>
> *From:* Wilco Fiers <wilco.fiers@deque.com>
> *Sent:* 24 March 2021 12:28
> *To:* Alastair Campbell <acampbell@nomensa.com>
> *Cc:* WCAG list (w3c-wai-gl@w3.org) <w3c-wai-gl@w3.org>
> *Subject:* Re: Focus-appearance flipped version
>
>
>
> Hey Alastair,
>
> I suggested an update, which I would address my concerns with the wording.
> It's more precise, but in doing so (as always) it got more complicated.
> Hope it helps though.
>
>
>
> On Tue, Mar 23, 2021 at 6:33 PM Alastair Campbell <acampbell@nomensa.com>
> wrote:
>
> Hi Wilco (and list),
>
>
>
> In the survey that we didn’t have time for today on focus-appearance, you
> mentioned that you didn’t think we’d resolved this previous comment:
>
> “I think the rewording still does not make it clear that not every single
> pixel in the focus indicator needs to have a contrast ratio of 3:1. I think
> this SC needs to be flipped around. The steps to go through to figure out
> conformance here is that you first count how many pixels in the focus state
> have a contrast ratio of 3:1 the unfocused state, and only than check do
> you check whether or not there is enough of them.”
>
>
>
> We had discussed this previously:
>
> https://www.w3.org/2021/02/16-ag-minutes.html#item12
>
>
>
> As I mentioned then, I’d looked at how that would work, but it is a
> chicken and egg situation, and it could undermines the ‘adjacent’ contrast
> bullet. I took another stab today, and still couldn’t see how to make that
> work.
>
>
>
> However, I did try adjusting it so the minimum focus indicator definition
> becomes the lynchpin of that (something DavidM suggested I think):
>
>
> https://docs.google.com/document/d/1KAo-6ID3NlVwdGl7uyjnlM_c28kBoizkjIdC8GXLwn4/edit#heading=h.sjv1tte0jm78
>
>
>
> I’m not entirely happy with that, the unobscured bit now dangles, and the
> min-focus indicator definition may need work.
>
>
>
> I wanted to try and address the comment, but I’m not convinced  it helps.
>
>
>
> Kind regards,
>
>
>
> -Alastair
>
>
>
> --
>
>
>
> @alastc / www.nomensa.com
>
>
>
>
> --
>
> *Wilco Fiers*
>
> Axe-core product owner - Facilitator ACT Task Force - Co-chair ACT-Rules
>
>
>


-- 
*Wilco Fiers*
Axe-core product owner - Facilitator ACT Task Force - Co-chair ACT-Rules