When standards go awry

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.

Here’s the decision.

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.

Tags: 

31 Comments

It's a shame the HTML working

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/

Flickr

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.

I don't see how adding empty

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.

A feature that "works in

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.

NVDA is a free AT for Windows

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?

I look after a very large

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.

Why do you equate "alt tag

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.

I fully agree with your point

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"?

if there was one consistent

if there was one consistent theme, it seemed to be that accessibility concerns were tossed out the window

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 :)

With all due respect, I think

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!

+1 to Dale However, a lot of

+1 to Dale

However, a lot of people who work regularly with accessibility have objected to those judgments.

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.

vfvg@gmail.com

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

Add new comment

Filtered HTML

  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd><p><h1><h2><h3><h4><h5><h6><blockquote><div><span>
  • Lines and paragraphs break automatically.

Pingback filter

  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.