Re: CFC - Target Size (Min)

+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 <mailto: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>
>>     > <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>
>>     <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/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/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>
>>     > <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://www.splintered.co.uk/> |
>>     https://github.com/patrickhlauke <https://github.com/patrickhlauke>
>>     https://flickr.com/photos/redux/
>>     <https://flickr.com/photos/redux/> |
>>     https://www.deviantart.com/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

Received on Thursday, 18 March 2021 10:29:01 UTC