W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > October to December 2010

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

From: Simon Harper <simon.harper@manchester.ac.uk>
Date: Tue, 30 Nov 2010 17:18:39 +0000
Message-ID: <4CF531EF.8030508@manchester.ac.uk>
To: Jim Allan <jimallan@tsbvi.edu>
CC: WAI-ua <w3c-wai-ua@w3.org>
Don't we cover this in out definition - in the flash or anything 
embedded is a kind of UA and therefore must provide access - I'm sure I 
set a whole set of text and discussion on this last year?

Cheers
Si.

=======================

Simon Harper
University of Manchester (UK)

More: http://simon.harper.name/about/card/


On 30/11/2010 16:57, Jim Allan wrote:
> 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 <mailto: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 
> <mailto: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 <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 <#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.9315fax: 512.206.9264http://www.tsbvi.edu/
>
> "We shape our tools and thereafter our tools shape us." McLuhan, 1964
>
>
Received on Tuesday, 30 November 2010 17:19:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 30 November 2010 17:19:49 GMT