Re: Adapting Text SC: Addressing the main issues

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
>

Received on Thursday, 6 April 2017 01:11:05 UTC