Re: ALT issue redux

Al Gilman wrote:
> We need effective
> action across the board.  

As a suggestion, one way to do this may be to not mix issues even if
they may be related (where possible). Re:
Conformance/error-checking/accessibility.

> There are several other cases where the instructions in the HTML5 draft
> are that the @alt should be empty.  These are similar to putting a null
> @alt on an image in an image link when the link @title is desired to be
> spoken.

In the wild @title content is rarely outputted by screen readers.

> I think that these cases need to be identified by machine-applicable
> selectors before the "no @alt" instruction can be acceptable. 

<Thinking out loud> Is there a need to successfully deal with @ALT
content for human users and then @ALT that is machine readable. Is this
correct? If so, can the same attribute satisfy both these requirements?
Or is there a need for @ALT x 2 or @ALT plus machine selector? How would
this be generated, via some option in the authoring tool? Would the
machine readable selector satisfy the requirements for situations where
there is no@ALT ?

> In other cases, where an image amplifies some text also in the page,
> the relationship of the image to the text must be machine recognizable.
> People with reading difficulties need the association to be machine-
> recognizable because they may be critically dependent on the image to
> grok the words.

When you say "amplify" do you mean that the image is complementary or is
used as an to aid comprehension? If so, then yes. If not then I would
argue that in many cases the relationship really does not need to be
explicit for human consumption. The way images are used is often quite
arbitrary, even if they are used to aid comprehension and while an image
can speak a thousand words and so on, a few well chosen words often will
suffice.

FWIW I would also suggest that the semantic relationship between an
image that "amplifies" text is different from what @ALT does. Maybe
there is a need for an attribute that more explicitly states that
semantic difference? Rather like @ADD (for additional, or addendum) or
@SUPP ( for supplementary),  etc.

> Given the low level of strict conformance to W3C format specifications
> in the Web as she is spoke today, it is not clear how much of a prize
> it is to insist that a missing @alt in this case is a format error
> vs. just being an accessibility error (which it will be anyway).

There seems to be two issues here.

> We should regard the HTML WG desire to standardize recovery from defects
> as a positive step.  Something that we should applaud and work with.
> 
> Clearly, the absense of an @alt in the narrow case described above
> should not be cause for the browser to reject the whole document, as
> is the uncomfortable rule with many XML errors.

Absolutely.

Cheers

Josh

Received on Friday, 1 February 2008 10:44:54 UTC