Semantics, Standards, Accessibility …

… the three legs of the Stool of Truth

As the thickest member of the WaSP ATF, I’ve been having a bit of a think about what the terms Accessibility, Standards, Semantics mean, trying to reach a working definition of the three terms, and how they inter-relate (while the other ATFers do hard work).

A good, modern website is like a stool. (The wooden kind. An inaccessible website is like the other kind.) The most stable stool is the one where each of the three legs is the same length, carries equal weight and supports its load well. Of course, it’s perfectly possible to sit on wobbly stool – but if it’s too wobbly, you’ll fall flat on your arse, in much the same way as this metaphor does.

Gurus need read no further; here’s my beginner’s guide to the Stool of Truth.

Semantics. Who needs them, and what colour are they?

Marking up a document semantically means describing what a piece of content actually is, not what it looks like

“Semantic” is defined in the dictionary as “Of or relating to meaning, especially meaning in language.” And (staggeringly) that’s what it means in the web world too. Marking up a document semantically means describing what a piece of content actually is, not what it looks like.

This isn’t just a web thing: you do it in Word when you choose “Heading 1″ from the styles and formatting menu, instead of just highlighting the words and underlining them or making them 14 point.

So if some content is a paragraph, wrap it in <p> tags. If it’s the second level heading, mark it up as an <h2>. If it’s a blockquote, mark it up so even if you don’t like the browser’s default way of displaying it – changing the appearance of something is exactly what CSS is for.

Similarly, only use a <table> if your content is actually tabular data. If it is a calendar, or would be logically displayed in a spreadsheet, it’s tabular. If you’re using a table just for layout, then it’s not semantic.

Sometimes, it’s not so easy to mark up your document semantically. For example, modern best practice says that menus should be marked up as an unordered list, with each item being a link in a list element. Menus are, after all, a list of links – but aren’t they’re a special kind of list? How can you semantically distinguish a menu list from any other list? You can’t, because html has a limited vocabulary, so sometimes you have to compromise.

Marking up semantically isn’t just a matter of using the right tag for the job, either. Once you’re steaming ahead using CSS, you need to think about the names you choose for your classes and your ids.

Something I’ve just come to understand (and haven’t yet implemented here) is that “what something looks like”, includes where it appears on the page. So a chunk of content that you’ve called “leftcolumn” isn’t semantically described: you’ve just said what it looks like. Ask yourself, what is the stuff in “leftcolumn”? Is it a menu? Is it the “About Us” section? Is it contact details? Is it a photo of me with the headline “Yummalicious dreamhunk?”. When you’ve worked out what it is, call it that!

What does it matter?

Consider these two pages, the first is marked up semantically:

h1 {font-size: x-large; color: red;}
p {font-size: medium;color:black;}
<h1>Depreacation's what you need</h1>
<p>Patrick Lauke recently shocked the web world when he deprecated xhtml in favour of Sinclair ZX81 Basic</p>
<h1>Web Standards: Brighton Beach standoff</h1>
<p>Hundreds of mods yesterday burned their parkas and donned bondage trousers after their lambrettas were mercilessly mocked by a portly punk on Brighton Beach</p>

Here’s a similar page, marked up without semantics:

.headline {font-size: x-large; color: red; display:block;}
.story {font-size: medium;color:black; display:block;}
<span class="headline">Depreacation's what you need</span>
<span class="story">Patrick Lauke recently shocked the web world when he deprecated xhtml in favour of Sinclair ZX81 Basic</span>
<span class="headline">Web Standards: Brighton Beach standoff</span>
<span class="story">Hundreds of mods yesterday burned their parkas and donned bondage trousers after their lambrettas were mercilessly mocked by a portly punk on Brighton Beach</span>

These will both look identical on the screen. But the first has invisible structure, the second has none. Who gives a blockquote’s bogie about invisible things? That’s right! A screenreader!

A screenreader user will be able to use special keyboard commands to “scan” the page by listing the headings, or jump from heading to heading. It knows which are the headings by looking for stuff between those <h1> tags (or h2, h3 etc). As there’s no headings in the second, a screenreader user can’t do that.

Standards: moral guidance, or fascist tyrrany?

“Standards” means two things. It’s the practice of using the right tools for the right job – for example, seperating your markup from your styles from your behaviour layer (JavaScript).

The best thing about choosing the right tools is that it gets you into the discipline of seperating your content from your presentation. Anything that describes how a page should look – fonts, colours, background images and (don’t forget!) where it is laid out on the page – goes into a different file. Markup for meaning, CSS for beauty. That’s your mantra.

“Standards” is also means that you must use the tools well, by making sure that your code conforms to formal grammars issued by the Holy W3C. Everyone coding a real programming language like C++, or FORTRAN (yay!) must conform to formal rules, or they get a syntax error, but html coders haven’t needed this discipline. Now they do.

The W3C validator is always right, and as merciless as a pre-menstrual dalek

Writing to formal rules is a poncey way of saying that all tags must close, everything must be lowercase, and there’s certain housekeeping rules that you must follow to be considered valid mark-up. Not only do you need to structure your document semantically, but you need to code those semantics accurately, or you’ll fall foul of The Validator, which is always right and as merciless as a pre-menstrual dalek.

Your initial level of frustration with the esoteric do’s and don’ts of these rules will depend on which set of rules you choose to conform to – html 4? xhtml 1? transitional? strict? xhtml 1.1? The choice is yours – just follow the rules.

Writing to Standards makes your markup more portable, more future-proof and more likely to be interpreted correctly by screenreaders.

Standards ain’t Semantics

Standards are not the same thing as semantics. It’s taken me a while to realise this – an article I wrote at the end of May called Standards and Accessibility – navigation lists should really have been called “Semantics and Accessibility”.

Those two sample pages above to illustrate semantic mark-up are both coded to conform to html 4.01 or xhtml in all its flavours. They are both “standard”, but one is plainly better than the other.

That’s because a machine can check whether your html’s got a clean vest on and has washed behind its ears (e.g., that you’ve closed your tags and escaped your entities etc). But it can’t tell what you mean and whether your purple prose should really be a blockquote, a header or a paragraph. It can pronounce on the science of validity, but it can’t judge on the art of meaning. That’s what you’re there for, chum.

Accessibility guidelines

But even then, there are some times when Standards and semantics still aren’t enough, as they don’t ensure access to people with disabilities.

So our good chums at the W3C set up the WAI to come up with guidelines on proper use of semantics and standards in order that the disabled have access to the Web.

<Personal opinion a.k.a. rant> In my opinion, “accessibility” means making the web accessible to disabled people. Mobile access etc is a noble aim of the standards community, but it’s not the primary aim of accessibility, and it’s scope-creep to worry about it in the context of accessibility. More rant.</rant>

Accessibility isn’t just about blind people

Here’s another mantra: accessibility isn’t just about blind people. Personally, my vision is pretty good, but because I have multiple sclerosis, if you ask me to click a link that’s 5px by 5px, I won’t be able to if I’m relapsing or simply tired.

My neighbour, Jane, has really bad arthritis so navigates using the keyboard. If you make her repeatedly press the tab key through your endless navigation (Hi, Jeff Bezos), you just aren’t going to get the hundreds of pounds a year she spends on books. People with dyslexia need ragged right edges, not justified text; people with autism or ADD need a page without whizbang graphics or ads to distract them.

Your job as a web developer, fashioning the third leg of the Stool of Truth, is to take my needs and their needs into account.

But these needs are so diverse. Sometimes, they’re contradictory. (How do designers marry a dyslexic’s need for Comic Sans with the quivering aesthete’s need for trebuchet or Georgia?)

This is why there isn’t a validator for accessibility (and anyone who says otherwise is a box-ticking bullshitter), because accessibility is about people. A push-button checker can help scan for obvious ommissions when deadlines growl, but the machine merely says that your code isn’t cretinous – but could easily still be stupid.

The WAI guidelines aren’t bad; they’re rather woolly and outdated, and occasionally nonsensical. Some things are prioritised incorrectly (skip navigation is only priority 3? Tish and Pish, Mr WAI!).

They also unfairly (arrogantly?) assume only w3c technologies can be accessible. PDFs can be made accessible (I’m looking forward to Joe Clark’s mega article on PDF). And let’s say it loud and proud: Flash isn’t necessarily evil, although you have to break the validation of your page in order to get the Flash movie in there.

The biggest problem with accessibility isn’t PDF, Flash or the WAI guidelines, it’s that the assistive devices don’t play nicely with Standards (which is why the WaSP ATF exists, of course).

Two more legs of the stool?

Half way through writing this, I worried about the two legs I missed out from the Ultimate Web Site – great design, and usability. I started trying to devise a new title (“the pentapodic seat of truth” didn’t read well). Then I stopped worrying.

Great design is up to you. Once you’ve seperated your content from presentation by using standards, the design layer is exposed ready for you to work your aesthetic magic. The CSS Zen Garden shows how easy it is to devise radically different designs that all sit on the same semantic(ish) structured markup. And as design is subjective, no-one can pronounce on it.

Usability is generally enhanced by the accessibility of your design. The DRC reports (in their report that is unavailable as html – doh!):

It is also notable that both blind users and non-impaired users took far longer on low accessibility sites than on high accessibility sites, and that this effect was not much more pronounced for disabled users: 51% longer for blind users, and 46% for non-disabled users.

Phew. Time for a Guinness.

What’s that? The colour of semantics? Easy – the same colour as the sound of one hand clapping. Cheers!

11 Responses to “ Semantics, Standards, Accessibility … ”

Comment by Matt

Interesting; any details on versions? Andrew’s comment is from 2004 and a tad brief…

To continue your metaphor, build a stool, but as one leg is finsihed, another leg gets shaved by an inch.

Comment by Bruce

I believe they’re doing research that’s not published yet. Whether or not it counts as Jaws not following a standard or not is an interesting point: is Flash Satay a hack?

Comment by Gez

Great article, Bruce.

The Validator, which is always right and as merciless as a pre-menstrual dalek.

This is probably going slightly off-topic, but one weakness of markup validators is that they don’t safeguard against DOM injection. It’s becoming more and more popular to see techniques that add invalid elements and/or attributes using scripting, purely so they get a clean bill of health from markup validators. As the scripts always run when the page is loaded, it would be relatively straight forward for markup validators to include changes to the DOM made through scripting.

Of course, their biggest weakness is the point that you make; they have no idea of what is semantically correct for the content.

Comment by Lachlan Hunt

Very good article, but you made one little mistake. The validator isn’t always right (there are bugs), but it is very close. However, because the chances of a relatively inexperienced author finding a validation bug (especially one that isn’t already known) are slim to nil, there’s little harm in saying the validator is always right.

Comment by Ian Lloyd

I was wondering the same thing, Chris. I imagine it would be one of their more old-fashioned comic strips, reminiscent of 1940s Boys Own stories. Anyway …

Like the summary, Bruce. As ever, you put it in a very readable and easy-to-understand way (dare I say it, you have an ‘accessible’ style?). In addition, any article that uses the phrase ‘pre-menstrual dalek’ has got to be good.

Anyone who has met you might not realise that you have a disability, but that just goes to show how many others are in the same boat, so to speak. It’s important to remind people of this.

Anyway, you focused on that one leg. Now I’d be interested to see one of the other legs of this ‘stool’ alongside it – that being the design leg. The examples of accessible sites that look like they’ve actually had an iota of designer input are few and far between (I’m not including the personal blogs here – they almost don’t count, in my opinion, preaching as they are to the converted – but rather I’m thinking of the bigger sites out there).

You know what though, I like Malarkey’s trifle analogy more than the stool one. Especially if I have to eat it ;-)