Re: "downplayed errors"

Hi Jon,

Jon Barnett 2009-02-10 21.52:
> 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?

I think the draft has moved in a right direction. Comments:

A) Below you talk about "warning messages". Hence, do you agree 
that the machine-checkable conditions, when met, should, in 
Charles' words[1], be considered "conforming but not recommended"?

B) W.r.t. the non-empty @title condition: Do you have any valid 
usecase for where an empty @alt in combination with an non-empty 
@title, should be the right thing?

IMHO such cases do no exist. Semantics and machine-checkability 
should thus be equal whether @alt is empty or un-present:

	<img alt="" src=x title="Photography: Mr Xyz." >
	<img        src=x title="Photography: Mr Xyz." >

If author tools, including validators, treat both empty @alt and 
un-present @alt as "conforming but not recommended" for the 
machine-checkable conditions, then, in order to discern beetween 
alt="" as a "decorative image signal" and alt="" for images which 
are "key part of the content", the author only needs to consider 
whether the <IMG> contains a non-empty @title or not.

Thus, un-present @alt-s as a private signal to the author himself 
that the IMG is key part of the content, aren't really needed, 
unless non-empty @title-s are very much unwanted. And perhaps 
those usecases are not not worth catering for? It would eventually 
only be the figure/section case that could benefit.

C) The only difference I see between the two <IMG> elements above, 
is w.r.t. the expectance of content-repair: The latter is more 
likely to be semantically repaired for the lack of @alt, than the 
former likely to be semantically repaired for the lack of content 
inside the @alt. I think that UAs should treat both cases the same 
way w.r.t. content-repair. Doing so would not break the Web.

>> 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).
> 
> As it stands, machines can give better error and warning messages for <img>
> elements covering more varied use cases.

I agree that the current direction can help authors to think about 
what they are doing - it isn't only a simple "add a empty alt in 
order to stay valid". However, it seems to me that it is possible 
to go much further. For instance, it should be machin-checkable 
whether the img@alt is identical to the figure caption etc.

[1] http://www.w3.org/mid/op.uo350sj3wxe0ny@widsith.local
-- 
leif halvard silli

Received on Wednesday, 11 February 2009 03:00:02 UTC