W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2017

RE: Target Size SCs issue feedback

From: Joshue O Connor <josh@interaccess.ie>
Date: Fri, 26 May 2017 17:22:22 +0100
To: "Repsher, Stephen J" <stephen.j.repsher@boeing.com>, WCAG <w3c-wai-gl@w3.org>
Message-Id: <20170526162238.82DC78A6DAA@relay.mailchannels.net>
Thanks Steve. Actually, in my book  it's good that you call this out :-} 
I'm not sure where / if this had been commented on. Maybe someone else can give a steer on that? 
Thanks 
Josh 
InterAccess - Accessible UX
-------- Original message --------From: "Repsher, Stephen J" <stephen.j.repsher@boeing.com> Date: 26/05/2017  15:53  (GMT+00:00) To: Joshue O Connor <josh@interaccess.ie>, WCAG <w3c-wai-gl@w3.org> Subject: RE: Target Size SCs issue feedback 


Josh,
 
Ø
Steve Repsher said:

>> The little testing it has undergone has turned up several issues, namely focus highlights and >overlap, Which have the potential to end up creating significant inaccessibility.  However, if the


>> technique is to use a 44 pixel line, then I’ll support it.



> Thanks for the suggestion. In terms of your request for clarification but I see that Kathy did reply.




To add some context to the sentence you quoted me on, I was talking specifically about the CSS padding and negative margin technique that had been proposed to
 handle links within blocks of text.  Yes, Kathy replied that this would no longer be used for the AA version, but my objection is for the AAA version.  What technique do we plan to document to make 44 pixel targets within blocks of text?
 
I find it hard to believe I’m the only one not concerned about this, but perhaps I’m missing where on list or on GitHub the issues with this technique were thoroughly
 discussed and resolved.  Yes, it’s AAA, but it’s still an SC that needs accessible techniques.
 

Steve

 


From: Joshue O Connor [mailto:josh@interaccess.ie]


Sent: Friday, May 26, 2017 6:16 AM

To: WCAG <w3c-wai-gl@w3.org>

Subject: Target Size SCs issue feedback


 

Hi all,



I'm moving this out of the CFC thread - we'd like those threads to be reserved for indications

of support (or not) of the CFC in question and not for detailed technical discussion.



I'll start to address some of the comments (others can chime in also).



Thanks for the those point Gregg - Gregg mentioned Zoom vs Magnification - and this is interesting as we have been discussing that we need a 'definition of Zoom' - that has arisen from current work on a different SC. I guess most people would see them as the
 same.



Regarding your comments on 'links' etc - we do (as Detlev pointed out) have concerns that we don't want to exempt too much from the SC, as this would reduce its impact but others may comment on the issue you raise around links. Note, we have updated the exemptions
 so do have a look and see if that addresses your concerns. [1]



Steve Repsher said:



> The little testing it has undergone has turned up several issues, namely focus highlights and >overlap, Which have the potential to end up creating significant inaccessibility.  However, if the


> technique is to use a 44 pixel line, then I’ll support it.



Thanks for the suggestion. In terms of your request for clarification but I see that Kathy did reply.



There are differences of opinion here but this SC is trying to address a user need, and can for sure be iterated and improved by the group over the coming months - but at this stage the group consensus is that this is ready to go.



Thanks



Josh



[1] 
https://rawgit.com/w3c/wcag21/target-size_ISSUE-60/guidelines/sc/21/target-size.html








Gregg said:

> This appears to include links




There are two exemptions now 'Equivalent: The target is available through an equivalent link or control on the same page that is at least 44 by 44 CSS pixels.' and 'In-Page: The target is a text link where the destination is on the same page.' as well as the
 final exemption 'User agent control: The appearance of the target is determined by the user agent and is not modified by the author.'

1.  
If not - then why is it important to have these large and not links.  If they can’t operate the links why is it important to operate these

2.  
if it DOES include links then we are forcing authors to never have small links on the page - even at the very bottom.  Everything has to be big.    

3.  
(check my math but does this mean that all links on a page have to be in something like 33 point font?   That can’t be right — too late at night but that is what
 the online calculator says 44px would be)

2.  
Why does the author have to make these big for everyone — when users can easily (if the content meets other SC) just use the  CTRL+  (or equiv)  to make everything
 bigger so they can use it.    

1.  
why force everyone to have things large when it is so easy for the user who needs it to make theirs larger?

2.  
 

3.  
Why does “customizable” exception exclude magnification.   Does this mean ZOOM is ok but Magnification is not?  

1.  
if ZOOM is OK   then maybe it should say  “ 



·      
Customizable: A mechanism is available to change the size of the target independent
 of the level of page magnification but not independent of Zoom.



 



(if I am missing something let me know)










--


Joshue O Connor

Director | InterAccess.ie 
Received on Friday, 26 May 2017 16:23:10 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 08:04:10 UTC