See also: IRC log
<MichaelC> Discussion of uses cases
<MichaelC> considered the following:
<MichaelC> 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...
<MichaelC> ...DOM support).
<MichaelC> Long text alternative can substitute for the object, fairly completely. Normally it complements a short text alternative but in the case of transcripts may stand on its own.
<MichaelC> 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.
<MichaelC> 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.
<MichaelC> Advisory / tooltip is 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.
<MichaelC> Idiosyncratic direct accessibility means 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...
<MichaelC> ...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.
<MichaelC> Specify none needed is for formats that need to be able to indicate that they are "presentational" and no accessibility fallback is needed.
<MichaelC> discussed which of these use cases apply to which types of embedded content
<MichaelC> ACTION: Michael to send his embedded content analysis to the task force list [recorded in http://www.w3.org/2010/11/23-a11y-bugs-minutes.html#action01]
<MichaelC> related to the above
<kliehm> Bug triage sub-team thinks this is not a HTML A11Y TF priority. The primary
<kliehm> accessibility need is to provide headings at all; providing them in an outline
<kliehm> or clearly associated with landmarks is helpful but only if implemented
<kliehm> consistently. Further, HTML 5 provides various ways to achieve this (though
<kliehm> none of them are mandatory). There could be some value in looking more closely
<kliehm> at section types aka landmarks in HTML.next, but don't think we should in the
<kliehm> HTML 5 timeframe. Furthermore, the issue is more with user agent presentation
<kliehm> existing heading features than with the HTML spec itself.
<kliehm> Bug triage sub-team think this is a HTML A11Y TF priority, is already in active discussion with the media sub-group.
<kliehm> Adding a11yTF keyword
<MichaelC> Bug triage sub-team agrees this is an A11Y TF priority. However, it is clear this will come back as needsinfo in its current state. Assigning to Rich to address within the canvas sub-team and provide the needed info. Assign to Ian when complete.
<MichaelC> Bug triage sub-team doesn't think this is a A11Y TF priority. It's not an HTML feature, just a spec clarity issue. Our understanding is there is a specific reason for the phrasing approach, and doesn't need task force involvement.
<kliehm> Homework for next week: shepherding Michael's post regarding embedded content to the list.
<kliehm> scribe: MichaelC
<kliehm> scribe: Martin_Kliehm
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/11999/11199/ Found Scribe: MichaelC Found Scribe: Martin_Kliehm WARNING: 0 scribe lines found (out of 82 total lines.) Are you sure you specified a correct ScribeNick? Scribes: MichaelC, Martin_Kliehm Default Present: kliehm, Michael_Cooper Present: Marco_Ranon Martin_Kliehm Michael_Cooper Regrets: Laura_Carlson Agenda: http://lists.w3.org/Archives/Public/public-html-a11y/2010Nov/0229.html Got date from IRC log name: 23 Nov 2010 Guessing minutes URL: http://www.w3.org/2010/11/23-a11y-bugs-minutes.html People with action items: michael[End of scribe.perl diagnostic output]