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

Re: Proposal for <canvas src> to allow images with structured fallback by Tab Atkins Jr.

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>
Message-ID: <20110308041954571244.2c864528@xn--mlform-iua.no>
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">
  <summary>Complex chart describing x, y, z.</summary>
    -data that the chart represents-

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:20:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:55:53 UTC