I have been a big advocate for web standards since I first read Jeffrey Zeldman’s Designing with Web Standards, well, let’s just say a while ago.
On most of the sites I’ve worked on, I’ve gone over every line of code to zap out every potential error message that would eliminate the nice little green check box that appears with the HTML Validator extension to Firefox when the page conforms to XHTML 1.0 Strict. I’ve taken this to the extreme of taking outside vendor code, importing it into some server side programming so I can eliminate the vendor’s coding errors through RegEx, then spitting that code back out all valid and shiny onto the web page.
Maybe that’s extreme, and maybe in the past I focused too much on that little green checkbox of validation. Validation alone doesn’t mean that your code is semantic or accessible or that your site is usable. It’s a step along the way, a little howdy-doo that says, you’re on the right path bub, no matter how far along that path you are.
To be fair, now that I develop almost exclusively in Drupal, I’ve been seeing that little green check box not as often as I would like. It’s not that you can’t make that yellow triangle go away in Drupal, it’s that sometimes, when time is pressed, I have not taken the time to massage the code in order to do so. I had been thinking I would like to spend more time on that.
Now, I wonder.
For a long time, I’ve spent less time losing sleep about invalid notations for CSS. Sometimes warnings and errors have popped up when I’ve used a CSS hack that was a necessary evil for a stupid older browser. (Ironically, those were rarely for IE, where I could use conditional comments, and instead for stupid Webkit and Mozilla bugs: yes, they do exist.)
Did the subsequent invalidity of the CSS mean the world was going to end? No.
Now I wonder, at some point should I feel the same way about HTML5?
My first inkling that something about HTML5 was odd was when it was decided that all the rules of syntax for XHTML no longer really mattered. Didn’t close a tag? No big whoop. Sure, if you wanted to, you could write syntactically valid HTML5, but would the validator care? Nope. Yes, you could make your page XHTML5, but then if you had one tiny error, kablooey, your page would be dead. This is a bad thing.
But after that, I’d hear about decision after decision on HTML5, and if there was one consistent theme, it seemed to be that accessibility concerns were tossed out the window.
I don’t follow all these decisions religiously. I don’t participate in all of the listservs. I wish I had time or the energy. I don’t. I’m a web designer/developer who cares about standards. I find out about what’s going on through blogs and Twitter, books and workshop sessions.
I heard about the elimination of the summary attribute from the table element, the death of the longdesc attribute. From what I know of accessibility, these have seemed like bad developments.
So now I hear that there will now be acceptable reasons to omit alt text from image elements. This is important. If there’s no alt text, my understanding is that most screen readers and such will read out the filename for an image. That’s really bad. Not to mention the fact that if the image contained important content value, it’s now become much more difficult for some to get that content value.
It’s not the most pleasant thing to read through. (By the way, is it considered “serious” to present important decisions in a monospace font? It’s quite hard to read.) Options are presented that, in my opinion, make HTML less accessible. Criticisms of those options are judged as weak, somewhat weak, strong, somewhat strong in a pseudo-scientific manner, as if one could simply tally up the arguments made on each side and judge whether or not they are good arguments based on how specific they are.
In the end, there were two outcomes that really surprised me.
One, if an HTML page has a meta name=generator tag in the head section, then alt text is no longer required for images on that page. At all. The theory, apparently, is that these pages come from content generation tools. I suppose this could be a CMS or an application like Dreamweaver. In any case, let’s say that this tool allows users to add images to a page. If it asks them what the alt text should be for each image, and nothing is entered, what should they do? Put an empty alt attribute on the image? Try to automatically generate alt text? Leave off the alt attribute? If the latter is done, now that will be perfectly valid. The reasoning used in the decision is that it could make the content generation tool look bad if it created invalid code based on the decision of a user to not put in alt text, even when prompted.
An error code could note that, hey, there’s no alt text here, it could be inaccessible. That’s a sign post, a warning. Sure, it’s the user’s fault, not the content generation tool’s, but so what? The fact that it might make the manufacturer look bad is now more important than whether or not the content is possibly inaccessible?
The second decision is that if an image element has a title attribute, but no alt attribute, that’s perfectly fine. Now the title attribute isn’t actually accessible, as Roger Johansson ably points out, but apparently, no worries.
The reason given? Well, it’s possibly a blind photographer might take 100 pictures, might not have easy access to know what each picture was, and thus wouldn’t be able to provide accurate alt text: thus, a generic caption in a title attribute should be ok.
Sure, those image elements are now inaccessible to people who are blind who are accessing the page, but so what? Apparently.
Now I’m not saying that a blind photographer shouldn’t be able to put up a photo gallery. Go right ahead! But quite frankly, if it ends up that page is invalid, so be it. Again, it’s a sign post, a warning that something isn’t quite right here, because it’s going to cause problems for people.
To take that one situation and to say that it’s more important than every other possible situation where having alt text is going to be far more accessible than a title attribute, well, it strikes me as an insane.
So what does that mean? I’ve believed in standards, because they seemed to be a codification of really good ideas of how code should be written. But while HTML5 is really promising in many ways, I’ve seen far too many individual decisions that strike me as jaw-dropping for me to really think that valid HTML5 is great HTML.
Options that I had before to make content accessible in XHTML are now gone in HTML5. I can do some very inaccessible things in HTML5 that won’t trigger validity warnings, because the standards writers just didn’t think those issues mattered very much.
Now to be fair, that was true with XHTML as well. Valid XHTML didn’t mean you had addressed all accessibility issues or that you had created a great web page. However, I have less faith in the inherent value of validity in HTML5 than I do in XHTML.
I imagine when I start doing more work in HTML5, I will probably do my best to conform to the HTML5 standard. I’m hoping I’ll be able to do that within Drupal.
It just makes me sad, really, to feel this way about the HTML5 “standard.” I want to smile at that green checkmark, not feel queasy about all the bad decisions made along the way.

31 Comments
It's a shame the HTML working
Submitted by Russell Heimlich (not verified) on
It's a shame the HTML working group would come to such a decision. An empty alt attribute would have been better than nothing at all because then the screen readers would just skip over that element completely and save the reader the trouble of listening to a garbled file name.
P.S. Check out these pages and view the source to see where standards may eventually end up http://passml.org/ and http://nwc.co/
So foreign
Submitted by Marc Drummond on
I've started getting into HTML5, but clearly I haven't read enough, because that source code looks so foreign to me.
Yes, I think an empty alt attribute would probably be better than nothing at all. It's not ideal, but better than than listening to an entire file path.
Those sites are going beyond
Submitted by Russell Heimlich (not verified) on
Those sites are going beyond HTML5 and using their own made up elements; < twitter >, < rss > etc. I'm a fan of this approach http://www.russellheimlich.com/blog/death-to-the-div/
Interesting approach
Submitted by Marc Drummond on
Oh, good. I wasn't just super-confused. (Well, about this at least.)
I think the comments on your post pretty much cover the gamut of the potential issues this approach would have, but it's an intriguing thought for extensibility and semantics.
Flickr
Submitted by Robert O'Callahan (not verified) on
The generator case is not about a Web author using a CMS, it's more about sites like Flickr. If you think alt should be mandatory, what do you think Flickr should do for user-uploaded photos?
1) Require uploaders to submit alt text: most won't, and will either submit the empty string, or (if Flickr forbids the empty string) switch to another photo site.
2) Add the empty string automatically if no alt-text given: pollutes the Web with false information for the sake of conforming to spec
3) Serve invalid HTML: surely it's unacceptable to have a spec under which some kinds of sites are simply unable to serve valid HTML.
As for your point about removing features: having accessibility features in the spec that history shows authors have not and will not use correctly (e.g., longdesc) does nothing for accessibility. In fact such features harm accessibility by diverting resources from features that can work.
Generators
Submitted by Marc Drummond on
I listed CMSs and Dreamweaver as examples of content generating tools, at least that was my intention. Flickr is obviously another example.
I disagree about longdesc. There were use cases for it, and it was a tool that was available. Just because not many people took advantage of that tool doesn’t mean it’s not good to have a tool there. And color me skeptical that the removal of longdesc will result in people making HTML or HTML authoring tools more accessible because they don't need to worry about longdesc anymore.
Thanks for the comment.
I don't see how adding empty
Submitted by Robert O'Callahan (not verified) on
I don't see how adding empty alt tags to to silence validator warnings improves accessibility in practice. ATs that read file names when there's an empty alt attribute are just broken.
Regarding longdesc, a study showed that more than 90% of images with longdesc values used the longdesc value incorrectly (e.g. by including descriptive text instead of a link to the longdesc resource). So most authors using longdesc simply wasted their time, and tools attempting to use longdesc would need heuristics to identify the small minority of cases where it was being used correctly.
Yes, we really do have better things to do with our time than spec, implement and evangelize features that have been successfully used by a vanishingly small percentage of Web authors. For example the new HTML form controls have far greater potential for actually improving accessibility.
Theory vs practice
Submitted by Marc Drummond on
On one hand we are told that whether or not something makes sense in theory, what’s really important is how something is used in practice. On the other hand, when the actual practice is that in the presence of no alt attributes, ATs read out the file name of an image, we are told that doesn’t really matter.
Something seems amiss there.
A feature that "works in
Submitted by Robert O'Callahan (not verified) on
A feature that "works in theory" but requires millions of Web authors (or hundreds of millions of Web users) to do the "right thing", where experience has shown they will not, is impractical.
On the other hand, fixing bugs in one or a handful of ATs is very practical. We regularly work with AT vendors to fix problems in their software.
Backwards
Submitted by Marc Drummond on
Sure, but what about backwards compatibility? It’s great if ATs no longer read out file names in the future. However, my understanding is that there are many with screenreaders that do not necessarily have the most current versions due to cost. Maybe that has changed, but if it is not, that is a factor.
The harm to requiring alt attributes for content generators is that they might be embarrassed because their code does not validate when users do not provide alt text. The harm to not requiring alt attributes is that some people using screenreaders may have a much worse experience using the web.
I have a real problem with the fact that more weight is seemingly being given to the content generators than to users with disabilities.
NVDA is a free AT for Windows
Submitted by Robert O'Callahan (not verified) on
NVDA is a free AT for Windows that works well with Firefox. It's open-source and the developers are very responsive.
http://www.nvda-project.org/
VoiceOver and Orca are also free on their respective platforms.
What about backwards compatibility with existing Web pages? Why, when faced with trivial bugs in one or more unspecified ATs, do people think that the best solution is to change the behavior of millions of Web authors and update billions of existing Web pages?
Null set
Submitted by Marc Drummond on
There is no standard for HTML that can be written that everyone will follow where everyone will validate. We don’t set speed limits based on the speed within which everyone will drive. So we might as well have a standard that makes sense and does good things, within the limits of practicality.
Requiring alt attributes for images is perhaps the most basic rule for accessibility. Ask anybody who has even a passing interest in accessibility to name one rule for accessibility, and I will bet you that is the one that will be named. Does that mean that rule is followed religiously? Or correctly 100% of the time? No, but that does not negate its importance.
Providing alternate text for an image is a good thing for people with disabilities. Not even just because of the file name thing, but because images are important content that people with visual impairments are likely to want and in some cases need.
That is what this comes down to. That need for alternate content for people with disabilities versus the supposed justification that content generators might feel bad when their page comes up as invalid. Or the anecdote that a blind photographer might not be able to have a valid page in certain situations.
The bottom line is that those are really dumb reasons to undermine the rule that most web workers that know their salt are familiar with, that images require alternate text for purposes of accessibility.
I look after a very large
Submitted by John Anderson (not verified) on
I look after a very large site, accessibility is important (manadated) for it so my initial reaction to the effective "death of the alt tag" decision was unkind - it makes my job harder.
I am even less impressed with Robert's argument. The obvious answer is to have "No alt text" as the alt text. It makes sense to screen readers. The idea that this would pollute the Web with false information is simply puerile. FYI, the web IS so polluted, was, is, and always will be - the cowboys are always out there. Surprise, search engines actually deal with it!
After a while though, I tend to see the decision as sensible for quite another reason. It separates technical syntactic validation from content accessibility rather than conflating the two concepts. We have WCAG for the latter so the HTML spec should be free from trying to mandate just a few selective bits of it.
Accessibility as part of HTML
Submitted by Marc Drummond on
That’s an interesting point that only a few select parts of accessibility are mandated in the HTML spec. I’m not sure that’s a reason to remove any or all accessibility from the HTML spec. While I wish it were not so, more people pay attention to HTML validation than they do WCAG, maybe because HTML has a validator that spits out a seemingly easy answer to whether or not a page is valid, while WCAG is much more subjective.
However, syntactic validation refers more to things like putting closing tags on elements, using quotation marks around attribute values, etc. HTML5 actually throws out most of the syntactic validation required by XHTML: it says you can still write syntactically valid code if you like, but it’s no longer a factor as to whether the page will be considered valid as per the HTML5 spec. Personally, I like code to be syntactically valid.
What we’re talking about is more whether or not the code is structurally valid. As in, which attributes are required for which elements, which elements can be nested within which elements, etc. Is it appropriate to consider accessibility as a factor for how we construct structural validity? I think so: we are trying to create rules to make our content as reusable as possible. So why wouldn’t we consider important factors like accessibility in that?
Why do you equate "alt tag
Submitted by Robert O'Callahan (not verified) on
Why do you equate "alt tag not mandatory in validators" with "death of the alt tag"? I cannot understand why forcing authors to add empty alt tags is considered such a boost for accessibility.
Not what I said
Submitted by Marc Drummond on
I never said anything about the death of the alt tag. That was another commenter. I did mention the death of the longdesc attribute (which actually is dead like a parrot).
I am not blind. I have tried to learn what I can about how people who are blind use screenreaders. My understanding is that if there is no alt attribute, then a screenreader will instead read out the filename of the image. If I were blind, I imagine this would bother me quite a lot.
In many cases, having empty alt text is actually preferred. Thank goodness we have gotten away from using spacer gifs, but just in theory, if there was one, it would be better to put an empty alt attribute on that img tag than to have no alt attribute or to have an alt text like “spacer,” as that image would be purely presentational with no content value.
For images that do have content value, where users for whatever reason do not provide alt text, would it be better for there to be simply an empty attribute or would it better for a screenreader to read out an ugly file name? I would be hard pressed to believe that the ugly file name is the better option for accessibility.
I fully agree with your point
Submitted by John Anderson (not verified) on
I fully agree with your point you made about close tags etc. ISTM that as you really need some close tags to validate appropriate nesting of semantic elements, it is better to explictly close everything than try to remember what needs closure and what doesn't. Anyone for xHTML5.0 strict???
I just want to take the empty alt tag thing a bit further though. A survey some years back:
http://webaim.org/projects/screenreadersurvey/#images found quite major discepancies between accessibility experts and actual vision impaired screenreader users. It seems from this and similar work that the users prefer to have their time wasted by real descriptions (even for images with no meaningful content) and so know that they have not missed what might be vital information. An empty alt tag is ambiguous, does it really mean "inconsequential cruft" or "author too lazy to provide vital information"?
Depressed
Submitted by Mario Vazquez (not verified) on
This post is so depressing, but only because you're totally right. I was looking at html5 as a bright new horizon, you've shown me it's full of clouds...
if there was one consistent
Submitted by mattur (not verified) on
Bear in mind there is a tiny minority of accessibility folks who are deliberately misrepresenting this issue. One side effect of W3C accidentally freezing its WCAG for 9 years was that some accessibility folks built a temple around WCAG1 1997-era techniques.
Summary and longdesc are obsoleted in HTML5 because the WG has decided that these techniques do not improve accessibility and actually cause problems: i.e. they are actively harmful to accessibility.
In each case alternative techniques have been proposed that do not have the same problems and have the potential to significantly improve accessibility.
It's also worth bearing in mind that making progress on accessibility requires trying new things and being candid about past failures.
Rightly or wrongly - and IMHO rightly, given the evidence compiled to date - these accessibility techniques have been judged suboptimal. Note that this does not mean they will stop working (another myth); this is just about whether authors see validator errors when they use these obsolete "inaccessibility" techniques.
Incidentally this "XHTML" page is badly formed and must be parsed as HTML to actually work. XHTML died for your well-formedness errors :)
I am a dork
Submitted by Marc Drummond on
I am just enough of a dork that I tracked down the sources of the two well-formedness errors and squashed those bugs. So all is well once more. :>
I have read enough things from people who I respect and who work on accessibility issues that I am concerned about how accessibility is being addressed in HTML5. My understanding is that, yes, the WG judged these techniques to no longer be needed and have suggested other methods. However, a lot of people who work regularly with accessibility have objected to those judgments. I do not think they are trying to mislead people, or that they are hopelessly out of date. Or that new things can never be tried.
But this particular issue? I do not see how making content generators feel better about themselves possibly advances accessibility.
With all due respect, I think
Submitted by Dale Cruse (not verified) on
With all due respect, I think we're looking at this argument from the wrong angle. We all seem to be ignoring the fact that the HTML5 spec still isn't fully baked. Unfortunately we're lamenting decisions that were made as if they're written in stone. They're not. If you don't like what the WHATWG is doing, get involved. Lobby to change it.
To me, arguing about this is like arguing about an election. If you don't go out, get involved, & vote, you have no right to complain about who gets elected.
If parts of the HTML5 spec don't satisfy you, get involved!
Not voting
Submitted by Marc Drummond on
That is definitely a good point. What disheartens me is that accessibility experts that know far more than me and are able to commit far more time than I am have done just as you suggest, and it seems their suggestions are rebuffed, at least on some of the high-profile issues I have seen.
+1 to Dale However, a lot of
Submitted by mattur (not verified) on
+1 to Dale
Perhaps bear in mind there's a lot of people who work regularly with accessibility have supported those judgements, too.
That's not to say all the decisions are beyond debate, but some PFWG members in particular have deliberately misrepresented issues, seemingly because they were appalled to realise that WHATWG and HTMLWG were doing a better job on accessibility than they were.
IOW it's a turf war, and there's been some pretty shameful behaviour from the accessibility establishment.
My advice is to check out the discussions and decisions for yourself. HTML5's general approach is to make accessibility obvious and available to all, not just (some) AT users.
It's hard to imagine how this universal design approach could sensibly be presented as being anti-accessibility - since it aims to ensure all users can benefit from accessibility features - but that's what has been happening. If anything, this accusation should be pointed the other way, but that's not happening. Go figure.
Pingback
Submitted by Bad IT day (th... (not verified) on
[...] Drummond has a great summary of the issues in his post “When standards go awry“. It’s worth checking out both the article and the interesting comments thread if [...]
Pingback
Submitted by Snapshots: Week... (not verified) on
[...] iPad isn’t “mobile”, Pete Fairhurst [article] defining mobile, iPad, netbooks, tablets When standards go awry, Marc Drummond [article] web standards, HTML5, accessibility, image attribute tags Comic Sans [...]
Great Post.....
Submitted by Joe Barry on
Great Post.....
Submitted by Joe Barry on
Thanks
Submitted by Joe Barry on
Trackback:
Submitted by Blog: (not verified) on
vfvg@gmail.com
Submitted by santa (not verified) on
Web standards is a general term for the formal, non-proprietary standards and other technical specifications that define and describe aspects of the World Wide Web. In recent years, the term has been more frequently associated with the trend of endorsing a set of standardized best practices for building web sites, and a philosophy of web design and development that includes those methods. Thanks.
Regards,
email lookup
Pingback from http://www.mold-removal.biz
Submitted by Guest (not verified) on
Add new comment