Re: img@relaxed CP [was: CfC: Close ISSUE-206: meta-generator by Amicable Resolution]

On Wed, Aug 1, 2012 at 8:41 AM, Janina Sajka <> wrote:
> When there's only one use case and only one error being evaded, it's
> dishonest to claim a generalized approach to multiple "errors."


> Let me add that I do not assert "hapless victims." Nor would I expect
> Ted to say that of himself in this CP. But, what other conclusion is
> there to draw when the rationale is arguing that these smart developer
> people need this remedy because they just can't do anything about those
> pesky alt errors? Worst of all, the argument even goes to claim the
> machine is at fault--the system, whatever you want to call it.


> My point, of course, is the opposite. I agree these are smart people who
> understand how to get things done. I don't accept the assertion of
> victimhood, hapless or otherwise. So, pardon me for being an
> inconvenient fact in their existence--but that's what the W3C a11y
> standards are about, the end users and consumers of web content, not the
> convenience of these smart developers.

Dynamically included third-party content (e.g. from a feed or from
editorial staff) often has lots of errors including missing alt.
Sometimes developers will simply want to sandbox this content, in
which case being able to omit it from linting entirely would be
helpful. For HTML5, @srcdoc addresses that use case. Other times
they'll want to correct it somewhat using a sanitizer and a linter can
help check the sanitizer is working.

Incorrectly opened, closed, or nested tags can easily wreck a whole
page for all users and are pretty easy to fix. By contrast, developers
are unlikely to spend lots of time on auto-generation of complex @alt,
because it's hard to do well and the benefits even to the @alt user
are extremely marginal. Complaining about missing @alt in ingested
content in a linter is likely to produce outcomes like:

1. Developer treats the complaints as noise (potentially missing
complaints about @alt in content they themselves have authored).

2. Developer abandons linting, either as part of automated checking or

3. Developer adds alt="" or alt="image" (or some similar simple text)
added to every image in third-party content.

4. Developer lints some version of the product customised to exclude
third-party content.

6. Developer forks the linter to add desired exclusion facilities themselves.

I've seen all of these approaches to noisy linter behavior in
practice. I think (1) and (2) are most common. Maybe in the future
they'll just be more inclined to use @srcdoc. None of these outcomes
helps end-users particularly.

(FWIW, I've been on the developer side trying to get better text
alternatives in the ingested content. I didn't succeed. Validity
wasn't a motivator for me or anyone else involved.)

John mentions elsewhere in this thread that missing @alt makes for a
poor user experience when @src is the only source of repair text for a
link. I'd suggest the critical failure there is that the link has no
human-friendly accessible name source not that the image has no text
alternative. I think efforts to help end-users through the linter
would be better directed at ensuring that all controls on the page
have programmatically determinable short names. The linter does a
woeful job at this, the spec doesn't seem to properly require it (it's
actually gotten gradually worse in this respect and nobody seems to
notice or care), and the same was true with HTML4 and the old
validator. And this is something that developers tend to be authoring
and can easily fix in a way that makes a big difference to usability,
whether it's adding an @alt, or a <label>, or link/button text to a
clickable image added with CSS.

IMO it's a travesty of accessibility promotion and a mockery of this
entire debate if we end up (again!) with a linter that complains about
the trivially recoverable suboptimal markup of <img
src="fluffy-marketing-image"> but not:

    <a href="whatever-page"></a>

    <a href="whatever-page"><img alt="" src="whatever-image"></a>

    <button id="whatever"></button>

    <input type="text" name="whatever">

I despair sometimes. :(

Benjamin Hawkes-Lewis

Received on Thursday, 2 August 2012 01:55:01 UTC