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

Hi Steve,

On Tue, 21 Aug 2012 15:47:39 +0200, Steve Faulkner
<faulkner.steve@gmail.com> wrote:

>> (in which version? My firefox release install just fails to do anything  
>> useful).
>
> I linked to details and test page in my previous email (probably
> should have noted it is not supported in mac as far as i know):

Ah, that's my problem then.

> http://www.paciellogroup.com/blog/2012/05/firefox-14-image-long-description-via-link-using-aria-describedby/
>
> the implementation is there it does work with AT, when the image has
> virtual focus pressing enter opens the link.

Only implementing this for AT users (specifically, tools that hook into
MSAA) seems like a bad approach - although I understand this is still only
an experiment.

[...]
> it is rarely the case that i get to preach to the choir, even for
> companies that have paid for a service, engineering groups are often
> not interested or on board with the idea.

fair enough.

>>  Anyway, all that to say that I have often hit the situation where  
>> people wouldn't change the visual design
[...]
> Well your experience is different to mine. We of course come against
> resistence to changing visual design and minimise the call for it
> where ever possible, but it is rarely that I find an instance where a
> negotiated comprimise cannot be achieved,

I'll remember to keep you on my list of negotiators then :)

>> The approach that relies on a visible link (being championed by Apple)  
>> seems to be essentially a rehash of the "D-link".
[...]
> there is a few major major differences:
> d link did not and could not provide an explicitly associated long
> description to AT, describedby as implemented in (firefox) does.

Well, since it linked to the same thing as a longdesc (in its early
recommended incarnations), it wouldn't have been terribly complicated to
notice that, even with the primitive state of the art at that time. But
the association was still only heuristic.

> d link could not provide a method to visually hide the link while
> making it not be problematic for keyboard users (hidden tab)

Hmmm. People tried all kinds of tricks (as they still do). Hiding things
by default, and not confusing users who come across them because they use
something other than a default WIMP interaction, is still something of a
black art although it has improved a lot in the last decade-and-a-half...
so I am not sure this is a qualitative difference, although I grant that
at the time it was even worse than now. I note that unfortunately I still
see people recommend, and use, display:none because they don't understand
that instead of hiding from visual users it completely removes the
content...

> d link needed to be placed near the image to provide the association,
> describebdby can point to a link anywhere in the page content and
> still provide the association to AT.
>
>>> 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.
>
>
> I don't advocate the use of longdesc currently as it hides the link
> from non AT users and non supporting AT users and users that can
> benefit from the information contained in the linked document, but do
> not use AT. Granted it has support via the context menu for users in
> Opera, but Opera has a very small desktop market share and no
> practical support for AT users.

OK, fair point. And adding iCab, JAWS, Window-eyes, the extensions that
allow other browsers to support it and so on doesn't greatly expand the
proportion of people who can use it by default.

[...]
>> (In a few words - I'm not trying to get free consultancy from you ;)
>
> I believe my record of advice (good and bad) freely provided shows I
> am happy to share :-)

Indeed, and I appreciate it :)

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

(As Leif pointed out, I incorrectly maligned iCab who do support longdesc
- and the testcase I sent does work in iCab as expected)

>>> This means we will have a longdesc
>
> OK so the difference as i see it is:
>
>  the URL from a referenced link can also be used
>
>     <img longdesc="poot">
> ...
>     <a href="description.html" id="poot">link text</a>

This case is the one firefox supports (for assistive technology on
windows), right?

The following is a rough version of how to enable that in a browser that
supports longdesc a la HTML4. It isn't real, and I believe it won't work,
but it should show that we are also not talking about rocket surgery here.
Making the code real and reasoanble robust as an extension would take me
the rest of the afternoon, but someone who is good at javascript and
writing extensions should be able to do it in about 30 minutes.

for (i in (document.querySelectorAll('[longdesc]')))
       if ((i.longdesc.indexOf('#')==0) &&
          (document.getElementById(i.longdesc).type == "a"))
         i.longdesc == document.getElementById(i.longdesc).href;

To be fair, I expect that it takes about the same amount of time to
implement support for HTML4 longdesc for firefox as an extension. But the
only extension framework I am really familiar with is Opera's, and I have
a passing acquaintance with Chrome's.

The following two options are already supported in Opera/iCab.

> or reference to a non link lement in the same page:
>
> <img longdesc="pooter">
> ...
> <div id="pooter">description</div>
>
> or link to other page:
>
> <img longdesc="http://poot.com">
>
> I don't think simply porting the longdesc text from HTML4 ot HTMl5 is
> a good idea. neither do I think it is a good idea to get longdesc back
> in HTML if browser vendors such as apple (i believe maciej indicated
> webkit would not be implementing longdesc as is) don't implement it.

Sure, but the same applies to the Firefox approach, or any other.
Standardisation is the art of finding a compromise that people agree is
usefully usable, and are prepared to implement.

> I have waded in to these murky waters once again because i feel strongly
> that the hidden rich content idea is not good for anyone.

I agree. As I said, I find that dealing with this is important because I
find designers don't.

>> 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.
>
> I would argue that conditional exposure of content is more acceptable
> to people that control design decisions than always exposed (i.e the
> skip link case). And is preferable to only exposed to subset of AT
> users.

And I would agree. I still put money on hidden content not going away. So
I think we need a solution that deals with the case when it is there. It
seems that managing an attribute containing a link (a la longdesc - but I
think we have consensus that whatever we come up with should work more
generally than just on img elements) is easier than managing content where
the link is somewhere else. Meanwhile, if you want a link somewhere else
it doesn't seem technically complicated to allow that on top of a
traditional longdesc implementation.

>> 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...
>
> James teh wrote [3]:
>
> "To clarify my position on this: I have no problem with the idea of
> the longdesc attribute. However, I believe it should be discoverable
> to *all* users, not just users of assistive technology. This means
> that the right place to implement this is in the browser (where all
> users can access it), not in screen readers such as NVDA."

OK. For what it is worth, I agree 100%. I still think it would be helping
NVDA users to implement longdesc support.

In an analagous example, I remember nagging Henter-Joyce to add header
navigation to their screen reader a very long time ago, because although I
believed and believe that this is something browsers should offer, I
thought having it in their product would at least give their users an
improved experience. I presume it wasn't just because I asked for it, but
they did indeed implement header navigation. It's far from perfect (among
other things it relies on good authoring practice, which means that it
won't be a uniform success any time soon) but I believe that it was worth
doing.

cheers

> regards
> SteveF

-- 
Chaals - standards declaimer

Received on Tuesday, 21 August 2012 17:28:27 UTC