- From: John Foliot <john@foliot.ca>
- Date: Thu, 18 Mar 2021 09:08:40 -0400
- To: Detlev Fischer <detlev.fischer@testkreis.de>
- Cc: WCAG <w3c-wai-gl@w3.org>
- Message-ID: <CAKdCpxwu=rgKvGAg2C+KnHhg+MR4VvZveER5UoFHxbFc5vbdpA@mail.gmail.com>
-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 > >
Received on Thursday, 18 March 2021 13:09:32 UTC