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

hi leif

>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.

not entirely correct

firefox exposes the text content of the link as the images accessible
description (not accessible name) this description may not be
announced by some AT on images.

regards
Steve

On 21 August 2012 14:29, Leif Halvard Silli
<xn--mlform-iua@xn--mlform-iua.no> wrote:
> 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



-- 
with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html

Received on Tuesday, 21 August 2012 13:50:50 UTC