- From: Jonathan Avila <jon.avila@ssbbartgroup.com>
- Date: Sun, 28 May 2017 19:29:14 +0000
- To: "w3c-waI-gl@w3. org" <w3c-wai-gl@w3.org>
- Message-ID: <SN1PR0301MB2047E9A3312187A48EB18ECC9BF20@SN1PR0301MB2047.namprd03.prod.outlook.>
Ø actually the research shows that enlarging text does help make it readable at lower contrast.
As I said it can help but it’s limited. That is there are three inch letters that when they don’t have sufficient contrast cannot be detected at all by someone with limited contrast. There are letters on a standard contrast chart that some of us cannot see even if you blow them up 400%. I’m telling you my experience as a person that deals with this – not from an academic point. Size helps but only up to a certain point in which case it has diminishing returns..
Ø but what are you talking about 2:1 contrast — we require much higher contrast for text.
Yes, but not for focus rectangle and not for icons.
Ø If you are talking about icons — then it is not clear what you mean by contrast. contrast with what? If you mean contrast within the icon elements - then it is not possible to achieve those contrast requirements with a colored logo with anything other than two or three colors in a very specific band (one essentially white, one essentially black and one in a narrow band in the middle.) Do you really mean to limit all icons to only those colors? and only three - and no shading?
There are plenty of two color icons used all over the web and we could apply this to two color icons.
• > AND there is a simple solution - -required by another SC that makes the targets bigger already.
Ø Simple for who? The person who uses a prosthetic? the person with tremors?
Ø yes all of those. We require (in another SC) that you can enlarge by 400 %. That would make BOTH the targets AND the hyperlinks larger than the 44 px of this SC -so those users can use the whole page.
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.
Ø The proposed SC only requires that the targets be large which, if the user needs the targets that large, would mean that the users could not use any of the links on the page.
The proposed SC makes it easier. You claim it’s already possible any way – so this SC is about making it easier for targets that can be made bigger without complicating testing. That has value. If we don’t have an exception than we lose the whole success criteria.
Jonathan
From: Gregg C Vanderheiden [mailto:greggvan@umd.edu]
Sent: Sunday, May 28, 2017 2:34 PM
To: Jonathan Avila
Cc: w3c-waI-gl@w3. org
Subject: Re: CFC: Target Size and Target Size (no exception) SC
actually the research shows that enlarging text does help make it readable at lower contrast.
but what are you talking about 2:1 contrast — we require much higher contrast for text.
If you are talking about icons — then it is not clear what you mean by contrast. contrast with what? If you mean contrast within the icon elements - then it is not possible to achieve those contrast requirements with a colored logo with anything other than two or three colors in a very specific band (one essentially white, one essentially black and one in a narrow band in the middle.) Do you really mean to limit all icons to only those colors? and only three - and no shading?
(black and white logos would all pass of course - but if the edge of the logo is not ALL black or all white (and the background the opposite — then the logo cannot have black or white but only black and mid grey or white and mid grey.
Please clarify on this. and it would be good to post icons you have in mind as passing and not passing.
> AND there is a simple solution - -required by another SC that makes the targets bigger already.
Simple for who? The person who uses a prosthetic? the person with tremors?
yes all of those. We require (in another SC) that you can enlarge by 400 %. That would make BOTH the targets AND the hyperlinks larger than the 44 px of this SC -so those users can use the whole page.
The proposed SC only requires that the targets be large which, if the user needs the targets that large, would mean that the users could not use any of the links on the page.
I am concerned that we are not thinking these through — not doing the logic and math to see what our text means.
g
Gregg C Vanderheiden
greggvan@umd.edu<mailto:greggvan@umd.edu>
On May 28, 2017, at 1:50 PM, Jonathan Avila <jon.avila@ssbbartgroup.com<mailto:jon.avila@ssbbartgroup.com>> wrote:
> one has to do with the readability of text. The contrast etc. You can blow up an icon if you want to examine it carefully. You cannot blow up each word to read it.
While increasing size of content can assist with reading content that has low contrast – this is a marginal factor – if you don’t have good contrast sensitivity no matter how large you make something won’t make it more readable. If someone can’t see a ratio below 2:1 making it a foot high doesn’t help.
> AND there is a simple solution - -required by another SC that makes the targets bigger already.
Simple for who? The person who uses a prosthetic? the person with tremors?
Jonathan
From: Gregg C Vanderheiden [mailto:greggvan@umd.edu]
Sent: Sunday, May 28, 2017 1:44 PM
To: Jonathan Avila
Cc: Andrew Kirkpatrick; w3c-waI-gl@w3. org
Subject: Re: CFC: Target Size and Target Size (no exception) SC
On May 28, 2017, at 1:34 PM, Jonathan Avila <jon.avila@ssbbartgroup.com<mailto:jon.avila@ssbbartgroup.com>> wrote:
> I respectfully do not think we should live with adding restrictions to page authorship that have no benefit -- because the page overall would not in the end be useable by the group the SC is intended to operate.
Gregg, this isn’t any different than WCAG 2. In WCAG 2 contrast only applies to text and not to icons, focus rectangles, etc. Resize only applies to text and images of text and not images, icons, etc. You could make the argument that without sufficient contrast or text size people with low vision couldn’t use the whole page – yet these and other success criteria were accepted under WCAG 2 despite their limitations. The rationale used to exempt icons contrast, etc. from WCAG 2 is not that much different from the rationale that is being used for inline interactive elements.
They are quite different.
1. one has to do with the readability of text. The contrast etc. You can blow up an icon if you want to examine it carefully. You cannot blow up each word to read it.
2. For this case it iso the opposite. It is all of the text on the page the would be inaccessible.
* AND there is a simple solution - -required by another SC that makes the targets bigger already. in 2.0 we also didn’t create new SC when there was already an SC that solved the problem.
Again - I ask. What population can use the page with this SC that cannot use it without it. (not that not accessing the links on a page means not being able to access the page)
Gregg
Jonathan
.
From: Gregg C Vanderheiden [mailto:greggvan@umd.edu]
Sent: Sunday, May 28, 2017 10:16 AM
To: Andrew Kirkpatrick
Cc: w3c-waI-gl@w3. org
Subject: Re: CFC: Target Size and Target Size (no exception) SC
On May 26, 2017, at 4:36 PM, Andrew Kirkpatrick <akirkpat@adobe.com<mailto:akirkpat@adobe.com>> wrote:
It isn’t strange, it is a CFC. CFC’s are the time where the question is 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”. As the chairs and staff contact felt that the questions raised had already been discussed, we approved the CFC.
Hi Andrew
Where was this issue dealt with?
The issue is that as written -
the SC requires that some parts of the page be larger -because they would not be useable if they were not — but says that all of the links can be smaller (too small for these same users).
What is the logic that the links on a page are not important but the buttons or Nav links are?
If there is a resolution to this — I missed it. Can you point me to it?
I saw some discussion but nothing that addressed this issue - or the logic of having the SC if this was true.
And in answer to your other question -
I respectfully do not think we should live with adding restrictions to page authorship that have no benefit -- because the page overall would not in the end be useable by the group the SC is intended to operate. That is, to force designers to do something on one part of a page to benefit a group that cannot use the rest of the page (ie. writing SC that only make parts of the page accessible but omits links — is not logical — nor helpful. It feels like tokenism. Which we should watch out for.
So I still think this item is open until this rather major issue is addressed.
regards
g
Gregg C Vanderheiden
greggvan@umd.edu<mailto:greggvan@umd.edu>
On May 26, 2017, at 4:36 PM, Andrew Kirkpatrick <akirkpat@adobe.com<mailto:akirkpat@adobe.com>> wrote:
It isn’t strange, it is a CFC. CFC’s are the time where the question is 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”. As the chairs and staff contact felt that the questions raised had already been discussed, we approved the CFC.
Thanks,
AWK
Andrew Kirkpatrick
Group Product Manager, Accessibility
Adobe
akirkpat@adobe.com<mailto:akirkpat@adobe.com>
http://twitter.com/awkawk
From: Gregg Vanderheiden <greggvan@umd.edu<mailto:greggvan@umd.edu>>
Date: Thursday, May 25, 2017 at 22:18
To: Andrew Kirkpatrick <akirkpat@adobe.com<mailto:akirkpat@adobe.com>>
Cc: WCAG <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Subject: Re: CFC: Target Size and Target Size (no exception) SC
this is strange. I posted several concerns - and did not see any resolution to the issues raised.
g
Gregg C Vanderheiden
greggvan@umd.edu<mailto:greggvan@umd.edu>
On May 25, 2017, at 3:17 PM, Andrew Kirkpatrick <akirkpat@adobe.com<mailto:akirkpat@adobe.com>> wrote:
AGWG’ers,
As we have received only positive feedback leading up to this CfC and no responses indicating that group members could not live this this decision, this CfC is agreed on as a consensus opinion of the working group. It is worth noting that there was discussion that came up during the CFC, but the discussion was determined to either focus on issues that have already been discussed.
This decision will be recorded at https://www.w3.org/WAI/GL/wiki/Decisions<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FWAI%2FGL%2Fwiki%2FDecisions&data=02%7C01%7C%7C1ab6006ec2be48e88f9008d4a210961e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636311639507586899&sdata=IafGoKjeQf7zBqxVj8m380hh8%2BWgU1VfPa2tZjq0Bx8%3D&reserved=0>
Thanks,
AWK
Andrew Kirkpatrick
Group Product Manager, Accessibility
Adobe
akirkpat@adobe.com<mailto:akirkpat@adobe.com>
http://twitter.com/awkawk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftwitter.com%2Fawkawk&data=02%7C01%7C%7C36cfdf48cb074d14101a08d4a3dd756a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636313618982506198&sdata=axcpk0RC9Ka470Q6Ip3v4KHioCLz6E2CAORPfXnRA0A%3D&reserved=0>
From: Andrew Kirkpatrick <akirkpat@adobe.com<mailto:akirkpat@adobe.com>>
Date: Tuesday, May 23, 2017 at 12:46
To: WCAG <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Subject: CFC: Target Size and Target Size (no exception) SC
Resent-From: WCAG <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Resent-Date: Tuesday, May 23, 2017 at 12:47
Call For Consensus — ends Thursday May 25rd at 1:00pm Boston time.
The Working Group has reviewed and approved two new Success Criteria for inclusion in the Editor’s Draft: Target Size and Target Size (no exception), at AA and AAA respectively, with the goal of obtaining additional input external to the working group.
Survey results: https://www.w3.org/2002/09/wbs/35422/SCreview_May_17/#wbsq4/results<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2F2002%2F09%2Fwbs%2F35422%2FSCreview_May_17%2F%23wbsq4%2Fresults&data=02%7C01%7C%7C36cfdf48cb074d14101a08d4a3dd756a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636313618982506198&sdata=40dPZbcD1w08VaNgzw7vKi4dMJHyTupW34qM%2FVOC%2B1s%3D&reserved=0>
Call minutes: https://www.w3.org/2017/05/23-ag-minutes.html#item04<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2F2017%2F05%2F23-ag-minutes.html%23item04&data=02%7C01%7C%7Cabc25a1800cb4c0ffad408d4a1fb8003%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636311548944237019&sdata=8nBllEuzUJNVOZKKC4j9%2B1YYlC6W8f1OgZ87LXtK494%3D&reserved=0>
The new SC can be reviewed here, in the context of the full draft:
https://rawgit.com/w3c/wcag21/target-size_ISSUE-60/guidelines/#target-size<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Frawgit.com%2Fw3c%2Fwcag21%2Ftarget-size_ISSUE-60%2Fguidelines%2F%23target-size&data=02%7C01%7C%7Cabc25a1800cb4c0ffad408d4a1fb8003%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636311548944237019&sdata=puROWmnsgFdu3qPy8YqdwZXi1RrE8f9x1QDEurpS1o0%3D&reserved=0>
https://rawgit.com/w3c/wcag21/target-size_ISSUE-60/guidelines/#target-size-no-exception<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Frawgit.com%2Fw3c%2Fwcag21%2Ftarget-size_ISSUE-60%2Fguidelines%2F%23target-size-all&data=02%7C01%7C%7Cabc25a1800cb4c0ffad408d4a1fb8003%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636311548944247027&sdata=mfVeQ%2BvJZwUG0QvA6aw8DhCdL4VT85NHH%2F6E5ezB1L0%3D&reserved=0>
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.
Thanks,
AWK
Andrew Kirkpatrick
Group Product Manager, Standards and Accessibility
Adobe
akirkpat@adobe.com<mailto:akirkpat@adobe.com>
http://twitter.com/awkawk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftwitter.com%2Fawkawk&data=02%7C01%7C%7Cabc25a1800cb4c0ffad408d4a1fb8003%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636311548944247027&sdata=uE3XXiCvh%2BHibX3HwcmCDLSO9ASDS0UwZJyI%2FQMxJps%3D&reserved=0>
Thanks,
AWK
Andrew Kirkpatrick
Group Product Manager, Accessibility
Adobe
akirkpat@adobe.com<mailto:akirkpat@adobe.com>
http://twitter.com/awkawk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftwitter.com%2Fawkawk&data=02%7C01%7C%7Cabc25a1800cb4c0ffad408d4a1fb8003%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636311548944247027&sdata=uE3XXiCvh%2BHibX3HwcmCDLSO9ASDS0UwZJyI%2FQMxJps%3D&reserved=0>
Received on Sunday, 28 May 2017 19:29:54 UTC