Hi, I’m Harry Roberts – a 17 year old web developer from the UK. I specialise in standards compliant, accessible and usable front-end development.
This article offers in no particular order the simplest yet often most effective tips for beginning life as an ‘accessible developer’. This list is by no means the be-all-and-end-all of building accessible sites – it is more of a starting point.
1) Web Standards
Probably the most obvious aspect of accessible web development is adherence to web standards. This means using CSS to separate content and style, tableless layouts and semantic markup. All these features provide a solid starting ground for crafting accessible sites.
By using external stylesheets to style a page’s elements users can disable CSS and be left with nothing but the content – arguably the most important part of any site. This coupled with not using tables for layout means a page can be brought down from a heavily styled document, to its bare bones text.
2) Validation and DOCTYPE
There is an age old debate as to whether validation is that important. In my eyes, and in the eyes of many other developers worldwide, it is. Valid markup means pages are rendered in standards mode, invalid markup means browsers try and interpret and render code themselves, in quirks mode. This can lead to undesirable results and simple errors such as an unclosed tag can have a domino effect on subsequent elements.
The correct DOCTYPE will instantly tell a browser how to render a document. It is a good idea to validate your xHTML documents in the 1.0 Strict DOCTYPE, or if that isn’t possible for whatever reason, 1.0 Transitional as a last resort.
3) Images
Images are a fundamental part of web development; however they can and should be used sparingly if a more accessible method can be put into practice. A great example is web text, where the font choices are limited and some developers are required to use an image of custom text, do not insert it as an <img /> element. Instead use image replacement. By far the most accessible means of image replacement is the Gilder-Levin method. This solution remains accessible when styles and images are disabled either independently of each other, or at the same time.
Another thing to look out for when using images for content backgrounds is to ensure that text is still readable when images are turned off. Always try and specify a background colour when applying a background image through CSS.
4) Printed Documents
Some users are required to print web pages for a number of reasons – this may be simply to read content offline, or because they need to through having a handicap or disability. One thing to realise when reading printed web pages is that links are (obviously) useless, and as such users can’t see where they point. A printed page can’t have its links followed out or the hrefs read/seen.
Bearing this in mind, any printed web page is taken out of ‘link context’ as soon as its interactivity is lost. A great CSS trick to alleviate this problem is the nifty :after pseudo-class:
a:link:after, a:visited:after{
content:"(" attr(href) ")";
}
By putting the above in a print specific stylesheet, the href attribute of any links are inserted after the <a> tag of any hyperlink. This means users reading printed sheets can see where links point.
In the same respect, <abbr> elements are useless to users reading printed documents as they actively require a mouse hover to display the abbreviation’s title tag, so by adding the following to your print stylesheet you can show users reading printed pages what abbreviations stand for:
abbr:after{
content:" ("attr(title)") ";
}
I put both of the above into use on my CSS Wizardry links page.
5) target=”_blank-faced”
First off I must admit that I myself have only recently stopped using the target=”_blank” attribute in my markup. This is for two reasons; a) it doesn’t validate under the Strict DTD and b) it is by all accounts an inaccessible practice. The reasoning behind this is that opening new tabs, or heaven forbid, new windows (yes IE6, I’m looking at you) disrupts the users flow, and also creates a ‘fresh’ back button. Less savvy users are suddenly confronted with a new window and no obvious means of returning the where they came from. This can be both confusing and frustrating.
I can understand why developers still advocate the use of target=”_blank”, after all, you don’t want users navigating away from your site when you could just set them up browsing an external link in a new window, leaving their session on your site still active. That is very true, but I look at it like this: if your site is worth them returning to they will hit the back button until they get back, if they don’t think it’s worth returning to – your fault!
6) Tables
Ok, hands up who didn’t see that coming. Those with their hands raised please leave now. Tables are the hottest of hot potatoes when it comes to accessible development. The cardinal rule is never use tables for layout purposes because this is one of the most inaccessible practices to have made it through from the nineties.
First off, tables for layout mean bulky code. Why nest dozens of <td> elements when a little semantic <div> work will work wonders. Properly implemented xHTML and CSS means semantic pages, which generally load quicker, contain less superfluous markup (which in turn reaps SEO benefits), and code which is infinitely easier to understand by both humans and screen readers alike.
Secondly, tables maintain their structural integrity when styles are turned off, so the page isn’t as easy to read when CSS is disabled. In terms of styling, a page created using semantic xHTML and CSS with styles on should generally be regarded as ‘all’, the same page with styles turned off should generally be regarded as ‘nothing’. A page built using tables for layout with styles off occupies the awkward middle ground between all and nothing – which is of extremely little use to anyone.
That said, tables are perfect for tabular data of all things. Who would have thought?! Do not rule out tables for displaying data such as a table of results, or a table of prices. A lot of developers try and create tables for displaying data by using lists and other CSS tricks. This completely defeats the object of CSS and xHTML – a CSS table is not semantic, and when styles are disabled they break shockingly. Buy CSS Mastery and learn how to code semantic, accessible and standards compliant data tables.
7) Flash
Once again, this was a dead cert in this list. Flash is a fantastic tool in the web developers’ arsenal. It is however inherently inaccessible when misused. As a general rule sites should not be made in 100% Flash. If they need to be, a HTML equivalent should be provided (adhering to the rest of this list, naturally).
Flash as a ‘bells and whistles’ addition should also be carefully considered when developing web pages. You need to consider the importance of the Flash in context of the document, and then decide whether or not an alternative should be provided. For example, a Flash banner ad need not have an accessible equivalent provided as it’s often of very little relevance to the content the user is after.
Headings
The heading tags are nothing short of a Godsend for developers wanting to craft accessible, semantic and meaningful documents. If you create an unstyled web page containing all the heading from <h1> through to <h6> in numerical order you will immediately see how a hierarchy is formed. Use the heading tags to apply a visual structure to your pages makes it easier to scan and ultimately more usable.
<h1> headings carry more weight than a <h4> heading, so bear this in mind when applying semantic emphasis to parts of web pages. For example, the <h1> should define the main title of the page and should be used once. <h2> tags obviously carry the next weight and can be used more than once, but not too much, perhaps defining sub categories of articles. Next is the <h3> which can be used more still right through to the <h6> tag. It is unlikely you will ever really get to the <h6> tag, but knowledge of the heading tags uses allows you to know when/where to use it.
9) The em based layout
A great way of adding to the usability and flexibility of a web page is to style it in a relative size such as ems. The nature of ems and their relative sizing mean that they resize flawlessly. Defining a <div> width in pixels give it a fixed width, styling the same <div> in ems allows the <div> itself to be zoomed.
Typically an em is defined as the width of the letter ‘m’ at any given type size. As most browsers’ default text size is 16px, one em is also 16px, thus 2em is 32px. This is not the simplest number to work with, so to convert one em to 10px instead of 16px apply the following CSS:
html{
font-size:16px; /* To make sure the default font size is 16px */
}
body{
font-size:62.5%; /* 62.5% of 16 = 10 */
}
div#wrapper{
width:90em; /* This equals 900px */
}
However, if you have a <h1> with a font-size of 2em and child element will be twice as big if you specify a new size in em:
h1{
font-size:2em; /* Equals 20px */
}
h1 strong{
font-size:2em; /* This equals 40px because it is 2 times the size of the parent */
}
Holding ctrl and scrolling the mouse wheel will now zoom not just fonts, but anything styled in ems – whether it be a <div>, <ul>, padding, margins and borders!
10) JavaScript
JavaScript is a fantastic way of adding further interactivity to web pages, whether it be flyout/drop-down menus, animated content such as accordions or slideshows/lightboxes.
What you must bear in mind however is whether or not the page/element will function without JavaScript – graceful degradation. The most critical of these are flyout menus or any JavaScript enhanced navigation. Navigation is undeniably the backbone of any website and if your navigation will not work without JavaScript then neither will your site. Make sure that anything reliant on JavaScript for aesthetics will still be usable (even if it is ugly) with JavaScript disabled.
There you have it – The Top Ten Tips for getting your accessible web development under way.