Re: CFC: Target Size and Target Size (no exception) SC

hmmmm

all of these seem to be ways to make the SC work on pages by making the links unusable to the target population.


MY QUESTION:   Why are we adding this SC?

IS THE ANSWER?:   ??Because this group of users cannot use clickable elements that are smaller than  44 px???  (or 100 px by Davids last comment)


SO WHERE IS THE LOGIC — of having an SC that only requires SOME of the items on the page to be large enough for the user to operate but not the rest of the items (including all links) on the page. 
and on top of that, we keep excluding more and more things each time they look unreasonable — further reducing the amount of the page that these people can use. 


If feels like TOKENISM.  ( e.g.   "well, it is better to do something for this group even if it doesn’t really give them access to the page” )


I started my career working with people with physical disabilities like CP — and have a number of friends with CP.   And in WCAG I was looking for both Cognitive and Physical SC to add.   
 But giving people access to part of the page but not the rest — seems like it is of little use. 



ALSO why doesn’t just enlarging the page - and thus making the targets larger - solve the problem?    There is already an SC to enlarge the page - which would do this also? 
someone posted that in mobile you can’t enlarge the page with word wrap — but if that is true — how do we solve the other SC?    (also in mobile — is 44 px any where near as large as it is on a full size screen?   
and if not — then how do they use it if they need 44 px?


confused and feeling we are just trying to do something — without really doing something that is meaningful.  That is a token without real value.  But it makes page design harder. 


This is the end of my discussion of this topic until next draft release.   I find I am repeating myself and that is not useful. 

g 

Gregg C Vanderheiden
greggvan@umd.edu




> On May 29, 2017, at 9:41 AM, David MacDonald <david100@sympatico.ca> wrote:
> 
> Another option for an exception to address Gregg's concern could be
> 
> - the target in part on a group of more than 10 navigation elements
> 
> The rationale being that if there are less than 10 links in the group there is not much good ui rationale for squishing links together... but when there are a lot of links then the user without a disability is being punished by the space because they have to scroll and links are not in view
> 
> 
> On Mon, May 29, 2017 at 8:37 AM Detlev Fischer <detlev.fischer@testkreis.de <mailto:detlev.fischer@testkreis.de>> wrote:
> Some evidence. I have gone through recent tests, picked nine sites and one page for each site, made screenshots, and checked where target size might be an issue:
> 
> http://www.3needs.org/en/testing/target-size.html <http://www.3needs.org/en/testing/target-size.html>
> 
> These are the nine most recent tests some of them not final conformance tests but design support tests, so I have not been cherry-picking. To be sure, these sites made an effort to be accessible. So they may be a fair representation of the site owners that are ether required by law to meet WCAG (or derivatives of WCAG).
> 
> Result: In my sample of relatively recent sites, most seem to meet the target size SC already (or at least largely). Issues appear in submenus and a few times around breadcrumbs but these should be easy to fix.
> 
> --
> Detlev Fischer
> testkreis c/o feld.wald.wiese
> Thedestr. 2, 22767 Hamburg
> 
> Mobil +49 (0)157 57 57 57 45
> Fax +49 (0)40 439 10 68-5
> 
> http://www.testkreis.de <http://www.testkreis.de/>
> Beratung, Tests und Schulungen für barrierefreie Websites
> 
> David MacDonald schrieb am 29.05.2017 14:23:
> 
> >
> > ​> ​look at the side menu - before and after.  we can do this - but I think we are just dooming 2.1 to be referred to at the unrealistic guidelines.
> >
> >
> > I have to agree it's a huge ask. Originally it was a mobile requirement, which everyone agrees on, but we couldn't define mobile, and so it morphed into desktop with the additional reason that it may help those who have trouble activating interactive elements on desktop.
> >
> >
> > However, the user testing we looked at indicated that most people with significant dexterity problems needed target sizes of 100px.
> >
> >
> > I had proposed exceptions for both inline links and groups of navigation links,  with the goal of balancing the huge UI burden on the author against the burden of zooming into navigation groups (which is less of a burden than zooming into text).
> >
> >
> > Two ways out of this iscould be
> >
> >
> > 1) to add an exception for navigation groups.
> >
> > 2) base the requirement on breakpoints, CSS pixel width of the display, which is a measurement that we are coalescing around.
> >
> >
> > Otherwise, we may want to punt it to Silver.
> >
> >
> > Cheers,
> > David MacDonald
> >
> >
> >
> > CanAdapt Solutions Inc.
> >
> > Tel:  613.235.4902
> >
> > LinkedIn  <http://www.linkedin.com/in/davidmacdonald100 <http://www.linkedin.com/in/davidmacdonald100>>
> >
> >
> > twitter.com/davidmacd <http://twitter.com/davidmacd> <http://twitter.com/davidmacd <http://twitter.com/davidmacd>>
> >
> > GitHub <https://github.com/DavidMacDonald <https://github.com/DavidMacDonald>>
> >
> > www.Can-Adapt.com <http://www.can-adapt.com/> <http://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 <http://www.davidmacd.com/disclaimer.html>>
> >
> >
> > On Sun, May 28, 2017 at 5:30 PM, Gregg C Vanderheiden <greggvan@umd.edu <mailto:greggvan@umd.edu> <mailto:greggvan@umd.edu <mailto:greggvan@umd.edu>> > wrote:
> >>
> >> well I just looked at a bunch and I guess we have different sites
> >>
> >>
> >> but even on the sites I visited — making all the navigation that large would mess up all the nav bars both vertically and horizontally.
> >>
> >>
> >> It makes the sites look horrid.   and take a menu that fits on one screen and spans it across multiple. (which is bad UX)
> >>
> >>
> >> Here is an example from Alastair
> >>
> >> https://alastairc.ac/tmp/ <https://alastairc.ac/tmp/> <https://alastairc.ac/tmp/wikipedia-44px-target-test.png <https://alastairc.ac/tmp/wikipedia-44px-target-test.png>> wikipedia-44px-target-test.png
> >>
> >>
> >> look at the side menu - before and after.
> >>
> >>
> >> we can do this - but I think we are just dooming 2.1 to be referred to at the unrealistic guidelines.
> >>
> >>
> >> g
> >>
> >>
> >> Gregg C Vanderheiden
> >>
> >> greggvan@umd.edu <mailto:greggvan@umd.edu> <mailto:greggvan@umd.edu <mailto:greggvan@umd.edu>>
> >>
> >>
> >>> On May 28, 2017, at 5:09 PM, Detlev Fischer <detlev.fischer@testkreis.de <mailto:detlev.fischer@testkreis.de> <mailto:detlev.fischer@testkreis.de <mailto:detlev.fischer@testkreis.de>> > wrote:
> >>>
> >>>
> >>> Gregg,
> >>>
> >>> It is not "a few non text links" - I have not made the count right now actoss sites that I have tested but my guess is that between 60 and 99 % of links on pages that I come across in testing are not inline text links. Most are
> >>>
> >>> - main navigation (including drop-down menus)
> >>>
> >>> - service navigation
> >>>
> >>> - site map (commonly in a footer section)
> >>>
> >>> - teaser links to content
> >>>
> >>> - social media links
> >>>
> >>> - links in sidebars (often with images) to supplementary info
> >>>
> >>>
> >>> ...and so on. Note that many are of these are text links (e.g. in menus) but would not fall under the inline text link exception. Sire, you do have inline text inks here and there but they generally both less numerous and less critical.
> >>>
> >>> I simply do not get it why you don't see the huge benefit for users who, once this new SC makes the most frequently used and most critical targets larger, will often not have to zoom in ( and likely vertically scroll) to recognize and hit a target with confidence.
> >>>
> >>>
> >>> Detlev
> >>>
> >>> Sent from phone
> >>>
> >>>
> >>> Am 28.05.2017 um 22:43 schrieb Gregg C Vanderheiden <greggvan@umd.edu <mailto:greggvan@umd.edu> <mailto:greggvan@umd.edu <mailto:greggvan@umd.edu>> >:
> >>>
> >>>
> >>>>> On May 28, 2017, at 3:29 PM, Jonathan Avila <jon.avila@ssbbartgroup.com <mailto:jon.avila@ssbbartgroup.com> <mailto:jon.avila@ssbbartgroup.com <mailto:jon.avila@ssbbartgroup.com>> > wrote:
> >>>>>
> >>>>>
> >>>>> This SC while applicable on all touch screens is most likely on small screen devices.  Today, almost all mobile browsers do not support reflow on zoom.  So small screen touch devices go into a mode that adds horizontal scrolling when enlarged.  So you are suggesting that it’s ok for users to have to initiate a pinch zoom, then scroll the screen and then tap the target in order to get a target that is large enough for them.  I don’t think this is very practical.
> >>>>>
> >>>>>
> >>>> That is not what I am saying.    That is what THE SC is saying.
> >>>>
> >>>>
> >>>> This SC says  ‘Make all the non-text targets big — but all the hypertext links on the page are exempt —  so the person will have to zoom it in order to use any hypertext link’.
> >>>>
> >>>>
> >>>> What I am saying is that if Zoom is good enough for all the links on the page  — why are we requiring that the few non-text targets be large ?
> >>>>
> >>>>
> >>>> g
> >>>>
> >>>
> -- 
> Cheers,
> David MacDonald
>  
> CanAdapt Solutions Inc.
> Tel:  613.235.4902
> LinkedIn 
>  <http://www.linkedin.com/in/davidmacdonald100>
> twitter.com/davidmacd <http://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>