RE: Request to reopen HTML-ISSUE-30

Edward O'Connor wrote:
> 
> This is really well put together, thanks! I'm looking through this,
> trying to find information that was unavailable to the Working Group at
> the time of the ISSUE-30 decision.
> 
> * In general, Working Group participants were aware that some web
>   authors have managed to use longdesc="" correctly, so I so far
> haven't
>   learned anything new in the Examples In the Wild section.
> 
> * Use Cases: this is awesome, thanks for pulling these together. While
>   these use cases are certainly much more fleshed-out than in the
>   original ISSUE-30 proposal[1], I think the spirit of them was covered
>   in the original issue. All eight use cases are handled in the spec as
>   it currently is, either via aria-describedby="" or other mechanisms.
> 
> In conclusion, while I really appreciate the level of care and effort
> you've obviously put into this effort, it's not clear to me that
> there's
> any substantially new information available at this time.


Hi Edward,

In the Chairs initial decision, a number of Arguments and
Counter-Arguments were addressed. Under the heading "Implementation", the
Chairs noted:

   "Overall, it was found that while this attribute is implemented, it is
not implemented widely. This necessarily makes this objection a weak
objection."

The new Change Proposal notes that "implementation" was possibly
misrepresented, and provides a detailed list of both GUI based browsers as
well as Authoring Tools and Adaptive Technology software that have native
implementation today for @longdesc, demonstrating far wider implementation
than first suggested. Alternative implementations/support also include
Universal Feed Parser by Mark Pilgrim
(http://www.feedparser.org/docs/html-sanitization.html), and Sam Ruby's
Planet Venus (http://www.intertwingly.net/code/venus/). 



Under "Function" the Chairs stated:

   "A number of use cases for semantically rich, structured descriptions
of images were provided, however those use cases are abstract and don't
directly and specifically require the support of a longdesc attribute. ...
Overall, the lack of identified use cases was found to be a strong
objection."

Importantly, the new Change Proposal provides 8 discrete Use Cases
covering the needs of user and authors. These Use Cases all point to
@longdesc as being the most efficient and appropriate choice, and further
the only choice to meet some of the identified Functional Requirements,
the most significant being programmatically tying the description to
image. It also shows how and why other proposed alternatives to @longdesc
fail on one or more Functional Requirement.

Edward, you stated:

>   All eight use cases are handled in the spec as
>   it currently is, either via aria-describedby="" or other mechanisms.

This is sadly not true, and the Change Proposal specifically explains why
these alternative mechanisms do not meet the needs requirements.
(http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc#Suggested_
Alternatives_Are_Not_Viable_Solutions) 

Regarding using aria-describedby the 3 main reasons why this technique
fails is:

 1) It strips all semantic information from the content, including table
structure or list enumeration (if used) as well as hyperlinks or other
HTML constructs. ("ARIA 1.0 specifies that anything that aria-describedby
points to is presented to the user as if it occurred inside an
attribute.")

 2) aria-describedby does not provide a choice of consuming or not
consuming the longer description: it forces the description on the
end-user. (It is the equivalent of me forcing you to stare at a complex
image until I feel you understand it completely - it removes your ability
to glance at the image versus study the image.) This is an extremely
negative and harmful user-experience.

 3) aria-describedby can only point to IDREFs and not URLs, and fails the
use-case of "Describing a Logo" where multiple pages contain the same
complex image, and the author wishes to point to a single resource to
describe that image. 

As well, both @figcaption and @details (while also insisting on in-page
text for the description) also force visual encumbrances on the design
esthetic, and thus fail to meet those requirements.

I urge you to review the 8 Use Cases and offer proof that they can be
satisfied using these alternative techniques. I think you will find that
they cannot.


Under "External" the Chairs stated:

   "A counter argument of "no stated reason that this feature will
actually be used more in the coming 10 years than it has in the past 10
years" was given. This observation significantly reduces the weight of the
argument of references by the various guidelines, standards, etc. "

No proof was offered however to suggest that this feature will actually be
used *LESS* in the coming 10 years: The fact that many of the mainstream
GUI based browsers still do not offer native user-support for sighted
users of this attribute today in no way diminishes the fact that other
tools, used around the globe, *DO* take advantage of this attribute, and
its exposure in the DOM as a node attribute. These tools are specifically
noted in the Change Proposal. 

(Anecdotally, having provided input on this proposal as well, I have also
heard from electronic Publishers - Pearson Education via Jim Thatcher - as
well as a member of the ePub Working Group - Geoff Freed - enquiring on
the status of @longdesc, as they too are looking for a means to achieve
the stated Functional Requirements outlined in this Change Proposal.
Should @longdesc be re-instated they can continue to look at HTML5 as a
potential viable solution to their needs. These inquiries serve to suggest
potential growth in the coming years, and I can ask both men for
statements to that effect if their evidence serves as further 'proof'.)

Question: Is there any proof that @longdesc will be used less in the
future than it is today? Is there a real possibility that @longdesc will
continue to be used as it is today? Is there a potential that with its
retention that it will be taken up more? Should accessibility
accommodations be governed by the 80/20 criteria?

Finally, the Change Proposal specifically identifies Laws, Regulations,
Standards, Tutorials and Documentation in place today. While none of these
items where grounds for the rejection of @longdesc in the Chairs decision,
the documentation of these items underscores how wide-spread @longdesc has
become in these areas, further questioning the measurement of
"Implementation" and what is meant by that term.

JF

Received on Thursday, 24 February 2011 19:37:03 UTC