W3C home > Mailing lists > Public > public-html@w3.org > May 2008

Re: HTML Action Item 54 - ...draft text for HTML 5 spec to require producers/authors to include @alt on img elements.

From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 13 May 2008 09:50:10 -0700
To: John Foliot <foliot@wats.ca>
Message-Id: <78F855EC-F5B5-406F-A290-AAB8375077A1@apple.com>
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:15 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:55 UTC