Re: target size

It doesn't strike me as an easily solvable problem in a User agent. It
seems like something to be incorporated at the design level.

But there may be another way to look at it. If linearization goes through
and zooming goes through, it is presumable that link targets sizes could
increase also in a way that doesn't cause horizontal scroll. Then people
with dexterity problems would be magnifying the screen just because they
couldn't hit a button rather than for a vision reason, which seems like it
would be frustrating for them. But the target would indeed be bigger.


Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*
Mobile:  613.806.9005

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

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 Wed, Apr 12, 2017 at 3:23 PM, White, Jason J <jjwhite@ets.org> wrote:

> 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
>
>
>
>
>
>
>
> On Apr 12, 2017, at 2:31 PM, David MacDonald <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
>
>
>
> *Can**Adapt* *Solutions Inc.*
>
> Mobile:  613.806.9005 <(613)%20806-9005>
>
> LinkedIn
> <http://www.linkedin.com/in/davidmacdonald100>
>
> 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.
> ------------------------------
>