Re: CFC - Target Size AA and AAA, and comment responses

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