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

I thought the use cases for media would raise some eyebrows.

The thinking was that media always need a full alternative, and
therefore a summary would be redundant. By contrast, many image types
(including images created / loaded by svg, canvas, img, object, and
embed) might have a summary that's useful but not a full text
alternative - say a brief summary of the trending in a chart, more than
you'd put in a short text alternative but not containing the full
information of a long text alternative.

However, applying the use case of summary to any of these media types is
both novel and subjective, and I imagine the argument can be made that a
summary is useful for all these embedded content types. I was trying to
keep the set of use cases as constrained as possible, but if the general
consensus is that it's applicable to all the media types, I don't object.

My thinking was similar for caption - an image might have a "caption" as
you see in a newspaper article, but I wasn't clear if videos would be
treated in that manner. However, evolution of the Web means maybe that
will become a norm, so again I can accept the use case if the consensus
is behind it.

Trying to meet all these use cases would entail a significant expansion
of the fallback mechanisms that we've been considering up to now. I was
trying to minimize that expansion. But if it does seem that an expanded
set of use cases is truly needed, then that's what we should work from
to figure out the fallback mechanisms question.

I do worry about the "can't get there from here" factor with respect to
existing support already defined. I can try to address that in a
hypothetical engineering proposal which is the next step in this process
(I think). My disclaimer on that is that it's just to show how we
*might* engineer to meet all the use cases - not necessarily how I think
the HTML spec will actually end up meeting them.

Michael

Silvia Pfeiffer wrote:
> Hi Michael,
>
> I think this is tremendous work and should help us get a better
> structure and consistent attribute names for accessibility.
>
> I only have a few questions about the media elements.
>
> For a short text alternative for video (not for audio though) I would
> expect that what is being seen on screen as the representative image
> (be that a poster or the first frame) needs some explanation, similar
> to the @alt on img. I'd prefer that to label - what would the label be
> for?
>
> Also, I am curious why you do not see a need for a summary on audio
> and video? I can see that a full transcript goes into the long text
> alternative, but a summary is different and useful to both, sighted
> and vision-impaired users. In fact, it is often provided underneath
> the video or in an overlay.
>
> And finally on caption (not captions but caption as used for images) -
> while it's not customary to provide a caption subtext on video or
> audio, it is very customary to display a video/audio title (and a
> short summary as stated). Maybe in the video case the video "caption"
> is the video title? It is also very important from an accessibility
> perspective since it explains to sighted and thus also vision-impaired
> users what can be expected in the video and should probably be made
> part of our concerns.
>
> I'm not sure how the media use cases fit with your classification and
> it would be great to clarify this.
>
> Cheers,
> Silvia.
>
>
> On Thu, Nov 25, 2010 at 9:33 AM, Michael Cooper <cooper@w3.org
> <mailto:cooper@w3.org>> wrote:
>
>     The attached file is a draft analysis of how fallback mechanisms
>     are applied to various types of embedded content in HTML. The
>     analysis is an important step towards determining where the
>     support provided by the HTML specification needs to be extended or
>     modified to ensure all accessibility use cases are covered. The
>     analysis is prepared primarily by Michael Cooper, with input from
>     members of the Bug Triage sub-team of the HTML Accessibility Task
>     Force.
>
>     This is a draft analyis put forth for discussion and should not be
>     viewed as complete, final, or constituting a proposal in itself.
>
>     This analysis relates to Bug 8885
>     <http://www.w3.org/Bugs/Public/show_bug.cgi?id=8885> and executes
>     ACTION-66 <http://www.w3.org/WAI/PF/HTML/track/actions/66>. As
>     discussed on 5 November 2010
>     <http://www.w3.org/2010/11/04-html-wg-minutes#item13>, preliminary
>     work on this was done by the bug triage sub-team on 16 November
>     2010 <http://www.w3.org/2010/11/16-a11y-bugs-minutes#item01> and
>     22 November 2010
>     <http://www.w3.org/2010/11/23-a11y-bugs-minutes#item02>, and it is
>     now being taken to the task force for wider review and discussion.
>
>     Michael
>     -- 
>
>     Michael Cooper
>     Web Accessibility Specialist
>     World Wide Web Consortium, Web Accessibility Initiative
>     E-mail cooper@w3.org <mailto:cooper@w3.org>
>     Information Page <http://www.w3.org/People/cooper/>
>
>
>       Fallbacks for embedded content
>
>     This is an attempt to analyze how fallback mechanisms are applied
>     to various types of embedded content in HTML. The analysis is an
>     important step towards determining where the support provided by
>     the HTML specification needs to be extended or modified to ensure
>     all accessibility use cases are covered. The analysis is prepared
>     primarily by Michael Cooper, with input from members of the Bug
>     Triage sub-team of the HTML Accessibility Task Force.
>
>     This is a draft analyis put forth for discussion and should not be
>     viewed as complete, final, or constituting a proposal in itself.
>
>     Sections of this document:
>
>         * HTML 4 <#12c80061e2356983_html4>
>         * HTML 5 <#12c80061e2356983_html5>
>         * General issues with fallback mechanisms
>           <#12c80061e2356983_generalissues>
>         * Use cases <#12c80061e2356983_usecases>
>
>
>         HTML 4
>
>     The table below shows known fallback mechanisms for embedded
>     content elements in HTML 4. Only elements defined in HTML 4 are
>     listed, plus the <embed> element which is a "de facto" HTML 4
>     element. The fallback mechanisms and issues are as generally used
>     in the wild, not as defined by the specification. This is in order
>     to identify the real support baseline upon which we are building.
>
>     Embedded content elements in HTML 4 Element / Approach  @alt
>     @title  embedded content  @longdesc  @name  <title> of referenced
>     content
>     embed  not standardized or widely used but recognized by some user
>     agents     not standardized, but may be supported by some user
>     agents         
>     iframe     @title widely recognized as labeling the frame, but
>     this was a narrowing of that general-purpose attribute      
>     Often misunderstood and used for a text label, or at used in an
>     "if all else fails" scenario, but this does not function well as
>     it's a token for processing with extreme limitations  Many
>     advocated fetching the referenced content and using the title as a
>     label for the frame, but it requires support for the element,
>     fetching an external resource, and being able to find a title
>     img  see general issues with @alt
>     <#12c80061e2356983_general_alt>  see general issues with @title
>     <#12c80061e2356983_general_title>     see general issues with
>     @longdesc <#12c80061e2356983_general_longdesc>      
>     object        See general issues with embedded content
>     <#12c80061e2356983_general_embedded>         
>
>
>         HTML 5
>
>     The table below shows fallback mechanisms documented in the HTML 5
>     specification for the embedded content types supported by the
>     specification. By contrast with the HTML 4 table, this HTML 5
>     table lists what the specification supports, /not/ what is
>     generally used in the wild. This is because the purpose of this
>     exercise is to review the specification, not current usage. Note
>     that the set of available fallback mechanisms (shown as column
>     headers) is different from the set used in HTML 4.
>
>     Embedded content elements in HTML 5 Element / Approach  @alt
>     @title  embedded content  @longdesc  @aria-labelledby
>     @aria-describedby
>     audio        supported, after <track> elements         
>     canvas        supported         
>     embed        disallowed         
>     iframe        permitted but markup will be removed and only for
>     HTML serialization; not specified if it's meant to be a
>     fallback         
>     img  @alt for short descriptions     not support@ted  removed
>     (under dispute)  proposed as replacement for @alt  proposed as
>     replacement for @longdesc
>     math        deferred to features of MathML, fallbacks should be
>     possible using @alttext         
>     object        supported, after <param> elements         
>     svg        deferred to features of SVG; fallbacks should be
>     possible using <desc> and <title>         
>     video        supported, after <track> and potentially <source>
>     elements         
>
>
>         General issues with fallback mechanisms
>
>     Some of the fallback mechanisms identified above have issues in
>     theory or practice that were generic to several embedded content
>     elements and / or were too long to include in the table. These
>     issues are shown here.
>
>
>           @alt
>
>         * simple and long history
>         * not internationalized and doesn't support phrase markup
>         * lack of feature to specify "decorative" images have led to
>           various heuristic uses of this attribute, but not complete
>           universality in these
>
>
>           @title
>
>         * variously proposed / used as a replacement and / or
>           supplement to @alt, but wildly inconsistent from an
>           accessibility perspective
>         * primacy between @alt and @title unspecified: does @title
>           come first, last, or cover @alt? Or should be ignored from
>           an accessibility perspective?
>
>
>           @longdesc
>
>         * provides explicit long descriptions, contrasted with
>           "d-link" approaches that don't semantically tie description
>           to image
>         * description referenced by a URI, but user agent behaviour
>           not specified (e.g., fetch and present? give user a link? etc.)
>         * many argue that a URI consisting only of a fragment on the
>           same page should be valid, but unclear that implementations
>           support this use case well, and expected UA behaviour not
>           specified
>
>
>           embedded content
>
>         * mixture of fallbacks and param elements
>         * unclear whether fallback intended for non-support of
>           element, non-support of the referenced content language
>           (fallback only visible if the technology not supported), or
>           accessibility (fallback displayed at user request)
>         * in practice, accessible fallbacks not available if browser
>           supports the technology, which is largely the case today
>
>
>         Use cases
>
>     This is an attempt to propose use cases for fallbacks, as a step
>     towards understanding what use cases remain to be met. The focus
>     is on /accessibility/ use cases. Use cases for non-support of the
>     embedded content element and non-support of the referenced content
>     technology are also important, and should not be confounded with
>     accessibility use cases. It may be necessary to expand on this in
>     the future in order to cleanly separate them.
>
>     The following list describes the use cases identified, and the
>     table shows which embedded content types may have the
>     corresponding use case. Beware of token overload; the terms are
>     used here as defined below, and should not be interpreted to have
>     any other meanings inherited from other contexts. Cells have an x
>     where the use case is believed to apply to the embedded content
>     type, otherwise they are blank.
>
>     Short text alternative
>         Can substitute for the object, sometimes on its own and
>         sometimes complemented by an additional long text alternative.
>         Normally, short text alternatives aren't provided if direct
>         accessibility is possible, but it may still be used if direct
>         accessibility for whatever reason isn't enabled (e.g., canvas
>         makes a simple image and there is no need to enable full
>         shadow DOM support).
>     Long text alternative
>         Can substitute for the object, fairly completely. Normally it
>         complements a short text alternative but may stand on its own,
>         e.g., in the case of transcripts. Label
>         Identifies the object and tells the user if they want to go
>         into it more. This has both non-accessibility and
>         accessibility use cases. Frequently confounded with short text
>         alternatives, it's a distinct use case and optimally should
>         have a different implementation. Generally, if a label is
>         provided, a short text alternative would be redundant and is
>         not separately required.
>     Caption
>         This is a visible label, such as appears below an image in
>         many publications. This is not primarily an accessibility use
>         case, but is confounded in a few ways: 1) implementation of
>         the caption is often (incorrectly, in my opinion) taken from
>         the implementation of short text alternatives; 2) captions and
>         short text alternatives are often both provided where their
>         content is identical and redundant; 3) when a caption is
>         provided, it should also generally be sufficient to meet the
>         short text alternative use case (but not vice versa).
>     Summary
>         Is more than a short text alternative, but not the complete
>         replacement that a long text alternative should be. Like a
>         label, it may help a user decide whether to explore more, or
>         may be a sufficient overview of the object in many cases.
>     Idiosyncratic direct accessibility
>         The object content itself provides ways to make it accessible,
>         e.g., caption formats in video, features of SVG, the shadow
>         DOM of canvas, etc. Generally, if a format supports direct
>         accessibility it may still benefit from a label, but should
>         not require a short or long text alternative. However, some
>         objects may not enable the direct accessibility and still
>         require external text alternatives, such as a short text
>         alternative for a simple image implemented with canvas, or a
>         transcript (i.e., long text alternative) for an audio. Note
>         that for <embed> and <object>, this depends on features of the
>         loaded content language, so these elements may or may not
>         require separate fallbacks within the HTML.
>     Advisory / tooltip
>         A kind of text label that is usually displayed as a tooltip.
>         Although frequently taken from short text alternatives or
>         captions, /this is not an accessibility use case/. It is in
>         the table to show that it is a distinct use case and should
>         not be confounded with other accessibility fallbacks.
>     Specify none needed
>         For formats that need to be able to indicate that they are
>         "presentational" and no accessibility fallback is needed. 
>
>     Fallback use cases for embedded content elements Element / Use
>     case  short text alternative  long text alternative  label
>     caption  summary  idiosyncratic direct accessibility  advisory /
>     tooltip  specify none needed
>     audio     x  x        x  x  x
>     canvas  x  x  x  x  x  x  x  x
>     embed  x  x  x  x  x  x  x  x
>     iframe        x  x  x     x  x
>     img  x  x     x  x     x  x
>     math  x              x  x  x
>     object  x  x  x  x  x  x  x  x
>     svg  x     x  x  x  x  x  x
>     video     x  x        x  x  x
>
>
>

-- 

Michael Cooper
Web Accessibility Specialist
World Wide Web Consortium, Web Accessibility Initiative
E-mail cooper@w3.org <mailto:cooper@w3.org>
Information Page <http://www.w3.org/People/cooper/>