[html4all] XHTML2 and alt

[Robert J Burns]

Hi Leif,

[moving to public list]

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?
>>
>> Well, the primary purpose for my message was exploring whether the
>> same benefits could be gained for the OBJECT/XHTML2 case. I think one
>> drawback I overlooked is that the errors for text/html IMG can be
>> avoided with alt='' while the other case would require the user to
>> enter an actual value. This could lead to more bogus placeholder text
>> than in the alt= case.
>
>
> There is a danger taht OBJECT could lead to more bogus fallback
> than does @alt. Agree.
>
> 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.
>
> However, both kinds of fallback are, per se, valid use cases. How
> can both issues be provided for, simultaneously?

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.


>
> [...]
>
>>>> [...] accessibility benefits an <img>fallback</img> [...]
>>>>
>>>> Even with XML serializations and IMG with no alt, the conformance
>>>> checker can still provide warnings whenever the IMG element has no
>>>> significant text content.
>>>
>>> Yes, but that issue has been forgotten. Doesn't this show that
>>> that the @alt checking in the HTML 4 validator really is a syntax
>>> check, and not a accessibility check?
>>
>> I don't think the issue of accessibility has been forgotten in  
>> XHTML2. [...]
>
>
> Right. And, if we include the WCAG recommendations, we could say
> that even in HTML, it has not been forgotten, not even for the
> <OBJECT> element. But reality is that we discuss @alt over and
> over, but not <object>.

I agree, that object needs to be addressed too. Though I think the  
role and describedby attributes provide everything we need (along with  
the element's contents).

>
>
> [ ... ]
>
>
>>> 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. Karl won't be put to death for his non-conforming
>> page. However, leaving the alt attribute missing allows Karl and
>> subsequent authors of the same document to discover and repair the
>> errors. Adding alt='' glosses over those errors and doesn't make the
>> page conforming (it only fools the machine and remains 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.

> 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.

> (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.

> 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.

>>> 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.

>>> To link this to Rob's message: We should try to look at <img> more
>>> like we look at <object> and go on from there.
>>
>> The purpose of my message was to try to understand how <object> could
>> be conformance checked in a way that preserved the accessibility
>> awareness raising of having the alt attribute.
>
> 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: ________

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>

cancel/later: <img>    <img></img> <object></object>
decorative/none: <img role='decor'> <img role='decor'></img> <object  
role='decor' ></object>
illustrative of surrounding text <img role='illustrative'> <img  
role='illustrative'></img> <object role='illustrative ></object>
enter <img alt='entered fallback'> <img> entered fallback </img>  
<object> entered fallback </object>

The authoring tool can further check the spelling and grammar of the  
text and alert the author if it appears to be bogus text and require  
further confirmation.

>
>
>> So I think we should get authoring tools and conformance checkers to
>> add much from WCAG, ARIA and other accessibility related
>> recommendations. We should also make sure the other embedding  
>> elements
>> retain accessibility capabilities so that <img alt= > is not the only
>> accessible embedding mechanism. Finally, I think we should be
>> strengthening the conformance norms for accessibility in HTML5 and  
>> not
>> weakening them. I've written about this before[1], but I think we
>> should recommend make conformance more stringent while recommending
>> conformance checkers allow authors to suppress error and warnings  
>> on a
>> per session basis (requiring that the suppression preference not be
>> stored persistently, but requires the author to suppress on each
>> launch of the application, or scan of a document). I don't think
>> anything more is required to satisfy the issues raised by the WhatWG
>> crowd.
>
> Very spesific rules for how validation should happen ..

That would help too. I've written on that before along with authoring  
tool norms. I'll try to find those previous emails.

Take care,
Rob