RE: target size

I would like to raise the question of whether this important problem could be better solved by user agents, or, if this is infeasible in the short term, by an assistive technology - possibly implemented as a browser extension.

Unfortunately, the W3C is not currently working on user agent guidelines, a situation that may change in the future depending on the scope of Silver. I am concerned that this creates undue pressure to address user requirements within WCAG even if a better solution could be implemented in user agents at less cost and with higher reliability.

Every requirement added to WCAG 2.1 creates additional work for Web content (including Web application) authors. It also creates ample opportunities for some of them - probably a large number of them - to make more or less serious mistakes. If a user agent or assistive technology can solve a problem, there only need to be a small number of high-quality implementations (by contrast with a large number of implementations of variable quality if the responsibility is placed on content creators).

It's necessary to make careful strategic decisions about where and by whom a problem is best solved. In some cases, it's best outside of WCAG.

From: Gregg C Vanderheiden [mailto:greggvan@umd.edu]
Sent: Wednesday, April 12, 2017 2:34 PM
To: David MacDonald <david@can-adapt.com>
Cc: w3c-waI-gl@w3. org <w3c-wai-gl@w3.org>; public-mobile-a11y-tf@w3.org
Subject: Re: target size

I think it is a great place for advice
a bad place for requirements

g



Gregg C Vanderheiden
greggvan@umd.edu<mailto:greggvan@umd.edu>



On Apr 12, 2017, at 2:31 PM, David MacDonald <david@can-adapt.com<mailto:david@can-adapt.com>> wrote:

I would like to see us get something into WCAG 2.1 on target size. Mobile guidelines address it and mobile accessibility guidelines such as the BBC also address it. However, we have a higher bar on testability and applying across technologies etc..  I don't think we should punt this SC to Silver, because the primary reason given for a WCAG update was mobile, and this is a fundamental issue with mobile. It would be a huge hole to ignore it because we couldn't come to consensus on this version.

There seem to be 2 ways we could approach it here in 2017

1) Make a wide SC with exceptions and not too hard sizes to implement applicable to all content and all views.
2) Use the viewport size as a threshold with larger target requirements and fewer exceptions on screen sizes that are more likely to be used with a finger.

I'm in favour of the 2nd solution, viewport size.  However, I understand objections to this approach:
1. many feel there is "no such thing as mobile" and
2. target size is important on big screens too
3. its hard to determine screen size because of resolutions ... etc

So I'm ok with coming to a consensus on the first item. I think we're close to consensus on the first one. But to get consensus I think it needs to be easier for menus (22x22 minimum) and an exception for

The size of the target at the default viewport size is at least 44 by 44 CSS pixels for pointer inputs except where:

- a mechanism is available to change the size of the target
- the target is available through an equivalent link or control that is at least 44 by 44 CSS pixels
- the target cannot be 44 by 44 CSS pixels due to mandatory layout
- the target is an in-page link
- the target is embedded in a block of text or is part of group of navigation links
- the target is controlled by the user agent and cannot be modified

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>


________________________________

This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.


Thank you for your compliance.

________________________________

Received on Wednesday, 12 April 2017 19:24:16 UTC