- From: Sukriti Chadha <sukriti1408@gmail.com>
- Date: Thu, 19 Nov 2020 12:09:40 -0500
- To: Wilco Fiers <wilco.fiers@deque.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: <CAAbHSgj3LKbH2xur5hr5f5Y_tgDBtQGWmP1Y9tpZR3PqUKzY0g@mail.gmail.com>
*For all adjacent targets, the farthest point of one target is at least 24 CSS pixels away from the other target, except if:* I see what you're saying. Definitely agree that the understanding document will help clarify. The current wording (above) still remains ambiguous with level 1 confusion of what is 'one' and what is 'other' and level 2 runs into the same problem as the second wording of not specifying where on the 'other target' and might be interpreted as picking one point. How's this? *For each target, the farthest point on the target is at least 24 CSS pixels away from any point on each adjacent target, except if : * On Thu, Nov 19, 2020 at 11:38 AM Wilco Fiers <wilco.fiers@deque.com> wrote: > Sorry, accidental send.... > > *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 here is that it now suggests to pick one point in the target > that is furthest away from every adjacent target, instead of picking a > different point for each adjacent target. I understand the lack of > specificity in what I'm suggesting, but this language is accurate. I think > the way to create more clarity on how to test this is better done in the > understanding document. > > Wilco > > > On Thu, Nov 19, 2020 at 5:24 PM Wilco Fiers <wilco.fiers@deque.com> wrote: > >> 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. >> > > > -- > *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. >
Received on Thursday, 19 November 2020 17:10:08 UTC