Re: "downplayed errors"

Hi Jon,

On Feb 10, 2009, at 2:52 PM, Jon Barnett wrote:

> On Tue, Feb 10, 2009 at 11:37 AM, Robert J Burns <rob@robburns.com>  
> wrote:
>
> On Feb 9, 2009, at 8:32 PM, Ian Hickson wrote:
>
> As far as I can tell we already have consensus on alt="" being  
> required.
> (With one or two exceptions, the spec requires alt="" to be present.  
> The
> exceptions are machine-checkable.)
>
> I can't imagine at all how you think these could be machine- 
> checkable criteria when it comes to omitting alt. Could you tell us  
> a little about what you're thinking?
>
> There are three bullet points in 4.8.2.1.9 that are machine- 
> checkable when @alt is omitted.  The <figure> and <article><h1>  
> cases are pretty semantically specific.  The @title case is a little  
> less specific. (There may be more cases where @title may be present  
> but don't match the semantics for when @alt is omitted - key part of  
> content with no suitable alternate)
>
> Does that make sense?
>

No it doesn't make sense to me. While I can certainly understand:

1)  how images might get added to HTML documents in an automated  
fashion where the alt cannot be provided immediately; and
2) how authors might want to include images in figures where the  
figure caption, img title attribute, or the image has a heading  
provided specifically for that image that provides sufficient alt text.

I do not understand what the two situations have to do with one  
another. If images are pulled off a camera and incorporated into an  
HTML document in an  automated fashion, then there, there's no way to  
generate the caption, title attribute or heading text anymore than one  
can do so for the alternate text.

The problem is with the entire section with the heading: "Images whose  
contents are not known". The words themselves are what Wikipedia calls  
weasel words. And the entire section might serve some function, but it  
doesn't really relate to the heading at all.


> To me the easiest way to make this machine checkable is to remove  
> those few conditions that allow the alt attribute to be omitted and  
> always require the attribute (of course allowing authoring tools to  
> produce non-conforming documents when authors fail to provide  
> conforming alt text as any other case when an author uses an  
> authoring tool to produce a non-conforming document).
>
> And then in doing so you make the semantics of those more ambiguous  
> and less machine-checkable (irrelevant vs. relevant images) - unless  
> we go back to the discussion of adding extra markup for those cases  
> (another thread, I'm sure).

No quite the opposite. These conditions have nothing to do within the  
authoring pattern described in the section. So while we may  
technically have a machine-checkable condition right now, it feels  
much like earlier situations where the prose gets quietly changed in  
the dark of night (like when the 'p' element content model was reduced  
to not support tables and lists even in XML which as far as I can tell  
now was simply added to get the draft approved as the deliverable for  
the WG). Otherwise I can't imagine why much of this prose remains in  
the draft (such as the heading of this section: "Images whose contents  
are not known"). It is completely unrelated to the prose that follows  
it.

Whereas the "extra" markup you dread deliberating here in the WG was  
designed to address the use cases Ian has described, yet still not  
addressed. The draft neglects to provide any way to deal with the  
infamous Flickr case: despite the fact that many of us have offered  
machine-checkable approaches to do so. I imagine somewhere when we  
"whiners" go away, these completely unrelated machine-checkable  
requirements will be silently removed and the draft will be back to  
the "this image simply has an unknown alternate text, what can an  
author possibly do about it?"

> As it stands, machines can give better error and warning messages  
> for <img> elements covering more varied use cases.

No, the other suggestions such as using the role attribute and  
specialized role keywords for non-text media gave much better  
opportunities for error and warning messages that suited author's needs.

The biggest problem here is claiming that we cannot allow authoring  
tools to produce non-conforming HTML. Yet there is nothing we can do  
to prevent that. The authoring tool cannot (and in general should not)  
override the work of the author. That means that some times the author  
is going to put non-conforming content into a document using an  
authoring tool: many times with things that simply are not machine- 
checkable. Is is the same with alternate text. At times authors will  
neglect to provide it and therefore produce—with the assistance of an  
authoring tool—a non-conforming HTML document. Again there's nothing  
we can do to prevent that and it's not something we need to worry  
about in this WG.

Take care,
Rob