Special WAI CG meeting on HTML alt -- 04 Mar 2009

<oedipus> "That HTML5 validity REQUIRE a terse text alternatives and that these be provided for non-text items using one of the HTML5 specified methods: (alt, labelledby, or legend)."

<oedipus> previous proposals: http://esw.w3.org/topic/PF/XTech/HTML5/TextAlternativeProposal?action=show#head-2542c1f8a5b7137c012e3852a00f238d12cff58f

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

<oedipus> item 6: "Long text alternatives (to supplement terse text alternatives) are not required for validity (though they may be required by WCAG 2.0 for some types of non-text content)."

<oedipus> GJR: Consider dropping point 6 to avoid conflation of long and terse text alternatives.

<oedipus> JS: can we agree on first 5?

<oedipus> GV: agree on first 5 before discuss item 6 (long descriptor)

JS: suggest we include long text alt in advice to HTML WG, but let's agree on terse first

<oedipus> 1. "That HTML5 validity REQUIRE a terse text alternative and that these be provided for non-text items using one of the HTML5 specified methods: (alt, labelledby, or legend)."

<oedipus> GV: readd "following"

<oedipus> JS: yes

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

<oedipus> For figures; alt attribute, aria-labelledby, or legend can be used.

GV: suggest that for now, HTML5 not worry about accessibility support
... shouldn't prevent something from being valid because there is no suppport today

<oedipus> Ben: is @alt a valid attribute for FIGURE

<oedipus> GJR: IMG is a child of FIGURE

<oedipus> Ben: @alt on FIGURE doesn't make sense -- already stated alt needed

<oedipus> GV: specify that alt be on IMG

<oedipus> Ben: examples of FIGURE with child paragraph and child legend

<oedipus> GV: for Figure, @alt applied to IMG if present

<oedipus> JR: multiple images inside a figure?

<oedipus> JR: one LEGEND sufficient for FIGURE?

<oedipus> GJR: composite images allowed in FIGURE

GV: could have figure with muliple pictures

<oedipus> GV: Figure containing 3 figures; LEGEND "3 Stages of Butterfly Growth", specific alt for each IMG in FIGURE

<oedipus> GV: composite images - ARIA BPG states that DIV marked as role="image" can contain composite images, with the alt text for the composite attached to the first IMG declaration and the rest of the composite IMG use alt=""

GL: was going to mention alt attribute on figure issue. WCAG 2.0 includes 5 star rating system where one image has alt and the others have alt="". A more appropriate way to do this woul dhave been to have use something like figure

<oedipus> ack oe\

<Zakim> oedipus, you wanted to say don't want to lose tying together of LEGEND and @alt (content should be same, save LEGEND can take markup ("rich text")

GJR: in GV's example would have three alternatives for 3 images

<oedipus> pointer, please?

<oedipus> yes, i was referring to COMPOSITE images only

SF: mentions one of the HTML5 examples having to do with castles. Where would legend fit in for this? (when each image has an alternative and a legend acts like a group label)

<Stevef> http://www.w3.org/TR/html5/embedded-content-0.html#the-figure-element

GV: correct that when you have an image with different pieces glued together, then you'd have an alt on one and hide the others (using alt=""). In this example where we have 3 butterflies in a figure, it would appear that the best thing to do would be that if the legend is "3 stages of butterfly growth," that's not very useful. Alt text out to say something about each stage (where each image depicts a stage)...

<oedipus> in case of multiple IMGs, LEGEND = meta-data for images as a whole, @alt or labelledby used to attach specific textual alternative to each individual image since they are designed to be perceived not as a single image, but a series of images

<Gez> Code I used was: 92424

<oedipus> implicit role for IMG in absence of declaration is role="image" which requires @alt or labelledby

GV: need to think about a couple things. Are these the only places where we require text alternatives? Other thing is that we need to look at both forward and backward compatability. Final point is that when we have things like FIGURE with an image inside, are we going to expect that users in AT will understand that when they hit an image and they they are marked presentation, will they understand that a legend or labeled by is coming later?

JR: Concerned that FIGURE is a rat hole. Putting role="presentation" on an image just to hide it seems like a hack.

<oedipus> implicit role for IMG in absence of declaration is role="image" which requires @alt or labelledby

GV: agree with GJR, presentation or alt="" should be put on a meaningful image only if there is an image that is one image but it has been sliced up for specific reasons. If a series of images, then each should have it's own alt. If a compound image, it is meant to be perceived as a single image (same for sliced images). But, anytime you have a series of images which appears to be a series of images to the user, it should have a series of alts.

<oedipus> IMG alt="Five Stars" not IMG="star" IMG="star" IMG="star" IMG="star" IMG="star"

GV: need to say "non-text items that are not presentational" in #1

JS: may do some cleanup later, more concerned that we agree on markup, can tweak later

<oedipus> the 3 butterfly scenario would NOT be a composite image

JS: need to think of various types of alt for various types of media. Might want to focus on a specific image within a figure element. If just legend, it might be harder to get to.

GJR: 3 butterflies is not composite, it's a series of images in a group
... composite is "all of the images combined to form a complete image"

SF: regarding figure, why not just say, "for images containing figures" ?

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

<oedipus> For an IMG which is a child of a FIGURE, alt attribute (on a child image), aria-labelledby, or legend can be used.

<oedipus> "For figures; alt attribute (on a child image), aria-labelledby, or legend can be used"

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

<oedipus> suggest "are intended to be perceived as a single image"

GJR: suggest "intended to be perceived as a single image"

<Stevef> For an IMG which is a child of a FIGURE, alt attribute, aria-labelledby, or legend can be used.

SF: suggest, "For an IMG which is a child of a FIGURE, alt attribute, aria-labelledby, or legend can be used."

GV: what's UA/AT behavior for figure/legend?

GJR: understanding is that it behaves like caption on table, not necessarily an equivalent, but more like a lable

<oedipus> GJR: sees LEGEND as a CAPTION (for table) or Heading for image; alt text often different than caption

LGR: if alt, AT would probably just use that, probably wouldn't go looking for LEGEND

<oedipus> For an image that is a child of a figure, the alt attribute and/or the aria-labelledby can be used. 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, and @alt or labelledby needs to be specified for each image. Note: this does not applly if the multiple IMG declarations are part of a _composite image_.

<oedipus> "_composite image_" indicates a defined term, as agreed to earlier

<Stevef> change "non-text items" to "images"

<oedipus> GJR: sees LEGEND for FIGURE as a CAPTION (for TABLE) or a heading for image; alt text often different than caption

<oedipus> http://esw.w3.org/topic/PF/XTech/HTML5/MediaSpecificElements

<oedipus> the wiki page cited above covers all media-specific elements in a consistent manner

SF: in first sentence of #1, it says non-text items, we also talke about images, but also video, etc. Suggest we get rid of non-text items and just say images

GJR: tried to build consistent model for all media-specific elements (canvas, figure, video, audio) - so that there is possibility for rich content, content negotiation, etc.

<Joshue> It would be best to stay within the domain of images and not move into rich media, would that confuse matters to do so? probably

<oedipus> http://esw.w3.org/topic/PF/XTech/HTML5/MediaSpecificElements

JS: should look to see if we can generalize this to various kinds of media
... think Jan's idea to look more closely at FIGURE is a good one, should we add other examples in #1?

<oedipus> agree strongly with SteveF -- let's answer the question we were asked

<JR> +1

<Gez> +1

SF: don't feel good about getting into these other things - started out talking about alt attribute on images. if we start talking about other exmaples, will become more problematic. not saying we shouldn't look at them, just that we separate them out

<Laura> +1 to Steve

<Joshue> +1

<oedipus> generic media-specific element model:

<oedipus> <LEGEND></LEGEND> - required

<oedipus> <CAPTION></CAPTION> - required

<oedipus> <DESC></DESC> - required (maps to HTML4's @longdesc)

<oedipus> in above, legend maps to @alt and CAPTION does what its name suggests

GV: proposes second note. have we captured everyone's major ideas?

2.) That HTML5 state that "For guidance on accessibility requirements for text alternatives authors SHOULD consult WCAG 2.0."

<Joshue> +1 to that

<Gez> +1

<Laura> +1

<oedipus> alt text not just for accessibility - minus 1

JS: do we agree that accessibility advice should not be scattered outside of WAI documents?

GV: also frees editors up to make comments about usage outside of accessibility

JS: think we should add something about working with them to provide appropriate pointers

GV: can be dangerous

MC: good to provide meta note to say that we are explicity intending to free them up to include advice about use cases that are not accessibility related

JS: can wordsmith further at a later date

<oedipus> plus 1 to move on

<Joshue> I think advice can be found outside of WAI docs but that advice should support WCAG and the languages and specifications themselves should natively enable compliance with WCAG

<oedipus> good point, Josh

JS: clear enough to move on?

3.) That the proper use of role="presentation" be taken from ARIA 1.0.

group agrees

4.) The following points regarding alt="" validity are under discussion. EITHER: (5 options)

<oedipus> A. That alt="" is valid ONLY when role="presentation".

<oedipus> B. That alt="" is valid ONLY when role="presentation". An IMG without a role attribute is the equivalent of <IMG aria-role="image"> and REQUIRES the use of alt, labelledby, and/or LEGEND for validity. For guidance as to what constitutes a valid text alternative for the purpose of disability access consult WCAG

<oedipus> C. That alt="" WITHOUT an accompanying role="presentation" MUST trigger a non-critical validity warning (but is still valid)

<oedipus> D. That alt="" is valid ONLY when role="presentation" (or role="presentation" would be appropriate if role is not used). alt="" with any role besides "presentation" MUST trigger a validity error.

<Gez> +1 to option C

<Joshue> For C, what does still valid mean?

GV: comes back to whether we require ARIA

<Joshue> Still considered conforming to HTML 5?

JS: I have an action to formally ask HTML5 chair whether it is their intention to include ARIA (part or all) into HTML5

<oedipus> http://www.w3.org/WAI/PF/Group/track/actions/391

<Joshue> As role="presentation" is an ARIA construct, then its use etc should be defined in ARIA

<oedipus> http://www.w3.org/2009/03/04-pf-minutes.html#action01

GV: let's assume ARIA will be included, if not, then we have to revisit whole discussion
... if included, it will be things that the author can use, not that they must use, correct?

JR: other possibility is that you should use ARIA, if not, you get the warning

GJR: reason B was so long was that I tried to capture concept of img without role attribute is equivalent of role="img" and needs alt or labelledby

<oedipus> GJR: A is open to abuse, as Jan noted

GV: concern was with D, which says if you use alt="" then you must use ARIA

JR: D already weakens itself because of the OR

<oedipus> GJR: plus 1 to cleaner version of B

SF: an image without an alt attribute and role="presentation" would be acceptable?

<oedipus> B. alt="" is valid ONLY when an IMG's role="presentation". An IMG without a role attribute is the equivalent of <IMG aria-role="image"> and REQUIRES the use of alt, labelledby, and/or LEGEND for validity. For guidance as to what constitutes a valid text alternative for the purpose of disability access consult WCAG 2.0.

SF: if we're asking for role="presentation" , also asking for alt="" seems redundant

JR: is it worth doing a straw poll on that?

GJR: Think we have to keep alt because of backward compatibility.

GV: think we should, not sure we must
... for WCAG, you would need it until AT supports it

<Joshue> I also like the B option but I have a question. An image can be presentational, without having the role="presentation", the wording will have to be a little different as it could be confusing.

<Joshue> To authors I mean btw.

<oedipus> josh, it does need wordsmithing

SF: also need to look at behavior of AT with regards to content without any alt attibute (currently mostly ignored except when in a link)

JS: think we can expect fairly quick uptake of ARIA in AT

<oedipus> GJR: depends upon user's verbosity settings

<Joshue> SF, the absence of the alt attribute will trigger heuristic evaluation/repair

GV: Agree, in high end AT, hopefully more broadly available by other through other efforts - hope we have good ARIA support before HTML5 goes out

<oedipus> marco zehe

SF: I think AT support so far is pretty good.

GJR: problem is that things like NVDA for a developer is "what is it's market share?"

MM: In my experience, it is not very accurate that developers are asking about market share. More of a priority to have an open source product that can be manipulated to address accessibilty issues than it is to have fixes included in closed source AT

JS: should talk about next meeting
... either this friday or the following friday

<oedipus> GJR: NVDA is open to idea of hardware synthesizer drivers provided they don't have to do the programming -- i am trying to coordinate a google-group or sourceforge project to provide hardware synth drivers

MM: can I recommend that we attempt to finalize something (SXSW and CSUN coming up and need to respond in a timely fashion)

JS: agree. objection to meeting Friday at 10 Eastern

<oedipus> consult http://esw.w3.org/topic/PF/XTech/HTML5/Caucus

<oedipus> EST is UTC minus 5 until 2 am sunday when U.S.A. changes to daylight savintgs

RESOLUTION: meet at noon Eastern Friday 6 March

<Laura> Why was the word MUST changed to SHOULD on "That alt="" WITHOUT an accompanying role="presentation" should trigger a non-critical warning recommending use of role="presentation" (but is still valid)." ?

<oedipus> 3. That the proper use of role="presentation" be taken from ARIA 1.0.

<oedipus> 4. That the proper use of role="presentation" be taken from ARIA 1.0.

<oedipus> 5. An IMG without a role attribute is the equivalent of <IMG aria-role="image"> and REQUIRES the use of alt, labelledby, and/or LEGEND for validity.

<oedipus> 6. for content where role="presentation" is appropriate either alt="" or role="presentation" or both can be used.

<oedipus> 6A) That alt="" WITHOUT an accompanying role="presentation" should trigger a non-critical warning recommending use of role="presentation" (but is still valid).

<oedipus> GreggV is literally keeping us on the same page

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

<Laura> bye

<oedipus> michael, are you going to push the minutes?

Special WAI CG meeting on HTML alt

04 Mar 2009

Attendees

Contents

WAI-CG on Alt: Continuing Discussion On "Alt=Needed"; GJR's Type=/Role=; Others?

2.) That HTML5 state that "For guidance on accessibility requirements for text alternatives authors SHOULD consult WCAG 2.0."

3.) That the proper use of role="presentation" be taken from ARIA 1.0.

4.) The following points regarding alt="" validity are under discussion. EITHER: (5 options)

Summary of Action Items

Scribe.perl diagnostic output