[html4all] XHTML2 and alt

[Leif Halvard Silli]

Robert J Burns 2008-08-28 01.04:

> On Aug 28, 2008, at 1:17 AM, Leif Halvard Silli wrote:
>> Robert J Burns 2008-08-27 08.52:
>>> Aug 27, 2008, at 2:38 AM, Leif Halvard Silli:


>>>> [ ... @alt (not) in XHTML 2 ... ]


>>>> So, do we prefer <IMG> with @alt over the OBJECT/XHTML 2 model,
>>>> just because presence of @alt is checked in the HTML validator?

   [...]

>> There is also a conflict between using the fallback to explain how
>> to e.g. load a failing video (think about <video> in HTML 5 in its
>> current shape and form) and providing real, textual fallback.

   [...]

> I don't think there's a conflict per se. The problem with both VIDEO  
> and AUDIO is that Ian has arbitrarily decided to prohibit the use of  
> the element's contents for textual fallback. The existence of ordered  
> <source> elements within these elements does not prevent other textual  
> fallback. After all the object element also has param elements that  
> are very similar to source elements. In fact source elements are not  
> really semantically different from <param name='source' value='URI' >  
> (compared with <source src='uri'>.  Yet the object element also  
> supports textual fallback after the param elements. I would like to  
> see the object element also support the source element (along with the  
> other audio and video element features). Yet all these elements could  
> still support textual fallback.


I don't think you explained what I asked. This is my simple issue: 
If the fallback is supposed to play two roles, then the content 
needs to be authored so that the one purpose does not disturb the 
other - either that, or there needs to a mechanism that separate 
the two issues in a userselectable way.

>>>> Talking about Karl Dubost's private photo album that he mentioned
>>>> in the HTMLwg: What would be best, today, for all his thousands of
>>>> images: <img src=src alt=""> or <img src=src >?
>>>

>>> I think the best thing would be <img src='src'> and for
>>> Karl's page to be non-conforming. [...]


>> I did not know you were open to making @alt optional? ;-) Would
>> you have had that idea, if it were not for HTML 5/Ian/WHATwg's
>> idea that it should be possible to do so?
>>
>> The only difference between his and your idea is that he thinks
>> <img src=src> should be valid. Whereas you think not.
> 
> Well, yes that's what I thought the whole debate was about. My view is  
> that making alt required introduces authors to accessibility issues. I  
> don't even see the downside.


Very many sides of the @alt issue have been discussed 
simultaneously, recently. But, no, I did not know that being 
/syntactically/ invalid was one option for you or anyone else.

 
>> Yet, at the same time, even Ian says that lack of alt should be
>> the symbol of something lacking. So how big is the difference?
> 
> Ian's approach completely removes HTML conformance checking as a  
> mechanism to introduce authors to accessibility issues. Requiring  
> accessibility within HTML5 does introduce authors to accessibility.

At the same time, OBJECT, which is supposed to be superior to 
<img> accessibilitywise, can be completely empty without 
triggering any error.

All the @alt checking in HTML 4 does, is that it introduces the 
/idea/ that <img> can have fallback text.

For <object>, there is no (or less) need to introduce anyone to 
that idea. And, yes, both <object></object> and alt="" can be 
empty, and nothing happens, in the validator.

>> (Btw, when Laura told Karl that he should be non-conforming, then
>> I suppose she meant that he should use <img src=src alt="">, as
>> this would be non-conforming as well.)
> 
> I understood her as meaning non-conforming in a machine verifiable  
> way: in other words, with the alt attribute omitted.

Karl used the phrase "put alt text".

>> I for one, having read Ramans message etc, wonder if an /formally/
>> optional alt is part of the solution. At the very least I agree
>> with him that mixing validation with content/accessibilty checking
>> is problematic.
> 
> What is the problem? I haven't heard anyone explain what the problem is.

The problem is that authors do not manage to think about all 
things simultaneously. If ask for HTML syntax errors, then I do 
not want to be told about CSS errors or content/accessibilty errors.

In the case of @alt, the need for validation causes authors to do 
what you say they should not do: Adding empty alt="".

>>>> I think that - in effect - we are spreading the message that <img
>>>> alt="" ...> would be better than no alt, and also better than <img
>>>> alt="photo" ...>. I say this not because I think no alt should be
>>>> permitted, but because, in effect, I think that all we are really
>>>> defending is a syntax, and not accessibility.
>>>
>>> Personally, I want to defend the syntax for its accessibility  
>>> benefits.
>>
>> Above you said Karl should have used <img src=src> = no alt.
> 
> Yes. To produce a non-conforming document that didn't simply add  
> alt='' to pretend to be conforming. Both leaving off the alt attribute  
> and using alt='' are non-conforming. The former provides a quick way  
> for software to alert authors it is non-conforming while the latter  
> does not.


However, if we introduce @role, would it still matter with no alt 
vs. alt=""?

 
>> Understood. Hence @role. Which I agree is the way to check if
>> fallback is used and used correct for OBJECT and the like.
> 
> In an authoring tool, one can imagine the UI asking for alt text:
> 
> enter alt text: ________


It should ask for role before asking for alt text, in my view.

 
> buttons:
> [cancel/later]
> [decorative/none]
> [illustrative of surrounding text]
> [enter] {enter button enabled only when text if filled in}
> 
> This UI works for either <img alt='fallback'>, <img>fallback</img> or  
> <object>fallbck</object>


Good idea.
-- 
leif halvard silli