- From: jake abma <jake.abma@gmail.com>
- Date: Sun, 1 Nov 2020 14:13:44 +0100
- To: Alastair Campbell <acampbell@nomensa.com>
- Cc: "Mobile a11y tf (public-mobile-a11y-tf@w3.org)" <public-mobile-a11y-tf@w3.org>, AGWG Chairs <group-ag-chairs@w3.org>
- Message-ID: <CAMpCG4Gdt8GwfQoY3vez45UqTYd41BzL-G+A5Wj29eZ2Fr7dhQ@mail.gmail.com>
any feedback on?: "For each edge of a target, the distance to the closest edge of the nearest target on the opposite side is at least 24 CSS pixels, except when:": this one preserves all we've been after... I think Op zo 1 nov. 2020 om 14:11 schreef jake abma <jake.abma@gmail.com>: > > "That's basically setting a minimum of 24px size" > > No it will not if you have target of 10px, maybe more, next to targets way > bigger, like 10 10px10px targets around a 1 70x70px target, the 24px is > easily met, BUT hitting the 10x10px targets will be difficult... > > Op vr 30 okt. 2020 om 01:26 schreef Alastair Campbell < > acampbell@nomensa.com>: > >> I think (testing my logical brain) that either we allow for spacing and >> get results where smaller targets can work, or we don't allow for spacing >> as such. The center to edge calculation is also throwing up an oddity. >> >> To keep it simple and allow for spacing I'd suggest: >> For each target, the horizontal and vertical non-overlapping distance >> between the center of the target and the @@center of the other targets@@ >> is at least 24 CSS pixels, except when... >> >> That's basically setting a minimum of 24px size, with a metric that that >> (I think) is more adaptable to irregular shapes. >> >> Cheers, >> >> -Alastair >> >> >> -----Original Message----- >> From: Patrick H. Lauke <splintered@gmail.com> >> Sent: 29 October 2020 21:58 >> To: Mobile a11y tf (public-mobile-a11y-tf@w3.org) < >> public-mobile-a11y-tf@w3.org> >> Cc: Alastair Campbell <acampbell@nomensa.com>; AGWG Chairs < >> group-ag-chairs@w3.org> >> Subject: Re: FW: Pointer target size >> >> I commented on the document itself (in answer to the original >> "non-overlapping distance", but i think this would also be simpler/more >> understandable than this "closest edge / opposite side / nearest target >> contortion), but copying it here as well for reference: >> >> what you're trying to say, but it needs a lot more words (because >> "non-overlapping distance" doesn't really seem to make sense) is that for >> each target, you're wanting a circle with radius 12px from the center of >> the target, and none of the circles for any of the targets are allowed to >> overlap. >> >> also, while this sort of reasoning/basing it on the center of a target >> works ok for regular/rectangular shaped targets, it may not be applicable >> for irregular-shaped targets (thinking for instance polygons as part of an >> SVG, or image map areas, or similar) >> >> P >> >> On 29/10/2020 21:35, jake abma wrote: >> > Sorry for the multiple mails, but distsnce need to be in there .. >> > >> > For each edge of a target, the distance to the closest edge of the >> > nearest target on the opposite side is at least 24 CSS pixels, except >> when: >> > >> > >> > Op do 29 okt. 2020 22:29 schreef jake abma <jake.abma@gmail.com >> > <mailto:jake.abma@gmail.com>>: >> > >> > Here it is: >> > >> > >> > For each edge of a target, the closest edge of the nearest target on >> > the opposite side is at least 24 CSS pixels, except when: >> > >> > >> > Op do 29 okt. 2020 22:24 schreef jake abma <jake.abma@gmail.com >> > <mailto:jake.abma@gmail.com>>: >> > >> > If fact, what we're looking for is more like: each outer edge of >> > a target is at least 24 px separated from other targets on the >> > opposite side >> > >> > Op do 29 okt. 2020 22:14 schreef jake abma <jake.abma@gmail.com >> > <mailto:jake.abma@gmail.com>>: >> > >> > 18px area I mean... >> > >> > Op do 29 okt. 2020 22:12 schreef jake abma >> > <jake.abma@gmail.com <mailto:jake.abma@gmail.com>>: >> > >> > Small addition, even with this adjustment you'll en up >> > with a 18px target, imagine the right one is 24, the >> > left 12 with 6px spacing will pass >> > >> > Op do 29 okt. 2020 21:37 schreef Sukriti Chadha >> > <sukriti1408@gmail.com <mailto:sukriti1408@gmail.com>>: >> > >> > Hi Alastair, Rachael, Chuck and MATF members, >> > >> > In today's MATF meeting, we went over the latest >> > proposed wording in this document >> > < >> https://docs.google.com/document/d/1_EHFVE-p4jEtKFa2jMEUruSvu6iv-Vt7UxRW9SrHTCQ/edit >> >. >> > Jake brought up a great point with an example. It >> > had two adjacent targets of 12 px width with a 6 px >> > spacing that would pass this criteria even though >> > each would have only 18 px in total instead of the >> > 24 we are aiming for (a drawing is included in the >> > doc). It would run into similar problems as the one >> > before where smaller target sizes might be >> > encouraged due to shared spacing. To avoid that we >> > added "non-overlapping" to the distance. >> > >> > Please let me know if I can help clarify. Thank you >> > everyone for your patience with this! >> > >> > Best, >> > Sukriti >> > >> > PS We also looked into going with a 24X24 version of >> > 2.5.5 (the AAA version) but considered elements such >> > as side rail links that aren't part of sentences but >> > standalone links which would fail the criteria on a >> > large number of websites even though those are the >> > only targets in a 24X24 area. >> > >> > >> > >> > On Thu, Oct 22, 2020 at 11:24 AM Alastair Campbell >> > <acampbell@nomensa.com >> > <mailto:acampbell@nomensa.com>> wrote: >> > >> > Sorry, I should have CCed the task force as >> > well.____ >> > >> > __ __ >> > >> > __ __ >> > >> > *From:*Alastair Campbell >> > *Sent:* 22 October 2020 15:53 >> > *To:* WCAG list ____ >> > >> > __ __ >> > >> > Hi everyone,____ >> > >> > __ __ >> > >> > We discussed pointer-target-spacing yesterday, >> > and whilst there was a general wish to carry on >> > with it, we needed a new version to account for >> > some of the comments.____ >> > >> > __ __ >> > >> > I’ve gathered a couple of suggestions together >> > to form this version:____ >> > >> > __ __ >> > >> > For each target, the horizontal and vertical >> > distance between the center of the target and >> > the closest edge of the nearest target is at >> > least 12 CSS pixels except when:____ >> > >> > * *Inline*: The target is in a sentence or >> > block of text;____ >> > * *User Agent Control:* The size of the target >> > is determined by the user agent and is not >> > modified by the author;____ >> > * *Essential*: A particular presentation of >> > the target is essential to the information >> > being conveyed.____ >> > >> > __ __ >> > >> > *Note*: The User Agent Control exception would >> > not apply as soon as styling properties such as >> > font size - and in the case of mobile/tablet >> > browsers, viewport meta - has been modified by >> > the author____ >> > >> > __ __ >> > >> > (Google doc version >> > >> > <https://docs.google.com/document/d/1_EHFVE-p4jEtKFa2jMEUruSvu6iv-Vt7U >> > xRW9SrHTCQ/edit?usp=sharing>)____ >> > >> > __ __ >> > >> > Don’t panic about the “12px” bit, that is the >> > same as 24px wide/tall but if you measure from >> > the center then you half it. It was a suggestion >> > from Jeff Witt in #1444 >> > <https://github.com/w3c/wcag/issues/1444> that >> > should prevent the shared space aspect.____ >> > >> > __ __ >> > >> > CCing Wilco to make sure the testing perspective >> > is considered for this approach. ____ >> > >> > __ __ >> > >> > There are other comments to deal with, but does >> > this seem like a good basis to continue?____ >> > >> > __ __ >> > >> > Kind regards,____ >> > >> > __ __ >> > >> > -Alastair____ >> > >> > __ __ >> > >> > -- ____ >> > >> > __ __ >> > >> > @alastc / www.nomensa.com >> > <http://www.nomensa.com>____ >> > >> > __ __ >> > >> >> >> -- >> 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 >> >
Received on Sunday, 1 November 2020 13:14:13 UTC