Re: [html4all] HTML5 Alternative Text, and Authoring Tools

On May 13, 2008, at 20:52, Matt Morgan-May wrote:

> On 5/13/08 12:47 AM, "Henri Sivonen" <hsivonen@iki.fi> wrote:
>> On May 12, 2008, at 20:46, Matt Morgan-May wrote:
>> My point is to show that there are legitimate uses of HTML that  
>> cannot
>> accessible by everyone. Thus, we should not pretend that all uses of
>> HTML can be accessible by everyone.
>
> And later:
>> If we find that we want to support use cases that aren't accessible
>> for everyone, we have to decouple the accessibility evaluation axis
>> from the syntactic correctness evaluation axis.
>>
>> I think making Web resources accessible is a good thing. However, I
>> don't agree with defining useful but inaccessible Web resources out  
>> of
>> existence in order to make a complex thing appear simpler.
>
> Ah. I think this is one misunderstanding. _No_ content, HTML or  
> other, can
> be perceived, operated, and understood by every person everywhere.

Right. So if we agree that accessibility in some cases fail, let's not  
define those cases out of syntactically correct existence and let's  
not incite those cases to fail harder than necessary.

> Under no circumstances, however, is it acceptable to throw up one's  
> hands
> and say, oh well, they can't make this HTML accessible anyway.  
> _Especially_
> not at the language level.

I thought you just said that there are going to be cases that aren't  
going to be accessible for everyone. To me that suggests that it's  
part of the universe of HTML use cases anyway.

> In the case of @alt, we recognize that many applications of alt text  
> are
> degradations from the original image. But we don't expect an expert  
> analysis
> of Mona Lisa's intriguing smile whenever someone puts up a photo of  
> the Mona
> Lisa. We require enough information to make sense of the semantics  
> provided
> by the image, in the context of its surrounding document. For all  
> content on
> the web, such information is available, and however degraded it may  
> be, it
> still improves the overall accessibility of the document.

Sure, in pretty much every case an alt text *could* be written if  
there were someone willing to write it. But in reality, there are  
cases where alt text *won't* be written, and we should consider how to  
avoid making those cases even worse than leaving alt unwritten.

As a contrived scenario, Validator.nu *could* defer its responses for  
a couple of days and delegate alt writing (or checking at that point)  
to Amazon's Mechanical Turk during that time. Of course, I'm not going  
to do that, because I *value* and expect my users to value an  
expedient and inexpensive response over a more accessible and  
expensive one. (Oh, and BTW, Mechanical Turk seems like a case where  
images are embedded in HTML without the software knowing what they  
are...)

> I strongly
> disagree with the line of reasoning that there are use cases where  
> @alt is
> in some way unnecessary or damaging to the extent that it should be
> optional.

To me, it seems obvious from non-contrived cases that it's possible to  
have alt text that is worse than not having alt text *if* UAs handle  
altless images reasonably gracefully (i.e. don't render the file name  
when it's unwieldy). Examples:
  * Putting a numeric file name, or worse path, into alt. (Ironically,  
the most persuasive reason for putting alt="image" or alt="" or  
something like that in the Validator.nu Image Report is to suppress  
file name rendering in *some* UAs that use the file name as an awful  
alt surrogate!)
  * Putting an empty-string alt on an image whose presence is  
important for comprehending surrounding text.
  * Putting alt="image" on an image when the UA would by itself render  
the word "image" or "graphic" as chrome.

You are saying than none of these are damaging to the *extent* that we  
should seek to avoid these. What I don't understand, however, is why  
wouldn't we try to eliminate these cases if they are *damaging* to  
*some* extent--especially if we find we can do the elimination without  
causing worse damage.

>> The irony I'm seeing is that you seem to willing to exclude a tool
>> intended to improve the state of alt text from the universe of use
>> cases that HTML supports.
>
> I've already offered two solutions to this: one in the form of how  
> it's done
> today, which is at worst redundant but still inoffensive;

Why shouldn't we remove the redundant stuff if we find we can?

> the other in the form of @noalt.

It seems to me that the @noalt proposal doesn't solve any  
accessibility problem: there's still no alt when there's no alt. All  
it seems to do is to create more syntactic error situations.  
Accessibility advocates seem to be really keen to create error  
situations in this area, but I'm not convinced that creating more  
syntactic error situations is helpful, since markup generators can  
paper over those cases without actually addressing the accessibility  
issue. Instead, I do think that offering text alternatives for review  
like the Image Report does is helpful.

>>> If you want to improve the state of accessibility overall in HTML5,
>>> you
>>> should add an attribute to img for the case you're describing. That
>>> way,
>>> evaluation tools would know whether the omission was intentional or
>>> accidental,
>>
>> How would you address the issue of markup generators just throwing
>> that attribute in there to silence validators? I think you are now
>> hung up on evaluation *tools* being able to guess intent.
>
> Since when is parsing semantic code "guessing"?

Markup generators written by people who think the way software  
developers tend to think will produce syntactically correct data  
streams even when the user did not cooperate. In such a case, any  
omission will be flagged as intentional if you that's the only  
syntactically correct way to flag an omission.

>>> and we could easily spot bad actors by pulling up all the images
>>> on a page marked with that attribute and determining whether they
>>> communicate meaningful information.
>>
>> The Image Report already pulls all images up for determining whether
>> they communicate useful information. If there were a class of images
>> that it didn't pull up, wouldn't you expect the problems to
>> concentrate into the class of images it was known not to pull up?
>
> The image report _should_ pull up all images with @noalt in order  
> for a
> human user to determine whether the images marked that way are in fact
> impossible to produce @alt for. It's not a get out of jail free pass.

So if all the images need to appear in the report anyway, what  
usefulness would @noalt add?

>> For example, in the case of Safari+VO on Leopard, the image presence
>> indicator is the UA speaking the word "image".
>
> Why the focus on VoiceOver?

It's an example of real software that fits the assumptions the HTML 5  
draft makes about what non-visual browsers should be like and that I  
happen to have readily available for testing.

>>> No, I'm afraid that people who are tired of HTML 4.01 requiring @alt
>>> will
>>> flock to HTML5 since it gives them the freedom to ignore  
>>> accessibility
>>> wholesale. And that they'll take those bad practices back with them,
>>> and
>>> further pollute the already murky (X)HTML world.
>>
>> So you feel not ignoring accessibility hinges on making alt a
>> syntactic requirement. What about the rest of WCAG 2.0? Are you
>> already giving up on promoting the other issues covered by WCAG 2.0
>> while taking what you feel is the most important bit and masquerading
>> it as something else?
>
> As I said before, this is only the most egregious example of  
> accessibility
> taking a back seat in HTML5.

I strongly disagree with the notion of accessibility taking a back  
seat in HTML5. The approach HTML5 takes is to avoid accessibility  
features that require dual authoring for different content consumption  
modes (e.g. visual and aural). The best accessibility features are  
ones that enable accessibility without requiring authors to take a  
specific accessibility action. (For example, <progress> is designed to  
work for all content consumption modes when authored once whereas the  
ARIA approach requires building the widget from lower-level parts  
twice.)

In the case of images, we are stuck with dual authoring, because  
making images accessible without dual authoring is an unsolved problem.

> And I have no idea where you get the idea I'd
> throw the rest of WCAG 2 under the bus just to get @alt back.

I get it from the notion that alt not being syntactically required in  
HTML 5 would give 'freedom to ignore accessibility'. That implies that  
WGAC gets ignored anyway.

> That doesn't
> mean any accessibility-related feature brought on by WCAG 2 would  
> need to be
> mandatory. But of the features that aren't already required for other
> reasons in HTML, @alt is the only one I can think of that is always
> potentially beneficial when present, and always damaging to  
> accessibility
> when missing.

The thing is, it can be damaging (I'm not speculating to what  
*extent*) to accessibility when present with a bad value.

The presence of alt is a prerequisite for accessibility (for people  
with certain types of disabilities), but it does not follow from that  
observation that *any* alt value is an improvement over not having it.

>> You (and others) are writing as if HTML 5 banned the alt attribute.  
>> It
>> did not ban it.
>
> That's a little hyperbolic, don't you think?

No, I think it characterizes pretty well what many emails to this  
thread and related threads read like.

> We're bringing this up because it's a substantial issue, not simply  
> to annoy you.

I'm not bringing this up to annoy you, either. My problem is that I  
care about the effects that my product induces and I want it to do  
good and not induce bad effects. I take no joy (quite the opposite) in  
arguing about this and if this thread didn't directly affect the  
quality of my product, I'd walk away from this thread in a heartbeat  
and use this time for writing better software instead of writing email.

The reason why I'm not just taking your expert word on this is that  
while I do believe that accessibility advocates are good at  
identifying accessibility problems, I frankly don't really trust the  
ability of accessibility advocates to formulate *syntactic*  
requirements in such a way that the requirements don't induce unwanted  
effects when exposed in a machine checker to potentially uninformed  
users or to users who don't share the goals of the accessibility  
advocates.

>>> Frankly, your validator and its feature aren't the issue, at least
>>> as far as
>>> this thread is concerned. They will do little if anything to improve
>>> the
>>> state of @alt relative to the alt text lost by being optional.
>>
>> That seems confusing.
>>
>> It seems to me that your advocacy point is that you want to make the
>> presence of the alt attribute a machine-checkable syntax requirement.
>> Isn't what you want validators to do precisely the issue then?
>>
>> If you aren't arguing that my validator should flag the absence of  
>> the
>> alt attribute as a syntax error, what *are* you arguing?
>
> My argument is about why @alt must be required. My problem right now  
> is with
> the letter of the law, not how you propose to police it.

If you are arguing that you want to make a piece of syntax machine- 
checkably required, it seems to me that the effect such a requirement  
will have when people use software that checks for the requirement is  
at the very center of evaluating whether the requirement is a good idea.

Setting a policy without considering what its effect on the stated  
goal is is very bad policy setting.

>>> An advisory
>>> message in a validator, however helpful, is not a forcing function
>>> in the
>>> same way a validity constraint is.
>>
>> A mere presence check doesn't force the value of the attribute to be
>> on the better side.
>
> At the atomic level, no. But you cannot argue that requiring @alt  
> per spec
> in HTML has not resulted in more useful alt text on the web than  
> there would
> have been had it been optional. Which is directly in line with my  
> stated
> goal at the top of making more content more accessible to more people.

I think we don't have data about that.

The Image Report is carefully designed to remove bad effects of  
putting an alt presence check in the validation function while at the  
same time making the feature more useful than a mere presence check to  
people whose actual goal is to make images accessible.

The interesting question is what effect the Image Report has on people  
aren't trying to make their pages accessible but who upon a presence  
check failing would happen to write better-than-nothing alt text by  
dumb luck. How will those people behave when they find a tool where  
they can enable something called the "Image Report" and the feature  
actually gives some succinct advice related to *accessibility*?

>>> Anybody who's evaluated a site that's "Bobby-approved" knows that.
>>
>> If there's anything to learn from Bobby, I think it is that a piece  
>> of
>> software can't tell if a page is accessible. Furthermore, I think it
>> is hurting your cause to suggest to people that software could tell  
>> if
>> a page is accessible.
>
> That's precisely my point. And I didn't suggest that, at all. Quite  
> the
> opposite, in fact. The problem is that your approach is  
> fundamentally no
> different from Bobby's, and given the relatively low success rate of  
> casual
> Bobby users to make arbitrary HTML content more accessible, the idea  
> of
> taking the constraint out of the spec and relying on your image  
> report for
> conformance does not comfort me in the least.

Low success rate relative to what? Is there data about the success  
rate of Bobby users? Do you have data about the success rate of the  
W3C Validator's HTML 4.01 alt presence check, which gives *no* advice  
about what alt is *for* and what you might want to put in its value  
and which says nothing at all about alt if it is present but has a  
badly composed value?



P.S. To get a practical idea of what is being advocated as a good-to- 
preserve status quo and where I'm trying to move the bar, here's a  
quick comparison.

When alt is missing the W3C Validator (the status quo the preservation  
of which is advocated) says this:

"The attribute given above is required for an element that you've  
used, but you have omitted it. For instance, in most HTML and XHTML  
document types the "type" attribute is required on the "script"  
element and the "alt" attribute is required for the "img" element.

Typical values for type are type="text/css" for <style> and type="text/ 
javascript" for <script>."

The Validator.nu Image Report, on the other hand, says this:

"The following images are not links and have no textual alternative  
available (no alt attribute), and are, therefore, not accessible to  
people who cannot see the images or understand the symbols in them.

An image belongs here if the image is significant (non-decorative) and  
the markup generator doesn’t have knowledge on what the image is about  
available. For example, a photo gallery generator does not have  
textual alternatives available when the user refuses to provide them.

Purely decorative images should have the empty string as the textual  
alternative (alt=""), so it is a mistake for those to appear here.  
Also, when the markup writer knows what the images are about, (s)he  
should write textual alternatives."

(The text can be improved--it's pulled from a wiki.)

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Wednesday, 14 May 2008 14:23:47 UTC