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

TL;DR: What you are asking for is longdesc, as it has been for a decade  
and a bit. Try the attached test case in Opera...

On Tue, 21 Aug 2012 12:02:17 +0200, Steve Faulkner
<faulkner.steve@gmail.com> wrote:

> Hi all,
>
> It seems to me we have moved from the notion of being able to activate a
> visually hidden link with AT, via ascribing its action to an associated
> image:
>
> This is essentially what longdesc does as implemented in Firefox today,
> same as what the new Firefox implementation does via aria-describedby[1]
> Note that firefox uses the same accessible action for both  
> (showLongdesc()).

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

> My understanding is/was that the ability to reference a hidden link was  
> for the (in my mind) edge case where the design  will not allow a 'visual
> incumberence' i.e a visible link.

Yes, I think that is also the case.

> In the vast majority of circumstances we should be advocating the use of
> visible content and visible interactions to access content for all users,
> not devising elaborate methods to display hidden content to AT only  
> users.

Agreed.

> I am not an AT or browser developer, but I am someone who provides ( and
> has done so for going on 12 years) advice to many organisations large and
> small on how to provide accessible content. I cannot think of one use  
> case for which I would advise the use of this proposed feature.

My experience mostly involves trying to add accessibility for people who
aren't really interested, and working with browser and authoring tool
manufacturers. If we consider that when someone has contracted you then
you are preaching to the choir, when I ma trying to get a change made
maybe I am evangilising to the infidel. (On second though, let's not take
that metaphor further).

Anyway, all that to say that I have often hit the situation where people  
wouldn't change the visual design, so I consider this use case as  
extremely common rather than being an edge case. In my opinion that is  
unfortunate, but I am here to help solve technical problems, not just tell  
people they are sinners (oops, there goes that metaphor again) and are  
thinking wrong.

> At the same time there is not one use case I would advise

The approach that relies on a visible link (being championed by Apple)  
seems to be essentially a rehash of the "D-link".  
http://www.laspositascollege.edu/accessibility/dlink.php is as reasonable  
an explanation as any of the concept if you weren't around in the 90s when  
people tried to promote it as a stop-gap solution. It didn't make much  
difference to the web, because it was extra-ugly, and because in any event  
people were largely not prepared to spend time on accessibility anyway and  
making their page ugly was an anti-incentive. Where it was used, it  
sometimes improved life significantly for the intended audience.

> or have advised for the use of longdesc as currently implemented (or  
> not).

You mean the firefox implementation, or the Opera implementation (matching
what iCab did until they switched engine and lost the feature as part of
the price of development leverage in other areas)? I don't understand what  
you are advocating here.

To clarify, here are some semi-hypothetical situations - what would you  
advise? (In a few words - I'm not trying to get free consultancy from you  
;) ):

* A driving course, where an image shows some situation and the learner is  
asked to determine what they are allowed or not allowed to do. (Yes this  
is a trick question. I know plenty of blind people who learned the road  
rules, and I see no reason why they shouldn't be able to help their kids  
learn to pass the theory exam that so many countries impose). The driving  
school refuses to add text to their layout, which is a more-or-less exact  
copy of the layout used in the official exam.
* http://xkcd.com and http://cssquirrel.com/comic and http://dilbert.com
* A brochure-ware site for an art museum, designed to match the printed  
brochure. Or a museum like http://www.vikingeskibsmuseet.dk/en/

> I can see a use for the aria-describedby implementation in Firefox, but I
> would not personally be advocating its use unless the associated link was
> made visible at some point (for example when the image is focused or
> hovered). And in most instances would be advocating the use of a default
> visible link .The value of the describedby and longdesc implementations
> being that they can provide an explicit linked URL with an action to an
> image. The advantage of the describedby method over longdesc is that by
> default it is exposed as part of the default UI (as a regular link), but
> can be hidden if the use case 'no visual incumberence' is required.
>
> given that we have entrenched positions on both sides I would like to
> propose a comprimise:
>
> 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.

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.

> This means we will have a longdesc

As far as I can tell, this means adding longdesc to HTML5 without  
introducing new constraints.

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

Whether something suffers from hidden content syndrome depends on whether  
designers who want to keep their layout simpler win out over developers  
who argue that maintenance will be cheaper if everything is made visible.  
Although it is probably impossible to predict this perfectly, I would be  
prepared to put my money on the former winning more often than the latter  
for sometime yet.

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

Can you point to a statement from them that says this is the reason? I was  
under the impression that they had not implemented it simply because its  
future is unclear. The same lack of clarity is apparently to blame for the  
advice of w3schools...

> We move away from the territory of large swathes of content only visible  
> to AT.

Sure. To the extent people are willing to do so. longdesc has been  
available to do this for a long time.

cheers

Chaals

-- 
Chaals - standards declaimer