Re: Adapting Text SC: Addressing the main issues

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:49 UTC