Re: Post WCAG 2 Issues comments/clarifications

David,
In defence of SC 4.1.1:
SC 4.1.1: can be reliably tested by validators / automated tools. If
these issues are identified and fixed first, it makes the code more
robust, standards-compliant - possibly an objective of most
enterprises.
I have long espoused the thought that accessibility testing should
commence after  markup validation is established. The principle is
robustness. For user agents / AT to behave reliably, they need to be
fed well marked up code.
And more importantly for accessibility testing,  it  will generate
fewer failures against other SCs and lesser work for manual evaluation
/ confirmation of issues.
Start of a heading tag before previous one is closed, or unclosed
script tag or duplicate id-values (when headers-id method is used for
complex table  are situations of 4.1.1 failures that have
accessibility impact.
Even duplicate id values in marking up forms will only be caught
reliably by a 4.1.1 test. Technically, an automated test of SC 1.3.1
will return a "pass" individually for each of the form fields because
each control has a for-id association, never mind one is incorrect.
Thanks,
Sailesh Panchang

On 8/4/15, David MacDonald <david100@sympatico.ca> wrote:
> 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
>>
>>
>

Received on Tuesday, 4 August 2015 19:36:16 UTC