Re: ( LC-2847)

 Dear John Foliot ,

The Web Content Accessibility Guidelines Working Group has reviewed the
comments you sent [1] on the Last Call Working Draft [2] of the Techniques
for WCAG 2.0 published on 5 Sep 2013. Thank you for having taken the time
to review the document and to send us comments!

The Working Group's response to your comment is included below.

Please review it carefully and let us know by email at
public-comments-wcag20@w3.org if you agree with it or not before 21 January
2014. In case of disagreement, you are requested to provide a specific
solution for or a path to a consensus with the Working Group. If such a
consensus cannot be achieved, you will be given the opportunity to raise a
formal objection which will then be reviewed by the Director during the
transition of this document to the next stage in the W3C Recommendation
Track.

Thanks,

For the Web Content Accessibility Guidelines Working Group,
Michael Cooper
W3C Staff Contact

 1. http://www.w3.org/mid/01d801ceaa60$bf5df030$3e19d090$@ca
 2. http://www.w3.org/TR/2013/NOTE-WCAG20-TECHS-20130905/


=====

Your comment on :
> This is some comments regarding the following: LC-2790 for Web Content
> Accessibility Guidelines Working Group - found at
>
https://www.w3.org/2006/02/lc-comments-tracker/35422/WD-WCAG20-TECHS-2013071
> 1/2790?cid=2790
> 
> It is unclear on how to respond to responses, and trust that this
> method
> will be deemed appropriate.  
> 
> ***************
> 
> The response to Laura's comment is pasted below, and I wish to comment
> on
> that response. My comments are provided in-line, and prefaced with my
> initials:
> 
> <-start->
> Thank you for your comment. A common @longdesc implementation pattern is
> to
> write the longdesc within a URI that has to be activated by the user
> (usually on a separate page).
> 
> JF: I note that this is in fact a design feature - the ability for the
> end
> user to consume or not consume the extended description.
> 
> 
> It takes the general form:
> 
> <img src="richimage.png"  alt="Some terse overview of the image"
> longdesc="somepage/longer_desc.html">
> 
> however, as you point out in your example:
> 
> <img
>  longdesc="#desc"
>  alt="Line graph of the number of subscribers"
>  src="http://www.company/images/graph.png">
> <div id="desc">
>  <!-- Full Description of Graph -->
> <div>
> 
> is valid.
> 
> However, this in page method is very similar to use of
> aria-describedby...
> 
> JF: *EXCEPT* for the very real difference that, unlike all current
> implementations of aria-describedby, @longdesc provides the ability for
> the
> end user to consume or not consume. I believe that it is CRITICAL that
> authors understand this important distinction - whether or not the
> longer
> text is inline or on a separate page.
> 
> 
> ...and is really at the discretion of the author as to what they choose
> to
> use. 
> 
> JF: Which is why making the distinction clear and obvious is important.
> Given the years of work and effort to retain @longdesc in HTML5
> (including
> the WAI sponsored HTML5 Image Description Extension specification -
> http://www.w3.org/TR/html-longdesc/) I would hope that any Techniques
> recommendation(s) would also be 'neutral' in laying out that author
> discretion.
> 
> 
> A possible change to the technique could be:
> 
> "This is unlike longdesc, which typically required the author to create
> a
> separate file to describe a picture, even though it does have the
> capacity
> to point to an in page description. It is preferable to have the
> descriptive
> text in prose so that it is readily available to all users."
> 
> JF: Proposed editorial change:
> "This is unlike longdesc, <del>which typically required the author
> to</del>
> <ins>which traditionally saw the author</ins> create a separate file to
> describe a picture, even though it does have the capacity to point to an
> in
> page description. <ins>While</ins> it is preferable to have the
> descriptive
> text in prose so that it is readily available to all users, <ins>when
> this
> is not possible due to design restrictions, longdesc will meet the
> success
> criteria</ins>."
> 
> Let us know if this is agreeable. Regarding this issue:
> 
> > Additionally, with aria-describedby the description is forced upon
> > screen reader users whether they want it or not. 
> How the @longdesc content or indeed the aria-describedby info is
> presented
> to the user, is largely a user agent issue. 
> 
> JF: While this is indeed true, we have I believe a duty to be factual
> and
> accurate as well. 
> 
> Currently all user-agent combinations that support aria-describedby do
> so as
> part of the page flow, without the ability for the end (screen reader)
> user
> to choose to consume or not consume. While it is true that the screen
> reader
> user can *stop* their reader at any time, and skip past blocks of
> content,
> the ability to proactively choose to hear the longer description,
> versus
> having to stop and skip past that description, provides a better user
> experience. I believe this fact is also important, and should be
> clearly
> articulated.
> 
> As well, currently aria-describedby, and in fact any aria attribute, is
> only
> being communicated to Assistive Technologies (via the AAPIs), which
> means
> that the programmatic association of the extended text is only apparent
> to
> users of AT. Conversely, while still having weak-ish native support from
> the
> browsers today, @longdesc content can be found and acted upon by any
> user
> who is using a browser or browser+extension that allows for @longdesc
> discovery and activation - for example Firefox's current contextual
> menu
> discovery/activation method - without the need for Assistive
> Technology.
> 
> When we present multiple possible techniques for the authors
> discretionary
> choice, it is important that all aspects of their choices are made
> clear.
> [/JF]
> 
> 
> Most @longdesc implementations may not be as 'controllable' or
> 'on-demand'
> as the comment suggests - as longdesc implementations and user
> experience
> has largely been poor. 
> 
> JF: Source? @longdesc implementations for the primary audience
> (non-sighted
> screen reader users) has been quite good for users of JAWS for many
> years
> now, and recent changes to both the NVDA screen reader and Firefox, as
> well
> as nightly builds emerging from Chrome (+ Chromevox) suggest that
> implementations and user experiences are actively improving. All of this
> has
> been previously researched and documented by members of the HTML5
> a11yTF,
> and can be found at:
>
http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc/Implementatio
> n 
> 
> The finalization of the HTML5 Image Description Extension specification
> will
> also likely drive better implementation and experience as browsers and
> other
> user-agent tools seek to be HTML5 conformant.
> 
> 
> Regarding the suggested change, to remove the text:
> 
> "This is unlike longdesc which typically required the author to create
> a separate file to describe a picture when it was preferred to have
> the descriptive text in prose as well so that it was readily available
> to all users. 
> 
> JF: I have already suggested some minor editorial changes here
> 
> 
> Yet, like longdesc, descriptive text is treated
> separately from the short name you would typically provide using the
> title or alt attributes in HTML. 
> 
> JF: this sentence, on the surface, implies that the user-experience is
> also
> the same, which clearly it is not today. It is not exactly true that it
> is
> "treated separately", as in practice today, while it is indeed a
> separate
> aria-node of content, like the @alt attribute (and unlike the @longdesc
> attribute) all ATs currently announce the value of aria-describedby
> without
> user activation - in fact many tools will concatenate both the alt text
> and
> the describedby text into a single "string", read aloud by the screen
> reader. I propose the following alternative edit:
> 
> "Similar to longdesc, descriptive content referenced by aria-describedby
> is
> treated separately in the DOM as a discrete node of content, similar to
> the
> short name you would typically provide using the title or alt attributes
> in
> HTML. Unlike longdesc however, most Assistive Technologies today treat
> aria-describedby content the same way that they treat @alt content: it
> is
> read aloud by the screen reader without user activation." [/JF]
> 
> 
> This is the preferred vehicle for
> providing long descriptions for elements in your document because the
> alternative is available to all, including sighted people who do not
> have assistive technology."
> 
> JF: Hmmm... why is it "preferred"? Earlier you note that
> longdesc="#samepage" was almost identical to aria-describedby
> ("However,
> this in page method is very similar to use of aria-describedby"), so
> either
> choice would be, on the surface, a wash. 
> 
> Add in the fact that aria attributes are only being programmatically
> associated and conveyed to the accessibility APIS today, whilst
> @longdesc
> content is programmatically associated at the DOM and can be acted upon
> in
> browsers without the intervention of Assistive Technology, and I would
> argue
> that using the longdesc="#samepage" pattern is actually superior. For
> this
> reason I have some *serious* reservations about that line. I propose
> the
> following edit:
> 
> "Whether an author chooses to use @longdesc or @aria-describedby to
> programmatically associate a complex image to its long description, the
> preferred solution is one that provides that longer text description in
> the
> same document, because the alternative is then available to all,
> including
> sighted people who do not have assistive technology."
> 
> 
> 
> For ease of reading, I will recap my proposed edits here:
> 
> "This is unlike longdesc, which traditionally saw the author create a
> separate file to describe a picture, even though it does have the
> capacity
> to point to an in page description. While it is preferable to have the
> descriptive text in prose so that it is readily available to all users,
> when
> this is not possible due to design restrictions, longdesc will meet the
> success criteria. 
> 
> Similar to longdesc, descriptive content referenced by aria-describedby
> is
> treated separately in the DOM as a discrete node of content, similar to
> the
> short name you would typically provide using the title or alt attributes
> in
> HTML. Unlike longdesc however, most Assistive Technologies today treat
> aria-describedby content the same way that they treat @alt content: it
> is
> read aloud by the screen reader without user activation. 
> 
> Whether an author chooses to use @longdesc or @aria-describedby to
> programmatically associate a complex image to its long description, the
> preferred solution is one that provides the longer text description in
> the
> same document, because the alternative is then available to all,
> including
> sighted people who do not have assistive technology."
> 
> 
> I look forward to your thoughts.
> 
> JF
> ---------------
> John Foliot
> Web Accessibility Specialist
> W3C Invited Expert | Co-Facilitator, W3C HTML5 Accessibility Task Force
> (Media)
> Co-Founder, Open Web Camp


Working Group Resolution (LC-2847):
Thank you for your comment.  We've reviewed your comment in conjunction
with similar remarks from another commenter, and are proposing changes to
address both.

The working group's intention is to offer information which authors can use
to understand ways to address WCAG 2.0 success criteria.  In response to
comments about the aria-describedby technique we are incorporating we are
proposing changes which will present about aria-describedby and longdesc in
the same way that recent changes to technique H45 introduced. 
Specifically, the second paragraph of the description for
http://www.w3.org/WAI/GL/wiki/Using_aria-describedby_to_provide_descriptions_of_objects
will read:

@@A feature of WAI-ARIA is the ability to associate descriptive text with a
section, drawing, form element, picture, and so on using the
aria-describedby property. This is similar to the longdesc attribute in
that both are useful for providing additional information to help users
understand complex images. Like longdesc, descriptive text provided using
aria-describedby is separate from the short name provided using the alt
attribute in HTML. Unlike longdesc, aria-describedby cannot reference
descriptions outside of the page containing the image. An advantage of
providing long descriptions using content from the same page as the image
is that the alternative is available to all, including sighted people who
do not have assistive technology. It is worth noting that as of the time of
writing (October 2013) some assistive technologies read aria-describedby
content immediately after an image's alt attribute information without user
activation - whereas current implementations of longdesc require the user
to take explicit action to read the additional description.

----

Received on Thursday, 16 January 2014 20:57:38 UTC