[html4all] XHTML2 and alt

[Robert J Burns]

On Aug 28, 2008, at 3:20 AM, Leif Halvard Silli wrote:

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

I'm not sure I still understand the question. My thinking is that  
video (or audio), as the highest element in the hierarchy implies that  
the video is the first choice of the author. The source elements  
contained in the element serve as fallback to separate resources each  
serving as a video resource in the order the author prefers. The  
remaining contents of the video serve as the textual (or HTML)  
fallback for the video when none of the video is available, or not  
supported by the UA, or not desired by the user.

For example:

<video>
   <source src='uri1' >
   <source src='uri2' >
   <source src='uri'3 >
   <source src='uri4' >
   <p>Here's some text fallback with even other <img src='uri5'  
alt='image fallback'> non-text media including objects <object  
data='uri6'>some more fallback text</object>..
   </p>
   <source src='uri7' >
</video>

Does that address the question. The UA chooses the first suitable  
resource referenced by a source element in document tree order. If  
none are suitable, it turns to the other contents of the video element  
and renders that.


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

This goes to the distinction introduced with XML between well-formed  
and invalid. I would not advocate authors ever produce ill-formed  
syntax (though HTML5 does support that). However, I do think that  
validity is of lower importance. It means the document is non- 
conforming, though well-formed. However, adding alt='' to an IMG  
element that should have replacement text is till non-conforming. The  
first case allows authors to easily discover their non-conformance  
problems with software. The latter non-conforming requires a careful  
read by a human of every embedded media element in the document. So  
certainly I prefer the former non-conforming to the latter non- 
conforming (with my authors hat on). But both are non-conforming and  
both are well-formed (but instead not valid).

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

Except with the role attribute keywords we can now introduce  
recommendations that text be present (and therefore conformance  
checker provide warnings — but not errors — when they do not have any  
text)

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

OK.

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

But with role, that will not necessarily help them avoid conformance  
checker messages (either errors, warning or suggestions). The key  
thing — both for combining CSS, Accessibility, HTML, etc into one  
conformance tool and also prodding authors whenever fallback is  
missing — is to provide conformance software that allows authors to  
filter, suppress, sort, arrange hierarchically all of the messages  
from the tool.

>
>
>>>>> 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=""?

I think it matters less. Plus it solves the problem of <img  
role='keyword' >fallback</img> and <object role='keyword' >fallback</ 
object>

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

Yeah, after I did this it occurred to me of using radio buttons  
instead. Combining that with your suggestion:

Role:
             (•) decorative
             (•) illustrative of surrounding text
             (•) other {when other is enabled the following popup and  
input field appear}
                    [ popup: other roles enabled when the other radio  
button is selected ]
                 Alt text:  _________________
  {with a localized hint string depending on the role selected from  
the popup}

[cancel/later/defer] [enter]

with the resulting source:

defer | <img>    <img></img> <object></object> {where the cancel/defer  
button still adds the image but leaves it non-conforming in a machine  
discoverable way }
decorative | <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>
other role | <img role='<entered role>' alt='<entered fallback>'> <img  
role='<entered role>'  ><entered fallback> </img>
<object role='<entered role>' ><entered fallback></object>

>> This UI works for either <img alt='fallback'>, <img>fallback</img> or
>> <object>fallbck</object>
>
>
> Good idea.

Thanks.

Take care,
Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://wilbur.bytowninternet.com/pipermail/list_html4all.org/attachments/20080828/d6b658fe/attachment-0001.html