[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 #11 from Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com> 2012-09-10 22:38:35 UTC ---
(In reply to comment #10)
> (In reply to comment #9)
> > In all these cases, if the description works as plain text, you can just hide
> > the referenced describing element using @hidden. You can reference an iframe if you want to reuse the text elsewhere.
> 
> How would sighted keyboard users (even non-disabled users) access this
> information if we use @hidden?

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

> Also, based on the response from Laura, longdesc
> could be a viable alternative here -- it is accessible to everyone.

Subject to implementation.

Mozilla, Microsoft, and Apple seem uninterested in adding default UI for
@longdesc even for images in their browsers, so I'm not holding my breath.

> > What's wrong with an ordinary link here?
> > <th abbr="2013 estimate">2013 estimate<a href=note-5
> > rel=help><sup>5</sup</a></th>
> 
> Nothing is wrong with your suggestion, but table navigation with screen reader
> is burdensome when keyboard focus shifts because the target (footnote) is
> outside the table. For large tables that reference footnotes from within <td>
> or even <th>, managing focus for most user groups can be diffcult. Here
> longdesc, when used, can be helpful.

I don't get how @longdesc would help here given the target of @longdesc would
be outside the table too.

-- 
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 Monday, 10 September 2012 22:38:36 UTC