Re: CFC - Target Size (Min)

-1

JF

On Thu, Mar 18, 2021 at 6:28 AM Detlev Fischer <detlev.fischer@testkreis.de>
wrote:

> +1
>
> revising my earlier vote to remove my qualification. Thanks to Alastair's
> reminder I now understand / remember why we need the "farthest point of one
> target to the nearest point of any adjacent target including spacing".
> Admittedly not easy to understand - but all simpler versions had their
> loopholes. And I think it is good that the focus (in SC name and main SC
> text) is on target size, with spacing as exception.
>
> Am 18.03.2021 um 10:26 schrieb Detlev Fischer:
>
> +1 (in principle)
>
> I agree with Wilco that we should still remove "including spacing" (and I
> believe we had determined in the WG call to do so) and revert to the
> simpler wording he cites, so this is a qualified +1 - not sure if such a
> change would need anopther CfC.
>
> I do not see the issue of confusion with the offset formulation in
> exception 1 that Patrick has focused on. The main SC text now clearly
> focuses on the target size of 24 x 24px, so that and the examples provided
> in understanding should leave little ambiguity. What is still missing there
> (I have drafted examples in
> http://3needs.org/en/testing/code/pointer-target.html ) is a
> clarification as to when targets will fall under the inline exception. But
> I believe that is doable.
>
> Detlev
>
> Am 17.03.2021 um 22:38 schrieb Wilco Fiers:
>
> -1
>
> I'm not sure when this happened but somewhere recently the sentence
> "farthest point of one target to the nearest point of an adjacent target"
> was changed to "farthest point of one target to the nearest point of each
> adjacent target including spacing".
>
> This doesn't make sense. Distance is measured from one point to another,
> not from one point to a multiple other points. Spacing has nothing to do
> with this either.
>
>
> @Patrick, the "exclusive area" idea doesn't work. We explored this. If you
> have two 5x5 buttons sitting right up against each other, with a bunch of
> space around them, they'll both pass because each can have the necessary
> space on opposite sides. The trick is for small things to measure the space
> between them, not the space around them. You can only do that from the
> farthest point of one, to the closest point of the other.
>
>
> On Wed, Mar 17, 2021 at 8:01 PM Patrick H. Lauke <redux@splintered.co.uk>
> wrote:
>
>> On 17/03/2021 17:09, Alastair Campbell wrote:
>> > Call For Consensus — ends 19th March at 3pm Boston time.
>> >
>> > The Working Group has discussed the WCAG 2.2 success criteria “Target
>> > Size (Minimum)”, formerly “Target spacing”, the latest version can be
>> > seen here:
>> >
>> > https://w3c.github.io/wcag/guidelines/22/#target-size-minimum
>> > <https://w3c.github.io/wcag/guidelines/22/#target-size-minimum>
>> >
>> > Survey of issues and responses:
>> >
>> >
>> https://www.w3.org/2002/09/wbs/35422/wcag22-target-spacing-issues/results
>> <
>> https://www.w3.org/2002/09/wbs/35422/wcag22-target-spacing-issues/results
>> >
>> >
>> > Previous minutes include:
>> >
>> > https://www.w3.org/2021/03/09-ag-minutes.html#item12
>> > <https://www.w3.org/2021/03/09-ag-minutes.html#item12>
>> >
>> > https://www.w3.org/2021/03/02-ag-minutes.html#item03
>> > <https://www.w3.org/2021/03/02-ag-minutes.html#item03>
>> >
>> > https://www.w3.org/2021/02/23-ag-minutes.html#item02
>> > <https://www.w3.org/2021/02/23-ag-minutes.html#item02>
>> >
>> > If you have concerns about this proposed consensus position that have
>> > not been discussed already and feel that those concerns result in you
>> > “not being able to live with” this decision, please let the group know
>> > before the CfC deadline.
>>
>> This has been discussed before, however my main concern is still with
>> the "offset" language and how, in the normative wording, it's very hard
>> if not impossible to understand.
>>
>> "Spacing: The offset between adjacent targets is at least 24 CSS pixels,
>> where the offset is measured from the farthest point of one target to
>> the nearest point of each adjacent target including spacing"
>>
>> Farthest point ... farthest from what? I assume it means farthest from
>> the particular adjacent target that you're then measuring the distance
>> from? It's not clear in isolation what "the farthest point of one
>> target". If this is to be kept, maybe turning the sentence around makes
>> it clearer? "...measured from each adjacent target to the farthest point
>> (on the other side) of the evaluated target".
>>
>> But this also doesn't really make it any clearer to a layperson.
>>
>> Looking over the examples in the understanding, where all targets are
>> square/rectangular, I would still say that a much simpler way of saying
>> this (that still matches exactly with the pass/fail assessments of those
>> examples in the understanding) is to say that each target "has an area
>> of 24 x 24 pixels which includes the target, and any spacing, that does
>> not contain any other adjacent target" or similar. That there's
>> essentially an "area of exclusion" / "exclusive area" of 24 x 24 pixels
>> that only contains that particular target. This would be much more
>> straightforward to understand (and effectively, I'd hazard a guess that
>> that's how auditors will test it as well ... they'll have a 24 x 24 CSS
>> px overlay and they'll check if that can be placed on a target and have
>> no other adjacent targets intruding in it.
>>
>> I'd be in favour of getting the wording in the normative part as clear
>> as possible, rather than relying on something obfuscated that then
>> requires intense study of the understanding doc to ... understand.
>> Otherwise, this will lead to a lot of headscratching by auditors in
>> future (when it's then too late to change it).
>>
>> P
>> --
>> Patrick H. Lauke
>>
>> https://www.splintered.co.uk/ | https://github.com/patrickhlauke
>> https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
>> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>>
>>
>
> --
> *Wilco Fiers*
> Axe-core product owner - Facilitator ACT Task Force - Co-chair ACT-Rules
>
>
> Join me at axe-con <http://deque.com/axe-con> 2021: a free digital
> accessibility conference.
>
>
> --
> Detlev Fischer
> DIAS GmbH
> (Testkreis is now part of DIAS GmbH)
>
> Mobil +49 (0)157 57 57 57 45
> http://www.dias.de
> Beratung, Tests und Schulungen für barrierefreie Websites
>
>
> --
> Detlev Fischer
> DIAS GmbH
> (Testkreis is now part of DIAS GmbH)
>
> Mobil +49 (0)157 57 57 57 45
> http://www.dias.de
> Beratung, Tests und Schulungen für barrierefreie Websites
>
>