- From: John Foliot <jfoliot@stanford.edu>
- Date: Sat, 10 Apr 2010 22:16:26 -0700 (PDT)
- To: "'Laura Carlson'" <laura.lee.carlson@gmail.com>
- Cc: "'Janina Sajka'" <janina@rednote.net>, "'HTML Accessibility Task Force'" <public-html-a11y@w3.org>, "'Michael\(tm\) Smith'" <mike@w3.org>, "'Michael Cooper'" <cooper@w3.org>, "'Judy Brewer'" <jbrewer@w3.org>, <wai-cg@w3.org>
Laura Carlson wrote: > > Hi John, Hey <grin> > > > I've stated my preference for using the stronger ERROR, and that, > > The resolution did not say "Modify Laura's change proposal to have the > conformance checker normatively emit a warning as opposed to an error > for text alternatives AND @src..." I get that. See my point #1 (above) > > > However, if, as Janina suggests, the fastest way to the bigger > > win (pointing to WAI Guidance for repair/remediation) is to call it a > > warning, then I say go for the bigger win. > > The resolution also referred to "the conformance checker". > > HTML5 mandating that ALL validators (not just Henri's) point to WAI > Guidance would certainly help educate authors and encourage them in > the right direction. Requiring such systems to do so would be a big > step in the right direction. That's in some ways an UAAG question. I agree however, and I am not of the impression that we are talking about only one validator in the recommendation. While I acknowledge the limitation of just one validator today, I suspect that once we settle down to a Standard, that others will emerge, including likely embedded validation/evaluation tools in editors. (I wonder what Rich might have to say about that?) We might also want to look at upload scripts, etc. that online tools use (the Flickr example), and work with the scripting folks at that level. If the issue is one of adding the letter "s" to Validator, surely we can do that. That's not a deal breaker is it? > > However this does not rectify the inequity. Without both @src and a > text alternative the <img> element is broken. Making them both a just > warning doesn’t make sense. Both are needed for an image to be > complete. Both are on the same level. Laura, you are preaching to the converted. Do you know why I call myself the "Unrepentant Hardliner"?[1,2] Why my twitter bio mentions "Extremist Frosting"?[3] The logical extension of what you are saying is what I've said for years; if it is incomplete it simply should not render in the browser - it's an error. Agreed! *But*, <img> with @src and no @alt will continue to render in the browsers, and no matter how much pleading, arguing and even W3C Standards making we make, this will NEVER change. Without a draconian fail, we are disadvantaged: and we will never get the draconian fail, so now what? An ERROR without any real consequences is meaningless in the real world.[4] I don't *CARE* what it is called, I care what happens to correct the problem. If browsers will continue to render incomplete <img>s, we need to go after the source of the problem, and attack it higher up the food chain; at the creation level, not the deployment level. I honestly don't think that HTML5 is going to be hand-rolled code for very long - do you, does anyone? The bulk of the code will come from authoring/editing tools, whether embedded into large system tools like CMSes, or stand-alone tools such as the (presumed) next generation of editors like Dreamweaver. So, if this is taken as a true statement, let's go work there to ensure that we get the best that we can get at that level, complete with HTML5 normative text that tells them what and how to address the problem of images with no alt text. Getting normative text in the spec that uses MUST language, saying that validators (and editors) MUST point to WAI authored help text when there is no @alt is likely the best we will get (as the next step is draconian fail - unless I've missed something), and going to the HTML WG with a one-time no-budge proposition such as this is likely our best shot; the browser folk won't really care or argue as they will continue to display broken (by our definition) images in their browsers no matter what, but now we have normative text in the spec that we can use at the Editor and Validator stages, text that is focused primarily at them. This is where the problem exists, and where we can actually gain ground - we aren't going to get it from the browsers. > > I hope that the task force reconsiders and supports the change > proposal [1] which implements WAI-CG's recommendation. Again, I really don't see where calling it an ERROR, WARNING, or Green Jello [5 - for Gez] has any real impact on the overall recommendation of your Change Proposal. In fact, the initial Summary paragraph states: "It requires any page that lacks a text alternative for an image by at least one of the machine testable options to have the validator flag an error and declare the page invalid." ...flag an error... Everything else in your Change Proposal remains (as I understand it) intact; the behaviors, the target audience, the thrust behind what we need is all there, and in this you have my personal 100% backing should it ever come to an actual vote, I'd fight for those requirements in no uncertain terms. But let's not worry about a word, a name, a point of order. It's not going to get us what we really need and want, and really (to me) it's not what we should be fighting for. Respectfully, JF [1 http://diveintomark.org/archives/2009/03/18/if-it-fails-for-some] [2 http://lists.w3.org/Archives/Public/public-html/2009Mar/0418.html] [3 http://www.simmerspaintshop.com/forums/dlcat-military-fonts-19/] [4 http://john.foliot.ca/consequences/] [5 http://bit.ly/cIoSKm]
Received on Sunday, 11 April 2010 05:17:01 UTC