Re: Target spacing refinement

This one solves it IMO. Thank you Alastair!

On Thu, Nov 19, 2020, 12:58 PM Alastair Campbell <acampbell@nomensa.com>
wrote:

> I think it helps to establish the focus at the start with “For each
> target”.
>
>
>
> The problem is that we can be dealing multiple adjacent targets, so the
> “furthest point” changes depending on the adjacent targets. I.e. it will be
> a different point for each adjacent target.
>
>
>
> Starting with the “furthest point” makes it seems like there is only one.
>
>
>
> Does swapping it around help?
>
> *For each target, the distance from the closest point of each adjacent
> target to the farthest point of the current target is at least 24 CSS
> pixels, except when:*
>
>
>
> When it is that way around it implies: “…to the farthest point of the
> current target *[from the adjacent target]* is at least 24 CSS pixels”.
>
>
>
> -Alastair
>
>
>
>
>
> *From:* Sukriti Chadha <sukriti1408@gmail.com>
> *Sent:* 19 November 2020 17:11
> *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>
> *Subject:* Re: Target spacing refinement
>
>
>
> This might be better
>
>
>
> *For a target, the farthest point on the target is at least 24 CSS pixels
> away from any point on each of its adjacent target, except if : *
>
>
>
> On Thu, Nov 19, 2020 at 12:09 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:*
>
>
>
> 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>
> 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-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.
>
>