17:03:01 RRSAgent has joined #cg 17:03:01 logging to http://www.w3.org/2009/03/06-cg-irc 17:03:08 +Cooper 17:03:20 rrsagent, make log world 17:03:35 meeting: WAI discussion on HTML alt 17:03:40 chair: Janina Sajka 17:03:56 +??P0 17:04:42 greggvanderheiden has joined #cg 17:05:27 +Matt 17:06:19 zakim, who is on the phone? 17:06:19 On the phone I see Janina, Gregory_Rosmaita, JR, [IPcaller], Cooper, ??P0, Matt 17:06:21 Loretta has joined #cg 17:06:43 josh, we are trying to find someone else on skype who can bridge you in 17:06:46 +Laura_Carlson 17:07:00 Thanks GJR 17:07:08 who is on the phone 17:07:17 josh I can try and conf you in on Skype...what's your Skype name? 17:07:24 zakim, who is on the phone? 17:07:24 On the phone I see Janina, Gregory_Rosmaita, JR, [IPcaller], Cooper, ??P0, Matt, Laura_Carlson 17:07:29 regrets: Steve_Faulkner 17:07:54 Its joshueoconnor Jan 17:07:56 q? 17:08:09 +Loretta_Guarino_Reid 17:08:23 zakim, ??P0 is greggvnaderheiden 17:08:24 I already had ??P0 as Gregg_Vanderheiden, oedipus 17:09:47 scribe: MichaelC 17:10:16 zakim, IPcaller is Jan 17:10:16 +Jan; got it 17:10:21 zakim, Joshue is with Jan 17:10:21 +Joshue; got it 17:11:27 example of FIGURE, LEGEND and alt in: http://lists.w3.org/Archives/Public/www-archive/2009Mar/0024.html 17:11:41
17:11:41 The Three Stages of a Butterfly's Life Cycle 17:11:41 Stage 1: The larval stage. longdesc="butterfly1.html"> 17:11:41 Stage 2: The pupal stage. longdesc="butterfly2.html"> 17:11:43 Stage 3: The adult stage. longdesc="butterfly3.html"> 17:11:46 http://esw.w3.org/topic/PF/XTech/HTML5/TextAlternativeProposal 17:11:47
17:11:57 topic: Continuing review of proposal http://esw.w3.org/topic/PF/XTech/HTML5/TextAlternativeProposal 17:13:31 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). 17:13:34 17:13:50 gjr may object 17:13:57 q+ 17:14:07 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]" 17:14:46 not sure we actually want to go this far 17:14:55 scribeOptions: -final -implicitContinuations 17:15:07 +Cynthia_Shelly 17:15:17 perhaps add "... for people with disabilities..." 17:15:30 q? 17:15:34 GJR: still wants "MUST" not "would" 17:15:35 q- ? 17:15:37 ack j 17:16:03 # That HTML5 make it clear that for guidance on the accessibility requirements for text alternatives, authors should consult WCAG 2.0. 17:16:05 # That any HTML5 guidance on providing text alternatives must not contradict WCAG 2.0. 17:16:19 laura suggested: "That any examples in HTML5 are to be non-normative coordinated with WAI PF WG." 17:16:26 jr: propose above 17:16:29 q+ 17:16:51 q? 17:16:58 should cover it without going too far 17:17:00 ack g 17:17:01 +1 to jan 17:17:02 +1 to Jans verbiage 17:17:25 plus three-quarters to Jan 17:17:37 I find the text "That any examples in HTML5 are to be non-normative coordinated with WAI PF WG." a little difficult to parse. 17:17:38 gv: worried about consequences of going too far in what we ask HTML to say 17:17:56 q+ 17:17:57 q+ the batch uploading of photos is a canard 17:18:11 +1 to GJR 17:18:13 q? 17:18:25 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 17:18:27 q+ to say the batch uploading of photos is a canard - if the tool allows the author to add alt text after the upload 17:18:34 we might end up in a similar situation 17:18:51 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. 17:18:57 zakim, mute me 17:18:57 sorry, Joshue, I do not know which phone connection belongs to you 17:19:00 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 17:19:26 q? 17:19:53 jr: so we agree guidance on accessibility requirements should satisfy WCAG 2.0 17:20:08 ack gez 17:20:18 we're saying HTML could provide advice that contradicts WCAG? 17:20:19 q? 17:20:36 ack oe\ 17:20:39 ack oe 17:20:39 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 17:20:50 I agree with Gez. 17:21:03 gl: don't see problem with considering things that aren't usable non-compliant; they can be non-compliant if author wants 17:21:29 gr: the whole batch upload issue is a canard 17:21:29 GJR: not compliant until add @alt -- that's life 17:21:43 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. 17:21:56 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 17:21:56 strong plus 1 to Joshue 17:22:10 why not let that small # of pages not be valid? 17:22:25 q? 17:22:33 GJR: straw poll - who enjoys looking at hundreds of pictures of anyone's vacation 17:23:15 gr: pages with lots of photos are generally uninteresting anyway 17:23:29 don't think the use case needs to hamstring us 17:23:34 it's an authoring tool and platform problem 17:23:50 those tools can insert placeholder alt to be valid 17:24:02 the issue distracts us 17:24:07 ack c 17:24:25 cs: consider if developer of photo site wants to validate 17:24:26 good point cynthia 17:24:37 do they care if user pages validate, or just their authored content? 17:24:52 q+ 17:24:55 gv: which is the WCAG Partial Conformance scenario 17:25:24 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 17:25:33 fickr being 100% accessible and valid is as infeasible as youTube being 100% valid and accessible 17:25:44 q? 17:25:50 q+ 17:26:06 they want to play with statistics -- we are dealing with individuals and individual needs 17:26:40 statistical arguments reveal more about authoring tool limitations than anything else 17:26:54 q+ 17:27:00 ack lor 17:27:18 gv: HTML is defining page level conformance, and validation 17:27:24 q? 17:27:25 he should follow ATAG!!! 17:27:29 cs: isn't validation a developer benefit? 17:28:03 lgr: 17:28:19 gr: need to provide feature to add alt 17:28:37 lgr: so in situation where allowed to add alt but doesn't, what happens? 17:28:45 One of the issues was about whether that tool should offer some kind of repair, right? 17:28:49 gr: so the page is invalid 17:29:05 lgr: that is user's fault, but the authorin tool might get blamed 17:29:22 gr: 17:29:33 Henri 's tool would conform. The author 's content wouldn't. 17:29:55 Good point Laura. 17:29:58 GJR: can't control usage of tools 17:30:12 gv: what happens when tools asks for something else required, and user doesn't comply? 17:30:17 cs: e.g., valid src 17:30:26 good point laura 17:30:42 2 part compliance: accessibility of tool and the potential to produce accessible output 17:30:53 -Jan 17:31:00 lgr: AU that outputs content that doesn't conform to WCAG, is the tool failing to comply to ATAG? 17:31:14 no 17:31:19 +[IPcaller] 17:31:23 q? 17:31:51 JS: if you have a car accident the car's manufacturer isn't responsible for individual auto accidents 17:32:02 ack Gez 17:32:20 gl: HTML is focused on conformance 17:32:26 accessibility feels like a push-back to them 17:32:33 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. 17:33:03 POV that authoring tool can never emit incorrect output for any reason 17:33:11 q? 17:33:18 ack Gez_L 17:33:31 17:33:41 An author can provide an address with the address element that isn't a contact address , which would not be considered compliant. 17:33:50 The author obviously has a responsibility in using an authoring tool. 17:33:58 that's not a correct expectation, because of user factors 17:34:30 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 17:34:41 q? 17:34:42 must not be tied to accessibility alone -- there are other valid use cases for @alt 17:34:47 ack g 17:35:03 in second case, the advice might be useful, just not for WCAG 17:35:29 what is the straw poll question? 17:35:30 ok with either approach, we need to pick one 17:36:39 cs: omitting alt could be like omitting src; tool can error or warn as it sees fit 17:36:51 plus 1 to line in the sand 17:36:54 +1 17:36:57 +1 17:37:04 +1 17:37:17 js: Straw Poll - Accessibility Guidance comes from WCAG, and HTML should not provide any guidance that conflicts with WCAG 17:37:21 plus 1 to line in the sand 17:37:22 +1 17:37:24 +1 17:37:37 +1 17:37:37 +1 17:37:39 +1 17:37:43 +1 Cytnhia 17:37:50 +0 17:38:04 +1 can live with this one but prefer other 17:38:31 +1 can live with it 17:38:44 zakim, who is here? 17:38:44 On the phone I see Janina, Gregory_Rosmaita, JR, Cooper, Gregg_Vanderheiden, Matt, Laura_Carlson, Loretta_Guarino_Reid, Cynthia_Shelly, Gez_Lemon 17:38:46 On IRC I see Loretta, greggvanderheiden, RRSAgent, Gez, Joshue, JR, janina, Laura, Zakim, MichaelC, oedipus, trackbot 17:39:13 mat: +/- 0 17:39:55 MC: can live with, but prefer other option 17:39:57 +0 17:40:16 +1 support; +0 can live with it; -1 to NO! 17:40:45 s/-1 to NO!/-1 equals NO! 17:41:12 <8 plus, 3 live, 0 no> 17:42:47 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. 17:42:55 -1 17:43:04 +1 17:43:06 -1 17:43:07 -1 17:43:10 I find the second part difficult to parse 17:43:11 strong minus 1 17:43:11 +o 17:43:33 +0 17:43:39 +0 17:43:50 -1 since more interpretation required 17:43:57 -1 17:44:50 <1 support, 4 can live, 6 oppose> 17:44:56 I am all for advise conforming to WCAG 2.0 as that should be the 'standard'. What are we really trying to say here? 17:45:39 s/advise/advice 17:46:02 consensus of this group supports the first proposal 17:46:18 17:47:08 as long as the SHOULD is an RFC2119 SHOULD, which is quite strong (do it, or explain why not) 17:48:47 +1 to GJR 17:48:52 +q 17:49:07 god = tbl 17:49:19 mc: appreciate that this would be the consensus of this group but worried HTML WG will reject and protract discussion 17:49:24 God may have something to say about that :-) 17:49:29 gr: we need to elevate the issue then 17:49:43 +[Microsoft] 17:49:47 -Cynthia_Shelly 17:50:02 we should arbitrate accessibility 17:50:12 gv: but they'll feel we're trying to arbitrate validity 17:50:24 js: this gets down to why W3C has different domains of expertise 17:51:39 ---next proposal in wiki--- 17:51:47 gv: "terse" vs. "short" 17:51:52 17:51:53 HTML5 charter was changed on "2009/02/06" 17:52:18 gv: legend, is it new? 17:52:26 gr: borrowed from fieldset 17:52:34 -q 17:52:44
17:52:44 The Three Stages of a Butterfly's Life Cycle 17:52:44 Stage 1: The larval stage. 17:52:44 Stage 2: The pupal stage. 17:52:44 Stage 3: The adult stage. 17:52:45
17:52:49 q? 17:53:24 http://www.w3.org/TR/html5/interactive-elements.html#the-legend-element 17:53:54 Content model: 17:53:54 * Either: one legend element followed by flow content. 17:53:54 * Or: Flow content followed by one legend element. 17:53:54 * Or: Flow content. 17:54:06 content model for FIGURE 17:55:11 ack c 17:55:20 http://www.w3.org/TR/html5/interactive-elements.html#the-legend-element 17:55:30 q? 17:55:51 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. ]" 17:56:10 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." 17:56:33 q+ 17:57:11 ack oe 17:57:27 \me have to leave now. bye! 17:57:33 http://www.w3.org/TR/html5/interactive-elements.html#the-legend-element 17:57:37 -Loretta_Guarino_Reid 17:59:32 sample code for FIGURE, LEGEND, IMG and @alt: http://esw.w3.org/topic/PF/XTech/HTML5/TextAlternativeProposal?action=show#head-af43e90d8443e4c9354cc3d3c867df1bcd6a3254 17:59:53 THis can go: 17:59:57 re: HTML5 guidance around text alternatives for accessibility: 17:59:59 1. That HTML5 make it clear that for guidance on the accessibility requirements for text alternatives, authors should consult WCAG 2.0. 18:00:00 2. That any HTML5 guidance on providing text alternatives must not contradict WCAG 2.0. 18:00:09 This should stay: 18:00:18 re: the structure of @alt for IMG: 18:00:20 Assuming that HTML5 will be fully adopting ARIA... 18:00:22 1. IMG is only valid under any of the following conditions: 18:00:23 * @alt is present (empty or non-empty) 18:00:25 * @labelledby is present (non-empty only) 18:00:27 * @role="presentation" 18:00:29 * the IMG is located within a FIGURE that has a non-empty LEGEND 18:00:30 2. 18:00:32 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 18:00:32 GJR: as long as the SHOULD and MUST are RFC2119 terms 18:00:33 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: 18:00:35 * @role="presentation" 18:00:37 * alt="" (also see (4)) 18:00:39 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) 18:04:08 +1 to Janina 18:04:18 It spans many issues.. 18:04:51 IMG is only valid under any of the following conditions: 18:04:53 * @alt is present (empty or non-empty) 18:04:55 * @labelledby is present (non-empty only) 18:04:57 * @role="presentation" 18:04:59 * the IMG is located within a FIGURE that has a non-empty LEGEND 18:05:28 sample code for FIGURE, LEGEND, IMG and @alt: http://esw.w3.org/topic/PF/XTech/HTML5/TextAlternativeProposal?action=show#head-af43e90d8443e4c9354cc3d3c867df1bcd6a3254 18:06:12
18:06:12 The Three Stages of a Butterfly's Life Cycle 18:06:12 Stage 1: The larval stage. longdesc="butterfly1.html"> 18:06:12 Stage 2: The pupal stage. longdesc="butterfly2.html"> 18:06:15 Stage 3: The adult stage. longdesc="butterfly3.html"> 18:06:19
18:06:30 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 18:06:40 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 18:06:40 a) each individual image's terse alternative text; 18:06:40 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; 18:06:58 q? 18:07:04 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. 18:07:04 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. 18:10:54 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. 18:10:54 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. 18:10:58 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. 18:10:58 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. 18:11:58 Should the mechanism be designed to handle both (sic) use cases? 18:12:02 q? 18:12:36 q? 18:14:09 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 18:14:11 q? 18:14:19 GV: not validity error, but a warning 18:14:39 GV: does HTML5 spec state what validity errors and warnings are? 18:15:15 Good question, I am not sure if it specifies what the warning should beyond some generic flag, is that correct? 18:15:28 q+ 18:15:30 GV: put IMGs inside of figure without alt on individual images using only LEGEND - should ask "does this fully describe this collection?" 18:15:43 s/beyond/be beyond 18:15:56 CS: if rare, ok, if occurs each time, will be ignored 18:16:15 Lets make alt mandatory! 18:16:22 http://esw.w3.org/topic/PF/XTech/HTML5/TextAlternativeProposal?action=show#head-af43e90d8443e4c9354cc3d3c867df1bcd6a3254 18:16:36 what a novel idea, josh! 18:17:07 q+ to say understand's JR's urge to seperate IMG from FIGURE advice 18:17:13 ack [Micro 18:17:35 JS: add WCAG URIs to proposals? 18:17:46 GV: doesn't change number 1 being correct 18:18:46 OLD: 18:18:48 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). 18:18:48 * For example 18:18:48 o 18:18:48 For images; alt attribute or aria-labelledby can be used. 18:18:48 o 18:18:50 For an image that is a child of a figure; alt attribute, aria-labelledby, or legend can be used (would be valid). 18:18:53 o (this would apply to other non-text content as well) 18:18:57 NEW: 18:19:13 Assuming that HTML5 will be fully adopting ARIA... 18:19:13 1. IMG is only valid under any of the following conditions: 18:19:13 * @alt is present (empty or non-empty) 18:19:13 * @labelledby is present (non-empty only) 18:19:13 * @role="presentation" 18:19:14 * the IMG is located within a FIGURE that has a non-empty LEGEND 18:20:39 plus 1 to replacing 18:20:54 "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 " 18:22:04 "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: 18:22:04 * @role="presentation" 18:22:04 * alt="" (also see (4))" 18:23:10 "new" number 4: 18:23:12 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) 18:23:30 plus one if change "would" to "will" 18:24:48 "will" would be a good word to use. 18:26:09 would is rather non-comittal. 18:26:33 +1 18:26:50 remove the 'would' bit, I guess. 18:27:38 alt="" WITHOUT an accompanying role="presentation" triggers a non-critical validator warning recommending use of role="presentation" (but @alt="" remains technically valid) 18:27:48 how about 'triggers'? 18:27:53 plus 1 to "triggers" 18:29:21 GJR & JOC: propose removing "would" and changing tense to triggers 18:29:31 GV: edit made 18:29:32 good stuff :-) 18:29:49 -Gez_Lemon 18:32:11 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; 18:32:22 I have to leave too. Bye. 18:32:56 -Laura_Carlson 18:34:00 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). " 18:34:12 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" 18:34:45 q+ still think we should first give advice on terse alternatives and handle long descriptions for another communique with the HTML WG 18:34:54 q+ to say that i still think we should first give advice on terse alternatives and handle long descriptions for another communique with the HTML WG 18:35:01 axk JR 18:35:04 ack JR 18:35:14 s/for another/in another 18:35:28 GJR: deprecate not obsolete 18:35:30 I would remove the part 'at least as well as longdesc ' 18:36:32 q? 18:36:50 ack oe 18:36:50 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 18:36:54 ... descriptions for another communique with the HTML WG 18:38:16 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. 18:38:42 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' 18:39:57 but GJR a lot of what we are suggesting is based on the assumption of ARIA integration? 18:40:10 Yes, if would be good.. 18:40:14 q+ 18:40:32 I wouldn't use the word assume... 18:40:41 Possible text: "Assuming that HTML5 will be fully adopting ARIA" 18:41:05 How about... 'If aria-describedby will be supported by AT when HTML5 goes to Rec, it is acceptable to make longdesc obsolete in HTML5' 18:41:18 JS: response from ChrisWilson to request to incorporate ARIA 18:41:59 Did ARIA not drop name spaces? 18:42:20 JS: very friendly message from CW 18:42:27 GV: what do we answer them? 18:42:30 q? 18:42:34 ack JR 18:43:02 AT is doing ARIA. 18:43:15 CS: browsers are doing it, but without namespacing... 18:43:31 JR: describedby as an attribute of HTML5 rather than point off to namespace 18:43:42 CS: agree theoretically, but all uas doing it anyway 18:43:48 rrsagent, make minutes 18:43:48 I have made the request to generate http://www.w3.org/2009/03/06-cg-minutes.html oedipus 18:44:01 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. 18:44:14 rrsagent, make logs world-visible 18:44:19 rrsagent, make minutes 18:44:19 I have made the request to generate http://www.w3.org/2009/03/06-cg-minutes.html oedipus 18:44:27 I will be very surprised if ARIA gets the upper hand.. 18:45:03 i/GV: leave JR's/ScribeNick: oedipus 18:45:08 rrsagent, make minutes 18:45:08 I have made the request to generate http://www.w3.org/2009/03/06-cg-minutes.html oedipus 18:45:32 me HTML 6 lol 18:45:34 CS: prefer namespace extension mechanism, but would like 1.0 incorporated into HTML5 18:45:53 in the year 2525 ;-) 18:45:54 CS: what happens with HTML6 - if ARIA changes, do aria properties change? 18:46:16 MM: already a wish list for ARIA 2.0 18:46:31 CS: wouldn't be surprised if ARIA 2.0 beats HTML5 to Rec 18:46:47 MM: not the place to answer that question?\ 18:47:00 JS: will be topic of discussion before next wednesday 18:47:08 GV: please refresh the wiki page 18:47:56 q+ to ask if anyone else noticed that the HTML WG charter was changed on 2009/02/06? 18:49:23 ack me 18:49:23 oedipus, you wanted to ask if anyone else noticed that the HTML WG charter was changed on 2009/02/06? 18:50:06 -Gregory_Rosmaita 18:52:03 looks fine to me 18:52:32 The conditional verbiage is good. 18:53:10 I agree with Janina that this can span multiple forms. 18:53:30 'this is not limited to one use case' 18:54:03 Joshue has left #cg 18:54:29 Change "BECAUSE" at top to "NOTING"? 18:57:42 you've lost your scribe 19:03:52 General RESOLUTIONS 19:03:52 NOTING THAT: 19:03:52 @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). 19:03:53 Having @alt "required" in HTML 4.01 raised public awareness of Web accessibility in general. 19:03:53 automatic validators can detect the presence/absence of @alt but in general can't certify the correctness of the text string. 19:03:54 RESOLUTION: We agree HTML5 should provide mechanism(s) for providing short text alternatives. 19:03:56 RESOLUTION: We agree HTML5 should provide mechanism(s) for providing long text alternatives. 19:03:58 RESOLUTION: We agree HTML5 should provide mechanisms to allow both short and long text alternatives at the same time. 19:04:01 RESOLUTION: We recommend continued inclusion of the "alt" attribute as a non-deprecated mechanism to provide short text alternatives. 19:04:04 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. 19:04:07 Regarding Short alternatives 19:04:09 IMG is only valid under any of the following conditions: 19:04:11 @alt is present (empty or non-empty) 19:04:13 @labelledby is present (non-empty only) 19:04:15 @role="presentation" 19:04:17 the IMG is located within a FIGURE that has a non-empty LEGEND 19:04:19 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. 19:04:23 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. 19:04:27 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 (and would follow the rules in #1 above) 19:04:30 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: 19:04:33 @role="presentation" 19:04:35 alt="" (also see (4)) 19:04:37 alt="" WITHOUT an accompanying role="presentation" triggers a non-critical validator warning recommending use of role="presentation" (but @alt="" remains technically valid) 19:04:40 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. 19:04:44 Regarding text alternatives beyond short text alternatives 19:04:46 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). 19:04:49 Mechanism(s) for long text alternatives should be capable of handling structured content. 19:04:51 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. 19:04:55 Because we assume that aria-describedby will be supported by AT at least as well as longdesc when HTML5 goes to Rec 19:04:58 IF 19:05:00 aria-describedby is incorporated in HTML5 19:05:02 and describedby allows pointing to long text alternatives off of the page (by pointing to a link on the page) 19:05:04 THEN 19:05:06 we believe it is acceptable to make longdesc deprecated in HTML5. 19:05:08 this is what we have in the WIKI at this point and what we are voting on 19:13:25 THE FINAL VERSION AS VOTED ON 19:13:42 ================================= 19:13:45 General RESOLUTIONS 19:13:45 NOTING THAT: 19:13:46 @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). 19:13:46 Having @alt "required" in HTML 4.01 raised public awareness of Web accessibility in general. 19:13:46 automatic validators can detect the presence/absence of @alt but in general can't certify the correctness of the text string. 19:13:48 RESOLUTION: We agree HTML5 should provide mechanism(s) for providing short text alternatives. 19:13:50 RESOLUTION: We agree HTML5 should provide mechanism(s) for providing long text alternatives. 19:13:52 RESOLUTION: We agree HTML5 should provide mechanisms to allow both short and long text alternatives at the same time. 19:13:55 RESOLUTION: We recommend continued inclusion of the "alt" attribute as a non-deprecated mechanism to provide short text alternatives. 19:13:58 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. 19:14:01 RESOLUTIONS REGARDING Short alternatives 19:14:03 IMG is only valid under any of the following conditions: 19:14:05 @alt is present (empty or non-empty) 19:14:07 @labelledby is present (non-empty only) 19:14:09 @role="presentation" 19:14:11 the IMG is located within a FIGURE that has a non-empty LEGEND 19:14:13 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 (and would follow the rules in #1 above) 19:14:16 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: 19:14:19 @role="presentation" 19:14:21 alt="" (also see (4)) 19:14:23 alt="" WITHOUT an accompanying role="presentation" triggers a non-critical validator warning recommending use of role="presentation" (but @alt="" remains technically valid) 19:14:26 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. 19:14:30 RELATED RECOMMENDATIONS TO WCAG 19:14:32 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. 19:14:35 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. 19:14:39 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. 19:14:43 RESOLUTIONS REGARDING Long text alternatives (that go beyond short text alternatives) 19:14:45 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). 19:14:48 Mechanism(s) for long text alternatives should be capable of handling structured content. 19:14:50 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. 19:14:54 Because we assume that aria-describedby will be supported by AT at least as well as longdesc when HTML5 goes to Rec 19:14:57 IF 19:14:59 aria-describedby is incorporated in HTML5 19:15:01 and describedby allows pointing to long text alternatives off of the page (by pointing to a link on the page) 19:15:03 THEN 19:15:05 we believe it is acceptable to make longdesc deprecated in HTML5. 19:15:07 ==========END================ 19:15:19 -[Microsoft] 19:15:22 -JR 19:15:24 -Matt 19:15:26 -Cooper 19:15:26 -Gregg_Vanderheiden 19:15:27 -Janina 19:15:28 Team_(pf)17:00Z has ended 19:15:30 Attendees were Janina, Gregory_Rosmaita, JR, Cooper, Matt, Laura_Carlson, Loretta_Guarino_Reid, Gregg_Vanderheiden, Jan, Joshue, Cynthia_Shelly, Gez_Lemon, [Microsoft] 19:17:39 rrsagent, make minutes 19:17:39 I have made the request to generate http://www.w3.org/2009/03/06-cg-minutes.html MichaelC 19:17:48 greggvanderheiden has left #cg 19:35:22 zakim, bye 19:35:22 Zakim has left #cg 19:35:24 rrsagent, bye 19:35:24 I see no action items