Re: Strange HTML5 errors on a Wordpress website

6.6.2011 8:38, Michael[tm] Smith wrote:

> I recently updated the backend for the HTML5 facet of the validator, to
> bring it into closer conformance with the current HTML5 spec.

I think you misspelled “some HTML5 draft.”

 > So the validator is now doing some checks that it was missing previously.

Using the experimental “HTML5 validation” can be fun, but using it 
routinely for quality assurance is somewhat awkward. Well, it _is_ 
called experimental.

> That is,
> it's checking conformance constraints that were already existing in the
> spec, but which the validator had not yet implemented.

If it plays by the rules set at
http://dev.w3.org/html5/spec/Overview.html#guidance-for-conformance-checkers
(which might change overnight, or later today)
then you could silence the error messages about missing alt attributes 
by adding
<meta name="generator">
but a more sensible approach is to modify the program or process that 
generated the image gallery by making it insert alt="..." containing a 
copy of the image caption (in mixed case, preferably).

Such an alt attribute is not particularly useful, as it duplicates 
existing information. But it’s probably the best you can do, as every 
img will at least have an alt attribute that _identifies_ the image. So 
for example, someone browsing the page with images turned off can find a 
photo of interest and download it. Marginal, indeed, but in a photo 
gallery, alt attributes are marginal anyway. They hardly make the page 
much more useful to a blind person, for example.

>> W3C error message: "An img element must have an alt attribute, except under certain conditions"

“Certain conditions” vary. In the WHATWG version,
http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#guidance-for-conformance-checkers
there is an additional option: You could wrap your image and its caption 
inside a <figure> element with a <figcaption> element. While this is a 
good (maybe brilliant) idea in principle, it just won’t work in 
practice. At present, browsers and assistive software just ignores such 
markup, except perhaps in the sense that they recognize the elements and 
let you style or script them.

 > Those thumbnail images should all have alt
> attributes with values that provide a textual equivalent of the image. For
> example, "View of the steeples of St. Louis Cathedral, from in front, at
> the ground level looking up at steep angle."

Are you serious? Would you like to write such novels for this picture 
gallery, or for some real-life gallery with say thousands of images? 
What specific good would that possibly do?

Such texts are awkward to write, basically useless (especially when 
hidden in alt attributes), and they are _not_ textual equivalents. If 
they were equivalents, you could replace all the images by them without 
losing information. You can’t, and it would not even be a useful 
simplified page.

Such requirements have contributed to giving accessibility a bad 
reputation. By requiring that all images be given textual alternatives, 
you go far beyond all reason that people tend to think you’re best 
ignored. The bad thing about this is that they won’t use alt attributes 
anywhere, even in cases where they are absolutely essential, useful, and 
dead easy to write (like for an image that contains just text in a 
particular style).

> But the thumbnails also need to have alt attributes, in order for any users
> who can't see them to have any idea at all what they are.

What would such users do with the information? In an image gallery, the 
most important thing to users who cannot see images at all is that the 
page _is_ an image gallery only, so that they won’t waste time on it. A 
descriptive, sufficiently informative <title> element, a heading, a 
short note at the start could be used for such purposes. The second 
important thing is to know what the images are about, what they relate 
to, so that e.g. a blind person who has a friend very interested in the 
topic could suggest visiting the page. But it would be awkward to have 
such information scattered in individual alt attributes – especially if 
they just technically describe how a photograph has been taken.

> The HTML5 validator now checks all rel values to make sure they are either
> values that are predefined in the HTML5 spec itself, or defined on the
> Microformats Wiki "existing rel values" page.

Which means that such checks are not of much use – they are partly based 
on what some drafts regard as recommendable, partly on a mutable wiki 
page that reflects proposals that have not yet been rejected. This is 
very far from the practical question “what rel values might be 
recognized by relevant software.”

>If you have a spec that defines what rel=archives,
> rel=wlwmanifest, and rel=google-site-verification mean, you can add those
> values there, with a link to the spec, and then next time we update the
> HTML5 backend of the validator, those values will no longer be reported as
> errors.

That might be interesting entertainment for a while, but the idea of 
individual authors registering rel values is just absurd. It seems that 
HTML5 is going to fail in specifying and standardizing rel attribute 
values, like its predecessors have. It will just outsource the failure 
to a wiki.

P.S. I have restored the messsage’s character encoding to UTF-8. The 
ISO-2022-JP encoding you used is not suitable for worldwide discussion 
lists (it may pointlessly trigger the use of font designed for Japanese, 
as e-mail programs oddly use encoding information in font selection).

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

Received on Monday, 6 June 2011 06:51:35 UTC