A validator is not an accessibility evaluation tool?

Currently, the most active discussion thread on the HTML working group’s public mailing list, public-html, is one regarding the issue of whether in HTML5 the alt attribute should always be required on images. And Henri Sivonen is among the most active participants in that discussion, posting to that thread (among other messages), the following:



The question of whether or not alt should always be required is an issue that affects the behavior of validators, so it shouldn’t be much of a surprise to see Henri taking interest in the discussion around it, because he maintains a validator (more precisely, a conformance-checking tool) called Validator.nu that he’s spent a lot of time developing and that he clearly wants to be a beneficial and serviceable as possible to the people who take time to use it.

Among the assertions that Henri makes in his postings to that thread is the following:

An HTML5 validator isn’t an accessibility evaluation tool–or at least I think it shouldn’t be.

He goes on to compare the purpose of a validator to that of a spell checker, and in a later message, adds this:

A validator cannot check that a page is semantically correct. It can’t properly check for accessibility, either.

We should dispel misconceptions about what validators do instead of catering to the misconceptions.

And to clarify what he intends Validator.nu to be useful (and not useful) for, he adds this:

The validator I develop is not a stamping tool. It is a tool that helps authors detect mistakes that they didn’t intend to make, so that they don’t need to spend time wondering about the effects about their unintentional doings. For example, the validator I develop helps author detect that the alt attribute was typoed as ‘atl’, which is useful, because atl wouldn’t work… I’m not interested in developing a formal stamp. I am interested in developing a development tool.

The assertion that earning a “this page is valid” stamp or badge should not be an end goal (or any kind of goal at all) for users of a validator or conformance checker is something that Henri has stated consistently since the earliest public versions of Validator.nu were available (and that others have been stating for quite a long time also) — as is the assertion that a validator should be a development tool, not a tool for advocacy. Henri states that most succinctly is a section of the Validator.nu FAQ:

Validation is a tool for you as a page author — not something your readers need to verify.

To make a somewhat ham-handed analogy of my own: Consider the case of when you create a document with a word processor like Microsoft Word or whatever and you run in through that application’s built-in spell-checking and grammar-checking tools to find and fix any spelling or grammar problems. You’re using those tools as an author to ensure that the document doesn’t contain any unintentional errors before you share it with others. And after you use them, you would never consider embedding a badge in the page to indicate that it’s free from spelling and grammar errors — because the fact that it is free from such is something of real value to you as an author, it’s of no value to have it highlighted to all your readers, and not something you want or need your readers to verify.

Anyway, that (bad) analogy aside, I think Henri and most other reasonable people would agree that there is great value in encouraging authors to produce valid content, and beyond that, to encourage authors to be familiar with best-practice accessibility and usability guidelines and to try to follow them to the best of their ability. The main difference of opinion here is around what role (if any) validators should be expected to have in encouraging authors to do those things.

6 thoughts on “A validator is not an accessibility evaluation tool?

  1. unless i’m misunderstanding, though, this sidesteps the core of the discussion: the validator is supposed to validate against HTML5…now the question is should HTML5 mandate ALT. if it turns out that HTML5 doesn’t mandate ALT, then Henri is absolutely right that his validator shouldn’t flag it either. if HTML5 does, though, then the validator needs to flag up a missing ALT. or have i got the wrong end of the (unwiedly, lengthy, partly philosophical, often heated) stick?

  2. I agree completely with Henri on the purpose and use of a validator. I think Michael’s analogy is right on the money. Patrick notes a particular conflict that even if HTML5 mandates alt, will still not be resolved. The conflict, as I have experienced it, is the change in the way alt is to be used in HTML5 and the interaction with WCAG checkers. HTML5 clarifies that title is to carry the tool-tip information and that alt should be a stand-alone sentence that makes sense in context in the absence of the image. This generates alt tags that are deemed too long by WCAG. This leaves me with the choice of conforming to the HTML5 guidelines or the WCAG 2.0 guidelines, but not both. Currently I choose to conform to WCAG 2.0 short alt tags when working on a 4.01 strict page. On HTML5 pages I randomly vary between sentence-long alt tags that contextually replace the image and short tool-tip-like image descriptors.

  3. Although I faithfully put in ALT attributes for my images, they are frequently empty (e.g. alt=””) as putting anything in the alt attribute would be redundant to the text adjacent to the image (e.g. a linked icon next to link text). There are very legitimate reasons to want there to be no traces or clues about an image’s presence provided to users of things like screen readers and dynamic Braille displays. Another annoying thing about ALT attributes is that if one wants an image description to be displayed to graphical browsers as a “tooltip” caption then one has to use both the ALT attribute and TITLE attribute for images, which is also redundant.

    After reading Henri Sivonen’s comments and giving some thought to it, I do agree that the ALT attribute should be optional in HTML5. He makes some very good points about the ALT attribute being required only causes developers to create bogus ALT descriptions. He also makes some compelling arguments that HTML5 specifications should stick to technical issues and leave the social engineering to the WCAG.

    Henri is right, the ALT attribute requirement is a failure and this attribute should be made optional.

  4. Well, Ken, you have (inadvertently, I presume) given one of the few cogent arguments against Henri’s position.

    alt=”” is supposed to indicate “this image is purely decorative; assistive technology should ignore it.” The absence of an alt attribute is supposed to indicate that the image is significant, but no usable alt text is available.

    It would be rare for a conforming hand-authored HTML5 document to have <img> elements without an alt attribute. Either the image is significant (in which case, the hand-author supplies suitable alt text) or it isn’t (in which case, the author adds an alt=””).

    You (and, one suspects, millions of less clueful authors) seem to take the proposed HTML5 Spec as a licence to omit the alt attribute for purely decorative images, which is exactly the opposite of what is intended.

    And here I thought that those arguing against Henri in the linked-to thread were complete idiots…

  5. A null value for img@alt is probably worse than a null value for html/head/title, because there is less text to supply context. The alt text is not for a specific group of people, it is for devices, which can then process the text in various ways, including rendering to various media or storing in indexes for search engines.

    It isn’t necessary for authors (or people who write validators) to always understand the “why” behind markup requirements, or indeed agree with them. The point is that the web is a vast, collective, interconnected system, and connecting poorly-described information to it will (however infinitesimally) reduce the quality of the overall system.

    Looking at content from the point of view of a single page is one view of the system; other views can look at collections of elements such as images. And increasingly an author doesn’t produce the entire page, but only a portion of the content.

    In other words, the author might have no clue about how the content they produce will be used, now or in the future, or what context it might appear in. However, they (or the developers of the generating application) might have a very good of the intended purpose of the image.

    It might therefore be more useful to have an attribute containing the purpose(s) or function(s) of the image (there is already a boolean for image map) or other element. This/these could be taken from a controlled vocabulary.

  6. Firstly, on Henri’s article.
    While the validator is an invaluable developer tool, I personally find the analogy deeply flawed. Correct spelling and grammar are and have for a long time widely accepted as being a good thing. This is thought from a very young age to everyone. Valid html, while considered positive by many, is less widely used, and certainly not something everyone is aware of or familiar with. Valid badges are an advertisement. If the validator is not created to this purpose, what should we use to “Spread Validity”?

    Secondly, on



    <div style="background-image:url('');"/>

    not a better way of inserting decorative images without having to worry about


    (even better again with external style)? Please correct me if I’m oh so wrong on this one, but I never use


    for decoration. Should I?

Comments are closed.