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 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> 
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
cellular: (250) 661-0098 *  fax: (250) 220-8034



From:        Alastair Campbell <acampbell@nomensa.com>
To:        Sarah Horton <sarah.horton@gmail.com>
Cc:        Wilco Fiers <wilco.fiers@deque.com>, "WCAG list (
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) 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> 
Sent: 19 November 2020 11:22
To: Alastair Campbell <acampbell@nomensa.com>
Cc: Wilco Fiers <wilco.fiers@deque.com>; WCAG list (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> 
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> 
Sent: 19 November 2020 10:36
To: Alastair Campbell <acampbell@nomensa.com>
Cc: WCAG list (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> 
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> 
Sent: 18 November 2020 16:16
To: Alastair Campbell <acampbell@nomensa.com>
Cc: Michael Gower <michael.gower@ca.ibm.com>; WCAG list (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

 
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> 
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

 
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
cellular: (250) 661-0098 *  fax: (250) 220-8034



From:        Alastair Campbell <acampbell@nomensa.com>
To:        "WCAG list (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

 
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
 
 
--
Wilco Fiers
Axe-core product owner - Co-facilitator WCAG-ACT - Chair ACT-R
 
Join me at axe-con2021: a free digital accessibility conference.
 
-- 
Wilco Fiers
Axe-core product owner - Co-facilitator WCAG-ACT - Chair ACT-R
 
Join me at axe-con2021: a free digital accessibility conference.