In the predecessor to this article, ‘Accessible web design – the whats and whys‘, I discussed the advantages of building accessible websites, what accessibility is and why we should be taking it seriously. In this article I’ll be running through some of the primary tasks to consider when building accessible sites.
Images
Images are often the first element considered when we talk about accessibility. Images feature heavily in web design, whether they are used in the construction of the layout or to aid the content – few sites are image-less. However, these images may prove useless to visually impaired or blind users, or anyone using a device or browser that doesn’t render imagery. In these instances, images can become hurdles as opposed to aids.
The alt attribute
The alt attribute provides alternative text to describe your images. It is placed within HTML elements just as any other attribute:
<img alt=”Descriptive text goes here” />
Describing images is important, especially if the image has a purpose (eg. logo, complimenting the copy, image link). If you don’t describe the image, it will make no sense to anyone who can’t see it.
null alt
If a particular image is meaningless, for example if it’s purely for decoration or to space layout elements, use alt=” “. There’s point describing an image that doesn’t have any purpose (ie ‘Spacer image’). This will just hassle users.
Common sense?
When describing your images, give them sensible descriptions which make sense and convey valid meaning. This doesn’t mean lines of text, just something short and sweet that makes sense. If the image links somewhere, describe where it links, for example:
Bad: alt=”logo_small_80x60″
Good: alt=”XYZ homepage”
Where’s my image!
Ah, the other benefit of the alt attribute is for those times when the images just don’t load. One of the great mysteries of life – everything else appears, the image is there on the server (or maybe it isn’t) but it sure as hell hasn’t popped up on the screen. So the alt text kindly steps in to replace it. It may not be sexy but it will provide insight into what should have been in that big white space.
Alt text for background images?
Well, if you’ve built your site semantically using CSS then all background images should be called through the stylesheet, therefore no alt text is necessary. In fact it’s impossible anyway. You can only apply the alt attribute to <img /> elements.
Links and Colour
When creating styles for links on a page, consider that not everyone can see colour. I, as you can tell by this site, am not currently practicing what I preach but will be taking it into account in the future.
If you use colour to denote links or click-able content, reinforce it with other methods such as emboldening or underlining. Otherwise colour-blind users may see no difference between standard copy and click-able links. However you go about doing it, it’s important to highlight links with more than one method.
Also, be careful that your copy and links don’t blend in too much with the background colour. Some people can’t pick out contrasting colours as well as others.
Don’t rely on colour to guide users. Methods such as ‘click on the purple box’ or ‘follow the red line’ may be deemed useless to colourblind users.
Flash!
EEk, there she is. You may or may not be surprised to know that Flash is actually quite accessible on some levels. It meets several Section 508 requirements including:
- Content magnification and scalability. Flash is predominantly built with vectors objects and so can often be scaled without distortion.
- Mouse-free navigation and keyboard accessibility. Flash offers tabbed browsing like in HTML but also provides a higher level of keyboard interaction.
- Visually/audibly engaging. Flash uses interactivity, dynamic visual effects and audio that may appeal better to younger users or people with cognitive disabilities.
- Custom colour palette support. Flash isn’t restricted to web-safe colours as with CSS, which of course can be taken advantage of to aid colourblind users.
Of course Flash still, being Flash, has it’s disadvantages.
- Some devices, such as the iPhone, plain don’t support it.
- Without captioning, Flash may prove completely useless to blind or deaf users.
- Flash can’t always be read by screen readers.
- Strobe effects and fast moving objects may prove difficult to understand or see clearly to anyone, not just visually inpaired users.
When it comes to Flash, I’m no expert. For more information on accessible Flash development check out ‘Creating accessible Flash content‘ and Macromedia’s white paper on ‘Best practices for accessible Flash design‘.
Structured Markup and CSS
I’d love to think that eveyrone was building semantic, well structured XHTML and CSS websites today but they’re really not, it’s a great shame. I haven’t got the time here to launch into a full article about semantic markup but I’ll touch on a few points.
Why? Oh yeah. Not all browsers use stylesheets so ensuring your HTML is valid, semantic and well structured will ensure it looks perfectly ledgible when the CSS is on vacation. Using the correct formula of HTML and CSS will also help to ensure that your site doesn’t break in different mainstream visual browsers (although it by no means guarantees this), it will make it easier to implement new content, scripts, imagery and more than anything makes it so easy to change massive details with one or two lines of CSS.
Lose the tables.
Use tables only for tabular data. Websites should be structured with divs, headers, paragraphs, lists and the odd spans and bits here and there.
Use lists for menus.
Whenever you have a menu, a list of links or even just a list – make sure it’s displayed that way. Use <ul> and <ol> to create lists, this will render as nice bullet points when no CSS is available. Chances are it will make your lists a lot easier to style up anyway.
Avoid ‘divitis’
Yep, divs are great. But you really don’t need loads of them. They contain blocks of content and are required for the central areas of your layout. However, most HTML elements can be individually styled and don’t need wrapping in extra layers of divs. This will reduce the file size of both your HTML and CSS and will clear unnecessary code.
No inline styles
Firstly, you don’t need to – get them all tucked away in the stylesheet. They add weight to the file size and aren’t always rendered correctly by different browsers.
Sure, there’s a wealth of information on this subject. If you want to learn how to build websites properly, aside from the plethora of information you could gather from a quick Google search, I would also strongly recommend Jeffrey Zeldman’s ‘Designing with Web Standards‘.
Cross-browser compatibility
So you’ve added your alt attributes, checked your links, and you reckon your markups pretty bob on. Your site looks great in Firefox (because that’s the coolest browser, of course). So what about Internet Explorer 6, and 7, which hold an estimated nearly 80% of browser market share?
When considering browsers, the main contenders on the market are:
- Internet Explorer 6
- Internet Explorer 7
- Firefox 2
- Firefox 3
- Safari
- Opera
- Camino
- Chrome
- Soon – Internet Explorer 8
To be honest – the list goes on. Personally, I’d recommend you always check your sites in IE6, IE7, FF2, FF3 and Safari. I know budgets don’t always cover it but they should do, and it may seem like a lot of effort and it can be. But regardless of accessibility, from a general Usability point of view – can you afford to lock these users out?
When tweaking your sites to render well in other browsers, don’t be tempted to use invalid CSS or HTML – this may affect other browsers that don’t render styles in the same way or even at all. I can assure you that all the main visual browsers can be catered for while using valid markup.
Validation
I’ll shamelessy tell you here and now that validation isn’t imperative. The majority of modern browsers can pick up on slight errors and either work out what you’re trying to do or produce an adequte alternative. Your sites do not always have to pass the W3C HTML and CSS validators, or Bobby or another generic ‘Accessibility test engine’ to be accessible. But to be honest, is it so much to ask to write your code correctly?
But don’t think for one minute that just because your HTML is valid and you’ve slapped a pretty little W3C ‘valid xhtml 1.0′ badge at the bottom of your site that it’s accessible. These validators don’t take into full consideration what font size you’re using in the text, the fact that your header colour may be low contrast against the background colour or whether your alt attributes acurately describe their parent image.
Scripts
There are 2 definitive rules to bare in mind when incorporating Javascript into your site.
- All scripts must be stored in an external Javascript file. No inline scripts unless absolutely necessary.
- All Javascript must be degradable so it doesn’t affect users who don’t have scripts turned on.
When developing in Firefox, I’d seriously reccommend you get hold of the Web Developer Toolbar plugin. This allows you to easily check how your site looks with/without scripts, CSS and has lots of other nifty features.
With Javascript languages such as jQuery and Mootools getting real popular – designers are spicing up their sites with non-intrusive and majoritively accessible Javascript, which is good! But always check that your site works full with all the scripts off or some users may get a nasty surprise.
Typography and Font Size
The area surrounding choices of typography, web-safe typography and scalable font sizes can get quite deep. Current browsers will only render fonts that are also present on the users system. So if you go designing and building a site with a great looking downloaded font – chances are only a very, very small fraction of visitors will actually benefit.
Web-safe fonts
Unfortunately, advances in general web font support have been small. We still have our hands tied dealing with the same default fonts as we were years ago. There are 3 main methods of dealing with this:
- The good way – the CSS ‘font-family’ property.
- The bad way – “Download this font here”
- The cool way – sIFR
CSS: font-family
When specifying your website’s fonts with CSS, you can specify multiple fonts for particular elements in order of preference. Therefore, if the user doesn’t have the first font installed, it will default to the next in the list and so on. This property looks as so:
p { font-family: Calibri, Tahoma, Arial, sans-serif; }
In the instance above, users with Calibri installed will see the paragraph fonts in Calibri. If not, it will default to Tahoma which is a relatively safe bet. Failing that, Arial will be used and in the most basic scenario the generic sans-serif font will be used.
“Download this font”
This is seen very rarely in modern design. But some designers force visitors to actually download the actual font file and install it on their machines so they can view the site in the designers selected font.
Not only is this completely inaccessible and unusable, it’s damn right unethical in some cases illegal.
sIFR (Scalable Inman Flash Replacement)
A popular option for text replacement is sIFR, pronoucned “siffer”. This is a Flash technology that replaces HTML text with a Flash rendered object, pulling in the required font from a .swf file.
This is great because it maximises the range of fonts that can be viewed on sites, breaking the mould of the restictive default fonts. And it’s completely accessible! If users don’t have Flash installed, they have Javascript turned off or their browsers plain don’t support Flash – it degrades to perfectly clean text that can be styled with CSS.
The only real downsides to sIFR are that, for the moment, it can only replace a single line of text so is only really useful for headings. Plus it can sometimes be a hassle to install and configure but if you do it enough times you’ll surely get wizzy at it.
It’s all well and good ensuring that your typography looks nice (as it’s an essential element of design) while still being accessible by all. However accessibility isn’t just about the typeface – you have to consider font size.
Em’s and Px’s
When specifying font sizes in CSS, the only units to consider are px and em:
- px (pixel) = static unit of measurement, corresponds with monitor resolutions.
- em = relative unit of measurement that equals the vertical size of an element’s text.
Assigning your font sizes with pixels ensures that they will be that exact size across the board. When visually impaired users wish to increase the font size, modern browsers feature the option to increase it, which will automatically increase or decrease the pixel size of fonts. (You can normally check out this feature somewhere in the ‘View’ menu under ‘Text Size’ or ‘Zoom’.)
The problem with this is that Internet Explorer 6 and certain other browsers don’t change the size of fonts set in pixels. IE7 features a page zoom function which does the job but this still doesn’t excuse sizing fonts with pixels. Instead we have to look at ems, which are relative.
The safest bet
The safest approach to styling your typography so that it displays at the size you want, while still being scalable by different browsers, is to set a default size in the body element. This is normally around 11px or 12px. Then use ems for the rest of the elements in your site.
If you set your default body text size to 10px, this makes it far easier to work out the sizes of other fonts as they will all be round decimal units. So:
- 12px will equal 1.2em.
- 35px will equal 3.5em.
You get the idea…
The tabindex attribute
The XHTML tabindex attribute allows your to specify the order in which keyboard users can tab through different elements on the page. By default, users who use the keyboard instead of a mouse to navigate website will tab from link to link in the order they appear in the source markup.
To apply tabindex just add the following HTML:
<a href=”#” tabindex=”2″></a>
and so on through the different elements you wish to prioritise:
<a href=”#” tabindex=”1″>Home</a>
<a href=”#” tabindex=”2″>Search</a>
<a href=”#” tabindex=”3″>Articles</a>
<a href=”#” tabindex=”4″>Return to top</a>
The benefit of using the tabindex means that users without the ability to navigate with a mouse can access the most important areas of your site faster, instead of tabbing endlessly through every link and active element on the page.
Accesskeys
Accesskeys are similar to tabindex. However, instead of specifying an order to travel through, accesskeys dictate a letter or number that represents an element. Different browsers interpret accesskeys differently. Sometimes you can simply press the number or letter while on a page but in most cases you have to either press alt/ctrl and the value to access it.
Apply accesskeys like so:
<a href=”#” title=”Return to the homepage” accesskey=”h”>Home</a>
The problem with accesskeys is that more often-than-not they’re not accurately depicted. So users don’t know what to press. It’s often a case of common sense – usually the first letter of the link title or the number of the item in the list in the case of menus. Sometimes a visual guide is given, yet sometimes they prove compeletely irrelevant.
Just don’t even do it.
To be honest, if you’re still designing websites with the techniques below… why? These were dirty elements that were on their way out when I first started playing with Freewebs and Dreamweaver MX.
- Image Maps – No. There’s no reason to be using image maps anymore. Opt for Flash or Javascript to really do justice.
- Table Layouts – No. Le’ts get semantic guys! Lose the tables and get with the structured XHTML and CSS.
- Spacer GIFs – No. Real simple – CSS > margin-top: 15px; = no pointless, bandwidth hugging, inaccessible spacer images.
- Frames – Absolutely Not.
- Applets – Nope, not here.
- Flashing and blinking elements – Most definitely not. Next time you create that family business site with some cheap WYSIWYG site builder with built in ‘snow effects’ or ‘flashing banners’ – go and knock your head on the wall and see the error of your ways. Do I honestly need to hold your hand to help you realise how inaccessible and darn right ugly these elements are.
On your way to becoming a better designer
Accessibility isn’t something you pick up over night, or indeed simply from a blog article such as this. In fact, it’s not a strictly defined set of rules or protocols that can just be learnt then adhered to and varies with every website you will build.
People such as the W3C, The Web Standards Project and the WAI are working every day to push for new changes and to evolve the mindset and general acknowledgment and acceptance of Accessible web design. It does benefit you as a designer or developer. It may not necessarily mean your designs look any better but will ensure that more people will gain access to your work, and demonstrates good ethics and consideration as a forwards-thinking member of the industry.
Where to next?
I’ll leave you with a few places to check out for far more information. If you wish to add anything please take full advantage of the comments section:
Read the full article and comments »
Resources for web designers are hardly scarce. Get subscribing to RSS feeds, get a good selection of favourite sites with regular news and tutorials and visit them regularly. I make an effort to spend a good 30-40 minutes (more if I get to the office early) every morning checking my feeds and bookmarking new sites full of inspiration.
Doesn’t agree with the idea of ‘improving yourself‘? On the contrary, teaching is one of the best forms of learning. Whether you’re teaching a friend how to use WordPress, writing an informative blog article (as I am now), lecturing a class or giving advice in a forum; the processes you have to go through to gather the information in the first place, then absorbing the feedback and further questions that develop, creates a perfect environment to learn so much more, almost subconsciously.
The main benefit of comment areas on blogs is the opportunity for readers to contribute and provide their own expertise and insight. Take full advantage of this, promote it and try to generate conversation with your commenters. Doing so will help to increase the chance of more input in future.
‘Improving yourself as a designer’ requires a lot more than reading books, toiling through tutorials and blogging around. There are so many contributing factors that make a good designer, and these vary from person to person.
For the past few months I’ve been blogging on a regular basis, usually between 1 and 3 times a week, even 4 times if you’re particularly lucky, or if I’ve been particularly bored. However since my previous post at the start of the month, Redswish has been left neglected by me and kept busy by the loyal readers popping back to seek new news, and perhaps a few new readers who’ve managed to source the site through whatever means.
What is this ‘accessibility’?
However, understanding web standards and accessibilty isn’t something you should really brag about. It doesn’t necessarily make you a better ‘designer’, it just means that you’re going about building websites the right way.