WAI discussion on HTML alt -- 06 Mar 2009

josh, we are trying to find someone else on skype who can bridge you in

<Joshue> Thanks GJR

<greggvanderheiden> who is on the phone

<JR> josh I can try and conf you in on Skype...what's your Skype name?

<Joshue> Its joshueoconnor Jan

<MichaelC> scribe: MichaelC

<oedipus> example of FIGURE, LEGEND and alt in: http://lists.w3.org/Archives/Public/www-archive/2009Mar/0024.html

<oedipus> <LEGEND id="l1">The Three Stages of a Butterfly's Life Cycle</LEGEND>

<oedipus> <IMG alt="Stage 1: The larval stage." src="butterfly1.svg"

<oedipus> longdesc="butterfly1.html">

<oedipus> <IMG alt="Stage 2: The pupal stage." src="butterfly2.svg"

<oedipus> longdesc="butterfly2.html">

<oedipus> <IMG alt="Stage 3: The adult stage." src="butterfly3.svg"

<oedipus> longdesc="butterfly3.html">

<JR> http://esw.w3.org/topic/PF/XTech/HTML5/TextAlternativeProposal

Continuing review of proposal http://esw.w3.org/topic/PF/XTech/HTML5/TextAlternativeProposal

gv: changing "must" to "would" on That alt="" WITHOUT an accompanying role="presentation" [ would ] trigger a non-critical warning recommending use of role="presentation" (but is still valid).

<oedipus> gjr may object

gv: adding second sentence in "We are explicity intending to free HTML5 up to include advice about use cases that are not accessibility related. [However any guidance on providing text alternatives must not contradict WCAG 2.0]"

not sure we actually want to go this far

perhaps add "... for people with disabilities..."

<oedipus> GJR: still wants "MUST" not "would"

<JR> # That HTML5 make it clear that for guidance on the accessibility requirements for text alternatives, authors should consult WCAG 2.0.

<JR> # That any HTML5 guidance on providing text alternatives must not contradict WCAG 2.0.

<oedipus> laura suggested: "That any examples in HTML5 are to be non-normative coordinated with WAI PF WG."

jr: propose above

should cover it without going too far

<Laura> +1 to jan

<Joshue> +1 to Jans verbiage

<oedipus> plus three-quarters to Jan

<Joshue> I find the text "That any examples in HTML5 are to be non-normative coordinated with WAI PF WG." a little difficult to parse.

gv: worried about consequences of going too far in what we ask HTML to say

<Joshue> +1 to GJR

e.g., they wanted to have ways to deal with posting 1000 pictures, we wanted alt to be required, they wanted placeholders if it was gonna be required

we might end up in a similar situation

<Joshue> I think the language of our part should be strong and clear. The batch example is one use case, the advice is there, its up to the author how they use it.

thought we got to a point that we would accept them providing advice about text alternatives, but not say it will satisfy WCAG 2.0

jr: so we agree guidance on accessibility requirements should satisfy WCAG 2.0

we're saying HTML could provide advice that contradicts WCAG?

<oedipus> ack oe\

<Zakim> oedipus, you wanted to say the batch uploading of photos is a canard - if the tool allows the author to add alt text after the upload

<Joshue> I agree with Gez.

gl: don't see problem with considering things that aren't usable non-compliant; they can be non-compliant if author wants

gr: the whole batch upload issue is a canard

<oedipus> GJR: not compliant until add @alt -- that's life

<Joshue> The use case is potentially, non-compiiant, full stop really. The tool can facilitate the addition of accessibility meta data and that is half the battle.

gv: 95% of Web is not valid; it's odd that they zero in on photo collections and want to define how to make them valid

<oedipus> strong plus 1 to Joshue

why not let that small # of pages not be valid?

<oedipus> GJR: straw poll - who enjoys looking at hundreds of pictures of anyone's vacation

gr: pages with lots of photos are generally uninteresting anyway

don't think the use case needs to hamstring us

it's an authoring tool and platform problem

those tools can insert placeholder alt to be valid

the issue distracts us

cs: consider if developer of photo site wants to validate

<oedipus> good point cynthia

do they care if user pages validate, or just their authored content?

gv: which is the WCAG Partial Conformance scenario

cs: it's under ATAG re encouraging user to do it right; site can decide whether or not to conform to ATAG, yet still conform to WCAG

<oedipus> fickr being 100% accessible and valid is as infeasible as youTube being 100% valid and accessible

<oedipus> they want to play with statistics -- we are dealing with individuals and individual needs

<oedipus> statistical arguments reveal more about authoring tool limitations than anything else

gv: HTML is defining page level conformance, and validation

<oedipus> he should follow ATAG!!!

cs: isn't validation a developer benefit?

lgr: <missed>

gr: need to provide feature to add alt

lgr: so in situation where allowed to add alt but doesn't, what happens?

<Joshue> One of the issues was about whether that tool should offer some kind of repair, right?

gr: so the page is invalid

lgr: that is user's fault, but the authorin tool might get blamed

gr: <missed>

<Laura> Henri 's tool would conform. The author 's content wouldn't.

<Joshue> Good point Laura.

<oedipus> GJR: can't control usage of tools

gv: what happens when tools asks for something else required, and user doesn't comply?

cs: e.g., valid src

<oedipus> good point laura

<oedipus> 2 part compliance: accessibility of tool and the potential to produce accessible output

lgr: AU that outputs content that doesn't conform to WCAG, is the tool failing to comply to ATAG?

<several> no

<oedipus> JS: if you have a car accident the car's manufacturer isn't responsible for individual auto accidents

gl: HTML is focused on conformance

accessibility feels like a push-back to them

<Joshue> While a constraint based approach that is weighted positively towards accessibility is very very useful, there is little more that can be done beyond that if the author is not interested.

POV that authoring tool can never emit incorrect output for any reason

<Laura> An author can provide an address with the address element that isn't a contact address , which would not be considered compliant.

<Laura> The author obviously has a responsibility in using an authoring tool.

that's not a correct expectation, because of user factors

gv: either we have to say to HTML that we don't want any advice that contradicts WCAG, or that we don't want any advice *about disability* that contradicts WCAG

<oedipus> must not be tied to accessibility alone -- there are other valid use cases for @alt

in second case, the advice might be useful, just not for WCAG

<oedipus> what is the straw poll question?

ok with either approach, we need to pick one

cs: omitting alt could be like omitting src; tool can error or warn as it sees fit

<oedipus> plus 1 to line in the sand

<Joshue> +1

<Gez> +1

<Laura> +1

js: Straw Poll - Accessibility Guidance comes from WCAG, and HTML should not provide any guidance that conflicts with WCAG

<oedipus> plus 1 to line in the sand

<Joshue> +1

<Gez> +1

<Loretta> +1

<Laura> +1

<janina> +1

+1 Cytnhia

<greggvanderheiden> +1 can live with this one but prefer other

<JR> +1 can live with it

<oedipus> mat: +/- 0

<oedipus> MC: can live with, but prefer other option

<greggvanderheiden> +0

<oedipus> +1 support; +0 can live with it; -1 equals NO!

<8 plus, 3 live, 0 no>

gv: Straw Poll - Any advice regarding people with disabilities would conform to WCAG 2.0. All other advice would note if it conflicts with WCAG 2.0.

<Gez> -1

<janina> -1

<Laura> -1

<Joshue> I find the second part difficult to parse

<oedipus> strong minus 1

<greggvanderheiden> +o

<greggvanderheiden> +0

<Loretta> +0

<JR> -1 since more interpretation required

<Joshue> -1

<1 support, 4 can live, 6 oppose>

<Joshue> I am all for advice conforming to WCAG 2.0 as that should be the 'standard'. What are we really trying to say here?

consensus of this group supports the first proposal

<oedipus> as long as the SHOULD is an RFC2119 SHOULD, which is quite strong (do it, or explain why not)

<Joshue> +1 to GJR

<Joshue> +q

<oedipus> god = tbl

mc: appreciate that this would be the consensus of this group but worried HTML WG will reject and protract discussion

<Joshue> God may have something to say about that :-)

gr: we need to elevate the issue then

we should arbitrate accessibility

gv: but they'll feel we're trying to arbitrate validity

js: this gets down to why W3C has different domains of expertise

---next proposal in wiki---

gv: "terse" vs. "short"

<oedipus> HTML5 charter was changed on "2009/02/06"

gv: legend, is it new?

gr: borrowed from fieldset

<Joshue> -q

<oedipus> <LEGEND id="l1">The Three Stages of a Butterfly's Life Cycle</LEGEND>

<oedipus> http://www.w3.org/TR/html5/interactive-elements.html#the-legend-element

<oedipus> Content model:

<oedipus> * Either: one legend element followed by flow content.

<oedipus> * Or: Flow content followed by one legend element.

<oedipus> * Or: Flow content.

<oedipus> content model for FIGURE

<oedipus> http://www.w3.org/TR/html5/interactive-elements.html#the-legend-element

gv: editing " We suggest new mechanisms for terse (short) text alternatives (e.g. labelledby, LEGEND?? should be capable of handling structured content. Our primary concern is that short text alternatives be able to inline support text structure, such as abbreviations, language changes, emphasis, etc. ]"

<oedipus> HTML5 PWD "Contexts in which LEGEND element may be used: 1) As the first child of a fieldset element. 2) As the first child of a details element. 3) As a child of a figure element, if there are no other legend element children of that element."

<Loretta> \me have to leave now. bye!

<oedipus> http://www.w3.org/TR/html5/interactive-elements.html#the-legend-element

<oedipus> sample code for FIGURE, LEGEND, IMG and @alt: http://esw.w3.org/topic/PF/XTech/HTML5/TextAlternativeProposal?action=show#head-af43e90d8443e4c9354cc3d3c867df1bcd6a3254

<JR> THis can go:

<JR> re: HTML5 guidance around text alternatives for accessibility:

<JR> 1. That HTML5 make it clear that for guidance on the accessibility requirements for text alternatives, authors should consult WCAG 2.0.

<JR> 2. That any HTML5 guidance on providing text alternatives must not contradict WCAG 2.0.

<JR> This should stay:

<JR> re: the structure of @alt for IMG:

<JR> Assuming that HTML5 will be fully adopting ARIA...

<JR> 1. IMG is only valid under any of the following conditions:

<JR> * @alt is present (empty or non-empty)

<JR> * @labelledby is present (non-empty only)

<JR> * @role="presentation"

<JR> * the IMG is located within a FIGURE that has a non-empty LEGEND

<JR> 2.

<JR> That the proper use of @role="presentation" be taken from ARIA 1.0 and that an IMG without a @role attribute is assumed to be the equivalent of <IMG @role="image">

<oedipus> GJR: as long as the SHOULD and MUST are RFC2119 terms

<JR> 3. For cases in which it is appropriate for user agents to ignore the presence of the image (e.g., when they are used for decoration, formatting, or are invisible), one or both of the following may be used:

<JR> * @role="presentation"

<JR> * alt="" (also see (4))

<JR> 4. NOTE that alt="" WITHOUT an accompanying role="presentation" would trigger a non-critical validator warning recommending use of role="presentation" (but @alt="" remains technically valid)

<Joshue> +1 to Janina

<Joshue> It spans many issues..

<JR> IMG is only valid under any of the following conditions:

<JR> * @alt is present (empty or non-empty)

<JR> * @labelledby is present (non-empty only)

<JR> * @role="presentation"

<JR> * the IMG is located within a FIGURE that has a non-empty LEGEND

<oedipus> sample code for FIGURE, LEGEND, IMG and @alt: http://esw.w3.org/topic/PF/XTech/HTML5/TextAlternativeProposal?action=show#head-af43e90d8443e4c9354cc3d3c867df1bcd6a3254

<oedipus> <LEGEND id="l1">The Three Stages of a Butterfly's Life Cycle</LEGEND>

<oedipus> <IMG alt="Stage 1: The larval stage." src="butterfly1.svg"

<oedipus> longdesc="butterfly1.html">

<oedipus> <IMG alt="Stage 2: The pupal stage." src="butterfly2.svg"

<oedipus> longdesc="butterfly2.html">

<oedipus> <IMG alt="Stage 3: The adult stage." src="butterfly3.svg"

<oedipus> longdesc="butterfly3.html">

<oedipus> Each of the images in the 3 stages of a butterfly's life REQUIRE alt text and/or labelledby to provide them with unique and appropriate terse descriptions, just as each form control in a FIELDSET has its own LABEL defined for it, with the value of the LEGEND element providing a CAPTION-like function for the FIELDSET, so too does LEGEND provide a means of declaratively marking explicit bindings of groups of related objects

<oedipus> the LEGEND applies to all three images as a collection of related objects, available, for example, in a screen reader situation, either through a verbosity setting or via an extended query, such as MagicKey+TAB reads the alt text of the individual graphic which has focus, MagicKey+TAB pressed twice rapidly (or with a moderator key) provides the user with the LEGEND which describes, tersely, the group to which the individual image belongs, so that the user can be m

<oedipus> a) each individual image's terse alternative text;

<oedipus> b) the grouping to which the image belongs (if it is one of a series presented in a FIGURE) or any other modality-specific content contained in HTML5's media-specific elements, including AUDIO, VIDEO, OBJECT and CANVAS;

<oedipus> If (and only if) an image is broken up into pieces that are intended to be perceived as one image the text alternative for the _composite image_ can be for the first image with the other pieces marked as presentational. This does not apply to a series of pictures.

<oedipus> NOTE: To provide a terse descriptor for a collection of images contained in a FIGURE, LEGEND can be used to provide a terse description of the varied images. If the LEGEND is used for something other than a terse description then @alt or labelledby needs to be specified for each image.

<Joshue> Should the mechanism be designed to handle both (sic) use cases?

<inserted> ScribeNick: oedipus

GV: leave JR's as is - warning for 1; warning for multiple images in FIGURE, or warning should appear in LEGEND does it really describe the collection of images
... not validity error, but a warning
... does HTML5 spec state what validity errors and warnings are?

<Joshue> Good question, I am not sure if it specifies what the warning should be beyond some generic flag, is that correct?

GV: put IMGs inside of figure without alt on individual images using only LEGEND - should ask "does this fully describe this collection?"

CS: if rare, ok, if occurs each time, will be ignored

<Joshue> Lets make alt mandatory!

http://esw.w3.org/topic/PF/XTech/HTML5/TextAlternativeProposal?action=show#head-af43e90d8443e4c9354cc3d3c867df1bcd6a3254

what a novel idea, josh!

ack [Micro

JS: add WCAG URIs to proposals?

GV: doesn't change number 1 being correct

OLD:

That HTML5 validity REQUIRE terse text alternatives for non-text items that are not presentational and that these be provided using one of the HTML5 specified methods: (alt, labelledby, or legend).

* For example

For images; alt attribute or aria-labelledby can be used.

For an image that is a child of a figure; alt attribute, aria-labelledby, or legend can be used (would be valid).

o (this would apply to other non-text content as well)

<scribe> NEW:

Assuming that HTML5 will be fully adopting ARIA...

1. IMG is only valid under any of the following conditions:

* @alt is present (empty or non-empty)

* @labelledby is present (non-empty only)

* @role="presentation"

* the IMG is located within a FIGURE that has a non-empty LEGEND

plus 1 to replacing

<scribe> "new" number 2: "That the proper use of @role="presentation" be taken from ARIA 1.0 and that an IMG without a @role attribute is assumed to be the equivalent of <IMG @role="image">"

<scribe> "new" number 3: "For cases in which it is appropriate for user agents to ignore the presence of the image (e.g., when they are used for decoration, formatting, or are invisible), one or both of the following may be used:

* @role="presentation"

* alt="" (also see (4))"

<scribe> "new" number 4:

NOTE that alt="" WITHOUT an accompanying role="presentation" would trigger a non-critical validator warning recommending use of role="presentation" (but @alt="" remains technically valid)

plus one if change "would" to "will"

<Laura> "will" would be a good word to use.

<Joshue> would is rather non-comittal.

<Joshue> +1

<Joshue> remove the 'would' bit, I guess.

<Joshue> alt="" WITHOUT an accompanying role="presentation" triggers a non-critical validator warning recommending use of role="presentation" (but @alt="" remains technically valid)

<Joshue> how about 'triggers'?

plus 1 to "triggers"

GJR & JOC: propose removing "would" and changing tense to triggers

GV: edit made

<Joshue> good stuff :-)

the grouping to which the image belongs (if it is one of a series presented in a FIGURE) or any other modality-specific content contained in HTML5's media-specific elements, including AUDIO, VIDEO, OBJECT and CANVAS;

<Laura> I have to leave too. Bye.

long text 1: "Long text alternatives (to supplement terse text alternatives) (e.g. describedby ) are not required for validity (though they may be required by WCAG 2.0 for some types of non-text content). "

long text 2: "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"

<JR> axk JR

GJR: deprecate not obsolete

<Joshue> I would remove the part 'at least as well as longdesc '

<Zakim> oedipus, you wanted to say understand's JR's urge to seperate IMG from FIGURE advice and to say that i still think we should first give advice on terse alternatives and handle long

<Joshue> I don't think its a good idea to associate longdesc and aria-describedby in the same sentence as 'obsolete'. The inference being that aria-describedby may some day go down the same road.

<Joshue> I suggest re-wording to 'Because we believe aria-describedby will be supported by AT when HTML5 goes to Rec, we believe it is acceptable to make longdesc obsolete in HTML5'

<Joshue> but GJR a lot of what we are suggesting is based on the assumption of ARIA integration?

<Joshue> Yes, if would be good..

<Joshue> I wouldn't use the word assume...

<JR> Possible text: "Assuming that HTML5 will be fully adopting ARIA"

<Joshue> How about... 'If aria-describedby will be supported by AT when HTML5 goes to Rec, it is acceptable to make longdesc obsolete in HTML5'

JS: response from ChrisWilson to request to incorporate ARIA

<Joshue> Did ARIA not drop name spaces?

JS: very friendly message from CW

GV: what do we answer them?

<Joshue> AT is doing ARIA.

CS: browsers are doing it, but without namespacing...

JR: describedby as an attribute of HTML5 rather than point off to namespace

CS: agree theoretically, but all uas doing it anyway

<Joshue> There will be a battle over what will win when there are two similar elements in the spec (one ARIA and one native HTML 5) that do the same kind of thing.

<Joshue> I will be very surprised if ARIA gets the upper hand..

<Joshue> me HTML 6 lol

CS: prefer namespace extension mechanism, but would like 1.0 incorporated into HTML5

<Joshue> in the year 2525 ;-)

CS: what happens with HTML6 - if ARIA changes, do aria properties change?

MM: already a wish list for ARIA 2.0

CS: wouldn't be surprised if ARIA 2.0 beats HTML5 to Rec

MM: not the place to answer that question?\

JS: will be topic of discussion before next wednesday

GV: please refresh the wiki page

<Zakim> oedipus, you wanted to ask if anyone else noticed that the HTML WG charter was changed on 2009/02/06?

<Joshue> looks fine to me

<Joshue> The conditional verbiage is good.

<Joshue> I agree with Janina that this can span multiple forms.

<Joshue> 'this is not limited to one use case'

<JR> Change "BECAUSE" at top to "NOTING"?

you've lost your scribe

<greggvanderheiden> General RESOLUTIONS

<greggvanderheiden> NOTING THAT:

<greggvanderheiden> @alt is a very important accessibility attribute (it is supported by all browsers, most authoring tools and is the most well known accessibility technique among authors).

<greggvanderheiden> Having @alt "required" in HTML 4.01 raised public awareness of Web accessibility in general.

<greggvanderheiden> automatic validators can detect the presence/absence of @alt but in general can't certify the correctness of the text string.

<greggvanderheiden> RESOLUTION: We agree HTML5 should provide mechanism(s) for providing short text alternatives.

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

<greggvanderheiden> RESOLUTION: We agree HTML5 should provide mechanisms to allow both short and long text alternatives at the same time.

<greggvanderheiden> RESOLUTION: We recommend continued inclusion of the "alt" attribute as a non-deprecated mechanism to provide short text alternatives.

<greggvanderheiden> RESOLUTION: That HTML5 state that "For guidance on accessibility requirements for text alternatives authors SHOULD consult WCAG 2.0." and that HTML should not provide any guidance that conflicts with WCAG.

<greggvanderheiden> Regarding Short alternatives

<greggvanderheiden> IMG is only valid under any of the following conditions:

<greggvanderheiden> @alt is present (empty or non-empty)

<greggvanderheiden> @labelledby is present (non-empty only)

<greggvanderheiden> @role="presentation"

<greggvanderheiden> the IMG is located within a FIGURE that has a non-empty LEGEND

<greggvanderheiden> NOTE: If (and only if) an image is broken up into pieces that are intended to be perceived as one image the text alternative for the _composite image_ can be for the first image with the other pieces marked as presentational. This does not apply to a series of pictures.

<greggvanderheiden> NOTE: To provide a short descriptor for a collection of images contained in a FIGURE, LEGEND can be used to provide a short description of the varied images. If the LEGEND is used for something other than a short description then @alt or labelledby needs to be specified for each image.

<greggvanderheiden> That the proper use of @role="presentation" be taken from ARIA 1.0 and that an IMG without a @role attribute is assumed to be the equivalent of <IMG @role="image"> (and would follow the rules in #1 above)

<greggvanderheiden> For cases in which it is appropriate for user agents to ignore the presence of the image (e.g., when they are used for decoration, formatting, or are invisible), one or both of the following may be used:

<greggvanderheiden> @role="presentation"

<greggvanderheiden> alt="" (also see (4))

<greggvanderheiden> alt="" WITHOUT an accompanying role="presentation" triggers a non-critical validator warning recommending use of role="presentation" (but @alt="" remains technically valid)

<greggvanderheiden> We suggest new mechanisms for short text alternatives (e.g. labelledby, LEGEND) should be capable of handling structured content. Our primary concern is that short text alternatives be able to support inline text structure, such as abbreviations, language changes, emphasis, etc.

<greggvanderheiden> Regarding text alternatives beyond short text alternatives

<greggvanderheiden> Long text alternatives (e.g. describedby ) (to supplement short text alternatives) are not required for validity (though they may be required by WCAG 2.0 for conformance for some types of non-text content).

<greggvanderheiden> Mechanism(s) for long text alternatives should be capable of handling structured content.

<greggvanderheiden> 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. However it is not necessarily limited to these and could include rich media types.

<greggvanderheiden> Because we assume that aria-describedby will be supported by AT at least as well as longdesc when HTML5 goes to Rec

<greggvanderheiden> IF

<greggvanderheiden> aria-describedby is incorporated in HTML5

<greggvanderheiden> and describedby allows pointing to long text alternatives off of the page (by pointing to a link on the page)

<greggvanderheiden> THEN

<greggvanderheiden> we believe it is acceptable to make longdesc deprecated in HTML5.

<greggvanderheiden> this is what we have in the WIKI at this point and what we are voting on

<greggvanderheiden> THE FINAL VERSION AS VOTED ON

<greggvanderheiden> =================================

<greggvanderheiden> General RESOLUTIONS

<greggvanderheiden> NOTING THAT:

<greggvanderheiden> @alt is a very important accessibility attribute (it is supported by all browsers, most authoring tools and is the most well known accessibility technique among authors).

<greggvanderheiden> Having @alt "required" in HTML 4.01 raised public awareness of Web accessibility in general.

<greggvanderheiden> automatic validators can detect the presence/absence of @alt but in general can't certify the correctness of the text string.

<greggvanderheiden> RESOLUTION: We agree HTML5 should provide mechanism(s) for providing short text alternatives.

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

<greggvanderheiden> RESOLUTION: We agree HTML5 should provide mechanisms to allow both short and long text alternatives at the same time.

<greggvanderheiden> RESOLUTION: We recommend continued inclusion of the "alt" attribute as a non-deprecated mechanism to provide short text alternatives.

<greggvanderheiden> RESOLUTIONS REGARDING Short alternatives

<greggvanderheiden> IMG is only valid under any of the following conditions:

<greggvanderheiden> @alt is present (empty or non-empty)

<greggvanderheiden> @labelledby is present (non-empty only)

<greggvanderheiden> @role="presentation"

<greggvanderheiden> the IMG is located within a FIGURE that has a non-empty LEGEND

<greggvanderheiden> @role="presentation"

<greggvanderheiden> alt="" (also see (4))

<greggvanderheiden> alt="" WITHOUT an accompanying role="presentation" triggers a non-critical validator warning recommending use of role="presentation" (but @alt="" remains technically valid)

<greggvanderheiden> RELATED RECOMMENDATIONS TO WCAG

<greggvanderheiden> NOTE: The following recommendations are being passed on to WCAG working group to be developed into techniques. They are provided here for background and context.

<greggvanderheiden> If (and only if) an image is broken up into pieces that are intended to be perceived as one image the text alternative for the _composite image_ can be for the first image with the other pieces marked as presentational. This does not apply to a series of pictures.

<greggvanderheiden> To provide a short descriptor for a collection of images contained in a FIGURE, LEGEND can be used to provide a short description of the varied images. If the LEGEND is used for something other than a short description then @alt or labelledby needs to be specified for each image.

<greggvanderheiden> RESOLUTIONS REGARDING Long text alternatives (that go beyond short text alternatives)

<greggvanderheiden> Mechanism(s) for long text alternatives should be capable of handling structured content.

<greggvanderheiden> Because we assume that aria-describedby will be supported by AT at least as well as longdesc when HTML5 goes to Rec

<greggvanderheiden> IF

<greggvanderheiden> aria-describedby is incorporated in HTML5

<greggvanderheiden> and describedby allows pointing to long text alternatives off of the page (by pointing to a link on the page)

<greggvanderheiden> THEN

<greggvanderheiden> we believe it is acceptable to make longdesc deprecated in HTML5.

<greggvanderheiden> ==========END================

WAI discussion on HTML alt

06 Mar 2009

Attendees

Contents

Continuing review of proposal http://esw.w3.org/topic/PF/XTech/HTML5/TextAlternativeProposal

Summary of Action Items

Scribe.perl diagnostic output