Re: Post WCAG 2 Issues comments/clarifications

Hi All

Jared has responded to my analysis for my action item to process his
article on WCAG next.
https://www.w3.org/WAI/GL/wiki/Post_WCAG_2_Issues_Sorted
As a courtesy, he provided his comments directly to me in an email and
invited me to post them to the list if I wish. So in the interest of an
open dialogue with the community I am doing so with my responses. As a
result of his comments I have revised some of my analysis, fix a couple of
typos:

Here it is:

===================
Response to analysis of #35
Jared's comment:
If there is a misunderstanding, then "Media Alternative for Text" has
changed since I proposed the concept in (probably) 2007 and the term and
definition were added to WCAG. This term came about when I pointed out that
if a page has text of a news article, for example, and also a video version
that presents that same text (a reporter reading the text of the article),
then it should not be necessary to provide a separate transcript. The
transcript would contain the same, redundant text as the primary article
and would be burdensome (and rather pointless) to require authors to
provide. I asked at the time whether this same concept should apply to
captions - should WCAG require captions for media that is an alternative
version of text content already on a page? It was concluded at that time
that WCAG did not require this for Level A, thus the term "Media
Alternative for Text" was born (despite my complaints that the term and its
definition were too confusing to be very useful) and added to all Level A
SC. At no time (that I recall) was the concept focused on only supplemental
media that would be of benefit to some users - such as those with cognitive
disabilities. If "Media Alternative for Text" is interpreted to only these
implementations of media, there are (at least) two distinct issues. First,
WCAG could require a separate transcript for media that already has a full
text alternative in it's primary presentation. Second, the applicability of
all Level A media SC would be based on the assumed intention of the author
in providing that media. How could one know whether the video is provided
primarily for users with cognitive disabilities, etc. as opposed to other
users?


David Response:
The understanding document further explains the nature of a media
alternative.

"Captions are not needed when the synchronized media is, itself, an
alternate presentation of information that is also presented via text on
the Web page. For example, if information on a page is accompanied by a
synchronized media presentation that presents no more information than is
already presented in text, but is easier for people with cognitive,
language, or learning disabilities to understand, then it would not need to
be captioned since the information is already presented on the page in text
or in text alternatives (e.g., for images). "
http://www.w3.org/TR/UNDERSTANDING-WCAG20/media-equiv-captions.html

My first memory of this issue was at CSUN Face to Face I think in 2004
because that was our last F2f there. It took a while to get it into draft.
An organization that helps people with severe cognitive disabilities in
England came over to present to us. They showed us a video of the people
with significant cognitive disabilities and they pleaded with us not to
require captions at level A because it would be a disincentive to
organizations who make the type of videos that help this demographic.  They
can't read and they need videos. It was a very moving presentation, and I
we all felt we had to make an exception for this type of content realizing
that it would be hard to manage with the apparently conflicting requirement
for deaf people to get captioning at level A. We were afraid organizations
would post ALL media alternatives, so we added this section of the
Understanding Document, to try to manage this. Gregg's thought I believe
was that if we said it does not contain any more information than the text
it is representing AND is clearly marked as a media alternative to text
that would be a sufficient enough bar to prevent abuse. So far I've not
seen abuse of this,  and no systematic abuses have hit our radar. But
perhaps you have. If so I think it would need to be addressed with
education, as I think the WCAG understanding doc is clear, for those who
may not get it from the WCAG definition.

=======

#37
David: You're absolutely right... a typo on my part. I've amended it to say
"move AD to AAA."

=====


#38

Jared:
Note 3 of the audio description definition -
http://www.w3.org/TR/WCAG20/#audiodescdef - clearly states that I don't
have to provide audio description if all visual content is already
presented via audio. So I can meet 1.2.3 by doing that - ensuring all
visual content is in audio (as would be the case with a talking head
video). Nowhere does it state or suggest that if I don't provide audio
description because it's not required (per Note 3) that I must also then
provide a transcript. In other words, if multimedia is natively audio
described, WCAG doesn't, as I interpret it, require a descriptive
transcript until Level AAA. And this is problematic.

David Response:
Yes "if all visual info is in the audio" then neither a transcript nor AD
is required. I can see that this could be a problem for deaf blind.  We've
never been contacted by a deaf blind agency. Personally I've never
encountered this barrier but it is possible. I'm assuming you are bringing
this up because you found it a problem with real users, not just a
hypothetical gap. A transcript was primarily allowed because AD is really
hard at Level A. We've never got a complaint on this, but that doesn't mean
it's not a problem. I'm guessing you would like a separate requirement for
a Transcript at Level A and not do the either/or with AD as per 1.2.3. We
could pitch this in WCAG NEXT OR try to work it into one of the extensions,
if it gets traction from the greater community, and industry I'd support
it. I've updated the table.

======
#42

Jared: ... The example I've been asked about is a graphical button with a
custom font face, drop shadow, rounded corners, angled text, text borders,
and a gradient background. Does 1.4.5 require that they use complex CSS3
and an embedded font to get the same visual presentation using text as they
could get by presenting this button as an image? There are many times that
an image is used for complex stylistic presentations of text that would not
be considered "essential". Does 1.4.5 prohibit this at Level AA? Anyway,
that's really what I'm getting at - "if the technologies being used can
achieve the visual presentation" isn't always as simple as simply replacing
the image with text.

David:

Strictly speaking if text lettering can be accomplished successfully with
CSS it should. However, if the font is not in CSS, or the positioning can
get messed up *in any view* then there is a justification for images of
text. Prime candidates of this are the situation you discuss, such as
buttons with a letter on them where positioning is critical, and ads on the
right site that come from third parties. I think the understanding document
makes all this very clear.

"If for any reason, the author cannot format the text to get the same
effect, the effect won't be reliably presented on the commonly available
user agents, or using a technology to meet this criterion would interfere
with meeting other criteria such as 1.4.4, then an image of text can be
used. This includes instances where a particular presentation of text is
essential to the information being conveyed, such as type samples,
logotypes, branding, etc. Images of text may also be used in order to use a
particular font that is either not widely deployed or which the author
doesn't have the right to redistribute, or to ensure that the text would be
anti-aliased on all user agents."
http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-text-presentation.html
======

#45
Jared:
My comments were on the difficulties of this term - what to do when
something is deemed to be programmatically determined but doesn't actually
result in better accessibility? It's a bit of a stretch to turn that into
your recommendation to remove the "in context" exemption for links. This
isn't what I was suggesting, though would be an example of the type of
thing that should be considered.

David:
I think the suggested fix would address the issue but it appears to go
beyond the recommendation.  I've made it clear that this is my
recommendation. Jared's recommendation is to reword "can be
programmatically determined" to something more sure. I've added to my
comments that the definition of accessibility supported sufficiently
addresses the issue.It requires that anything they do "works" with AT.


=======

#Issue 46
Jared:
I see this minimal vision of the applicability of the keyboard-related SC
all the time. People too often focus on just "keyboard-only users". I'd
suggest a broader vision of "keyboard users". Many use a keyboard due to a
disability or out of preference, but are not required to. As you state,
it's true that lack of focus indicators may have minimal impact on the
majority of "keyboard-only users" that use MouseKeys, but what of the MANY
other "keyboard users"... people like me with RSI that prefer using the
keyboard when I can.

With the strong current push to get browsers to increase their default
keyboard support (per UAAG - which would notably decrease reliance on
MouseKeys online), the need for focus indicators at Level A is even more
acute.

David:
It is beyond the current scope of WCAG to solve web problems for those who
do not have disabilities. I think this should happen, but it is not WCAG's
mandate currently to address usability. There are several on the group who
would like to see a usability extension. If that ever flies, then this
requirement should be a considered there. We are stretched as it is.

=====
#47
Jared:
I think the mindset of many "standardistas" has changed in recent years
with the advent of HTML5. Mine has. With HTML5's focus on error handling -
automatically remediating in-browser the very things this SC requires - I
think it would be worth revisiting this. I've yet to find anyone that can
give me an example of a 4.1.1 failure that impacts accessibility that is
not captured by another WCAG SC. But there are many examples of 4.1.1.
failures that have no impact on accessibility at all (especially with
HTML5). It just seems odd that WCAG would in these cases require effort
(and sometimes significant effort or retooling) to meet a Level A SC when
there is no accessibility impact.

David: I've amended my recommendation to:
"In the next version of WCAG we should ask the question about these parsing
requirements, and see if it's a war and if we need to make the same
requirement or not., this will involve researching if any of our parsing
requirement are resulting in real world accessibility improvements."

Cheers,

David MacDonald



*Can**Adapt* *Solutions Inc.*

Tel:  613.235.4902

LinkedIn <http://www.linkedin.com/in/davidmacdonald100>

www.Can-Adapt.com



*  Adapting the web to all users*
*            Including those with disabilities*

If you are not the intended recipient, please review our privacy policy
<http://www.davidmacd.com/disclaimer.html>

On Mon, Aug 3, 2015 at 5:07 PM, Jared Smith <jared@webaim.org> wrote:

> This has been on my to-do list for some time, and lest I be judged one of
> the 9 workers that simply stands by and watches, here's
> some thoughts/feedback on your Post WCAG analysis -
> https://www.w3.org/WAI/GL/wiki/Post_WCAG_2_Issues_Sorted I've referenced
> these based on row number.
>
> #35
>
> I don't think we can say, if the content provides all the
>> necessary information in text on the page that Captions are not required.
>
>
> But this is exactly what the success criteria states.
>
> It appears that there may be a misunderstanding of an media alternative,
>> which is primarily for people with cognitive disabilities
>
>
> Its definition does not make this distinction.
>
> If there is a misunderstanding, then "Media Alternative for Text" has
> changed since I proposed the concept in (probably) 2007 and the term and
> definition were added to WCAG. This term came about when I pointed out that
> if a page has text of a news article, for example, and also a video version
> that presents that same text (a reporter reading the text of the article),
> then it should not be necessary to provide a separate transcript. The
> transcript would contain the same, redundant text as the primary article
> and would be burdensome (and rather pointless) to require authors to
> provide.
>
> I asked at the time whether this same concept should apply to captions -
> should WCAG require captions for media that is an alternative version of
> text content already on a page? It was concluded at that time that WCAG did
> not require this for Level A, thus the term "Media Alternative for Text"
> was born (despite my complaints that the term and its definition were too
> confusing to be very useful) and added to all Level A SC.
>
> At no time (that I recall) was the concept focused on only supplemental
> media that would be of benefit to some users - such as those with cognitive
> disabilities. If "Media Alternative for Text" is interpreted to only these
> implementations of media, there are (at least) two distinct issues. First,
> WCAG could require a separate transcript for media that already has a full
> text alternative in it's primary presentation. Second, the applicability of
> all Level A media SC would be based on the assumed intention of the author
> in providing that media. How could one know whether the video is provided
> primarily for users with cognitive disabilities, etc. as opposed to other
> users?
>
> #37
>
> Your comment in the final column is a misstatement and conflicts with your
> comments in the earlier column, or there's a misunderstanding. Our
> recommendation is that descriptive transcripts be moved from level AAA to
> level AA and that audio description be moved from level AA to level AAA. In
> other words, that 1.2.5 and 1.2.8 swap positions. I think this is more
> reasonable, better matches the reality of current accessibility
> implementations (as indicated by Canadian and other guidelines taking this
> approach), and provides a better accessibility experience, particularly for
> deaf-blind users and those with cognitive disabilities (a transcript is
> more accessible to them than audio description).
>
> #38
>
> I think this is a stretch of the Success Criteria. 1.2.3 say: "An
>> alternative for time-based media or audio description of the prerecorded
>> video content is provided for synchronized media, ... (Level A)"
>
> ...
>
> but at level A there needs to be one OR the other, and therefore the
>> waving off of the AD does not wave off the Transcript requirement.
>
>
> But it does, I think. Note 3 of the audio description definition -
> http://www.w3.org/TR/WCAG20/#audiodescdef - clearly states that I don't
> have to provide audio description if all visual content is already
> presented via audio. So I can meet 1.2.3 by doing that - ensuring all
> visual content is in audio (as would be the case with a talking head
> video). Nowhere does it state or suggest that if I don't provide audio
> description because it's not required (per Note 3) that I must also then
> provide a transcript. In other words, if multimedia is natively audio
> described, WCAG doesn't, as I interpret it, require a descriptive
> transcript until Level AAA. And this is problematic.
>
> #42
>
> David: I think this is is a misreading of the SC. It does not require the
>> author to change his desired font.
>
>
> I think you misunderstand my comments. The example I've been asked about
> is a graphical button with a custom font face, drop shadow, rounded
> corners, angled text, text borders, and a gradient background. Does 1.4.5
> require that they use complex CSS3 and an embedded font to get the same
> visual presentation using text as they could get by presenting this button
> as an image?
>
> There are many times that an image is used for complex stylistic
> presentations of text that would not be considered "essential". Does 1.4.5
> prohibit this at Level AA? Anyway, that's really what I'm getting at - "if
> the technologies being used can achieve the visual presentation" isn't
> always as simple as simply replacing the image with text.
>
> #45
>
> My comments were on the difficulties of this term - what to do when
> something is deemed to be programmatically determined but doesn't actually
> result in better accessibility? It's a bit of a stretch to turn that into
> your recommendation to remove the "in context" exemption for links. This
> isn't what I was suggesting, though would be an example of the type of
> thing that should be considered.
>
> #46
>
> I see this minimal vision of the applicability of the keyboard-related SC
> all the time. People too often focus on just "keyboard-only users". I'd
> suggest a broader vision of "keyboard users". Many use a keyboard due to a
> disability or out of preference, but are not required to. As you state,
> it's true that lack of focus indicators may have minimal impact on the
> majority of "keyboard-only users" that use MouseKeys, but what of the MANY
> other "keyboard users"... people like me with RSI that prefer using the
> keyboard when I can.
>
> With the strong current push to get browsers to increase their default
> keyboard support (per UAAG - which would notably decrease reliance on
> MouseKeys online), the need for focus indicators at Level A is even more
> acute.
>
> #47
>
> I think the mindset of many "standardistas" has changed in recent years
> with the advent of HTML5. Mine has. With HTML5's focus on error handling -
> automatically remediating in-browser the very things this SC requires - I
> think it would be worth revisiting this. I've yet to find anyone that can
> give me an example of a 4.1.1 failure that impacts accessibility that is
> not captured by another WCAG SC. But there are many examples of 4.1.1.
> failures that have no impact on accessibility at all (especially with
> HTML5). It just seems odd that WCAG would in these cases require effort
> (and sometimes significant effort or retooling) to meet a Level A SC when
> there is no accessibility impact.
>
>
> I really appreciate your analysis of my comments. Hopefully these comments
> and clarifications might be useful. And you're welcome to share these
> comments if you think they would be helpful.
>
> Unfortunately nearly all of these cannot be adequately addressed via
> extensions alone. I do hope the working group will consider a true update
> to WCAG, despite how difficult and painful it surely will be. From my
> perspective working every day with developers, I can assure you that one is
> needed - and more so each year. The added complexity of extensions will
> certainly decrease the approachability and understandability of WCAG.
> Perhaps some day soon I can provide commentary on additional items I think
> would be worthy of consideration (small text, more attention to cognitive
> disabilities, mobile implications, etc., etc.).
>
> Judy's suggestion of a WAI 3.0 that incorporates several accessibility
> guidelines into one is particularly worrisome - do you think it possible to
> do this on a meaningful timeline via W3C processes? I don't. I'd think the
> opposite approach (as Sailesh recommended this morning) of more finite
> standards would be a better approach.
>
> Thanks for all your work on WCAG. We both know that I am critical (and
> overly so at times), but as I've said before, I'm critical because I care.
> What happens with WCAG is important to me, and especially impactful on the
> lives of people with disabilities.
>
> Cheers,
>
> Jared
>
>