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

Hi Detlev

comments below


> On May 29, 2017, at 1:37 PM, Detlev Fischer <detlev.fischer@testkreis.de> wrote:
> 
> Hi Gregg,
> 
> I think it is important to keep in mind that the new SCs will be applied to *new* content (relaunches, new sites) - 2 years from now.
> I don”t think it is reasonable to expect that legacy sites will meet WCAG 2.1.

GV: Agree.     I’m not sure what that has to do with my post.   In order for us to create an SC we need to be able to show that we could create a version of all of the current sites in the future.  THOSE sites don’t need to conform but it must be possible to create sites LIKE them (same function and similar designs).   I have never said the sites needed to already conform — but we should be able to show how they COULD conform if they were created today or 2 years from now. 

> Sites won’t be required to do so even where laws such as in the UK point to the latest version of the standard, as Alistair Duggin has clarified on this list, following my question. These sites (and I assume the sites you were thinking of) should be fine if they continue to meet 2.0 (if they do).
> 
> I believe with the exceptions that we have, target size can apply throughout. Surely, public comments wil show l if that stance is tenable.

GV: yes - but read my other posts.   
my concern is that we keep adding exceptions every time it looks unreasonable.   so now we have an SC that only makes part of a page accessible but not core parts.  


> 
> The case of Google Docs, MS Office on web etc. and other ‘secondary UA’ living in the browser might be called out more expliitly if it is not already seen as covered under the exceptions "User agent control: The appearance of the target is determined by the user agent and is not modified” or "Essential: A particular presentation of target is essential to the information being conveyed.”

GV: same comment as above.   this is good language borrowed from another SC -  but in this case it isnt essential to the information provided — it is essential to make the page look good or to be as functional.  

but again — if it means making parts of every page be excepted — then all pages are only partially accessible — (see my TOKENISM comment
)
> 
> You wrote
> 
>>>>>> 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)
> 
> I think it would be helpful if you could point to a few URLs where such things would happen (preferably sites meeting WCAG 2.0 today), and where an eventual  re-launch would struggle to meet the target size SC. I am genuinely curious to learn what sites you were thinking of. 

GV: I did.    in fact it is the next sentence. 

> 
>>>>>> 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
> 
> 
> The site you point to (Alastair”s example) is actually an example to the contrary: The Wikipedia redesign with increased line height in the navigation would work and be easy to implement.

GV: ????? 
how do you figure.

1) the only way to make it work is to take menu that fit on one screen — and make it so the user must scroll vertically over 3 or more screens.   Take this to any designer and ask if they would do this to their side menu.  

2) the hypertext links all overlap so that in many places a click would be ambiguous.    And excepting them means that all of those links would not be usable by a person who actually needs 44 px targets.   (and if they don’t, why make the menus so big.)     that is,  if they can use the links on the page  — they could use the menus too without being 44 px high.





> Rearranging the bulleted nav items so that you have groups of two,and not increasing line height in the text block under the Welcome message (these links are iexempted as they sit in a block of text) would reduce the vertical gain of the redesign. The side menu (containing, I note, more secondary links, not critical for the core use case of looking up a Wikipedia entry) sure would make users scroll more often, but has the benefit of being usable with touch. If compression is deemed important, authors would be free to resort to exception "Customizable: A mechanism is available to change the size of the target independent of the level of page magnification.” 
> 
> Detlev
> 
>  
>> On 29 May 2017, at 18:52, Gregg C Vanderheiden <greggvan@umd.edu <mailto:greggvan@umd.edu>> wrote:
>> 
>> Hi
>> 
>> 
>> I think we need to keep in mind that we want 2.1 to be required - not just “good if you can do this”
>> 
>> for that to be true (for that to happen) we need to be sure that 2.1 CAN be applied on ALL sites.
>> 
>> 
>> If we do,  then the question isnt if it works on one page per site 
>> or even if it works on MOST sites
>> 
>> the question is    Will it work on ALL sites. 
>> 
>> and for ANY site that it doesn’t work
>> can we figure out why it won’t work - and make that an exception
>> OR
>> do we want to say that that site just won’t be able to conform.
>> 
>> 
>> We need to remember that:
>> We can’t create a rule — that we want everyone to follow on every page (or we want people to REQUIRE for every page —  unless we know that everyone CAN follow it on EVERY page.
>> otherwise we need to just have it be advice
>> 
>> Unfortunately  we can’t have it both ways.   (i.e. it doesn’t work EVERYWHERE but we want it to be REQUIRED) 
>> 
>> so the test is never "I can show where it works"
>>  (if we want people to require 2.1 SC)  the test has to be  “no one can find a page where it doesn’t work (given our exceptions)"
>> 
>> 
>> g 
>> 
>> Gregg C Vanderheiden
>> greggvan@umd.edu <mailto:greggvan@umd.edu>
>> 
>> 
>> 
>> 
>>> On 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:
>>> 
>>>