Re: Target spacing refinement

Sarah, you are right. Having both would be the ideal solution but we ran
into two problems - a baseline of below 24 wouldn't make sense for the
overall size given the research we looked at, and having that baseline
would break most sites overnight for cases even where targets are isolated
and there is less chance of hitting the wrong one.

We tried to address the reverse incentive problem by not allowing space to
be shared. One thing we can and should do, as you and Alaistar pointed out
in the meeting is say that the easiest way to meet this SC is to have a
24X24 target at the very top of the understanding document.

On Thu, Nov 19, 2020 at 10:40 AM Sarah Horton <sarah.horton@gmail.com>
wrote:

> Sometimes I find it helpful to look at the intents of SCs, which are
> really good (kudos and a big thank you to WCAG 2.x authors!).
>
>    - SC 2.5.5: Target Size (AAA): The intent of this success criterion is
>    to ensure that target sizes are large enough for users to easily activate
>    them, even if the user is accessing content on a small handheld touch
>    screen device, has limited dexterity, or has trouble activating small
>    targets for other reasons.
>    - SC 2.5.8: Pointer Target Spacing (AA): The intent of this Success
>    Criterion is to ensure targets can easily be activated without accidentally
>    activating an adjacent target.
>
> With 2.5.8 Pointer Target Spacing as a Level AA SC, we are essentially
> saying, we are going to try to address through guidelines the issue of
> accidentally activating an adjacent target, and we are going to do that by
> measuring the distance between targets. At Level AA, we are only
> addressing issues related to adjacent targets, and only the
> space between them. We are not attempting to address issues related to
> small targets or issues related to individual targets that do not have
> adjacent targets at Level AA. Those issues we address at Level AAA.
>
> I suppose addressing any issue with a Level A or AA SC is progress, since
> those SCs are effectively the ones that have an impact. So I can stand
> down, but I do feel we could do better addressing both use cases. And I
> hope we can get the wording right, so people don’t misinterpret the SC and
> make smaller targets in order to meet the requirement, thinking, “It’s the
> spacing that matters, not the size!” I know that’s not what’s intended, but
> it could be what happens if the language and measurements aren’t
> straightforward.
>
> Thanks for all the hard work on this, everyone!
>
> Best,
> Sarah
>
>
> On Nov 19, 2020, at 12:57 PM, Alastair Campbell <acampbell@nomensa.com>
> wrote:
>
> 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.
>
>
>