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

Hi Chaals,

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

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


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.

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


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, for example in the case of
skip links, the show link on focus method is a comprimise that
corporates are willing to use [1]

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


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.
d link could not provide a method to visually hide the link while
making it not be problematic for keyboard users (hidden tab)
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.


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



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

I presume they refuse because of design constraints right? but they
are willing to provide the text. If so I would recommend adding a link
to the text that appears on focus and hover on the some appropriate
part of the content.Something it adds minimum screen noise but makes
the content available to anyone that may benefit from it.

I would not use a method only available to blind screen reader users
as this content should be equally available (and equally useful) to
screen magnifier users or older users who use browser/OS based screen
enlagement etc.

>  * http://xkcd.com and http://cssquirrel.com/comic and http://dilbert.com

as above

> * A brochure-ware site for an art museum, designed to match the printed brochure. Or a museum like http://www.vikingeskibsmuseet.dk/en/

unclear about which particluar content on this site, but in general
museams and other public institutions appear willing to provide text
descriptions for stuff, for example [2] The site you referenced does
not appear to have an issue with adding links and other functionality
which would not be part of the printed brochure, so could not imagine
that they would be willing to invest time in providing text
descriptions, but not provide access to them.

>(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 :-)

> 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

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>

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

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

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


regards
SteveF

[1] examples of use of skip links (on some bank sites) shown on focus

http://www.halifax.co.uk/home/home.asp
http://www.co-operativebank.co.uk/servlet/Satellite/1193206375355,CFSweb/Page/Bank
http://www.hsbc.co.uk/1/2/
www2.firstdirect.com/1/2/banking/current-account/?code=PSR0000008&WT.mc_id=FSDT_PSR0000008&WT.Srch=1
http://www.standardchartered.com/en/

[2] http://www.tate.org.uk/art/artworks/waterhouse-the-lady-of-shalott-n01543/text-summary
[3] http://www.nvda-project.org/ticket/809


On 21 August 2012 13:17, Chaals McCathieNevile <w3b@chaals.com> wrote:
>
> 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

Received on Tuesday, 21 August 2012 13:48:55 UTC