<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Aug 28, 2008, at 3:20 AM, Leif Halvard Silli wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Robert J Burns 2008-08-28 01.04:<br><br><blockquote type="cite">On Aug 28, 2008, at 1:17 AM, Leif Halvard Silli wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite">Robert J Burns 2008-08-27 08.52:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Aug 27, 2008, at 2:38 AM, Leif Halvard Silli:<br></blockquote></blockquote></blockquote><br><br><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">[ ... @alt (not) in XHTML 2 ... ]<br></blockquote></blockquote></blockquote></blockquote><br><br><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">So, do we prefer &lt;IMG> with @alt over the OBJECT/XHTML 2 model,<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">just because presence of @alt is checked in the HTML validator?<br></blockquote></blockquote></blockquote></blockquote><br> &nbsp;&nbsp;[...]<br><br><blockquote type="cite"><blockquote type="cite">There is also a conflict between using the fallback to explain how<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">to e.g. load a failing video (think about &lt;video> in HTML 5 in its<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">current shape and form) and providing real, textual fallback.<br></blockquote></blockquote><br> &nbsp;&nbsp;[...]<br><br><blockquote type="cite">I don't think there's a conflict per se. The problem with both VIDEO &nbsp;<br></blockquote><blockquote type="cite">and AUDIO is that Ian has arbitrarily decided to prohibit the use of &nbsp;<br></blockquote><blockquote type="cite">the element's contents for textual fallback. The existence of ordered &nbsp;<br></blockquote><blockquote type="cite">&lt;source> elements within these elements does not prevent other textual &nbsp;<br></blockquote><blockquote type="cite">fallback. After all the object element also has param elements that &nbsp;<br></blockquote><blockquote type="cite">are very similar to source elements. In fact source elements are not &nbsp;<br></blockquote><blockquote type="cite">really semantically different from &lt;param name='source' value='URI' > &nbsp;<br></blockquote><blockquote type="cite">(compared with &lt;source src='uri'>. &nbsp;Yet the object element also &nbsp;<br></blockquote><blockquote type="cite">supports textual fallback after the param elements. I would like to &nbsp;<br></blockquote><blockquote type="cite">see the object element also support the source element (along with the &nbsp;<br></blockquote><blockquote type="cite">other audio and video element features). Yet all these elements could &nbsp;<br></blockquote><blockquote type="cite">still support textual fallback.<br></blockquote><br><br>I don't think you explained what I asked. This is my simple issue: <br>If the fallback is supposed to play two roles, then the content <br>needs to be authored so that the one purpose does not disturb the <br>other - either that, or there needs to a mechanism that separate <br>the two issues in a userselectable way.</div></blockquote><div><br></div><div>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.</div><div><br></div><div>For example:</div><div><br></div><div>&lt;video></div><div>&nbsp;&nbsp;&lt;source src='uri1' ></div><div>&nbsp;&nbsp;&lt;source src='uri2' ></div><div>&nbsp;&nbsp;&lt;source src='uri'3 ></div><div>&nbsp;&nbsp;&lt;source src='uri4' ></div><div>&nbsp;&nbsp;&lt;p>Here's some text fallback with even other &lt;img src='uri5' alt='image fallback'> non-text media including objects &lt;object data='uri6'>some more fallback text&lt;/object>..</div><div>&nbsp;&nbsp;&lt;/p></div><div>&nbsp;&nbsp;&lt;source src='uri7' ></div><div>&lt;/video></div><div><br></div><div>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.</div><div><br></div><br><blockquote type="cite"><div><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Talking about Karl Dubost's private photo album that he mentioned<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">in the HTMLwg: What would be best, today, for all his thousands of<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">images: &lt;img src=src alt=""> or &lt;img src=src >?<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><br><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I think the best thing would be &lt;img src='src'> and for<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Karl's page to be non-conforming. [...]<br></blockquote></blockquote></blockquote><br><br><blockquote type="cite"><blockquote type="cite">I did not know you were open to making @alt optional? ;-) Would<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">you have had that idea, if it were not for HTML 5/Ian/WHATwg's<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">idea that it should be possible to do so?<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">The only difference between his and your idea is that he thinks<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">&lt;img src=src> should be valid. Whereas you think not.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Well, yes that's what I thought the whole debate was about. My view is &nbsp;<br></blockquote><blockquote type="cite">that making alt required introduces authors to accessibility issues. I &nbsp;<br></blockquote><blockquote type="cite">don't even see the downside.<br></blockquote><br><br>Very many sides of the @alt issue have been discussed <br>simultaneously, recently. But, no, I did not know that being <br>/syntactically/ invalid was one option for you or anyone else.</div></blockquote><div><br></div>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).</div><div><br><blockquote type="cite"><div><blockquote type="cite"><blockquote type="cite">Yet, at the same time, even Ian says that lack of alt should be<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">the symbol of something lacking. So how big is the difference?<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Ian's approach completely removes HTML conformance checking as a &nbsp;<br></blockquote><blockquote type="cite">mechanism to introduce authors to accessibility issues. Requiring &nbsp;<br></blockquote><blockquote type="cite">accessibility within HTML5 does introduce authors to accessibility.<br></blockquote><br>At the same time, OBJECT, which is supposed to be superior to <br>&lt;img> accessibilitywise, can be completely empty without <br>triggering any error.<br><br>All the @alt checking in HTML 4 does, is that it introduces the <br>/idea/ that &lt;img> can have fallback text.<br><br>For &lt;object>, there is no (or less) need to introduce anyone to <br>that idea. And, yes, both &lt;object>&lt;/object> and alt="" can be <br>empty, and nothing happens, in the validator.</div></blockquote><div><br></div><div>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)</div><br><blockquote type="cite"><div><blockquote type="cite"><blockquote type="cite">(Btw, when Laura told Karl that he should be non-conforming, then<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I suppose she meant that he should use &lt;img src=src alt="">, as<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">this would be non-conforming as well.)<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I understood her as meaning non-conforming in a machine verifiable &nbsp;<br></blockquote><blockquote type="cite">way: in other words, with the alt attribute omitted.<br></blockquote><br>Karl used the phrase "put alt text".</div></blockquote><div><br></div>OK.</div><div><br><blockquote type="cite"><div><blockquote type="cite"><blockquote type="cite">I for one, having read Ramans message etc, wonder if an /formally/<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">optional alt is part of the solution. At the very least I agree<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">with him that mixing validation with content/accessibilty checking<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">is problematic.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">What is the problem? I haven't heard anyone explain what the problem is.<br></blockquote><br>The problem is that authors do not manage to think about all <br>things simultaneously. If ask for HTML syntax errors, then I do <br>not want to be told about CSS errors or content/accessibilty errors.<br><br>In the case of @alt, the need for validation causes authors to do <br>what you say they should not do: Adding empty alt="".</div></blockquote><div><br></div><div>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.</div><br><blockquote type="cite"><div><br><br><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I think that - in effect - we are spreading the message that &lt;img<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">alt="" ...> would be better than no alt, and also better than &lt;img<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">alt="photo" ...>. I say this not because I think no alt should be<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">permitted, but because, in effect, I think that all we are really<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">defending is a syntax, and not accessibility.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Personally, I want to defend the syntax for its accessibility &nbsp;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">benefits.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Above you said Karl should have used &lt;img src=src> = no alt.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Yes. To produce a non-conforming document that didn't simply add &nbsp;<br></blockquote><blockquote type="cite">alt='' to pretend to be conforming. Both leaving off the alt attribute &nbsp;<br></blockquote><blockquote type="cite">and using alt='' are non-conforming. The former provides a quick way &nbsp;<br></blockquote><blockquote type="cite">for software to alert authors it is non-conforming while the latter &nbsp;<br></blockquote><blockquote type="cite">does not.<br></blockquote><br><br>However, if we introduce @role, would it still matter with no alt <br>vs. alt=""?</div></blockquote><div><br></div><div>I think it matters less. Plus it solves the problem of &lt;img role='keyword' >fallback&lt;/img> and &lt;object role='keyword' >fallback&lt;/object></div><br><blockquote type="cite"><div><blockquote type="cite"><blockquote type="cite">Understood. Hence @role. Which I agree is the way to check if<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">fallback is used and used correct for OBJECT and the like.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">In an authoring tool, one can imagine the UI asking for alt text:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">enter alt text: ________<br></blockquote><br><br>It should ask for role before asking for alt text, in my view.</div></blockquote><div><br></div>Yeah, after I did this it occurred to me of using radio buttons instead. Combining that with your suggestion:</div><div><br></div><div>Role:</div><div>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;(•)&nbsp;decorative</div><div>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;(•)&nbsp;illustrative of surrounding text</div><div>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;(•) other {when other is enabled the following popup and input field appear}</div><div>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; [ popup: other roles enabled when the other radio button is selected ]</div><div>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Alt text: &nbsp;_________________</div><div>&nbsp;{with a localized hint string depending on the role selected from the popup}</div><div><br></div><div>[cancel/later/defer]&nbsp;[enter]<br><div><font class="Apple-style-span" color="#006312"><br></font></div><div><font class="Apple-style-span" color="#006312">with the resulting source:</font></div><div><font class="Apple-style-span" color="#006312"><br></font></div><div><font class="Apple-style-span" color="#006312"><span class="Apple-style-span" style="color: rgb(0, 0, 0); ">defer | &lt;img> &nbsp;&nbsp;&nbsp;&lt;img>&lt;/img> &lt;object>&lt;/object> {where the cancel/defer button still adds the image but leaves it non-conforming in a machine discoverable way }<br>decorative | &lt;img role='decor'> &lt;img role='decor'>&lt;/img> &lt;object role='decor' >&lt;/object><br>illustrative of surrounding text |&nbsp;&lt;img role='illustrative'> &lt;img role='illustrative'>&lt;/img> &lt;object role='illustrative >&lt;/object><br>other role | &lt;img role='&lt;entered role>' alt='&lt;entered fallback>'> &lt;img role='&lt;entered role>'&nbsp; >&lt;entered fallback> &lt;/img> &nbsp;</span></font></div><div><font class="Apple-style-span" color="#006312"><span class="Apple-style-span" style="color: rgb(0, 0, 0); ">&lt;object role='&lt;entered role>' >&lt;entered fallback>&lt;/object></span></font></div><div><br></div></div><div><blockquote type="cite"><div><blockquote type="cite"><span class="Apple-style-span" style="-webkit-text-stroke-width: -1; ">This UI works for either &lt;img alt='fallback'>, &lt;img>fallback&lt;/img> or &nbsp;</span></blockquote><blockquote type="cite">&lt;object>fallbck&lt;/object><br></blockquote><br><br>Good idea.</div></blockquote><div><br></div>Thanks.</div><div><br></div><div>Take care,</div><div>Rob</div></body></html>