Re: DRAFT analysis of fallback mechanisms for embedded content ACTION-66

Dear task force,

in fact we were hoping for a little more feedback on this list regarding 
"equivalent, accessible fallback content" for AT as well as "repair 
fallback content" in case the browser doesn't support an element at 
all.[1]  I hope the reason for the silence is that you are still in a 
Thanksgiving food coma. ;)

Michael Cooper wrote up some use cases how fallback content could be 
handled consistently in embedded content in the future.[2]  If you have 
difficulties accessing that HTML table please let us know.

The base for the table was the following gap analysis of bug #8885 [3] 
that addresses fallback content for embedded content [4].  "Embedded 
content" consists of the following elements:

img, iframe, embed, object, param, video, audio, source, track, canvas, 
map, area, MathML, and SVG.

In summary:

- <img> has @alt that acts both as repair and as accessible fallback, 
details are discussed in ISSUE-31 [5].
- <iframe> is a browser window that could be empty, no fallback required.
- <embed> doesn't have any fallback content at all.  <embed> itself is 
considered as fallback for <object>.
- <object> has repair fallback content, but no accessible fallback.
- <video> has repair fallback. It has a poster image without @alt 
(ISSUE-142)[6].  It can contain several <track> elements (see below). 
It contains control buttons (are they mapped to A11Y API?) and a context 
menu. More details discussed in ISSUE-9 (video accessibility) [7].
- <audio> has repair fallback.  It can contain several <track> elements 
(see below).  It contains control buttons (mapped to A11Y API?) and a 
context menu.  It doesn't have @summary or @alt.
- <source> has an implicit @label and @language for closed captions 
defined in the closed format.
- <track> has explicit @label and @language attributes.  @label is 
dynamic and can by changed by script.  @language can include sgn-X (sign 
language).
- <canvas> has repair fallback.  Accessible fallback is discussed in 
ISSUE-74.[8]
- <map> and server-side image maps don't have a @summary, details are 
handled in <area>s.
- <area> has @alt.
- MathML has the <math> element that has @alttext.
- SVG has a <desc> element that can contain an <img> with @alt.

So we have:

1. elements like <img> and <math> that have some kind of @alt on the top 
element,
2. elements like <video>, <audio>, <svg>, <source>, and <map> where 
there is some kind of @alt on a child element, but no @summary on the 
container,
3. elements like <object>, <video>, <audio>, and <canvas> that have 
repair fallback, but no accessible fallback like exposure to AT (yet).
4. elements like <iframe> and <embed> that do not have any fallback 
content at all.

We think it would benefit authors, users, and browser and AT vendors to 
have a consistent approach, therefore we propose Michael's matrix. 
What's your opinion?

Cheers,
   Martin


[1] http://www.w3.org/html/wg/wiki/DefinitionFallBackContent
[2] Michael's matrix: 
http://lists.w3.org/Archives/Public/public-html-a11y/2010Nov/att-0246/embeddedcontent.html
[3] Bug #8885: http://www.w3.org/Bugs/Public/show_bug.cgi?id=8885
[4] Embedded content: 
http://dev.w3.org/html5/spec/embedded-content-1.html#embedded-content-1
[5] ISSUE-31:  http://www.w3.org/html/wg/tracker/issues/31
[6] ISSUE-142: http://www.w3.org/html/wg/tracker/issues/142
[7] ISSUE-9:   http://www.w3.org/html/wg/tracker/issues/9
[8] ISSUE-74:  http://www.w3.org/html/wg/tracker/issues/74

Received on Tuesday, 30 November 2010 17:51:37 UTC