[Bug 18385] Programmatic association of a page element to a 'description' text in a different uri

https://www.w3.org/Bugs/Public/show_bug.cgi?id=18385

--- Comment #15 from Devarshi Pant <devarshipant@gmail.com> 2012-09-11 15:21:06 UTC ---
> > If aria-describedby points to visible text, how does a sighted user
> > or a magnifier user track focus to the visible description.
> Same way as content focus is normally tracked? I don't understand the problem
> here.

The problem I have is with sending the focus away and then navigating back when
more than link needs to be described. On a complex UI with many links,
navigating back and forth from focusable targets (visible) is not something I
would want to experience as a user. 

> > Well, using longddesc, the keyboard focus will land on the link that was
> > selected once the target dialog is closed, thus preserving focus.
> If you navigate a same-page link, then navigate back, keyboard focus should
> land on the same-page link. (There may be client software where that doesn't
> happen, however that's a clear usability defect.)
> Users have the option to open the footnote link in a new window, which should
> provide the same experience as an AT triggering opening @longdesc in a new
> window.
> Authors have the option of linking to notes on other pages, or suggesting the
> opening of a new window with @target=_blank.
> Client software has the option of developing specific behaviors around
> @rel=help such as always opening help links in a new window.

Extending the longdesc attribute (however far-fetched) might also include
setting properties of the new window to simulate lightboxes and other display
types.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Tuesday, 11 September 2012 15:21:08 UTC