RE: RESOLUTION to modify text alternative change proposal and reject WAI CG's consensus recommendation

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