https://www.w3.org/Bugs/Public/show_bug.cgi?id=18385
--- Comment #13 from Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com> 2012-09-11 14:30:36 UTC ---
(In reply to comment #12)
> > If you want a visible description, make it visible and point at it with
> > aria-describedby.
> > (Requiring sighted keyboard users to use a secondary action on a control just
> > to get additional explanation seems like terrible UI by the way.)
>
> Your point is taken, but I disagree, there is no terrible UI when content is
> accessible.
It's easy to make content and functionality available to an accessibility API
but still hard to use, people do that all the time.
> 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.
> > I don't get how @longdesc would help here given the target of @longdesc would
> > be outside the table too.
>
> 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.
--
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.