Archive for the ‘Accessibility’ Category

Semantic Whitespace

Monday, September 7th, 2009

Perhaps a little-known feature of many applications, including most web browsers, is that as well as click-and-drag selection, you can often use double-click-and-drag word selection. There's also a triple-click paragraph or line selection that you may not be aware of. (Internet Explorer has a heuristic selection model that makes it easier to select words at the expense of making it harder to select arbitrary amounts of text.)

Though little-known, it's extremely useful! A favourite trick is to double-click and drag to select words, then right-click and "Search current search provider for".

This word selection can show up an accessibility problem. Browsers and probably some search engines identify words by splitting the content on whitespace and block-level HTML tags – not on inline-level tags! This is sensible. If I write HyperText Markup Language (ie. highlighting initials in bold), I don't want the semantic content to be "H yper T ext M arkup L anguage"!

The accessibility problem is this. With CSS it's possible to accidentally write HTML that is neatly padded to look like words, but which doesn't tokenize (split up into words) properly. For two words to be considered separate you need to include semantic whitespace. Sites as big as Facebook and Twitter still make this mistake!

If your browser supports proper word selection (Internet Explorer's word-selection model is useless here), try double-clicking near formatting changes to check that your website is semantically correct.

Try it out! Can you detect the difference between these?

withoutsemanticwhitespace

with semantic whitespace

Tip: Don't use uppercase/lowercase in HTML

Wednesday, January 14th, 2009

It's sometimes tempting to use case for emphasis: uppercase and lowercase are well within the repertoire of useful graphic design tools. Graphic designers know that uppercase is slower to read than lower case, but in isolated phrases that's unimportant. But on the web there's a penalty to using just upper- or lowercase: it's not as accessible. Writing in normal sentence case conveys information. Specifically, the semantics of the sentence – particularly abbreviations – depend on the use of case, as this photo shows:

NUT CONFERENCE

NUT CONFERENCE

CSS provides a way around this: the text-transform property. This allows you to write your content in full-sentence case, and display it in full uppercase or lowercase as desired for stylistic reasons. For example, if your design calls for <h2> tags to be in uppercase, use

h2 {
text-transform: uppercase;
}

Of course, this allows you to simply remove the property if you change your site design; no content needs to be rewritten.

Some offenders even publish an RSS feed using uppercase titles. Never do this. People who want to syndicate your feed normally want it in sentence case, and there's no way to force that to happen if you aren't publishing the RSS feed using proper sentence case.

WCAG + Samurai

Wednesday, July 9th, 2008

The WCAG Samurai Errata to WCAG 1.0 is an independently-produced set of amendments ("errata" is not really the right word) that fairly accurately nail how WCAG is and isn't working for pragmatic but standards-compliant developers like me.

I stumbled across this while browsing Google for references while writing a proposal for a client. I was writing my usual set of caveats about the Web Content Accessbility Guidelines (WCAG), in which I lament how rubbish they are in practice. My usual spiel goes along the lines of "WCAG 1.0 informs all of our work at Mauve Internet. However, because the WCAG is subject to intepretation, and is now somewhat dated, we do not warrant conformance." I would like to make a clearer statement of how and why but a specification isn't really the place to challenge sections of the WCAG.

Happily, I can now get rid of this kind of non-committal note when writing specifications, and offer a firm commitment to WCAG+Samurai.

I will also be revising my company website – indeed, my company policy – to recommend conformance to the WCAG guidelines as amended by the WCAG Samurai Errata where possible.