Skip to content
This repository has been archived by the owner on Jun 30, 2018. It is now read-only.

The Paciello Group comment on 2.5.3 Target Size #701

Closed
patrickhlauke opened this issue Jan 12, 2018 · 2 comments
Closed

The Paciello Group comment on 2.5.3 Target Size #701

patrickhlauke opened this issue Jan 12, 2018 · 2 comments

Comments

@patrickhlauke
Copy link
Member

This SC seems to exempt more than it specifies.

User Agent Control: The size of the target is determined by the user agent and is not modified by the author.

This leaves a few questions open:

  • what if an author chooses an image which is smaller than 44x22 CSS pixels, and - without any modification - wraps a link around it? Does this exception exempt that image link from needing to be 44x22, since the author hasn't "modified" the target? Is it not the type of content (its rendered size) that matter?
  • what specifically counts as "modified by the author"? If an author sets a very high-level CSS style that just minimally changes the default font size (e.g. body { font-size: 0.99em; }) does that count as "modified by the author" (as it affects the actual rendered size of both static and interactive text, the size of <button> elements, etc)? Where is the line drawn?

Fundamentally, users that find controls too small to accurately click/tap can zoom in (provided zooming isn't counteracted in some way). While zooming does not change the CSS pixel dimensions, it still renders everything larger (CSS pixel to hardware pixel ratio changes, real-world - as measured on screen - dimensions increase), meaning a user can very easily make previously hard to click/tap targets large enough for their needs. This would obviously not work in situations where content is prevented from zooming, but as most user agents (including on mobile) now either ignore things like user-scalable=no in viewport meta, or provide the user with an option to ignore it, and there are no other mechanisms for web content to "lock" a particular size, it seems there's a fairly common standard way for users to ensure they can always tap/click. It may not be user-friendly, but this feels like it veers into trying to codify a usability recommendation into a hard accessibility requirement. The ability/inability of users to zoom into content also crosses over with the proposed SC 1.4.10 Reflow, which requires content to be zoomable/scalable up to 400% on desktop.

There's uncertainty about whether this SC can be met by offering a setting/option (e.g. a switch to change from "mouse optimized" to "touch optimized", as is the case in software like MS Word), or to use other means (e.g. checking for presence of a touchscreen) to determine if targets should be rendered at a particular (larger) size.

In light of these two points, would it be more appropriate to:

  • keep the first exception (about alternatives)
  • drop the other exceptions
  • instead include "A mechanism is available..." type language? This would require some consideration - since, as stated above, zooming does not alter the actual CSS pixel dimensions.

As a side note, since the SC leans on Apple/Google/Microsoft guidance for (native) apps: note that in these guides, the minimum target size is suggested, often for "important" controls, and Apple etc break their own guidance in certain situations.

@awkawk
Copy link
Member

awkawk commented Jan 12, 2018

Thanks you for your comment. The deadline for comments has passed, but the Working Group will make efforts to consider your comment and any suggestions for improvements.

@awkawk
Copy link
Member

awkawk commented Jan 24, 2018

(Official WG Response)
Thank you for the comment. The Working Group was not able to reach consensus on Target Size, and as a result the Target Size (SC) is now removed from the Editor's Draft. The Target Size (Enhanced) SC at AAA will be renamed to "Target Size".

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants