W3C home > Mailing lists > Public > public-html-a11y@w3.org > May 2011

Re: Moving longdesc forward

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Wed, 4 May 2011 03:33:06 +0200
To: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
Cc: Richard Schwerdtfeger <schwer@us.ibm.com>, Charles McCathieNevile <chaals@opera.com>, Laura Carlson <laura.lee.carlson@gmail.com>, HTML Accessibility Task Force <public-html-a11y@w3.org>, public-html-a11y-request@w3.org
Message-ID: <20110504033306084416.e99fba9f@xn--mlform-iua.no>
Benjamin Hawkes-Lewis, Wed, 4 May 2011 00:21:07 +0100:

> On Tue, May 3, 2011 at 2:41 PM, Richard Schwerdtfeger wrote:

>> I would add text that when the long description dialog is closed
>> that the user agent return the user's point of regard to the element
>> within the document where the user left off.
>
> Can you elaborate about what you're worried about here and why?
  [...]
> Opening a new browsing context does not normally alter the existing
> browsing context. I'd expect the same to be true of opening some sort
> of dialog.

May be Richard talks about a different concern. But one concern I have 
myself, is that implementors which opt to let longdesc URLs open in a 
tab or in a window, shall not understand the value of opening it in a 
*new/blank* tab/window rather than in the current tab/window. Also, 
when closing the window/tab, user should be back in the originating 
location.

Here are some concrete problems that occur when UAs do not behave like 
I said above:

    A) Firefox longdesc add-on
       The Firefox add-on opens the longdesc in the current tab/window, 
and if the current tab/window contains the full-length version of the 
HTML5 spec, then it could take considerable time getting back to the 
place one was reading even if the browser flawlessly took the user back 
to the original image. Such a thing could considerably lower the users 
experience, and perhaps lead a user to ignore the entire feature. 
Remember, also, that unlike for normal links, the user is usually not 
given freedom to choose in which tab/window to open the longdesc URL.

    B) Opera context-menu
       The Opera context-menu opens the URL in a new tab.  So far so 
good. But, at least on my Mac, when I close the "longdesc tab", then I 
am taken to the *next* Tab rather than back to the originating Tab. I 
know I can fine-tune how tabs works in Opera. However, I have to select 
"one global behaviour".  I believe that it should not be required to 
change how tabs, in general, works just to get a good longdesc 
experience: as long as Opera opens a longdesc URL in a new tab, then 
closing that tab, should take me back to the originating tab.

   C) iCab - the good example
      iCab opens the longdesc URL in a new window. Some would consider 
a new window less "cool" than a new tab. However, unless the user agent 
can ensure that, when closing the tab, one is taken back to the old 
window, then I find a new window much better than a new tab.

Laura, could you add text to say that implementations which open the 
longdesc URL in a window or tab, should open it in a *new/blank* 
window/tab, and ensure that - when closing the window/tab, the user is 
taken back to the originating window? Regarding new tab/window, then I 
have often compared it to how target="_blank" works.

> "User agents should allow users to access long text alternatives."
>
> I wouldn't have suggested that text were it not that the spec for
> @cite contains a similar SHOULD-level conformance point: "User agents
> should allow users to follow such citation links."

+1 Important to keep the link to @cite.
-- 
Leif Halvard Silli
Received on Wednesday, 4 May 2011 01:33:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:42:37 GMT