Re: Post WCAG 2 Issues comments/clarifications

I tend to agree Sailesh

I think we struck the right balance with our 4 parsing requirements in
4.1.1 (unique ids, unique attributes, proper nesting, proper
opening/closing). I don't think the a11y community would let us drop these
in the next version.

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 Tue, Aug 4, 2015 at 3:35 PM, Sailesh Panchang <sailesh.panchang@deque.com
> wrote:

> 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
> >>
> >>
> >
>
>