Accessibility: whats that mean?

I am often asked about accessibility, being the resident expert (this by no means qualifies me as an expert, simply the most qualified in the office.) To some peers in my field, or those in related fields, they imagine accessibility is simply the validation of their code. It’s possible that every frontside web developer starts out this way: I know originally, I did. I believed that if the code validated the W3C, jumped through their hoops so to speak, my code was accessible to everybody.

This, to my chagrin, is not the case.

The thing about the W3C’s CSS Validator and (x)HTML Validator is that they do only exactly what they proclaim to do: check the validity of a type of document. Basically, if it works syntactically, its valid. If you miss a semi-colon, or forget to encapsulate a certain something with the right kind of brackets, the document doesn’t parse properly, thus being invalid.

So, whilst this proves a lack of parsing problems, it doesn’t prove much else. Your document could be riddled with problems, but could still come out the other end of the validation service squeaky clean, not a damaging error or warning flag to its name. I am going to outline a few simple things you can do to increase the accessibility (which, in case you didn’t quite catch the meaning, is “to be easily understood,” or “able to be easily obtained or used.”)

I like skipping stuff

The bits you don’t want to read, because they’re not relevant to you, or that you already know, why should you put up with reading it over and over? This is especially true for menu navigation present in websites with more than one page (technically, if it were just the one, it would be called a webpage, not a website, wouldn’t it?) Imagine now, the thought that hearing an entire website will take a great deal longer to get through than visually grasping the information. Not to mention the fact that users on the small screen (handheld devices,) with their awkward scrolling (in)capabilities, will appreciate it. Skip to navigation is a great way to overcome this. Placed just underneath your <body></body> (so it’s the first thing to be read or heard,) it’s as simple as:

<ul id="menu-skip">
    <li><a href="#menu">Skip to main navigation</a></li>
    <li><a href="#extras">Skip to secondary content</a></li>

Main navigation structurally above your content? No problem, simply switch the skip to for the main navigation with a skip to #content: skip to content. Now for the setbacks: not every design accounts for visible skip to navigation. Most designers don’t like it, and most clients are less than thrilled, to put it euphemistically. Since we all know display: none; prevents screen readers from even acknowledging there is content available, we resort to a more roundabout method:

ul#menu-skip { position: absolute;
    left: 0;
    top: 0;
    visibility: hidden;
    font-size: 1px; }

… and the skip to menu has vanished to visible users. Just make sure the CSS code is placed in a stylesheet only for screen media. No other device needs to see that.

Just because you want to see a period-colon-colon-period doesn’t mean I want to hear it

So, that whole “separating content from presentation” thing? That isn’t just leaving out the spacer.gifs or nested tables, it also means getting rid of those useless characters that somehow get insisted upon as a design feature. Page titles with “.::.” might look prettier to you, but they’re a bother for someone hearing “period colon colon period”. Also, it doesn’t really look all that cool anyway.

I’m also peering in the direction of Breadcrumb menu creators who decide that, four levels deep, it’s not at all distracting to hear “right-angled bracket” three times. It’s a list of navigation, sourced by how deep hierarchically you are within a website, so use a list. What seems logical to me is using an ordered list, as it’s ordered by level, but if you prefer an unordered list, that’s fine, as long as I don’t see a bunch of “>”s lying around. Use a background image on the <li>s instead, so it won’t leave an audible scar. Utility menu creators with pipeline fetishes are also in the same boat here.

Headings signify how deep the rabbit hole goes, not the approximate size your designer has set in a PSD

It is widely known as “<h3> abuse”—using a <h3> where the document structure might be calling for a <h2>, but because you think those look too big, you decide to skip to <h3>. Think of your document structure clearly. You have a main heading that encompasses all the content on the page. You split up that content into little subsections, and perhaps even those into even smaller subsections (sub-subsections?)

Don’t skip heading numbers. Use CSS to make <h2>s’ font size smaller.

There’s a (probably never-ending) debate as to whether a document should be single document structured, or entire website structured. I haven’t made my mind up about the matter: I think both seem decently logical enough. This fence-sitting view might change with time.

It might be clean, but that doesn’t mean the content isn’t rubbish

This can be a difficult one, especially for those professionally in this business: if you have no idea what your client is talking about in the copy, how could you judge if it were rubbish or not? One simple rule is to not beat around the bush—get to the point, quickly and succinctly. It’s no good forcing a user to wade through hours of literary drivel only to find one small pertinent fact right at the end. People get bored really quickly, and the general consensus is eight seconds worth of bored. If your site can’t load up fast enough for a growing culture of impatience, they won’t even get to read your content. They will simply move onto another site that can get the information they want faster. Get them their information as fast as you can.


This isn’t all there is to it. There is much, much more. But this is all for the now. There should be enough things here to get anyone started. Good luck, learn things, and have fun :)

This entry was posted in techthings and tagged . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *