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

Hi Leif,

at this stage I am not offering a CP. I may in the future.

>Has Firefox always implemented @longdesc like that? Or is it a variant
>that came up together with the new 'aria-describedby link' method?

the longdesc implementation = use URL in longdesc as URL for action
(showLongdesc())

the describedby implementation use URL derived from link referenced as URL
for action (showLongdesc())


>that what you propose suggests that one should use @longdesc to
>point to a in-page anchor rather than pointing to an off-page resource.

I think it would be useful provide a way to move to in page content.

regards
SteveF

On 21 August 2012 12:03, Leif Halvard Silli <
xn--mlform-iua@xn--mlform-iua.no> wrote:

> Steve Faulkner, Tue, 21 Aug 2012 11:02:17 +0100:
> > given that we have entrenched positions on both sides I would like to
> > propose a comprimise:
>
> I like your compromise. (Se below.) But do you propose a new change
> proposal, so to speak? And would it be a CP for ISSUE-30 or ISSUE-204
> or both?
>
> > we accept the use of aria-describedby as implemented in firefox and see
> if
> > we can converge on that.
> >
> > 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.
>
> Has Firefox always implemented @longdesc like that? Or is it a variant
> that came up together with the new 'aria-describedby link' method?
>
> At any rate: One great thing about what you propose here, is that in
> ATs which do not support that method, it would still be
> back-compatible. Because, in principle, in case of
>
>     <img src=file alt=text longdesc=#fragment>
>     <a id=fragment href=link>link</a>
>
> then all the Firefox implementation does is that it reduces the steps
> to the long description resource from two to one click. Thus, to AT
> without support for this implementation, the long description link
> would just be one click further away.
>
> > This means we will have a longdesc (that still works for current AT),
> that
> > can use a visible link or point to in page content (non link ID) and so
> > does not suffer from hidden content syndrome, but does provide the
> ability
> > to explicitly associate a rich text description of the image. and IF we
> > must hide the link it can be done.
> >
> > the implementation in browsers as shown by firefox for both describedby
> and
> > longdesc is simple (relatively) and I believe orders of magnitude simpler
> > than what is being discussed. I also think that some AT will simply not
> > implement the rich hidden content model as described, The NVDA developers
> > have not implemented longdesc due to it having no visible UI (for
> example).
> >
> > We move away from the territory of large swathes of content only visible
> to
> > AT.
>
> It sounds like an excellent compromise. But we may have moved past the
> land of
>
> In fact, the only difference from Laura's CP in this is, it seems to
> me, that what you propose suggests that one should use @longdesc to
> point to a in-page anchor rather than pointing to an off-page resource.
> (But perhaps a full CP would reveal more differences?)
>
> When it comes to the ISSUE-204 decision, then that decision does
> however allow much more than simply hiding a link that, in turn, is
> referenced by @longdesc and/or @aria-describedby. I don't say that that
> is a problem - I just say that that is how it is. I think, if ATs are
> going to treat @hidden as a synonym of @aria-hidden=true, then I would
> not use @longdesc to point to a link that had been hidden with @hidden
> (or with @aria-hidden=tru). I would then rather hide the link via other
> means - such as pure and simple CSS. (Or else the link might not
> presented to AT users, even when visible. Whereas if the link has
> *only* been hidden via CSS, then the CSS :target selector can be used
> to make the link visible on focus etc.)
> --
> Leif Halvard 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