- From: Simon Harper <simon.harper@manchester.ac.uk>
- Date: Tue, 30 Nov 2010 17:18:39 +0000
- 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 UTC