WAI discussion on HTML alt

12 Feb 2009

See also: IRC log


Cooper, Jeanne, Ben_Caldwell, Joshue, JR, Cynthia, Matt_May


-> http://www.w3.org/2009/02/04-cg-minutes Previous meeting

testing "We want HTML5 to provide mechanisms for providing short text alternatives"

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

Testing "We want HTML5 to provide mechanisms for providing long text alternatives."

<Joshue> yes

<Joshue> It has been retired

RESOLUTION: We agree HTML5 should provide mechanism(s) for providing long text alternatives

short and long text alternatives mutually exclusive?

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

structured text alternatives

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.

test consensus on "We want the alt attribute to be one of the mechanisms HTML provides"

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

reusing existing text as a long description

gv: This is implicit in our support of aria-describedby

so OBE

Should short text alternative be required always

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

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2009/02/12 21:19:58 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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


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]