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

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

Received on Tuesday, 21 August 2012 11:03:54 UTC