- From: Laura Carlson <laura.lee.carlson@gmail.com>
- Date: Thu, 6 Apr 2017 08:03:13 -0500
- To: Gregg C Vanderheiden <greggvan@umd.edu>
- Cc: "w3c-waI-gl@w3. org" <w3c-wai-gl@w3.org>, public-low-vision-a11y-tf <public-low-vision-a11y-tf@w3.org>
Hi Gregg and all, Thank you very much. We have wrestled with both 1 and 2. I appreciate you stating it so clearly. For #1, the current proposals [1] [2] [3] do not have notes. Jon, has an idea to address #2 regarding scoping. https://github.com/w3c/wcag21/issues/78#issuecomment-292161456 If anyone has comments please reply on GitHub. Ideas for improvement are most welcome. Kindest Regards, Laura [1] Proposal C https://github.com/w3c/wcag21/issues/78#issuecomment-290810047 [2] Proposal D https://github.com/w3c/wcag21/issues/78#issuecomment-291618718 [3] Proposal E & F https://github.com/w3c/wcag21/issues/78#issuecomment-290810047 On 4/5/17, Gregg C Vanderheiden <greggvan@umd.edu> wrote: > couple of comments. > > 1) NOTES can only explain - not add or subtract or exempt from an SC. So > there should be no note about anything being exempt from the SC if the > language is not specifically in the SC. > > 2) If an SC cannot be applied everywhere — or can only be applied for some > technologies — then the SC MUST include something that scopes the SC to only > apply where it should - or the SC fails applicability. > > > Gregg > > > Gregg C Vanderheiden > greggvan@umd.edu > > > >> On Apr 5, 2017, at 4:17 PM, Laura Carlson <laura.lee.carlson@gmail.com> >> wrote: >> >> Hi all, >> >> On Tuesday's AG call Andrew kindly noted the main issues for the >> Adapting Text SC for in the minutes. >> >> 1. <AWK> "Applicability to mobile, Flash, Java, etc when user agents >> don't support." >> >> In in earlier versions we tried to add exemptions for things that >> don't support by adding language to the SC. However, that was >> rejected. Bruce said on the March 14 Survey: >> >> "The NOTE belongs to Accessibility Supported, and is harmful if left >> with with SC (because then it would be poking Accessibility Supported >> in the eye)." >> >> Steve has made a proposal with a subtle change using "WHEN a mechanism >> overrides" language. It places no requirement on that mechanism to >> even exist. Instead, authors need only be concerned with loss of >> content or functionality when the client makes changes. >> >> Steve's idea is Proposal D (4 April 2017) >> https://github.com/w3c/wcag21/issues/78#issuecomment-291618718 >> >> 2. <AWK> conformance being superficial (only one option) >> >> Having one option is not superficial. It does exactly what it needs to >> do. It addresses the ability to override. The author has to prove that >> each bullet can overridden. That is the test, plain and simple. >> >> 3. <Greg> "Ideally we would split this into two SC: Level A to work >> when author formatting is overridden, and Level AAA to provide its own >> mechanism to override the formatting." >> >> I had an idea for an in tandem 2 SC approach. It is Proposal E and F: >> https://github.com/w3c/wcag21/issues/78#issuecomment-291918379 >> >> As Steve said, I suspect we will find for Proposal F there simply >> isn't enough research for what a widget should require in fonts, color >> combinations, etc. But I have asked Jim if LVTF wants to tackle it. >> >> 4. <AWK> "Greg's point - perhaps this should be an SC to speak to >> non-interference where adaptability is used" >> >> That is what proposal E (as well as the others) is attempting to do. >> What we are missing is the understanding doc to add explanations. >> >> Ideas for improvement? Please respond on GitHub with your comments. >> https://github.com/w3c/wcag21/issues/78 >> >> Thanks everyone! >> >> Kindest Regards, >> Laura >> >> -- >> Laura L. Carlson -- Laura L. Carlson
Received on Thursday, 6 April 2017 13:03:47 UTC