(Last Updated on )
Everybody knows that to be completely accessible and web standardsly lovely your site should
- be perfectly semantic
- completely separate style from content
and without that holy trinity, your site isn’t doing its job, right?
Wrong. Or rather, not wrong – but the three above are often not possible in a commercial environment, so you do the best you can.
Last month, two new sites launched for which I was front-end technical lead. Not a single page on either site validated.
The main problem
The main reason for the lack of validation is to get round a really important Internet Explorer bug that can make in-page links inaccessible if they’re identified by an
id on an element like a heading, or a div or a paragraph that doesn’t have hasLayout. That is, if you link to
I’ve got a simple test page. Try it in a modern non-IE browser and activate the link in the first paragraph. The focus goes to the paragraph that’s the destination of the link, so you’ll see nothing (unless you’re using Firefox, in which case the whole paragraph that is the
:target of the link turns a nice pink backing). Hit tab again, and the focus should go to the link in the paragraph, which will go yellow.
But in IE (and, shamefully, this includes IE7), you can never tab to the second link as the focus gets lost. (Further explanation of the bug on Jim Thatcher‘s site.)
Jim Thatcher’s round-up suggests the following code
<a name="content" id="content"> </a>
but frankly, that seems a bit clunky, especially as the sites I launched were relying on content to be provided ready-marked up by subject area experts in the business rather than the web team.
It was Gez Lemon who provided the answer, which is to give each link destination a
tabindex of -1:
Styling away spurious outlines
One unintended side-effect of a negative tabindex is that it makes elements focussable, and they can then receive dotted outlines. I toyed with the idea of leaving these in so the user could see where they’ve landed, but decided eventually that it’s best not to muck about with user expectation, so killed these in modern browsers with the CSS
Invalid code? Won’t somebody think of the children?
I’m generally a stickler for valid code, as I believe it helps accessibility, However, as Gez says,
Despite my stance on validity being important for accessibility, this is one of those situations where I believe an invalid attribute with an invalid value would be excusable as there’s an obvious benefit for accessibility.
It’s also a question of philosophy. From my perspective, valid code is worth aspiring to, as it creates a predictable DOM tree, which is good for assistive devices, as well as for scripts that add Ajaxy bollocks. Incorrectly closing tags, nesting elements the wrong way and other markup sins will make your DOM unpredictable. But adding an invalid attribute is unlikely to do so.: I’d be very interested if anyone can show me ill-effects. (Also see my somewhat dated 2004 post CSS/ xhtml: does validation matter?)
Semantics go down the pan, as well
I mentioned that content was being given to me ready-marked up by non-webheads, who all received a styleguide called the “Expert Author Markup Guide” (PDF, 140K) that detailed the elements they were allowed to use. Deliberately, not every element available in html was in there. (The definition list is notably absent, and tables glossed over.)
(You’re invited to criticise the Markup Guide; it accompanies the Web site Constitution.)
Another thing that breaches the Standardista’s Code of Honour is my advice that expert authors add decorative images in the mark-up. This is because it’s folly to commit yourself to adding lines to the stylesheet for every bit of stock photography frippery, and suicidal to ask expert authors to add stuff to the CSS themselves – with a
min-height rule and an IE6 pseudo-min-height too.
For a fraction of a second I considered inline css to add decoration – and then saw the error of my ways. In those areas of the site marked-up by expert authors, decorative images are achieved by the good old-fashioned
img element, no presentational attributes and blank alternative text.
Swings and roundabouts
I believe that this pragmatic approach has benefits as well as compromises. The negative tabindex has an obvious benefit – it makes content accessible in Internet Explorer.
The cut-down markup delivered by expert authors has an advantage for web editors, who can run save time by quickly reading the code to check semantics, and running submitted content through html tidy to fix incorrectly closed tags.
There’s a more subtle advantage too; whereas previously, expert authors wrote reams of unstyled Word pages and “put it on the web” by pressing the “make PDF” button in Office, now they have to think about structure, levels of heading and the like, so the documents that are published as html benefit from better structure, more thought and fewer words.