Re: Coming to a decision on 2.2

Part of what I envision that we may want to wind up with a familiar document that describes "WCAG 2.0 + Low Vision Extension” and with that we would want there to be a connection between the existing WCAG 2.0 and the new/changed SC found in the extension.  If the extension changes a 1.2.8 and 1.4.3 and adds 2.1.4 we would want people to be able to see how the extension criteria fit into the existing WCAG 2.0 picture, and also allow people to differentiate between the two easily.  Of course we would also make clear that by meeting the WCAG 2.0 with the extension that you would meet WCAG 2.0 on its own as well.  I do agree that the success criteria would need different ID’s, but only barely.  The example below shows one possible way to deal with this, by adding “LV” (or something) to the existing SC ID.

So the extension document might say (I’m paraphrasing here):
1) Change 1.2.8 in this way...
2) Change 1.4.3 in this way…
3) Add 2.1.4 to do this…

And the resulting consolidated WCAG 2.0+LV extension would be like this:

WCAG 2.0 + Low Vision Extension

1.1.1 Non-text Content: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below. (Level A)
1.2.1 Audio-only and Video-only (Prerecorded): For prerecorded audio-only and prerecorded video-only media, the following are true, except when the audio or video is a media alternative for text and is clearly labeled as such: (Level A)
...
1.2.8-LV Media Alternative (Prerecorded): An alternative for time-based media is provided for all prerecorded synchronized media and for all prerecorded video-only media. (Level AA)
...
1.4.3-LV Contrast (Minimum): The visual presentation of text and images of text has a contrast ratio of at least 5:1, except for the following: (Level A)
...
2.1.4-LV Keyboard Equivalent: blah blah here, not a real example

Does this make sense to people?

Thanks,
AWK

Andrew Kirkpatrick
Group Product Manager, Accessibility
Adobe 

akirkpat@adobe.com
http://twitter.com/awkawk

http://blogs.adobe.com/accessibility









On 2/22/16, 09:36, "Sailesh Panchang" <sailesh.panchang@deque.com> wrote:

>1. I understand that "The extension is not changing the SC in WCAG
>2.0, it is modifying the SC in the context of the extension", then
>should not the  statement, "Extension specifications are expected to
>offer modifications to existing WCAG 2.0 success criteria  ..." be
>worded differently to convey what is intended?
>2. Yes, "All of the details regarding numbering and association with
>the techniques are details that do need to be figured out", but this
>extension requirements doc should explicitly state that the SCs  in an
>extension will not duplicate  an SC# from the WCAG 2.0.
>Else, an SC in the extension that has  a number identical to a WCAG
>2.0 SC will surely create confusion  as Greg pointed out in his first
>email especially with regard to documentation for techniques and
>understanding.
>It may not be very problematic for some changes  e.g. SC 1.4.3 in the
>extension say, only changes the ratio from 4.5:1 to 5:1 to make it
>stronger.
>But consider what will happen, if say, SC 3.3.2 in the extension
>begins with "Labels and instructions" instead of "Labels or
>instructions".
>
>I believe the above should be addressed, then the statement suggested
>by David will absolutely fit in and not create room for any confusion.
>
>Thanks,
>Sailesh Panchang

Received on Monday, 22 February 2016 15:14:09 UTC