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

James Graham, Wed, 15 Jun 2011 16:11:19 +0200:
> On 06/15/2011 03:54 PM, Janina Sajka wrote:
>> Matthew Turvey writes:
>>> longdesc is not implemented in Orca or VoiceOver so is currently
>> 
>> Stop right there. Repeating untruths does not make them true.
>>
>> aobviously, you haven't looked at:
>>
>> html/wg/wiki/ChangeProposals/InstateLongdesc
> 
> Sorry, could you be more clear about what exactly you mean here? [ snip ]

May I suggest a good-will reading: as soon as there is no doubt about 
the future and role of @longdesc in HTML5, then it will be implemented, 
in VoiceOver and Orca too.

Otherwise, Matthew broke into a dialog between Janina and Jonas about 
Jonas' upcoming CP. It is unclear to me how Matthew could propose the 
following, when he haven't read Jonas' proposal:

Matthew Turvey, Wed, 15 Jun 2011 10:21:45 +0100:
> 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.

This sounds as if Matthew thinks status quote is the best. But, AFAIK, 
the original counter-proposal has not been resubmitted. Jonas, OTOH, 
has said that he is going to propose ARIA specifics related to 
aria-describedby. It would be great if HTML5 UAs became required to 
present @aria-describedby content as structured mark-up. But I am not 
certain that that is what Jonas is planning.

If I may interpret Matthew to have been speaking about Jonas' proposal, 
then he claimed the following:

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

However, it does not seem certain that UAs without ARIA support *can* 
access those elements, because Jonas has put forward the idea that 
aria-describedby can also "link" to *hidden* elements.

 However, Jonas' CP looks to me to have other potential problems as 
well: 

* No UA and no AT support links in aria-describedby resources - 
pointing to an anchor element would currently make the link be 
presented as "pure text", plus that the link *text* would be read 
twice: once as part of aria-describedby and once when the AT reaches 
that element via its normal presentation of the page.

* Even if aria-describedby treatment is enhanced to handle links, the 
link would be repeated unless aria-describedby is also given capability 
to handle invisible/hidden links, which in turn may have back-compat 
issues. 

* Another back-compat issue that it I doubt that Jonas' CP will cater 
for, is the contextual menu etc that iCab, Opera and the Firefox 
plug-in display.

* The need to train users to use @longdesc correctly was brought up. 
However, given that @aria-describedby does not do what Jonas wants it 
to do (yet), despite that authors think it can present links 
(historical examples: myself and Jonas), correct and useufl use of 
aria-describebby needs much author training and weeding of 
misconseptions, too.

But all this is just more or less reasonable speculation until we see 
what Jonas' CP actually will propose.
-- 
Leif Halvard Silli

Received on Wednesday, 15 June 2011 14:55:40 UTC