See also: IRC log
-> http://www.w3.org/2009/02/04-cg-minutes Previous meeting
gv: objections to statement?
jr: note it's plural; what if they proposed e.g., describedby only?
gv: could make plurality optional
RESOLUTION: We agree HTML5 should provide mechanism(s) for providing short text alternatives
<Joshue> yes
<Joshue> It has been retired
RESOLUTION: We agree HTML5 should provide mechanism(s) for providing long text alternatives
jr: a particular piece of content should be able to have both short and long descriptions
<discussion of aria-labelledby, aria-describedby, alt>
cs: there are times we want only short, or only long, or both
gv: only long?
<Joshue> JOC: I agree that the language about mutually exclusive could be confusing.
cs: an article might be the description for a picture, don't need a short text alternative
gv: still need to know what it is
cs: role can do that
gv: but still don't know details of the picture
cs: there are scenarios where the surrounding text is sufficient
<need to add a label anyway>
cs: label doesn't hurt, but doesn't add anything
jr: can imagine situations
gv: still worry that you need to know "what" the image is, and allowing omission of short alternative could be wildly abused
leave people guessing, and people may make poor judgements
cs: worry HTML WG will consider it a logical fallacy that long description is never sufficient absent a short description
gv: maybe you'd get redundant info sometimes, but seems enough of an edge case it's best to just say short alternative is required
cs: can live with that, let's make sure it's clear we've consider a) the edge case and b) the short label doesn't hurt anything in coming up with this
<Joshue> JOC: Should how these tools are used be basically up to the judgement of authors anyway?
mc: wonder if people might fudge things by e.g., pointing labelledby and describedby to the same target
gv: would be violation of what a label is
mc: ARIA deliberately doesn't differentiate them clearly
<Joshue> JOC: Does ARIA need to differentiate them? A discussion for another day..
gv: generally we've felt short is always needed, and long is needed
mechanisms for text alternatives that don't differentiate between short and long don't seem to have been in use
<Joshue> +1 to Cythias rewording idea
<JR> +1
<Joshue> +1
RESOLUTION: We agree HTML5 should provide mechanisms to provide both short and long text alternatives at the same time
gv: should text alternative be structured?
<Joshue> JOC: If a text alternative needs to be structured then it should be, otherwise not
<Joshue> JOC: In terms of using normative language.
gv: clarify we're talking of whether the mechanism is capable of structuring text alternatives, not whether we require it of authors
jr: question if long desc need to be structurable
mc: if it's something that needs to be a "long" description, it should have structure
RESOLUTION: We agree mechanism(s) for long text alternatives should be capable of handling structured content
gv: do we want to say short should also be structurable, or be silent?
jr: consider alt "Photo of FBI headquarters", would want to put <abbr> on "FBI"
gv: maybe we want them to "consider" structured short alt?
js: don't want to break backward compatibility
mc: alt should stay as it is, but new mechanisms might support structure
<Joshue> JOC: I think the use cases for this will probably relate more to longer descriptions. More terse descriptions will probably not need this kind of structuring capability.
jr: would like to restrict the structure to text structure (no fancy stuff in a description)
<Joshue> +q
RESOLUTION: We
suggest new mechanisms for short text alternatives should be
capable of handling structured content
... Our primary concern with short text alternatives is that
they be able to inline support text structure, such as
abbreviations, language changes, emphasis, etc.
... Our primary concern with long text alternatives is that
they be able to support block and inline text structure, such
as abbreviations, language changes, emphasis, tables, headings,
etc.
RESOLUTION: We recommend continued inclusion of the "alt" attribute as a non-deprecated mechanism to provide short text alternatives
<discussion about whether longdesc should be deprecated; maybe premature to decide either way; relationship to anticipated support for ARIA>
gv: maybe if AT support for aria-describedby is sufficient when HTML5 being finalized, longdesc could be deprecated
mc: Do note that aria-describedby only points to an internal resource (IDREF), while longdesc can also reference an external resource
<concern about this>
gv: If the target of aria-describedby contains a link to an external description, that should be sufficient
jr: concern this introduces a dependency on AT vendors that HTML WG can't manage
<cyns> +1 jan
mm: clarify that longdesc is currently considered "obsolete", has been removed from HTML spec
RESOLUTION: Because we believe aria-describedby will be supported by AT at least as well as longdesc when HTML5 goes to Rec, we believe it is acceptable to make longdesc obsolete in HTML5
gv: This is implicit in our support of aria-describedby
so OBE
mc: note this is not the same question as whether "alt" should be required
-> http://www.w3.org/WAI/PF/aria/#presentation ARIA presentation role
A presentational element wouldn't even need short text alternative because the role implies it can be omitted
gv: personal view is HTML shouldn't require alt attribute
even WCAG doesn't require text alternatives in all situations
<JR> MM: Could ask for @alt OR labelled-by OR role=presentation
<much good discussion but scribe failing to capture while also participating>
noalt idea
maybe call it altneeded
have a role that indicates alt needed?
(issue with multiple roles, not adding roles to ARIA right now)
maybe a validity check that if role!=presentation then alt|labelledby [must be] present
still issues of uncooperative authors
tools that genuinely don't know what to do
<JR> other idea: @yesalt (means yes you can trust my alt="")
we don't want the inaction of an uncooperative author to have same presumed semantics as some mechanism we define
jr: maybe we should say alt="" no longer means ignore, must use role=presentation
cs: what about existing content?
jr: that's HTML4
mm: UAs won't distinguish HTML 4 from HTML 5 content much
bc: won't get around bad author behaviour
noalt just gives them a way to say they're being bad
gv: we don't want validity to push authors into doing stupid things
let's return to this topic in next call
NEXT MEETING: Wednesday 18 February, 20:00 UTC
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/RESOLUTION: We recommend continued inclusion of the "longdesc" attribute as a non-deprecated mechanism to provide long text alternatives// Found embedded ScribeOptions: -final *** RESTARTING DUE TO EMBEDDED OPTIONS *** Found Scribe: MichaelC Inferring ScribeNick: MichaelC Default Present: Cooper, Jeanne, Ben_Caldwell, Joshue, JR, Cynthia, Matt_May Present: Cooper Jeanne Ben_Caldwell Joshue JR Cynthia Matt_May Got date from IRC log name: 12 Feb 2009 Guessing minutes URL: http://www.w3.org/2009/02/12-cg-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]