From Philip-and-LeKhanh at Royal-Tunbridge-Wells.Org Tue Apr 1 00:11:25 2008 From: Philip-and-LeKhanh at Royal-Tunbridge-Wells.Org (Philip TAYLOR) Date: Tue, 01 Apr 2008 08:11:25 +0100 Subject: [html4all] Another choice snippet from Ian Hickson, in re MathML Message-ID: <47F1E01D.6060405@Royal-Tunbridge-Wells.Org> > On the contrary, experience with the Web has shown that including > redundant data (e.g. accessibility metadata, page description metadata, > and so forth) is actively harmful, ... From foliot at wats.ca Tue Apr 1 12:22:02 2008 From: foliot at wats.ca (John Foliot) Date: Tue, 1 Apr 2008 12:22:02 -0700 Subject: [html4all] Another choice snippet from Ian Hickson, in re MathML In-Reply-To: <47F1E01D.6060405@Royal-Tunbridge-Wells.Org> Message-ID: <007f01c8942d$ad4fb3a0$cf2a42ab@stanford.edu> Philip TAYLOR wrote: >> On the contrary, experience with the Web has shown that including >> redundant data (e.g. accessibility metadata, page description >> metadata, and so forth) is actively harmful, ... > > _______________________________________________ > List_HTML4all.org mailing list > http://www.html4all.org/wiki Oh please, what is the original source of this quote? This is just absolute rubbish of the Nth degree and he *really* needs to be called out on this. Prove this statement Ian, with qualified research and data, just like he asks of us. * What experience? * Actively harmful to whom? How? JF From rob at robburns.com Tue Apr 1 12:49:15 2008 From: rob at robburns.com (Robert J Burns) Date: Tue, 1 Apr 2008 21:49:15 +0200 Subject: [html4all] Another choice snippet from Ian Hickson, in re MathML In-Reply-To: <007f01c8942d$ad4fb3a0$cf2a42ab@stanford.edu> References: <007f01c8942d$ad4fb3a0$cf2a42ab@stanford.edu> Message-ID: <97F6041C-374F-476C-A718-64B6A8E5A143@robburns.com> On Apr 1, 2008, at 9:22 PM, John Foliot wrote: > Philip TAYLOR wrote: >>> On the contrary, experience with the Web has shown that including >>> redundant data (e.g. accessibility metadata, page description >>> metadata, and so forth) is actively harmful, ... >> >> _______________________________________________ >> List_HTML4all.org mailing list >> http://www.html4all.org/wiki > > Oh please, what is the original source of this quote? This is just > absolute > rubbish of the Nth degree and he *really* needs to be called out on > this. > Prove this statement Ian, with qualified research and data, just > like he > asks of us. > > * What experience? > * Actively harmful to whom? How? I have to admit that without the parenthetical there's nothing wrong with what Ian says (though it's not clear what he's referring to then). There certainly is a problem with including redundant data (there certainly is a problem with including redundant data). Where the statement gets ridiculous is in his claim that anything in the parenthesis could be considered redundant. Using the table element?s summary attribute we've been discussing lately, one may make a leap and claim that the summary of the table is redundant in that a sighted user (and one also educated in the discipline in which the table is constructed) should be able to understand the same summation from a careful and perhaps protracted study of the table itself. However, to say that a succinct summary is somehow redundant still strains credibility. Would Ian suggest that in writing essays and academic papers no one every redundant summarize their theses in the introduction or the conclusion of the essay (because it is redundant to do so)? I wouldn't think so. Likewise table header association information is hardly redundant (often the information is conveyed visually through CSS styling). And again, the alt attribute on images is often very necessary (though one may falsely contort this somehow into redundant accessibility metadata because the information conveyed in the succicnt alt text may already be conveyed through the image itself to a particular audience sharing the authors cultural background). The chairs of the WG should really put a stop to these claims that metadata and accessibility values are somehow redundant and harmful. Take care, Rob From joshue.oconnor at cfit.ie Tue Apr 1 14:18:08 2008 From: joshue.oconnor at cfit.ie (Joshue O Connor) Date: Tue, 01 Apr 2008 22:18:08 +0100 Subject: [html4all] summary issue closed In-Reply-To: <1207070517.12340.47.camel@pav.lan> References: <55687cf80803231355j65ea03d7y9365a358b07c8bcf@mail.gmail.com> <55687cf80803240955j4586820l25f706e4acb99aa4@mail.gmail.com> <1c8dbcaa0803241032h3e0c829pebfa7d121a8c8eba@mail.gmail.com> <47F0C357.1000108@cfit.ie> <1207070517.12340.47.camel@pav.lan> Message-ID: <47F2A690.90208@cfit.ie> Dan Connolly wrote: >>>> Rejected by editor due to unclear problem description. [Ian Hickson]" >>> http://www.w3.org/html/wg/tracker/issues/32 >> The issue will be rewritten for the sake of clarity and then re-submitted. > > Thanks, Josh. > > Feel free to use the same issue number when you re-submit; > I don't see any reason to make a new/separate issue. Thanks Dan, I will. I don't by any means consider the issue closed. Cheers Josh From oedipus at hicom.net Wed Apr 2 15:17:30 2008 From: oedipus at hicom.net (Gregory J. Rosmaita) Date: Wed, 2 Apr 2008 23:17:30 +0100 Subject: [html4all] FYI: joint forms task force activity (or at least talk of such) Message-ID: <20080402221243.M82776@hicom.net> aloha! just an FYI on the state of the joint forms task force -- the recent activity starts at: http://lists.w3.org/Archives/Public/public-forms-tf/2008Apr/0000.html or you can just go to http://lists.w3.org/Archives/Public/public-forms-tf/2008Apr and follow things from there... gregory. -------------------------------------------------------------- You cannot depend on your eyes when your imagination is out of focus. -- Mark Twain -------------------------------------------------------------- Gregory J. Rosmaita: oedipus at hicom.net Camera Obscura: http://www.hicom.net/~oedipus/ Oedipus' Online Complex: http://my.opera.com/oedipus -------------------------------------------------------------- From faulkner.steve at gmail.com Fri Apr 4 03:02:31 2008 From: faulkner.steve at gmail.com (Steven Faulkner) Date: Fri, 4 Apr 2008 11:02:31 +0100 Subject: [html4all] 2 simple ARIA examples Message-ID: <55687cf80804040302l6cb3d452i77f5d3edff8cd6e1@mail.gmail.com> have publshed 2 aria examples on our company blog: http://www.paciellogroup.com/blog/?p=53 feedback welcome! -- with regards Steve Faulkner Technical Director - TPG Europe Director - Web Accessibility Tools Consortium www.paciellogroup.com | www.wat-c.org Web Accessibility Toolbar - http://www.paciellogroup.com/resources/wat-ie-about.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wilbur.bytowninternet.com/pipermail/list_html4all.org/attachments/20080404/fa7b87ee/attachment.html From faulkner.steve at gmail.com Fri Apr 11 01:23:03 2008 From: faulkner.steve at gmail.com (Steven Faulkner) Date: Fri, 11 Apr 2008 09:23:03 +0100 Subject: [html4all] New issue: IMG section of HTML5 draft contradicts WCAG 1 & WCAG 2 (draft) Message-ID: <55687cf80804110123s69564fe4h2cd882e1733590f9@mail.gmail.com> Gregory, can you add this issue to the issue tracker. thanks. issue: IMG section of HTML5 draft contradicts WCAG 1 & WCAG 2 (draft). Currently the IMG section of the draft HTML5 spec contains normative and informative statements about the alt attribute and how it is to be used, that contradict the normative and informative statements in WCAG 1.0 and WCAG 2.0 (draft). A request[1] was made by members of the working group to the PF WG to provide advice on this issue The PF WG provided their views [2] on this matter to the HTML WG: 1. By the principles, HTML5 wants to support accessibility 2. By their charters, WAI groups (here WCAG) are the go-to experts in matters of accessibility 3. WCAG requires @alt (WCAG1) or the function that in HTML4 is provided by @alt (WCAG2) [editorial note -- add links] 4. By the principles, if it ain't broke, don't fix it. 5. Conclusion: barring the introduction of new, good reasons for a change, the failure of the HTML5 draft to make @alt on an across-the-board requirement (even if sometimes it has the value of "") is a bug. There has been no response from the HTML WG to the PF WG in regards to this. The purposes of opening this issue is to work towards the HTML5 spec providing normative and informative statements that are in line with the WCAG 1.0/WCAG 2.0. As a part of this process an action item is in place Action 54 - draft text for HTML 5 spec to require producers/authors to include @alt on img elements [3] It is requested that this orphan action item be attached to this new issue. It is requested that this issue remain open until: Consensus has been reached by the HTML WG on normative/informative statements within the HTML 5 spec regarding the alt and its uses or if consensus cannot be reached, the issue is brought to a formal vote. [1]http://lists.w3.org/Archives/Public/wai-xtech/2007Oct/0044.html [2]http://lists.w3.org/Archives/Public/public-html/2008Feb/0082.html [3] http://www.w3.org/html/wg/tracker/actions/54 -- with regards Steve Faulkner Technical Director - TPG Europe Director - Web Accessibility Tools Consortium www.paciellogroup.com | www.wat-c.org Web Accessibility Toolbar - http://www.paciellogroup.com/resources/wat-ie-about.html From hsivonen at iki.fi Fri Apr 11 02:29:20 2008 From: hsivonen at iki.fi (Henri Sivonen) Date: Fri, 11 Apr 2008 12:29:20 +0300 Subject: [html4all] New issue: IMG section of HTML5 draft contradicts WCAG 1 & WCAG 2 (draft) In-Reply-To: <55687cf80804110123s69564fe4h2cd882e1733590f9@mail.gmail.com> References: <55687cf80804110123s69564fe4h2cd882e1733590f9@mail.gmail.com> Message-ID: <6BC82B20-F753-46F0-80B9-E53661B8C27E@iki.fi> On Apr 11, 2008, at 11:23, Steven Faulkner wrote: > 5. Conclusion: barring the introduction of new, good > reasons for a change, the failure of the HTML5 draft to make > @alt on an across-the-board requirement (even if sometimes > it has the value of "") is a bug. Hixie's email on the matter and my previous email(s) on the matter gave a reason: A piece of software gets images from somewhere and puts them automatically out on the Web. What should the developer of that piece of software program it to do when an image arrives from whatever pipe they arrive from without alternative text? How do you require a program to emit something it simply doesn't have without faking it with junk? (Note: Saying that the program should block until human intervention won't be a viable approach. A product that did that would only be supplanted by products that don't. Saying that such products should be programmed to output invalid HTML isn't a viable answer, either. Saying that the program should emit alt='' would lose information about lack of data vs. marking the image as decorative.) Should I conclude that you don't count the reason as a good reason? -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/ From Philip-and-LeKhanh at Royal-Tunbridge-Wells.Org Fri Apr 11 03:06:48 2008 From: Philip-and-LeKhanh at Royal-Tunbridge-Wells.Org (Philip TAYLOR) Date: Fri, 11 Apr 2008 11:06:48 +0100 Subject: [html4all] New issue: IMG section of HTML5 draft contradicts WCAG 1 & WCAG 2 (draft) In-Reply-To: <6BC82B20-F753-46F0-80B9-E53661B8C27E@iki.fi> References: <55687cf80804110123s69564fe4h2cd882e1733590f9@mail.gmail.com> <6BC82B20-F753-46F0-80B9-E53661B8C27E@iki.fi> Message-ID: <47FF3838.2040302@Royal-Tunbridge-Wells.Org> Henri Sivonen wrote: > Saying that the program should emit alt='' would lose information > about lack of data vs. marking the image as decorative.) Why could the program not emit something along the lines of 'alt=""' ? Philip TAYLOR From chaals at opera.com Fri Apr 11 03:08:50 2008 From: chaals at opera.com (Charles McCathieNevile) Date: Fri, 11 Apr 2008 12:08:50 +0200 Subject: [html4all] New issue: IMG section of HTML5 draft contradicts WCAG 1 & WCAG 2 (draft) In-Reply-To: <6BC82B20-F753-46F0-80B9-E53661B8C27E@iki.fi> References: <55687cf80804110123s69564fe4h2cd882e1733590f9@mail.gmail.com> <6BC82B20-F753-46F0-80B9-E53661B8C27E@iki.fi> Message-ID: On Fri, 11 Apr 2008 11:29:20 +0200, Henri Sivonen wrote: > On Apr 11, 2008, at 11:23, Steven Faulkner wrote: >> 5. Conclusion: barring the introduction of new, good >> reasons for a change, the failure of the HTML5 draft to make >> @alt on an across-the-board requirement (even if sometimes >> it has the value of "") is a bug. > > > Hixie's email on the matter and my previous email(s) on the matter > gave a reason: > > A piece of software gets images from somewhere and puts them > automatically out on the Web. What should the developer of that piece > of software program it to do when an image arrives from whatever pipe > they arrive from without alternative text? How do you require a > program to emit something it simply doesn't have without faking it > with junk? > > (Note: Saying that the program should block until human intervention > won't be a viable approach. A product that did that would only be > supplanted by products that don't. This is not necessarily true. There are plenty of contexts where such programs would not be (or even are not) supplanted by others - although in some cases that will indeed happen. > Saying that such products should be > programmed to output invalid HTML isn't a viable answer, either. Why not? Almost *every* tool I know of that produces HTML produces invalid HTML, so I am not sure how you determine that there is some existential reason why this cannot happen. > Saying that the program should emit alt='' would lose information > about lack of data vs. marking the image as decorative. Indeed - I am thoroughly in agreement on this point. The group might like to consider the relevant parts of the Authoring Tool Accessibility Guidelines 1.0 [1] which address this particular problem, or their equivalent sections in the ATAG 2 draft [2] (and the suggested techniques linked from the relevant aprts of those documents). This seems not to be a new issue, but a continuation of ISSUE-31 [1] http://www.w3.org/TR/ATAG10 see especially http://www.w3.org/TR/ATAG10/atag10.html#check-leave-access-content http://www.w3.org/TR/ATAG10/atag10.html#check-no-default-alt http://www.w3.org/TR/ATAG10/atag10.html#check-provide-missing-alt http://www.w3.org/TR/ATAG10/atag10.html#check-notify-on-schedule http://www.w3.org/TR/ATAG10/atag10.html#check-dont-require-knowledge http://www.w3.org/TR/ATAG10/atag10.html#check-have-alt-registry as well as http://www.w3.org/TR/ATAG10/atag10.html#check-include-pro-descs For the summary version of ATAG 10 see http://www.w3.org/TR/ATAG10/atag10-chklist.html - it is a few screenfuls. [2] Principles B2.2, B2.3 and B2.4 in section http://www.w3.org/TR/ATAG20/#principle-support-author, although note also section B3 cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle fran?ais -- hablo espa?ol -- jeg l?rer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com From Philip-and-LeKhanh at Royal-Tunbridge-Wells.Org Fri Apr 11 03:21:34 2008 From: Philip-and-LeKhanh at Royal-Tunbridge-Wells.Org (Philip TAYLOR) Date: Fri, 11 Apr 2008 11:21:34 +0100 Subject: [html4all] New issue: IMG section of HTML5 draft contradicts WCAG 1 & WCAG 2 (draft) In-Reply-To: References: <55687cf80804110123s69564fe4h2cd882e1733590f9@mail.gmail.com> <6BC82B20-F753-46F0-80B9-E53661B8C27E@iki.fi> Message-ID: <47FF3BAE.2010300@Royal-Tunbridge-Wells.Org> Charles McCathieNevile wrote: >> Saying that such products should be >> programmed to output invalid HTML isn't a viable answer, either. > > Why not? Almost *every* tool I know of that produces HTML produces invalid > HTML, so I am not sure how you determine that there is some existential > reason why this cannot happen. Are you serious, Charles ? Are you really arguing that the generating of invalid code is an acceptable option ? If so, I would seriously suggest you move a motion to disolve the W3C, since it would have no role whatsoever in the anarchic world that you appear to be willing to tolerate. Phiip TAYLOR From Philip-and-LeKhanh at Royal-Tunbridge-Wells.Org Fri Apr 11 03:31:41 2008 From: Philip-and-LeKhanh at Royal-Tunbridge-Wells.Org (Philip TAYLOR) Date: Fri, 11 Apr 2008 11:31:41 +0100 Subject: [html4all] New issue: IMG section of HTML5 draft contradicts WCAG 1 & WCAG 2 (draft) In-Reply-To: <47FF3B65.7060605@gmx.de> References: <55687cf80804110123s69564fe4h2cd882e1733590f9@mail.gmail.com> <6BC82B20-F753-46F0-80B9-E53661B8C27E@iki.fi> <47FF3838.2040302@Royal-Tunbridge-Wells.Org> <47FF3B65.7060605@gmx.de> Message-ID: <47FF3E0D.30607@Royal-Tunbridge-Wells.Org> Julian Reschke wrote: >> 'alt=""' > > ... > > How is that better than not having a value at all? By "no value at all", do you mean (a) "no ALT attribute" (in which case the answer is that my proposal is syntactically valid, assuming a mandate for ALT atributes), or (b) a null ALT attribute, in which case the latter is reserved for images that do not contribute to the content of the page. Philip TAYLOR From Philip-and-LeKhanh at Royal-Tunbridge-Wells.Org Fri Apr 11 04:05:54 2008 From: Philip-and-LeKhanh at Royal-Tunbridge-Wells.Org (Philip TAYLOR) Date: Fri, 11 Apr 2008 12:05:54 +0100 Subject: [html4all] New issue: IMG section of HTML5 draft contradicts WCAG 1 & WCAG 2 (draft) In-Reply-To: <47FF455B.1000509@gmx.de> References: <55687cf80804110123s69564fe4h2cd882e1733590f9@mail.gmail.com> <6BC82B20-F753-46F0-80B9-E53661B8C27E@iki.fi> <47FF3838.2040302@Royal-Tunbridge-Wells.Org> <47FF3B65.7060605@gmx.de> <47FF3E0D.30607@Royal-Tunbridge-Wells.Org> <47FF455B.1000509@gmx.de> Message-ID: <47FF4612.2070603@Royal-Tunbridge-Wells.Org> Julian Reschke wrote: >> By "no value at all", do you mean (a) "no ALT attribute" > > Yes. > >> (in which case the answer is that my proposal is >> syntactically valid, assuming a mandate for ALT > > Well, if we insist on requiring the attribute, than not having the > attribute is invalid. Invalid is bad. This is why we are having this > discussion, aren't we? Fine, so we agree, do we not ? My proposal leads to valid HTML, and the AT user will learn from the ALT text supplied that no more meaningful ALT text was available at the time that the page was generated. Not sure where we differ ... ** Phil. From Philip-and-LeKhanh at Royal-Tunbridge-Wells.Org Fri Apr 11 04:24:57 2008 From: Philip-and-LeKhanh at Royal-Tunbridge-Wells.Org (Philip TAYLOR) Date: Fri, 11 Apr 2008 12:24:57 +0100 Subject: [html4all] New issue: IMG section of HTML5 draft contradicts WCAG 1 & WCAG 2 (draft) In-Reply-To: <47FF47F4.1080104@gmx.de> References: <55687cf80804110123s69564fe4h2cd882e1733590f9@mail.gmail.com> <6BC82B20-F753-46F0-80B9-E53661B8C27E@iki.fi> <47FF3838.2040302@Royal-Tunbridge-Wells.Org> <47FF3B65.7060605@gmx.de> <47FF3E0D.30607@Royal-Tunbridge-Wells.Org> <47FF455B.1000509@gmx.de> <47FF4612.2070603@Royal-Tunbridge-Wells.Org> <47FF47F4.1080104@gmx.de> Message-ID: <47FF4A89.2080008@Royal-Tunbridge-Wells.Org> Julian Reschke wrote: > A string saying "there is no alternate text" may be syntactically valid, > but doesn't help the user at all. I disagree ... It will be displayed/read just like it > was the alternate text. Yes,it will; and if, when displayed/read, it explains to the end user /why/ there is no ALT text (available), then he/she will be better informed than if it were simply omitted. We could postulate, for example, by analogy with ARIA, that there be conventions for indicating the reason for the omission of more meaningful ALT text. > > In general, requiring values for things that can't always be provided is > a bad idea. It always leads to authors making up values, which makes the > situation *worse* for the people depending on it. Not if there are well-defined rules for these "made up" values. ** Phil. From chaals at opera.com Fri Apr 11 04:53:50 2008 From: chaals at opera.com (Charles McCathieNevile) Date: Fri, 11 Apr 2008 13:53:50 +0200 Subject: [html4all] validity and other important things Re: New issue: IMG section of HTML5 draft contradicts WCAG 1 & WCAG 2 (draft) In-Reply-To: <47FF3BAE.2010300@Royal-Tunbridge-Wells.Org> References: <55687cf80804110123s69564fe4h2cd882e1733590f9@mail.gmail.com> <6BC82B20-F753-46F0-80B9-E53661B8C27E@iki.fi> <47FF3BAE.2010300@Royal-Tunbridge-Wells.Org> Message-ID: On Fri, 11 Apr 2008 12:21:34 +0200, Philip TAYLOR wrote: > Charles McCathieNevile wrote: > >>> Saying that such products should be >>> programmed to output invalid HTML isn't a viable answer, either. >> >> Why not? Almost *every* tool I know of that produces HTML produces >> invalid >> HTML, so I am not sure how you determine that there is some existential >> reason why this cannot happen. > > Are you serious, Charles ? Are you really arguing that > the generating of invalid code is an acceptable option ? Yes. Under certain circumstances it is an acceptable option, if the choice is between several things, none of which produce a desired outcome and this is the one that does the least harm, and if the consequential effects. It is even in W3C recommendations. > If so, I would seriously suggest you move a motion to > disolve the W3C, since it would have no role whatsoever > in the anarchic world that you appear to be willing to > tolerate. Actually, I think W3C has an important role to play in the anarchic world in which I live. I did not validity is not important. The point of my question is that it is clearly feasible to produce invalid code without the web grinding to a halt (since the web works despite being almost all of the HTML on it being invalid), therefore I don't understand why it is not possible to argue that breaking validity *may* be a reasonable approach to a given problem. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle fran?ais -- hablo espa?ol -- jeg l?rer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com From chaals at opera.com Fri Apr 11 04:58:50 2008 From: chaals at opera.com (Charles McCathieNevile) Date: Fri, 11 Apr 2008 13:58:50 +0200 Subject: [html4all] New issue: IMG section of HTML5 draft contradicts WCAG 1 & WCAG 2 (draft) In-Reply-To: <47FF3838.2040302@Royal-Tunbridge-Wells.Org> References: <55687cf80804110123s69564fe4h2cd882e1733590f9@mail.gmail.com> <6BC82B20-F753-46F0-80B9-E53661B8C27E@iki.fi> <47FF3838.2040302@Royal-Tunbridge-Wells.Org> Message-ID: On Fri, 11 Apr 2008 12:06:48 +0200, Philip TAYLOR wrote: > Henri Sivonen wrote: > >> Saying that the program should emit alt='' would lose information >> about lack of data vs. marking the image as decorative.) > > Why could the program not emit something along the lines of > > 'alt=""' It could. But it is a bad idea because 1. Because that does not mean anything in most langauges of the world. 2. Because you are unlikely to come up with a complete text string that people always emit correctly, and get it implemented through the various tool chains in use, with anything like the same efficiency as working out what the lack of an alt attribute means. 3. Because it isn't actually a terribly helpful statement for a person to hear multiple times. 4. It means that all legacy testing systems will have to be rebuilt to ensure that they recognise this magic string as being equivalent to not having any alt attribute. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle fran?ais -- hablo espa?ol -- jeg l?rer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com From Philip-and-LeKhanh at Royal-Tunbridge-Wells.Org Fri Apr 11 05:07:34 2008 From: Philip-and-LeKhanh at Royal-Tunbridge-Wells.Org (Philip TAYLOR) Date: Fri, 11 Apr 2008 13:07:34 +0100 Subject: [html4all] New issue: IMG section of HTML5 draft contradicts WCAG 1 & WCAG 2 (draft) In-Reply-To: References: <55687cf80804110123s69564fe4h2cd882e1733590f9@mail.gmail.com> <6BC82B20-F753-46F0-80B9-E53661B8C27E@iki.fi> <47FF3838.2040302@Royal-Tunbridge-Wells.Org> Message-ID: <47FF5486.8090909@Royal-Tunbridge-Wells.Org> Off cycling now, so my last contribution for a while : Charles McCathieNevile wrote: > 1. Because that does not mean anything in most langauges of the world. It means neither more, nor less, than "Mt Fuji, the peak bathed in early evening sunset orange, silhouetted against a background of pellucid white cumulus clouds", which most of us (and I suspect that includes yourself) would regard as a totally acceptable ALT text for an image depicting that scene ... > 2. Because you are unlikely to come up with a complete text string that > people always emit correctly, and get it implemented through the various > tool chains in use, with anything like the same efficiency as working out > what the lack of an alt attribute means. Why ? These are /automated/ tools, and it is therefore trivial to modify them to emit a pre-agreed string in circumstances such as these. > 3. Because it isn't actually a terribly helpful statement for a person to > hear multiple times. I agree. > 4. It means that all legacy testing systems will have to be rebuilt to > ensure that they recognise this magic string as being equivalent to not > having any alt attribute. It is /not/ equivalent : that is the whole point. ** Phil. From chaals at opera.com Fri Apr 11 08:16:33 2008 From: chaals at opera.com (Charles McCathieNevile) Date: Fri, 11 Apr 2008 17:16:33 +0200 Subject: [html4all] New issue: IMG section of HTML5 draft contradicts WCAG 1 & WCAG 2 (draft) In-Reply-To: <47FF5486.8090909@Royal-Tunbridge-Wells.Org> References: <55687cf80804110123s69564fe4h2cd882e1733590f9@mail.gmail.com> <6BC82B20-F753-46F0-80B9-E53661B8C27E@iki.fi> <47FF3838.2040302@Royal-Tunbridge-Wells.Org> <47FF5486.8090909@Royal-Tunbridge-Wells.Org> Message-ID: On Fri, 11 Apr 2008 14:07:34 +0200, Philip TAYLOR wrote: > Charles McCathieNevile wrote: > >> 4. It means that all legacy testing systems will have to be rebuilt to >> ensure that they recognise this magic string as being equivalent to not >> having any alt attribute. > > It is /not/ equivalent : that is the whole point. Ah. This is where we disagree I think. Fundamentally I don't think there is such a case as "it is impossible to provide useful alt" - although there are many cases of "I couldn't be bothered" and "we didn't bother making our application support that" and "the Author didn't give any informatin" and so on, that lead to no useful text (in which category I include alt="") being present. And the case where nothing useful has been provided, in the context of getting meaningful content from an author to a user is in fact one of those that is most important and easiest (currently) to distinguish. FWIW I think the current HTML draft recognises this - in line with the reocmmendations from WAI on authoring tools, evaluation mechanisms, and dealing with this issue. >> 1. Because that does not mean anything in most langauges of the world. > > It means neither more, nor less, than "Mt Fuji, the peak bathed > in early evening sunset orange, silhouetted against a background > of pellucid white cumulus clouds", which most of us (and I suspect > that includes yourself) would regard as a totally acceptable ALT > text for an image depicting that scene ... In the right circumstances that would be a fine text. If you are suggesting that we should generally accept any human-readable text explaining that the author didn't provide anything, then I disagree (there has already been a thread on default values in alt, and I don't think there is any reasoning that hasn't been exposed). >> 2. Because you are unlikely to come up with a complete text string that >> people always emit correctly, and get it implemented through the various >> tool chains in use, with anything like the same efficiency as working >> out what the lack of an alt attribute means. > > Why ? These are /automated/ tools, and it is therefore trivial > to modify them to emit a pre-agreed string in circumstances > such as these. Because you have to identify each such tool and convince them to follow the new standard. Given the abject failure so far to convince most HTML authoring tool developers to follow the relevant standards, I suspect that "build it and they will come" is not a useful answer - having spent several years when i worked at W3C being *one* of the people pushing tools towards standards compliance my experience is that this is the sort of thing that takes a lot longer to get into the tool chain than people just doing nothing. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle fran?ais -- hablo espa?ol -- jeg l?rer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com From vlad.alexander at xstandard.com Fri Apr 11 11:59:47 2008 From: vlad.alexander at xstandard.com (Vlad Alexander (XStandard)) Date: Fri, 11 Apr 2008 14:59:47 -0400 Subject: [html4all] New issue: IMG section of HTML5 draft contradicts WCAG 1 & WCAG 2 (draft) Message-ID: <0yqftvczoeitmpv.110420081459@pinscher> > Almost *every* tool I know of that produces HTML > produces invalid HTML Charles, I am glad you said "almost" :-) (given what we do) > The point of my question is that it is clearly feasible > to produce invalid code without the web grinding to a halt > (since the web works despite being almost all of the HTML > on it being invalid) The Web only works for the majority, but certainly not work for everyone. > A piece of software gets images from somewhere and puts > them automatically out on the Web. What should the > developer of that piece of software program it to do > when an image arrives from whatever pipe they arrive > from without alternative text? Just because a Web browser can render image files, we automatically assume that these files are content? In this case, these image files are not content, they are just eye-candy, and therefore should have alt="". Regards, -Vlad http://xstandard.com From foliot at wats.ca Fri Apr 11 12:09:45 2008 From: foliot at wats.ca (John Foliot) Date: Fri, 11 Apr 2008 12:09:45 -0700 Subject: [html4all] New issue: IMG section of HTML5 draft contradicts WCAG 1 & WCAG 2 (draft) In-Reply-To: <47FF47F4.1080104@gmx.de> Message-ID: <009801c89c07$9be48cd0$6e2a42ab@stanford.edu> (Slightly trimmed list to reduce overload) Julian Reschke wrote: > > In general, requiring values for things that can't always be provided > is a bad idea. It always leads to authors making up values, which > makes the situation *worse* for the people depending on it. You know, I've heard this opinion expressed numerous times, but have yet to see any evidence at all to substantiate this claim. Please explain in normative and technical terms how this is "worse", else remove the claim from the discussion. Thank you. JF From foliot at wats.ca Fri Apr 11 13:15:02 2008 From: foliot at wats.ca (John Foliot) Date: Fri, 11 Apr 2008 13:15:02 -0700 Subject: [html4all] New issue: IMG section of HTML5 draft contradicts WCAG 1 & WCAG 2 (draft) In-Reply-To: Message-ID: <00aa01c89c10$baa9a930$6e2a42ab@stanford.edu> Dave Singer wrote: > > Consider an image that is 'part of the content' > an image > tells the user agent that there is a useful alt string that is I will insert here "should be" (as opposed to "is") > worth > displaying to the user, which is a lie (the string provided is not > useful), and > > tells the user-agent that the image is not 'part of the content', > it's not worth describing, which in this hypothetical case is also a > lie, whereas > > tells the user agent the truth, that there is not a useful > author-provided string. And herein lies the first fundamental problem. While your first 2 scenarios have credibility, they both also illustrate a failure on the content contributor, not on the technical merits of mandating an alternative text value to non-textual content. The problem with the proposed spec is that it allows a gray area to exist (in some instances, you don't need an alt value), and the fear (justifiable) from some quarters is that this gray area can and will be exploited. I need only quote one of the HTML5 Working Groups' personal blogs to illustrate this fear: "I am currently following HTML5 (omitting alt) as it wasn't really clear to me what would be a better solution given the single constrain I have: not finding it necessary to provide replacement text for all those images." (http://annevankesteren.nl/2007/09/alt) - Here Anne did not "find it necessary" - not that he could not, nor that the image was an Ink blot test that providing alternative text to would invalidate (the two scenarios suggested in the draft spec), but simply that he did not find it necessary. The fear is very real! All three of your examples do dis-service to those that truly need to have alternative text, but only the third (your "the truth") is a tacit acceptance, almost approval, of the failure of the content creator to do anything. The spec uses "strong language" but does not outright forbid non-textual content to be compliant without alternative text. This is a direct reversal of years of HTML authoring guidelines and web accessibility teaching. > > Lies are "worse" than the truth. Endorsing and permitting truths that cause harm, simply because technically it can be done, is even worse than accepting the truth that still today some authors cannot be bothered to recognize those in our society who are both disadvantaged and who could be further empowered if the content author gave a damn. And this is problem 2 of this on-going discussion. At what point does a technical specification acknowledge social responsibility? Should it? Some other thoughts/responses: Henri Sivonen wrote: > A piece of software gets images from somewhere and puts them > automatically out on the Web. What should the developer of that piece > of software program it to do when an image arrives from whatever pipe > they arrive from without alternative text? How do you require a > program to emit something it simply doesn't have without faking it > with junk? If sewage passes through a conduit, should the conduit do nothing, or at the very least attempt to filter out the larger pieces of sewage? "Faking it with junk" is an un-defined action: this is an identified problem, and if HTML 5 is about identifying and addressing problems, the proposed solution (do nothing) is not a solution, but rather a burying of one's head in the sand. Ryan Parman wrote: > > In regards to the accessibility concerns, it's less important that all > images have alternate text, and more important that the alternate text > provided is actually useful. (Occasionally, IMO, accessibility zealots > tend to trip over their own feet while running to the goal.) Yes, > accessibility is extremely important -- nobody is arguing that -- but > sometimes the right answer is "no value." Fair enough, so what we need then is a method to specifically say that, which is far different than accepting no information at all, which is what making alt optional allows. > > In the related (but not identical) point, does having a fake (i.e. > unusable) value make things *worse* than not having a value (in cases > where there SHOULD be one -- which is most of them) at all? I'd argue > that it certainly has the potential to be worse for people using > assistive technologies, search engine spidering and the like, although > I admittedly don't have any notable experience with assistive/search > technology. Henri S. used the word "fake", but that is undefined. This once again points to the need (IMHO) for one or more reserved values that user agents can "standardize" on (remember, this *IS* about standards) that address possible scenarios when content authors fail to, or cannot, provide appropriate alternative text. "_notsupplied" and "_decorative" are two that instantly come to mind. The "_notsupplied" while still far from useful does signify that the image is probably of value, as opposed to "_decorative" which is fairly self-explanatory. "_notsupplied" has the added benefit (IMHO) of also applying a subtle but real social pressure on content contributors to do something, but if they choose to ignore that pressure, then the default of "_notsupplied" still allows compliancy, whilst still retaining the mandated need for alt values for all non-textual content. Charles McCathieNevile wrote: > 4. It means that all legacy testing systems will have to be rebuilt to > ensure that they recognise this magic string as being equivalent to > not having any alt attribute. Chaals and I have discussed this, and he is correct. However, if the choice is between having the alt attribute optional vs. legacy tools becoming less useful, I vote for option 2. WCAG 2 will necessitate a re-writing of many testing tools, do we then not embrace WCAG 2 because it breaks legacy tools? Of course not! Software evolves, in part based on market conditions. Just as sure as we will see an Opera 10, we will see testing systems evolve to new standards. JF From foliot at wats.ca Fri Apr 11 14:14:08 2008 From: foliot at wats.ca (John Foliot) Date: Fri, 11 Apr 2008 14:14:08 -0700 Subject: [html4all] New issue: IMG section of HTML5 draft contradicts WCAG 1 & WCAG 2 (draft) In-Reply-To: Message-ID: <000401c89c18$ff1a4900$ee2042ab@stanford.edu> Ian Hickson wrote: > > You might be able to get some people to describe some of the most > popular photos, but there's no way that's going to scale to all > photos on all photo galleries, so the problem of what to do with > photos that have no useful alternative text will always exist. Alt="" Alt="_notsupplied" (default) Alt="[user]'s photo #__ of __" (auto-generated) While the first 2 of the 3 above are weak to useless, the third does provide some useful context for non-visual users (and could be programmatically achieved with little effort). In all 3 instances, maintaining the alt attribute for conformance causes no less "problems" than experienced today, while at the same time not endorsing *NOT* providing some alternative text. Remember, Anne wrote, "...the single constrain I have: not finding it necessary to provide replacement text for all those images." Not that he could not, but that he decided not to - it wasn't necessary. Endorsing and allowing that mind-set is just plain wrong IMHO. JF From joshue.oconnor at cfit.ie Fri Apr 11 15:31:03 2008 From: joshue.oconnor at cfit.ie (Joshue O Connor) Date: Fri, 11 Apr 2008 23:31:03 +0100 Subject: [html4all] New issue: IMG section of HTML5 draft contradicts WCAG 1 & WCAG 2 (draft) In-Reply-To: References: Message-ID: <47FFE6A7.3020804@cfit.ie> Ian Hickson wrote: > >> > Even if there is no reasonable text equivalent, there's nothing to say >> > that a blind user wouldn't want to be informed of that image. > > Exactly. But if you give alt="", the image will be removed from the output > stream, _without_ telling the user about its existence. Please note in many cases this is *desirable*. Josh From foliot at wats.ca Fri Apr 11 19:13:25 2008 From: foliot at wats.ca (John Foliot) Date: Fri, 11 Apr 2008 19:13:25 -0700 Subject: [html4all] New issue: IMG section of HTML5 draft contradicts WCAG 1 & WCAG 2 (draft) In-Reply-To: Message-ID: <001901c89c42$cfdd2390$6601a8c0@stanford.edu> Dave Singer wrote: > > Whoever commented that this is a psychological and policy issue > rather than technical are right! This has been a philosophical debate from the onset, and archived transcripts abound at public-html at . For what it's worth, I wrote earlier today (in response to your posting): "At what point does a technical specification acknowledge social responsibility? Should it?" > > When a significant proportion of a democratic society doesn't obey a > set of laws, then yes, I do actually think it's time to examine those > laws and the effect they were trying to achieve, because they may not > be succeeding. This is not *exactly* the case we have today. For at least the past 6, 8, almost 10 years, images without appropriate alternative text have for the most part at least had alt="". While this is less than optimal, it is an established convention, a default setting in most authoring tools, and a poor but established precedent. I would rather that the situation did not exist, that all images had appropriate alternative text, but we don't have that. At debate however is the notion that the current status quo is somehow harmful, as opposed to just less useful. One camp is suggesting that in light of the numerous images with no alternative text, and citing sites such as flickr as being notorious for not providing a means (whether the content provider wished to or not) of providing alternative text, that the spec allow for some images, some of the time, under special conditions, to be 'excused'. At heart is the fact that it is a subjective decision however, and as such cannot be machine measured for compliance - and I have previously cited one of the Working Group's blogs as evidence that the author did not feel it necessary to provide alt text, and that this was allowed within HTML5. Not that it was not possible, only that *he* thought it not necessary. The other camp (of which I am firmly entrenched) argues that this is the thin edge of the wedge, and that allowing the spec to back-peddle on existing requirements (from HTML 3.2 on) that insisted on the alt attribute (not to mention also contravening both the existing WCAG 1 and Draft WCAG 2) causes as much "social harm" as the purported harm being created by alt="". This assertion has never been adequately addressed by the first camp that I am aware of, and I have been embroiled in this debate for some time. > > I think we are in violent agreement about goals and struggling with > ways. This all hinges around the subtlety of accessibility design. > Good accessibility results from > a) good specifications that enables it > b) good authoring that provides it > c) good user-side engineering that exposes it > > So, it's not hard to see ways of building systems that fail on one of > these three. For example (this is a pure strawman) "if everyone > would write a transcript of every video they posted, and link it, > then user-agents could speak the transcript to those unable to see > the video". It's not hard to see that such a specification is poor > because it's vague about how long or detailed the transcript is and > what language it's in, or how it's synchronized with the other audio > (or interleaved with it), it's unlikely to be done by authors, and > (partly because of the spec. problems) rather hard to present to > users. Fail on all 3 counts. Exactly the point. The current spec language is regrettably vague, in that it cites 2 possible scenarios, but leaves open the possibility of other "reasons" for not providing alternative content - the criteria is subjective. The reasons cited are real, but the solution proposed is not a solution, but rather a throwing up of the hands and saying, "..and then if you can't (or won't), don't, and we'll still allow you to be conformant". I argue that this is fundamentally wrong. The "solution" might have merit on a technical level, but it undoes close to a decade's worth of precedence of social engineering (of attempting to educate the masses on the need to provide alt text, of authoring tools trying *very hard* to enable this, etc., etc.). If, as I asked earlier, there is a social requirement for the next generation authoring language to continue to encourage content authors to provide useful textual information to those who are unable to visualize an image, then the proposed "solution" fails (based upon your 3 point criteria), and needs to be re-visited. Some of us (myself for sure) have suggested that a small subset of informative, reserved values be established to address edge case requirements (and even mainstream requirements at times) that the Draft authors are suggesting. Next generation authoring tools could be re-tooled to allow content contributors to choose, with a tick of a box, a default value of "_decorative" for images in that category; flickr and it's kin should be re-tooled to allow contributors to provide alt text, but in the absence of author supplied content to default to "_not supplied"; both of these conditions would be "informed" (as such) decisions/values, and conformance checkers and other "validators" could then flag new content (or even when retrofitting prior content) that had simply alt="" as being problematic and worthy of review/repair. This solution: A) enables authoring tools and automated sites the ability to provide some measure of semantic meaning to images, even if such meaning is of little true value. It does however also maintain the status quo of requiring alt text with images, and from a social-engineering perspective re-enforces the need/value of doing the right thing. [Your a) good specifications that enables it] B) rather than the open, subjective situation the current draft suggests, this locks down the envisioned edge cases that the current proposal suggests to address with a pro-active solution. [Your b) good authoring that provides it] C) with a small subset of reserved values that have been standardized and entrenched into a next-gen spec, authoring tools, user-agents, and adaptive technology alike can take advantage of this standardization and can deal with this DOM node value as it requires. [Your c) good user-side engineering that exposes it] It is worth noting that all of these points have been expressed over numerous occasions to the Draft Working Group, and yet rather than examining the merits of alternative solutions they have stead-fastedly maintained that the current proposed solution is the best solution, despite protestations from many, both from within and outside of the HTML WG. (It is for this reason that you might sense a fair bit of "heat" from some quarters...) JF From faulkner.steve at gmail.com Sat Apr 12 06:23:14 2008 From: faulkner.steve at gmail.com (Steven Faulkner) Date: Sat, 12 Apr 2008 14:23:14 +0100 Subject: [html4all] Propose removing "An image in an e-mail or document intended for a specific person who is known to be able to view images" from the HTML5 spec. Message-ID: <55687cf80804120623s55a2e682pf4eba664abacc57b@mail.gmail.com> The part in the HTML 5 spec (see below). about it being OK to leave the alt off if you are sending an email to someone who is known to view images, is unecessary and just a variation on the "disabled people don't use my web site, so I don't need to make it accessible" argument. It adds nothing of use to the spec apart from providing another dubious reason to omit the alt attribute. I propose it is removed. "An image in an e-mail or document intended for a specific person who is known to be able to view images When an image is included in a communication (such as an HTML e-mail) aimed at someone who is known to be able to view images, the alt attribute may be omitted. However, even in such cases it is stongly recommended that alternative text be included (as appropriate according to the kind of image involved, as described in the above entries), so that the e-mail is still usable should the user use a mail client that does not support images, or should the e-mail be forwarded on to other users whose abilities might not include easily seeing images." source http://www.w3.org/html/wg/html5/#the-img -- with regards Steve Faulkner Technical Director - TPG Europe Director - Web Accessibility Tools Consortium www.paciellogroup.com | www.wat-c.org Web Accessibility Toolbar - http://www.paciellogroup.com/resources/wat-ie-about.html From Philip-and-LeKhanh at Royal-Tunbridge-Wells.Org Sat Apr 12 11:14:42 2008 From: Philip-and-LeKhanh at Royal-Tunbridge-Wells.Org (Philip TAYLOR) Date: Sat, 12 Apr 2008 19:14:42 +0100 Subject: [html4all] Propose removing "An image in an e-mail or document intended for a specific person who is known to be able to view images" from the HTML5 spec. In-Reply-To: <55687cf80804120623s55a2e682pf4eba664abacc57b@mail.gmail.com> References: <55687cf80804120623s55a2e682pf4eba664abacc57b@mail.gmail.com> Message-ID: <4800FC12.6040002@Royal-Tunbridge-Wells.Org> As far as I am concerned, the (ab)use of HTML in e-mail is a complete red herring. HTML is a language intended for the markup of web pages; any reference to its (ab)use for other purposes should be eliminated from the specification. Philip TAYLOR -------- Steven Faulkner wrote: > The part in the HTML 5 spec (see below). about it being OK to leave > the alt off if you are sending an email to someone who is known to > view images, is unecessary and > just a variation on the "disabled people don't use my web site, so I > don't need to make it accessible" argument. It adds nothing of use to > the spec apart from providing another dubious reason to omit the alt > attribute. > > I propose it is removed. From hsivonen at iki.fi Sun Apr 13 01:55:05 2008 From: hsivonen at iki.fi (Henri Sivonen) Date: Sun, 13 Apr 2008 11:55:05 +0300 Subject: [html4all] several messages about alt In-Reply-To: References: <55687cf80804110123s69564fe4h2cd882e1733590f9@mail.gmail.com> <6BC82B20-F753-46F0-80B9-E53661B8C27E@iki.fi> Message-ID: <70F786EB-06B3-4761-80CC-B44EC73A8012@iki.fi> First, why do I even care to touch this rathole topic? It affects directly how the product I develop is expected to behave, and that affects its relationship with its users. Here's how I see this discussion: There is no law of physics or a fundamental result of computer science that prevented computers from pushing pixels around without pushing around a string at the same time. One group of people (the html4all folks) makes a value judgement that people using computers should make computers push around a string when they push around pixels in order to benefit a second group of people (the blind). A third group of people will make a value judgement that pushing pixels around without a string is valuable as such and they don't provide the string as having to provide a string as well would effectively make their use case infeasible (for example, people with camera phones with one- button photo taking and immediate uploading to a photo hosting service). A fourth group of people (developers of photo hosting services) will write software that the third group of people will use. This fourth group--not the third group--are potential users of software I develop: an HTML5 validator. A part of this fourth group consists of software engineers who will 1) write software that is primarily meant for pushing pixels onto the Web (no matter how you try to spin it, in the real world, pushing the pixels to the Web is the primary function--getting the alt text out there is not the primary function) 2) want (either directly themselves or as a client requirement) the output of their software to be valid HTML (whatever that means) 3) realize that there's no fundamental computer science barrier to pushing around pixels without an accompanying string (hence the string can be faked to accomplish #1 and #2 simultaneously) The first group of people wants, based on their value judgment, to establish a social norm onto the third group of people against the value judgment of this third group. This is a social problem. The norm is supposed to benefit the second group of people: the blind. Thus, any rational measure of the goodness of the policy should involve measuring the actual benefit to this second group. Now, does the first group take their social norm directly to the people whose behavior they want to modify? No. Instead, they want to masquerade the social norm as a technical norm, to use the PFWG as a proxy that tells the HTML WG what to do, so that the HTML WG may use the HTML 5 spec as a proxy for influencing the behavior HTML5 validators, so that HTML5 validators are turned into vehicles of advocacy against the fourth group (developers) in the hope that they turn their products into vehicles of advocacy that finally reach the people that the first group wants to impose their social norm on. I think that in this process, the relationship between the product I develop and its users is harmed, because the product then is no longer a tool working for its users but a vehicle of advocacy for someone else. This is one reason why I care. Furthermore, I think complaining about missing alt to developers whose software *simply doesn't have that data* because the third group of people didn't provide it causes developers to either ignore the validator (not what I want) or faking the data they don't have (bad for the supposed beneficiaries of the policy). I even agree that it would be nice if all photos had alternative text. But I don't think it is realistic, and I don't want to internalize the fallout that the first group externalizes by making the product I develop part of a long proxy chain instead of taking their issue directly to the people they want to influence (the people with camera phones in this example). Now, does the policy benefit the intended beneficiaries? It is clear that the policy will lead to information loss or bogus information in a non-trivial proportion of cases. This means that user agents have less information to work with to benefit users. The harm part is obvious on the surface given what we know about the consequences of faking data when it is missing instead of signaling that it is missing. (Consider the examples Julian gave: http://lists.w3.org/Archives/Public/public-html/2008Apr/0314.html ) If the harm in this case defies the obvious, I think the obvious needs to be proven wrong by research. Furthermore, the alleged benefits of the policy are speculative--that the policy of requiring alt syntactically would make more people supply useful alt text than telling people that a good alt text is needed for accessibility. With the harm side obvious and the benefit side speculative, I think the policy shouldn't be adopted without empirical research showing that the benefit exceeds the harm as perceived by the supposed beneficiaries. If research shows that there indeed would be a net benefit for the blind, then we can weigh if that net benefit is so great that it justifies collateral damage (e.g. turning some potential users away from validators). As for "sending a strong message" while actually not benefitting the supposed beneficiaries, I have no interest in becoming (through the product I develop) a stooge for such a policy. This is another reason I care. Sending a strong message doesn't necessarily translate into better accessibility. Consider: http://www.nytimes.com/2008/01/20/magazine/20wwln-freak-t.html?_r=1&ex=1358485200&en=0d05099c03c97375&ei=5090&partner=rssuserland&emc=rss&pagewanted=all&oref=slogin On Apr 11, 2008, at 13:08, Charles McCathieNevile wrote: > On Fri, 11 Apr 2008 11:29:20 +0200, Henri Sivonen > wrote: >> Saying that such products should be >> programmed to output invalid HTML isn't a viable answer, either. > > Why not? Almost *every* tool I know of that produces HTML produces > invalid > HTML, so I am not sure how you determine that there is some > existential > reason why this cannot happen. We are talking about defining what's valid. The validity definition doesn't matter for people who don't even want the tools they write to output valid HTML. Therefore, it is only relevant to consider people who might care about the validity of the output of their products. On Apr 11, 2008, at 15:05, Steven Faulkner wrote: > Two images without explicitly associated text alternatives. > 1 is an image is decorative that the author has accidently left off > the alt, the other is "critical content" that the author could not > provide an alt for whatever reason > 1 can be safely ignored, the other should be brought to the attention > of the user. > > > > > > How is Assistive Technology supposed to reliably determine this? > Given that these two images could be the same, but their meaning > differ widely depending on the intent of the author in regards to > their use. That question is a red herring. The right question is: What do you expect a content management system to do when its user uploaded an image but did not provide alternative text? And the follow-up: How is your answer better that letting the CMS signal to the UA that it doesn't have alternative text? (The simplest definition for such signaling is the omission of the alt attribute.) On Apr 11, 2008, at 20:34, Dave Singer wrote: > I gave an anecdote before about an installer program that insisted > on text strings to describe optional installs. Many, many packages > came configured offering, say "the frotz option" and if I asked for > the "alt" I would get the text "this installs the frotz option". If > the installer *knew* that there was no explanation, it might be able > to say "this installs a background process with root privilege, and > a plug-in to the mail program" and I might be a little more informed. Indeed. A software developer with an output spec and insufficient input where the input can satisfy the main objective of his/her software *will* fake the missing data to match the output spec as far a computer can tell. That's how software developers behave. Here's my earlier example: "For example, if you are a kernel developer and you are copying files from a file system that doesn't record the creation dates of files to another file system that insists that every file *must* have a creation date, you don't tell your boss/customers/whatever that you can't copy the files. Instead, you fake the creation date (the current time from the clock, the start of the epoch, whatever)." > Similarly, a web agent given an image with no alt might be able to > indicate the size of the picture, and there is plenty of evidence to > suggest that in time it could do image analysis and work out that > there is a person, it's a landscape, and so on. If the alt text is > provided but worthless, it would obscure this capability. Indeed. On Apr 11, 2008, at 23:07, Matt Morgan-May wrote: > We know from over 10 years of experience that authors are going to > lie. Does inducing authors to lie benefit the stated beneficiaries of your policy? > You cannot turn one of the most common validity and accessibility > failures > on its head simply because an empty alt attribute is unattractive. The empty string as the value and the absence of the attribute signal different things. Making both cases the same is information loss. On Apr 11, 2008, at 23:15, John Foliot wrote: > I need > only quote one of the HTML5 Working Groups' personal blogs to > illustrate > this fear: > > "I am currently following HTML5 (omitting alt) as it wasn't really > clear to me what would be a better solution given the single > constrain I > have: not finding it necessary to provide replacement text for all > those > images." (http://annevankesteren.nl/2007/09/alt) - Here Anne did not > "find > it necessary" - not that he could not, nor that the image was an Ink > blot > test that providing alternative text to would invalidate (the two > scenarios > suggested in the draft spec), but simply that he did not find it > necessary. > The fear is very real! Suppose Anne hadn't written his CMS himself and I'm selling Anne a CMS that I develop. What should I program the system to do when Anne doesn't supply alternative text? (Also suppose that I still want to extract a licensing or consulting fee from him.) > Henri Sivonen wrote: >> A piece of software gets images from somewhere and puts them >> automatically out on the Web. What should the developer of that piece >> of software program it to do when an image arrives from whatever pipe >> they arrive from without alternative text? How do you require a >> program to emit something it simply doesn't have without faking it >> with junk? > > If sewage passes through a conduit, should the conduit do nothing, > or at the > very least attempt to filter out the larger pieces of sewage? What incentive does the developer of the conduit have to block what you call sewage? Is that incentive stronger than whatever incentive there is to let the "sewage" pass through? > Henri S. used the word "fake", but that is undefined. This once again > points to the need (IMHO) for one or more reserved values that user > agents > can "standardize" on (remember, this *IS* about standards) that > address > possible scenarios when content authors fail to, or cannot, provide > appropriate alternative text. "_notsupplied" How is alt='_notsupplied' better than defining the absence of the attribute to mean exactly what you would define alt='_notsupplied' to mean? > and "_decorative" are two that > instantly come to mind. How is alt='_decorative' better than defining alt='' to mean exactly what you would define alt='_decorative' to mean? > "_notsupplied" has the added benefit > (IMHO) of also applying a subtle but real social pressure on content > contributors to do something, but if they choose to ignore that > pressure, > then the default of "_notsupplied" still allows compliancy, whilst > still > retaining the mandated need for alt values for all non-textual > content. Ah. This is how it is supposed to be better. Thus you want someone other than you to apply the pressure to someone other than whom you seek to apply the pressure to. And you want to do it by making the syntax cruftier. Frankly, I think you are now at the point where you are vehemently clinging onto a bad policy and amending it with worse and worse additional rules in order to avoid re-examining whether the need of the amendments should be taken as an indication that the base policy needs adjustment. I don't know a name for this phenomenon, but others shouldn't play along to save you from re-examining the policy. On Apr 11, 2008, at 23:18, Bonner, Matt (IPG) wrote: > Are there any usability studies or tests done by screen > reader software companies that could help resolve this > debate? Excellent point! On Apr 11, 2008, at 23:54, Katie Haritos-Shea wrote: > People will continue to commit crimes and break the law........but > it that a reason not to have them? First, HTML 5 is not law, and I don't want an HTML5 validator to have anything to do with legal proceedings. As for making laws that people break, it is corrosive (to use Lessig's vocabulary) to society to have laws that normal people are in violation of in their daily lives. This is why prohibition and laws like the DMCA/EUCD are bad as they turn normal people into law- breakers and makes them really cynical about law in general thereby devaluing laws in general. Likewise, a validity rule that normal Web developers would game in their daily development activities devalues validator messages. On Apr 12, 2008, at 01:24, Matt Morgan-May wrote: > If you allow alt to become optional in order to satisfy user-uploaded > content requirements, then accessibility evaluation and repair tools > have no > way of knowing whether you omitted it purposely, or out of ignorance. We are talking about what HTML5 validators are to say. We aren't talking about accessibility evaluation tools. WCAG is free to be normative about those. However, I think accessibility evaluation tools make people write for the tools instead writing for accessibility. That's why accessibility should be evaluated by people. An HTML5 validator isn't an accessibility evaluation tool--or at least I think it shouldn't be. An HTML5 validator is just a spell checker for the benefit of markup writers so that they can identify typos and typo-like mistakes instead of having to figure out why a counter- intuitive error handling mechanism kicks in when they test in browsers. A spell checker doesn't tell you if your fiction writing is entertaining or non-fiction actually factual. Those are different evaluation axes. > You can define the exception case that warrants a missing alt > attribute as > narrowly as you like in the spec, but you know as well as I do that > people > aren't going to read the spec for guidance at that level, if they > read it at > all. FWIW, Validator.nu doesn't flag PUA characters as errors even though they are prohibited most of the time, since there's also a narrow legitimate use. It does give a one-time warning, though. > Further, I think that while user-generated content is a popular > category of > web content, it's just one such category, and since there are any > number of > other kinds of content for which no such exception should exist, > there's no > justification to turn the rules around on alt solely for the benefit > of > those sites. The syntax rules need to be lax enough for all kinds of sites to be able to comply. If all sites can't be accessible, too, then accessibility and syntactic correctness are different evaluation axes. On Apr 13, 2008, at 03:35, Leif Halvard Silli wrote: > In this regard, I proposed [1] - as an replacement for the current > "WYSIWYG made" stamp - a new "unready" stamp, which all authors - > couples, and blind - and all editing tools - could use, when they > need to offer HTML which they consider technically unready. Alternatively, we could call "unready" valid HTML5 and "better than unready" valid HTML5 with WCAG compliance. We don't have to conflate accessibility evaluation with the syntactic correctness. -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/ From hsivonen at iki.fi Sun Apr 13 05:05:36 2008 From: hsivonen at iki.fi (Henri Sivonen) Date: Sun, 13 Apr 2008 15:05:36 +0300 Subject: [html4all] several messages about alt In-Reply-To: <5f37426b0804130415p2dc0503csc669bc4d90aa74a2@mail.gmail.com> References: <55687cf80804110123s69564fe4h2cd882e1733590f9@mail.gmail.com> <6BC82B20-F753-46F0-80B9-E53661B8C27E@iki.fi> <70F786EB-06B3-4761-80CC-B44EC73A8012@iki.fi> <5f37426b0804130415p2dc0503csc669bc4d90aa74a2@mail.gmail.com> Message-ID: On Apr 13, 2008, at 14:15, Ben Boyle wrote: > > I think I understand this, but not sure. > > There is a difference between checking one's HTML syntax is valid, vs > evaluating its accessibility (or any other value-based quality > measure). You're advocating keeping these separate. I can see the gulf > between the two. > > Where does "conformance" fit in on the scale? It depends on what kind of conformance is meant. First, there's the question of conformance to what? To HTML5? To WCAG? Second, there's the issue that overall conformance criteria may have parts that are not machine checkable. In theory, HTML5 conformance and HTML5 validity are the same thing. In practice, though, people tend to think that validity is what a validator checks, which is machine-checkable conformance criteria. Examples of non-machine-checkable conformance criteria: * "The img must not be used as a layout tool." (HTML 5) * "Authors must only use elements, attributes, and attribute values for their appropriate semantic purposes." (HTML 5) * "Content MUST NOT use a code point for any purpose other than that defined by its coded character set." (Charmod) * "Images of text are only used for pure decoration or where a particular presentation of text is essential to the information being conveyed." (WCAG 2.0) -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/ From lhs at malform.no Sun Apr 13 08:33:05 2008 From: lhs at malform.no (Leif Halvard Silli) Date: Sun, 13 Apr 2008 17:33:05 +0200 Subject: [html4all] several messages about alt In-Reply-To: References: <55687cf80804110123s69564fe4h2cd882e1733590f9@mail.gmail.com> <6BC82B20-F753-46F0-80B9-E53661B8C27E@iki.fi> <70F786EB-06B3-4761-80CC-B44EC73A8012@iki.fi> <5f37426b0804130415p2dc0503csc669bc4d90aa74a2@mail.gmail.com> Message-ID: <480227B1.20802@malform.no> Henri Sivonen 08-04-13 14.05: ? > On Apr 13, 2008, at 14:15, Ben Boyle wrote: > > > Where does "conformance" fit in on the scale? > > It depends on what kind of conformance is meant. First, there's the > question of conformance to what? To HTML5? To WCAG? Second, there's > the issue that overall conformance criteria may have parts that are > not machine checkable. > And as you say below, HTML 5 has such criterias. > In theory, HTML5 conformance and HTML5 validity are the same thing. In > practice, though, people tend to think that validity is what a > validator checks, which is machine-checkable conformance criteria. > Your product is called a conformance checker. So, I take it that you are in doubt about whether it should actually be a conformance checker, or if it should be a validity checker. And also it seems that even if it will be a validity checker, you still consider calling it a conformance checker. (Conformance to HTML 5, that is.) > Examples of non-machine-checkable conformance criteria: > * "The img must not be used as a layout tool." (HTML 5) > * "Authors must only use elements, attributes, and attribute values > for their appropriate semantic purposes." (HTML 5) > * "Content MUST NOT use a code point for any purpose other than that > defined by its coded character set." (Charmod) > * "Images of text are only used for pure decoration or where a > particular presentation of text is essential to the information being > conveyed." (WCAG 2.0 If we formalise that the first step of validation/conformance checking, namely the checking of whether images have the correct alt text and are used in the right way, if tables have summary, and so on and so forth, as a step that must be done by the author/webmaster, then your product could be allowed to check only the more formal points - while at the same time also give a stamp that the document conforms, taking into account that the author has done his job in advance. Of course, if there are photo web sites taking constant streams of photos from mobile phones etc, then it should be possible to make that CMS handle those photos in a way that the webmaster approves of, so that he can offer the site for validation/conformance checking. It will be up to the site policy to decide whether one are satisfied with the way it is handeled or not. Henri Sivonen 08-04-13 10.55: ? > The syntax rules need to be lax enough for all kinds of sites to be > able to comply. If all sites can't be accessible, too, then > accessibility and syntactic correctness are different evaluation axes. > Those are different evaluation axes. But experience has shown us that the only validation that authors care about is the general CSS and HTML stamps. Therefore, we must (continue to) incorporate social consciousness into the general stamping tools. And also - and this goes against what you said in your rathole letter: people tend to think that the HTML stamp actually also incorporate some general accesibility checking, as it does check if there is an alt and a summary etc. The W3 HTML checker has always done a small bit of accessiblity checking , and that is part of why people want to check their pages in that validator. To offer a checker as a same kind of prestiged checker as the current W3 tool, without incorporating some basic accessibility checking, would be a bit like stealing goodwill from a wholly different kind of tool. It was Anne, who in his blog once said those very wise words (quoted from my mind) that "people are making XHTML pages thinking they are making more accessible and semantic pages - though in reality both etc are permitted in current XHTML". He is right, but this also shows that people expect to be measured against a accessibility and semantisism standard when they run their pages through the validator mill. The way I propose it, with some kind of "unready" stamp etc, people will be allowed to cheat - just remove the 'unready' and do the minimum thing with the alt attribtues - but they will also then know that they are cheating. At the same time, what is cheating? The author evalution always counts. Btw, it strikes me that validation tools have two kinds of purposes: One is acting as a formal stamp. The other is that they are developement tools. For instance, my main browser, iCab, incorporates an error checker, which informs me about lacking alt attributes and so on. And my text editor stops coloring the syntax if there is a syntax error. (Unfortunatly - or perhaps not - forgetting an alt attribute does not destroy the syntax colors.) Henri Sivonen 08-04-13 10.55: ? > On Apr 13, 2008, at 03:35, Leif Halvard Silli wrote: > > In this regard, I proposed [1] - as an replacement for the current > > "WYSIWYG made" stamp - a new "unready" stamp, which all authors - > > couples, and blind - and all editing tools - could use, when they > > need to offer HTML which they consider technically unready. > > Alternatively, we could call "unready" valid HTML5 and "better than > unready" valid HTML5 with WCAG compliance. We don't have to conflate > accessibility evaluation with the syntactic correctness. > For one thing, I meant real unreadyness. And, in fact, not only the accessibility side. And it would be up to the validator to tell if the syntax etc actually is ready. (Unless you think that any document starting with is valid, in which case we don't need any checkers.) [*] For the second, the "unready" stamp does not conflate those two things. It helps keeping them apart. And allows an HTML 5 conformance checker to give a definitive 'Yes', when the author has done his part. And it raises the consciousness about the fact that writing HTML documents is a process. Only the author can know if the document is ready - only he is in charge of how the text needs to be "alt-ed". WCAG is a higher degree of accessibility checking. Given all the things you say that a normal page maker never will do, how come you think he/she will do WCAG cheking? Will you offer a direct link in your tool for running the page in a WCAG checker, for instance? (That could be nice, regardless.) [*] PS: I once asked a vendor representative how, with HTML 5, we will be able to serve pages that triggers quirks mode. And the answer I got was "by omitting the alltogether". I understand that there is hope that quirksmode could be built into CSS, instead. And that would be nice. But that answer showed me that there is no universal demand amongst "vendors" that that any thing presented as HTML needs to be valid. -- leif halvard silli From hsivonen at iki.fi Sun Apr 13 11:57:47 2008 From: hsivonen at iki.fi (Henri Sivonen) Date: Sun, 13 Apr 2008 21:57:47 +0300 Subject: [html4all] several messages about alt In-Reply-To: <480227B1.20802@malform.no> References: <55687cf80804110123s69564fe4h2cd882e1733590f9@mail.gmail.com> <6BC82B20-F753-46F0-80B9-E53661B8C27E@iki.fi> <70F786EB-06B3-4761-80CC-B44EC73A8012@iki.fi> <5f37426b0804130415p2dc0503csc669bc4d90aa74a2@mail.gmail.com> <480227B1.20802@malform.no> Message-ID: On Apr 13, 2008, at 18:33, Leif Halvard Silli wrote: > > Henri Sivonen 08-04-13 14.05: >> On Apr 13, 2008, at 14:15, Ben Boyle wrote: >> > Where does "conformance" fit in on the scale? >> >> It depends on what kind of conformance is meant. First, there's >> the question of conformance to what? To HTML5? To WCAG? Second, >> there's the issue that overall conformance criteria may have parts >> that are not machine checkable. >> > > And as you say below, HTML 5 has such criterias. > >> In theory, HTML5 conformance and HTML5 validity are the same thing. >> In practice, though, people tend to think that validity is what a >> validator checks, which is machine-checkable conformance criteria. >> > > Your product is called a conformance checker. So, I take it that you > are in doubt about whether it should actually be a conformance > checker, or if it should be a validity checker. And also it seems > that even if it will be a validity checker, you still consider > calling it a conformance checker. (Conformance to HTML 5, that is.) Conformance checker software is understood (or should be understood) to only check for machine-checkable conformance criteria. Quoting the spec draft: "Conformance checkers are exempt from detecting errors that require interpretation of the author's intent" The spec defines "HTML5 validator" to mean a conformance checker. The spec doesn't define 'validity' or 'valid', but it is assumed that a validator checks if a document is valid. >> Examples of non-machine-checkable conformance criteria: >> * "The img must not be used as a layout tool." (HTML 5) >> * "Authors must only use elements, attributes, and attribute >> values for their appropriate semantic purposes." (HTML 5) >> * "Content MUST NOT use a code point for any purpose other than >> that defined by its coded character set." (Charmod) >> * "Images of text are only used for pure decoration or where a >> particular presentation of text is essential to the information >> being conveyed." (WCAG 2.0 > > If we formalise that the first step of validation/conformance > checking, namely the checking of whether images have the correct alt > text and are used in the right way, if tables have summary, and so > on and so forth, as a step that must be done by the author/ > webmaster, then your product could be allowed to check only the more > formal points - An automated tool becomes less automated if it starts giving more and more messages of the nature "Please check yourself if you are violating rule foo here." If you take it to absurdity, the tool should ask the user to verify the semantic correctness of the use of each element and attribute. > Henri Sivonen 08-04-13 10.55: >> The syntax rules need to be lax enough for all kinds of sites to >> be able to comply. If all sites can't be accessible, too, then >> accessibility and syntactic correctness are different evaluation >> axes. >> > > Those are different evaluation axes. But experience has shown us > that the only validation that authors care about is the general CSS > and HTML stamps. Therefore, we must (continue to) incorporate social > consciousness into the general stamping tools. The validator I develop is not a stamping tool. It is a tool that helps authors detect mistakes that they didn't intend to make, so that they don't need to spend time wondering about the effects about their unintentional doings. For example, the validator I develop helps author detect that the alt attribute was typoed as 'atl', which is useful, because atl wouldn't work. > And also - and this goes against what you said in your rathole > letter: people tend to think that the HTML stamp actually also > incorporate some general accesibility checking, as it does check if > there is an alt and a summary etc. I have no interest in spreading claims that you get accessibility by syntactic correctness. > The W3 HTML checker has always done a small bit of accessiblity > checking , and that is part of why people want to check their pages > in that validator. To offer a checker as a same kind of prestiged > checker as the current W3 tool, without incorporating some basic > accessibility checking, would be a bit like stealing goodwill from a > wholly different kind of tool. I'm pretty sure I haven't advertised Validator.nu in a way that stole goodwill deceptively. Please let me know if you find bogus claims in Validator.nu documentation, UI or advertising. Unfortunately, I can't fully stop people from transferring bogus impressions created by others onto their preconceptions about Validator.nu. Aside: I'm not a big fan of "prestige", "gravitas" and words of that nature that keep popping up in accessibility debates where appeals to authority are made. > It was Anne, who in his blog once said those very wise words (quoted > from my mind) that "people are making XHTML pages thinking they are > making more accessible and semantic pages - though in reality both > etc are permitted in current XHTML". He is right, but this > also shows that people expect to be measured against a accessibility > and semantisism standard when they run their pages through the > validator mill. A validator cannot check that a page is semantically correct. It can't properly check for accessibility, either. We should dispel misconceptions about what validators do instead of catering to the misconceptions. > Btw, it strikes me that validation tools have two kinds of purposes: > One is acting as a formal stamp. The other is that they are > developement tools. I'm not interested in developing a formal stamp. I am interested in developing a development tool. > For the second, the "unready" stamp does not conflate those two > things. It helps keeping them apart. And allows an HTML 5 > conformance checker to give a definitive 'Yes', when the author has > done his part. And it raises the consciousness about the fact that > writing HTML documents is a process. Software can't give a definitive yes. I have made a specific effort in the UI and documentation of Validator.nu and any statements that might be considered advertising never to suggest that passing validation meant conforming to *all* conformance criteria there is. > Only the author can know if the document is ready - only he is in > charge of how the text needs to be "alt-ed". Right. > WCAG is a higher degree of accessibility checking. Given all the > things you say that a normal page maker never will do, how come you > think he/she will do WCAG cheking? I think the population of authors who will check their pages for WCAG conformance will be smaller than the population of authors that will check their pages for machine-checkable HTML5 syntactic conformance criteria. The reason why I think so is that checking for WCAG conformance requires human labor while checking for machine-checkable syntactic conformance criteria can be, by definition, automated. > Will you offer a direct link in your tool for running the page in a > WCAG checker, for instance? (That could be nice, regardless.) You really need a human to check for WCAG 2.0 conformance. I do intend to offer links to JSlint and the CSS validator, though. -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/ From lhs at malform.no Sun Apr 13 18:58:07 2008 From: lhs at malform.no (Leif Halvard Silli) Date: Mon, 14 Apr 2008 03:58:07 +0200 Subject: [html4all] several messages about alt In-Reply-To: References: <55687cf80804110123s69564fe4h2cd882e1733590f9@mail.gmail.com> <6BC82B20-F753-46F0-80B9-E53661B8C27E@iki.fi> <70F786EB-06B3-4761-80CC-B44EC73A8012@iki.fi> <5f37426b0804130415p2dc0503csc669bc4d90aa74a2@mail.gmail.com> <480227B1.20802@malform.no> Message-ID: <4802BA2F.2030009@malform.no> Henri Sivonen 08-04-13 20.57: ? > Apr 13, 2008, at 18:33, Leif Halvard Silli: >> If we formalise that the first step of validation/conformance >> checking, namely the checking of whether images have the correct alt >> text and are used in the right way, if tables have summary, and so on >> and so forth, as a step that must be done by the author/webmaster, >> then your product could be allowed to check only the more formal >> points - > > An automated tool becomes less automated if it starts giving more and > more messages of the nature "Please check yourself if you are > violating rule foo here." If you take it to absurdity, the tool should > ask the user to verify the semantic correctness of the use of each > element and attribute. Well, I thought about it this way: If the author has "stamped" it himself - with regard to the not machine-checable things, then the validator do not need to give all those messages that you mention. >> Henri Sivonen 08-04-13 10.55: > The validator Conformance checker, > I develop is not a stamping tool. [...] So no "Valid" icons from Validator.nu. >> The W3 HTML checker has always done a small bit of accessiblity >> checking , and that is part of why people want to check their pages >> in that validator. To offer a checker as a same kind of prestiged >> checker as the current W3 tool, without incorporating some basic >> accessibility checking, would be a bit like stealing goodwill from a >> wholly different kind of tool. > > I'm pretty sure I haven't advertised Validator.nu in a way that stole > goodwill deceptively. > > Please let me know if you find bogus claims in Validator.nu > documentation, UI or advertising. Unfortunately, I can't fully stop > people from transferring bogus impressions created by others onto > their preconceptions about Validator.nu. I guess I may have looked at it as "Validator 5". I now understand that it was never meant to be. However, I also understand/get the impression that you want your validator to be an example of what validator.w3.org should be. > Aside: I'm not a big fan of "prestige", "gravitas" and words of that > nature that keep popping up in accessibility debates where appeals to > authority are made. Did I refer to prestige as a kind of "appeal to authority"? Do you disagree in that Validator.w3.org has prestige? If you want, we can discuss whether it should have prestige, but that is another matter. My impression of my own argument was the complete opposite: We hear so much about cowpaths and what people generally do etc, so I thought I would allow myself the same kind of argument. It is very well, indeed, that you are accurate about what validator.nu checks for. My point was to say that people have expectations about what the W3 validator does. (And I shall to become more familiar with English jargong before you hear me use words like "gravitas" and other outlandish terms.) >> For the second, the "unready" stamp does not conflate those two >> things. It helps keeping them apart. And allows an HTML 5 conformance >> checker to give a definitive 'Yes', when the author has done his >> part. And it raises the consciousness about the fact that writing >> HTML documents is a process. > > Software can't give a definitive yes. Software is able to insert the word 'yes'. Or as you said yourself: "An automated tool becomes less automated if it starts giving more and more messages [...] -- leif halvard silli From lhs at malform.no Sun Apr 13 19:36:49 2008 From: lhs at malform.no (Leif Halvard Silli) Date: Mon, 14 Apr 2008 04:36:49 +0200 Subject: [html4all] several messages about alt In-Reply-To: References: <55687cf80804110123s69564fe4h2cd882e1733590f9@mail.gmail.com> <6BC82B20-F753-46F0-80B9-E53661B8C27E@iki.fi> <70F786EB-06B3-4761-80CC-B44EC73A8012@iki.fi> <5f37426b0804130415p2dc0503csc669bc4d90aa74a2@mail.gmail.com> <480227B1.20802@malform.no> Message-ID: <4802C341.40500@malform.no> Dannii 08-04-14 02.44: ? > On Mon, Apr 14, 2008 at 1:33 AM, Leif Halvard Silli > wrote: > > Those are different evaluation axes. But experience has shown us > that the only validation that authors care about is the general > CSS and HTML stamps. Therefore, we must (continue to) incorporate > social consciousness into the general stamping tools. > > ... > > The way I propose it, with some kind of "unready" stamp etc, > people will be allowed to cheat - just remove the 'unready' and do > the minimum thing with the alt attribtues - but they will also > then know that they are cheating. At the same time, what is > cheating? The author evalution always counts. > > > > As you say, most people generally only care about getting the tick of > approval, or in this case, validator images. This unready stamp > reminds me a lot of the transitional doctypes. The transitional > doctypes too were meant to be used by a small segment of the web that > were unable to completely fulfil the proper spec (ie, strict). In the > case of the transitional doctypes those pages were flawed using > presentational markup rather than inaccessible markup, but I think it > should still be a warning. The difference from "transitional" is that 'unready' should be something that is meant to be temporary, for each document. And not like the proposed WYSIWYG flag which, just as the trasinsitional types, are offered as a less strivt version of HTML. 'Unready' is mean to help the author reach the goal. It is not meant as an alternative goal. > Because the transitional doctypes were not used as intended. > > For an unready stamp to be successful I think all of the following > would need to be ensured. Can you provide any evidence they would be? > 1. It really would have to be used by only a small number of pages > 2. The public would have to continue seeing it as undesirable, rather > than accepting and even preferring it to the full spec. Even if the > validators gave warnings or errors those might soon be regarded as > flaws of the validator... for example, does anyone actually pay > attention to the CSS validator messages about not providing both fore > and background colours? The public would see it as undesirable because, as I said, a document with the 'unready' stamp should never be considered valid, even if otherwise is fully OK. > 3. People would actually need to work actively to fix pages with the > stamp. As long as validity and "stamping" are used as page developement tools, the I think it would. > 4. That the stamp wouldn't be used in more cases than intended. Yes > it's intended for CMS', but what's to stop it being used on any pages > where the author is too lazy to add alt attributes? Ok - I remember that in a debate at HTML4all.org, with and about Anne's blog, I referred to the DOCTYPE of a page there (I think it was that famouse time when he dropped that famous alt, because he could not find a good alt text for it). The DOCTYPE was HTML 4, but after I mentioned this, he changed it to . And thus suddenly my words lost all their power. :) Yes, if I staffed a page with the "unready" stamp, I could say to you, if you complained about the lack of ALT texts, that, sorry, the page is still being worked on. But also, just removing the unready stamp, would not make that page valid, unless it really was valid (in a machine checkable way - and in general). -- leif halvard silli From lhs at malform.no Sun Apr 13 21:16:42 2008 From: lhs at malform.no (Leif Halvard Silli) Date: Mon, 14 Apr 2008 06:16:42 +0200 Subject: [html4all] several messages about alt In-Reply-To: <12AE712A-B9C5-491F-B54C-5FC7A973D46E@w3.org> References: <55687cf80804110123s69564fe4h2cd882e1733590f9@mail.gmail.com> <6BC82B20-F753-46F0-80B9-E53661B8C27E@iki.fi> <70F786EB-06B3-4761-80CC-B44EC73A8012@iki.fi> <5f37426b0804130415p2dc0503csc669bc4d90aa74a2@mail.gmail.com> <480227B1.20802@malform.no> <4802C341.40500@malform.no> <12AE712A-B9C5-491F-B54C-5FC7A973D46E@w3.org> Message-ID: <4802DAAA.8050307@malform.no> Karl Dubost 08-04-14 04.55: ? > Le 14 avr. 2008 ? 11:36, Leif Halvard Silli a ?crit : >> The difference from "transitional" is that 'unready' should be >> something that is meant to be temporary, for each document. And not >> like the proposed WYSIWYG flag which, just as the trasinsitional >> types, are offered as a less strivt version of HTML. 'Unready' is >> mean to help the author reach the goal. It is not meant as an >> alternative goal. >> > "meant to be", "should", etc. > The issue is crippling into the language. "Transitional" is almost > never used as it was "meant to be", nor implemented in such a way to > help the transition. I guess it's a case of bad design choice, that > was difficult to know in advance that it would be. But we can try to > avoid repeating the same mistakes. However, you can validate a 'transitional' document. Wheras, it would be impossible to get a document stamped with 'unready' to validate.. (Allthough, you could of course validate = check it for errors.) Therefore, an 'unready' stamp, placed there by the author himself, would not be same thing. (Wheras a WYSIWYG stamp would be something of the same.) -- leif halvard silli From chaals at opera.com Sun Apr 13 23:49:54 2008 From: chaals at opera.com (Charles McCathieNevile) Date: Mon, 14 Apr 2008 08:49:54 +0200 Subject: [html4all] Unready and social engineering Re: several messages about alt In-Reply-To: References: <55687cf80804110123s69564fe4h2cd882e1733590f9@mail.gmail.com> <6BC82B20-F753-46F0-80B9-E53661B8C27E@iki.fi> <70F786EB-06B3-4761-80CC-B44EC73A8012@iki.fi> <5f37426b0804130415p2dc0503csc669bc4d90aa74a2@mail.gmail.com> <480227B1.20802@malform.no> Message-ID: On Mon, 14 Apr 2008 02:44:02 +0200, Dannii wrote: > On Mon, Apr 14, 2008 at 1:33 AM, Leif Halvard Silli > wrote: > >> Those are different evaluation axes. But experience has shown us that >> the only validation that authors care about is the general CSS and HTML >> stamps. Hmmm. Experience shows that there are people who care about other stamps, including accessibility ones. It also shows comprehensively that all of these together are still, with teh Web almost two decades old, things that only a small minority of developers care about. >> Therefore, we must (continue to) incorporate social consciousness into >> the general stamping tools. Henri and others have made it clear that they do not think the necessity for this is clearly established. So at the very least there is no consensus on this point. Personally I look at the question slightly differently. The HTML specification determines what needs to be done to make a document interoperable. For some known classes of users, interoperability relies on (and for some more classes is greatly improved by) being able to strip the document down to a non-graphic interpretation. This should be clarified by the specification. How that plays out in terms of what "validity" means is still an unanswered question - at least in the sense that we still appear to have violent disagreement in the working group on the issue (far more disagreement than with the principle that I stated above about non-graphic representation being necessary to interoperability, for example). ... > For an unready stamp to be successful I think all of the following would > need to be ensured. Can you provide any evidence they would be? > 1. It really would have to be used by only a small number of pages No, I don't see why this matters. Validating HTML is still a minority activity (very minority) and yet is clearly of value, or we wouldn't have this discussion. > 2. The public would have to continue seeing it as undesirable, rather > than accepting and even preferring it to the full spec. Even if the > validators gave warnings or errors those might soon be regarded as flaws > of the validator... for example, does anyone actually pay attention to > the CSS validator messages about not providing both fore and background > colours? Yes. Furthermore, do you have any evidence that people actively regard these warnings as bad? The fact that people often don't do what they consider to be "the right thing" accords well with everything we know about people, and the fact that sometimes they attempt to rationalise that by claiming that somehow "the right thing" isn't actually right does too. So the question boils down to evidence that the stamp is seen as a desirable thing overall. Anecdotally, validation of HTML is seen as a desirable thing, but is generally held as secondary in priority to pages actually working in browsers. For an example, see Ben Buchanan's discussion [1] of getting part of "The Australian" (a major Australian news site) to validate - and note that almost all of the site still doesn't, since it is more important that it actually work, and that is defined differently by the people responsible for the site. > 3. People would actually need to work actively to fix pages with the > stamp. I don't think this is the critical thing, I think that it is more important that what the stamp conveys is seen as something worth working towards. Which means you would expect an increase over time in the proportion of content that merits the stamp. The alt case may be instructive here. A decade ago, when WAI was first working, use of the alt attribute was far lower and far worse than it is today. The common response to the statement that things needed an alt attribute, then as now, was that this was unrealistic, or bad for [insert wierd edge case here], or unnecessary for [insert current draft's email/document case here - and discussion of it]. In the intervening decade, despite ongoing discussion about whether it is necessary, despite many development tool chains still making it very hard to achieve, and despite the fact that it can often seem like an acitvity with little real return, my observation is that the prevalence of alt attributes, and the quality of use, has increased massively. Again, this is anecdotal, based largely on the sites I use everyday or every month, but it really is a significant level of change. Almost none of those sites actually claim conformance to accessibility guidelines (and nor should they since the generally still have major problems) but they have all made substantial progress towards being able to do so. Additionally, the ability to provide alt has become far more widespread - although there are still glaring examples of failure in this area there are also far more tools that have improved their "level of conformance" to ATAG [1] and similar requirements. > 4. That the stamp wouldn't be used in more cases than intended. Yes it's > intended for CMS', but what's to stop it being used on any pages where > the author is too lazy to add alt attributes? Nothing - so we should be realistic about the use cases for any stamp, and reckon on the overall cost/benefit from this. Ian asked elsewhere what would be the benefit in making a private email between himself and his partner non-conforming, but equally it could be asked what possible benefit is tehre to them in knowing that their private email *is* conforming? In either case I suspect the answer is "none whatesoever", so looking at the cost becomes worthwhile... As a thought exercise, then, if we had such a stamp, what would be the drawback of extending its use from CMS' to any lazy author? Personally, I see none - and actually some benefits in doing so. I find it very difficult to understand why the current draft is prepared to allow some classes of tool to claim conformance while being second-rate. But this goes to the fact that a lot of the validation discussion is really about social engineering, and howto achieve an outcome that is desirable for technical reasons but cannot simply be specified into being... cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle fran?ais -- hablo espa?ol -- jeg l?rer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com From lhs at malform.no Mon Apr 14 00:14:33 2008 From: lhs at malform.no (Leif Halvard Silli) Date: Mon, 14 Apr 2008 09:14:33 +0200 Subject: [html4all] several messages about alt In-Reply-To: <7EDACA65-1D16-4744-8E82-2704CBF32182@w3.org> References: <55687cf80804110123s69564fe4h2cd882e1733590f9@mail.gmail.com> <6BC82B20-F753-46F0-80B9-E53661B8C27E@iki.fi> <70F786EB-06B3-4761-80CC-B44EC73A8012@iki.fi> <5f37426b0804130415p2dc0503csc669bc4d90aa74a2@mail.gmail.com> <480227B1.20802@malform.no> <4802BA2F.2030009@malform.no> <7EDACA65-1D16-4744-8E82-2704CBF32182@w3.org> Message-ID: <48030459.5090803@malform.no> Karl Dubost 2008-04-14 04.51: ? > Le 14 avr. 2008 ? 10:58, Leif Halvard Silli a ?crit : >> It is very well, indeed, that you are accurate about what >> validator.nu checks for. My point was to say that people have >> expectations about what the W3 validator does. >> [...]Different groups of People have sets of expectations about what >> the W3C validator does. [...] Certainly. But I was referring to expectations, based on experience about what the W3 validator does. If the W3 Validator would suddenly start dropping to check for @alt, then this would fool many. > There is also another issue which is the intersection of more or less > well defined specifications. For an example, XHTML 1.0 defines what is > a [*strict* conforming document][1]. But it doesn't define the > [conformance of multi-namespaces documents][2]. And in that regard: MathML has a required ALT attribute, for the elmement. It would be strange if there would be no checking for the @ALT on the HTML part of a document, while a full check on the MatML part. Btw, regarding what Henri said about stamping tools, stamping is not only about offering a badge to put on validated web sites: Ian Hickson 2008-04-11 00.11: [...] > On Tue, 24 Jan 2006, Henri Sivonen wrote: > >> > On Jan 23, 2006, at 18:43, dolphinling wrote: >> >>> > > Second, it could force authoring tools to produce invalid documents if >>> > > the author did not provide any alt text. However, those documents >>> > > would be non-conformant anyway, so this is not a huge problem. >>> >> > >> > It is. Authoring tools are judged by taking a page authored using the >> > tool and running it through the W3C Validator or, presumably in the >> > future, through an HTML5 conformance checker.Authoring tool makers who >> > are capable of making their tool produce syntactically conforming >> > documents will want to do so and minimize the chance that the users of >> > their software tarnish the reputation of the tool in the eyes of people >> > who use an automated test as a litmus test of authoring tool bogosity. >> > (People who test tools that way will outnumber the people who make a >> > more profound analysis due to the "validate, validate, validate" >> > propaganda.) >> > > Indeed. > The problem indeeded here is one of psychology. Sales psychology. Let's remove the requirement for checking if alt is used, so that we can prevent that the customer, he himself having forgotten to insert the alt, complains that the tool is producing invalid content. This is not about a rathole. It's about a hair in the soup. Design principles, 3.2. Priority of Constituencies: In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. [...] -- leif halvard silli From hsivonen at iki.fi Mon Apr 14 00:51:12 2008 From: hsivonen at iki.fi (Henri Sivonen) Date: Mon, 14 Apr 2008 10:51:12 +0300 Subject: [html4all] several messages about alt In-Reply-To: <4802BA2F.2030009@malform.no> References: <55687cf80804110123s69564fe4h2cd882e1733590f9@mail.gmail.com> <6BC82B20-F753-46F0-80B9-E53661B8C27E@iki.fi> <70F786EB-06B3-4761-80CC-B44EC73A8012@iki.fi> <5f37426b0804130415p2dc0503csc669bc4d90aa74a2@mail.gmail.com> <480227B1.20802@malform.no> <4802BA2F.2030009@malform.no> Message-ID: On Apr 14, 2008, at 04:58, Leif Halvard Silli wrote: > Henri Sivonen 08-04-13 20.57: >> Apr 13, 2008, at 18:33, Leif Halvard Silli: >>> If we formalise that the first step of validation/conformance >>> checking, namely the checking of whether images have the correct >>> alt text and are used in the right way, if tables have summary, >>> and so on and so forth, as a step that must be done by the author/ >>> webmaster, then your product could be allowed to check only the >>> more formal points - >> >> An automated tool becomes less automated if it starts giving more >> and more messages of the nature "Please check yourself if you are >> violating rule foo here." If you take it to absurdity, the tool >> should ask the user to verify the semantic correctness of the use >> of each element and attribute. > > Well, I thought about it this way: If the author has "stamped" it > himself - with regard to the not machine-checable things, then the > validator do not need to give all those messages that you mention. Do you mean you are arguing for validator pragmas that silence certain validator messages? (Note that semi-automated tools aren't useless, but they are different tools. A semi-automated tools could display each image and its alt side-by-side and ask the user to verify that the alternatives make sense.) > So no "Valid" icons from Validator.nu. Right. >>> The W3 HTML checker has always done a small bit of accessiblity >>> checking , and that is part of why people want to check their >>> pages in that validator. To offer a checker as a same kind of >>> prestiged checker as the current W3 tool, without incorporating >>> some basic accessibility checking, would be a bit like stealing >>> goodwill from a wholly different kind of tool. >> >> I'm pretty sure I haven't advertised Validator.nu in a way that >> stole goodwill deceptively. >> >> Please let me know if you find bogus claims in Validator.nu >> documentation, UI or advertising. Unfortunately, I can't fully stop >> people from transferring bogus impressions created by others onto >> their preconceptions about Validator.nu. > > I guess I may have looked at it as "Validator 5". I've called it "validation 2.0", but "5" is quite apt. :-) > I now understand that it was never meant to be. However, I also > understand/get the impression that you want your validator to be an > example of what validator.w3.org should be. Specifically, I think a validator should check for things that are machine checkable but go beyond a schema formalism, and I think handing out badges skews the motivations of users in such way that it is better not to hand out badges. So yes, I not only don't want Validator.nu to give out badges, but I think badge-focusedness is bad for validators in general. > It is very well, indeed, that you are accurate about what > validator.nu checks for. My point was to say that people have > expectations about what the W3 validator does. This is partly due to past advertising of the W3C Validator: http://www.w3.org/Bugs/Public/show_bug.cgi?id=1399 Let's try to focus on what these tools are good for instead of catering to old misconceptions about their capabilities. -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/ From joshue.oconnor at cfit.ie Mon Apr 14 00:58:03 2008 From: joshue.oconnor at cfit.ie (Joshue O Connor) Date: Mon, 14 Apr 2008 08:58:03 +0100 Subject: [html4all] several messages about alt In-Reply-To: References: <55687cf80804110123s69564fe4h2cd882e1733590f9@mail.gmail.com> <6BC82B20-F753-46F0-80B9-E53661B8C27E@iki.fi> <70F786EB-06B3-4761-80CC-B44EC73A8012@iki.fi> <5f37426b0804130415p2dc0503csc669bc4d90aa74a2@mail.gmail.com> <480227B1.20802@malform.no> Message-ID: <48030E8B.9020702@cfit.ie> Whatever the outcome from this debate, the collective goal is conformance to HTML 5, compliance with WCAG, improved accessibility and enhanced user experience. Currently there is a degree of dissonance between how individuals see each of these goals being reached and also at what node in this hierarchy each of these elements sit. FWIW I would put the last two at the top of this hierarchy and wish to note that the creation of accessible websites that are usable by a very wide audience, and can provide a positive user experience is possible without conformance or compliance to either. Josh From hsivonen at iki.fi Mon Apr 14 01:13:30 2008 From: hsivonen at iki.fi (Henri Sivonen) Date: Mon, 14 Apr 2008 11:13:30 +0300 Subject: [html4all] Unready and social engineering Re: several messages about alt In-Reply-To: References: <55687cf80804110123s69564fe4h2cd882e1733590f9@mail.gmail.com> <6BC82B20-F753-46F0-80B9-E53661B8C27E@iki.fi> <70F786EB-06B3-4761-80CC-B44EC73A8012@iki.fi> <5f37426b0804130415p2dc0503csc669bc4d90aa74a2@mail.gmail.com> <480227B1.20802@malform.no> Message-ID: <29D41A2E-8D9D-4074-8282-C030DEBF58A8@iki.fi> On Apr 14, 2008, at 09:49, Charles McCathieNevile wrote: > > On Mon, 14 Apr 2008 02:44:02 +0200, Dannii > wrote: > >> On Mon, Apr 14, 2008 at 1:33 AM, Leif Halvard Silli >> wrote: >> >>> Those are different evaluation axes. But experience has shown us >>> that the only validation that authors care about is the general >>> CSS and HTML stamps. > > Hmmm. Experience shows that there are people who care about other > stamps, including accessibility ones. It also shows comprehensively > that all of these together are still, with teh Web almost two > decades old, things that only a small minority of developers care > about. However, caring about getting a badge too often is caring about getting a badge--not caring about accessibility. Seeking to exploit people's desire to brag with a badge leads to them gaming a validator to get a badge (see A List Apart articles about custom DTDs, etc.). It doesn't magically make them author pages that are actually accessible. See also: http://www.cs.tut.fi/~jkorpela/html/validation.html#icon >>> Therefore, we must (continue to) incorporate social consciousness >>> into the general stamping tools. > > Henri and others have made it clear that they do not think the > necessity for this is clearly established. So at the very least > there is no consensus on this point. I try to be socially conscious about what kind of behaviors Validator.nu induces. In this case, I don't want it to induce information loss by people stuffing bogus placeholders into alt in order to silence the validator. After all, it is clear that requiring alt would induce that behavior. It isn't clear that syntactically requiring alt would cause people to write non-bogus alt text when they already wouldn't otherwise. And conversely, it's not like people who care about accessibility stopped caring about it if alt weren't a *syntactic* requirement. > Again, this is anecdotal, based largely on the sites I use everyday > or every month, but it really is a significant level of change. > Almost none of those sites actually claim conformance to > accessibility guidelines (and nor should they since the generally > still have major problems) but they have all made substantial > progress towards being able to do so. Additionally, the ability to > provide alt has become far more widespread - although there are > still glaring examples of failure in this area there are also far > more tools that have improved their "level of conformance" to ATAG > [1] and similar requirements. Did this change because accessibility advocates *talked to people* about why alt is needed or because validators whined at people about missing alt and stopped when *any* alt was provided? >> 4. That the stamp wouldn't be used in more cases than intended. Yes >> it's >> intended for CMS', but what's to stop it being used on any pages >> where the author is too lazy to add alt attributes? > > Nothing - so we should be realistic about the use cases for any > stamp, and reckon on the overall cost/benefit from this. Ian asked > elsewhere what would be the benefit in making a private email > between himself and his partner non-conforming, but equally it could > be asked what possible benefit is tehre to them in knowing that > their private email *is* conforming? In either case I suspect the > answer is "none whatesoever", so looking at the cost becomes > worthwhile... Validating the email you send isn't a particularly useful activity, but a email app vendor may still want their QA to check that the output of their program matches the spec. I think HTML should focus on Web pages, though. -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/ From chaals at opera.com Mon Apr 14 01:48:31 2008 From: chaals at opera.com (Charles McCathieNevile) Date: Mon, 14 Apr 2008 10:48:31 +0200 Subject: [html4all] Unready and social engineering Re: several messages about alt In-Reply-To: <29D41A2E-8D9D-4074-8282-C030DEBF58A8@iki.fi> References: <55687cf80804110123s69564fe4h2cd882e1733590f9@mail.gmail.com> <6BC82B20-F753-46F0-80B9-E53661B8C27E@iki.fi> <70F786EB-06B3-4761-80CC-B44EC73A8012@iki.fi> <5f37426b0804130415p2dc0503csc669bc4d90aa74a2@mail.gmail.com> <480227B1.20802@malform.no> <29D41A2E-8D9D-4074-8282-C030DEBF58A8@iki.fi> Message-ID: On Mon, 14 Apr 2008 10:13:30 +0200, Henri Sivonen wrote: > On Apr 14, 2008, at 09:49, Charles McCathieNevile wrote: >> >> On Mon, 14 Apr 2008 02:44:02 +0200, Dannii >> wrote: >> >>> On Mon, Apr 14, 2008 at 1:33 AM, Leif Halvard Silli >>> wrote: ... >> Hmmm. Experience shows that there are people who care about other >> stamps, including accessibility ones. It also shows comprehensively >> that all of these together are still, with teh Web almost two decades >> old, things that only a small minority of developers care about. > > However, caring about getting a badge too often is caring about getting > a badge--not caring about accessibility. Seeking to exploit people's > desire to brag with a badge leads to them gaming a validator... Indeed. > ... I don't want it to induce information loss by people stuffing bogus > placeholders into alt in order to silence the validator. After all, it > is clear that requiring alt would induce that behavior. It isn't clear > that syntactically requiring alt would cause people to write non-bogus > alt text when they already wouldn't otherwise. And conversely, it's not > like people who care about accessibility stopped caring about it if alt > weren't a *syntactic* requirement. Indeed. But none of these things happen all the time - so the big question is balancing the relative values to get the outcome that is most useful... >> [people got better at using alt] > Did this change because accessibility advocates *talked to people* about > why alt is needed or because validators whined at people about missing > alt and stopped when *any* alt was provided? remember that we're talking about anecdotal experience (and now about backing that up from working with developers), but the answer is that both things were actually very important - the validator effect increased the number of people who just did it right, and much further increased the number of people who did it but wrong, the talking to people (especially people who had already got enough of the message to do it wrong) was important in significantly raising the quality of what went into the attributes. (From an average level of "appalling" to "not very good", but when these things have a real impact on your life that is an important difference all the same). >> ... Ian asked elsewhere what would be the benefit in making a private >> email between himself and his partner non-conforming, but equally it >> could be asked what possible benefit is tehre to them in knowing that >> their private email *is* conforming? In either case I suspect the >> answer is "none whatesoever", so looking at the cost becomes >> worthwhile... > > Validating the email you send isn't a particularly useful activity, but > a email app vendor may still want their QA to check that the output of > their program matches the spec. Indeed. And should read the bits of the spec that are about quality (like using semantic elements) and figure out how to get those right. But experience suggests that hardly any email app vendor has done this so far. > I think HTML should focus on Web pages, though. Actually, email *is* an important use case for HTML, and should be considered. Perhaps doing so would be one step to getting an improvement in the quality of HTML produced by email apps at least to the level that has been achieved by mainstream web page editors. It won't be used all the time, but while some email is throwaway ephemera from one person to another, some email (like this one) is written in the knowledge that it is destined to become web content in its own right, available to anyone who happens to look at it. However, I think this is a seperate question. -- Charles McCathieNevile Opera Software, Standards Group je parle fran?ais -- hablo espa?ol -- jeg l?rer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com From joshue.oconnor at cfit.ie Mon Apr 14 02:41:03 2008 From: joshue.oconnor at cfit.ie (Joshue O Connor) Date: Mon, 14 Apr 2008 10:41:03 +0100 Subject: [html4all] Unready and social engineering Re: several messages about alt In-Reply-To: References: <55687cf80804110123s69564fe4h2cd882e1733590f9@mail.gmail.com> <6BC82B20-F753-46F0-80B9-E53661B8C27E@iki.fi> <70F786EB-06B3-4761-80CC-B44EC73A8012@iki.fi> <5f37426b0804130415p2dc0503csc669bc4d90aa74a2@mail.gmail.com> <480227B1.20802@malform.no> Message-ID: <480326AF.3020602@cfit.ie> **am v busy today so am replying briefly to some points, please forgive random presentation and apologies in advance if I quote anyone out of context** Charles McCathieNevile wrote: > The HTML > specification determines what needs to be done to make a document > interoperable. For some known classes of users, interoperability relies on > (and for some more classes is greatly improved by) being able to strip the > document down to a non-graphic interpretation. This should be clarified by > the specification. A happy by product of that would be elements whose relationships would be more programmatically determined, possibly improved semantic descriptions etc. This will of course enhance accessibility. Also as Chaals mentions validity is still only on the radar of a minority of developers but the *message* that validity is important and the tools such as validators have an impact on improving the web. Even thought the web is built on broken code. Also WCAG etc sets the *standard* by which accessibility compliance is judged, and of course many fall short but thats not so important as having a clear goal to aim for. This is a part of my concerns with @alt, how making it optional will be perceived, but I have said that before. Examples given such as the Inkblot tests are disingenuous, as I don't believe that images are indescribable and that should be a rational for not using @alt. However, there are cases where @alt just may not be needed at all. The issue is how this omission will be dealt with by UAs, the behaviour that the lack of @alt will trigger . So on one level this is a user agent issue. [1] > Henri Sivonen wrote: >> >> On Apr 14, 2008, at 09:49, Charles McCathieNevile wrote: >>> >>> On Mon, 14 Apr 2008 02:44:02 +0200, Dannii >>> wrote: >>> >>>> On Mon, Apr 14, 2008 at 1:33 AM, Leif Halvard Silli >>>> wrote: >>>> >>>>> Those are different evaluation axes. But experience has shown us >>>>> that the only validation that authors care about is the general CSS >>>>> and HTML stamps. >>> >>> Hmmm. Experience shows that there are people who care about other >>> stamps, including accessibility ones. It also shows comprehensively >>> that all of these together are still, with teh Web almost two decades >>> old, things that only a small minority of developers care about. >> >> However, caring about getting a badge too often is caring about getting >> a badge--not caring about accessibility. Seeking to exploit people's >> desire to brag with a badge leads to them gaming a validator to get a >> badge (see A List Apart articles about custom DTDs, etc.). It doesn't >> magically make them author pages that are actually accessible. It would be good if passing validation tests did equal accessible webpages but it doesn't. However it does show that if they are valid they are more likely to be accessible. As the tools advance this relationship may develop a greater correlation as opposed to validation being more of an outlier value. Cheers Josh [1] http://www.paciellogroup.com/resources/articles/altinhtml5.html#apply1 From lhs at malform.no Mon Apr 14 04:00:56 2008 From: lhs at malform.no (Leif Halvard Silli) Date: Mon, 14 Apr 2008 13:00:56 +0200 Subject: [html4all] several messages about alt In-Reply-To: References: <55687cf80804110123s69564fe4h2cd882e1733590f9@mail.gmail.com> <6BC82B20-F753-46F0-80B9-E53661B8C27E@iki.fi> <70F786EB-06B3-4761-80CC-B44EC73A8012@iki.fi> <5f37426b0804130415p2dc0503csc669bc4d90aa74a2@mail.gmail.com> <480227B1.20802@malform.no> <4802BA2F.2030009@malform.no> Message-ID: <48033968.4010902@malform.no> Henri Sivonen 08-04-14 09.51: ? > On Apr 14, 2008, at 04:58, Leif Halvard Silli wrote: >> Henri Sivonen 08-04-13 20.57: >>> Apr 13, 2008, at 18:33, Leif Halvard Silli: >>>> If we formalise that the first step of validation/conformance >>>> checking, namely the checking of whether images have the correct >>>> alt text and are used in the right way, if tables have summary, and >>>> so on and so forth, as a step that must be done by the >>>> author/webmaster, then your product could be allowed to check only >>>> the more formal points - >>> >>> An automated tool becomes less automated if it starts giving more >>> and more messages of the nature "Please check yourself if you are >>> violating rule foo here." If you take it to absurdity, the tool >>> should ask the user to verify the semantic correctness of the use of >>> each element and attribute. >> >> Well, I thought about it this way: If the author has "stamped" it >> himself - with regard to the not machine-checable things, then the >> validator do not need to give all those messages that you mention. > > Do you mean you are arguing for validator pragmas that silence certain > validator messages? > > (Note that semi-automated tools aren't useless, but they are different > tools. A semi-automated tools could display each image and its alt > side-by-side and ask the user to verify that the alternatives make > sense.) > I guess you could say I argued for a semiautomated tool. But at least I argue for a validation where the author becomes more "involved". One can have different opinions about it, but here in Norway, when companies are making their yearly report, they are also requested to report not only how they did economocally, but also what they did for certain goals that he society/politicians desires. And so, you must e.g. tell what you did for the equality of sexes within your company and so on. Doing it this way, regardless of whether it becomes automatic/a ritual only, has some effect ... -- leif halvard silli From laura.lee.carlson at gmail.com Mon Apr 14 05:33:18 2008 From: laura.lee.carlson at gmail.com (Laura Carlson) Date: Mon, 14 Apr 2008 07:33:18 -0500 Subject: [html4all] Unready and social engineering Re: several messages about alt In-Reply-To: <480326AF.3020602@cfit.ie> References: <55687cf80804110123s69564fe4h2cd882e1733590f9@mail.gmail.com> <6BC82B20-F753-46F0-80B9-E53661B8C27E@iki.fi> <70F786EB-06B3-4761-80CC-B44EC73A8012@iki.fi> <5f37426b0804130415p2dc0503csc669bc4d90aa74a2@mail.gmail.com> <480227B1.20802@malform.no> <480326AF.3020602@cfit.ie> Message-ID: <1c8dbcaa0804140533w7388ee4fu5ae6b20531d123fc@mail.gmail.com> Josh wrote: Also as Chaals mentions validity is still only on the radar of a > minority of developers but the *message* that validity is important > and the tools such as validators have an impact on improving the web. > Even thought the web is built on broken code. Also WCAG etc sets the > *standard* by which accessibility compliance is judged, and of course > many fall short but thats not so important as having a clear goal to > aim for. Exactly. The fact is the W3C validator is currently used as a web accessibility teaching tool. How do I know that? I know that because I have my students use it in the classes that I teach in order to flag missing alt. It is a first step in getting that important *message* across. One of their first lessons is to validate HTML on the W3C site to be sure that it is error-free and that they have indeed examined each alt. Best Regards, Laura From hsivonen at iki.fi Mon Apr 14 06:08:40 2008 From: hsivonen at iki.fi (Henri Sivonen) Date: Mon, 14 Apr 2008 16:08:40 +0300 Subject: [html4all] New issue: IMG section of HTML5 draft contradicts WCAG 1 & WCAG 2 (draft) In-Reply-To: <35C11FF1-B365-49E2-B036-12EFDD172D87@ieee.org> References: <55687cf80804110123s69564fe4h2cd882e1733590f9@mail.gmail.com> <1207927331.10875.109.camel@pav.lan> <35C11FF1-B365-49E2-B036-12EFDD172D87@ieee.org> Message-ID: On Apr 14, 2008, at 15:07, Al Gilman wrote: > By the continuity (minimize change) values of the HTML WG, it is the > change that must demonstrate necessity. I don't think the HTML WG has a 'minimize change' value in the conformance department. > So far nobody has demonstrated the necessity of making @alt optional. Saying 'nobody' is conveniently ignoring for example these two messages: http://lists.w3.org/Archives/Public/public-html/2008Apr/0273.html http://lists.w3.org/Archives/Public/public-html/2008Apr/0322.html In summary: Requiring alt to have a value when a proper value is not available leads to developers of HTML generators to put junk into the alt value when a proper value *is not available* to the software. Putting junk there is information loss compared to signaling the unavailability. Information loss is bad, because then UAs have less information to work with in order to function to the benefit of users. To avoid this badness, alt must be allowed to be absent when the piece of software that would generate it doesn't have the data that it should put there. (Insisting that a page not be generated at all when alternative text is not available is not realistic.) > Not changes from the HTML5 baseline, but changes from the testable > assertions that accessibility checkers as implemented now are coded > to check. That's what needs to bear the burden of proof. HTML 5 is not normative over products that purport to check documents for accessibility. Those products may check for assertions that aren't part of the syntax constraints of HTML5. (However, if those tools are used for mere badge hunting, they will induce bogus alt, too.) HTML 5 is normative over what byte streams are valid HTML5. This discussion is about whether a particular simplistic purported accessibility check should be baked into the concept of syntactic correctness of the HTML5 language. > Although user issues are to be given some preference over toolsmith > issues, the accessibility checker tools are still bona-fide > stakeholders. They aren't stakeholders here. HTML5 validators are. > So the previous input concluded that the draft should be fixed to > _keep_ it required until an alternate plan for providing the > information > required by WCAG is available, The whole point is that there are HTML generators that *do not have* the information that would be needed to generate a WCAG-compliant page because someone else did not provide it. Why require the impossible (generating a page with information that doesn't exist to the generator software)? Why not admit that HTML *syntax* and accessibility are different things and that some generators at least under some circumstances produce HTML that is syntactically correct (i.e. no typos in markup) but is not accessible for everyone? -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/ From hsivonen at iki.fi Mon Apr 14 06:50:13 2008 From: hsivonen at iki.fi (Henri Sivonen) Date: Mon, 14 Apr 2008 16:50:13 +0300 Subject: [html4all] Unready and social engineering Re: several messages about alt In-Reply-To: <1c8dbcaa0804140533w7388ee4fu5ae6b20531d123fc@mail.gmail.com> References: <55687cf80804110123s69564fe4h2cd882e1733590f9@mail.gmail.com> <6BC82B20-F753-46F0-80B9-E53661B8C27E@iki.fi> <70F786EB-06B3-4761-80CC-B44EC73A8012@iki.fi> <5f37426b0804130415p2dc0503csc669bc4d90aa74a2@mail.gmail.com> <480227B1.20802@malform.no> <480326AF.3020602@cfit.ie> <1c8dbcaa0804140533w7388ee4fu5ae6b20531d123fc@mail.gmail.com> Message-ID: <6405CAF3-0A07-4D08-82DC-7D365ED376F3@iki.fi> On Apr 14, 2008, at 15:33, Laura Carlson wrote: > The fact is the W3C validator is currently used as a web > accessibility teaching tool. > > How do I know that? I know that because I have my students use it in > the classes that I teach in order to flag missing alt. It is a first > step in getting that important *message* across If you are teaching them about writing alt text, using a suboptimal tool to find the missing alt instances is OK. (A proper tool for the purpose would be one that showed images and their alt text side by side for the evaluation of a sighted human operator, as it would let the human operator also check that the present alt text isn't bogus.) However, teaching that making a page validate makes it accessible is not true. And we should avoid getting that bogus message across even though that message would be simple and strong. -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/ From laura.lee.carlson at gmail.com Mon Apr 14 07:05:27 2008 From: laura.lee.carlson at gmail.com (Laura Carlson) Date: Mon, 14 Apr 2008 09:05:27 -0500 Subject: [html4all] Unready and social engineering Re: several messages about alt In-Reply-To: <6405CAF3-0A07-4D08-82DC-7D365ED376F3@iki.fi> References: <55687cf80804110123s69564fe4h2cd882e1733590f9@mail.gmail.com> <70F786EB-06B3-4761-80CC-B44EC73A8012@iki.fi> <5f37426b0804130415p2dc0503csc669bc4d90aa74a2@mail.gmail.com> <480227B1.20802@malform.no> <480326AF.3020602@cfit.ie> <1c8dbcaa0804140533w7388ee4fu5ae6b20531d123fc@mail.gmail.com> <6405CAF3-0A07-4D08-82DC-7D365ED376F3@iki.fi> Message-ID: <1c8dbcaa0804140705g14558394mdd4f6c9d781ec7fe@mail.gmail.com> Hi Henri, > If you are teaching them about writing alt text, using a suboptimal > tool to find the missing alt instances is OK. (A proper tool for the > purpose would be one that showed images and their alt text side by > side for the evaluation of a sighted human operator, as it would let > the human operator also check that the present alt text isn't bogus.) I assure you, they are introduced to an array of tools: http://www.d.umn.edu/itss/support/Training/Online/webdesign/tools.html > However, teaching that making a page validate makes it accessible is > not true. Completely agree with you. It is a *first step* in good authoring practice. Best regards, Laura From harry.loots at ieee.org Mon Apr 14 07:11:44 2008 From: harry.loots at ieee.org (Harry Loots) Date: Mon, 14 Apr 2008 15:11:44 +0100 Subject: [html4all] New issue: IMG section of HTML5 draft contradicts WCAG 1 & WCAG 2 (draft) In-Reply-To: References: <55687cf80804110123s69564fe4h2cd882e1733590f9@mail.gmail.com> <1207927331.10875.109.camel@pav.lan> <35C11FF1-B365-49E2-B036-12EFDD172D87@ieee.org> Message-ID: <20080414141144.M22050@ieee.org> Henri wrote > So far nobody has demonstrated the necessity of making @alt optional. Saying 'nobody' is conveniently ignoring for example these two messages: http://lists.w3.org/Archives/Public/public-html/2008Apr/0273.html http://lists.w3.org/Archives/Public/public-html/2008Apr/0322.html i hardly see why these two articles may be quoted as demonstrating why @alt should be optional? Unless the author thinks the opinion of one speaks for all? I remain firmly entrenched in the camp of _keeping_ @alt mandatory. In 1999 when WCAG was launched the use of validation tools was almost unheard of - even as recent as 3 or 4 years ago very few developers that i work with were bothered to validate X/HTML or check for WCAG compliance (i'm a specialist consultant and therefore come into contact with a large cross-section of the development community in our organisation). This picture has changed - the majority now regularly uses tools to check X/HTML validity and WCAG compliance. And some will no longer go without checking religiously! This is relevant to the argument only insofar as the mindset of the majority of developers have changed from optional to mandatory (and i'm referring to professionals, as opposed to someone who's setting up a photo album for the family to enjoy). But, so what if this someone leaves the alt out; and what if the software inserts alt="none supplied" or whatever pixels we wish it to push out... 'none supplied' is still more meaningful to a blind person than nothing at all - at least they will know there is an image; and may then ask a friend to explain its significance if they think it may be important. But no alt and no mention that there is an image means they they completly miss out on the fact that there is an image and the potentially important information contained in the image. Making @alt optional is giving in to those who are too ignorant, lazy or inconsiderate to supply an alt description and it seems to me that it is giving in to software makers who couldnt be bothered to add automated routines to push out pixels that says 'none supplied'. Regards Harry ~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~ We do not inherit the Earth from our Parents- We are simply Borrowing it from our Children! ~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~ From lhs at malform.no Mon Apr 14 07:57:55 2008 From: lhs at malform.no (Leif Halvard Silli) Date: Mon, 14 Apr 2008 16:57:55 +0200 Subject: [html4all] New issue: IMG section of HTML5 draft contradicts WCAG 1 & WCAG 2 (draft) In-Reply-To: References: <55687cf80804110123s69564fe4h2cd882e1733590f9@mail.gmail.com> <1207927331.10875.109.camel@pav.lan> <35C11FF1-B365-49E2-B036-12EFDD172D87@ieee.org> Message-ID: <480370F3.1070203@malform.no> Henri Sivonen 08-04-14 15.08: ? > On Apr 14, 2008, at 15:07, Al Gilman wrote: > ... > Putting junk > there is information loss compared to signaling the unavailability. > Information loss is bad, because then UAs have less information to > work with in order to function to the benefit of users. It is not only about loosing or gaining information, but also about usability. (If it ain't usable, then you can't use the possibly rich(er) information ...) The draft as it stands does not have any advices especially directed towards CMS-es and image sites etc. If we could move to discussing the right advices to give about how CMS-es should act, then I think it would be a step forward in the debate - and the spec. I would assume that if we actually gave ourselves that task, then we would easily be able to agree about at last *few cases where* an alt would be better than no alt. And thenafter, we could see wht to do with the rest. > > Not changes from the HTML5 baseline, but changes from the testable > > assertions that accessibility checkers as implemented now are coded > > to check. That's what needs to bear the burden of proof. > > HTML 5 is not normative over products that purport to check documents > for accessibility. Those products may check for assertions that aren't > part of the syntax constraints of HTML5. (However, if those tools are > used for mere badge hunting, they will induce bogus alt, too.) > "Look, no alt, but still valid" can also be a form of badge hunting. -- leif halvard silli From hsivonen at iki.fi Mon Apr 14 09:28:36 2008 From: hsivonen at iki.fi (Henri Sivonen) Date: Mon, 14 Apr 2008 19:28:36 +0300 Subject: [html4all] New issue: IMG section of HTML5 draft contradicts WCAG 1 & WCAG 2 (draft) In-Reply-To: <20080414141144.M22050@ieee.org> References: <55687cf80804110123s69564fe4h2cd882e1733590f9@mail.gmail.com> <1207927331.10875.109.camel@pav.lan> <35C11FF1-B365-49E2-B036-12EFDD172D87@ieee.org> <20080414141144.M22050@ieee.org> Message-ID: <1AB3E8FE-3200-473F-BA48-58FCDE712B49@iki.fi> On Apr 14, 2008, at 17:11, Harry Loots wrote: >> Henri wrote >>> So far nobody has demonstrated the necessity of making @alt >>> optional. >> >> Saying 'nobody' is conveniently ignoring for example these two >> messages: >> http://lists.w3.org/Archives/Public/public-html/2008Apr/0273.html >> http://lists.w3.org/Archives/Public/public-html/2008Apr/0322.html >> > i hardly see why these two articles may be quoted as demonstrating > why @alt > should be optional? Unless the author thinks the opinion of one > speaks for all? One is more than nobody. It would sure be convenient if one opinion spoke for all. :-) > I remain firmly entrenched in the camp of _keeping_ @alt mandatory. Would you still, if the leading HTML5 validator integrated an alt text and image review tool in addition to the validation function? (The tool would show the images from a Web pages in three categories: images with no textual alternative available, images marked as purely decorative and the rest with images and alternatives side-by-side.) I think developing such a tool would be the most productive way to move forward on this issue. However, such output would itself not have alternative text for the images available and would itself not be accessible to people who cannot review contents of bitmaps. It would be pretty ironic if the syntax definition of HTML5 prevented a validator with such a value-added feature from being self-validating. In general, I think getting better software written is more productive than being entrenched to the status quo. > This picture has changed - the majority now regularly uses tools to > check > X/HTML validity and WCAG compliance. And some will no longer go > without > checking religiously! I think it isn't healthy to position a validator as an object of religious worship. People shouldn't cause information loss to please the spirits of the validator, for example. You really need to be able to articulate the reasons for using a validators on their merits instead of making it matter of faith and dogma. > This is relevant to the argument only insofar as the mindset of the > majority > of developers have changed from optional to mandatory (and i'm > referring to > professionals, as opposed to someone who's setting up a photo album > for the > family to enjoy). Software used in a family setting is often written by professionals, though. Also, family photo albums are part of the Web, so HTML5 needs to cater for that use case among other things. > But, so what if this someone leaves the alt out; and what if > the software inserts alt="none supplied" or whatever pixels we wish > it to push > out... 'none supplied' is still more meaningful to a blind person > than nothing > at all - at least they will know there is an image; While I don't expect AT to become AI-complete, software can do better than conveying "none supplied" when none is supplied. (What I said above about getting better software written especially means not accepting the status quo of AT in general and JAWS in particular as something to get entrenched in.) -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/ From laura.lee.carlson at gmail.com Mon Apr 14 13:51:56 2008 From: laura.lee.carlson at gmail.com (Laura Carlson) Date: Mon, 14 Apr 2008 15:51:56 -0500 Subject: [html4all] Unready and social engineering Re: several messages about alt In-Reply-To: <1c8dbcaa0804140705g14558394mdd4f6c9d781ec7fe@mail.gmail.com> References: <55687cf80804110123s69564fe4h2cd882e1733590f9@mail.gmail.com> <5f37426b0804130415p2dc0503csc669bc4d90aa74a2@mail.gmail.com> <480227B1.20802@malform.no> <480326AF.3020602@cfit.ie> <1c8dbcaa0804140533w7388ee4fu5ae6b20531d123fc@mail.gmail.com> <6405CAF3-0A07-4D08-82DC-7D365ED376F3@iki.fi> <1c8dbcaa0804140705g14558394mdd4f6c9d781ec7fe@mail.gmail.com> Message-ID: <1c8dbcaa0804141351t5321618eo5aa725d6d1ae8575@mail.gmail.com> Hi Henri, > Completely agree with you. It is a *first step* in good authoring practice. This is one of the W3C pages that I refer people to where it is listed: http://www.w3.org/TR/WCAG/#validation Also more info that I have gathered on the subject over the years that may be helpful: http://www.d.umn.edu/itss/support/Training/Online/webdesign/accessibility.html#testingaccess http://www.d.umn.edu/itss/support/Training/Online/webdesign/standards.html#validation http://www.d.umn.edu/itss/support/Training/Online/webdesign/accessibility.html#checklists Best Regards, Laura -- Laura L. Carlson From foliot at wats.ca Mon Apr 14 16:23:36 2008 From: foliot at wats.ca (John Foliot) Date: Mon, 14 Apr 2008 16:23:36 -0700 Subject: [html4all] several messages about alt In-Reply-To: <70F786EB-06B3-4761-80CC-B44EC73A8012@iki.fi> Message-ID: <003301c89e86$961dc9c0$ae2e42ab@stanford.edu> Henri Sivonen wrote: > First, why do I even care to touch this rathole topic? It affects > directly how the product I develop is expected to behave, and that > affects its relationship with its users. > > Here's how I see this discussion: > > ...no matter how you try to spin it, in the real world, pushing > the pixels to the Web is the primary function--getting the alt text > out there is not the primary function And herein lies the flaw in your reasoning. Let's quote the "inventor" of the web as we have it today: "The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect." Yes, I know, over-quoted to the point of clich?. Here's some better ones though [source: http://www.brainyquote.com/quotes/authors/t/tim_bernerslee.html]: "I think IT projects are about supporting social systems-about communications between people and machines. They tend to fail due to cultural issues." "IT professionals have a responsibility to understand the use of standards and the importance of making Web applications that work with any kind of device." "The original idea of the Web was about supporting the way people already work socially, but this doesn't happen with a lot of IT projects." (maybe because the "social" aspect is missing? - JF) "The Web is now philosophical engineering. Physics and the Web are both about the relationship between the small and the large." "Whatever the device you use for getting your information out, it should be the same information." With all due respect Henri, I think I'll listen to TBL over you when it comes to understanding the web. Pushing pixels is the "how" part, but pushing information is the "what" part, and this is where the engineer driven opposition to a mandatory @alt comes from. It is analogous to saying that because not everyone uses seat-belts, car manufacturers should be allowed to make seat-belts optional on some cars. While on the surface that certainly stands up to a logic test, the reality is that it is not "right", which is why all cars today are sold with seatbelts. Whether or not *YOU* Henri wish to be part of a social engineering movement is not the point - it is incumbent on the next generation authoring language to accept that responsibility, warranted or wanted (or not). > 2) want (either directly themselves or as a client requirement) the > output of their software to be valid HTML (whatever that means) > 3) realize that there's no fundamental computer science barrier to > pushing around pixels without an accompanying string (hence the string > can be faked to accomplish #1 and #2 simultaneously) > Right, and still today many people refuse to wear their seatbelt, so car-makers should be able to argue that mandating seatbelts in all automobiles has not succeeded in the goal that it was set to accomplish? Thus, seatbelts should not be mandatory in automobiles... After all, cars still drive even if the seatbelt is not worn. Taking the analogy one step forward, I for one am not arguing that images without @alt not render... Heck there are enough broken web pages out there already, but what I do want is that @alt remain required, and if you don't provide it that glaring stupid blinking light on the dashboard that reminds me to buckle up continue to flash. Ignore it or not, that is the author's prerogative, but disabling the blinking dashboard light does absolutely nothing for anyone save the person who cannot be bothered to buckle up - blinking or not, the car still drives, but the blinking has an effect... Maybe someone will start to wear their seatbelt. > > Now, does the policy benefit the intended beneficiaries? It is clear > that the policy will lead to information loss or bogus information in > a non-trivial proportion of cases. This means that user agents have > less information to work with to benefit users. The harm part is > obvious on the surface given what we know about the consequences of > faking data when it is missing instead of signaling that it is > missing. This is why I continue to advocate for reserved values. They aren't "faked", they're known. Their real value remains minimal to users who require appropriate alternative text (not just the blind as Steven F has pointed out), however unlike "faked" values, reserved values can be accounted for by all class of users, and dealt with accordingly. Your checker can sniff the reserved values and know that the author has thought about the image (or not, but at least it conforms) whereas alt="" or no alt attribute at all is flagged as an error/warning. I would think that this would be a good thing for a testing tool (but I don't make testing tools - I work professionally in the field of web accessibility). > > As for "sending a strong message" while actually not benefitting the > supposed beneficiaries, I have no interest in becoming (through the > product I develop) a stooge for such a policy. Your personal views and desires should not count one iota in the development of both International specification and policy. The fact that you see advocating for a more accessible web ("sending a strong message") as being a "stooge" does little to instill confidence in your commitment to accessibility. > This is another reason > I care. Sending a strong message doesn't necessarily translate into > better accessibility. Consider: > http://www.nytimes.com/2008/01/20/magazine/20wwln-freak-t.html?_r=1&ex=13584 85200&en=0d05099c03c97375&ei=5090&partner=rssuserland&emc=rss&pagewanted=all &oref=slogin > This can be read two ways: consider the final line of your article - "Because if there is any law more powerful than the ones constructed in a place like Washington, it is the law of unintended consequences." It is the unintended consequences of making @alt optional that has not been fully thought through by those who seek only a technical purity, despite the obvious (to some) "social" need of the continued requirement of @alt _all-the-time_. Making @alt optional "some of the time" is akin to the article's reference to 'heter mechira': "This allowed for a Jew to temporarily ?sell? his land to a non-Jew and to continue farming it during the sabbatical year and then ?buy? it back immediately afterward ? a solution that helped the modern state of Israel keep its agricultural economy humming. ...And so this year, which happens to be a sabbatical year, the poorest Jews in Israel who wish to eat only food grown on non-Jewish land are left to buy imported goods at double or triple the regular price ? all in order to uphold a law meant to help feed the poorest Jews in Israel." The article actually defends the need to maintain the requirement of @alt (rather than the rare, 7th year-like instance of the photo upload site that users send 3,000 holiday pictures to) > > That question is a red herring. The right question is: What do you > expect a content management system to do when its user uploaded an > image but did not provide alternative text? And the follow-up: How is > your answer better that letting the CMS signal to the UA that it > doesn't have alternative text? (The simplest definition for such > signaling is the omission of the alt attribute.) But that only sends half a signal. Why or why not? With a reserved value of _notsupplied, you at least know why/why not, whereas with alt="" or even no alt value period, the user has *no* information, with no reasonable way of even attempting to find out. > > Suppose Anne hadn't written his CMS himself and I'm selling Anne a CMS > that I develop. What should I program the system to do when Anne > doesn't supply alternative text? (Also suppose that I still want to > extract a licensing or consulting fee from him.) Default to a reserved value. "_not supplied" might not be attractive, but it is accurate, and given that you are a smart fellow, your CMS will make it very simple for Anne or anyone else to provide better alternative text anyway. How "good" it will be may be open to debate, but at least you as a software developer have provided the means - the seatbelt of earlier - and most likely the blinking dashboard light too. Remember, it won't just be *your* CMS that needs to deal with this issue, it will be *ALL* CMSes, as the mandate to provide @alt is neither user-agent nor authoring tool specific - it cuts across all. > > What incentive does the developer of the conduit have to block what > you call sewage? Is that incentive stronger than whatever incentive > there is to let the "sewage" pass through? OK, Henri, I'll just toss my garbage out the window of my car... I mean, why not - there already is a ton of garbage on the roadside anyway. To quote Arlo Guthrie: "...we had never heard of a dump closed on Thanksgiving before, and with tears in our eyes we drove off into the sunset looking for another place to put the garbage. We didn't find one. Until we came to a side road, and off the side of the side road there was another fifteen foot cliff and at the bottom of the cliff there was another pile of garbage. And we decided that one big pile is better than two little piles, and rather than bring that one up we decided to throw our's down." (Great logic huh? For those unfamiliar with this ode, Arlo gets arrested for doing this) The "incentive" is doing the right thing, of building a better mouse-trap, of being both clever and smart (not always mutual) > > How is alt='_notsupplied' better than defining the absence of the > attribute to mean exactly what you would define alt='_notsupplied' to > mean? > > How is alt='_decorative' better than defining alt='' to mean exactly > what you would define alt='_decorative' to mean? Do I really need to explain reserved values to you? The whole point is that as "reserved" values, the *USER* can consistently define and have their user-agent announce/process it as whatever they want it to mean, and it will be consistent. Decorative is pretty self explanatory, whereas ' ' means what, exactly? Because _notsupplied means something, whereas _________ means just that - nothing - and further, no-one save the author him/herself has any idea of the intent of the image. With a common "" (null value) there is *NO* information supplied, whereas with reserved values there is some information provided. > > Ah. This is how it is supposed to be better. Agreed it is marginally better, but yes, in fact. Providing *NO INFORMATION* is the worst of any/all possibilities. > > Frankly, I think you are now at the point where you are vehemently > clinging onto a bad policy and amending it with worse and worse > additional rules in order to avoid re-examining whether the need of > the amendments should be taken as an indication that the base policy > needs adjustment. I don't know a name for this phenomenon, but others > shouldn't play along to save you from re-examining the policy. Well Henri, you are entitled to your opinion, but the fact of the matter is that others *are* chiming in and arguing against a bad decision (in our opinions) re @alt being optional. Some even support my idea: Christophe Strobbe wrote: > > If HTML 5 were to specify certain values (e.g. "_notsupplied" and > "_decorative") that would need to be used when real text alternative > cannot be provided (as John Foliot proposed at > and > ), > these values could be a technique to meet the last item of success > criterion 1.1 of WCAG 2.0 > ( in > the current draft): > "If it [= non-text content] is pure decoration, or used only for > visual formatting, or if it is not presented to users, then it is > implemented in a way that it can be ignored by assistive technology." > > This would not "require the impossible". It would allow us to keep > the alt attribute as a required attribute in HTML 5, and allow sites > with file upload functions to meet success criterion 1.1 of WCAG 2.0. ... while others are seeking guidance from other W3C working groups: [conf] wrote: > I think that the AUWG and UAWG folks are the experts in this area who > could provide real insight to this possible solution or another like > it. We need to ask them for their advice. Now I don't claim to have a lock on the right answer, however I have put forward proposals (that I believe are constructive in nature) that potentially enhance @alt at the same time allowing to continue to insist that @alt be mandatory. You just keep arguing that we are wrong. > > As for making laws that people break, it is corrosive (to use Lessig's > vocabulary) to society to have laws that normal people are in > violation of in their daily lives. This is why prohibition and laws > like the DMCA/EUCD are bad as they turn normal people into law- > breakers and makes them really cynical about law in general thereby > devaluing laws in general. > > Likewise, a validity rule that normal Web developers would game in > their daily development activities devalues validator messages. But what exactly are you trying to test for? Pixel pushing or information conveyance? If all you want to do is push pixels, you are missing so much of the big picture as to be frightening. > > An HTML5 validator isn't an accessibility evaluation tool--or at least > I think it shouldn't be. An HTML5 validator is just a spell checker > for the benefit of markup writers so that they can identify typos and > typo-like mistakes instead of having to figure out why a counter- > intuitive error handling mechanism kicks in when they test in > browsers. A spell checker doesn't tell you if your fiction writing is > entertaining or non-fiction actually factual. Those are different > evaluation axes. Most good spell checkers also offer proposed alternative spellings - they aren't just reactive, they are proactive. So an evaluator that sniffs a graphic with no alt value should suggest some form of repair (just like most spell checkers), rather than just say oops, you made a mistake (or the even easier - hey, it's allowed). It has nothing to do with fiction or non-fiction, but rather to do with rite/write/right. JF From hsivonen at iki.fi Tue Apr 15 00:46:25 2008 From: hsivonen at iki.fi (Henri Sivonen) Date: Tue, 15 Apr 2008 10:46:25 +0300 Subject: [html4all] several messages about alt In-Reply-To: <003301c89e86$961dc9c0$ae2e42ab@stanford.edu> References: <003301c89e86$961dc9c0$ae2e42ab@stanford.edu> Message-ID: <1AD46C0E-64D9-432C-A4BE-2663641014DE@iki.fi> On Apr 15, 2008, at 02:23, John Foliot wrote: > Henri Sivonen wrote: >> ...no matter how you try to spin it, in the real world, pushing >> the pixels to the Web is the primary function--getting the alt text >> out there is not the primary function > > And herein lies the flaw in your reasoning. I think it isn't worthwhile for me to address your other points when it seems you don't believe that the primary functions on a camera and a photo hosting service are capturing pixels and hosting them respectively. As for social engineering, if you cannot acknowledge what the people whose behavior you are trying to modify are seeking to do without your intervention, you can't develop successful social engineering strategies except by accident. -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/ From harry.loots at ieee.org Tue Apr 15 01:25:09 2008 From: harry.loots at ieee.org (Harry Loots) Date: Tue, 15 Apr 2008 09:25:09 +0100 Subject: [html4all] New issue: IMG section of HTML5 draft contradicts WCAG 1 & WCAG 2 (draft) In-Reply-To: <1AB3E8FE-3200-473F-BA48-58FCDE712B49@iki.fi> References: <55687cf80804110123s69564fe4h2cd882e1733590f9@mail.gmail.com> <1207927331.10875.109.camel@pav.lan> <35C11FF1-B365-49E2-B036-12EFDD172D87@ieee.org> <20080414141144.M22050@ieee.org> <1AB3E8FE-3200-473F-BA48-58FCDE712B49@iki.fi> Message-ID: <20080415082509.M56706@ieee.org> Henri > > checking religiously! > > I think it isn't healthy to position a validator as an object of > religious worship. People shouldn't cause information loss to please > the spirits of the validator, for example. You really need to be > able to articulate the reasons for using a validators on their > merits instead of making it matter of faith and dogma. The term 'religiously' refers to checking without fail, or faithfully ;) nothing more and nothing less. Regards Harry ~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~ We do not inherit the Earth from our Parents- We are simply Borrowing it from our Children! ~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~ From hsivonen at iki.fi Tue Apr 15 04:03:15 2008 From: hsivonen at iki.fi (Henri Sivonen) Date: Tue, 15 Apr 2008 14:03:15 +0300 Subject: [html4all] img/alt summary attempt In-Reply-To: References: Message-ID: On Apr 14, 2008, at 20:48, Jim Jewett wrote: > -- Note -- HTML5 expands the use of LEGEND -- there may be cases where > alt is not useful *because* it is redundant with LEGEND. This case > may not be covered in current WCAG Recommendations. Also note -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/ From hsivonen at iki.fi Tue Apr 15 06:06:31 2008 From: hsivonen at iki.fi (Henri Sivonen) Date: Tue, 15 Apr 2008 16:06:31 +0300 Subject: [html4all] img/alt summary attempt In-Reply-To: <002a01c89ef5$ab6fb4e0$0901a8c0@HANDS> References: <002a01c89ef5$ab6fb4e0$0901a8c0@HANDS> Message-ID: <87C79D11-0B3C-44F7-83F2-7FAF3F15F63A@iki.fi> On Apr 15, 2008, at 15:38, David Poehlman wrote: > described by is not equivalent and I believe this point has already > been > made. Legend if used properly is not equivalent either. Right. Describedby, alt, title and legend of surrounding figure aren't exactly the same concept. They are in the same ballpark, though. When there are four concepts that are close to each other, two questions arise: 1) How should authors assess the necessity and usefulness of each of these concepts in a given authoring situation? 2) How are user agents expected to convey the subtleties in difference of concept and handle the presence of different data in different cases in a smooth way? Does at least one plausible UI design exist? -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/ From joshue.oconnor at cfit.ie Tue Apr 15 07:12:58 2008 From: joshue.oconnor at cfit.ie (Joshue O Connor) Date: Tue, 15 Apr 2008 15:12:58 +0100 Subject: [html4all] img/alt summary attempt In-Reply-To: <87C79D11-0B3C-44F7-83F2-7FAF3F15F63A@iki.fi> References: <002a01c89ef5$ab6fb4e0$0901a8c0@HANDS> <87C79D11-0B3C-44F7-83F2-7FAF3F15F63A@iki.fi> Message-ID: <4804B7EA.60303@cfit.ie> Henri Sivonen wrote: > 1) How should authors assess the necessity and usefulness of each of > these concepts in a given authoring situation? By informing themselves of how user agents will handle each of them in practice. How the spec says they should be used is one thing and how vendors choose to apply a specification is another. So for example by understanding how a screen reader user may deal with @alt contents, or how useful the title element is to a screen reader user, the author is in a better position to make a judgement call on how they should be applied in any given situation. Of course these are examples that relate to assistive technology but correct use of @alt and a good title element can have an impact in other domains such as SEO. There are also a wider variety of UAs to consider, but the principle is the same. How will the UA deal with this code and how will this then be of value to the end user. The world of web development is full of adjusting to these kinds of behaviours. Josh From vlad.alexander at xstandard.com Tue Apr 15 09:58:10 2008 From: vlad.alexander at xstandard.com (Vlad Alexander (XStandard)) Date: Tue, 15 Apr 2008 12:58:10 -0400 Subject: [html4all] alt issue: image uploaded in bulk are not Web content Message-ID: I think my point in a previous email may have been too subtle. Images uploaded in bulk, through a camera (or FTP), are not _Web content_. They are just files which a Web application may use to decorate a Web page. These images are no different than Word documents or TIFF files uploaded via FTP. All that has happened is that non-HTML files have been uploaded in bulk, no content has been authored here! Since there files (images) are not Web content, the Web application should generate the img element with alt="". Regards, -Vlad http://xstandard.com From P.Taylor at Rhul.Ac.Uk Tue Apr 15 09:55:15 2008 From: P.Taylor at Rhul.Ac.Uk (Philip Taylor (Webmaster, Ret'd)) Date: Tue, 15 Apr 2008 17:55:15 +0100 Subject: [html4all] alt issue: image uploaded in bulk are not Web content In-Reply-To: References: Message-ID: <4804DDF3.9030300@Rhul.Ac.Uk> I am afraid that I think you are still being too subtle (for me) : what is the basis for your assertion that "Images uploaded in bulk, through a camera (or FTP), are not Web content", onced those images have been incorporated into (more precisely, referenced from) a web page ? ** Phil. -------- Vlad Alexander (XStandard) wrote: > I think my point in a previous email may have been too subtle. Images uploaded in bulk, through a camera (or FTP), are not _Web content_. They are just files which a Web application may use to decorate a Web page. These images are no different than Word documents or TIFF files uploaded via FTP. > > All that has happened is that non-HTML files have been uploaded in bulk, no content has been authored here! > > Since there files (images) are not Web content, the Web application should generate the img element with alt="". > > Regards, > -Vlad > http://xstandard.com > > > > _______________________________________________ > List_HTML4all.org mailing list > http://www.html4all.org/wiki From vlad.alexander at xstandard.com Tue Apr 15 10:36:09 2008 From: vlad.alexander at xstandard.com (Vlad Alexander (XStandard)) Date: Tue, 15 Apr 2008 13:36:09 -0400 Subject: [html4all] alt issue: image uploaded in bulk are not Web content Message-ID: <35kfolj3y3wi2uu.150420081336@pinscher> Hi Phil, What is the difference between uploading a 1000 JPEG files versus 1000 TIFF files? What makes JPEG files content? >what is the basis for your assertion ... Content must be authored. When a person uploads images in bulk, no content is authored. All that is happening is a Web application is displaying different decorative images through a template. Regards, -Vlad http://xstandard.com -------- Original Message -------- From: Philip Taylor (Webmaster, Ret'd) Date: 2008-04-15 12:55 PM > I am afraid that I think you are still being > too subtle (for me) : what is the basis for > your assertion that "Images uploaded in bulk, > through a camera (or FTP), are not Web content", > onced those images have been incorporated > into (more precisely, referenced from) > a web page ? > > ** Phil. > -------- > Vlad Alexander (XStandard) wrote: >> I think my point in a previous email may have been too subtle. Images uploaded in bulk, through a camera (or FTP), are not _Web content_. They are just files which a Web application may use to decorate a Web page. These images are no different than Word documents or TIFF files uploaded via FTP. >> >> All that has happened is that non-HTML files have been uploaded in bulk, no content has been authored here! >> >> Since there files (images) are not Web content, the Web application should generate the img element with alt="". >> >> Regards, >> -Vlad >> http://xstandard.com >> >> >> >> _______________________________________________ >> List_HTML4all.org mailing list >> http://www.html4all.org/wiki > > _______________________________________________ > List_HTML4all.org mailing list > http://www.html4all.org/wiki > From P.Taylor at Rhul.Ac.Uk Tue Apr 15 10:43:19 2008 From: P.Taylor at Rhul.Ac.Uk (Philip Taylor (Webmaster, Ret'd)) Date: Tue, 15 Apr 2008 18:43:19 +0100 Subject: [html4all] alt issue: image uploaded in bulk are not Web content In-Reply-To: <35kfolj3y3wi2uu.150420081336@pinscher> References: <35kfolj3y3wi2uu.150420081336@pinscher> Message-ID: <4804E937.9060400@Rhul.Ac.Uk> Vlad Alexander (XStandard) wrote: > Hi Phil, > > What is the difference between uploading a 1000 JPEG files versus 1000 TIFF files? Little, though the former could be intended to be rendered by an unaugmented browser whilst the latter could not ... What makes JPEG files content? Their incorporation into a web page. > >> what is the basis for your assertion ... > Content must be authored. When a person uploads images in bulk, no content is authored. Agreed. All that is happening is a Web application is displaying different decorative images through a template. No, that is your interpretation : I can see no basis for your claim that an image becomes "decorative" simply because it was uploaded at the same time as several (or many) others ... ** Phil. From vlad.alexander at xstandard.com Tue Apr 15 11:14:23 2008 From: vlad.alexander at xstandard.com (Vlad Alexander (XStandard)) Date: Tue, 15 Apr 2008 14:14:23 -0400 Subject: [html4all] alt issue: image uploaded in bulk are not Web content Message-ID: <5ounc6nhdbui0j8.150420081414@pinscher> For an image to be non-decorative, content must be authored. Since we agree that the act of bulk upload does not author content, therefore these images are decorative. >> What makes JPEG files content? > Their incorporation into a web page. Decorative images are also incorporated into a Web page, but decorative images are not content. Regards, -Vlad http://xstandard.com -------- Original Message -------- From: Philip Taylor (Webmaster, Ret'd) Date: 2008-04-15 1:43 PM > > Vlad Alexander (XStandard) wrote: >> Hi Phil, >> >> What is the difference between uploading a 1000 JPEG files versus 1000 TIFF files? > > Little, though the former could be intended > to be rendered by an unaugmented browser whilst > the latter could not ... > > What makes JPEG files content? > > Their incorporation into a web page. >>> what is the basis for your assertion ... >> Content must be authored. When a person uploads images in bulk, no content is authored. > > Agreed. > > All that is happening is a Web application is displaying different decorative images through a template. > > No, that is your interpretation : I can see no > basis for your claim that an image becomes > "decorative" simply because it was uploaded > at the same time as several (or many) others ... > > ** Phil. > > _______________________________________________ > List_HTML4all.org mailing list > http://www.html4all.org/wiki > From foliot at wats.ca Tue Apr 15 11:48:19 2008 From: foliot at wats.ca (John Foliot) Date: Tue, 15 Apr 2008 11:48:19 -0700 Subject: [html4all] Request for review of alt and alt value for authoring or publishing tools In-Reply-To: Message-ID: <006101c89f29$470c67d0$cf2a42ab@stanford.edu> Ian Hickson wrote: > The only actual solution suggestion I see there is alt="1", alt="2", > etc, > but it is unclear how that would improve accessibility. Any information is better than no information. It puts the images in a rudimentary context (this is image 4 of 9 on the page). A non-visual user still may have no idea what the image really is, but can be told that image number 4 at the "photo-upload site" is of their grandchild, and they could then copy the file to a flash drive, and have the photo printed and framed for when visitors come over to visit (just to make the scenario "real"). > > Note that in many of these cases, putting the caption or other > metadata in > the alt="" attribute would be harmful as it would merely duplicate > information already available elsewhere on the page. (I mention this > merely because WCAG does currently suggest giving such text in some > cases, > but this doesn't help when such text is already available outside of > the element.)

I snapped this photo the other day while walking around the Googleplex and saw Ian Hickson working at his desk.
(slightly modified from an actual Flickr page) ...is the image the Googleplex, or you working at your desk? JF From foliot at wats.ca Tue Apr 15 11:58:54 2008 From: foliot at wats.ca (John Foliot) Date: Tue, 15 Apr 2008 11:58:54 -0700 Subject: [html4all] The Philosophy of @alt (was several messages about alt) In-Reply-To: <1AD46C0E-64D9-432C-A4BE-2663641014DE@iki.fi> Message-ID: <006201c89f2a$c197e820$cf2a42ab@stanford.edu> Henri Sivonen wrote: > > I think it isn't worthwhile for me to address your other points when > it seems you don't believe that the primary functions on a camera and > a photo hosting service are capturing pixels and hosting them > respectively. I accept that. This however is a re-direct on your part that skirts the real issue. Those images are not presented in a vacuum - they use HTML as a binder to gather and present the files as web content. If all you want is an FTP link for people to look at pictures then we have no debate: present your tree view of the FTP directory complete with cryptic file name(s) and browse away (there's a paved cowpath for you). But that's not what the majority want either. The moment you add the additional layer of the HTML container, then we are talking about a different beast altogether, as you are seeking to make those cryptic file names meaningful to those who can visualize (the majority) by adding essentially a GUI interface - yet the current proposal says "Pfttt..." to those who cannot work with a GUI interface (the minority), and who instead require semantic logic and structured, complete disclosure of information. The current proposal of optional @alt suggests that "cryptic file names" or worse *NO INFORMATION* should be deemed acceptable to some users, simply because the majority *might* not provide such, and that automated systems should not take some responsibility for providing any kind of information. It suggests that somehow the very same genius engineers/developers who will unveil heuristic image analysis some day in the future cannot figure out a better solution than making an established convention today optional moving forward. > > As for social engineering, if you cannot acknowledge what the people > whose behavior you are trying to modify are seeking to do without your > intervention, you can't develop successful social engineering > strategies except by accident. Whereas you cannot come to terms with the fact that if you cannot or do not seek to change peoples behaviour, and in fact remove any moral or social pressure to do so, that change will *never* happen. Throughout the majority of the 20th century, most people saw cigarette smoking not only as socially acceptable (movies, television), but even "normal", "sexy" (Marlboro Man) or "cool" (Joe Camel) - that's the way it was, and using the paved cowpath logic, that's the way it should have stayed. Times have changed though, albeit slowly, and there is still resistance today from some people who do not want to quit smoking, and the pipeline continues to be filled with new, young smokers, despite the overwhelming evidence that now shows smoking is bad for you. What really do you not understand about social engineering? You cannot change everyone's thinking, especially over-night, yet societally speaking smoking is no longer considered "normal" or acceptable, and those who continue to do so are now ostracized by "rules" that infuriate some (as they stand huddled 10 meters away from the building entrance at "break time"), but have - over time - created the climate where the greater goal/benefit is beginning to emerge (and it warrants mentioning that this change has taken longer than 10 years - far longer than the popularization of the world wide web). Restaurants no longer have ash-trays, newlyweds no longer order embossed matchbooks, new cars do not have ashtrays or cigarette lighters, etc. etc. You don't just throw up your hands and say "...oh well, some people will never stop smoking, so let's stop trying." ("...oh well, some content authors will never bother to add alternative text, so let's just make it optional sometimes.") It is now 'against the rules/non-conformant' to smoke in restaurants, and doing so has consequences - oh physically you can, but socially you cannot. Should social engineers stop trying to get people to quit smoking, even when it is clear that for some smokers, they do not want to be told that smoking is bad? Sure, we will continue to get some bad alt text (some people who quit smoking start up again), but gradually the pendulum swings to where we want it, and suggesting to make @alt optional in the future disrupts the progress that has been made to date. You overlook the context of time. JF From foliot at wats.ca Tue Apr 15 12:42:57 2008 From: foliot at wats.ca (John Foliot) Date: Tue, 15 Apr 2008 12:42:57 -0700 Subject: [html4all] Request for review of alt and alt value for authoring or publishing tools In-Reply-To: Message-ID: <006601c89f30$e92aec10$cf2a42ab@stanford.edu> Ian Hickson wrote: >> >> The same would be true if the AT involved simply read out the >> filename, as some of them do in absence of an alt-Attribute. > > Indeed the AT itself could read out the "1 of 4" thing -- and at least > then there would be a reasonably good chance of the numbering being > correct, which would not be the case if we relied on the author. :-) But this is not the case being suggested in the draft spec. To whit, the draft suggests that a user employing an automated system to up-load 3000 vacation photos cannot or will not supply alternative text, and the spec suggests that the automated system be excused from attempting to improve this. Some suggestions have emerged, the least helpful from an accessibility perspective is providing *nothing* by making the alt attribute optional. I argue that there is some responsibility for the tool (web-app) to play a role (one of the reasons why a request has gone out to the AUWG and UAWG folks at W3C), and that one way of ensuring that tools assume their responsibility in the equation is to insist that some alternative text be provided to be "conformant" - it places a burden of effort upon them to facilitate the addition of alternative text to images. Henri S. has classified this as possibly being "faked" content, without stopping to think if there is a way to minimize the amount of faked or spurious alternative text being generated; I continue to advocate reserved values in lieu of any other suggestion, but curiously await feedback from the afore-mentioned W3C working groups. JF From P.Taylor at Rhul.Ac.Uk Tue Apr 15 13:39:48 2008 From: P.Taylor at Rhul.Ac.Uk (Philip Taylor (Webmaster, Ret'd)) Date: Tue, 15 Apr 2008 21:39:48 +0100 Subject: [html4all] alt issue: image uploaded in bulk are not Web content In-Reply-To: <5ounc6nhdbui0j8.150420081414@pinscher> References: <5ounc6nhdbui0j8.150420081414@pinscher> Message-ID: <48051294.4010006@Rhul.Ac.Uk> Vlad Alexander (XStandard) wrote: > For an image to be non-decorative, content must be authored. Since we agree that the act of bulk upload does not author content, therefore these images are decorative. No, they may be /regarded/ as decorative (by you, if not by everyone) until such time as they are incorporated into a web page; once they form a part of a web page, they may or may not "be decorative", depending on the author's intentions,but that choice must be made regardless of whether the author chooses to upload one, or one million, images. Thus the act of mass uploading does not, of itself, create a set of images that are decorative. > >>> What makes JPEG files content? >> Their incorporation into a web page. > Decorative images are also incorporated into a Web page, but decorative images are not content. Agreed. ** Phil. From foliot at wats.ca Tue Apr 15 13:44:10 2008 From: foliot at wats.ca (John Foliot) Date: Tue, 15 Apr 2008 13:44:10 -0700 Subject: [html4all] Request for review of alt and alt value for authoring or publishing tools In-Reply-To: Message-ID: <007101c89f39$7604afb0$cf2a42ab@stanford.edu> Ian Hickson wrote: > > Right, because the UA/AT is in a much better place to know how to > help the user in these cases. The idea here is to help the user. Then start by giving the user something that their AT can work with. You are handing them a vacuum and saying figure it out. Ian, there is a picture on my desk, what is it of? You are asking AT to play "Is it bigger than a breadbox" and then not answering any of the questions. The current spec goes to great lengths explaining to authors on how to do many, many things (and if I've never formally gone on record as acknowledging this strength, I will do so now - take the compliment Ian). But in this particular case, the spec is excusing a key player (the authoring tool/web-app) from it's role in ensuring that the playing field remain level. You are saying "we can't come up with a solution, so AT needs to do so" while at the same time giving AT *absolutely* nothing to work with. > We > can get better accessibility by letting user agents compete on best > handling of these images than we can by letting servers, who have > near zero motivation to address this issue, try to come up with some > half-baked solution. But if the servers *must* provide part of the solution (to be "conformant" servers) you have given them the motivation. Besides, it's not the server, it's the 'web-app' running on the server. Flickr and Photobucket use servers to deliver content, and it's the content we are focusing on here, not the machines. > > Reserved values are just syntactic variants on omitting the attribute. > There is no practical difference. (Well, other than reserved values > being significantly less usable in today's UAs, and omitting the > alt="" attribute being cleaner, which is why the spec says to omit > the attribute instead of inventing some new reserved value.) Yes and no. Reserved values can be programmatically assigned whatever values/uses a user-agent needs or wants. By using a reserved value, AT, all AT not just a particular flavor or brand of AT, can parse the value and say "oh, one of those... I do this with those" consistently. While there is a weak semantic value to a reserved value, there is *some* value, whereas the vacuum of not having any alt value is just that, a vacuum, and asks essentially for a guess, without providing *ANY* clues. Visual users can see the photo, non-visual users are discriminated against by being handed nothing. Finally, "Whatever the device you use for getting your information out, it should be the same information." - TBL ...suggests to me that it should *not* be the final consuming user-agent that must deal with the problem (end of the supply chain), but rather the author and authoring tools (beginning of the supply chain) - it's the old adage: garbage in = garbage out and nothing within the spec currently contradicts or corrects this problem. JF From annevk at opera.com Tue Apr 15 14:22:14 2008 From: annevk at opera.com (Anne van Kesteren) Date: Tue, 15 Apr 2008 23:22:14 +0200 Subject: [html4all] there are markup options [was: Re: img/alt summary attempt] In-Reply-To: <4805162A.6070904@utoronto.ca> References: <3A582960-A630-4584-83ED-25E24197A44D@IEEE.org> <4805162A.6070904@utoronto.ca> Message-ID: On Tue, 15 Apr 2008 22:55:06 +0200, Jan Richards wrote: > If I may, I would like to replace "is important" with "CONVEYS > INFORMATION", as in: > > (1) Image DOES NOT CONVEY INFORMATION, alternative text is available. > (alt="") > (2) Image CONVEYS INFORMATION, alternative text is available. (alt="...") > > Now, in my opinion, a missing "alt" attribute actually represents: > > (3-REWORDED) Image MAY OR MAY NOT CONVEY INFORMATION and alternative > text is not available. I think here you start to confuse the issue. If an image does not convey information there is a clear solution: set the alt attribute to the empty string. Whether or not authors actually do that is a matter of conformance. If an image does not convey information and has no alt attribute specified it is non-conforming. Similarly if an image does convey information and alternative text is available setting the alt attribute to the empty string would be non-conforming. > Now, I think there is a fourth state that I see use in representing: > > (4-NEW) A tool (CMS, etc.) knows that the image CONVEYS INFORMATION > (e.g. someone uploaded it from their camera, so it's probably not a > blank placeholder), but alternative text is not available. > > That said, I'm not sure how (4) should be represented (e.g., some have > suggested something like alt="_none"). This is case three. -- Anne van Kesteren From joshue.oconnor at cfit.ie Tue Apr 15 14:44:54 2008 From: joshue.oconnor at cfit.ie (Joshue O Connor) Date: Tue, 15 Apr 2008 22:44:54 +0100 Subject: [html4all] Request for review of alt and alt value for authoring or publishing tools In-Reply-To: References: <007101c89f39$7604afb0$cf2a42ab@stanford.edu> Message-ID: <480521D6.3070400@cfit.ie> Ian Hickson wrote: > There is *absolutely no practical difference* to the UA between omitting > the alt="" attribute altogether, and having the alt="" attribute set to > some magical reserved value. They are functionally identical, and user > agents can get as much information from either. Thats not entirely true. If you consider a UA like a screen reader which will pretty much by default skip images that have a null alt value and the other situation you cite where there is some reserved value that will potentially trigger some kind of behaviour (which is undefined as yet). The difference (an benefit) of this magical reserved value is that the user may be able to choose to also ignore it via some verbosity settings. Without this 'magical reserved value' the screen reader will potentially default into heuristic evaluation which is not desirable when interacting with an application - such as the much vaunted photo sharing application - and its dynamically generated/random alphanumeric URLs. [1] So while in principle there may be no practical difference to the UA, and I see your point, there is potential for a very real impact on the user. Cheers Josh [1] http://www.paciellogroup.com/resources/articles/altinhtml5.html#apply1 From lhs at malform.no Tue Apr 15 14:56:38 2008 From: lhs at malform.no (Leif Halvard Silli) Date: Tue, 15 Apr 2008 23:56:38 +0200 Subject: [html4all] Request for review of alt and alt value for authoring or publishing tools In-Reply-To: References: <006101c89f29$470c67d0$cf2a42ab@stanford.edu> Message-ID: <48052496.5010601@malform.no> Ian Hickson 08-04-15 20.56: ? > On Tue, 15 Apr 2008, John Foliot wrote: > > Ian Hickson wrote: > > There's no way to know. My point is that this: > >
> > I snapped this photo the other day while walking around the > Googleplex and saw Ian Hickson working at his desk. >
> > ...is significantly less annoying than this: > >
> I snapped this photo the other day while > walking around the Googleplex and saw Ian > Hickson working at his desk. > I snapped this photo the other day while walking around the > Googleplex and saw Ian Hickson working at his desk. >
> And why do you come with that comparison? To bad things, and let's see what is best? Btw, I think it was at AListApart I read that AT users disliked that the content of the TITLE element was repeated in the

element. > ...while providing no less information -- and arguably more, since in the > second case the image-disabled user can't easily distinguish it from this > third case: > >
>

I snapped this photo the other day while walking around the > Googleplex and saw Ian Hickson working at his desk.

> I snapped this photo the other day while walking around the > Googleplex and saw Ian Hickson working at his desk. >
> > ...which, per spec, is semantically equivalent. > > A third bad example, again talking about the fact - yest - that it is possible to have alt content without having the embedded content in place. But, why would anyone drop to place a photo inside
or forget the SRC inside ? How often does that happen? Is it a real problem? Do you think that anyone will actively try to fool AT users? So: No one care about alternative content, unless they can use it to fool an AT user? For that matter, even if ther is a IMG and a SRC in that IMG, the AT user cannot know if there actually is any image at that URL. Nor can he know if it is the right image. -- leif halvard silli From lhs at malform.no Tue Apr 15 15:04:11 2008 From: lhs at malform.no (Leif Halvard Silli) Date: Wed, 16 Apr 2008 00:04:11 +0200 Subject: [html4all] there are markup options [was: Re: img/alt summary attempt] In-Reply-To: References: <3A582960-A630-4584-83ED-25E24197A44D@IEEE.org> Message-ID: <4805265B.2000802@malform.no> Ian Hickson 08-04-15 21.09: ? > On Tue, 15 Apr 2008, Al Gilman wrote: > > The problem is that there are _three_ states, not two: > > 1. Image is not important. (alt="") > 2. Image is important, alternative text is available. (alt="...") > 3. Image is important, alternative text is not available. > > Case 3 is the one we are discussing. Cases 1 and 2 are well understood and > nobody is suggesting changing them. > What do you exactly mean by "unavailable"? I ask because In another message you said that: > Ian Hickson wrote: > >> > The only actual solution suggestion I see there is alt="1", alt="2", >> > etc, but it is unclear how that would improve accessibility. >> So, if you see the solution alt=1, alt=2, does that mean that alternative text **is** available? Or does it mean that it is unavailable? -- leif halvard silli From lhs at malform.no Tue Apr 15 15:10:12 2008 From: lhs at malform.no (Leif Halvard Silli) Date: Wed, 16 Apr 2008 00:10:12 +0200 Subject: [html4all] Request for review of alt and alt value for authoring or publishing tools In-Reply-To: References: <006101c89f29$470c67d0$cf2a42ab@stanford.edu> <5887DAED-91A4-45F4-806C-343E303C5BDA@tomascaspers.de> Message-ID: <480527C4.4070602@malform.no> Ian Hickson 08-04-15 21.26: ? > On Tue, 15 Apr 2008, Tomas Caspers wrote: > > > > Am 15.04.2008 um 20:48 schrieb John Foliot: > > > Any information is better than no information. It puts the images in a > > > rudimentary context (this is image 4 of 9 on the page). A non-visual user > > > still may have no idea what the image really is, but can be told that image > > > number 4 at the "photo-upload site" is of their grandchild, and they could > > > then copy the file to a flash drive, and have the photo printed and framed > > > for when visitors come over to visit (just to make the scenario "real"). > > > > The same would be true if the AT involved simply read out the filename, > > as some of them do in absence of an alt-Attribute. > > Indeed the AT itself could read out the "1 of 4" thing -- and at least > then there would be a reasonably good chance of the numbering being > correct, which would not be the case if we relied on the author. :-) > :-) Have we suddenly stopped discussing the issue of 10000 images on **automated** websites? Btw, I think giving the image number 9999 would not be so useful. But if we actually get to agree that there must be replacement text, then we could discuss how it is best done. -- leif halvard silli From foliot at wats.ca Tue Apr 15 15:15:44 2008 From: foliot at wats.ca (John Foliot) Date: Tue, 15 Apr 2008 15:15:44 -0700 Subject: [html4all] Request for review of alt and alt value for authoring or publishing tools In-Reply-To: Message-ID: <007f01c89f46$402a9a00$cf2a42ab@stanford.edu> Ian Hickson wrote: > > So let's look at a random image on Flickr: > > http://flickr.com/photos/18356286 at N00/854359279/ So you feel compelled to make this personal then (and here I was being super polite and reasonable all day, even paying you a compliment...). You pick on one photo of four in my public Flickr account that lacks a Flickr "Description". It does have a "Note" however: "Bug meets knee at 90 miles an hour. Good thing for chaps...", which , if Flickr could get it right, could possibly also serve as pseudo-alt text. Problem is, the Flickr interface sucks: there is no way to add appropriate alternative text, whether I wanted to or not. (alt="John's knee showing a bruise" - see how everyone reading this now knows what that "random" image is, even if they don't go to the URL - alt text is for everyone!) However, if the next generation authoring language *DID NOT ALLOW THIS*, then Flickr and kin would wake up and smell the coffee, and allow the contributors the ability to do the right thing. Instead, *you* think that the status quo is fine, and should be blessed. > > We all agree that the authors should include alternative text. > > Why don't you include alternative text for the images on your Flickr > account? You could easily add a comment to each image describing the > photo for the benefit of blind users. Why don't you? As I said, only one of four does not have a "Description" (but it does have a "Note"); they all have unique Titles, they all have been "tagged", Flickr has no problem extracting all sorts of metadata about my camera, and the date the picture was taken, etc. etc.. They allow me to place the photo on a map, to send it to my friends, to add "Notes" and pretty much do everything else outside of turning it into gift-wrap paper, yet they do not allow me to add alternative text (which it should be stressed is different than a description or a note anyway). It is for this *VERY* reason that the next-gen language needs to be more pro-active in the social engineering regard, to force (through the risk of non-conformance) authoring tools to provide the ability for content authors to do the right thing - something I cannot do at Flickr even if I wanted to. > > And if _you_, an accessibility expert who cares about blind people, FOR THE LAST FRIGGIN' TIME, ALT TEXT IS ABOUT MORE THAN BLIND PEOPLE!!!!!!!!!!!!!!! (Statements like that just serve to illustrate how very little you really do understand about web accessibility. Now you are just pissing me off) > don't bother to include descriptions of photos you upload to Flickr, > how can we possibly expect Random Joe User, who frankly _doesn't_ > care about blind users, to write descriptions for Flickr to include? Which is also why Flickr should be given the tools for "error recovery"... Hmmm alt="_not supplied" is possibly better than "...The empty string! That's the single _worst_ value you can give in this case." - Ian Hickson ************ So in one email you've managed to make a passionate but polite open debate personal, shown your lack of real understanding of web accessibility by painting this as a "Blind user" issue, and defended my suggestion for reserved values. Way to go Ian. I must now retire from this discussion, as Ian has managed to flame my anger once again, despite my best efforts to be polite. Maybe it's because he's beginning to come to realize that *we* might be right... JF From annevk at opera.com Tue Apr 15 15:21:51 2008 From: annevk at opera.com (Anne van Kesteren) Date: Wed, 16 Apr 2008 00:21:51 +0200 Subject: [html4all] Request for review of alt and alt value for authoring or publishing tools In-Reply-To: References: <007101c89f39$7604afb0$cf2a42ab@stanford.edu> <480521D6.3070400@cfit.ie> Message-ID: On Tue, 15 Apr 2008 23:56:36 +0200, Ian Hickson wrote: > I don't understand. Why can't whatever behaviour will happen for > alt="magic vlaue" also happen when the alt="" attribute isn't present? In > both cases we're talking about future tools, and in both cases we're > presumably talking about the same behaviour. I agree that the users of > legacy tools are screwed either way (magic value or missing attribute, > both will result in a poor user experience for these images in today's > UAs, though the missing alt case at least typically has user prefs so > that > the user can tweak those cases, another reason why I personally prefer > simply omitting the alt="" attribute rather than introducing keywords). I think the "opposing viewpoint" is more about today's behavior and content than how we can have it in the future. The assumptions seem to be that: * If the alt attribute is specified it is likely to be correct. * If the alt attribute is omitted the more typical case is that the image does not convey information. Joshue also made the point that AT software skips today where they would not skip ... today. I think your assumption is that whether the alt attribute is specified or not does not affect the likelyhood of it being correct. (As in, for an image that needs alternate text and for an image that doesn't are about as likely to occur.) (This is probably an oversimplification and I'd love for people to make it more clear where they are coming from with this.) -- Anne van Kesteren From lhs at malform.no Tue Apr 15 16:16:36 2008 From: lhs at malform.no (Leif Halvard Silli) Date: Wed, 16 Apr 2008 01:16:36 +0200 Subject: [html4all] Request for review of alt and alt value for authoring or publishing tools In-Reply-To: References: <007101c89f39$7604afb0$cf2a42ab@stanford.edu> Message-ID: <48053754.3010408@malform.no> Ian Hickson 08-04-15 23.14: ? > On Tue, 15 Apr 2008, John Foliot wrote: > > Ian Hickson wrote: > > > But in this particular case, the spec is excusing a key player (the > > authoring tool/web-app) from it's role in ensuring that the playing > > field remain level. You are saying "we can't come up with a solution, > > so AT needs to do so" while at the same time giving AT *absolutely* > > nothing to work with. > > The server has nothing to work wither either. None of the players here > have anything to work with. It sucks, but that doesn't make information > magically appear out of nowhere. > There ought to be several things to work with on the page you provided below: The image caption, the name of the user, date/time, title of the photostream. > > > We can get better accessibility by letting user agents compete on best > > > handling of these images than we can by letting servers, who have near > > > zero motivation to address this issue, try to come up with some > > > half-baked solution. > > > > But if the servers *must* provide part of the solution (to be > > "conformant" servers) you have given them the motivation. > > Well, we can test that now, can't we? Since HTML4 require the alt="" > HTML 5 gives many examples. That is an improvement. It is not only demanding that matters, but showing the way as well. > attribute, your argument is that servers have the motivation to include > alternative text on images for which the user has not included any > alternative text. > > So let's look at a random image on Flickr: > > http://flickr.com/photos/18356286 at N00/854359279/ > > What's the alternative text on the critical image?: > >
> alt="" width="500" height="375" onload="show_notes_initially();" > class="reflect">
> > The empty string! That's the single _worst_ value you can give in this > case. What we learn from this is that requiring alt="" attributes on > images ends up motivating the servers _to lie_. They say the image isn't > important, that it's decorative, when in fact it is the single most > important piece of information on the page. > > 20 of 26 images all together have alt text and are just site stuffing. (And 4 of the elements also have alt attributes ...). The 6 other images have emty alt. At least half of those 6 belong to the user/reader generated content/stream. So, there is a some kind of pattern there. If thoe images could have meaningful text, it would matter. > > > Reserved values are just syntactic variants on omitting the attribute. > > > There is no practical difference. (Well, other than reserved values > > > being significantly less usable in today's UAs, and omitting the > > > alt="" attribute being cleaner, which is why the spec says to omit the > > > attribute instead of inventing some new reserved value.) > > > > Yes and no. Reserved values can be programmatically assigned whatever > > values/uses a user-agent needs or wants. By using a reserved value, AT, > > all AT not just a particular flavor or brand of AT, can parse the value > > and say "oh, one of those... I do this with those" consistently. While > > there is a weak semantic value to a reserved value, there is *some* > > value, whereas the vacuum of not having any alt value is just that, a > > vacuum, and asks essentially for a guess, without providing *ANY* clues. > > Visual users can see the photo, non-visual users are discriminated > > against by being handed nothing. > > This is incorrect. There is absolutely no practical semantic difference > from the UA's point of view between an omitted alt="" attribute when > omitting hte attribute is defined to mean "the image is critical but has > no content" and a special reserved value which is defined to mean "the > image is critical but has no content". It is merely a syntactic detail. > I agree that there is no practical semantic difference then. And for the sake of semanticness, it could be possible to define several equally bad/good solutions. (Some migh prefer no alt, som an alt with a reserved word, others would prefer enumeration.) But there might be a practical user experience difference, depending on what the user agent is prepared to make something out of. -- leif halvard silli From lhs at malform.no Tue Apr 15 16:26:21 2008 From: lhs at malform.no (Leif Halvard Silli) Date: Wed, 16 Apr 2008 01:26:21 +0200 Subject: [html4all] there are markup options [was: Re: img/alt summary attempt] In-Reply-To: References: <3A582960-A630-4584-83ED-25E24197A44D@IEEE.org> <4805265B.2000802@malform.no> Message-ID: <4805399D.7020206@malform.no> Ian Hickson 08-04-16 00.55: ? > On Wed, 16 Apr 2008, Leif Halvard Silli wrote: > > Ian Hickson 08-04-15 21.09: ? > > > On Tue, 15 Apr 2008, Al Gilman wrote: > > > > > > The problem is that there are _three_ states, not two: > > > > > > 1. Image is not important. (alt="") > > > 2. Image is important, alternative text is available. (alt="...") > > > 3. Image is important, alternative text is not available. > > > > > > Case 3 is the one we are discussing. Cases 1 and 2 are well understood and > > > nobody is suggesting changing them. > > > > What do you exactly mean by "unavailable"? > > I mean that the person generating the page (e.g. Flickr) has no idea what > the image represents, only that it's important. > We have usually many ways of telling that something is important. A "1" can mean that it is very important. > > I ask because In another message you said that: > > > > > Ian Hickson wrote: > > > > > > > > The only actual solution suggestion I see there is alt="1", > > > > > alt="2", etc, but it is unclear how that would improve > > > > > accessibility. > > > > So, if you see the solution alt=1, alt=2, does that mean that > > alternative text **is** available? Or does it mean that it is > > unavailable? > > As I said in that message and in messages following it, alt="1" would be a > bad choice for alternative text as it would hurt accessibility. The image > doesn't represent "1". We don't know what it represents. That's the > problem. > Yes, I saw that you said so. But I don't think I agree. And image of a "cat" doesn't only represent "cat". It can reprsent my number one. It can represent the first image on that page, in that stream, of that day etc. If you need aditional stuffing, you put it into title. Or in the caption. -- lh From lhs at malform.no Tue Apr 15 17:07:52 2008 From: lhs at malform.no (Leif Halvard Silli) Date: Wed, 16 Apr 2008 02:07:52 +0200 Subject: [html4all] Request for review of alt and alt value for authoring or publishing tools In-Reply-To: References: <007101c89f39$7604afb0$cf2a42ab@stanford.edu> <480521D6.3070400@cfit.ie> Message-ID: <48054358.10208@malform.no> Anne van Kesteren 08-04-16 00.21: ? > On Tue, 15 Apr 2008 23:56:36 +0200, Ian Hickson wrote: > > I don't understand. Why can't whatever behaviour will happen for > > alt="magic vlaue" also happen when the alt="" attribute isn't present? > > I think the "opposing viewpoint" is more about today's behavior and > content than how we can have it in the future. The assumptions seem to be > that: > > * If the alt attribute is specified it is likely to be correct. > And if it is correct that it is likely to be "correct", then we should have an @ALT for VIDEO as well, as I guess will be the same need for alt="labels" there? > * If the alt attribute is omitted the more typical case is that the image > does not convey information. > While the other opposition claims that omitted alt means that it was about content images for which there were no time/urge/method/etc to add alternative text? I think there is a consesus that there is a need to define what should happen when the web application expect the user/author to submit alt text, but this does not happen. The first thing is that the web application should actually start to expect this. If it doesn't tell the user that it expects such input, and give opportunity to insert it it, then little shall happen. The spec does not say that such CMS tools must tell that it expect such text. (I would expect it to help users to mass-insert useful, short, thematic texts.) The next thing is that there must be defined what shall happen when the user still, after the web software _gently_ has offered the user to do add it, still fails to submit such texts. Then there must be a back-up solution. **Perhaps** this is what we are discussing now. I don't feel that the spec as it stands is "proactive". "When alt text is unavailable" is not very clear speak. It is clear that many of us in the HTML4all flock do not think that not having a backup plan for how to deal with lack of user submitted alt text is equal to "no alt text available". Perhaps what Ian wants to say is that the CMS should never generate alt texts on its own? And never close an alt with alt="" on its own? But even the we might not agree. I think it is good if such images are enumerated. Ian does not. And it sounds to me as if Joshue are more positive about alt="" than many of us who are not accessibility professionals. > Joshue also made the point that AT software skips today > where they would not skip ... today. > > > I think your assumption is that whether the alt attribute is specified or > not does not affect the likelyhood of it being correct. "Correct alt" does not sound good in mine ears. But it should not be misleading. > (As in, src=... alt=""> for an image that needs alternate text and > for an image that doesn't are about as likely to occur.) > > It was not clear to me what you meant by referring to what Joshue said etc. -- leif halvard silli From foliot at wats.ca Tue Apr 15 17:08:24 2008 From: foliot at wats.ca (John Foliot) Date: Tue, 15 Apr 2008 17:08:24 -0700 Subject: [html4all] Request for review of alt and alt value for authoring or publishing tools In-Reply-To: Message-ID: <008b01c89f55$fd3c4080$cf2a42ab@stanford.edu> (Against my better judgment) Ian Hickson wrote: > What we really want here is: > > My First Border Crossing... Welcome to Nevada > > [UA-specific image indicator] > > Crossing from California to Nevada on the motorcycle - gotta stop > for the photo-op > > ...which is why we need a way to flag images that are neither > decorative nor have any useful alternative text. > > > I'm not honestly convinced that there is _any_ alternative text that > would be useful beyond your captions on any of these images, or, > frankly, most images on Flickr. alt="Me posing with my motorcycle at the border crossing, Welcome sign and mountains in the background" ...and since we've now publicly discussed 2 of the whopping 4 images on my public Flickr site, let's put to rest what alt text I would have provided *IF* Flickr allowed me to do so for the other 2: Getting Ready II - Alt="Me standing behind my motorcycle getting ready to leave" 4th of July - alt="Me posing with three cute blondes dressed in Red, White and Blue" (Interesting factoid for the world - my 4 image Flickr site is apparently important enough to be discussed on the WHATWG cabal IRC channel) > > >> FOR THE LAST FRIGGIN' TIME, ALT TEXT IS ABOUT MORE THAN BLIND >> PEOPLE!!!!!!!!!!!!!!! > > Of course they're not. I didn't say they were. You wrote: "And if _you_, an accessibility expert who cares about blind people, don't bother to include descriptions of photos you upload to Flickr, how can we possibly expect Random Joe User, who frankly _doesn't_ care about blind users, to write descriptions for Flickr to include?" I see the word "blind" twice in that sentence, so readers can draw their own conclusions regarding what you said or did not say, meant and did not mean. JF From faulkner.steve at gmail.com Wed Apr 16 01:33:17 2008 From: faulkner.steve at gmail.com (Steven Faulkner) Date: Wed, 16 Apr 2008 09:33:17 +0100 Subject: [html4all] On HTML WG process - was [Re: Request for review of alt and alt value for authoring or publishing tools] Message-ID: <55687cf80804160133x4e22d7edscb6b6258807392e@mail.gmail.com> As an individual: I am not convinced of the merit of a reserved value for the alt attribute, nor am I convinced of the desirability of having alt required. Neither am I convinced of the worthlessness of these proposals. I am convinced that the spec needs to use a working definition of "text alternative" or "alternative text" that is in agreement with the WCAG guidelines and that the normative and informative statements provided in the spec must embody that agreement. I am not convinced that the decision about these issues should effectively be up to one person in the HTML WG, namely the editor. Therefore, if after all input from members of the HTML WG and relevant WAI working groups is considered, a consensus cannot be reached, then the legitmate and logical next step is for the issues to be brought to a vote. I don't think we are at that stage yet on these issues, and think that a better outcome would be that we can work as a group to acheive consensus. regards Stevef On 16/04/2008, Steven Faulkner wrote: > hi graham, > > Can you give an example of the differences in behavior you would expect? > > > If a screen reader encounters an > instead of ignoring the image if it is or as it > does now (in most circumstances) it could simply announce the presence > of the graphic as it does now: > useful text announces "graphic useful text" > > or announces nothing > > future: > useful text announces "graphic useful text" > > announces "graphic" > > announces nothing > > announces nothing > > > By announcing the presence of the graphic (a cue), the user is alerted > that the image may contain important information, this could result in > the user paying closer attention to to graphic, for example, > increasing magnification if they are using a magnifier, to see if they > can discern anything from the pixels > or asking somebody to explain to them what the image is. > > Screen magnifiers could add a border around the image to indicate that > it may be of interest. thus providing a visual cue for the user. > > > > regards > stevef > > > On 15/04/2008, James Graham wrote: > > Steven Faulkner wrote: > > > > > > > There is *absolutely no practical difference* to the UA between omitting > > > > the alt="" attribute altogether, and having the alt="" attribute set to > > > > some magical reserved value. They are functionally identical, and user > > > > agents can get as much information from either. > > > > > > > > > > No. you are wrong. > > > > > > if signals to an AT that an image can be safely ignored > > > (which is current usage). > > > then could signal that image should not be ignored by AT > > > signals that neither can the image safely be ignored or that it > > > should not be ignored as it may contain something important. > > > > > > > I think this makes the incorrect assumption that a UA will be able to make a > > useful distinction between the @noalt case and the missing alt attribute > > case. In practice @noalt will end up on images that should have alt="" > > (because e.g. of developers misunderstanding the spec) and images that > > should not be ignored will have neither @alt nor @noalt. Therefore in the > > absence of an alt attribute or in the presence of a noalt attribute, the UA > > should do its level best to supply some useful information about the image, > > hopefully using something better than the crummy "read the filename" > > algorithm that AT vendors have employed to date. > > > > Can you give an example of the differences in behavior you would expect? > > > > -- > > "Mixed up signals > > Bullet train > > People snuffed out in the brutal rain" > > --Conner Oberst > > > > > -- > with regards > > Steve Faulkner > Technical Director - TPG Europe > Director - Web Accessibility Tools Consortium > > www.paciellogroup.com | www.wat-c.org > Web Accessibility Toolbar - > http://www.paciellogroup.com/resources/wat-ie-about.html > -- with regards Steve Faulkner Technical Director - TPG Europe Director - Web Accessibility Tools Consortium www.paciellogroup.com | www.wat-c.org Web Accessibility Toolbar - http://www.paciellogroup.com/resources/wat-ie-about.html From chaals at opera.com Wed Apr 16 02:25:17 2008 From: chaals at opera.com (Charles McCathieNevile) Date: Wed, 16 Apr 2008 11:25:17 +0200 Subject: [html4all] Request for review of alt and alt value for authoring or publishing tools In-Reply-To: References: <007101c89f39$7604afb0$cf2a42ab@stanford.edu> <480521D6.3070400@cfit.ie> Message-ID: On Wed, 16 Apr 2008 00:21:51 +0200, Anne van Kesteren wrote: > On Tue, 15 Apr 2008 23:56:36 +0200, Ian Hickson wrote: >> I don't understand. Why can't whatever behaviour will happen for >> alt="magic vlaue" also happen when the alt="" attribute isn't present? >> In both cases we're talking about future tools, and in both cases we're >> presumably talking about the same behaviour. I agree that the users of >> legacy tools are screwed either way (magic value or missing attribute, >> both will result in a poor user experience for these images in today's >> UAs, though the missing alt case at least typically has user prefs so >> that the user can tweak those cases, another reason why I personally >> prefer simply omitting the alt="" attribute rather than introducing >> keywords). > > I think the "opposing viewpoint" is more about today's behavior and > content than how we can have it in the future. The assumptions seem to be > that: > > * If the alt attribute is specified it is likely to be correct. > * If the alt attribute is omitted the more typical case is that the > image does not convey information. (Leaving aside the question of validity and focusing on the effect on users) I am with Ian here. Adding magic values is likely to mess up existing workflows from user agents through to authoring tools, system evaluation tools (the sort of thing that the people who currently really care about getting tehir HTML right actually use), and even websites explaining how to write good web pages. Leaving out the alt attribute where you don't know anything about what would be a good value (whether you are a second-rate tool that never asked, or a lazy or second-rate author that never bothere to think about the answer - and I really do mean that to sound at least as judgemental as it does) is the simplest approach to allowing those who are doing a decent job to improve the web overall. If the alt attribute is specified it is somewhat likely to be correct. If it is ommitted, it is almost certain that this is an error - there is *some* useful value (which may be alt="") for every example I have *ever* seen, but where that is not made clear, machines guessing it are more likely to get it wrong (i.e. a machine heuristic is more likely to be harmful than useful). > Joshue also made the point that AT software skips today > where they would not skip ... today. Where there is not alt attribute, AT software will often try to do something useful with whatever is left (but mostly fail - it's beyond the state of AT today, partly as a result of the way people use the Web). Where there is an alt attribute, the AT will present that. Increasingly (for some value of increasingly - AT gets tweaked and adjusted far faster than browsers, so it may go up and down depending on the current 3-month perception of the most useful way to read the existing Web, but the trend seems clear) alt="" is recognised as being *probably* deliberately included for images where the best thing is not to say anything. > I think your assumption is that whether the alt attribute is specified or > not does not affect the likelyhood of it being correct. (As in, src=... alt=""> for an image that needs alternate text and > for an image that doesn't are about as likely to occur.) > > > (This is probably an oversimplification and I'd love for people to make > it more clear where they are coming from with this.) I hope that clarifies where I am coming from at least :) -- Charles McCathieNevile Opera Software, Standards Group je parle fran?ais -- hablo espa?ol -- jeg l?rer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com From joshue.oconnor at cfit.ie Wed Apr 16 02:35:45 2008 From: joshue.oconnor at cfit.ie (Joshue O Connor) Date: Wed, 16 Apr 2008 10:35:45 +0100 Subject: [html4all] Request for review of alt and alt value for authoring or publishing tools In-Reply-To: References: Message-ID: <4805C871.1070801@cfit.ie> Ian Hickson wrote: > I did consider this, however -- it has been suggested several times in the > past. The problem is that I am skeptical that magic keywords won't be > abused as much as the simpler syntax we have now. If anything, the > longdesc="" attribute should show us how much authors are likely to use > nonsense values. longdesc="" is supposed to take a URI, but a huge > fraction of longdesc="" attributes have strings that are not URIs at all. > (The most common longdesc="" value is the empty string!) Please note that because use of @longdesc in very small in comparison to other elements, does not mean it has no value. Because it can be abused, does not mean it has no value and the same applies even if It's implementation is flawed. I understand that you wish to develop the spec in a way that can minimize abuse and that is laudable but this should not be done at the expense of elements and attributes that are explicitly designed to support the needs of people with disabilities. Cheers Josh From lachlan.hunt at lachy.id.au Wed Apr 16 02:40:05 2008 From: lachlan.hunt at lachy.id.au (Lachlan Hunt) Date: Wed, 16 Apr 2008 11:40:05 +0200 Subject: [html4all] Request for review of alt and alt value for authoring or publishing tools In-Reply-To: <007f01c89f46$402a9a00$cf2a42ab@stanford.edu> References: <007f01c89f46$402a9a00$cf2a42ab@stanford.edu> Message-ID: <4805C975.50502@lachy.id.au> John Foliot wrote: > However, if the next generation authoring language *DID NOT ALLOW > THIS*, then Flickr and kin would wake up and smell the coffee, and > allow the contributors the ability to do the right thing. Keep in mind that the *current* generation authoring language does not allow alt to be omitted. A simple requirement for alt in HTML5, just like in HTML4, won't have any effect on sites like flickr. But there is sure to be other, more effective approaches that might. > It is for this *VERY* reason that the next-gen language needs to be more > pro-active in the social engineering regard, to force (through the risk of > non-conformance) authoring tools to provide the ability for content authors > to do the right thing - something I cannot do at Flickr even if I wanted to. HTML5 conformance criteria should not be considered to be a social engineering tool. The lack of requirement for alt in a few cases does not prevent alt text inspection tools being integrated into accessibility checkers or validators. Social engineering on this issue can and should continue through other avenues, such as accessibility guidelines, advocacy and education; but not in the HTML5 specification. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/ From faulkner.steve at gmail.com Wed Apr 16 02:52:40 2008 From: faulkner.steve at gmail.com (Steven Faulkner) Date: Wed, 16 Apr 2008 10:52:40 +0100 Subject: [html4all] Request for review of alt and alt value for authoring or publishing tools In-Reply-To: <4805C975.50502@lachy.id.au> References: <007f01c89f46$402a9a00$cf2a42ab@stanford.edu> <4805C975.50502@lachy.id.au> Message-ID: <55687cf80804160252y52ee9f22w5e574d6ea378be49@mail.gmail.com> Hi Lachlan, > HTML5 conformance criteria should not be considered to be a social > engineering tool. The lack of requirement for alt in a few cases does > not prevent alt text inspection tools being integrated into > accessibility checkers or validators. Social engineering on this issue > can and should continue through other avenues, such as accessibility > guidelines, advocacy and education; but not in the HTML5 specification. The current spec in most cases related to the alt does _require_ an alt with a useful value as a conformance criteria. So it is being used as a "Social engineering" tool. regards stevef On 16/04/2008, Lachlan Hunt wrote: > John Foliot wrote: > > However, if the next generation authoring language *DID NOT ALLOW > > THIS*, then Flickr and kin would wake up and smell the coffee, and > > allow the contributors the ability to do the right thing. > > Keep in mind that the *current* generation authoring language does not > allow alt to be omitted. A simple requirement for alt in HTML5, just > like in HTML4, won't have any effect on sites like flickr. But there is > sure to be other, more effective approaches that might. > > > It is for this *VERY* reason that the next-gen language needs to be more > > pro-active in the social engineering regard, to force (through the risk of > > non-conformance) authoring tools to provide the ability for content authors > > to do the right thing - something I cannot do at Flickr even if I wanted to. > > HTML5 conformance criteria should not be considered to be a social > engineering tool. The lack of requirement for alt in a few cases does > not prevent alt text inspection tools being integrated into > accessibility checkers or validators. Social engineering on this issue > can and should continue through other avenues, such as accessibility > guidelines, advocacy and education; but not in the HTML5 specification. > > -- > Lachlan Hunt - Opera Software > http://lachy.id.au/ > http://www.opera.com/ > > _______________________________________________ > List_HTML4all.org mailing list > http://www.html4all.org/wiki > -- with regards Steve Faulkner Technical Director - TPG Europe Director - Web Accessibility Tools Consortium www.paciellogroup.com | www.wat-c.org Web Accessibility Toolbar - http://www.paciellogroup.com/resources/wat-ie-about.html From chaals at opera.com Wed Apr 16 03:55:17 2008 From: chaals at opera.com (Charles McCathieNevile) Date: Wed, 16 Apr 2008 12:55:17 +0200 Subject: [html4all] "Social engineering" Re: Request for review of alt and alt value ... In-Reply-To: <4805C975.50502@lachy.id.au> References: <007f01c89f46$402a9a00$cf2a42ab@stanford.edu> <4805C975.50502@lachy.id.au> Message-ID: On Wed, 16 Apr 2008 11:40:05 +0200, Lachlan Hunt wrote: > The lack of requirement for alt in a few cases does not prevent alt text > inspection tools being integrated into accessibility checkers or > validators. Social engineering on this issue can and should continue > through other avenues, such as accessibility guidelines, advocacy and > education; but not in the HTML5 specification. In general I don't know that this is true. "Social engineering" (at the most basic level, actually writing a spec as a group rather than having it handed down from on high by some particular genius or monopolist or whatever) is part of the toolkit available to achieve desirable technical outcomes. The real question here is what approach to this particular piece of social engineering best meets our goals. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle fran?ais -- hablo espa?ol -- jeg l?rer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com From harry.loots at ieee.org Wed Apr 16 04:56:28 2008 From: harry.loots at ieee.org (Harry Loots) Date: Wed, 16 Apr 2008 12:56:28 +0100 Subject: [html4all] Request for review of alt and alt value for authoring or publishing tools In-Reply-To: References: <007101c89f39$7604afb0$cf2a42ab@stanford.edu> <480521D6.3070400@cfit.ie> Message-ID: <20080416115628.M11155@ieee.org> On Wed, 16 Apr 2008 11:25:17 +0200, Charles McCathieNevile wrote: > (Leaving aside the question of validity and focusing on the effect > on users) I am with Ian here. Adding magic values is likely to mess > up existing workflows from user agents through to authoring tools, > system evaluation tools (the sort of thing that the people who > currently really care about getting tehir HTML right actually use), > and even websites explaining how to write good web pages. Are we saying that once the tool has been published it can not be changed to allow for changes in the way the code is presented? > Leaving out the alt attribute where you don't know anything about what > would be a good value (whether you are a second-rate tool that > never asked, or a lazy or second-rate author that never bothere to > think about the answer - and I really do mean that to sound at > least as judgemental as it does) is the simplest approach to > allowing those who are doing a decent job to improve the web overall. I cannot agree with this viewpoint: we share the viewpoint that where ALT has been provided it is assumed to have been provided with good intentions, ie, to describe the image to users who may benefit from ALT. On equal terms with this statement where developers deliberately add ALT=" " let's assume for the moment that they do so in the understanding that AT will ignore the image and skip to next segment of text content. Based on the above development practices, we have two scenarios: If ALT is used as described above, users who read or hear the text alternative to the visual content are presented with either the ALT description or nothing. In the case where ALT has been ignored due to laziness, ignorance, or whatever other reason, the same group of people described above may benefit if the UA announces or inserts text to the effect 'ALT missing/omitted/not supplied/AWOL' or whatever words we choose to tell the user the developer is lazy, second rate or simply ignorant of their needs. If the words 'ALT not supplied/whatever' is heard/appears, the user knows that an image appeared in the content; they do not know if it has value, but at least they can ask someone who can view or see the image if it contains information of relevance. If ALT="" is used for this scenario then the user will not know there is an image and will not be able to do anything about it. Regards Harry From laura.lee.carlson at gmail.com Wed Apr 16 05:05:02 2008 From: laura.lee.carlson at gmail.com (Laura Carlson) Date: Wed, 16 Apr 2008 07:05:02 -0500 Subject: [html4all] On HTML WG process - was [Re: Request for review of alt and alt value for authoring or publishing tools] In-Reply-To: <55687cf80804160133x4e22d7edscb6b6258807392e@mail.gmail.com> References: <55687cf80804160133x4e22d7edscb6b6258807392e@mail.gmail.com> Message-ID: <1c8dbcaa0804160505t3351c658w32812c0942841bb6@mail.gmail.com> > As an individual: > I am not convinced of the merit of a reserved value for the alt > attribute, nor am I convinced of the desirability of having alt > required. Neither am I convinced of the worthlessness of these > proposals. > I am convinced that the spec needs to use a working definition of > "text alternative" or "alternative text" that is in agreement with the > WCAG guidelines and that the normative and informative statements > provided in the spec must embody that agreement. > > I am not convinced that the decision about these issues should > effectively be up to one person in the HTML WG, namely the editor. > > Therefore, if after all input from members of the HTML WG and relevant > WAI working groups is considered, a consensus cannot be reached, then > the legitmate and logical next step is for the issues to be brought to > a vote. > > I don't think we are at that stage yet on these issues, and think that > a better outcome would be that we can work as a group to acheive > consensus. As an individual I agree will all of the above. As an individual, I do think that the HTML5 WG actually seeking advice from PFWG, as well as the WAI offering advice on a regular on-going basis would be most beneficial to process improvement. For this use case AUWG and UAWG folks are the experts who could provide real insight into possible solutions. We needed to ask them for their advice. And we need to listen. Best Regards, Laura --- Laura Carlson From chaals at opera.com Wed Apr 16 05:40:18 2008 From: chaals at opera.com (Charles McCathieNevile) Date: Wed, 16 Apr 2008 14:40:18 +0200 Subject: [html4all] Request for review of alt and alt value for authoring or publishing tools In-Reply-To: <20080416115628.M11155@ieee.org> References: <007101c89f39$7604afb0$cf2a42ab@stanford.edu> <480521D6.3070400@cfit.ie> <20080416115628.M11155@ieee.org> Message-ID: On Wed, 16 Apr 2008 13:56:28 +0200, Harry Loots wrote: > On Wed, 16 Apr 2008 11:25:17 +0200, Charles McCathieNevile wrote: >> (Leaving aside the question of validity and focusing on the effect >> on users) I am with Ian here. Adding magic values is likely to mess >> up existing workflows from user agents through to authoring tools, >> system evaluation tools (the sort of thing that the people who >> currently really care about getting tehir HTML right actually use), >> and even websites explaining how to write good web pages. > > Are we saying that once the tool has been published it can not be > changed to allow for changes in the way the code is presented? Not at all. I am saying that standardising some behaviour other than using the absence of an alt attribute to signal that there is no decent text alternative provided means that most of today's tools would not be useful and would need to be changed. So would most of the tutorial information around today. (If we standardised on alt="" instead then there may be a few tools which would suddenly work properl, but would be considered broken today). >> Leaving out the alt attribute where you don't know anything about what >> would be a good value (whether you are a second-rate tool that >> never asked, or a lazy or second-rate author that never bothere to >> think about the answer - and I really do mean that to sound at >> least as judgemental as it does) is the simplest approach to >> allowing those who are doing a decent job to improve the web overall. > > I cannot agree with this viewpoint: > we share the viewpoint that where ALT has been provided it is assumed to > have been provided with good intentions, ie, to describe the image to > users who may benefit from ALT. On equal terms with this statement where > developers deliberately add ALT=" " let's assume for the moment that > they do so in the understanding that AT will ignore the image and skip > to next segment of text content. [modulo minor quibbles about alt not being a description per se, but more like a "functionally equivalent text", and this being about more than a handful of users or about screenreaders, sure] > Based on the above development practices, we have two scenarios: > If ALT is used as described above, users who read or hear the text > alternative to the visual content are presented with either the > ALT description or nothing. Indeed. Depending on what is most useful. > In the case where ALT has been ignored due to laziness, ignorance, or > whatever other reason, the same group of people described above may > benefit if the UA announces or inserts text to the effect > 'ALT missing/omitted/not supplied/AWOL' or whatever words we choose > to tell the user the developer is lazy, second rate or simply > ignorant of their needs. If the words 'ALT not supplied/whatever' is > heard/appears, the user knows that an image appeared in the content; > they do not know if it has value, but at least they can ask > someone who can view or see the image if it contains information of > relevance. Right. > If ALT="" is used for this scenario then the user will not know there is > an image and will not be able to do anything about it. Then we really do agree. By *leaving out* the alt attribute, I mean no attribute is present. Unless some useful alt content has been supplied, there should be no alt attribute and nothing there. This has been a common idea in accessibility for something like a decade. Note that while alt="" and alt=" " are, to a screen reader, equivalent - nothing gets read (unless the user has selected super-critical punctuation sensitivity), they are different to a visual user with images off, since they potentially change the presentation. They are potentially different to a braille reader for the same reason. Search engines, software evaluation frameworks, and other non-visual user agents may also react to them in different ways. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle fran?ais -- hablo espa?ol -- jeg l?rer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com From harry.loots at ieee.org Wed Apr 16 06:37:21 2008 From: harry.loots at ieee.org (Harry Loots) Date: Wed, 16 Apr 2008 14:37:21 +0100 Subject: [html4all] Request for review of alt and alt value for authoring or publishing tools In-Reply-To: References: <007101c89f39$7604afb0$cf2a42ab@stanford.edu> <480521D6.3070400@cfit.ie> <20080416115628.M11155@ieee.org> Message-ID: <20080416133721.M7340@ieee.org> On Wed, 16 Apr 2008 14:40:18 +0200, Charles McCathieNevile wrote: On Wed, 16 Apr 2008 14:40:18 +0200, Charles McCathieNevile wrote: > On Wed, 16 Apr 2008 13:56:28 +0200, Harry Loots > wrote: > > > On Wed, 16 Apr 2008 11:25:17 +0200, Charles McCathieNevile wrote: > >> (Leaving aside the question of validity and focusing on the effect > >> on users) I am with Ian here. Adding magic values is likely to mess > >> up existing workflows from user agents through to authoring tools, > >> system evaluation tools (the sort of thing that the people who > >> currently really care about getting tehir HTML right actually use), > >> and even websites explaining how to write good web pages. > > > > Are we saying that once the tool has been published it can not be > > changed to allow for changes in the way the code is presented? > > Not at all. I am saying that standardising some behaviour other than > using the absence of an alt attribute to signal that there is no > decent text alternative provided means that most of today's tools > would not be useful and would need to be changed. So would most of > the tutorial information around today. > > (If we standardised on alt="" instead then there may be a few tools > which would suddenly work properl, but would be considered broken > today). So if i read this correctly you are suggesting that tools be fixed first to correctly displayed the 'conventional' value of alt="" - ie, display nothing? > >> Leaving out the alt attribute where you don't know anything about what > >> would be a good value (whether you are a second-rate tool that > >> never asked, or a lazy or second-rate author that never bothere to > >> think about the answer - and I really do mean that to sound at > >> least as judgemental as it does) is the simplest approach to > >> allowing those who are doing a decent job to improve the web overall. > > > > I cannot agree with this viewpoint: > > we share the viewpoint that where ALT has been provided it is assumed to > > have been provided with good intentions, ie, to describe the image to > > users who may benefit from ALT. On equal terms with this statement where > > developers deliberately add ALT=" " let's assume for the moment that > > they do so in the understanding that AT will ignore the image and skip > > to next segment of text content. > > [modulo minor quibbles about alt not being a description per se, but > more like a "functionally equivalent text", and this being about > more than a handful of users or about screenreaders, sure] Fair comment - i should choose my words more carefully ;) > > Based on the above development practices, we have two scenarios: > > If ALT is used as described above, users who read or hear the text > > alternative to the visual content are presented with either the > > ALT description or nothing. > > Indeed. Depending on what is most useful. > > > In the case where ALT has been ignored due to laziness, ignorance, or > > whatever other reason, the same group of people described above may > > benefit if the UA announces or inserts text to the effect > > 'ALT missing/omitted/not supplied/AWOL' or whatever words we choose > > to tell the user the developer is lazy, second rate or simply > > ignorant of their needs. If the words 'ALT not supplied/whatever' is > > heard/appears, the user knows that an image appeared in the content; > > they do not know if it has value, but at least they can ask > > someone who can view or see the image if it contains information of > > relevance. > > Right. > > > If ALT="" is used for this scenario then the user will not know there is > > an image and will not be able to do anything about it. > > Then we really do agree. By *leaving out* the alt attribute, I mean > no attribute is present. Unless some useful alt content has been > supplied, there should be no alt attribute and nothing there. This > has been a common idea in accessibility for something like a decade. To a point.... I'm happy to agree that no alt should be interpreted as the lazy second-rate couldnt care less.... However in practice i have seen to many people who do not know what to do when they encounter nothing.... Give the same people a string of nonsensical text such as 'none supplied' and they'll immediately come up with an elegant solution on how to deal with this! Either way, if we agree that the omission of alt, whether by total omission or through reserved value, should be dealt with by UAs in a specified way, how do we get UA makers to implement this simple convention? How can we get them to interpret an omitted ALT and advise the user/reader/listener that an image is present but no equivalent has been provided? > > Note that while alt="" and alt=" " are, to a screen reader, > equivalent - nothing gets read (unless the user has selected super- > critical punctuation sensitivity), they are different to a visual > user with images off, since they potentially change the > presentation. They are potentially different to a braille reader > for the same reason. Search engines, software evaluation frameworks, > and other non-visual user agents may also react to them in > different ways. Minor point: agree on equivalence from AT perspective - and you're right it may be potentially different to other non-visual UAs - i seem to recall (though not sure i want remember that far back) that Bobby used to complain about alt="" but accepted alt=" ". In practice though alt="" and alt=" " is not equivalent. Example: Ma riding her bicyclePa riding his bicycle will be rendered as 'Ma riding her bicyclePa riding his bicycle' - note the concatenation of 'bicycle' and 'Pa' Best practice suggest that alt values should start and end with a space (where a value is supplied) and a single space inserted where the intention is to leave this blank. But that's probably a point for a different discussion.... From chaals at opera.com Wed Apr 16 08:40:18 2008 From: chaals at opera.com (Charles McCathieNevile) Date: Wed, 16 Apr 2008 17:40:18 +0200 Subject: [html4all] Request for review of alt and alt value for authoring or publishing tools In-Reply-To: <20080416133721.M7340@ieee.org> References: <007101c89f39$7604afb0$cf2a42ab@stanford.edu> <480521D6.3070400@cfit.ie> <20080416115628.M11155@ieee.org> <20080416133721.M7340@ieee.org> Message-ID: On Wed, 16 Apr 2008 15:37:21 +0200, Harry Loots wrote: > On Wed, 16 Apr 2008 14:40:18 +0200, Charles McCathieNevile wrote: >> wrote: >> >> > On Wed, 16 Apr 2008 11:25:17 +0200, Charles McCathieNevile wrote: >> >> ... Adding magic values is likely to mess >> >> up existing workflows... >> > >> > Are we saying that once the tool has been published it can not be >> > changed to allow for changes in the way the code is presented? >> >> Not at all. I am saying that standardising some [new] behaviour... >> means that most of today's tools >> ... and would need to be changed. So would most of >> the tutorial information around today. >> >> (If we standardised on alt="" instead then there may be a few tools >> which would suddenly work properl, but would be considered broken >> today). > > So if i read this correctly you are suggesting that tools be fixed first > to correctly displayed the 'conventional' value of alt="" - ie, display > nothing? Most existing tools today work, based on the assumption that alt="" means "there is nothing that needs to be said about this image in the ordinary flow of text" and img elements that have no attributes just mean the tool has to do its best to figure out how to solvethe rpoblem that the page was badly authored. User agents generally present nothing when alt="" Authoring tools that get it right check for no alt attribute, and prompt for something useful. Which can be "" (the empty string) or " " (space) or something else. Most authoring tools do not add a value if they do not have any information. Flickr, it seems, is a prominent exception - right now it does the wrong thing (this is by report - I no longer use flickr and haven't gone back to log in just to check) and adds alt="" automagically, whether there is a description[1] (in which case that is reasonable) or not[2]. On a page full of photos[3] it just repeats the title of the photo, which is generally reckoned as a bad alt text. There are other prominent exceptions - and we should fix what they do. This discussion is substantially about whether they add alt="" in order to claim validity to the spec, since the outcome "we" are trying to establish is that they do not automatically add this value. ... >> [modulo minor quibbles about alt not being a description per se, but >> more like a "functionally equivalent text", and this being about >> more than a handful of users or about screenreaders, sure] > > Fair comment - i should choose my words more carefully ;) > ... >> > If ALT="" is used for [when nothing is supplied] then the user will >> > not know there is an image and will not be able to do anything about >> > it. >> >> Then we really do agree. ... Unless some useful alt content has been >> supplied, there should be no alt attribute and nothing there. This >> has been a common idea in accessibility for something like a decade. > > To a point.... > I'm happy to agree that no alt should be interpreted as the lazy > second-rate couldnt care less.... > However in practice i have seen to many people who do not know what to > do when they encounter nothing.... Give the same people a string of > nonsensical text such as 'none supplied' and they'll immediately come > up with an elegant solution on how to deal with this! Do you mean end users can't cope? This is properly handled by their user agent (or UA/AT combination if applicable) providing them the information that there is an image. Mine does so by putting a little box in the layout, and putting the alt in the little box. > Either way, if we agree that the omission of alt, ... should be > dealt with by UAs in a specified way, I doubt we will agree on many details of the "best" way to deal with this. I think the requirements in the User Agent Accessibility Guidelines [4] already clarify what information needs to be available, but how various systems present that is properly a matter for competing software to determine on their own. All we are likely to really agree on is the meaning of the syntax when an img element is present, but it has no alt attribute at all, and maybe also when that attribute is present but has the value of the empty string (both these cases are currently explained in the existing draft. The argument is about whether they should be represent valid HTML 5. > how do we get UA makers to implement this simple convention? How can > we get them to interpret an omitted ALT and advise the user/reader/ > listener that an image is present but no equivalent has been provided? There are a lot of techniques. Turning on the program is one, setting the preference for what it does in the case of missing information is another, setting a user style sheet is another (my user-mode stylesheet in Opera pretty much gives me the same information that is presented to a jaws user, although it doesn't make as much effort to find something useful with which to replace alt when the attribute is not there). This is a solved problem. If your particular software does it wrong, file a bug or change software. >> Note that while alt="" and alt=" " are, to a screen reader, >> equivalent - nothing gets read (unless the user has selected super- >> critical punctuation sensitivity), they are different to a visual >> user with images off, since they potentially change the >> presentation. They are potentially different to a braille reader >> for the same reason. Search engines, software evaluation frameworks, >> and other non-visual user agents may also react to them in >> different ways. > In practice though alt="" and alt=" " is not equivalent. My paragraph above says "it is equivalent *FOR*SCREEN*READERS* and *IT*IS*NOT*EQUIVALENT* for a whole raft of other technologies for which the alt attribute is important". Which is exactly what I read you saying. [1] http://flickr.com/photos/evamen/2375249026/in/photostream/ [2] http://flickr.com/photos/evamen/2374420061/in/photostream/ [3] http://flickr.com/search/?q=evamen [4] http://www.w3.org/TR/UAAG10/guidelines.html#tech-conditional-content (admittedly UAAG is written in complex language. Now that I work for a user agent developer I believe even more strongly than I did that more care should be taken to ensure that it is easy to read and understand specifications like this). Have a look also at the draft of UAAG 2.0 (bearing in mind that it is a first public working draft, especially principles 3.1, 3.2, 3.4 and 3.5 at http://www.w3.org/TR/UAAG20/#principle-perceivable cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle fran?ais -- hablo espa?ol -- jeg l?rer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com From hsivonen at iki.fi Wed Apr 16 13:33:32 2008 From: hsivonen at iki.fi (Henri Sivonen) Date: Wed, 16 Apr 2008 23:33:32 +0300 Subject: [html4all] several messages about alt In-Reply-To: <48065530.6030909@degeneration.co.uk> References: <55687cf80804110123s69564fe4h2cd882e1733590f9@mail.gmail.com> <6BC82B20-F753-46F0-80B9-E53661B8C27E@iki.fi> <70F786EB-06B3-4761-80CC-B44EC73A8012@iki.fi> <48065530.6030909@degeneration.co.uk> Message-ID: <3AEF6CDD-392C-46C2-A234-A29B68E5FBD7@iki.fi> On Apr 16, 2008, at 22:36, Martin Atkins wrote: > * Accept that invalid HTML is going to be created when the user does > not provide alternative text and live with it. This could be > supplemented with a strong recommendation in the software that > alternative text be provided, thus informing the author of his > "responsibilities". That's not really an option. Copying and pasting what Hixie already quoted in his "Re: several messages": On Tue, 24 Jan 2006, Henri Sivonen wrote: >> On Jan 23, 2006, at 18:43, dolphinling wrote: >> >> Second, it could force authoring tools to produce invalid documents >> if >> the author did not provide any alt text. However, those documents >> would be non-conformant anyway, so this is not a huge problem. > > It is. Authoring tools are judged by taking a page authored using the > tool and running it through the W3C Validator or, presumably in the > future, through an HTML5 conformance checker. Authoring tool makers > who > are capable of making their tool produce syntactically conforming > documents will want to do so and minimize the chance that the users of > their software tarnish the reputation of the tool in the eyes of > people > who use an automated test as a litmus test of authoring tool bogosity. > (People who test tools that way will outnumber the people who make a > more profound analysis due to the "validate, validate, validate" > propaganda.) -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/ From foliot at wats.ca Wed Apr 16 14:08:15 2008 From: foliot at wats.ca (John Foliot) Date: Wed, 16 Apr 2008 14:08:15 -0700 Subject: [html4all] Is this an accurate reflection of where we stand today? (was RE: New issue: IMG section of HTML5 draft contradicts WCAG 1 & WCAG 2 (draft)) In-Reply-To: Message-ID: <009501c8a006$01f72080$b83c42ab@stanford.edu> Ian Hickson wrote: > > If I haven't replied to an e-mail sent prior to this e-mail: > > http://lists.w3.org/Archives/Public/public-html/2008Apr/0220.html > > Please let me know. I thought I had dealt with all feedback prior to > that point. > I believe that Charles McCathieNevile reopened ISSUE-31 "Should img without alt ever be conforming" late last week, in part due to procedural/administrative issues. (Action item #54 still being open) [http://lists.w3.org/Archives/Public/public-html/2008Apr/0231.html] > > > Regarding: > > http://lists.w3.org/Archives/Public/public-html/2008Feb/0082.html > > ...I did carefully read this message the spec has changed to take into > account that feedback. However, that e-mail was rather vague and it > wasn't at all clear to me exactly what was desired. Non-vague conclusion follows: "Conclusion: barring the introduction of new, good reasons for a change, the failure of the HTML5 draft to make @alt on an across-the-board requirement (even if sometimes it has the value of "") is a bug." I guess we are awaiting *NEW*, *GOOD* reasons for change beyond skepticism and opinion. If this qualitative information has emerged, please be kind enough to point us to it. Furthermore, the response also stated: "The language "In such cases, the alt attribute may be omitted," gives the appearance of creating a policy line that is inconsistent with WCAG, whether 1.0 or 2.0. As such, this needs to be changed." Yet the current draft reads: "This could be the case, for instance, on a photo upload site, if the site has received 8000 photos from a user without the user annotating any of them. In such cases, the alt attribute may be omitted, but the alt attribute should be included, with a useful value, if at all possible." [http://www.w3.org/html/wg/html5/#alt] (I do not see the recommended change implemented, although note the change from 3,000 to 8,000 photos) > > If there is some more concrete feedback that I should deal with, I > would encourage you to send it. I believe that Laura Carlson, Steven Faulkner, et.al., as members of the HTML WG, have requested further feedback from 2 other W3C working groups. [http://lists.w3.org/Archives/Public/public-html/2008Apr/0408.html] JF From foliot at wats.ca Wed Apr 16 14:23:57 2008 From: foliot at wats.ca (John Foliot) Date: Wed, 16 Apr 2008 14:23:57 -0700 Subject: [html4all] More effective approaches? (was RE: Request for review of alt and alt value for authoring or publishing tools) In-Reply-To: <4805C975.50502@lachy.id.au> Message-ID: <009e01c8a008$2ea050a0$b83c42ab@stanford.edu> Lachlan Hunt wrote: > > Keep in mind that the *current* generation authoring language does not > allow alt to be omitted. A simple requirement for alt in HTML5, just > like in HTML4, won't have any effect on sites like flickr. But there > is sure to be other, more effective approaches that might. Lachlan, if this is true, then let us hear the optional, more effective approaches. Right now, the only option we are being presented from the Working Group is to omit adding an alt value "sometimes". This is really not that effective in addressing the real needs (that most of us on either side of this discussion are all in agreement with) of non-visual users. Strong language and instruction within HTML5 aside, the spec ultimately leaves the binary decision to subjective determination, which leaves open the possibility of abuse. The text says: "In a rare[1] subset of these cases, there might be no alternative text available[2]. This could be the case, for instance, on a photo upload site[3], if the site has received 8000[4] photos from a user without the user annotating any of them. In such cases, the alt attribute may[5] be omitted, but the alt attribute should be included, with a useful value, if at all possible." [http://www.w3.org/html/wg/html5/#alt] [1] Rare as in 1 in a million, 1 in a trillion, or 1 in 100? [2] Or perhaps the content provider just can't be bothered to add an alt text because "...it wasn't really clear to me what would be a better solution given the single constrain I have: not finding it necessary to provide replacement text for all those images." (http://annevankesteren.nl/2007/09/alt) [3] So other CMS applications cannot seek the same dispensation? A wiki is not a "photo upload site" even though it allows for photo uploads. Wikis and other CMSes then must insist on adding alt text for all images uploaded or be non-conformant? I guess the other solution would be to rename my wiki a "photo upload site" that includes a lot of text, and I'm home-free then? ("Drupal, a popular photo-upload utility") [4] I note that we've upped the ante to 8,000 from 3,000. So then, if the number of images uploaded < 8,000 then alt *must* be included, but if the number of images uploaded >= 8,000 it can become optional? Yes or course, I am both poking fun at and exaggerating to some extent, but the real problem is that the caricatures I note above [5]may emerge as reality, and the spec explicitly condones such. This is what I (we?) see as a serious flaw in the current proposal. Having worked *directly* with WCAG 1 for close to a decade, I know first-hand the problems of slippery words such as "may", "should", and "until such time" when it comes to guidance and (even more importantly) standards. May and should are not "standards" words, they are at best suggestions. There have been at least two other proposals ("Magic tokens/reserved values" and an "unready" stamp) that at the very least should warrant real investigation beyond Ian's "*I* have considered it and am skeptical" response. > > HTML5 conformance criteria should not be considered to be a social > engineering tool. The lack of requirement for alt in a few cases does > not prevent alt text inspection tools being integrated into > accessibility checkers or validators. Social engineering on this > issue can and should continue through other avenues, such as > accessibility guidelines, advocacy and education; but not in the > HTML5 specification. Lachlan, I can tell you first hand that without a stick, the carrot alone is often less than useful. Like it or not, HTML today transcends merely a technical "mark-up" language - the emergence of the WWW in the past decade is on par with the effect that the steam engine had on the Industrial Revolution, or on how the automobile has shaped society (especially "Western" society) - I think we can all agree on this. Since HTML is the primary binder of the bulk of the content that moves over the internet, it now contains a social engineering component, whether or not mechanical (CS) engineers wish to accept it or not. JF From foliot at wats.ca Wed Apr 16 17:46:37 2008 From: foliot at wats.ca (John Foliot) Date: Wed, 16 Apr 2008 17:46:37 -0700 Subject: [html4all] Another summary of alt="" issues and why the spec says what it says In-Reply-To: Message-ID: <00dd01c8a024$7e928ee0$b83c42ab@stanford.edu> Ian Hickson wrote: > > If you can suggest a way to make the text not machine-checkable > instead of > subjective, I'm certainly eager to change the spec to be more machine > checkable. However, I really cannot see any way to compute whether > alternative text is valid or not, or whether it is ok for alternative > text to be omitted or not. Ergo, as a technical solution, the one proposed is not a solution, but rather a failure to find a good solution. I myself cannot accept a technical standard that bases a key accessibility question upon a subjective determination by an unknown third-party entity regarding conformance. Ian, I *do* appreciate that this is difficult, but 2 key points keep coming back to haunt: "WCAG WG is chartered to set Accessibility guidelines and HTML WG is not; so HTML5 should be careful to create features that support WCAG and describe their use in ways that conform to WCAG." "2. By their charters, WAI groups (here WCAG) are the go-to experts in matters of accessibility 3. WCAG requires @alt (WCAG1) or the function that in HTML4 is provided by @alt (WCAG2)" >> [1] Rare as in 1 in a million, 1 in a trillion, or 1 in 100? > > I have no idea. Does it affect the debate? It happens on major sites, > like > Flickr, so even if Flickr was the _only_ site it happened on, we'd > still have to deal with it. Except, as Jim Jewitt notes: "Taking out the alt requirement will remove any pressure on flikr to fix this." [http://lists.w3.org/Archives/Public/public-html/2008Apr/0456.html] See, this is the point - push it back on the offending authors/sites to get their houses in order, not mangle the next-gen authoring language to forgive crap. This is the social pressure point that has been brought up, but that the (CS)engineers want to side-step. Just because you *can* is not a reason, and should certainly not be entrenched into a spec. > > >> [2] Or perhaps the content provider just can't be bothered to add an >> alt text because "...it wasn't really clear to me what would be a >> better solution given the single constrain I have: not finding it >> necessary to provide replacement text for all those images." >> (http://annevankesteren.nl/2007/09/alt) > > No, the spec makes the alt attribute required in this case: > > When it is possible for alternative text to be provided [...] text > that conveys can serve as a substitute for the image must be given > as the contents of the alt attribute. But how can this be enforced, or even checked, when the very same spec says that under "certain circumstances"... All Anne needs to do is claim that his is one of those "certain circumstances", and, given the subjective criteria, he is once again "conformant". Talk about Magic Tokens - this one clause is a Get-Out-of-Jail-Free card of the highest order. > > The [...] bit is a non-normative clause giving examples of such cases: > > for example if the image is part of a series of screenshots in a > magazine review, or part of a comic strip, or is a photograph in a > blog entry about that photograph, > > "Not bothering" is not one of the reasons that the spec gives for not > providing alternative text. I can make this more explicit if you like. Let's look at this. The text reads: "When it is possible for alternative text to be provided..." - first of all, the circumstances cited are tainted: I *CANNOT* add alt text to my Flickr images today because the interface does not allow me. Should the interface change to allow for content authors to add real alternative text, then some would, some wouldn't, some might get it right, and others might get it wrong - however the "possibility" aspect is not a technical restraint, but rather a programming restraint/fault of the current Flickr UI. To be more explicit, you (and the site/program/application seeking to use this clause) must give a "technical" reason why it is not possible, not a "human" reason why it is not, and to date I have not seen one. > > It's just an example. The normative text is "In a rare subset of these > cases, there might be no alternative text available. In such cases, > the alt attribute may be omitted, but the alt attribute should be > included, with a useful value, if at all possible.". That's all. It doesn't > make any judgments about whether this does or doesn't apply to wikis or CMSes. And again, this is problematic. "Rare subset" is undefined, and so any time a site/application/author explicitly ignores the specification point that states "...text that conveys can serve as a substitute for the image must be given as the contents of the alt attribute." they can cite that they are part of the rare subset, and we have nothing to fall back on that demands they offer a burden of proof. And so, gradually, we see more and more pages/sites/applications that become members of the "rare subset" club that eventually we have as many critical images with no useful values attached as we do with. > > >> [4] I note that we've upped the ante to 8,000 from 3,000. So then, >> if the number of images uploaded < 8,000 then alt *must* be >> included, but if the number of images uploaded >= 8,000 it can >> become optional? > > No, that's again just an example and the number is meaningless. I can > make > it smaller if you want. It's just a random number. Citing a large number in the non-normative part (as opposed to my measly 4 images on my Flickr account) suggests that at some point the ability of the content author becomes diminished by the volume of images to be dealt with - after all adding alt text to my four photos would take me all of 5 minutes to do, should I both care to do so, and was programmatically provided the means to do so. And so your assertion that the number is meaningless, yet at the same time increasing it from 3,000 to 8,000 leads me to believe that the volume factor and thresh-hold is one that does count for something. I can add alt text to four images, but doing so to 8,000 is hard (although, I might add, still possible). So the spec leaves open a gray area that apparently *is* hinged on volume. Remove the number issue, and (presuming a good UI) it is possible to provide alt text to 4, 40, 400, 4000 or 40,000 Flickr images - it boils down to time and effort. How to eliminate the possibility of Flickr claiming they can't perform this function, and make the spec criteria more specific I do not know, but this is the nut of the problem - at what point do we through up our hands and cry uncle... It's not about "can't", it's about "won't". If the W3C says that WAI and not HTMLWG are responsible for Accessibility guidelines, and WAI says that "WCAG requires @alt (WCAG1) or the function that in HTML4 is provided by @alt (WCAG2)", and the only example you can provide is one where it is a question of willingness, and not technical feasibility, then you must/should accept the experts advice. > > >> In such cases, the alt attribute may[5] be omitted, but the alt >> attribute should be included, with a useful value, if at all >> possible." [http://www.w3.org/html/wg/html5/#alt] > > This is the actual normative conformance criteria. And so, again, we require a "technical" reason why it is not possible, not a 'social' reason, such as when Joe Public uploads their vacation photos. Technically he *could* add alt text, but maybe he won't. And so this is your real problem - how do you let Flickr off the hook when they have no control over the content supplier? I argue you don't: make it difficult for Flickr to live with the Status Quo, and provide them with real fallback mechanisms rather than absolution. > > D. Mark the image as being critical-but-of-unknown-content. > > Options A-C all result in a worse accessibility situation. D is not > possible in HTML4, and is the option we want to provide in HTML5. How > we > provided it is up to us. As listed at the top of this e-mail, I'm > aware of > three syntax proposals for D (omitting alt to indicate this case, > introducing a new attribute value to indicate this case, and > introducing a > new attribute to indicate this case) and one conformance definition > proposal for handling D. I've cited above the e-mails listing the > problems > with two of the syntax proposals, and the "unready" conformance > proposal > doesn't solve the problem (sites that care about conformance want to > conform, they don't want to reach a level of "unready" conformance), > so > that leaves us with just what the spec says now. Your emails cite your reasoning, but often the reasoning is subjective and is inter-sprinkled with your own opinion. Where it is short on technical merit, it becomes long on conjecture. To whit: "The problem is that I am skeptical that magic keywords won't be abused as much as the simpler syntax we have now... If we had reason to believe that these new magic values wouldn't be abused as much as the current proposal, then I'd agree. However, I think that that would be naive." (Scorecard: 2 "I"s, 1 "I'd", and one "we") [http://lists.w3.org/Archives/Public/public-html/2008Apr/0458.html] "...another reason why I personally prefer simply omitting the alt="" attribute rather than introducing keywords." (Scorecard: 1 "I", 1 "personally") [http://lists.w3.org/Archives/Public/public-html/2008Apr/0439.html] "There is *absolutely no practical difference* to the UA between omitting the alt="" attribute altogether, and having the alt="" attribute set to some magical reserved value. They are functionally identical, and user agents can get as much information from either." (This is also the email where you set about "randomly" picking on my 4 image Flickr account) [http://lists.w3.org/Archives/Public/public-html/2008Apr/0434.html] While there is no "I"s in this response, there is an assertion with no proof. The practical difference has been debated by others (notably Joshue O'Connor and David Poehlman), and you cannot argue that something = nothing: does not equal {any_value} and no matter how many times you say it, it does not become true - unless you can technically prove otherwise. "Reserved values are just syntactic variants on omitting the attribute. There is no practical difference. (Well, other than reserved values being significantly less usable in today's UAs, and omitting the alt="" attribute being cleaner, which is why the spec says to omit the attribute instead of inventing some new reserved value.)" [http://lists.w3.org/Archives/Public/public-html/2008Apr/0431.html] Hey, wait a minute, didn't you just say that there is no practical difference in the previous email, and now you are saying that there *ARE* differences? Which is it? How can variants be identical, when the very definition of variant is "manifesting variety, deviation, or disagreement" [http://www.merriam-webster.com/dictionary/variant] If you are going to directly oppose the recommendation of the PFWG, then the burden of proof rest upon you to prove your assertions, which you have not done. > > The words "may" and "should" are defined by RFC2119 and have very > specific > conformance meanings in the context of HTML5: [from RFC2119 - http://www.ietf.org/rfc/rfc2119] MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. (and so, as I stated, it is "subjective". Flickr "may" decide that adding the alt-text feature to their interface may hurt them in the marketplace, so they won't/don't do it. The spec forgives this, not on technical merit, but because "the marketplace" makes it uncomfortable for them.) An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. (the page is non-conformant would be "reduced" functionality - a token value that admonishes that alt text was "_notsupplied" would be reduced functionality as well. If, as you claim, HTML5 should be focused on the users, then I have no issue making it harder on the people who profit from putting stuff on the web.) In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.) ...and again, it is unclear how providing absolutely no information about a critical image (if you could prove a technical reason why it was not present) can "interoperate" with an interface that seeks this information, especially when all other things being equal (conformant) most images have some alternative text, be it good, bad or indifferent. > > I have given these proposals serious thought and I have listed the > technical reasons for rejecting those proposals. This is the same > process I have followed for all the other issues in the spec so far. I beg to differ - regarding the reserved values/magic tokens question, you have not provided *ANY* technical reason in the 4 responses cited above, but rather only your opinion and conjecture. > > I don't know what else you want me to do, short of ignore the > technical reasons I've listed and go with one of the other proposals despite my > conclusions. Your conclusions on not based on use-case scenarios - none have been formally provided or tested. Your conclusions are not based on empirical data or survey - again none has been provided. I have not read anything "technical" in any of the responses outside of the fact that you believe that the current proposal is "cleaner", which from an engineering perspective may seem good, but does little to really affect accessibility concerns. > The problem is that if you want me to ignore technical > considerations and go with your solution, I end up with a propblem > when people in an opposing camp ask me to ignore technical considerations > and go with _their_ solution. How do I pick which solution to follow? Listen to the W3C experts, as *mandated* and "...make @alt on an across-the-board requirement (even if sometimes it has the value of "")"; and if a new scenario exists (as you suggest), then work within the recommendation to find a workable solution that does not contravene current recommendations by said experts - or push it back to said experts to propose a solution, rather than go with your *opinion*. JF From lachlan.hunt at lachy.id.au Thu Apr 17 02:56:46 2008 From: lachlan.hunt at lachy.id.au (Lachlan Hunt) Date: Thu, 17 Apr 2008 11:56:46 +0200 Subject: [html4all] Another summary of alt="" issues and why the spec says what it says In-Reply-To: <00dd01c8a024$7e928ee0$b83c42ab@stanford.edu> References: <00dd01c8a024$7e928ee0$b83c42ab@stanford.edu> Message-ID: <48071EDE.1070106@lachy.id.au> John Foliot wrote: > Let's look at this. The text reads: "When it is possible for alternative > text to be provided..." - first of all, the circumstances cited are tainted: > I *CANNOT* add alt text to my Flickr images today because the interface does > not allow me. No-one is defending Flickr's failure to allow alt text to be supplied by its users, but whether appropriate UI is provided or not is outside the domain of HTML5's syntactic requirements. That is the domain of the Authoring Tool Accessibility Guidelines. As far as HTML5's requirements are concerned, the only question is whether or not suitable alt text is available. It doesn't matter whether it's not available due to the authoring tools failure to provide suitable UI, or because the author just failed to provide it. However, allowing alt to be omitted in such cases does not excuse the authoring tool's failure to provide suitable UI. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/ From joshue.oconnor at cfit.ie Fri Apr 18 01:54:27 2008 From: joshue.oconnor at cfit.ie (Joshue O Connor) Date: Fri, 18 Apr 2008 09:54:27 +0100 Subject: [html4all] Another summary of alt="" issues and why the spec says what it says In-Reply-To: References: <55687cf80804172313i22549c44u22103a23cabc8cab@mail.gmail.com> <55687cf80804172325m703bbcbfs4a1ac57827395646@mail.gmail.com> <4F080DAD-2FA5-468E-AEDB-C12122C46242@w3.org> Message-ID: <480861C3.4030707@cfit.ie> Karl Dubost wrote: >> * A series of photos/descriptions. You will not be able to not if the >> description is for the picture below or above. Sometimes this is >> conveyed by the layout. When the layout is lost it will be in some cases >> hard to associate the right image with the right description. >> >> * Another issue is the description being really somewhere else in the >> page and not in the linear flow of the text. I also see the utility in use of aria-describedby and get that it is very useful for the above reasons but don't get why a relationship that is contiguous or close, or more serial is particularly prone to error?? Answers on a postcard please :-) Josh From hsivonen at iki.fi Fri Apr 18 07:06:16 2008 From: hsivonen at iki.fi (Henri Sivonen) Date: Fri, 18 Apr 2008 17:06:16 +0300 Subject: [html4all] Image Report feature in Validator.nu Message-ID: <4BCD55CF-7CC3-4034-BA41-4368C377868E@iki.fi> I don't usually announce features on mailing lists, but this one has relevance to the ongoing discussion: Validator.nu now has a feature called Image Report. It helps a sighted human user make non-computable assessments about alt--hopefully in a way that doesn't induce bogus values to the extent making the presence of alt a syntax requirement would. http://blog.whatwg.org/image-report for more information. http://html5.validator.nu/?showimagereport=yes for Validator.nu. -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/ From laura.lee.carlson at gmail.com Fri Apr 18 07:25:02 2008 From: laura.lee.carlson at gmail.com (Laura Carlson) Date: Fri, 18 Apr 2008 09:25:02 -0500 Subject: [html4all] Image Report feature in Validator.nu In-Reply-To: <4BCD55CF-7CC3-4034-BA41-4368C377868E@iki.fi> References: <4BCD55CF-7CC3-4034-BA41-4368C377868E@iki.fi> Message-ID: <1c8dbcaa0804180725t29d2ba70p32a9cece4c76e2af@mail.gmail.com> Image Report is an excellent feature, Henry. It will greatly aid accessibility education and awareness. Thank you! It doesn't solve the problem of what an authoring or publishing tool should insert, in a case where no alt has been provided by the author, but the image is known to be "critical content" but it isn't meant to do that. We will await PFWG for their wisdom on that. Thanks again. Much appreciated. Best regards, Laura From faulkner.steve at gmail.com Fri Apr 18 08:03:46 2008 From: faulkner.steve at gmail.com (Steven Faulkner) Date: Fri, 18 Apr 2008 17:03:46 +0200 Subject: [html4all] Image Report feature in Validator.nu In-Reply-To: <4BCD55CF-7CC3-4034-BA41-4368C377868E@iki.fi> References: <4BCD55CF-7CC3-4034-BA41-4368C377868E@iki.fi> Message-ID: <55687cf80804180803p5a4c9410y10d632e0cea5f5b0@mail.gmail.com> Nice One Henri, Who says the continued debate of a "rathole" topic does not sometimes yield positive results. regards steve On 18/04/2008, Henri Sivonen wrote: > I don't usually announce features on mailing lists, but this one has > relevance to the ongoing discussion: > > Validator.nu now has a feature called Image Report. It helps a sighted > human user make non-computable assessments about alt--hopefully in a > way that doesn't induce bogus values to the extent making the presence > of alt a syntax requirement would. > > http://blog.whatwg.org/image-report for more information. > http://html5.validator.nu/?showimagereport=yes for Validator.nu. > > -- > Henri Sivonen > hsivonen at iki.fi > http://hsivonen.iki.fi/ > > > > _______________________________________________ > List_HTML4all.org mailing list > http://www.html4all.org/wiki > -- with regards Steve Faulkner Technical Director - TPG Europe Director - Web Accessibility Tools Consortium www.paciellogroup.com | www.wat-c.org Web Accessibility Toolbar - http://www.paciellogroup.com/resources/wat-ie-about.html From joshue.oconnor at cfit.ie Fri Apr 18 08:11:21 2008 From: joshue.oconnor at cfit.ie (Joshue O Connor) Date: Fri, 18 Apr 2008 16:11:21 +0100 Subject: [html4all] Image Report feature in Validator.nu In-Reply-To: <4BCD55CF-7CC3-4034-BA41-4368C377868E@iki.fi> References: <4BCD55CF-7CC3-4034-BA41-4368C377868E@iki.fi> Message-ID: <4808BA19.4040600@cfit.ie> Henri Sivonen wrote: > > I don't usually announce features on mailing lists, but this one has > relevance to the ongoing discussion: Good stuff Henri. Cheers Josh From faulkner.steve at gmail.com Thu Apr 17 23:13:47 2008 From: faulkner.steve at gmail.com (Steven Faulkner) Date: Fri, 18 Apr 2008 08:13:47 +0200 Subject: [html4all] Another summary of alt="" issues and why the spec says what it says In-Reply-To: References: Message-ID: <55687cf80804172313i22549c44u22103a23cabc8cab@mail.gmail.com> Hixie wrote: >I guess, though I don't really understand what practical benefit there is >to linking the description to the image using aria-describedby. Simple really, it would provide an explicit association between the image and it description, which can be relaible conveyed to an AT user. See Ya! On 18/04/2008, Ian Hickson wrote: > > On Fri, 18 Apr 2008, Jim Jewett wrote: > > > > > Wouldn't that require that the image be described somewhere? The whole > > > point here is that we don't know what the image is. > > > > Yes -- but the description, like alt text in practice, need not be > > perfect. > > > > There are plenty of reasons that "good enough" alt text may not be > > available, but no one has come up with an example where *nothing* was > > known about the image. You just posted your four main examples, and > > there was indeed information. Not as much as we would like, but quite a > > bit more than nothing. > > > > You then said that information wasn't suitable for alt text, because it > > should be in a visible element instead -- which it could be, if > > aria-describedby were used to link the two elements. > > I guess, though I don't really understand what practical benefit there is > to linking the description to the image using aria-describedby. > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > > -- with regards Steve Faulkner Technical Director - TPG Europe Director - Web Accessibility Tools Consortium www.paciellogroup.com | www.wat-c.org Web Accessibility Toolbar - http://www.paciellogroup.com/resources/wat-ie-about.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wilbur.bytowninternet.com/pipermail/list_html4all.org/attachments/20080418/71a3ed15/attachment-0001.html From faulkner.steve at gmail.com Thu Apr 17 23:25:52 2008 From: faulkner.steve at gmail.com (Steven Faulkner) Date: Fri, 18 Apr 2008 08:25:52 +0200 Subject: [html4all] Another summary of alt="" issues and why the spec says what it says In-Reply-To: References: <55687cf80804172313i22549c44u22103a23cabc8cab@mail.gmail.com> Message-ID: <55687cf80804172325m703bbcbfs4a1ac57827395646@mail.gmail.com> >Isn't the association already pretty obvious? To you perhaps, but unless there is an explicit association it would not be *obvious* in a programmatic sense. could be wrong though. See Ya! On 18/04/2008, Ian Hickson wrote: > On Fri, 18 Apr 2008, Steven Faulkner wrote: > > Hixie wrote: > > >I guess, though I don't really understand what practical benefit there > > >is to linking the description to the image using aria-describedby. > > > > Simple really, it would provide an explicit association between the > > image and it description, which can be relaible conveyed to an AT user. > > Isn't the association already pretty obvious? I really don't understand > how this is supposed to work in a real life situation. What would the user > experience be? > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > -- with regards Steve Faulkner Technical Director - TPG Europe Director - Web Accessibility Tools Consortium www.paciellogroup.com | www.wat-c.org Web Accessibility Toolbar - http://www.paciellogroup.com/resources/wat-ie-about.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wilbur.bytowninternet.com/pipermail/list_html4all.org/attachments/20080418/878389be/attachment-0001.html From faulkner.steve at gmail.com Thu Apr 17 23:44:56 2008 From: faulkner.steve at gmail.com (Steven Faulkner) Date: Fri, 18 Apr 2008 08:44:56 +0200 Subject: [html4all] Another summary of alt="" issues and why the spec says what it says In-Reply-To: References: <55687cf80804172313i22549c44u22103a23cabc8cab@mail.gmail.com> <55687cf80804172325m703bbcbfs4a1ac57827395646@mail.gmail.com> Message-ID: <55687cf80804172344t57af406bg3253bcb2ee045478@mail.gmail.com> >I agree it wouldn't necessarily be obvious to the computer, but it's the >user that matters, and I can't really see why the association wouldn't be >obvious to the user. becasue being contiguous is a wek relationship and prone to error. for example some AT use a heauristic to work out what it thinks a label for a control is if its not explicitly associated using the for/id or title attrbute. for a text input it looks for text to the left of the input an announces that if it finds it. Works some of the time, dosn't work other times. The AT user relies on the computer (AT) to recognize the associations, thus an explcict association as supplied by the author is usually a much more robust. = utility of aria-describedby See Ya! On 18/04/2008, Ian Hickson wrote: > > On Fri, 18 Apr 2008, Steven Faulkner wrote: > > > > > > Isn't the association already pretty obvious? > > > > To you perhaps, but unless there is an explicit association it would not > > be *obvious* in a programmatic sense. could be wrong though. > > I agree it wouldn't necessarily be obvious to the computer, but it's the > user that matters, and I can't really see why the association wouldn't be > obvious to the user. > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > -- with regards Steve Faulkner Technical Director - TPG Europe Director - Web Accessibility Tools Consortium www.paciellogroup.com | www.wat-c.org Web Accessibility Toolbar - http://www.paciellogroup.com/resources/wat-ie-about.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wilbur.bytowninternet.com/pipermail/list_html4all.org/attachments/20080418/f7e8d6eb/attachment-0001.html From joshue.oconnor at cfit.ie Fri Apr 18 01:34:57 2008 From: joshue.oconnor at cfit.ie (Joshue O Connor) Date: Fri, 18 Apr 2008 09:34:57 +0100 Subject: [html4all] Another summary of alt="" issues and why the spec says what it says In-Reply-To: References: Message-ID: <48085D31.30200@cfit.ie> Ian Hickson wrote: > On Fri, 18 Apr 2008, Jim Jewett wrote: >>> Wouldn't that require that the image be described somewhere? The whole >>> point here is that we don't know what the image is. >> Yes -- but the description, like alt text in practice, need not be >> perfect. >> >> There are plenty of reasons that "good enough" alt text may not be >> available, but no one has come up with an example where *nothing* was >> known about the image. You just posted your four main examples, and >> there was indeed information. Not as much as we would like, but quite a >> bit more than nothing. >> >> You then said that information wasn't suitable for alt text, because it >> should be in a visible element instead -- which it could be, if >> aria-describedby were used to link the two elements. > > I guess, though I don't really understand what practical benefit there is > to linking the description to the image using aria-describedby. I have read the rest of the posts in this thread and I also can't see what benefit there would be in using aria-describedby in this case. Unless I am missing something, the use of @alt to provide alternate text is pretty much the same thing, the same kind of programmatic association. Cheers Josh From joshue.oconnor at cfit.ie Fri Apr 18 01:47:12 2008 From: joshue.oconnor at cfit.ie (Joshue O Connor) Date: Fri, 18 Apr 2008 09:47:12 +0100 Subject: [html4all] Another summary of alt="" issues and why the spec says what it says In-Reply-To: <55687cf80804172344t57af406bg3253bcb2ee045478@mail.gmail.com> References: <55687cf80804172313i22549c44u22103a23cabc8cab@mail.gmail.com> <55687cf80804172325m703bbcbfs4a1ac57827395646@mail.gmail.com> <55687cf80804172344t57af406bg3253bcb2ee045478@mail.gmail.com> Message-ID: <48086010.7070703@cfit.ie> Steven Faulkner wrote: >> I agree it wouldn't necessarily be obvious to the computer, but it's the >> >user that matters, and I can't really see why the association wouldn't be >> >obvious to the user. > > becasue being contiguous is a wek relationship and prone to error. I don't follow. There are plenty of elements and attributes whose relationship is contiguous or defined in a linear way and they work fine. This comment suggests that writing code in a way that defines the relationships in a "non-serial" or more lateral way is somehow better? Or am I missing something? I guess you can use of aria-describedby to create programmatic associations with content that is in order parts of the document or indeed in other resources/URIs but how is this somehow better? Cheers Josh From faulkner.steve at gmail.com Fri Apr 18 02:41:24 2008 From: faulkner.steve at gmail.com (Steven Faulkner) Date: Fri, 18 Apr 2008 11:41:24 +0200 Subject: [html4all] Another summary of alt="" issues and why the spec says what it says In-Reply-To: <48086010.7070703@cfit.ie> References: <55687cf80804172313i22549c44u22103a23cabc8cab@mail.gmail.com> <55687cf80804172325m703bbcbfs4a1ac57827395646@mail.gmail.com> <55687cf80804172344t57af406bg3253bcb2ee045478@mail.gmail.com> <48086010.7070703@cfit.ie> Message-ID: <55687cf80804180241y5c0c2265m12c8e9912932fe59@mail.gmail.com> Hi Josh, i think you maybe missing something. question - how does using aria-describedby help in this example (or rather how could it help as the expected AT behaviuor is not yet documented)

Photograph 2

View North East from 23 High Street.

AT (screen reader in this case jaws/window eyes) cannot be certain of the relationship bewteen the content of the

and the image. theer is nothing in the amrkup that says this

contains a description of the above it. announces: Photograph 2 View North East from 23 High Street. Not bad agreed. same thing with describedby added:

Photograph 2

View North East from 23 High Street.

what is known is that describebdy maps to MSAA description, so the explicit association is provided and semantic relationship is provided what is in this

is a description of 321098412.jpeg so could announce; "Photograph 2 Description View North East from 23 High Street." Since there is an explicit description relationship it the AT could now include the image in the virtual tab order for Graphics (example in JAWS using the G key a user can navigate the page via graphics that have an alt value). When the user has virtual focus on the graphic the description could be announced. "Description View North East from 23 High Street." It could also use the description to provide a label in the graphics list (In JAWS Graphics list CTRL+INSERT+G), rather than it being absent. does this provide some examples of how it could help in this example? regards steve . On 18/04/2008, Joshue O Connor wrote: > Steven Faulkner wrote: > > > > > I agree it wouldn't necessarily be obvious to the computer, but it's the > > > >user that matters, and I can't really see why the association wouldn't > be > > > >obvious to the user. > > > > > > > becasue being contiguous is a wek relationship and prone to error. > > > > I don't follow. There are plenty of elements and attributes whose > relationship is contiguous or defined in a linear way and they work fine. > This comment suggests that writing code in a way that defines the > relationships in a "non-serial" or more lateral way is somehow better? > > Or am I missing something? > > I guess you can use of aria-describedby to create programmatic associations > with content that is in order parts of the document or indeed in other > resources/URIs but how is this somehow better? > > Cheers > > Josh > > -- with regards Steve Faulkner Technical Director - TPG Europe Director - Web Accessibility Tools Consortium www.paciellogroup.com | www.wat-c.org Web Accessibility Toolbar - http://www.paciellogroup.com/resources/wat-ie-about.html From joshue.oconnor at cfit.ie Fri Apr 18 03:05:40 2008 From: joshue.oconnor at cfit.ie (Joshue O Connor) Date: Fri, 18 Apr 2008 11:05:40 +0100 Subject: [html4all] Another summary of alt="" issues and why the spec says what it says In-Reply-To: <55687cf80804180241y5c0c2265m12c8e9912932fe59@mail.gmail.com> References: <55687cf80804172313i22549c44u22103a23cabc8cab@mail.gmail.com> <55687cf80804172325m703bbcbfs4a1ac57827395646@mail.gmail.com> <55687cf80804172344t57af406bg3253bcb2ee045478@mail.gmail.com> <48086010.7070703@cfit.ie> <55687cf80804180241y5c0c2265m12c8e9912932fe59@mail.gmail.com> Message-ID: <48087274.4030702@cfit.ie> Steven Faulkner wrote: > does this provide some examples of how it could help in this example? Thanks for that Steve. So it seem to me that the use of the aria described can be added to many elements like

, or etc. >

Photograph 2

> >

View North East from 23 High Street.

[...] > announces: > Photograph 2 View North East from 23 High Street. > Not bad agreed. That would only be the case if the screen reader user was using SAY ALL or using the cursor keys to go through the content in a linear manner. So normally to create the programmatic association you would use @alt like this: View North East from 23 High Street. > what is known is that describebdy maps to MSAA description, so the > explicit association is provided and semantic relationship is provided > what is in this

is a description of 321098412.jpeg > > so could announce; > > "Photograph 2 Description View North East from 23 High Street." [...] > It could also use the description to provide a label in the graphics > list (In JAWS Graphics list CTRL+INSERT+G), rather than it being > absent. > > does this provide some examples of how it could help in this example? It does in terms of what aria described by is useful for, it is the point that a contiguous relationship such as that defined by View North East from 23 High Street. being somehow prone to error that I don't understand. Cheers Josh From lhs at malform.no Sat Apr 19 09:09:26 2008 From: lhs at malform.no (Leif Halvard Silli) Date: Sat, 19 Apr 2008 18:09:26 +0200 Subject: [html4all] Another summary of alt="" issues and why the spec says what it says In-Reply-To: References: Message-ID: <480A1936.2050402@malform.no> Ian Hickson 08-04-18 02.47: ? > On Thu, 17 Apr 2008, Jim Jewett wrote: > > > > > > ... sometimes there simply is no alternative text available. Examples > > > I can think of that have been mentioned so far include: > > > > > > * Images uploaded by a blind user before that user has had a chance > > > to ask his friends to describe the images to him. > > > > Unlabeled Photo 3, taken on 2008-04-17. > > That would be a fine caption -- but as it should be visible to everyone, > not just those who can't see the image, it doesn't consist of good > alternative text (since if the alt attribute had this value, you'd be > saying stuff twice for the users who use alt text, which is worse than > saying it once). > [ snipped losts of same thing examples ] What you are saying here, Ian, is that it would be better user experience for a sighted, if this text was was used as a caption. And when you talk about "saying stuff twice", you calculates in, that it should have been used as captions. But, 1. To say that it should be in the caption, is an author advice. Authors are not obligued to staff images with captions and headers. In fact, there can be many times where the author prefers to not do that at all. After all, the sighted can see the image anyhow. And there might be other things in the page giving the sighted (enough) context. 2. Speaking about how much work it is (2 days per week for a professional photographer, I think yhou said) adding alt text, it would not be less work adding the same text as caption. In fact, it could be more work adding a separate element thant it would be adding a text inside @ALT. What is simplest for the author, depends on the tool, the design of the page and so on and so forth. [And thus, the fact that Explorer has showed @ALT text as tool-tips can, as someone was mentioning, have had an effect on the use of alt.] 3. This doesn't really help anyone, but it can just as well be the caption or the header that is a duplicate of the ALT text. As the opposite. This depends of what is written first. In an off-list reply to me, you, Ian, again pointed to the below paragraph from WCAG 2 [1], as an example of a WCAG text requiring duplicate ALT text (you and Steve allready discussed this text a few times, so I think I do no harm mentioning that you took it up with me off-list ? you have also expressed roughly the same thing in public a few times): "Sometimes content is primarily intended to create a specific sensory experience that words cannot fully capture. Examples include a symphony performance, works of visual art etc. For such content, text alternatives at least identify the non-text content with a descriptive label and where possible, some descriptive text. If the reason for including the content in the page is known and can be described it is helpful to include that information." When you feared that the above WCAG 2 advice could lead to duplicate alt text, then - again - it must have been that you were calculating in that, whatever the alt text said, would also - or should instead - be said in a header or an caption. However, I think there for the most part is agreement that the above WCAG 2 text speaks about a use case where adding an image caption or image header would harm the experience for the sighted user. Or - and this is the same thing - where the *author* did not want to disturb the pure image experience or the pure sound/video performance experience (quote: "a symphony performance") with a caption or a header. The above advice for instance goes against offering a direct link to 'great_painting.jpg', for those that want to experience a full page version of the the image. On should instead offer a real web page with an embedded 'great_painting.jpg' and an alt text for it. Related but not the same thing - and hitherto unsolved in HTML 5: The above text also speaks about having replacement text for audio content. (Allthough, it would perhaps be possible to use

if one hid the caption or something.) [1] http://www.w3.org/TR/2007/WD-UNDERSTANDING-WCAG20-20071211/text-equiv-all.html -- leif halvard silli From lhs at malform.no Sun Apr 20 00:29:43 2008 From: lhs at malform.no (Leif Halvard Silli) Date: Sun, 20 Apr 2008 09:29:43 +0200 Subject: [html4all] Another summary of alt="" issues and why the spec says what it says In-Reply-To: <55687cf80804180241y5c0c2265m12c8e9912932fe59@mail.gmail.com> References: <55687cf80804172313i22549c44u22103a23cabc8cab@mail.gmail.com> <55687cf80804172325m703bbcbfs4a1ac57827395646@mail.gmail.com> <55687cf80804172344t57af406bg3253bcb2ee045478@mail.gmail.com> <48086010.7070703@cfit.ie> <55687cf80804180241y5c0c2265m12c8e9912932fe59@mail.gmail.com> Message-ID: <480AF0E7.1020308@malform.no> Steven Faulkner in reply to Joshue's question 2008-04-18 11.41: > question - how does using aria-describedby help in this example (or > rather how could it help as the expected AT behaviuor is not yet > documented) > >

Photograph 2

> >

View North East from 23 High Street.

> > AT [...] cannot be certain of the relationship [...] > Indeed. and

*could* be unrelated to each others. > same thing with describedby added: > >

Photograph 2

> >

View North East from 23 High Street.

> [Snipped the aria-describedby=idref programmatic association benefits.] The aria-describedby approach adds new, hidden, meta information whic must be kept in order. Instead, I'd like to propose these solution: 1. Reserved keywords acting as CSS selectors: Elements with an ALT attribute or fallback content could have reserved keywords which would point to the element containing its description: A "_prev" keyword could point to previous element, a "_next" to next element, a "_parent" to the parent element. For FIGURE, keywords are not needed and should not be taken account of, as long as FIGURE only contains LEGEND plus one single, embedding element. But if there are more elements in FIGURE, then the keyword could link the IMG to a particular other element inside FIGURE. Or, if there are less elements (= only one IMG, and thus no LEGEND), then the keyword could link to outside the FIGURE element. Option: The _parent and _next keywords could possibly be joined into just one "_auto" keyword. Alternative syntax: _ for _auto, _* for _parent, _+ for _next and _- for _prev. Pros: 1) If one adds lots of images in a repeated pattern of etc, then this method could be effective. 2) It is also possibly useful for hand coders. 3) It supports the (current) requirement of obligatory alt text. 4) It doesn't use a new IDREF based meta information attribute which must be kept in order. Example:

Photograph 2

_next

View North East from 23 High Street.

2. Automatic IMG description via TITLE or ALT matching: Looking at how HTML 5's Automatic cross-referencing works, and leaning towards what web authors are used to when it comes to IMG - and the errors they commit (duplicate ALT texts), we could define an automatic feature where the programmatic association is achieved via a match between a describing element's content or TITLE attribute, and the TITLE or ALT content of the described IMG (the *nearest* match). And just as for the auto cross-ref feature, we must define which elements can be used as captions (I propsoe only P and H1-H6). Just like aria-describedby, this approach would work for all embedding elements. Yes, I know that for the IMG element, I turn the issue of "duplicate alt text" on its head. AT must learn to tacle such duplicate alt text. Or, one could argue that the best thing would be to use the TITLE attribute of the embedding element. For users of graphic User Agents, such a rule should not be much of a problem. For instance, getting the same TITLE for e.g. both e.g. a VIDEO element and a captioning element, could help draw the conclusion that the elements belong together, and perhaps give the impression that they are one and the same element. This feature could work in tandem with the reserved keyword selectors. A reserved keyword selector would take presendence over this method. Examples: 1)

Photograph 2

View North East from 23 High Street.

View North East from 23 High Street.

2)

Photograph 2

Photograph 2

View North East from 23 High Street.

3) Here, could argue that it would be wrong using alt="", as it gives a conflicting message:

Photograph 2

View North East from 23 High Street.

4)

Photograph 2

photo 2

View North East from 23 High Street.

-- leif halvard silli From lhs at malform.no Sun Apr 20 15:10:44 2008 From: lhs at malform.no (Leif Halvard Silli) Date: Mon, 21 Apr 2008 00:10:44 +0200 Subject: [html4all] Another summary of alt="" issues and why the spec says what it says In-Reply-To: References: <55687cf80804172313i22549c44u22103a23cabc8cab@mail.gmail.com> <55687cf80804172325m703bbcbfs4a1ac57827395646@mail.gmail.com> <55687cf80804172344t57af406bg3253bcb2ee045478@mail.gmail.com> <48086010.7070703@cfit.ie> <55687cf80804180241y5c0c2265m12c8e9912932fe59@mail.gmail.com> <480AF0E7.1020308@malform.no> Message-ID: <480BBF64.6060501@malform.no> Jim Jewett 08-04-20 22.44: ? > On 4/20/08, Leif Halvard Silli wrote: > > > [Snipped the aria-describedby=idref programmatic association benefits.] > > > The aria-describedby approach adds new, hidden, meta > > information whic must be kept in order. > > True. > > > Instead, I'd like to propose these solution: > > > 1. Reserved keywords acting as CSS selectors: > > Elements with an ALT attribute or fallback content could have reserved > > keywords which would point to the element containing its description: A > > "_prev" keyword could point to previous element, a "_next" to next element, > > a "_parent" to the parent element. > > Unfortunately, so does this -- and the burden is higher, and the > burder is higher. It would not longer be enough to to update the > metadata when you change the element itself (or the pointed-to > element), you would also have to worry about whether someone inserted > a new element in between. > Of course it could be done via updating the meta data. In my post, I merely thought about the most obvious description selectors, and tried to show that one could come a long way only with them. But if one are interested in following this path, then such "alt=_selectors" could be made just as advanced as CSS selectors, and thuse _more_ advanced than I pereive aria-describedby to be. Personally, I think it is a greater risk that a

would become invalid, than there is a risk that _next becomes invalid. The author of course placed the description near the image because that is where it is most often logical to keep them. And when the author sees that something which doesn't describe the image creeped between the image and the description, then he is likely to want to correct that, rather than wanting to keep the description far away from the image. > > For FIGURE, keywords are not needed and > > should not be taken account of, as long as FIGURE only contains LEGEND plus > > one single, embedding element. > > WCAG agrees that this would be sufficient if it were part of the > definition of those elements. > > I would still prefer to see it expressed in terms of aria-describedby, > perhaps as: > > """ > If a figure contains exactly one multimedia element (image, video, > audio, or object), and exactly one textual element (caption, legend, > span, div, p), then there is a weakly implied aria-describedby > relationship from the multimedia element to the textual element. > > This relationship is overridden if there is an explicit > aria-describedby relationship. > """ > I think at the *very* least, the special role of FIGURE's caption element - namely the legend element, must be acknowledged: If there is exactly one multimededia element and one legend elment, then the implied aria-describedby relationship is *strong*. > and I would still like the alt (or fallback) to be mandatory unless > there is a (possibly implied) aria-describedby attribute. > I have problems with understanding why not instead let the association be done via identifying a class (something like aria-describedby=class) or selector rather by identifying a certain idref. -- leif halvard silli From lhs at malform.no Sun Apr 20 19:04:31 2008 From: lhs at malform.no (Leif Halvard Silli) Date: Mon, 21 Apr 2008 04:04:31 +0200 Subject: [html4all] Another summary of alt="" issues and why the spec says what it says In-Reply-To: References: <55687cf80804172325m703bbcbfs4a1ac57827395646@mail.gmail.com> <55687cf80804172344t57af406bg3253bcb2ee045478@mail.gmail.com> <48086010.7070703@cfit.ie> <55687cf80804180241y5c0c2265m12c8e9912932fe59@mail.gmail.com> <480AF0E7.1020308@malform.no> <480BBF64.6060501@malform.no> Message-ID: <480BF62F.4020000@malform.no> Jim Jewett 21-04-08 01:57: ? > [Individual Cc removed; not sure which lists to trim] > > On 4/20/08, Leif Halvard Silli wrote: > > Jim Jewett 08-04-20 22.44: ? > > > > On 4/20/08, Leif Halvard Silli wrote: > > > > > [Snipped the aria-describedby=idref programmatic association benefits.] > > > > > 1. Reserved keywords acting as CSS selectors: > > > > Elements with an ALT attribute or fallback content could have reserved > > > > keywords which would point to the element containing its description: A > > > > "_prev" keyword could point to previous element, a "_next" to next > > element, > > > > a "_parent" to the parent element. > > ... > > > In my post, I merely thought about the most obvious description selectors, > > and tried to show that one could come a long way only with them. But if one > > are interested in following this path, then such "alt=_selectors" could be > > made just as advanced as CSS selectors, and thuse _more_ advanced than I > > pereive aria-describedby to be. > > Ahh. That is interesting, particularly since most user agents needs > to implement CSS selectors anyhow. > > > Personally, I think it is a greater risk that a

would > > become invalid, than there is a risk that _next becomes invalid. > > The risk isn't that alt=_next will become a dangling pointer; the risk > is that it will start pointing to a different (and wrong) element. > Since it still points to something, automatic tools won't show the > problem. Since it only applies to alt (which isn't typically > visible), most designers won't notice on their own. > By 'automatic toools won't show the problem', do you mean that you can't use a validator or something to check whether there is a match? At any rate, relying on predefined selectors for the ALT attribute would make it quite simple for web designers to perform their own tests via CSS. For instance, if I want to see if my choice of using alt=_next was correct for all the images I have applied it to, then I could use this CSS style: img[alt="_next"]+*{border:red dashed thick} or if I used the _prev keyword: *+img[alt="_prev"]{border:red dashed thick} And such a thing would also be simple to use in Henri's validator, I suppose. With aria-describedby=, however, since it contains a idrefs, and since idrefs can look any way you want, it becomes more cumbersome to check, via CSS. And also, just getting a match is only a ID match. The content of that element might still not match. > > I have problems with understanding why not instead let the association be > > done via identifying a class (something like aria-describedby=class) or > > selector rather by identifying a certain idref. > > Would you want 10 elements to all act collectively as the description? > Would it be useful, anyhow, to link 10 paragraph to the same image? I guess my thought involved that the author could apply a class to a description container, and that one would specify that the first (or all ?) elments with this class, before the next embedded object appeared, would describe the image. However, there is then not very much difference between this thought, and what I said about an "alt _selector". Even an alt _selector could look for a class, if we defined the syntaxt for it. > Maybe, but I'm not sure how easy that would be for a UA to handle. > > I also suspect we would get quite a few pages like > > _class_photocap >

...
> _class_photocap >
...
> _class_photocap > > So which description goes with which photo? > To make it more CSS selector like, I would perhaps proposed something like this: _next div.photocap And if so, then it should be obvious that the last IMG above did not have any description. While if I meant ths: _prev div.photocap Then only the first IMG would be without a description. Finally, som questions and claims about aria-describedby: Steve explained aria-describedby= by comparing it to how for=/id= work for the LABEL element. And it is a matter of fact that several LABEL elements can point to the same ID. (I now also see that aria-describedby can even point to *several* IDREFS, which makes it more similar headers= than to the for= attribute.) Thus, I assume that aria-describedby= could also point to the same description. And thus I foresee that a very simple solution for some, could be, if they have 1000 photos, to let all of them point to the same description. Voila, case closed. A test would render it valid. But, it is then I starts to wonder about the programmatic link between image and description that Steve talked about. If the same ID can actually be pointed to from several images, then we should also, as well, be able to say that the LEGEND of FIGURE should create a programmatic, allthough identical, label for all the embedded elements inside the FIGURE element. -- leif halvard silli From lhs at malform.no Wed Apr 23 19:54:51 2008 From: lhs at malform.no (Leif Halvard Silli) Date: Thu, 24 Apr 2008 04:54:51 +0200 Subject: [html4all] [whatwg] Feeedback on , , and other elements related to cross-references In-Reply-To: <20080423223717.GB5815@stripey.com> References: <86k5rpb7xh.fsf@rakim.cfhp.org> <580990fe0804231036g7f22951fna43e02007a08afd@mail.gmail.com> <20080423223717.GB5815@stripey.com> Message-ID: <480FF67B.2050803@malform.no> Note about process: It is about time the HTMLWg start keeping just one INBOX. The Chairs could lead the way by unsubscribing from the WHATwg list. Background: It is very demotivating and time wasting when the editor announces decissions about dropping mayor new inventions of HTML 5 (automatic cross-referencing) on another list (WHATwg), and discusses it there **for 3 days** [1] before bringing it to the attention of the HTML working group listees [2]. It surprises me that the W3 voluntarelly allows itself and its working group members to be insulted in that way, which happens over and over. Any host (W3) must demand a minimum of order in its house. Or else it will start to loose respect, selfrespect and loyalty. The rest of this letter is about the cross-references. Smylers 24-04-08 00:37: ? > Nicholas Shanks writes: > > 2008/4/23 Ian Hickson : > > > > On Mon, 21 Apr 2008, Nicholas Shanks wrote: > > > > > > > > We need to go through this more methodically before making a decision. I > > > > hope the following aids matters. > > > > > > More methodically than > > > > > > http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-April/014470.html > > > > > > ...? I'm not sure exactly what you have in mind! :-) > Is that the really the best you can think of? > > What I meant was you were just addressing people's points as they came > > up. > > That is very methodical; it ensures that every point brought up gets > considered. > > > If we want to do this properly we need to ensure we have covered every > > aspect from the beginning. > snip > > Set up a focus group or something :) > > What could a focus group say [snip] > Very good suggestions, Nicholas. > > > > Situations where expansions of abbreviations are needed: It should > > > > not be required that the user screw around looking for the acronym > > > > with a dotted underline. > > > > > > Abbreviations are no more special here than any term of art. > The automatatic cross-referencing feature does/did not only cover ABBR, so that point is moot. By disabling the cross-referencing feature, HTML 5 suddenly became a whole lot more boring. What is the motivation for marking up anything correctly as SAMP, VAR, ABBR, I etc, with the different semantics assessed, if, in the end, I can just instead use a single : > An a element that links to a dfn element represents an instance of > the term defined by the dfn element. This ultimately means that one can skip using those elements. > > > It's quite obvious that the "BAR" in "RAISE THE BAR" is not an > > > acronym. > > > > Only if you know English. ('you' being the User Agent who has to > > decide how to expand/pronounce it). Great point. As Henri has said [3]: One cannot expect the UA to be able to include for instance warning text etc in more than one langauge - namely that of the user interface. > > It is not reasonable to expect > > UAs, other than perhaps TTS engines, to correctly identify this. > > Why would a user-agent that isn't speaking need to correctly identify > it? > In order to help its user. > > And to the person who suggested it be written in lowercase, I > > explicitly said it was a newspaper headline. > > That was me. Sorry, I interpreted that to mean a headline on a > newspaper's website; I hadn't realized you meant transcribing from a > printed newspaper. > Transcribing or not is entirely off the point. > > You should not change the case of printed material when transferring > > it to electronic form, reproductions should be faithful to the > > original, and use uppercase characters rather than style > > transformations (since they might not get applied). > And not only that: It might be common in English to write UN as U.N. in some situation - I don't know - but that would be an entirely English tradition. Not applicable outside the English lanaguage sphere. > On that basis one could argue for not transcribing it at all, [... etc ...] > LaTeX and TeX is not the correct way of writing those words. But the alternative to writing them correct, is not to not write them. THere are conventions. Again, if U.N. is the right English way of doing it, then please do. [1] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-April/014470.html [2] http://lists.w3.org/Archives/Public/public-html/2008Apr/0707.html [3] http://lists.w3.org/Archives/Public/public-html/2008Apr/0723.html -- leif halvard silli From lhs at malform.no Wed Apr 23 20:43:46 2008 From: lhs at malform.no (Leif Halvard Silli) Date: Thu, 24 Apr 2008 05:43:46 +0200 Subject: [html4all] ACRONYM and ABBR Message-ID: <481001F2.4080801@malform.no> What do the AT professionals of our group think in general about the removal of ACRONYM from HTML, as proposed in HTML 5? Currently, it is proposed to drop the requirement of @TITLE for the ABBR element. I imagine that such a solution makes it more needed to have the ACRONYM element included, or else the acronym will be read as if it is an abbreviation. -- leif halvard silli From jason at jasonjgw.net Wed Apr 23 21:06:20 2008 From: jason at jasonjgw.net (Jason White) Date: Thu, 24 Apr 2008 14:06:20 +1000 Subject: [html4all] ACRONYM and ABBR In-Reply-To: <481001F2.4080801@malform.no> References: <481001F2.4080801@malform.no> Message-ID: <20080424040620.GA22010@jpc.local> On Thu, Apr 24, 2008 at 05:43:46AM +0200, Leif Halvard Silli wrote: > What do the AT professionals of our group think in general about the > removal of ACRONYM from HTML, as proposed in HTML 5? > It would be better to have only one element, as then the interminable disagreements and confusions surrounding the acronym/abbreviation distinction are eliminated. > Currently, it is proposed to drop the requirement of @TITLE for the ABBR > element. While I think @title should be supported, I am not convinced that its use should be mandatory - that it should be a required attribute. According to the HTML 4.01 DTD, it is not required; rather, it is #implied. Dropping @title altogether from ABBR would be a bad move, as there would then be no place to record the expansion of the abbreviation. From lhs at malform.no Wed Apr 23 22:08:45 2008 From: lhs at malform.no (Leif Halvard Silli) Date: Thu, 24 Apr 2008 07:08:45 +0200 Subject: [html4all] ACRONYM and ABBR In-Reply-To: <20080424040620.GA22010@jpc.local> References: <481001F2.4080801@malform.no> <20080424040620.GA22010@jpc.local> Message-ID: <481015DD.6020504@malform.no> Jason White 24-04-2008 06:06: ? > On Thu, Apr 24, 2008 at 05:43:46AM +0200, Leif Halvard Silli wrote: > > What do the AT professionals of our group think in general about the > > removal of ACRONYM from HTML, as proposed in HTML 5? > > > > It would be better to have only one element, as then the interminable > disagreements and confusions surrounding the acronym/abbreviation distinction > are eliminated. > True. > > Currently, it is proposed to drop the requirement of @TITLE for the ABBR > > element. > > While I think @title should be supported, I am not convinced that its use > should be mandatory - that it should be a required attribute. According to the > HTML 4.01 DTD, it is not required; rather, it is #implied. > Then you agree with the current draft, which makes @title optional. I cannot see from HTML 4.01, however, that @title is #implied. > Dropping @title altogether from ABBR would be a bad move, as there would then > be no place to record the expansion of the abbreviation. > One view is that no @title means that the abbreviaiton is an acronym. [1] However, when I tested VoiceOver and Fire Vox, it turned out that ACRONYM and ABBR elements were read the same way. Thus, NATO was read Enn,Ay,Tee,Oh. Which leads me to assume that acronyms are not read as acronyms anyhow, and thus AT users are happy with acronyms being marked up as ABBR. Right? [1] http://lists.w3.org/Archives/Public/public-html/2008Apr/0725.html -- leif halvard silli From jason at jasonjgw.net Wed Apr 23 22:22:01 2008 From: jason at jasonjgw.net (Jason White) Date: Thu, 24 Apr 2008 15:22:01 +1000 Subject: [html4all] ACRONYM and ABBR In-Reply-To: <481015DD.6020504@malform.no> References: <481001F2.4080801@malform.no> <20080424040620.GA22010@jpc.local> <481015DD.6020504@malform.no> Message-ID: <20080424052200.GA24366@jpc.local> On Thu, Apr 24, 2008 at 07:08:45AM +0200, Leif Halvard Silli wrote: > Then you agree with the current draft, which makes @title optional. I > cannot see from HTML 4.01, however, that @title is #implied. ABBR and ACRONYM are defined as phrase elements in the DTD (via an entity). The attlist is specified as including coreattrs, which declares TITLE as #implied. From joshue.oconnor at cfit.ie Thu Apr 24 01:23:06 2008 From: joshue.oconnor at cfit.ie (Joshue O Connor) Date: Thu, 24 Apr 2008 09:23:06 +0100 Subject: [html4all] ACRONYM and ABBR In-Reply-To: <481015DD.6020504@malform.no> References: <481001F2.4080801@malform.no> <20080424040620.GA22010@jpc.local> <481015DD.6020504@malform.no> Message-ID: <4810436A.70406@cfit.ie> Leif Halvard Silli wrote: > Jason White 24-04-2008 06:06: ? [...] >> It would be better to have only one element, as then the interminable >> disagreements and confusions surrounding the acronym/abbreviation distinction >> are eliminated. >> > > True. Agreed. However, If support was better for then I think it is a fine useful element. > Which leads me to assume that acronyms are not read as acronyms anyhow, > and thus AT users are happy with acronyms being marked up as ABBR. Right? I think so. It is mostly nerds who get in a flap about such things. Cheers Josh From rob at robburns.com Thu Apr 24 03:25:45 2008 From: rob at robburns.com (Robert J Burns) Date: Thu, 24 Apr 2008 12:25:45 +0200 Subject: [html4all] ACRONYM and ABBR In-Reply-To: <4810436A.70406@cfit.ie> References: <481001F2.4080801@malform.no> <20080424040620.GA22010@jpc.local> <481015DD.6020504@malform.no> <4810436A.70406@cfit.ie> Message-ID: On Apr 24, 2008, at 7:08 AM, Leif Halvard Silli wrote: > One view is that no @title means that the abbreviaiton is an > acronym. [1] > > However, when I tested VoiceOver and Fire Vox, it turned out that > ACRONYM and ABBR elements were read the same way. Thus, NATO was read > Enn,Ay,Tee,Oh. > > Which leads me to assume that acronyms are not read as acronyms > anyhow, > and thus AT users are happy with acronyms being marked up as ABBR. > Right? Something like NATO should be pronounced by AT as "Nay - tow" whether or not it is marked up with ABBR of ACRONYM. Pronunciations like that should be drawn from a pronunciation dictionary for the product (in the same way word processors have spelling dictionaries). ABBR should be reserved for either abbreviations not widely used or newly coined abbreviations. In such cases more information than simply pronouncing it as a word is needed (is "Nah - two" or "Nat - oh" or "Nay - toe", etc.). The wiki proposal I drafted with the cooperation of others provides the needed hooks for that[1] On Apr 24, 2008, at 10:23 AM, Joshue O Connor wrote: > Leif Halvard Silli wrote: >> Jason White 24-04-2008 06:06: > [...] >>> It would be better to have only one element, as then the >>> interminable >>> disagreements and confusions surrounding the acronym/abbreviation >>> distinction >>> are eliminated. >>> >> >> True. > > Agreed. However, If support was better for then I think it > is > a fine useful element. I think the problem Jason refers to here is not related to support for ACRONYM. They problem is that the distinction between acronyms and abbreviations is not great enough to warrant separate elements. It would be better to simply markup unusual abbreviated forms and then provide pronunciation hints which is the only significant semantic distinction an author wants to make here. >> Which leads me to assume that acronyms are not read as acronyms >> anyhow, >> and thus AT users are happy with acronyms being marked up as ABBR. >> Right? > > I think so. It is mostly nerds who get in a flap about such things. > Agreed, which is why I don't think we need to continue having separate elements. Take care, Rob [1]: From lhs at malform.no Thu Apr 24 05:52:05 2008 From: lhs at malform.no (Leif Halvard Silli) Date: Thu, 24 Apr 2008 14:52:05 +0200 Subject: [html4all] ACRONYM and ABBR In-Reply-To: References: <481001F2.4080801@malform.no> <20080424040620.GA22010@jpc.local> <481015DD.6020504@malform.no> <4810436A.70406@cfit.ie> Message-ID: <48108275.8080700@malform.no> Robert J Burns 24-04-08 12:25: ? > On Apr 24, 2008, at 7:08 AM, Leif Halvard Silli wrote: > > > when I tested VoiceOver and Fire Vox, [...] NATO was read > > Enn,Ay,Tee,Oh. [...] > > Something like NATO should be pronounced by AT as "Nay - tow" whether > or not it is marked up with ABBR of ACRONYM. Both VoiceOver and Fire Vox reads NATO roughly the same way, regardless of whether it is marked up as ABBR or not, > Pronunciations like that > should be drawn from a pronunciation dictionary for the product (in > the same way word processors have spelling dictionaries). Seems like Fire Vox and VoiceOver have such a dictionary. > ABBR should > be reserved for either abbreviations not widely used or newly coined > abbreviations. That rule only seems meaningful if the sole purpose of the ABBR is to tell how it should be pronounced or be expanded. > In such cases more information than simply pronouncing > it as a word is needed (is "Nah - two" or "Nat - oh" or "Nay - toe", > etc.). The wiki proposal I drafted with the cooperation of others > provides the needed hooks for that[1] > Could be useful. > >> Which leads me to assume that acronyms are not read as acronyms > >> anyhow, and thus AT users are happy with acronyms being marked up > >> as ABBR. Right? > > > > I think so. It is mostly nerds who get in a flap about such things. > > > > Agreed, which is why I don't think we need to continue having separate > elements. > I don't feel I need to say anything negative about nerds to agree to this. Thus I agree. -- leif halvard silli From rob at robburns.com Fri Apr 25 05:40:51 2008 From: rob at robburns.com (Robert J Burns) Date: Fri, 25 Apr 2008 14:40:51 +0200 Subject: [html4all] Fwd: ACRONYM and ABBR References: Message-ID: Another thing I meant to say in this message about ABBR and ACRONYM is that for the example Leif gave, the HTML5 recommendation (and any other recommendation where it's relevant) should be pushing UAs to include such dictionaries to get the pronunciation of acronyms right (even when not marked up). The other thing that occurs to me after Leif raises the issue again is that a dramatic step that might drive home the point that authors should only markup abbreviations and acronyms in exceptional circumstances would be to deprecate both elements (ABBR and ACRONYM) and advise authors to use DFN for marking up the defining instance of any term, including exceptional abbreviations or acronyms requiring such definition. Take care, Rob Begin forwarded message: > From: Robert J Burns > Date: April 24, 2008 12:25:45 PM GMT+02:00 > To: HTML4All > Subject: Re: [html4all] ACRONYM and ABBR > Reply-To: HTML4All > > > On Apr 24, 2008, at 7:08 AM, Leif Halvard Silli wrote: >> One view is that no @title means that the abbreviaiton is an >> acronym. [1] >> >> However, when I tested VoiceOver and Fire Vox, it turned out that >> ACRONYM and ABBR elements were read the same way. Thus, NATO was read >> Enn,Ay,Tee,Oh. >> >> Which leads me to assume that acronyms are not read as acronyms >> anyhow, >> and thus AT users are happy with acronyms being marked up as ABBR. >> Right? > > Something like NATO should be pronounced by AT as "Nay - tow" whether > or not it is marked up with ABBR of ACRONYM. Pronunciations like that > should be drawn from a pronunciation dictionary for the product (in > the same way word processors have spelling dictionaries). ABBR should > be reserved for either abbreviations not widely used or newly coined > abbreviations. In such cases more information than simply pronouncing > it as a word is needed (is "Nah - two" or "Nat - oh" or "Nay - toe", > etc.). The wiki proposal I drafted with the cooperation of others > provides the needed hooks for that[1] > > > On Apr 24, 2008, at 10:23 AM, Joshue O Connor wrote: > >> Leif Halvard Silli wrote: >>> Jason White 24-04-2008 06:06: >> [...] >>>> It would be better to have only one element, as then the >>>> interminable >>>> disagreements and confusions surrounding the acronym/abbreviation >>>> distinction >>>> are eliminated. >>>> >>> >>> True. >> >> Agreed. However, If support was better for then I think it >> is >> a fine useful element. > > I think the problem Jason refers to here is not related to support for > ACRONYM. They problem is that the distinction between acronyms and > abbreviations is not great enough to warrant separate elements. It > would be better to simply markup unusual abbreviated forms and then > provide pronunciation hints which is the only significant semantic > distinction an author wants to make here. > >>> Which leads me to assume that acronyms are not read as acronyms >>> anyhow, >>> and thus AT users are happy with acronyms being marked up as ABBR. >>> Right? >> >> I think so. It is mostly nerds who get in a flap about such things. >> > > Agreed, which is why I don't think we need to continue having separate > elements. > > Take care, > Rob > > [1]: > > _______________________________________________ > List_HTML4all.org mailing list > http://www.html4all.org/wiki -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wilbur.bytowninternet.com/pipermail/list_html4all.org/attachments/20080425/b4a8bb58/attachment.html From oedipus at hicom.net Sun Apr 27 08:02:03 2008 From: oedipus at hicom.net (Gregory J. Rosmaita) Date: Sun, 27 Apr 2008 16:02:03 +0100 Subject: [html4all] ACRONYM and ABBR In-Reply-To: <20080424040620.GA22010@jpc.local> References: <481001F2.4080801@malform.no> <20080424040620.GA22010@jpc.local> Message-ID: <20080427144743.M713@hicom.net> aloha! the "title" element is ESSENTIAL and MUST be REQUIRED for ABBR for the #implied mechanism not only doesn't work, it is illogical when applied to abbreviated forms, as there are many abbreviated forms that share the same combination of letters, but which represent completely different words/concepts: ADA can be expanded to: * Americans With Disabilities Act * American Dental Association * American Diabetes Association * American Dietetic Association * the programming language "ADA" (named for Ada Lovelace) what is needed, therefore, to make "title" an OPTIONAL attribute -- AFTER the first REQUIRED declaration of an ABBR -- is a FOR/ID mechanism for reuse of the expansion for the abbreviated form; moreover, there are thousands of acronyms that overlap, as discussed in: HTML Needs Initialisms: http://esw.w3.org/topic/HTML/AbbrAndInitialisms the same re-use problem applies to DFN as well -- if one encases an abbreviated form in an abbr without a title, but encases the ABBR in a DFN element, then it is the DFN element that needs a reuse mechanism, and the optimal solution is not JUST the use of title for both, but a reuse mechanism that is universal, not merely document specific... the first instance of an ABBR or DFN MUST be glossed with an expansion via the "title" attribute, as well as an ID so that further incidents of the ABBR or DFN can be bound to an initial expansion; obviously, a means of referring to an external resource containing a site-wide table of abbreviation and definition expansions is a superior mechanism and that is the issue upon which we should be concentrating... gregory. ------------------------------------------------------ It is better to ask some of the questions than to know all the answers. -- James Thurber ------------------------------------------------------ Gregory J. Rosmaita, oedipus at hicom.net Camera Obscura: http://www.hicom.net/~oedipus Oedipus' Online Complex: http://my.opera.com/oedipus ------------------------------------------------------ From oedipus at hicom.net Sun Apr 27 08:16:28 2008 From: oedipus at hicom.net (Gregory J. Rosmaita) Date: Sun, 27 Apr 2008 16:16:28 +0100 Subject: [html4all] providing proper pronunciation for abbreviated forms In-Reply-To: References: <481001F2.4080801@malform.no> <20080424040620.GA22010@jpc.local> <481015DD.6020504@malform.no> <4810436A.70406@cfit.ie> Message-ID: <20080427150343.M32049@hicom.net> aloha, rob! pronunciation rules for the ennunciation of abbreviated forms should be controlled by aural stylesheets, including instructions to AT how to pronounce an acronym or expansion -- the reason you hear the acronym spelt out is that that is the default setting for most screen readers -- in the case of FireVox, if the page has CSS3 speech properties http://www.w3.org/TR/css3-speech/ applied to it, one can control: 1. speak: - default value 'normal' | 'spell-out' (this is backwards compatible with CSS2/CSS2.1) 2. phonemes, @phonetic-alphabet, and content http://www.w3.org/TR/css3-speech/#phonetic-props so, in the case of NATO, one would use the CSS3 Speech Module's phoneme property, the default alphabet for which is comprised of the unicode values for the international phonetic alphabet (IPA) IPA in Unicode / Unicode and IPA * general: http://unicode.org/press/quotations.html * comprehensive: http://www.phon.ucl.ac.uk/home/wells/ipa-unicode.htm this is something, i suppose, i ought to add to the HTML wiki pages on abbreviated forms, although i have argued in the past that it isn't just screen readers who may need a pronunciation guide, but those for whom the document's natural language is a secondary or tertiary language gregory. -------------------------------------------------------------- I love Americans, but not when they try to talk French. What a blessing it is that they never try to talk English. -- Saki (HH Munro), "The Chronicles of Clovis" -------------------------------------------------------------- Gregory J. Rosmaita, oedipus at hicom.net Camera Obscura: http://www.hicom.net/~oedipus/ Oedipus' Online Complex: http://my.opera.com/oedipus/ -------------------------------------------------------------- ---------- Original Message ----------- From: Robert J Burns To: HTML4All Sent: Thu, 24 Apr 2008 12:25:45 +0200 Subject: Re: [html4all] ACRONYM and ABBR > On Apr 24, 2008, at 7:08 AM, Leif Halvard Silli wrote: > > One view is that no @title means that the abbreviaiton is an > > acronym. [1] > > > > However, when I tested VoiceOver and Fire Vox, it turned out that > > ACRONYM and ABBR elements were read the same way. Thus, NATO was read > > Enn,Ay,Tee,Oh. > > > > Which leads me to assume that acronyms are not read as acronyms > > anyhow, > > and thus AT users are happy with acronyms being marked up as ABBR. > > Right? > > Something like NATO should be pronounced by AT as "Nay - tow" > whether or not it is marked up with ABBR of ACRONYM. > Pronunciations like that should be drawn from a pronunciation > dictionary for the product (in the same way word processors > have spelling dictionaries). ABBR should be reserved for either > abbreviations not widely used or newly coined abbreviations. In > such cases more information than simply pronouncing it as a > word is needed (is "Nah - two" or "Nat - oh" or "Nay - toe", > etc.). The wiki proposal I drafted with the cooperation of > others provides the needed hooks for that[1] > From rob at robburns.com Sun Apr 27 08:38:12 2008 From: rob at robburns.com (Robert J Burns) Date: Sun, 27 Apr 2008 17:38:12 +0200 Subject: [html4all] ACRONYM and ABBR In-Reply-To: <20080427144743.M713@hicom.net> References: <481001F2.4080801@malform.no> <20080424040620.GA22010@jpc.local> <20080427144743.M713@hicom.net> Message-ID: <4331541A-883F-41A7-962D-FAD185F11E15@robburns.com> HI Gregory, I like the wiki article you cite. It has some valuable examples and some forward looking approaches. You won't get any disagreement from me on the need to markup these abbreviations and initialisms. In the examples that Leif and I discussed (e.g., NATO) it was my contention that this would not need markup because it is an abbreviated form that does not share the same ambiguities as for instance 'Dr.' in the example you gave. Of course this implies that authors and authoring tools need to be careful to ensure that any potentially ambiguous abbreviations are marked up properly. A look at Wikipedia shows their are indeed some possible alternative expansions[1], though wikipedia directs NATO the obvious NATO without first using the disambiguation page[2]. My contention then is that we should be striving for a situation (with proper UAs in place) where NATO for the treaty organization could be authored into a document without markup while using NATO for any other meaning would need markup. Of course using markup would be the safest approach in any event. The wiki article you cite also nicely complements the work I put into the wiki article on definitions and abbreviations[3]. That article just cited does not anticipate the need you nicely highlight for a cross document referencing approach. However, it does suggest the need for the opposite as well: that is a way to scope the abbreviations within the same document. This scoping could be especially necessary when a page includes multiple articles by separate authors using the same abbreviations and defined terms, but in different ways. Next, I feel strongly that another new element is not needed for this. I think a better approach than adding an IABBR element would be to use the existing ABBR element and to attach the newly proposed attributes to that element. In this way, the type attribute could default to 'non- initialism'. While the expressed as could default to 'character' (perhaps). I guess this goes a bit against the point that abbreviations are abbreviations and initialisms are initialisms, but I do not see what might be the problem with treating them all as abbreviated forms (though with semantic differences as indicated through the type attribute). For me this makes sense even in the abstract. However, given the goals of HTML5 I think there are further reasons to avoid introducing a new element and using new attributes instead. In terms of backwards compatibility with existing user agents, the introduction of new attributes has no issues and the attributes get added correctly to the DOM in every major browser. On the other hand with new elements each of the three or four major browsers handles elements differently. These new elements would work in Presto and WebKit and fail in IE and Mozilla (until those UAs could be updated). So these element problems provide yet another reason to introduce new attributes here rather than new element or elements. However, I would say again that I think the use of the ABBR element while distinguishing semantics further through additional attributes is a nice fit for what you're proposing. Take care, Rob [1]: [2]: [3]: On Apr 27, 2008, at 5:02 PM, Gregory J. Rosmaita wrote: > aloha! > > the "title" element is ESSENTIAL and MUST be REQUIRED for ABBR > for the #implied mechanism not only doesn't work, it is illogical > when applied to abbreviated forms, as there are many abbreviated > forms that share the same combination of letters, but which represent > completely different words/concepts: > > ADA can be expanded to: > > * Americans With Disabilities Act > * American Dental Association > * American Diabetes Association > * American Dietetic Association > * the programming language "ADA" (named for Ada Lovelace) > > what is needed, therefore, to make "title" an OPTIONAL attribute -- > AFTER the first REQUIRED declaration of an ABBR -- is a FOR/ID > mechanism > for reuse of the expansion for the abbreviated form; moreover, there > are > thousands of acronyms that overlap, as discussed in: > > HTML Needs Initialisms: > http://esw.w3.org/topic/HTML/AbbrAndInitialisms > > the same re-use problem applies to DFN as well -- if one encases > an abbreviated form in an abbr without a title, but encases the > ABBR in a DFN element, then it is the DFN element that needs a > reuse mechanism, and the optimal solution is not JUST the use > of title for both, but a reuse mechanism that is universal, not > merely document specific... the first instance of an ABBR or DFN > MUST be glossed with an expansion via the "title" attribute, as > well as an ID so that further incidents of the ABBR or DFN can be > bound to an initial expansion; obviously, a means of referring to > an external resource containing a site-wide table of abbreviation > and definition expansions is a superior mechanism and that is the > issue upon which we should be concentrating... > > gregory. > ------------------------------------------------------ > It is better to ask some of the questions than to know > all the answers. -- James Thurber > ------------------------------------------------------ > Gregory J. Rosmaita, oedipus at hicom.net > Camera Obscura: http://www.hicom.net/~oedipus > Oedipus' Online Complex: http://my.opera.com/oedipus > ------------------------------------------------------ > > > _______________________________________________ > List_HTML4all.org mailing list > http://www.html4all.org/wiki From oedipus at hicom.net Sun Apr 27 09:42:50 2008 From: oedipus at hicom.net (Gregory J. Rosmaita) Date: Sun, 27 Apr 2008 17:42:50 +0100 Subject: [html4all] ACRONYM and ABBR In-Reply-To: <4331541A-883F-41A7-962D-FAD185F11E15@robburns.com> References: <481001F2.4080801@malform.no> <20080424040620.GA22010@jpc.local> <20080427144743.M713@hicom.net> <4331541A-883F-41A7-962D-FAD185F11E15@robburns.com> Message-ID: <20080427162609.M49777@hicom.net> aloha, rob! thanks for your insightful comments and feedback... (although at this point, i expect nothing less from you!) my initialisms versus abbreviations proposal is actually quite old, the plan having been to submit it as a suggestion for XHTML2, but then the MarkUp activity split in two, and so i ported my concerns to HTML5... i realize that it is rather inconsistent of me to advocate 2 abbreviated forms, especially since i have been a vociferous advocate of deprecating BLOCKQUOTE and having a single QUOTE or Q element, with the rest left to styling. as explained in: http://esw.w3.org/topic/HTML/MuchAdoAboutQ also, i should have cited the excellent "executive summary" of the abbreviated form issues, as logged in: http://esw.w3.org/topic/HTML/AbbrAcronym01 i am not opposed to dropping the request/recommendation for a new element -- IABBR -- which would have superseded ACRONYM (and could have been mapped to ACRONYM for backwards compatibility), as long as the types suggested for IABBR are ported to ABBR... perhaps, in the spare time i don't have, i will be able to re-articulate my position using but a single element, ABBR to cover abbreviated forms of all types... as for default acronym/abbreviation expansion, such as that discussed for NATO, i am wary of the "tower of babel" phenomenon, where use and custom in one natural language differs greatly from another (think of the UK, US, canada, australia, and new zealand as 5 countries separated by a common language), unless such a default is defined in an external resource (akin to a stylesheet) so that an expansion is available for all abbreviated forms, no matter how "common" or "universal" gregory. --------------------------------------------------------------- DELIBERATION, n. The act of examining one's bread to determine which side it is buttered on. Ambrose Bierce, The Devil's Dictionary --------------------------------------------------------------- Gregory J. Rosmaita: oedipus at hicom.net United Blind Advocates for Talking Signs: http://ubats.org/ --------------------------------------------------------------- ---------- Original Message ----------- From: Robert J Burns To: HTML4All Sent: Sun, 27 Apr 2008 17:38:12 0200 Subject: Re: [html4all] ACRONYM and ABBR > HI Gregory, > > I like the wiki article you cite. It has some valuable examples > and some forward looking approaches. > > You won't get any disagreement from me on the need to markup > these abbreviations and initialisms. In the examples that Leif > and I discussed (e.g., NATO) it was my contention that this > would not need markup because it is an abbreviated form that > does not share the same ambiguities as for instance 'Dr.' in > the example you gave. Of course this implies that authors and > authoring tools need to be careful to ensure that any > potentially ambiguous abbreviations are marked up properly. A > look at Wikipedia shows their are indeed some possible > alternative expansions[1], though wikipedia directs NATO the > obvious NATO without first using the disambiguation page[2]. My > contention then is that we should be striving for a situation > (with proper UAs in place) where NATO for the treaty > organization could be authored into a document without markup > while using NATO for any other meaning would need markup. Of > course using markup would be the safest approach in any event. > > The wiki article you cite also nicely complements the work I put > into the wiki article on definitions and abbreviations[3]. That > article just cited does not anticipate the need you nicely > highlight for a cross document referencing approach. However, > it does suggest the need for the opposite as well: that is a > way to scope the abbreviations within the same document. This > scoping could be especially necessary when a page includes > multiple articles by separate authors using the same > abbreviations and defined terms, but in different ways. > > Next, I feel strongly that another new element is not needed for > this. I think a better approach than adding an IABBR element > would be to use the existing ABBR element and to attach the > newly proposed attributes to that element. In this way, the > type attribute could default to 'non- initialism'. While the > expressed as could default to 'character' (perhaps). > > I guess this goes a bit against the point that abbreviations are > abbreviations and initialisms are initialisms, but I do not see > what might be the problem with treating them all as abbreviated > forms > (though with semantic differences as indicated through the type > attribute). For me this makes sense even in the abstract. > However, given the goals of HTML5 I think there are further > reasons to avoid introducing a new element and using new > attributes instead. In terms of backwards compatibility with > existing user agents, the introduction of new attributes has no > issues and the attributes get added correctly to the DOM in > every major browser. On the other hand with new elements each > of the three or four major browsers handles elements > differently. These new elements would work in Presto and WebKit > and fail in IE and Mozilla (until those UAs could be updated). > So these element problems provide yet another reason to > introduce new attributes here rather than new element or > elements. However, I would say again that I think the use of > the ABBR element while distinguishing semantics further through > additional attributes is a nice fit for what you're proposing. > > Take care, > Rob > > [1]: > [2]: > [3]: > > On Apr 27, 2008, at 5:02 PM, Gregory J. Rosmaita wrote: > > > aloha! > > > > the "title" element is ESSENTIAL and MUST be REQUIRED for ABBR > > for the #implied mechanism not only doesn't work, it is illogical > > when applied to abbreviated forms, as there are many abbreviated > > forms that share the same combination of letters, but which represent > > completely different words/concepts: > > > > ADA can be expanded to: > > > > * Americans With Disabilities Act > > * American Dental Association > > * American Diabetes Association > > * American Dietetic Association > > * the programming language "ADA" (named for Ada Lovelace) > > > > what is needed, therefore, to make "title" an OPTIONAL attribute -- > > AFTER the first REQUIRED declaration of an ABBR -- is a FOR/ID > > mechanism > > for reuse of the expansion for the abbreviated form; moreover, there > > are > > thousands of acronyms that overlap, as discussed in: > > > > HTML Needs Initialisms: > > http://esw.w3.org/topic/HTML/AbbrAndInitialisms > > > > the same re-use problem applies to DFN as well -- if one encases > > an abbreviated form in an abbr without a title, but encases the > > ABBR in a DFN element, then it is the DFN element that needs a > > reuse mechanism, and the optimal solution is not JUST the use > > of title for both, but a reuse mechanism that is universal, not > > merely document specific... the first instance of an ABBR or DFN > > MUST be glossed with an expansion via the "title" attribute, as > > well as an ID so that further incidents of the ABBR or DFN can be > > bound to an initial expansion; obviously, a means of referring to > > an external resource containing a site-wide table of abbreviation > > and definition expansions is a superior mechanism and that is the > > issue upon which we should be concentrating... > > > > gregory. > > ------------------------------------------------------ > > It is better to ask some of the questions than to know > > all the answers. -- James Thurber > > ------------------------------------------------------ ------- End of Original Message ------- From foliot at wats.ca Sun Apr 27 11:07:36 2008 From: foliot at wats.ca (John Foliot) Date: Sun, 27 Apr 2008 11:07:36 -0700 Subject: [html4all] some reflections on @alt usage Message-ID: <003601c8a891$93ca1d80$0200000a@stanford.edu> Charles McCathieNevile wrote: >>> +1 to "required @alt is persuasive in training sessions" >>> Accessibility staff get limited time [...] > > I don't actually find this terribly persuasive. > With due respect then Chaals, some more time in those particular trenches is recommended. While I am painfully coming around to the notion that "bad" @alt is indeed worse than "no" @alt, one of my on-going concerns remains working at the content author level. I keep thinking that it is not an accident that *ALL* the major accessibility guidelines out there start with a variant that insists on a textual alternative to visual only content: * WCAG 1: 1.1 Provide a text equivalent for every non-text element * WCAG 2.0 (Draft): 1 Perceivable 1.1 Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language * Section 508: a) A text equivalent for every non-text element shall be provided (e.g., via "alt", "longdesc", or in element content) * AccessiWeb (France): 1.1 : Chaque ?l?ment graphique poss?de-t-il une alternative textuelle? [Trans: Does each graphic element possess a text alternative?] (http://tinyurl.com/2o5zuu) *IBM Web Accessibility Checklist V 3.5: Checkpoint 1: Images and animations - Use the alt="text" attribute to provide text equivalents for images. Use alt="" for images that do not convey important information or convey redundant information. *AND* Checkpoint 2: Image maps - Use client-side image maps and alternative text for image map hot spots. If a server-side map is needed, provide equivalent text links. (http://tinyurl.com/23yjfr) * WCAG Samurai Errata (Unofficial): Guideline 1. Provide equivalent alternatives to auditory and visual content. (http://wcagsamurai.org/errata/errata.html) * TEITAC Draft Recommendation (AKA Section 508 Refresh) 3-F - Non-text Objects - All non-text objects that are presented to the user must have a text alternative that presents equivalent information, except for the situations listed below. (http://teitac.org/wiki/EWG:Draft_Jan_7#3-F_-_Non-text_Objects) {This is the exception to the norm, in that it is not the /first/ requirement on the list, although it is noted as being critical, and that it affects "all disabilities"} (I am sure as well that there exists numerous corporate internal requirements, not wholly published, that insist on a similar requirement - Sample: http://tinyurl.com/6bn97o) While *WE* all know that web accessibility transcends more than just the visually impaired, *WE* still have a long way to go in conveying that message (as even those that should know better forget sometimes - http://tinyurl.com/3noxl9 "...FOR THE LAST TIME..."), and further have a long way to go simply conveying the entire "web accessibility" message, never mind that it is more than just for blind people. None-the-less, as the "web" for most users remains a visual experience, using the notion that a suitable alternative *must* exist for visual only elements to ensure universal access is a simple concept to grasp by virtually all (right down to a primary school level), and so has enormous value to those of us who "teach" about this subject. Removing the requirement for this concept at the technical level *does* send a poor message, and equates roughly to "Do as I say, not as I do". [Sidebar: I wish to commend Henri Sivonen and his http://validator.nu method of providing a means of checking appropriate text alternatives, as his methodology is both sound and useful] ************* There has been much discussion surrounding heuristic evaluations, and other ways of providing useful alternative content to the end-user, outside of cramming in bogus @alt content, and for the large part they do have credence. The question then remains, how do we continue to pressure content creators to include useful "equivalent alternatives", when at the end of the day the spec says you *really* don't have to. (Guidance and specific language aside, the fact remains that anyone can step up and claim "special" status, and the spec as written today in it's interpretive way* will allow conformance, as there is no programmatic way of testing the subjective decision of the author/authoring tool). [* there is "can't", and then there is "won't", and the difference is worlds apart] If we are to relax the mandatory requirement for @alt in the next generation Markup Language, then we must also explicitly note and provide as many /other/ ways of providing this information as possible: @alt and/or @longdesc @alt and/or @legend @alt and/or @id @alt and/or @figure @alt and/or @caption @alt and/or (ARIA Variants suggested) @alt and/or (suggested reserved values) @alt and/or (open to further suggestions) With these (and perhaps other) means/tools at their disposal, I cannot think of *any* scenario where one of these options could not be implemented, either by the end (human) author or at the "program" level (WYSIWYG/file upload site/etc.). Having *any* of the above methods of expanding upon the visual-only content present would thus render the element conformant. I would then suggest that any other HTML 5 implementation of which lacks *any* of the provided means of "equivalent alternatives" be non-conformant, and further suggest that this result with the most drastic of consequences: non-rendering. (Give out more rope, but increase the risk of hanging oneself) Regarding backwards compatibility: The web is a constantly evolving organism, and all players have a responsibility to ensure that the web continues "to work". I am sure we are all familiar with the IE8 "switch" problem, and why they (Microsoft) felt that using the DTD was (is?) an unreliable mechanism. However, as the defacto HTML 5 Conformance checker (validator.nu) notes, content that lacks the appropriate DTD () is non-conformant, and so this mechanism *could* be deployed as the means of conformance checking for images and other visual-only content. Documents that were authored to any other spec ( =< HTML 4.01, => XHTML 1.0, documents with no DTD) could continue to allow non-conformant elements to render (in a 'quirks' kind of way), but moving forward if you want to be authoring true HTML 5 then you need to step up to the plate and use any one of the now (proposed) multiple means of ensuring equivalency provided within the spec. Let fly the bouquets and brickbats. JF From oedipus at hicom.net Sun Apr 27 11:19:56 2008 From: oedipus at hicom.net (Gregory J. Rosmaita) Date: Sun, 27 Apr 2008 19:19:56 +0100 Subject: [html4all] abbreviated form wiki pages updated (FYI/RFC) In-Reply-To: <20080427162609.M49777@hicom.net> References: <481001F2.4080801@malform.no> <20080424040620.GA22010@jpc.local> <20080427144743.M713@hicom.net> <4331541A-883F-41A7-962D-FAD185F11E15@robburns.com> <20080427162609.M49777@hicom.net> Message-ID: <20080427180623.M10119@hicom.net> in an attempt to capture the "Single Abbreviated Element" aspect of http://esw.w3.org/topic/HTML/AbbrAndInitialisms i have added a new section "A Single Abbreviated Element" to the wiki page (which i have also linked-to from http://esw.w3.org/topic/HTML/AbbrAcronym01) you can get to the "new" section directly by appending: #head-b574cee489e2711e4895e8e5eb667b6ea9a2918e to http://esw.w3.org/topic/HTML/AbbrAndInitialisms or by following the link on http://esw.w3.org/topic/HTML/AbbrAcronym01 or using the "Quick Links" on http://esw.w3.org/topic/HTML/AbbrAndInitialisms rob, others -- does this suffice? if not, feel free to expand, prune, clarify, add and subtract from the section (i simply copy-and-pasted verbiage from the original proposal into verbiage for a single element, ABBR, for consistency's sake) gregory. ---------------------------------------------- Theory helps us to bear our ignorance of fact. -- George Santayana, "The Sense of Beauty" ---------------------------------------------- Gregory J. Rosmaita: oedipus at hicom.net Camera Obscura: http://www.hicom.net/~oedipus/ ---------------------------------------------- From lhs at malform.no Mon Apr 28 00:46:04 2008 From: lhs at malform.no (Leif Halvard Silli) Date: Mon, 28 Apr 2008 09:46:04 +0200 Subject: [html4all] [whatwg] several messages about the HTML syntax In-Reply-To: <1707BA8C-FED7-45EC-AFA9-5B73DD9CC9EF@thymeonline.com> References: <000f01c8a889$ef94c730$4d01010a@IBM42F76C011DF> <1707BA8C-FED7-45EC-AFA9-5B73DD9CC9EF@thymeonline.com> Message-ID: <481580BC.8070008@malform.no> Maurice 2008-04-28 04.10: > I think longdesc should be expanded to all attributes. Did you mean to say that @longdesc should be expanded to all elements? Or to all elements? (In the code examples you only added it to the element.) > It will be used as a native (no javascript needed) way of making more > useful tooltips. > It's value can either be a full url or the id of an element on the > current page or the id of an element on another page (but this would > require loading a whole other file in the background just to get a > small portion of it). [...] > Delete [...] What you have identified here, is a situation where also sighted users could benefit from a long description before taking action to activate a link. And by having @longdesc on a the usecase als becomes identical to the usecase HTML 4 gives for requiring that the @longdesc URL and the URL must be accessible in two different ways. (So that the user can choose to read the long description before following the link.) Having @longdesc on the element should increase the use of @longdesc greatly, and this would be beneficial in itself. Because, the problem with @longdesc today, is that too few, including users, know that it exist and how to use it. The problem of how to solve the hiding of the long description - in the file itself or in an external file - is also the same. Solving that problem will also benefit both the usecase and the usecase. I have been fiddeling with extending the use of @longdesc as well, in connection with cross-referencing. Before the auto cross-reference feature was deleted, I began an article, where I argue for including @longdesc in elements of the cross-reference feature, so that one could point to elements on other pages. * http://www.malform.no/cross-referencing-to-long-descriptions I also made an example of how a long description can be kept in the same page, while at the same time being hidden for those who don't care/need it, yet still be available via doubleclick - for any JavScript supporting browser: * http://www.malform.no/acidlongdesctest Regarding cross-refs again, taking your idea further, I could imagine without href, instead of adding the @longdesc directly to the (former) auto cross-reference elements. The default style for with @longdesc but without @href could be different from etc. That way one could easily use @longesc for cross-references without getting default blue links etc (as Nicholas Shanks mentioned [1]), in addition to the benefit of being able to show the context defining a term as a "tooltip". [1] http://lists.w3.org/Archives/Public/public-html/2008Apr/0725.html -- leif halvard silli From faulkner.steve at gmail.com Mon Apr 28 02:44:07 2008 From: faulkner.steve at gmail.com (Steven Faulkner) Date: Mon, 28 Apr 2008 10:44:07 +0100 Subject: [html4all] some reflections on @alt usage In-Reply-To: <003601c8a891$93ca1d80$0200000a@stanford.edu> References: <003601c8a891$93ca1d80$0200000a@stanford.edu> Message-ID: <55687cf80804280244h77fd9eacxf57b9a3bd58e2838@mail.gmail.com> Hi Al, John, It should be noted that some of the suggestions outlined by John and myself were previously raised by Al and discussed on a thread back in February [1]: [1] what's machinable [was: Re: ALT issue redux] http://lists.w3.org/Archives/Public/wai-xtech/2008Feb/0006.html http://lists.w3.org/Archives/Public/wai-xtech/2008Feb/0008.html regards stevef On 27/04/2008, John Foliot wrote: > Charles McCathieNevile wrote: > >>> +1 to "required @alt is persuasive in training sessions" > >>> Accessibility staff get limited time [...] > > > > I don't actually find this terribly persuasive. > > > > With due respect then Chaals, some more time in those particular trenches is > recommended. > > While I am painfully coming around to the notion that "bad" @alt is indeed > worse than "no" @alt, one of my on-going concerns remains working at the > content author level. I keep thinking that it is not an accident that *ALL* > the major accessibility guidelines out there start with a variant that > insists on a textual alternative to visual only content: > > * WCAG 1: > 1.1 Provide a text equivalent for every non-text element > > * WCAG 2.0 (Draft): > 1 Perceivable > 1.1 Provide text alternatives for any non-text content so that it can be > changed into other forms people need, such as large print, braille, speech, > symbols or simpler language > > * Section 508: > a) A text equivalent for every non-text element shall be provided (e.g., > via "alt", "longdesc", or in element content) > > * AccessiWeb (France): > 1.1 : Chaque ?l?ment graphique poss?de-t-il une alternative textuelle? > [Trans: Does each graphic element possess a text alternative?] > (http://tinyurl.com/2o5zuu) > > *IBM Web Accessibility Checklist V 3.5: > Checkpoint 1: Images and animations - Use the alt="text" attribute to > provide text equivalents for images. Use alt="" for images that do not > convey important information or convey redundant information. > *AND* > Checkpoint 2: Image maps - Use client-side image maps and alternative text > for image map hot spots. If a server-side map is needed, provide equivalent > text links. (http://tinyurl.com/23yjfr) > > * WCAG Samurai Errata (Unofficial): > Guideline 1. Provide equivalent alternatives to auditory and visual > content. (http://wcagsamurai.org/errata/errata.html) > > * TEITAC Draft Recommendation (AKA Section 508 Refresh) > 3-F - Non-text Objects - All non-text objects that are presented to the > user must have a text alternative that presents equivalent information, > except for the situations listed below. > (http://teitac.org/wiki/EWG:Draft_Jan_7#3-F_-_Non-text_Objects) > {This is the exception to the norm, in that it is not the /first/ > requirement on the list, although it is noted as being critical, and that it > affects "all disabilities"} > > (I am sure as well that there exists numerous corporate internal > requirements, not wholly published, that insist on a similar requirement - > Sample: http://tinyurl.com/6bn97o) > > > While *WE* all know that web accessibility transcends more than just the > visually impaired, *WE* still have a long way to go in conveying that > message (as even those that should know better forget sometimes - > http://tinyurl.com/3noxl9 "...FOR THE LAST TIME..."), and further have a > long way to go simply conveying the entire "web accessibility" message, > never mind that it is more than just for blind people. > > > None-the-less, as the "web" for most users remains a visual experience, > using the notion that a suitable alternative *must* exist for visual only > elements to ensure universal access is a simple concept to grasp by > virtually all (right down to a primary school level), and so has enormous > value to those of us who "teach" about this subject. Removing the > requirement for this concept at the technical level *does* send a poor > message, and equates roughly to "Do as I say, not as I do". > > [Sidebar: I wish to commend Henri Sivonen and his http://validator.nu method > of providing a means of checking appropriate text alternatives, as his > methodology is both sound and useful] > > ************* > > > There has been much discussion surrounding heuristic evaluations, and other > ways of providing useful alternative content to the end-user, outside of > cramming in bogus @alt content, and for the large part they do have > credence. The question then remains, how do we continue to pressure content > creators to include useful "equivalent alternatives", when at the end of the > day the spec says you *really* don't have to. (Guidance and specific > language aside, the fact remains that anyone can step up and claim "special" > status, and the spec as written today in it's interpretive way* will allow > conformance, as there is no programmatic way of testing the subjective > decision of the author/authoring tool). > > [* there is "can't", and then there is "won't", and the difference is worlds > apart] > > If we are to relax the mandatory requirement for @alt in the next generation > Markup Language, then we must also explicitly note and provide as many > /other/ ways of providing this information as possible: > > @alt and/or @longdesc > @alt and/or @legend > @alt and/or @id > @alt and/or @figure > @alt and/or @caption > @alt and/or (ARIA Variants suggested) > @alt and/or (suggested reserved values) > @alt and/or (open to further suggestions) > > With these (and perhaps other) means/tools at their disposal, I cannot think > of *any* scenario where one of these options could not be implemented, > either by the end (human) author or at the "program" level (WYSIWYG/file > upload site/etc.). Having *any* of the above methods of expanding upon the > visual-only content present would thus render the element conformant. > I would then suggest that any other HTML 5 implementation of which > lacks *any* of the provided means of "equivalent alternatives" be > non-conformant, and further suggest that this result with the most drastic > of consequences: non-rendering. (Give out more rope, but increase the risk > of hanging oneself) > > Regarding backwards compatibility: The web is a constantly evolving > organism, and all players have a responsibility to ensure that the web > continues "to work". I am sure we are all familiar with the IE8 "switch" > problem, and why they (Microsoft) felt that using the DTD was (is?) an > unreliable mechanism. However, as the defacto HTML 5 Conformance checker > (validator.nu) notes, content that lacks the appropriate DTD ( HTML>) is non-conformant, and so this mechanism *could* be deployed as the > means of conformance checking for images and other visual-only content. > Documents that were authored to any other spec ( =< HTML 4.01, => XHTML 1.0, > documents with no DTD) could continue to allow non-conformant elements > to render (in a 'quirks' kind of way), but moving forward if you want to be > authoring true HTML 5 then you need to step up to the plate and use any one > of the now (proposed) multiple means of ensuring equivalency provided within > the spec. > > > Let fly the bouquets and brickbats. > > JF > > > > > > > _______________________________________________ > List_HTML4all.org mailing list > http://www.html4all.org/wiki > -- with regards Steve Faulkner Technical Director - TPG Europe Director - Web Accessibility Tools Consortium www.paciellogroup.com | www.wat-c.org Web Accessibility Toolbar - http://www.paciellogroup.com/resources/wat-ie-about.html From gez.lemon at gmail.com Mon Apr 28 03:15:09 2008 From: gez.lemon at gmail.com (Gez Lemon) Date: Mon, 28 Apr 2008 11:15:09 +0100 Subject: [html4all] some reflections on @alt usage In-Reply-To: <55687cf80804280244h77fd9eacxf57b9a3bd58e2838@mail.gmail.com> References: <003601c8a891$93ca1d80$0200000a@stanford.edu> <55687cf80804280244h77fd9eacxf57b9a3bd58e2838@mail.gmail.com> Message-ID: 2008/4/28 Steven Faulkner : > It should be noted that some of the suggestions outlined by John and > myself were previously raised by Al and discussed on a thread back in > February [1]: > > [1] what's machinable [was: Re: ALT issue redux] > http://lists.w3.org/Archives/Public/wai-xtech/2008Feb/0006.html > http://lists.w3.org/Archives/Public/wai-xtech/2008Feb/0008.html Just to add to my position on using aria-describedby and aria-labelledby in response to Al's original message. I think aria-describedby could be considered an appropriate alternative to longdesc when the description exists in the same page, but obviously not when the description is in another document. I can also see there may be some edge-cases when aria-labelledby may be considered a suitable replacement for alt. These are edge-cases, as ARIA was designed to bridge the accessibility gaps with the current structure we have. Providing alt text for images wasn't one of those gaps, as there is already a suitable attribute. Cheers, Gez -- _____________________________ Supplement your vitamins http://juicystudio.com From joshue.oconnor at cfit.ie Mon Apr 28 04:28:18 2008 From: joshue.oconnor at cfit.ie (Joshue O Connor) Date: Mon, 28 Apr 2008 12:28:18 +0100 Subject: [html4all] some reflections on @alt usage In-Reply-To: References: <003601c8a891$93ca1d80$0200000a@stanford.edu> <55687cf80804280244h77fd9eacxf57b9a3bd58e2838@mail.gmail.com> Message-ID: <4815B4D2.8010908@cfit.ie> Gez Lemon wrote: > 2008/4/28 Steven Faulkner : >> It should be noted that some of the suggestions outlined by John and >> myself were previously raised by Al and discussed on a thread back in >> February [1]: >> >> [1] what's machinable [was: Re: ALT issue redux] >> http://lists.w3.org/Archives/Public/wai-xtech/2008Feb/0006.html >> http://lists.w3.org/Archives/Public/wai-xtech/2008Feb/0008.html > > Just to add to my position on using aria-describedby and > aria-labelledby in response to Al's original message. I think > aria-describedby could be considered an appropriate alternative to > longdesc when the description exists in the same page, but obviously > not when the description is in another document. I can also see there > may be some edge-cases when aria-labelledby may be considered a > suitable replacement for alt. These are edge-cases, as ARIA was > designed to bridge the accessibility gaps with the current structure > we have. Providing alt text for images wasn't one of those gaps, as > there is already a suitable attribute. + 1 josh From laura.lee.carlson at gmail.com Mon Apr 28 05:00:58 2008 From: laura.lee.carlson at gmail.com (Laura Carlson) Date: Mon, 28 Apr 2008 07:00:58 -0500 Subject: [html4all] some reflections on @alt usage In-Reply-To: References: <003601c8a891$93ca1d80$0200000a@stanford.edu> <55687cf80804280244h77fd9eacxf57b9a3bd58e2838@mail.gmail.com> Message-ID: <1c8dbcaa0804280500k2876966bw39caaab70e320de1@mail.gmail.com> Gez Lemon wrote: > Just to add to my position on using aria-describedby and > aria-labelledby in response to Al's original message. I think > aria-describedby could be considered an appropriate alternative to > longdesc when the description exists in the same page, but obviously > not when the description is in another document. I can also see there > may be some edge-cases when aria-labelledby may be considered a > suitable replacement for alt. These are edge-cases, as ARIA was > designed to bridge the accessibility gaps with the current structure > we have. Providing alt text for images wasn't one of those gaps, as > there is already a suitable attribute. +1 The question of should HTML5 throw out mandatory alt and write optional alt into the spec to sanction for *one* use case (so flickr et al doesn't have to bother with accessibility, can be blessed as valid, and corporations can rack up more profit$) is a very slippery slope. At this point I really don't think requiring alt is the problem. It is the value that is the problem for vendors in one use case. Optional alt is a way to codify and bless bad tools. This is the elephant in the room. And until someone either comes up with a solution that maintains the integrity of the markup while addressing their business needs, or addresses putting the business requirements above the integrity of the markup and accessibility, everyone is wasting time arguing. Best Regards, Laura -- Laura L. Carlson From chaals at opera.com Mon Apr 28 05:25:02 2008 From: chaals at opera.com (Charles McCathieNevile) Date: Mon, 28 Apr 2008 14:25:02 +0200 Subject: [html4all] longdesc and ARIA Re: some reflections on @alt usage In-Reply-To: References: <003601c8a891$93ca1d80$0200000a@stanford.edu> <55687cf80804280244h77fd9eacxf57b9a3bd58e2838@mail.gmail.com> Message-ID: On Mon, 28 Apr 2008 12:15:09 +0200, Gez Lemon wrote: > 2008/4/28 Steven Faulkner : >> It should be noted that some of the suggestions outlined by John and >> myself were previously raised by Al and discussed on a thread back in >> February [1]: >> >> [1] what's machinable [was: Re: ALT issue redux] >> http://lists.w3.org/Archives/Public/wai-xtech/2008Feb/0006.html >> http://lists.w3.org/Archives/Public/wai-xtech/2008Feb/0008.html > > Just to add to my position on using aria-describedby and > aria-labelledby in response to Al's original message. I think > aria-describedby could be considered an appropriate alternative to > longdesc when the description exists in the same page, but obviously > not when the description is in another document. I can also see there > may be some edge-cases when aria-labelledby may be considered a > suitable replacement for alt. These are edge-cases, as ARIA was > designed to bridge the accessibility gaps with the current structure > we have. Providing alt text for images wasn't one of those gaps, as > there is already a suitable attribute. Yep. In general, it seems a very bad idea to use ARIA where there is something existing that works, since you are relying on implementations. Even though 3 of the 4 desktop browsers have ARIA support announced and demonstrated (in varying stages of maturity - come on Safari, there's time...) it makes more sense to rely on the older standards than to somehow try to replace them. There is a seperate issue, which is really on ARIA, about how browsers should behave when you have ARIA conflicting with other stuff e.g. longdesc and aria-describedBy and they point to different things. Should ARIA be trusted in all cases? Should it be determined seperately for different ARIA properties? Should we trust the old attributes (this has the benefit that backwards-compatibility comes up with the same results, which is probably quite valuable really). cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle fran?ais -- hablo espa?ol -- jeg l?rer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com From chaals at opera.com Mon Apr 28 06:00:00 2008 From: chaals at opera.com (Charles McCathieNevile) Date: Mon, 28 Apr 2008 15:00:00 +0200 Subject: [html4all] some reflections on @alt usage In-Reply-To: <1c8dbcaa0804280500k2876966bw39caaab70e320de1@mail.gmail.com> References: <003601c8a891$93ca1d80$0200000a@stanford.edu> <55687cf80804280244h77fd9eacxf57b9a3bd58e2838@mail.gmail.com> <1c8dbcaa0804280500k2876966bw39caaab70e320de1@mail.gmail.com> Message-ID: On Mon, 28 Apr 2008 14:00:58 +0200, Laura Carlson wrote: > Optional alt is a way to codify and bless bad tools. I don't think so. There is a lot of nonsense that Ian had in drafta about when you can omit alt - circumstances where it is necesary and he is just wrng. There are other badly constructed examples (his use of HTML5 markup with figure and legend should have alt="" since the content is already there, not omit the alt). All of the stupid advice about times when alt can be ommitted needs to be rewritten. There are arguments given in the debate that are about blessing bad tools, an those specific arguments should be shot down in flames. The spec should point out that not having alt is wrong. But having some default value that is meaningless, or that collides with a meaningful value like alt="" is even more wrong since it not only breaks the user experience like no alt does, but it also becomes harder to test and breaks existing rules, advice, and tools. If we get these issues fixed in the spec then we are ready to start addressing the actual question of whether missing alt should be a validation error. Optional alt is about a belief that validation is more important to people (in particular tool developers) than accessibility. If that turns out to be true, then it makes sense. If that turns out to be false, then it doesn't. But we have to have some research - both sides of the argument are currently based on gut feeling and instinct. There is a real issue here, and there is very little real information being provided to settle the question rationally. So my preferred approach is to fix the rest of the rubbish in the spec, and do some research on the real issue, and *then* talk about making a decision... cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle fran?ais -- hablo espa?ol -- jeg l?rer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com From gez.lemon at gmail.com Mon Apr 28 06:37:01 2008 From: gez.lemon at gmail.com (Gez Lemon) Date: Mon, 28 Apr 2008 14:37:01 +0100 Subject: [html4all] some reflections on @alt usage In-Reply-To: References: <003601c8a891$93ca1d80$0200000a@stanford.edu> <55687cf80804280244h77fd9eacxf57b9a3bd58e2838@mail.gmail.com> <1c8dbcaa0804280500k2876966bw39caaab70e320de1@mail.gmail.com> Message-ID: On 28/04/2008, Charles McCathieNevile wrote: > Optional alt is about a belief that validation is more important to people > (in particular tool developers) than accessibility. If that turns out to > be true, then it makes sense. If that turns out to be false, then it > doesn't. But we have to have some research - both sides of the argument > are currently based on gut feeling and instinct. There is a real issue > here, and there is very little real information being provided to settle > the question rationally. I think the issue should be about the integrity of the structure. If alternate text isn't provided for important images, then we know it isn't accessible to people who cannot readily change an aspect of themselves to make it accessible. Alternate text maintains the integrity of the structure to ensure that it is accessible to everyone. Lowering the integrity requirements to make poor authoring tools compliant doesn't address the issue that important images without alternate text are inaccessible. Badly written alt text being a greater evil is misdirection. They're both extremely bad scenarios for accessibility. The markup language should ensure the integrity of the data. Cheers, Gez -- _____________________________ Supplement your vitamins http://juicystudio.com From chaals at opera.com Mon Apr 28 10:15:23 2008 From: chaals at opera.com (Charles McCathieNevile) Date: Mon, 28 Apr 2008 19:15:23 +0200 Subject: [html4all] some reflections on @alt usage In-Reply-To: References: <003601c8a891$93ca1d80$0200000a@stanford.edu> <55687cf80804280244h77fd9eacxf57b9a3bd58e2838@mail.gmail.com> <1c8dbcaa0804280500k2876966bw39caaab70e320de1@mail.gmail.com> Message-ID: On Mon, 28 Apr 2008 15:37:01 +0200, Gez Lemon wrote: > On 28/04/2008, Charles McCathieNevile wrote: >> Optional alt is about a belief that validation is more important to >> people >> (in particular tool developers) than accessibility. If that turns out >> to >> be true, then it makes sense. If that turns out to be false, then it >> doesn't. But we have to have some research - both sides of the argument >> are currently based on gut feeling and instinct. There is a real issue >> here, and there is very little real information being provided to >> settle >> the question rationally. > > I think the issue should be about the integrity of the structure. I think the issue should be about what makes the most content most accessible. > If > alternate text isn't provided for important images, then we know it > isn't accessible to people who cannot readily change an aspect of > themselves to make it accessible. Sure, couldn't agree more. > Alternate text maintains the > integrity of the structure to ensure that it is accessible to > everyone. When done right. And I think there is universal agreement on that. (There is not universal agreement on how to do it, and I think that some of the stuff in the HTML5 draft I last read was nonsense, suggesting that there was nothing to be done when this was clearly not the case). The issue is what happens when things go wrong. > Lowering the integrity requirements to make poor authoring tools > compliant doesn't address the issue that important images without > alternate text are inaccessible. I am not proposing lowering the requirements on poorly-designed authoring tools. They should be castigated like crazy for not making it easy and friendly to include alt text. I happen to include My.Opera.com in the list of things that need to be improved. The problem is poor advice to tool developers (which we need to get out of the spec), and more so lazy authors. Unfortunately, tools cannot always force authors to do the right thing, and the question is what they should do in that case. > Badly written alt text being a > greater evil is misdirection. They're both extremely bad scenarios for > accessibility. They are. But one scenario is worse, because it makes it harder to identify, and therefore repair, problems. > The markup language should ensure the integrity of the > data. Indeed. This includes the ability to improve the data where necessary, and that relies on having clear ways of knowing what type of error we are dealing with in each case. Note that I do not yet have any position one way or another on whether alt should be required for validity. I have a very strong and simple position on whether we need to get better alt into more pages, and on whether pages that skip doing that are any good. But I don't want to lead us down a path that actually makes accessibility worse, just because we are saying the right thing as we go. I would rather we look carefully at where the paths lead, and then choose the one that gets to the result that we are looking for. Cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle fran?ais -- hablo espa?ol -- jeg l?rer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com From gez.lemon at gmail.com Mon Apr 28 10:21:01 2008 From: gez.lemon at gmail.com (Gez Lemon) Date: Mon, 28 Apr 2008 18:21:01 +0100 Subject: [html4all] some reflections on @alt usage (and even sometimes @aria-labelledby...) In-Reply-To: <72524FD0-2088-4956-AC9A-9D754F2B67B8@IEEE.org> References: <003601c8a891$93ca1d80$0200000a@stanford.edu> <55687cf80804280244h77fd9eacxf57b9a3bd58e2838@mail.gmail.com> <72524FD0-2088-4956-AC9A-9D754F2B67B8@IEEE.org> Message-ID: On 28/04/2008, Al Gilman wrote: > Don't dismiss @aria-labelledby from consideration as an alternative > to @alt in the "where to find the text alternate" algorithm. It hasn't been dismissed. > User text should be Web text, not attribute-value-text. I completely agree, but there are circumstances where it is more difficult to use a labelling design pattern. That's why the WCAG 2 draft discusses scenarios where authors can use attribute text when the labelling design pattern should be used, but doesn't work [1]. aria-labelledby could be considered a good alternative to HTML's label element. It's not as useful for providing alternative text for images, as inline images aren't really suited to the labelling design pattern. There may be edge cases where the labelling design pattern is more suitable as a concise alternative for an inline image, in the same way that there are cases where a text attribute is more suitable than a label. [1] http://www.w3.org/TR/2007/WD-WCAG20-TECHS-20071211/H65.html Gez -- _____________________________ Supplement your vitamins http://juicystudio.com From foliot at wats.ca Mon Apr 28 10:40:19 2008 From: foliot at wats.ca (John Foliot) Date: Mon, 28 Apr 2008 10:40:19 -0700 Subject: [html4all] Research? (was RE: some reflections on @alt usage) In-Reply-To: Message-ID: <006901c8a956$f0b34060$5a2e42ab@stanford.edu> Charles McCathieNevile wrote: > All of the stupid advice about > times when alt can be ommitted needs to be rewritten. +1 > > There are arguments given in the debate that are about blessing bad > tools, an those specific arguments should be shot down in flames. > ...more like blessing bad practice (I note with irony that they no longer call it paving cowpaths, although the concept remains the same). > The spec should point out that not having alt is wrong. Agreed (perhaps *very* wrong?) > But having > some default value that is meaningless, or that collides with a > meaningful value like alt="" is even more wrong since it not only > breaks the user experience like no alt does, but it also becomes > harder to test and breaks existing rules, advice, and tools. Agreed (painful to admit Chaals, but, agreed). Ditto for shoveling in lousy alt text just to shut up the validator. > > If we get these issues fixed in the spec then we are ready to start > addressing the actual question of whether missing alt should be a > validation error. It should be (more below). Actually, I think what is more important is the *consequences* of inserting visual only content into the information stream without providing the "alternative". In my previous posting, I echoed thoughts that Steven had suggested in an earlier thread (never claimed they were my original thoughts Steven ): give the authors plenty of different ways - entrenched into the spec - to ensure that a textual alternative is present, but at the same time I proposed to up the ante for failing to do /anything/. My proposal was drastic to the extreme, yet nobody has commented on this. (Am I really that far out on the ledge with that one?) Chaals, I wish we could deal with this issue in the linear fashion you propose, but this apparently clashes with the "all-in" approach that Ian and Co. are taking - they want whole solutions now, not partial proposals with dangling action items: hell you re-opened the whole @alt issue on the technicality that Ian had attempted to close it even though there was an official open action item... > > Optional alt is about a belief that validation is more important to > people (in particular tool developers) than accessibility. If that > turns out to be true, then it makes sense. If that turns out to be > false, then it doesn't. But we have to have some research - both > sides of the argument are currently based on gut feeling and > instinct. There is a real issue here, and there is very little real > information being provided to settle the question rationally. I believe that this is only partially true. Clearly, to the editor and his cohorts, validation (conformance) *is* important; and isn't the whole point of standards is that to do things right, to *ensure* inter-operability, adherence to said standards is a given? I think we would be hard pressed today to find an engineer of any stripe to argue against this concept. Accessibility advocates want/need the same kind of entrenched requirements, else the demands/requirements get pushed down a notch: it really is that simple. The research you ask for exists already: the millions (trillions?) of inaccessible web pages in the wild today simply because WCAG 1 is a W3C Guideline and not a W3C Recommendation. If we are to advance even the simplest of needs/requirements beyond where we are today, we need more stick - full stop. This might *sound* like gut feeling, but I cannot find any examples on the web today to counter this feeling, and the fact that we need to fight **this hard** just to ensure that visual only content is properly accounted for by authors, simply highlights the fact that my gut feeling is inherently true. But I made myself a promise to calm down and reign in the rhetoric... I believe the concept was winnable battles? > > So my preferred approach is to fix the rest of the rubbish in the > spec, and do some research on the real issue, and *then* talk about > making a decision... What further research needs to be done, exactly? Way back when, one of the lofty goals of html4all was to actually get this kind of stuff done, but that "stuff" needs to be fully articulated and defined. You are one of the wise sages here, so give me/us some direction on what kind of research you believe is required to settle this round-robin and get actual traction happening. I will jump in whole-hog, hopefully others as well, and we can also tap our existing contacts and reach out: there are groups such as GAWDS that seem to be almost ignorant of what is going on here - ready troops who would probably jump in "...just because". What about Fundaci?n Sidar? Chaals, you still have inroads there, correct? Web Standards Group? A request for help via "AListApart"? Rounding up troops should not be that hard (says John, fully realizing that it may be a bit naive to say so, but I've stuck my neck out before...) > > cheers > > Chaals From laura.lee.carlson at gmail.com Mon Apr 28 11:09:27 2008 From: laura.lee.carlson at gmail.com (Laura Carlson) Date: Mon, 28 Apr 2008 13:09:27 -0500 Subject: [html4all] some reflections on @alt usage In-Reply-To: References: <003601c8a891$93ca1d80$0200000a@stanford.edu> <55687cf80804280244h77fd9eacxf57b9a3bd58e2838@mail.gmail.com> <1c8dbcaa0804280500k2876966bw39caaab70e320de1@mail.gmail.com> Message-ID: <1c8dbcaa0804281109rbd8c010v3bd7c02fb847a15@mail.gmail.com> Gez Lemon wrote: >> I think the issue should be about the integrity of the structure. Charles McCathieNevile wrote: > I think the issue should be about what makes the most content most accessible. I think it is both. 1. The PF/WAI issue is to tell the HTMLWG what mechanisms and features are needed to make content accessible. 2. The HTML5 issue is to provide the mechanisms and features that WAI needs. Making content accessible is WAI's domain. AUWG, UAWG, WCAGWG etc are chartered to set accessibility guidelines and HTML WG is not. When PF says "the failure of the HTML5 draft to make @alt on an across-the-board requirement (even if sometimes it has the value of "") is a bug", as they already have [1], alt should indeed be reinstated as a requirement in the HTML5 spec. PF's advice should not be ignored. Lowering the structural integrity requirements of a markup language doesn't help the people that structure was intended to help in the first place. Putting the faults of poor authoring tools (and authors) above the needs of a feature which allows the creation of accessible content pays no heed to PF's guidance. HTML5 WG should listen to PFWG on this and on the pending request for advice regarding "what should an authoring or publishing tool insert, in a case where no alt has been provided by the author, but the image is known to be 'critical content'?" [2] Best Regards, Laura [1] http://lists.w3.org/Archives/Public/public-html/2008Feb/0082.html [2] http://lists.w3.org/Archives/Public/public-html/2008Apr/0408.html From foliot at wats.ca Mon Apr 28 11:52:58 2008 From: foliot at wats.ca (John Foliot) Date: Mon, 28 Apr 2008 11:52:58 -0700 Subject: [html4all] more alt rant In-Reply-To: Message-ID: <007301c8a961$142351c0$5a2e42ab@stanford.edu> William Loughborough wrote: > One problem is that our surmises of where the paths lead are > inevitably flawed. > > We thought we had it from start with the alt attribute. Any further > tinkering may merely be a seductive way to introduce new > disappointments. > > If the intent to accessibilise is sacrificed with edge-case > nitpicking, we can never get the results we are looking for. > > In essence it in fact "ain't broke" and to fix it in response to > irresponsible exception-citations is simply wrong. > William, As many will attest, I have been fighting tooth and nail for some time on this issue, but sadly, it *is* broke (and my friend, it took me forever to get to that, and with considerable pain I might add). @alt alone is not /the/ answer - it cannot be a magic token for all that ails, even if it *is* the best solution more often than not. @alt today can be restrictive, and is currently abused as often (or perhaps more often) than it is used properly. We need to acknowledge that if we are to really improve things. There is no doubt that the current spec takes the wrong route in justifying no @alt - the scenarios provided are bogus and can be shot down quite easily - really in fact they already have been. None-the-less we are faced with a fundamental problem: sometimes is all we have. So the real question is "then what"? The current suggestion from HTML WG is incomplete, and as has also been pointed out, it is not within the scope of their charter to define or decide web accessibility issues: the W3C already has 'experts' in the form of other Working Groups to address these points. What we need is positive steps forward, not entrenched ideals at all costs (another painful realization) - and I might add that this acceptance is required from both sides of the debate. Yesterday I proposed some ideas - alternatives to @alt as it were - in an effort to continue discussion moving forward in that direction. I do not claim to have all the answers, and most of the ideas I attempted to summarize in my posting yesterday have emerged in other posts (often left dangling). I also suggested a radical consequence for non-conformant , which to my surprise has not elicited one comment despite it's extreme position. I really am passionate in wishing to ensure that the web is truly accessible, but now is not the time to dig in, but rather to think outside of the box and soar (third and final gestalt for JF). Our real goal is to improve the accessibility of and it's kin, and at the end of the day if we can come up with a better way, let's talk about that instead. JF From gez.lemon at gmail.com Mon Apr 28 12:17:14 2008 From: gez.lemon at gmail.com (Gez Lemon) Date: Mon, 28 Apr 2008 20:17:14 +0100 Subject: [html4all] some reflections on @alt usage In-Reply-To: References: <003601c8a891$93ca1d80$0200000a@stanford.edu> <55687cf80804280244h77fd9eacxf57b9a3bd58e2838@mail.gmail.com> <1c8dbcaa0804280500k2876966bw39caaab70e320de1@mail.gmail.com> Message-ID: On 28/04/2008, Charles McCathieNevile wrote: > > Lowering the integrity requirements to make poor authoring tools > > compliant doesn't address the issue that important images without > > alternate text are inaccessible. > > > > I am not proposing lowering the requirements on poorly-designed authoring > tools. They should be castigated like crazy for not making it easy and > friendly to include alt text. I happen to include My.Opera.com in the list > of things that need to be improved. > > The problem is poor advice to tool developers (which we need to get out of > the spec), and more so lazy authors. Unfortunately, tools cannot always > force authors to do the right thing, and the question is what they should do > in that case. These are the responsibilities of the author and the authoring tool they choose to use. Allowing alternate text to be optional in the structure doesn't address the problem of poor alternative text being provided by the author or the authoring tool they use - it is lowering the integrity requirements for conformance. The only obvious benefit is that most tool vendors will automatically adhere to HTML5, as very few adhere to existing standards. > > Badly written alt text being a > > greater evil is misdirection. They're both extremely bad scenarios for > > accessibility. > > > > They are. But one scenario is worse, because it makes it harder to > identify, and therefore repair, problems. I understand why one is worse, but, ignoring authors that just don't care, the assumption here is that authoring tools will populate content with random alternative text for conformance. In reality, we haven't seen evidence that authoring tool vendors care about conformance (markup or accessibility), apart from a few notable exceptions (and those exceptions do not populate content with random alt text). > > The markup language should ensure the integrity of the > > data. > > > Indeed. This includes the ability to improve the data where necessary, and > that relies on having clear ways of knowing what type of error we are > dealing with in each case. I disagree. The integrity of the structure is in its completeness and appropriateness. Repair techniques are the responsibilities of the authoring tool and the user agent. Only the author can know what they really intended, so the authoring tool should make it as easy as possible for the user to provide alternative text. If the author doesn't provide the alternative, then the content isn't compliant. Breaking integrity constraints on the structure doesn't solve that problem - it weakens it so that non-conforming authoring tools can claim conformance to HTML5 for an incomplete and inappropriate structure, but would not adhere to WCAG. Cheers, Gez -- _____________________________ Supplement your vitamins http://juicystudio.com From joshue.oconnor at cfit.ie Mon Apr 28 14:27:32 2008 From: joshue.oconnor at cfit.ie (Joshue O Connor) Date: Mon, 28 Apr 2008 22:27:32 +0100 Subject: [html4all] longdesc and ARIA Re: some reflections on @alt usage In-Reply-To: References: <003601c8a891$93ca1d80$0200000a@stanford.edu> <55687cf80804280244h77fd9eacxf57b9a3bd58e2838@mail.gmail.com> Message-ID: <48164144.5050406@cfit.ie> Charles McCathieNevile wrote: > There is a seperate issue, which is really on ARIA, about how browsers should behave when you have ARIA conflicting with other stuff e.g. longdesc and aria-describedBy and they point to different things. >Should ARIA be trusted in all cases? Should it be determined seperately for different ARIA properties? Should we trust the old attributes (this has the benefit that backwards-compatibility comes up with the same results, >which is probably quite valuable really). There was some comment by Ian on IRC/WG list (cannot find reference just now) about what would happen when ARIA described by etc was used alongside the new HTML 5 elements etc to describe the same content/instances or if there was some dissonance etc. To paraphrase, the thrust of it was saying that these issues are problematic and may halt the /adoption/ or /absorption/ of ARIA into HTML 5. Cheers Josh From joshue.oconnor at cfit.ie Mon Apr 28 14:35:49 2008 From: joshue.oconnor at cfit.ie (Joshue O Connor) Date: Mon, 28 Apr 2008 22:35:49 +0100 Subject: [html4all] some reflections on @alt usage In-Reply-To: References: <003601c8a891$93ca1d80$0200000a@stanford.edu> <55687cf80804280244h77fd9eacxf57b9a3bd58e2838@mail.gmail.com> <1c8dbcaa0804280500k2876966bw39caaab70e320de1@mail.gmail.com> Message-ID: <48164335.7000006@cfit.ie> Charles McCathieNevile wrote: > > On Mon, 28 Apr 2008 14:00:58 +0200, Laura Carlson > wrote: > >> Optional alt is a way to codify and bless bad tools. > > I don't think so. It does seem to me be one of the main reasons for making @alt optional. Josh From oedipus at hicom.net Mon Apr 28 19:38:28 2008 From: oedipus at hicom.net (Gregory J. Rosmaita) Date: Tue, 29 Apr 2008 03:38:28 +0100 Subject: [html4all] Image Annotation on the Semantic Web [Incubator Group Report] Message-ID: <20080429023757.M26306@hicom.net> Image Annotation on the Semantic Web W3C Incubator Group Report 14 August 2007 http://www.w3.org/2005/Incubator/mmsem/XGR-image-annotation-20070814/ Document Roadmap After reading this document, readers may turn to separate living documents discussing individual multimedia annotation vocabularies [1], and other relevant tools and resources. [2] Most of the current approaches to image annotation are not based on Semantic Web languages. Interoperability between these technologies and RDF and OWL-based approaches is not the topic of this document, but interested readers can look at the Multimedia Annotation Interoperability Framework document. [3] Target Audience This document is target at everybody with an interest in image annotation, ranging from non-professional end-users that are annotating their personal digital photos to professionals working with digital pictures in image and video banks, audiovisual archives, museums, libraries, media production and broadcast industry, etc. Objectives * To illustrate the benefits of using semantic technologies in image annotations. * To provide guidelines for applying semantic technologies in this area. * To collect currently used vocabularies for Semantic Web-based image annotation. * To provide use cases with examples of Semantic Web-based image annotation. Discussion of this document is invited on the public mailing list public-xg-mmsem at w3.org (public archives). Public comments should include "[MMSEM-Image]" as subject-prefix. [4] [1] http://www.w3.org/2005/Incubator/mmsem/wiki/Vocabularies [2] http://www.w3.org/2005/Incubator/mmsem/wiki/Tools_and_Resources [3] http://www.w3.org/2005/Incubator/mmsem/XGR-interoperability/ [4] http://lists.w3.org/Archives/Public/public-xg-mmsem/ ---------------------------------------------------------- "Half of expertise is tease." -- Harry Shearer ---------------------------------------------------------- Gregory J. Rosmaita: oedipus at hicom.net Camera Obscura: http://www.hicom.net/~oedipus/ United Blind Advocates for Talking Signs: http://ubats.org ---------------------------------------------------------- From chaals at opera.com Tue Apr 29 02:27:38 2008 From: chaals at opera.com (Charles McCathieNevile) Date: Tue, 29 Apr 2008 11:27:38 +0200 Subject: [html4all] some reflections on @alt usage In-Reply-To: References: <003601c8a891$93ca1d80$0200000a@stanford.edu> <55687cf80804280244h77fd9eacxf57b9a3bd58e2838@mail.gmail.com> <1c8dbcaa0804280500k2876966bw39caaab70e320de1@mail.gmail.com> Message-ID: On Mon, 28 Apr 2008 21:17:14 +0200, Gez Lemon wrote: > On 28/04/2008, Charles McCathieNevile wrote: >> > Lowering the integrity requirements to make poor authoring tools >> > compliant doesn't address the issue that important images without >> > alternate text are inaccessible. >> > >> >> I am not proposing lowering the requirements on poorly-designed >> authoring tools.. >> >> The problem is poor advice to tool developers (which we need to get >> out of the spec), and more so lazy authors. Unfortunately, tools >> cannot always force authors to do the right thing, and the question >> is what they should do in that case. > > ... The only obvious benefit > is that most tool vendors will automatically adhere to HTML5, as very > few adhere to existing standards. > >> > Badly written alt text being a >> > greater evil is misdirection. They're both extremely bad scenarios for >> > accessibility. >> > >> >> They are. But one scenario is worse, because it makes it harder to >> identify, and therefore repair, problems. > > I understand why one is worse, but, ignoring authors that just don't > care, the assumption here is that authoring tools will populate > content with random alternative text for conformance. *note this bit* > In reality, we > haven't seen evidence that authoring tool vendors care about > conformance (markup or accessibility), *to here* > apart from a few notable > exceptions (and those exceptions do not populate content with random > alt text). > >> > The markup language should ensure the integrity of the >> > data. >> > >> Indeed. This includes the ability to improve the data where necessary, >> and that relies on having clear ways of knowing what type of error we >> are dealing with in each case. > > I disagree. The integrity of the structure is in its completeness and > appropriateness. Repair techniques are the responsibilities of the > authoring tool and the user agent. Only the author can know what they > really intended, so the authoring tool should make it as easy as > possible for the user to provide alternative text. If the author > doesn't provide the alternative, then the content isn't compliant. > Breaking integrity constraints on the structure doesn't solve that > problem - it weakens it so that non-conforming authoring tools can > claim conformance to HTML5 for an incomplete and inappropriate > structure, but would not adhere to WCAG. I agree that authoring tool vendors in the large don't really care about adherence to standards. The question remains: Do they care more about HTML5, about WCAG, about ATAG, or do they do the things they do for some completely different reason - perhaps to avoid having pesky tooltips on their nice design, or because someone advised them to do it this way (who?). Until we answer that question with something better than assertions and guesswork, no position on this issue is more defensible than any other. So I am trying to get focus on a real answer to that question, at which point the question of what should be "valid HTML5" should be straightforward to answer one way or the other. In the meantime, I would prefer spending my energy to establish that some of the things in the draft that are clearly nonsense get corrected. Cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle fran?ais -- hablo espa?ol -- jeg l?rer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com From vlad.alexander at xstandard.com Tue Apr 29 03:00:31 2008 From: vlad.alexander at xstandard.com (Vlad Alexander (XStandard)) Date: Tue, 29 Apr 2008 06:00:31 -0400 Subject: [html4all] some reflections on @alt usage Message-ID: > authoring tool vendors in the large don't really care > about adherence to standards And that will not change until major Web browsers will begin to report invalid markup to the users in some way. There is no incentive for tool vendors to generate standards-compliant markup if it gets treated by Web browsers the same as tag soup. In fact, HTML 5 will make the problem even worse. HTML 5 will help Web browsers parse tag soup better which will then provide less incentive for authors and tool vendors to author Web pages to specification and thus creating more tag soup on the Web. Regards, -Vlad http://xstandard.com -------- Original Message -------- From: Charles McCathieNevile Date: 2008-04-29 5:27 AM > On Mon, 28 Apr 2008 21:17:14 +0200, Gez Lemon wrote: > >> On 28/04/2008, Charles McCathieNevile wrote: >>>> Lowering the integrity requirements to make poor authoring tools >>>> compliant doesn't address the issue that important images without >>>> alternate text are inaccessible. >>>> >>> I am not proposing lowering the requirements on poorly-designed >>> authoring tools.. >>> >>> The problem is poor advice to tool developers (which we need to get >>> out of the spec), and more so lazy authors. Unfortunately, tools >>> cannot always force authors to do the right thing, and the question >>> is what they should do in that case. >> ... The only obvious benefit >> is that most tool vendors will automatically adhere to HTML5, as very >> few adhere to existing standards. >> >>>> Badly written alt text being a >>>> greater evil is misdirection. They're both extremely bad scenarios for >>>> accessibility. >>>> >>> They are. But one scenario is worse, because it makes it harder to >>> identify, and therefore repair, problems. >> I understand why one is worse, but, ignoring authors that just don't >> care, the assumption here is that authoring tools will populate >> content with random alternative text for conformance. > *note this bit* >> In reality, we >> haven't seen evidence that authoring tool vendors care about >> conformance (markup or accessibility), > *to here* >> apart from a few notable >> exceptions (and those exceptions do not populate content with random >> alt text). >> >>>> The markup language should ensure the integrity of the >>>> data. >>>> >>> Indeed. This includes the ability to improve the data where necessary, >>> and that relies on having clear ways of knowing what type of error we >>> are dealing with in each case. >> I disagree. The integrity of the structure is in its completeness and >> appropriateness. Repair techniques are the responsibilities of the >> authoring tool and the user agent. Only the author can know what they >> really intended, so the authoring tool should make it as easy as >> possible for the user to provide alternative text. If the author >> doesn't provide the alternative, then the content isn't compliant. >> Breaking integrity constraints on the structure doesn't solve that >> problem - it weakens it so that non-conforming authoring tools can >> claim conformance to HTML5 for an incomplete and inappropriate >> structure, but would not adhere to WCAG. > > I agree that authoring tool vendors in the large don't really care about > adherence to standards. The question remains: Do they care more about > HTML5, about WCAG, about ATAG, or do they do the things they do for some > completely different reason - perhaps to avoid having pesky tooltips on > their nice design, or because someone advised them to do it this way > (who?). > > Until we answer that question with something better than assertions and > guesswork, no position on this issue is more defensible than any other. So > I am trying to get focus on a real answer to that question, at which point > the question of what should be "valid HTML5" should be straightforward to > answer one way or the other. In the meantime, I would prefer spending my > energy to establish that some of the things in the draft that are clearly > nonsense get corrected. > > Cheers > > Chaals > From rob at robburns.com Tue Apr 29 03:21:37 2008 From: rob at robburns.com (Robert J Burns) Date: Tue, 29 Apr 2008 12:21:37 +0200 Subject: [html4all] default namesapce declarations Message-ID: <18995994-5929-4770-AF39-851812067C23@robburns.com> Hello all, Yesterday I raised namespaces (along with parsing) as the only thing I think HTML 4.1 should be focussed on right now. After further reflection on that I had some more ideas. First, many in the WhatWG claim that namespaces are unwieldy. While I find this claim way overblown, I had an idea that could probably satisfy most of the WhatWG concerns and also make authoring with HTML4.1 (or HTML5 whatever one wants to call it) a lot easier. HTML5 could make default namespace declarations. These could be overridden by authors at their discretion, but for other authors, they would never need to think about the namespace URIs. It would work something like this. We would declare several default attributes values for the root HTML element. For the extensions from HTML5 (i.e., proposed content models, new elements, and new attributes): xmlns:h4='http://www.w3.org/1999/xhtml' For xmlns:svg = 'http://www.w3.org/2000/svg' Also include default namespace declarations of: ? xmlns:a (for ARIA); ? xmlns:m (for MathML); ? xmlns:ev (for XEvents); and any others we feel authors will want to use easily and meet certain agreed upon criteria. These namespace declarations would all be the default values for these attributes on the HTML root element. This would allow authors to incorporate these other standards into their HTML documents without making any xmlns declarations. They could at their own option make new declarations that would override these defaults, but I think that would seldom happen. The issue as I see it is that the W3C wanted to set a good example for others by choosing namespaces that were fully qualified http schema identifiers. On the other hand, since these are so often the basis from which we use other namespaces, it would have been nice to have namespaces that were much shorter, and make declarations for other namespaces. This solution addresses the problem in a way that satisfies both goals: 1) W3C continues to set a good example by using fully qualified http schema URIs as their namespace URIs; 2) authors can use minimized and easily remembered prefixes without necessarily ever encountering a namespace declaration. A simple example document making use of this approach might look like this: ... An abstract of the document with rich markup ? A heading some text and then
  • A list of items within a paragraph
    • ...

just a regular paragraph with only strictly inline content a and an img a lengthy description of the image Another copy of the same image with the color adjusted

some more MathML content? If we do this right, the above namespaced content should work in IE (I think back to IE5 or IE6: i.e., back nearly a decade). The other browsers could be more responsive in adopting the namespace mechanism to text/html, but the same document could be authored for serving to IE back to IE5 as text/html and the other browsers as XHTML. Obviously there could be all sorts of nagging issues to get in the way, but its worth consideration. Once namespaces had been added to all browsers for text/html authors could easily choose to use text/html or application/xml+xhtml at their own discretion. Take care, Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wilbur.bytowninternet.com/pipermail/list_html4all.org/attachments/20080429/94d5806e/attachment-0001.html From rob at robburns.com Tue Apr 29 03:24:49 2008 From: rob at robburns.com (Robert J Burns) Date: Tue, 29 Apr 2008 12:24:49 +0200 Subject: [html4all] default namesapce declarations In-Reply-To: <18995994-5929-4770-AF39-851812067C23@robburns.com> References: <18995994-5929-4770-AF39-851812067C23@robburns.com> Message-ID: I forgot the alt='' on the second color adjusted image. It would really suck if my HTML conformance checker didn't bring that immediately to my attention. :-) Take care, Rob On Apr 29, 2008, at 12:21 PM, Robert J Burns wrote: >

just a regular paragraph with only strictly inline > content a and an img a lengthy > description of the image > Another copy of the same image with the color adjusted a:described-by='myimg' > >

> From jason at jasonjgw.net Tue Apr 29 03:36:21 2008 From: jason at jasonjgw.net (Jason White) Date: Tue, 29 Apr 2008 20:36:21 +1000 Subject: [html4all] some reflections on @alt usage In-Reply-To: References: Message-ID: <20080429103621.GA21981@jdc.jasonjgw.net> On Tue, Apr 29, 2008 at 06:00:31AM -0400, Vlad Alexander wrote: > And that will not change until major Web browsers will begin to report > invalid markup to the users in some way. There is no incentive for tool > vendors to generate standards-compliant markup if it gets treated by Web > browsers the same as tag soup. In fact, HTML 5 will make the problem even > worse. HTML 5 will help Web browsers parse tag soup better which will then > provide less incentive for authors and tool vendors to author Web pages to > specification and thus creating more tag soup on the Web. Another way of thinking about this is that tag soup thereby becomes part of the standard. If the error handling is specified, this means that user agents have to treat "invalid" markup as the spec dictates, which processing can then be relied on by authors and authoring tools. This is why I suggested in an earlier contribution that the @alt discussion is ultimately a question of what markup validators should treat as acceptable. These days we have accessibility validators as well as markup validators - I think we need general "good practice" validators (lint for HTML, CSS, etc.), - but irrespective of this, it is important to realize just how narrow the issues are which have inspired so much discussion recently. If you accept the premise of HTML 5 that user agents should parse and handle broken markup in predictable, specified ways, then the question inevitably arises as to how missing @alt should be treated. Note that this question occurs, under the assumptions of HTML 5, regardless of whether the spec goes on to assert that missing @alt is syntactically incorrect. The only practical effect of declaring it as syntactically ill-formed, would be to determine what validating parsers accept. In the end, I think the answer matters, but not much. That is, there are so many accessibility-related checks that can be performed, but which go beyond what a markup validator (even under HTML 4) is required to test, that in order to produce quality content, any authoring tool will have to implement much more extensive validation than is required by the HTML spec. This being the case, I doubt that it makes much practical difference whether @alt is mandatory or optional in the grammar, given that if it is missing, error handling will have to be specified (or left for implementations to define), and any worthwhile validator that checks content for accessibility, internationalization, or other desirable practices will have to go beyond syntactic well-formedness testing anyway. From P.Taylor at Rhul.Ac.Uk Tue Apr 29 04:02:08 2008 From: P.Taylor at Rhul.Ac.Uk (Philip TAYLOR (Ret'd)) Date: Tue, 29 Apr 2008 12:02:08 +0100 Subject: [html4all] default namesapce declarations In-Reply-To: <18995994-5929-4770-AF39-851812067C23@robburns.com> References: <18995994-5929-4770-AF39-851812067C23@robburns.com> Message-ID: <48170030.6080807@Rhul.Ac.Uk> I don't want to be picky (and to be honest, I'm not sufficiently au fait with the need for name spaces to comment from a position of authority) but IMHO the use of "h4" here > xmlns:h4='http://www.w3.org/1999/xhtml' and here > as with "a" here > ? xmlns:a (for ARIA); terribly confusing. If (as I suspect) "h4" means "HTML4" and "a" means "ARIA", then why not > xmlns:hhtml4='http://www.w3.org/1999/xhtml' > > ? xmlns:aria (for ARIA) so as to render impossible any confusion with

and ? ** Phil. -------- Robert J Burns wrote: > Hello all, > > Yesterday I raised namespaces [...] From rob at robburns.com Tue Apr 29 04:08:21 2008 From: rob at robburns.com (Robert J Burns) Date: Tue, 29 Apr 2008 13:08:21 +0200 Subject: [html4all] default namesapce declarations In-Reply-To: <48170030.6080807@Rhul.Ac.Uk> References: <18995994-5929-4770-AF39-851812067C23@robburns.com> <48170030.6080807@Rhul.Ac.Uk> Message-ID: <36485930-656C-4F22-8E9E-D8DA3C741293@robburns.com> Those suggestions would be fine. I was trying to minimize the syntax it to the extreme. Actually both declarations could be made by default (a: and aria:) and authors would be free to choose the syntax they wanted. I agree though that sometimes there's an attempt to make things overly terse which damages readability. Take care, Rob On Apr 29, 2008, at 1:02 PM, Philip TAYLOR (Ret'd) wrote: > I don't want to be picky (and to be honest, > I'm not sufficiently au fait with the need > for name spaces to comment from a position > of authority) but IMHO the use of "h4" here > > > xmlns:h4='http://www.w3.org/1999/xhtml' > > and here > > > > > as with "a" here > > > ? xmlns:a (for ARIA); > > terribly confusing. If (as I suspect) "h4" > means "HTML4" and "a" means "ARIA", then why > not > > > xmlns:hhtml4='http://www.w3.org/1999/xhtml' > > > > ? xmlns:aria (for ARIA) > > so as to render impossible any confusion with >

and ? > > ** Phil. > > -------- > > Robert J Burns wrote: >> Hello all, >> >> Yesterday I raised namespaces [...] > > _______________________________________________ > List_HTML4all.org mailing list > http://www.html4all.org/wiki From lhs at malform.no Tue Apr 29 05:12:47 2008 From: lhs at malform.no (Leif Halvard Silli) Date: Tue, 29 Apr 2008 14:12:47 +0200 Subject: [html4all] some reflections on @alt usage In-Reply-To: <20080429103621.GA21981@jdc.jasonjgw.net> References: <20080429103621.GA21981@jdc.jasonjgw.net> Message-ID: <481710BF.7000006@malform.no> Jason White 2008-04-29 12.36: > On Tue, Apr 29, 2008 at 06:00:31AM -0400, Vlad Alexander wrote: > > And that will not change until major Web browsers will begin to report > > invalid markup to the users in some way. There is no incentive for tool > > vendors to generate standards-compliant markup if it gets treated by Web > > browsers the same as tag soup. In fact, HTML 5 will make the problem even > > worse. HTML 5 will help Web browsers parse tag soup better which will then > > provide less incentive for authors and tool vendors to author Web pages to > > specification and thus creating more tag soup on the Web. > Vlad, why can't such tools have error checkers anyhow? Why can't browsers have them? iCab has always had one. (But, ps, the idea had about an unready stamp comes to mind. It does not seem appropriate to receive the full load of errors messages at all steps of the author process.) > This is why I suggested in an earlier contribution that the @alt discussion is > ultimately a question of what markup validators should treat as acceptable. > > If you accept the premise of HTML 5 that user agents should parse and handle > broken markup in predictable, specified ways, then the question inevitably > arises as to how missing @alt should be treated. > I doubt that it makes much practical difference whether @alt is > mandatory or optional in the grammar, given that if it is missing, error > handling will have to be specified (or left for implementations to define) Jason, now that you say it, this sounds so obvious. And it makes me think that the ideas driving HTML 5 has not been implemented when it comes to @alt. At least, I see no error handeling being specified. Yes, of course, it would be entirely in the spirit of HTML 5 to say that a missing alt should be corrected in the DOM. To put it like that would be to say that a missing ALT is, in fact, an error. Correcting it in the DOM should also help screen reader users, since they need to read the web through a graphical User Agent. To leave the issue to the implementations to define, does not seem to be in the spirit of HTML 5, as it would be unpredictable. So, what should the DOM do with a missing alt? Should it always be corrected in the same way, for instasnce by enumerating the images in a certain way? Or can some contexts be identfied, and some contextual error handeling be specified? -- leif halvard silli From vlad.alexander at xstandard.com Tue Apr 29 11:38:56 2008 From: vlad.alexander at xstandard.com (Vlad Alexander (XStandard)) Date: Tue, 29 Apr 2008 14:38:56 -0400 Subject: [html4all] some reflections on @alt usage Message-ID: > Another way of thinking about this is that tag soup thereby > becomes part of the standard. Well said. > Vlad, why can't such tools have error checkers anyhow? > Why can't browsers have them? They can and it can be done in an informative and non-intrusive way. And if stakeholders in the Web wanted to, tag soup can be significantly reduced and a good portion of the Web can be made accessible even with HTML 4. But this is not going to happen. None of the major stakeholders in the Web really wants to have an honest conversation about the problems of the Web and how to solve them. Regards, -Vlad http://xstandard.com -------- Original Message -------- From: Leif Halvard Silli Date: 2008-04-29 8:12 AM > Jason White 2008-04-29 12.36: >> On Tue, Apr 29, 2008 at 06:00:31AM -0400, Vlad Alexander wrote: >>> And that will not change until major Web browsers will begin to report >>> invalid markup to the users in some way. There is no incentive for tool >>> vendors to generate standards-compliant markup if it gets treated by Web >>> browsers the same as tag soup. In fact, HTML 5 will make the problem even >>> worse. HTML 5 will help Web browsers parse tag soup better which will then >>> provide less incentive for authors and tool vendors to author Web pages to >>> specification and thus creating more tag soup on the Web. >> > > Vlad, why can't such tools have error checkers anyhow? Why can't > browsers have them? iCab has always had one. (But, ps, the idea had > about an unready stamp comes to mind. It does not seem appropriate to > receive the full load of errors messages at all steps of the author > process.) > >> This is why I suggested in an earlier contribution that the @alt discussion is >> ultimately a question of what markup validators should treat as acceptable. >> >> If you accept the premise of HTML 5 that user agents should parse and handle >> broken markup in predictable, specified ways, then the question inevitably >> arises as to how missing @alt should be treated. >> I doubt that it makes much practical difference whether @alt is >> mandatory or optional in the grammar, given that if it is missing, error >> handling will have to be specified (or left for implementations to define) > > Jason, now that you say it, this sounds so obvious. And it makes me > think that the ideas driving HTML 5 has not been implemented when it > comes to @alt. At least, I see no error handeling being specified. > > Yes, of course, it would be entirely in the spirit of HTML 5 to say that > a missing alt should be corrected in the DOM. To put it like that would > be to say that a missing ALT is, in fact, an error. Correcting it in the > DOM should also help screen reader users, since they need to read the > web through a graphical User Agent. > > To leave the issue to the implementations to define, does not seem to be > in the spirit of HTML 5, as it would be unpredictable. > > So, what should the DOM do with a missing alt? Should it always be > corrected in the same way, for instasnce by enumerating the images in a > certain way? Or can some contexts be identfied, and some contextual > error handeling be specified?