[html4all] XHTML2 and alt

[Leif Halvard Silli]

Robert J Burns 2008-08-28 15.17:

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


>> 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 <source> element is (planned as) a void element. If it had 
been planned as normal element, then one could have "technical 
fallback" inside the <source></source> element and textual 
fallback directly in the <video></video> element. See more below.

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


Why did you place the <source src=uri7 > after the fallback?

I don't see that this addressess my question. Because I don't see 
that you discern between technical fallback and media preferencial 
fallback.

But I think that this would:

<video>
<source src=format-a >Fallback: Info about how to see the 
video</source>
<source src=format-b >Fallback: Info about how to see the 
video</source>
<h1>Fallback: Transcript ...
<video>

For the <source src=format-a> and <source src=format-b >, the 
choice between the two would be dependent of what the User Agent 
supports - possibli in interecation with UA preferences that the 
user can regulate.

A text based browser or a screen reader could then go directly to 
the preferred media - the text fallback directly inside <video>.

Thoughts?

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


Basically, well-formed = correctly nested.

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

But as long as <img> is void, lack of well-formedness is no 
problem. If <img> was non-void, however, well-formedness and 
validity would be the same thing, since omitting the end tag would 
make the document both un-well-formed and invalid. Thus it should 
be simpler for authors to handle.

At any rate, the somewhat hard to get difference between 
well-formed, valid and non-conforming does not favour that 
accessibilty is checked together with syntax checkign.

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

Of course. But I had not thought about that errors with regard to 
@role should only provide warnings. However, if evaluating @role 
instead was part of an content/accessibility check, then it could 
create errors.

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


In that very exchange in the HTMLwg, I definitely felt there was a 
lack of presiction with regard to what kind of conformance etc one 
talked about.

>>> 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 suppose there is nothing which prevents anyone form making such 
"check-it-all" instrument.

My web browser, iCab, shows both CSS and HTML error 
simultaneously, and connect the errors to the file they appear in. 
Also, when I ask iCab to check the page in the W3 checker tools, 
then it does not only send it to the HTML checker, but also to 
other relevant checkers at W3.

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

The message that non-validity is less serious non-conformance, is 
difficult to sell.

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

Yup.

>>> In an authoring tool, one can imagine the UI asking for 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>

I think there is much good here. But there are some fundamental 
problems we must solve first ...
-- 
leif halvard sillli