- From: Maciej Stachowiak <mjs@apple.com>
- Date: Tue, 13 May 2008 09:50:10 -0700
- To: John Foliot <foliot@wats.ca>
- Cc: 'Dave Singer' <singer@apple.com>, public-html@w3.org, 'W3C WAI-XTECH' <wai-xtech@w3.org>, wai-liaison@w3.org, 'Dan Connolly' <connolly@w3.org>, 'Chris Wilson' <Chris.Wilson@microsoft.com>, "'Michael(tm) Smith'" <mike@w3.org>, 'Boris Zbarsky' <bzbarsky@MIT.EDU>
On May 12, 2008, at 3:45 PM, John Foliot wrote: > Maciej Stachowiak wrote: >> >> This particular point wasn't about making alt optional. It was about >> whether particular markup situations are better handled with empty >> alt >> or non-empty alt. Please re-read the thread. > > David Singer's point about the round and round notwithstanding... > > I have read all of the points in all of the threads... It is not > like I've > just dropped in to this discussion. In the use-case where there is no > author supplied alternative text, then any number of other alternative > pieces of metadata might suffice. Which piece is better than > another might > be open for discussion, but providing *nothing* is not, nor should > not, be > considered one of the options. Yet your whole email below is about optional alt, where I was discussing a specific case where I thought present but empty alt might be better. In fact, I said that in the very email you are replying to, and I also said I was not arguing for optional alt specifically. You seem to have completely missed this point. > >> I think before being dismissive of other's efforts you could read the >> thread and try to understand the actual point at issue here. > > The point of the issue is that @alt is for more than just screen > readers. > *You* are concerned that providing redundant text is detrimental to > the > user-experience, and *you* appear to continue to support the idea > that @alt > being optional some of the times is a valid assertion. I disagree, > although > appreciate your question regarding redundancy. Now you are misstating my position. What I said in my previous email: "a number of solutions have been proposed, including allowing alt to be omitted in such cases, having a magical alt value (such as a space or asterisk), or requiring a different attribute such as noalt or importantimage, possibly in conjunction with an alt value. I did not argue for or against any of these, simply noted that the use case was not addressed." Please realize that different people may have different positions or in fact multiple separate points to make. >> I think it is the job of the spec to not explicitly require redundant >> text, yes. > > Correct me if I am wrong, but the emergent HTML5 spec is about how > to mark > up content so that it can be rendered in a "user agent" normally > thought of > as a browser. Where does it "explicitly" require redundant text? > You are > suspecting that this may be a possible outcome, but I don't see > anywhere > where it says "...and the user agent must explicitly provide redundant > text". It requires non-empty alt text to be provided even in cases where the image is completely described in detail by the surrounding text. >> I am personally unwilling to take the word of a self-proclaimed >> expert >> on any topic without explanation. > > First, I do not claim to be said expert (although I will unabashedly > state > that I probably have more experience in this area than you do). > However > since the W3C has decided that the PFWG and WAI should be the go-to > 'experts' in the area of web accessibility, and that WCAG 1 (and 2) > emerged > via consensus, what better pedigree do you require? I don't care about pedigree, that's what I'm telling you. Citing authority instead of making reasoned arguments does not move the discussion forward. > They have reported back > to the HTML WG that maintaining @alt as a mandatory requirement should > remain, and yet that group (your group?) continue to question us/ > them and > argue for your point. I find the premise that official experts are not to be questioned antithetical to open development of Web standards. > >> Examples of valid public >> reasoning would include (but are not limited to) citing a user study, >> explaining what alternatives were considered and why they were >> rejected or presenting pros and cons of different approaches. I do >> not >> see citation of expert opinion as valid public reasoning. > > Others have pointed to the relevant records at WAI regarding images > and > WCAG2, which is what the current revised draft text references. I read the "Understanding WCAG 2" document. Here is what it has to say about text equivalents: <http://www.w3.org/TR/UNDERSTANDING-WCAG20/text-equiv.html> "The purpose of this guideline is to ensure that all non-text content is also available in text. "Text" refers to electronic text, not an image of text. Electronic text has the unique advantage that it is presentation neutral. That is, it can be rendered visually, auditorily, tactilely, or by any combination. As a result, information rendered in electronic text can be presented in whatever form best meets the needs of the user. It can also be easily enlarged, spoken aloud so that it is easier for people with reading disabilities to understand, or rendered in whatever tactile form best meets the needs of a user." This is a great explanation of the benefits of text equivalents in general. But it does not address the details at all. > Can we see > the same kind of "evidence" that supports the contrary claims? > We've been > asking for that for a very long time now, and still we've yet to see > it. > Your considered concerns aside, where does it state (via, but not > limited > to, a user study) that there is a problem? Where does it show other > alternatives considered besides making @alt optional, complete with > pros and > cons, etc. Many people made alternate proposals and discussed the pros and cons. I personally suggested "noalt" instead of missing alt, and I felt that Ian gave my proposal due consideration. In fact he has now made a similar proposal himself in the course of the recent discussion, which as far as I can tell no one has responded to or even acknowledged. > As has also been pointed out, there is *always* some useful > information > attached to an image. The question is not whether or not @alt > should be > mandatory, but rather what is an acceptable default value when the > content > author does not provide something. I pointed to Robert Burns' > thoughts on > that topic, specific to a photo sharing site. You seem to be assuming a specific solution (default value for the alt attribute). However, so far as I can tell, the Action Item 54 proposal and WCAG both disallow the authoring tool entering a default value. Robert Burns also seems to disagree with AI54, since he says empty alt for a photo (one that is not purely decorative but part of the content) is OK, but AI54 requires non-empty alt in this case. > >> >> b) I asked for an explanation for why images that carry the same >> information as surrounding text (adding only a visual aid) should >> carry alt text or description links repeating the same information >> yet >> again. It seems that this would lead to repetitive text in screen >> readers, which could be annoying. > > It can be, and often is. So is having a news (portal) page with 7 > different > links that all have the link text of "More...". Shall we write the > spec to > forbid the using the same link text more than once on the same > document, so > as not to annoy users? The spec can't forbid bad authoring, but it also should not require it. Requiring descriptive alt text for an image already fully described by surrounding text is effectively a requirement to be repetitive as far as I can tell. >> No one has clearly explained why >> this is not a problem ("screen reader users have learned to tune >> things out" is a partial explanation, but no one made that argument >> when it comes to possibly reading meaningless filenames), > > It is a problem. The proposed solution of making @alt optional as a > means > of fixing this problem is not an acceptable solution. This issue is abosolutely not about making alt optional. In this specific case, the alternatives are empty alt, or alt that restates the normal flow text around the image. > Reading meaningless > file names is a problem too, which is what would generally happen with > today's screen reading technology if @alt is omitted. In the > absence of any > real solution, most would agree better the devil we know than the > devil we > don't. > >> or whether >> alternatives have been considered that serve the required use cases >> without creating this problem. > > Some have, yes. See Robert Burns' thoughts. In an email* now some > 2 weeks > old, I suggested that if *any* method of /directly linking/ text to > an image > was present then perhaps relaxing a mandatory @alt could be > envisioned. It seems to me that AI54 does not include your proposal. Do you know why it was rejected? > I also suggested in the same email however that if there was no text > alternative available in any fashion, that the image be non- > conformant and > simply not render on screen. Harsh yes, but that is essentially > what would > be given to some users through ignorance, ineptitude or by deliberate > exclusion. I believe I said "give them more rope..." This seems to take the position that it is better for content not to be on the Web at all, than to be on the Web but not marked up for accessibility. This seems like an unreasonable extreme to me. > [* http://lists.w3.org/Archives/Public/wai-xtech/2008Apr/0393.html] > >> Note that besides screen reader users, >> users of text-only browsers will also see repeated text. I have >> lifelong experience as a reader of printed text, and in this >> context I >> can say with some certainty that excess repetition harms the user >> experience. > > This is an authoring issue, just as having 7 links to "More..." is an > authoring issue. It is not nor should it be the goal of a markup > specification to make value judgments of any subjective nature. The AI54 proposal requires repetitive text and includes it in an example. If it is only the example that is in error then it would be fine to fix it. I think examples should strive to show good authoring practices, even as to subjective matters. Regards, Maciej
Received on Tuesday, 13 May 2008 17:56:14 UTC