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.