[html4all] XHTML2 and alt

[Robert J Burns]

Hi Leif,

On the issue of technical fallback versus media preferential fallback  
versus textual fallback, I fear I'm not understanding you at all. In  
terms of instructions for adding plugins/handlers, I'm fine with the  
UA handling that in a localized fashion (especially since much non- 
text media is inherently internationalized).

On the issue of syntactic errors, I don't think leaving alt off of an  
attribute is a syntax error. It is invalid, but neither a syntax error  
nor a well-formedness error. Basically, I agree with what Al Gilman  
says[1]. A syntax error would be to add an atl attribute (intending to  
add the alt attribute).

Take care,
Rob

[1]: <http://lists.w3.org/Archives/Public/public-html/2008Aug/0871.html>

On Aug 28, 2008, at 6:33 PM, Leif Halvard Silli wrote:

> 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
>
> _______________________________________________
> List_HTML4all.org mailing list
> http://www.html4all.org/wiki
> Archives: http://html4all.org/mailman/private/list_html4all.org/