Comments regarding LC-2790 for Web Content Accessibility Guidelines Working Group

All,

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

Received on Thursday, 5 September 2013 17:55:34 UTC