- From: Jim Allan <jimallan@tsbvi.edu>
- Date: Tue, 30 Nov 2010 10:57:58 -0600
- To: WAI-ua <w3c-wai-ua@w3.org>
- Message-ID: <AANLkTi=68dccZEc0_v+6c8gqVRdtXfkr72Lyc8R0_kc5@mail.gmail.com>
This is very interesting work. It has direct implication for UAAG 1.1
Provide access to alternative content.
One of the fall back mechanisms that I don't think we have covered, but we
imply, is the internal content of <object> or <embed>. If the technology
(i.e. Flash) is installed, there is no currently UA implemented method to
access the alternative content.
Do we need an explicit GL that UA must allow access to 'fallback' content
internal to <object> etc.?
Jim
---------- Forwarded message ----------
From: Michael Cooper <cooper@w3.org>
Date: Wed, Nov 24, 2010 at 4:33 PM
Subject: DRAFT analysis of fallback mechanisms for embedded content
ACTION-66
To: HTML Accessibility Task Force <public-html-a11y@w3.org>
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 <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 <#12c800636f48d585_html4>
- HTML 5 <#12c800636f48d585_html5>
- General issues with fallback mechanisms<#12c800636f48d585_generalissues>
- Use cases <#12c800636f48d585_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<#12c800636f48d585_general_alt> see
general issues with @title <#12c800636f48d585_general_title> see general
issues with @longdesc <#12c800636f48d585_general_longdesc> object See
general issues with embedded content <#12c800636f48d585_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
--
Jim Allan, Accessibility Coordinator & Webmaster
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315 fax: 512.206.9264 http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964
Received on Tuesday, 30 November 2010 16:58:33 UTC