Re: [html4all] some reflections on @alt usage

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  

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.



Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk   Try Opera 9.5:

Received on Tuesday, 29 April 2008 09:28:24 UTC