W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2017

Re: Adapting Text SC: Addressing the main issues

From: Laura Carlson <laura.lee.carlson@gmail.com>
Date: Thu, 6 Apr 2017 08:03:13 -0500
Message-ID: <CAOavpvd51DiGzt8pTLxMSQMpqE=6CubqvTZaZ=PgD6kOhifbeA@mail.gmail.com>
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.

If anyone has comments please reply on GitHub. Ideas for improvement
are most welcome.

Kindest Regards,
[1] Proposal C

[2] Proposal D

[3] Proposal E & F

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

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 21:08:12 UTC