- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Tue, 8 Mar 2011 04:19:54 +0100
- To: "jackalmage@gmail.com" <jackalmage@gmail.com>
- Cc: HTML WG LIST <public-html@w3.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>, Steve Faulkner <faulkner.steve@gmail.com>
Leif Halvard Silli, Tue, 8 Mar 2011 03:52:58 +0100:
(In reply to a letter by Tab:)
>> UAs must already have ways to delay
>> showing in-band information until requested, so as to correctly
>> represent the <details> element, for example. The same mechanism can
>> be used for <canvas>; while I'm not in any place to recommend UI for
>> screen-readers, it may even make sense to present <canvas> and
>> <details> in a unified fashion.
> But the comparison with <details> seems odd to me: For <details>, users
> first usually get a "summary" in the <summary> element, which they they
> can use when deciding about looking at "the details". There is no
> similar thing in <canvas>. (At least as long as we literally keep for
> example the @aria-label out the picture.)
When the hide-until-activated-by-AT-user behaviour is sought for, and a
<img> element is not what the author wants to use, then one could
eventually probably place <details> in the fallback:
<canvas src="complex-chart.png">
<details>
<summary>Complex chart describing x, y, z.</summary>
<table>
-data that the chart represents-
</table>
</details>
</canvas>
Issues, in contrast with @longdesc:
* legacy user agents, including text based user agents, do not
support <details>, so they would display the entire thing.
(Though the text/console based browsers don't understand
@longdesc either, so wouldn't matter so much for those.)
* requires more preplanning/thinking about how the user will
- or should - interact than use of a @longdesc would.
Leif Halvard Silli
Received on Tuesday, 8 March 2011 03:21:30 UTC