- From: Detlev Fischer <detlev.fischer@testkreis.de>
- Date: Thu, 18 Mar 2021 11:28:40 +0100
- To: w3c-wai-gl@w3.org
- Message-ID: <00db6c9d-f201-a944-44e8-449323c9b47f@testkreis.de>
+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