- From: Wilco Fiers <wilco.fiers@deque.com>
- Date: Thu, 19 Nov 2020 17:24:29 +0100
- To: Sukriti Chadha <sukriti1408@gmail.com>
- Cc: Michael Gower <michael.gower@ca.ibm.com>, Alastair Campbell <acampbell@nomensa.com>, Sarah Horton <sarah.horton@gmail.com>, "WCAG list (w3c-wai-gl@w3.org)" <w3c-wai-gl@w3.org>
- Message-ID: <CAHVyjGMWmTaDryWFheiJRvz=D-uWPKTAi1or4zfYhdKZQi9Wgw@mail.gmail.com>
Hey Sukriti, I looked at phrasing the SC the way you suggest before: *The distance between the farthest point from a given target to any point on all adjacent targets is at least 24 CSS pixels, except if:* The problem On Thu, Nov 19, 2020 at 4:36 PM Sukriti Chadha <sukriti1408@gmail.com> wrote: > *For all adjacent targets, the farthest point of one target is at least 24 > CSS pixels away from the other target, except if:* > > The language here is pretty confusing - we need to be more clear about > what is 'one target' and what is 'other target'. Here's a crack at one > > *The distance between the farthest point from a given target to any point > on all adjacent targets is at least 24 CSS pixels, except if:* > > On Thu, Nov 19, 2020 at 10:30 AM Michael Gower <michael.gower@ca.ibm.com> > wrote: > >> Actually, we could even consider making diameter a defined term, thus >> making those measurements normalized. >> Michael Gower >> Senior Consultant in Accessibility >> IBM Design >> >> >> 1803 Douglas Street, Victoria, BC V8T 5C3 >> gowerm@ca.ibm.com >> cellular: (250) 661-0098 * fax: (250) 220-8034 >> >> >> >> From: Michael Gower/CanWest/IBM >> To: Sukriti Chadha <sukriti1408@gmail.com> >> Cc: Alastair Campbell <acampbell@nomensa.com>, Sarah Horton < >> sarah.horton@gmail.com>, "WCAG list (w3c-wai-gl@w3.org)" < >> w3c-wai-gl@w3.org>, Wilco Fiers <wilco.fiers@deque.com> >> Date: 2020/11/19 07:27 AM >> Subject: Re: [EXTERNAL] Re: Target spacing refinement >> ------------------------------ >> >> >> Suktriti, I think the various methods of calculating the diameter of >> shapes (rectangle, triangle) can be provided in the Understanding document, >> including for irregular shapes. >> >> Note that the language Wilco put forward (and for which I have suggested >> minor edits) would replace the language you have listed. The preamble would >> become the following (with the addition of a new diameter bullet) >> >> *For all adjacent targets, the farthest point of one target is at least >> 24 CSS pixels away from the other target, except if:* >> >> >> Michael Gower >> Senior Consultant in Accessibility >> IBM Design >> >> >> 1803 Douglas Street, Victoria, BC V8T 5C3 >> gowerm@ca.ibm.com >> cellular: (250) 661-0098 * fax: (250) 220-8034 >> >> >> >> >> From: Sukriti Chadha <sukriti1408@gmail.com> >> To: Michael Gower <michael.gower@ca.ibm.com> >> Cc: Alastair Campbell <acampbell@nomensa.com>, Sarah Horton < >> sarah.horton@gmail.com>, Wilco Fiers <wilco.fiers@deque.com>, "WCAG list >> (w3c-wai-gl@w3.org)" <w3c-wai-gl@w3.org> >> Date: 2020/11/19 07:14 AM >> Subject: [EXTERNAL] Re: Target spacing refinement >> ------------------------------ >> >> >> >> Thank you Alaistar, Wilco, Detlev and Michael for all the examples,... >> >> >> >> *This Message Is From an External Sender* >> This message came from outside your organization. >> >> >> Thank you Alaistar, Wilco, Detlev and Michael for all the examples, those >> are incredibly helpful! While I like the approach of diameters from a >> mathematical standpoint, it might be confusing when implementing as a >> developer, given most targets are confined in rectangular spaces, even if >> the visible targets might be irregularly shaped. This was brought up before >> and the group decided not to pursue that route for similar reasons. I have >> one small edit to #5 to clarify where on the adjacent target. The SC reads, >> where "from the closest edge" is the new text : >> >> *For each target, the distance from the closest edge of each adjacent >> target to the farthest edge of the current target is at least 24 CSS pixels >> except when*” >> >> >> On Thu, Nov 19, 2020 at 10:05 AM Michael Gower < >> *michael.gower@ca.ibm.com* <michael.gower@ca.ibm.com>> wrote: >> Wilco and Detlev, thanks for working up another treatment. I agree with >> Wilco that the parenthetical wording isn't required (it can be clarified in >> the Understanding), so we end up with >> *For all adjacent targets, the distance from the farthest point of one >> target is at least 24 CSS pixels away from the other target, except if:* >> >> - *Diameter**: The smallest diameter is at least 24 CSS pixels;* >> >> >> I believe this rewording could even be further reduced by having >> "distance from the" removed, to become >> *For all adjacent targets, the farthest point of one target is at least >> 24 CSS pixels away from the other target, except if:* >> >> Wilco, thanks for all those examples. My only request going forward if >> you ever go to this trouble again, that you label or otherwise provide a >> key for your expected outcome. (made up example: 'All example Ds should >> fail'). That would help each of us scan to see if we're in agreement on >> that outcome, and then scan to see what the real outcome was. IMO, a matrix >> of examples like this would be beneficial in the Understanding document. >> >> Sarah, I echo Alastair's comments on size. For example, those little Xs >> in the corners of dialogs are universal (and have another mechanism for >> dismissal on the desktop, via the keyboard) and if we come up with wording >> that fails them, we would have a hard time getting traction. >> >> Michael Gower >> Senior Consultant in Accessibility >> IBM Design >> >> >> 1803 Douglas Street, Victoria, BC V8T 5C3 >> *gowerm@ca.ibm.com* <gowerm@ca.ibm.com> >> cellular: (250) 661-0098 * fax: (250) 220-8034 >> >> >> >> From: Alastair Campbell <*acampbell@nomensa.com* >> <acampbell@nomensa.com>> >> To: Sarah Horton <*sarah.horton@gmail.com* >> <sarah.horton@gmail.com>> >> Cc: Wilco Fiers <*wilco.fiers@deque.com* <wilco.fiers@deque.com>>, >> "WCAG list (*w3c-wai-gl@w3.org* <w3c-wai-gl@w3.org>)" < >> *w3c-wai-gl@w3.org* <w3c-wai-gl@w3.org>> >> Date: 2020/11/19 04:58 AM >> Subject: [EXTERNAL] RE: Target spacing refinement >> ------------------------------ >> >> >> >> Hi Sarah, We do have an SC that addresses target size, but it is... >> >> >> >> *This Message Is From an External Sender* >> This message came from outside your organization. >> >> Hi Sarah, >> >> >> >> We do have an SC that addresses target size, but it is at AAA. This is >> the “other” SC that allows more flexibility so is aiming at AA. >> >> >> >> If we try and incorporate a minimum size as well as size+ spacing into >> one SC, I think that would make it more convoluted. >> >> >> >> Also, if the user-need is met by targets+spacing (as described in the >> previous email), we would get significant push-back on asking authors to >> spend lots of time doing things that don’t actually help users. >> >> >> >> I appreciate the need, but we also have to note that it conflicts with >> other needs, such as some people with low-vision ( >> *https://github.com/w3c/wcag/issues/1381* >> <https://github.com/w3c/wcag/issues/1381>) and the ability to create >> information-dense interfaces. We’ve reduced the size requirement to >> compromise, it’s then a balance between competing requirements. >> >> >> >> With user-group conflicts the better approach is often personalisation >> options rather than author requirements. >> >> >> >> So the question becomes: Is this SC a baseline worth having? >> >> >> >> Kind regards, >> >> >> >> -Alastair >> >> >> >> >> >> *From:*Sarah Horton <*sarah.horton@gmail.com* <sarah.horton@gmail.com>> >> *Sent:* 19 November 2020 11:22 >> *To:* Alastair Campbell <*acampbell@nomensa.com* <acampbell@nomensa.com>> >> *Cc:* Wilco Fiers <*wilco.fiers@deque.com* <wilco.fiers@deque.com>>; >> WCAG list (*w3c-wai-gl@w3.org* <w3c-wai-gl@w3.org>) <*w3c-wai-gl@w3.org* >> <w3c-wai-gl@w3.org>> >> *Subject:* Re: Target spacing refinement >> >> >> >> Without an SC that addresses minimum target size I think this target >> spacing SC is going to end up confusing and convoluted, and will not >> address the real and significant user need for a minimum target size. >> >> >> >> What about trying for two new SCs, one for target size and one for target >> spacing, either as part of the WCAG 2.2 effort or in whatever comes next >> (2.3 or 3.0)? >> >> >> >> Best, >> >> Sarah >> >> On Nov 19, 2020, at 11:06 AM, Alastair Campbell <*acampbell@nomensa.com* >> <acampbell@nomensa.com>> wrote: >> >> >> >> > The only two that I question are A4 and D1. Those are just so small... >> If we added an absolute minimum diameter of 12px for every target those two >> would fail without changing any of the other ones. >> >> >> >> Part of the reasoning for this SC was that, in touch-scenarios, the >> devices use heuristics to guess which thing you meant to tap. I.e. if you >> tap reasonably close to a link it generally works because the device finds >> the nearest link. However, if you have small links close to each other >> that heuristic can make the wrong choice because you accidentally tapped >> closer to an adjacent target. >> >> >> >> That’s why it is size+spacing rather than just size, and why we weren’t >> trying to set a minimum size as such. (Although it Patrick were reading >> this, he’d pipe in with “what about mouse users?”, which is fair, but it’s >> hard to accomplish everything in one SC.) >> >> >> >> Also, I’m worried about adding complexity to (necessarily) convoluted SC >> text… >> >> >> >> -Alastair >> >> >> >> >> >> >> >> >> >> >> >> *From:*Wilco Fiers <*wilco.fiers@deque.com* <wilco.fiers@deque.com>> >> *Sent:* 19 November 2020 10:36 >> *To:* Alastair Campbell <*acampbell@nomensa.com* <acampbell@nomensa.com>> >> *Cc:* WCAG list (*w3c-wai-gl@w3.org* <w3c-wai-gl@w3.org>) < >> *w3c-wai-gl@w3.org* <w3c-wai-gl@w3.org>> >> *Subject:* Re: Target spacing refinement >> >> >> >> Hey Alastair, >> >> You are correct, I made a mistake on H3. There is just enough space for >> the outer box to pass. I've fixed that, and added an example that's similar >> but where the box is rounded (N1 - N4) >> >> >> >> As for E3 and E4, I think it is okay for those to fail. They are more >> difficult to hit than some of the other fails like G4 and H4. I think this >> actually strikes a good balance. The only two that I question are A4 and >> D1. Those are just so small... even if someone isn't likely to hit the >> wrong thing, it'll be hard to hit. If we added an absolute minimum diameter >> of 12px for every target those two would fail without changing any of the >> other ones. >> >> >> >> >> >> On Thu, Nov 19, 2020 at 2:04 AM Alastair Campbell < >> *acampbell@nomensa.com* <acampbell@nomensa.com>> wrote: >> >> HI Wilco, >> >> >> >> That’s great! Thanks for putting that together. >> >> >> >> > Unfortunately, none of the proposals actually gets all of them right. >> >> >> >> I think we might need to discuss ‘right’ in this context. >> >> >> >> The previous wording from the FPWD did allow examples like E3/E4 assuming >> there were no other targets to consider: >> >> <image007.png> >> >> >> >> But is that a good thing? The newer wording means that the proximity of >> the small targets to another target causes a fail. I think that aligns with >> the intent. >> >> >> >> When we get down to the overlapping examples I’m not sure that >> interpretation is correct? >> >> >> >> Taking H3 as an example: >> >> <image008.png> >> >> The red square is 60 wide, the green is 24 + 12 left-padding, so there is >> 24px of the parent on the right-hand side. >> >> >> >> With a wording of “*For each target, the distance from each adjacent >> target to the farthest edge of the current target is at least 24 CSS pixels >> except when*” >> >> >> >> The green target fits the exception bullet, but for the red one: >> >> - We can consider the green target as “adjacent”; >> - The farthest edge of the red target from the green target is 24px – >> pass. >> >> I agree that H4 would fail, and I think most of the others. I’m not clear >> about L2, I can’t see how much space is between those circles? For a circle >> I think we have to treat the furthest point as the ‘edge’. >> >> >> >> Kind regards, >> >> >> >> -Alastair >> >> >> >> >> >> *From:*Wilco Fiers <*wilco.fiers@deque.com* <wilco.fiers@deque.com>> >> *Sent:* 18 November 2020 16:16 >> *To:* Alastair Campbell <*acampbell@nomensa.com* <acampbell@nomensa.com>> >> *Cc:* Michael Gower <*michael.gower@ca.ibm.com* >> <michael.gower@ca.ibm.com>>; WCAG list (*w3c-wai-gl@w3.org* >> <w3c-wai-gl@w3.org>) <*w3c-wai-gl@w3.org* <w3c-wai-gl@w3.org>> >> *Subject:* Re: Target spacing refinement >> >> >> >> Hey folks, >> >> I did what I always do when rules get too complex. I write test cases. >> Here's what I wrote. I used color gradients to indicate passes and fails. >> Light green to dark green is passed, dark red to pink is fail. >> >> *https://codepen.io/wilcofiers/pen/abZxPow* >> <https://codepen.io/wilcofiers/pen/abZxPow> >> >> >> >> Unfortunately, none of the proposals actually gets all of them right. So >> this is going to need more work. I'll see if I can come up with a proposal >> that gets all cases right. Probably worth for folks to have a look, see if >> we're all in agreement on these. Maybe most noteworthy are E3 and E4. Those >> corner blocks pass with the currently published SC text, but they fail in >> all of the new . >> >> >> >> >> >> >> >> On Wed, Nov 18, 2020 at 4:41 PM Alastair Campbell < >> *acampbell@nomensa.com* <acampbell@nomensa.com>> wrote: >> >> Hi Michael, >> >> >> >> Tackling the second one: >> >> > *The distance from each target's mid-point to the mid-point of >> adjacent targets is at least 24 CSS pixels, expect when...* >> >> >> >> Measuring from mid-points allows for tiny targets next to larger ones, >> e.g: >> >> <image009.png> >> >> >> >> Although easier to understand (slightly), I don’t think it aligns to the >> goal quite as well. >> >> >> >> For the re-write of option 5, I think it would need to start with the >> thing you are evaluating, e.g: >> >> *For each target, the distance from each adjacent target to the farthest >> edge of the current target is at least 24 CSS pixels except when:* >> >> >> >> If others think that scans ok, I’m happy with that. >> >> >> >> Regarding the ‘objectives’, I think we can easily include that on the new >> understanding docs at the top of the intent, and work back through the >> 2.1/2.0 docs later. >> >> The upcoming re-design looks like this for the understanding doc: >> >> >> *https://w3c.github.io/wai-wcag-supporting-documents-redesign/2020-07-15-prototype-understanding.html* >> <https://w3c.github.io/wai-wcag-supporting-documents-redesign/2020-07-15-prototype-understanding.html> >> >> >> >> We can add a CSS class to the objective paragraph and work out the >> styling in parallel. >> >> >> >> Cheers, >> >> >> >> -Alastair >> >> >> >> >> >> *From:*Michael Gower >> >> >> >> I agree option 5 *seems *to scan best, but I also think there is a >> missing preposition. There are 2 ideas here: >> 1) we are talking about the edge *farthest from* an adjacent target >> 2) we are talking about the distance* from *that edge *to* the adjacent >> target (or *between *them) >> >> So I think we need 2 prepositions, one to describe which edge and one to >> describe the distance *between* two points. i think a rejig of the >> sentence still allows that to scan okay: >> *The distance from each adjacent target to the farthest edge of the >> current target is at least 24 CSS pixels.* >> >> I think we need to bear in mind that this is a design-centric >> consideration. As such, it is even more important to get the >> language/concept simple. As such, I want to advocate for a variation I >> pasted into the channel yesterday: >> >> *The distance from each target's mid-point to the mid-point of adjacent >> targets is at least 24 CSS pixels, expect when...* >> >> AWK said that this wouldn't work for some edge cases, but I'd like to see >> some examples to understand what gets through the net. >> >> Regardless of wording, this is another SC where a quick blurb summarizing >> the objective would help with rapid comprehension. For instance: >> *Objective: Ensure separation of targets for ease of operation.* >> I wrote such blurbs for all the 2.1 additions, which were supposed to be >> included in the Understanding documents, but were never incorporated. >> >> Michael Gower >> Senior Consultant in Accessibility >> IBM Design >> >> >> 1803 Douglas Street, Victoria, BC V8T 5C3 >> *gowerm@ca.ibm.com* <gowerm@ca.ibm.com> >> cellular: (250) 661-0098 * fax: (250) 220-8034 >> >> >> >> From: Alastair Campbell <*acampbell@nomensa.com* >> <acampbell@nomensa.com>> >> To: "WCAG list (*w3c-wai-gl@w3.org* <w3c-wai-gl@w3.org>)" < >> *w3c-wai-gl@w3.org* <w3c-wai-gl@w3.org>> >> Date: 2020/11/17 04:34 PM >> Subject: [EXTERNAL] Target spacing refinement >> ------------------------------ >> >> >> >> >> Hi everyone, After the long discussion on target spacing today,... >> >> >> >> >> *This Message Is From an External Sender* >> This message came from outside your organization. >> >> Hi everyone, >> >> >> >> After the long discussion on target spacing today, I tried to collate the >> options into one place and add a couple of diagrams: >> >> >> *https://docs.google.com/document/d/1Q9zWT1OjdCrts2xuadVEaJ2wpyLzxnysFQCSTs72L2o/edit?usp=sharing* >> <https://docs.google.com/document/d/1Q9zWT1OjdCrts2xuadVEaJ2wpyLzxnysFQCSTs72L2o/edit?usp=sharing> >> >> >> >> Personally, I’m leaning towards option 5 as the simplest which measures >> the size+spacing of the target, which would be: >> >> >> >> For each target, the distance of the target’s edge farthest from each >> adjacent target is at least 24 CSS pixels, except when: >> >> - [3 bullets unchanged] >> - *Nested:* The target is enclosed within another target and has a >> minimum height and width of 24 CSS pixels. >> >> >> >> If you’d like to add something (options, positives/negatives, diagrams >> etc) please let me know and I’ll add you as an editor of the doc. It is >> open for comments. >> >> >> >> Kind regards, >> >> >> >> -Alastair >> >> >> >> -- >> >> >> >> @alastc / *www.nomensa.com* <http://www.nomensa.com/> >> >> >> >> >> >> -- >> >> *Wilco Fiers* >> >> Axe-core product owner - Co-facilitator WCAG-ACT - Chair ACT-R >> >> >> >> Join me at *axe-con* <http://deque.com/axe-con>2021: a free digital >> accessibility conference. >> >> >> >> -- >> >> *Wilco Fiers* >> >> Axe-core product owner - Co-facilitator WCAG-ACT - Chair ACT-R >> >> >> >> Join me at *axe-con* <http://deque.com/axe-con>2021: a free digital >> accessibility conference. >> >> >> >> >> -- *Wilco Fiers* Axe-core product owner - Co-facilitator WCAG-ACT - Chair ACT-R Join me at axe-con <http://deque.com/axe-con> 2021: a free digital accessibility conference.
Attachments
- image/gif attachment: deque_logo_180p.gif
Received on Thursday, 19 November 2020 16:24:57 UTC