Re: why are we pursuing this idea? (was: Implementation Details request on Issue 204 Decision)

Chaals McCathieNevile, Tue, 21 Aug 2012 14:17:23 +0200:
> On Tue, 21 Aug 2012 12:02:17 +0200, Steve Faulkner wrote:

> (in which version? My firefox release install just fails to do 
> anything useful).

Firefox 14 and later. But you must use it with e.g. JAWS to get to see 
it. (Or ... hear it.)

> what iCab did until they switched engine and lost the feature as part of
> the price of development leverage in other areas)?

iCab still supports it - WebKit did not prevent anything.

> I don't understand what you are advocating here.

He advocated this,

  <img src=file alt=text longdesc=#fragment>
  <a id=fragment class="could be hidden if you wish"
     title="link to long description" href=link></a>

where the AT would - when presenting the link as a long description 
link - ignore the textual content of the anchor and only present its 
URL to the user as a long description link. That is what Firefox does 
now, already. (Or, what it apparently does: I have only tested that it 
works in the aria-described="fragment" situation - when the anchor is 
*not* hidden. But Steve has told, last week, that Firefox's 
accessibility layer supports it even for links that are hidden with 
aria-hidden="true" and/or with hidden="hidden". Hopefully he documents 
this in the A11Y API implementation guide before ISSUE-30 goes to poll 
...)

Thus the above example is, in Firefox, identical to this:

  <img src=file alt=text aria-describedby=fragment>
  <a id=fragment class="could be hidden if you wish" 
     title="link to long description" href=link></a>

In the combined form, it would work even in AT that choose to not 
implement @longdesc:

  <img src=file alt=text longdesc=#fragment
                 aria-describedby=fragment>
  <a id=fragment class="could be hidden if you wish"
     title="link to long description" href=link></a>

Due to VoiceOver's current lack of support for hidden links - whether 
via @longdesc or via @aria-describedby, and if the authors wants to 
create something that works in Safari+VoiceOver, then it would 
currently probably be very difficult to create something which does not 
result in link duplication in Jaws+Firefox. (E.g. they would first hear 
the link as a longdesc link, and then hear it as normal link.) 

  [...]
>> we allow longdesc, but improve it so that it can either take a URL (as it
>> does currently) and it can also take an ID reference if as implemented in
>> firefox that id reference points to a link then it does the same as the
>> describedby and uses the href content of the link as the actionable 
>> URL. In other words its a special case native HTML describedby.
> 
> I believe that is what it always was. There is nothing I can see in 
> HTML4 that prevents it being used like that, as an author and adviser 
> I have used and advisde that it be used like that, and as the 
> attached test case shows (for best effect use a moderately small size 
> window) the Opera implementation already works fine like that.

In your example, the @longdesc essentially points to <p 
id=same-page-fragment> whereas Firefox and Steve advocates that 
@longdesc could point to <a id=same-page-fragment href=elswhere 
>link</a> and that if/when it does so, then the AT may skip reading the 
anchor element (especially if some method has been used to hide it) and 
only present the URL of the anchor element to the user as a long 
description URL.

>> This means we will have a longdesc
> 
> As far as I can tell, this means adding longdesc to HTML5 without 
> introducing new constraints.

So it do I. But it also means that authors and vendors are advised to 
build upon the Firefox implementation.
-- 
leif h silli

Received on Tuesday, 21 August 2012 13:30:37 UTC