- From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Date: Thu, 2 Aug 2012 02:54:12 +0100
- To: "Michael[tm] Smith" <mike@w3.org>, public-html@w3.org
On Wed, Aug 1, 2012 at 8:41 AM, Janina Sajka <janina@rednote.net> 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." [snip] > 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. [snip] > 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 altogether. 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