RE: Revised Pointer Target Spacing

Hi David,

I generally agree. I’d probably balance your points with: There is a clear user-need to avoid small targets for people with certain mobility impairments.

In terms of next steps, I don’t see much value in a fall-back SC on non-interference. You’d have to go through some large contortions to pass reflow & text-size and fail such an SC.

I think the Mobile TF are looking at this, and whatever they come back with we can put to the commenters and see if it works.

Cheers,

-Alastair


From: David MacDonald <david@can-adapt.com>
Sent: 24 September 2020 11:04
To: Alastair Campbell <acampbell@nomensa.com>
Cc: w3c-wai-gl@w3.org
Subject: Re: Revised Pointer Target Spacing

Hi Alastair

I've been out of the issue loop over the last month because of an inter city move of home and office... now having read through the threads, yes there are significant issues with the SC.

  1.  high impact on designers (which is always hard to sell)
  2.  Some believe it has the highest impact on conformance of existing sites of all the new SCs since WCAG 2.0
  3.  high impact on testing, which increases the cost of audits for companies
  4.  It appears that the benefits are questionable in a world where browser zoom is highly customizable
  5.  There are significant questions about whether it might end up with a negative impact on target size
  6.  With the new 26px by 26px proposal, issue #1 above is minimized but issues #2-4 above seem to remain, especially #3 & 4
Some studies have suggested that for people with difficulties around motor control of the arm and/or hand, that 100px is the minimum target size. It seems like we may need to rely on personalization settings, browser AT (that increase button sizes on the client side) .

I see the options as:

  1.  put it out there with the Mobile TF 26px proposal
  2.  Introduce a fallback SC that basically says, "don't interfere with the user's attempt to increase button size" (like the text spacing SC 1.4.12)
  3.  drop the SC and focus our time on other more viable improvements for 2.2 noting that we ran into these same issues when trying to make this SC work for 2.1

Cheers,

David MacDonald



CanAdapt Solutions Inc.
Mobile:  613.806.9005

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd<http://twitter.com/davidmacd>

GitHub<https://github.com/DavidMacDonald>

www.Can-Adapt.com<http://www.can-adapt.com/>



  Adapting the web to all users
            Including those with disabilities

If you are not the intended recipient, please review our privacy policy<http://www.davidmacd.com/disclaimer.html>


On Thu, Sep 24, 2020 at 4:27 AM Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>> wrote:
> What if we leave it out there for another draft round and see what
> comes back?

We've had some fairly tricky issues raised for which we don’t have an answer, except an update to the SC text.
https://github.com/w3c/wcag/issues?q=is%3Aissue+is%3Aopen+label%3A%222.5.8+Pointer+Target+Spacing%22

(Particularly #1361 & #1384.)

I'd be inclined to go back to those commenters with an updated version, if we can document the rational for the size.

-Alastair