- From: Detlev Fischer (TK) <detlev.fischer@testkreis.de>
- Date: Wed, 6 Dec 2017 11:02:04 +0100
- To: w3c-wai-gl@w3.org
Hi Patrick, the reason no one else is taking this up is probably general fatigue on the last mile. I think you raise valid points and would like to see your concerns addressed (where possible) while still keeoing some form of this SC on level AA. I'll take your points one by one, between the lines. Am 05.12.2017 um 14:15 schrieb Patrick H. Lauke: > Even though the CFC on this has passed (was busy on project work to > follow through), and the SC was passed anyway, would still be > interested in some actual answers or justifications to the queries below. > > P > > On 28/11/2017 20:39, Patrick H. Lauke wrote: >> On 28/11/2017 20:01, Andrew Kirkpatrick wrote: >>> Call For Consensus — ends Thursday November 30th at 2:45pm Boston time. >>> >>> The Working Group has discussed changes to Target Size (AA) and >>> Target Size (Enhanced) (AAA), as well as approving comment responses >>> for these SC. >>> >>> The specific changes are detailed in this pull >>> request: https://github.com/w3c/wcag21/pull/592 >>> >>> Call minutes: https://www.w3.org/2017/11/28-ag-minutes.html#item05, >>> https://www.w3.org/2017/11/28-ag-minutes.html - item06 >>> <https://www.w3.org/2017/11/28-ag-minutes.html#item06>, >>> https://www.w3.org/2017/11/28-ag-minutes.html#item07 >>> >>> If you have concerns about this proposed consensus position that >>> have not been discussed already and feel that those concerns result >>> in you “not being able to live with” this decision, please let the >>> group know before the CfC deadline. >> >> Still of the belief that, though better than before, this SC at AA is >> problematic. >> >> Circling back to the discussions in the call, per the minutes, it's >> noted that 44x44 / 48x48 are industry standards. That is true, but >> I'd add that these are standards (which are worded more as >> recommendations - for instance, Apple's HIG state "Try to maintain a >> minimum tappable area of 44pt x 44pt for all controls", emphasis on >> "Try to") that are mainly aimed at native applications on touch >> devices. Native applications do not provide pinch-zoom, whereas web >> content does. Even in desktop browsers, with a mouse, users that have >> trouble confidently activating a link/control can full-page-zoom and >> make the targets bigger. In both cases, web content users have >> built-in mechanisms to enlarge small targets. While designing targets >> to be "large enough" in the first place is a great usability advice, >> I'm still not seeing specifically why it needs to be a hard pass/fail >> criterion. Further, noting that even Apple, Google, etc themselves >> break their own guidelines/suggestions when they deem it >> necessary/applicable. I have to admit that even with the current exception for targets in blocks of text, the SC can be hard to meet for all controls when the interface gets complex. It can lead to sub-optimal arrangements of controls from a usability perspective because there isn't enough space for them when going to 44x22, forcing solutions like the hiding of targets in pop-up sections that first have to be revealed before the intended function becomes available, adding one extra actions as compared to a layout that put all what is needed for a task in front of the user's eye. But I believe in many other cases, authors having to design for large targets will mean that less can be squeezed onto the viewport which will encourage simplification to the benefit all users (not just low-vision people but also, for example, people with cognitive impairments). So it is a trade-off. >> >> Does the SC, as worded now, allow for an interface/site to provide >> different interfaces, one of which has the required target sizes? If >> a site implemented, say, media queries that check for the presence of >> coarse and fine pointers, and only showed smaller targets if no >> coarse pointer (e.g. touchscreen) was detected, would it pass or >> fail? If a site offered an explicit setting or switch to go into a >> "touch-friendly" layout, would that be sufficient? My answer would be a clear yes - covered by the conforming alternate version option in Conformance requiremnt 1. >> >> "The size of the target is determined by the user agent and is not >> modified by the author." >> >> The simple act of defining a base font size for html/body would >> constitute a modification by the author, no? While yes, the >> understanding document can clarify when/how/what "modified by the >> author" means, I'm worried that the normative SC text is fairly wooly >> and unclear here and quite open to very wide, as well as very narrow, >> interpretation. In Firefox, Chrome and IE, increasing the base font size has no effect on the size of natively small controls like input type=radio and input type=checkbox see, for example http://www.3needs.org/en/testing/code/wohngeld.html (checkbox right at the bottom) where I cranked up fase font size via body {font-size:2.5em}. >> >> "A particular presentation of the target is <a>essential</a> to the >> information being conveyed" >> >> What scenarios are there? A pixel-hunting game (where only a tiny >> area in a large image is clickable)? Other? Yes, I guess we are mostly in games territory. Some people may want to claim the essential exception for things like a slider thumb (for more precision), the (draggable) symbol for a tab stop in a word processing app, or a sorting control in a table header. Not sure where exactly to draw the line here - I hope that could be dealt with in the understanding text rather than leading to SC bloat. >> >> P > >
Received on Wednesday, 6 December 2017 10:02:36 UTC