RE: ISSUE-30 longdesc - Chairs Solicit Alternate Proposals or Counter-Proposals

Matthew Turvey wrote:
> 
> I don't think it is entirely accurate to say that longdesc currently
> provides a reliable and effective user experience, or has effective
> and consistent support.

This of course wholly depends on how you consume content on the web. For
users of the major screen reading software tools, they *do* have access to
longdesc content when provided.  Those tools include multiple screen
reading software packages, as well as other dedicated AT tools. 
http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc/Implementat
ion 



> 
> longdesc is not implemented in Orca or VoiceOver so is currently
> inaccessible by default to entire platforms.

This is completely a business decision of the software platforms and
related tools. Lack of support of any technology by a platform or platform
vendor in no way de-legitimizes a software solution: Apple fans may be
satisfied with no support for Flash on their iOS devices, however *I*
choose to use tools that do support Flash - a point that many US based
Telcos tout when promoting their Android devices. (RIM too, they even
licensed the musical track "Flash" [Flash Gordon] by 80's super-group
Queen for their television commercials) 

The fact that VoiceOver still does not support an HTML4.01 attribute that
has been on the books for over a decade is surely not something Apple
should be proud of. However, that remains their choice and business
decision, and individual users will make their purchasing decisions based
upon what is important to them.



> It is also inaccessible
> by default to IE, Firefox, Chrome or Safari users, and NVDA, ZoomText,
> etc AT users etc.

This again depends on how you measure "accessible" - for those users who
need and want longdesc content, there is a varied collection of tools that
they can choose from that will afford them this option today. Not all
browsers support .webm content, perhaps we should ban that... or maybe
because all but one major browser supports .webm, we should outlaw .mp4
content, as it is inaccessible in Firefox, Opera and Chrome. This line of
argument by Matthew is ludicrous - user-agents already choose to support
or not support other aspects of HTML (whether 4.01, XHTML1.1, or 5) and
that support or lack of should hardly be grounds for dismissing usable and
useful elements, attributes or other technologies.



> longdesc also has a history of authoring and
> usability problems (see previous CPs).

As does elements such as <b>, <i>, and especially <u>. Let's outlaw those
too.


> 
> aria-describedby is more backward compatible than longdesc, 

Evidence please.

As well, in current implementations, aria-describedby forces the
referenced text on the screen reader user, which has negative and
intrusive user-experience outcomes - a point Janina's original email
points out.


> because
> UAs that don't support it can still access the elements referenced by
> aria-describedby i.e. it is more robust.

*ONLY* by imposing authoring requirements that many authors have expressly
rejected as being onerous or intrusive to their visual design. Matt, you
really do need to listen to what authors and users are saying, and stop
drinking the green koolaid.


> In contrast londesc links are
> completely inaccessible in UAs and AT that do not support it.

...yup, just like H.264 encoded video... 

Please note, I do not advocate that HTML5 *not* support H.264 encoded
videos - I believe authors should have the freedom to support or not
support whatever tools and platforms they choose to support, a position in
stark contrast to Matt's apparent suggestion that without *uniform*
support across *all* user-agents something should be jettisoned from
HTML5. 


> 
> So:
> 
> 1) longdesc is not backward- or currently-compatible with some
> existing UAs and AT

Why should this be a reason for obsoleting @longdesc? Why not instead
apply pressure on the Major Browsers to support a decade's old attribute?
(One, BTW, that remains perfectly valid in HTML4.01 and XHTML 1.1)  Matt's
argument sits squarely on some tools failing to actually do what they
should do - it is based not on users, but implementers.


> 
> 2) most users, including some SR users, cannot currently display
> longdesc content at all

Most users who need and want @longdesc content have already selected tools
that deliver it to them. Just like I've selected mobile devices that
support Flash.


> 
> 3) longdesc needs improved UA and AT support, and author/user
> training, before it can provide a reliable and effective user
> experience

Finally, we can find some common ground. 

@longdesc needs improved UA support: user-agents, SHOULD support the
exposure of @longdesc content to all users. 

AT support: that's a market condition issue. For what it's worth (and
repeating once again since Matt seems to continually dismiss this point)
NVDA are not opposed to 'supporting' @longdesc, they simply do not feel
that they should be inventing new user interactions, that those
interactions should be native to the browser, at which point they would
then map keystrokes/interactions to that functionality.


> 
> I'll also note WAI-CG accepted obsoleting longdesc in HTML5 if aria
> was incorporated into the spec, and aria-describedby was spec'ed to
> support links, which it is:
> 
> http://www.w3.org/2009/06/Text-Alternatives-in-HTML5
> http://www.w3.org/TR/wai-aria-
> implementation/#mapping_additional_relations

Matt, continually quoting an email that is now 2 years old simply serves
to illustrate how you have no idea what the WAI-CG, PFWG, or the HTML5
a11yTF feel about this topic in June of 2011.  Trust me when I tell you
that unlike you, they have continued to think about this issue and now
support the retention of @longdesc in HTML5. Gotta keep up with the times!


> 
> I'd like to suggest that the HTML-A11Y Task Force's longdesc CP be
> withdrawn by amicable consensus so we don't have to spend any more
> time on this issue.

Your suggestion is now on the record. I don't think you will find any
sympathy towards that suggestion from within the HTML5-a11yTF however, so
your other options are to submit an alternative Change Proposal, or wait
for the Chairs next move.

JF

Received on Wednesday, 15 June 2011 23:17:05 UTC