Practical Accessibility Tips with WCAG 2.0

Derek Featherstone recently wrote a blog entry titled "When is the right time for accessibility?" in which he looks at when is it appropriate to invest in accessibility. Is it better to release your product and add accessibility later, or build-in accessibility from the start?

As far as building web sites is concerned, I’m with James Edwards when he says it’s our job as web developers and designers to ensure content accessibility:

We should make an effort to create accessible content, because it’s part of our job. And frankly, it doesn’t take much effort; it’s not difficult.

I have to admit that for me, accessibility has often appeared to be a minefield, where every seemingly minor decision has the potential to create an accessibility disaster. I’ve looked for a central resource that will show me practical examples of correct markup, so that I can avoid making accessibility mistakes that will be hard to fix in the future. I think the "Techniques for WCAG 2.0" document is a great starting point.

Usually W3C documents are tedious, technical, and hard to wade through — trust me, I did a lot of wading when I was editing the SitePoint CSS Reference. But "Techniques for WCAG 2.0" is unlike that at all; it’s written for web developers and designers — instead of browser makers — which makes it very accessible (ha ha).

As a quick sampler of the techniques presented, here are a few tips for constructing forms. You’ll notice straight away that the techniques frequently seem like basic common sense, but that’s often the case with accessibility.

Use Standard HTML Form Elements

As described in H91: Using HTML form controls and links, the recommendation is to use standard HTML form controls and links. Standard form elements have established keyboard shortcuts provided by user agents, and assistive technology software makes use of the associated accessibility APIs built into every operating system. Yes, it can be as simple as that.

Always Use Explicit Labels

H44: Using label elements to associate text labels with form controls makes the recommendation that you should always have a label element with an appropriate for attribute value for all your form fields:

<label for="fname">First Name:</label> 
<input type="text" name="fname" id="fname" value=""/>

It also recommends that you avoid implicit labels like the following because of compatibility problems with some screen readers:

<label>First Name: <input type="text" name="fname" id="fname" value=""/></label>

Use the tabindex Attribute

H4: Creating a logical tab order through links, form controls, and objects highlights the importance of the tabindex attribute. Adding the attribute to all your form elements to create a logical tab order allows for efficient keyboard navigation of your form:

<label for="fname">First Name:</label> 
<input type="text" name="fname" id="fname" value="" tabindex="1"/>

Indicating Required Fields

H90: Indicating required form controls is my favorite of the few I’ve mentioned here and an example of the practical help you’ll find in the guidelines. It outlines three simple, accessible ways to indicate that a field is required.

Use the word required in the field label:

<label for="fname">First Name (required):</label> 
<input type="text" name="fname" id="fname" value="" tabindex="1"/>

If you use an asterisk to indicate required fields (like so many sites do) then try using the abbr element to add the much needed information:

<label for="fname">First Name <abbr title="required">*</abbr>:</label> 
<input type="text" name="fname" id="fname" value="" tabindex="1"/>

If you use an icon, make sure to use the alt attribute:

<label for="fname">First Name <img src="required.png" alt="Required field"/>:</label>
<input type="text" name="fname" id="fname" value="" tabindex="1"/>

There are many more tips on the WCAG 2.0 Techniques page, enough for a firm grounding in the art of accessibility. When you read through them you realize that accessibility is more about how to make your content accessible to everyone — regardless of user agent, device, or circumstance — rather than just various screen readers. Which is what the Web is all about anyway.

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • http://manwithnoblog.com Gary Barber

    When you read through them you realize that accessibility is more about how to make your content accessible to everyone

    Thanks Andrew, yes, correct, accessibility is about everyone. For the most part it’s just a little more work if you do it in the beginning or just plan for the site to be accessible in the first place. WCAG 2 is not to be feared, but embraced.

  • vavroom

    Good post Andrew, thanks for that :) Always nice to see accessibility discussed on big sites like Sitepoint.

    As for the question of which is better, investing in accessibility from the start or retrofit later, I’d say the answer is “from the start”, no contest. It’s a bit like building a house. If you put in narrow doors and steps and need to retrofit for accessibility, you’ll have to tear down doorways to widen them, and build ramps. It costs both time and money to do that. If you’d made the doors wide enough and hadn’t build steps, you would have saved tons of effort and energy. Same thing for websites!

    Regarding tabindex, there is some controversy about just how useful they are. Undoubtedly in forms, they are good, but they may become rather cumbersome if used in menus and other navigation elements. The WCAG guidelines could easily be read to mean that all links, form elements and objects on a page have to be tabindexed. To do this would be a mistake and create more accessibility barriers than resolving any.

  • http://www.tyssendesign.com.au Tyssen

    Adding the attribute to all your form elements to create a logical tab order allows for efficient keyboard navigation of your form

    As vavroom mentioned, using tabindex can sometimes cause more problems than it solves, and in most cases, there would be no need to include tabindex on form elements as the normal tabbing behaviour would follow the order in which they’re laid out. It’s only when you want tabbing order to be different from that of source order that you’d really need to use tabindex.

  • MGoddard

    I thought that the abbr element’s title attribute was not read out by browsers or screen reader software by default, unless an option within the preferences is turned on.

    If this is the case then the * is not a really good solution, or am I wrong on this scenario?

  • Sojan80

    It’s interesting that you advise the use of the tabindex attribute. I spoke briefly with Derek Featherstone via twitter not long ago about this particular attribute. Derek mentioned that the vast majority of browsers have advanced enough to where tabindex is not as useful as it once was and that most folks often misuse or overuse it.

    I would tend to agree because as long as the fields in your form are logically ordered you can tab through them easily without the need for tabindex. Not to mention if you add in another field somewhere in the middle of the form you have to go back through and readjust the tabindex on all those fields and this can be a pain depending how complicated your form is.

    Many of the other rules you mention are indeed good and one or two are even things I was taught as fundamental stuff, like using explicit labels.

    I do agree though as web developers it is our job tomake the content as accessible as we can.

  • http://www.optimalworks.net/ Craig Buckler

    I’d agree that tabindex is mostly useful if your forms or navigation are not in the order you’d expect on the page, but that’s rare.

    They do have one other useful function: setting a tabindex of zero on an element makes it keyboard navigable, e.g. for custom JavaScript widgets.

  • Skip Wilson

    I know this is heretical to say, but who cares about accessibility?

    Granted, it doesn’t take much work so this isn’t a hill I’d die on, but who is the audience that accessible code services? How big is that audience? What kind of revenue do they represent for the web sites will bills to pay? What’s the opportunity cost of *not* making your site accessible?

    In all cases, I think the answer to these questions is universally ‘miniscule’.

    I’m concerned with making sites with maximum quality, with minimal cost. I do that by focusing my finite (and expensive) development resources on code that serves the majority of my audience, not the microscopic edge case.

  • Jared Smith

    Skip-

    20% of the US population reports some disability. 8.5% of the population has a disability that impacts use of a computer. I doubt you’d build a page that intentionally is unusable for Safari, for instance. Yet you seem perfectly fine with discriminating against a potentially larger audience. This audience also has around $220 billion in discretionary income in the US alone. And guess what, they spend a good share of that online – but only on sites they can access. You may see this as ‘miniscule’, but I see it as a great revenue potential.

    Besides, it’s just the right thing to do. Unfortunately some (apparently including you) are more concerned with ‘audience’, ‘revenue’, and ‘opportunity costs’ than you are with treating others ethically and fairly. With that said, once you understand that accessibility is about people and not about all of these other things, you’ll also find that accessibility is quite inexpensive and easy to implement.

  • Martin Seamus McFly

    @Skip lol, how’s the weather over there in 1998?

  • http://www.sitepoint.com/articlelist/487/ Andrew Tetlaw

    @Skip asks an important question.

    Yes I realise that the sentiment is a little out-of-date, and that the moral imperative of “it’s just the right thing to do” is the right one. But I think it’s important to explain the benefits of building in accessibility from the start, and the cost of ignoring it.

    So let’s hear them, everybody!

    I think it relates back to the debate about web standards and unobtrusive JavaScript – they have the same basis for their approach. You just can’t predict how your web page is being used, what kind of user agent, by whom, and on what sort of device.

    Web standards, unobtrusive JavaScript and accessibility all mean flexibility: it just works all the time and builds no road blocks.

  • http://accessibility.net.nz vavroom

    I tried to post this earlier, but it looks like the post was eaten by cyber goblins ;)

    Skip asks an important question, and one that many people seem to ask.

    As Jared points out, about 20% of the US population has a disability. That average is approximately the same in Canada, Australia, the UK, France, Australia, New Zealand and most “western” English speaking countries. That’s 1 person in 5. As Jared also points out, it’s not everyone with a disability that requires accessibility, yet, it’s still a significant portion.

    Add to that the family and friends of people who’ll go shop at the accessible stores because they want to patronise those who’ve made the (minimal) effort to make their sites disability friendly, and you have a potentially HUGE market.

    Don’t forget that “Google is the largest blind user on the internet”. Improve accessibility and search engines will be better able to index your sites properly. SEO is not, last I heard, a minor concern.

    Oh, there’s also the fact that an accessible site is easier to view on cell phones and handheld devices. Also not such a minor concern.

    And yet another thing that people tend to forget: In many situations, it’s the law. If you, an american based developer, make a site for an american business selling products worldwide, you are at risk of breaching the law wherever the business is selling products!

    I wrote more in depth about this several years ago on Dave Shea’s site. If you are interested, have a read:
    http://www.mezzoblue.com/archives/2003/08/10/accessibilit/

  • http://www.scottradcliff.com ScottRadcliff

    Great point vavroom. I was going to point out that if nothing else, accessibility only helps SEO.

    These are all very easy things to add, and awesome tips for developers that may be overlooking accessibility. In addition to these, creating a shortcut menu with accesskey is real easy to do and a great addition for the ones that navigate with a keyboard.

  • http://accessibility.net.nz vavroom

    @Scott The use of accesskeys is actually NOT recommended in most situations. The idea and concept of accesskeys is very good, but the actual implementation of them means it’s a poor improvement to access, and can in fact be downright trouble. It’s one of the reason they were removed out of the guidelines in WCAG 2.0.

    The problem is that there are really no standard shortcut for the navigation, hence the idea of a shortcut becomes quite useless. The only “system” that seems to be used most is that of the BBC’s, using numeric elements in the AK. But by and large, there’s no standard.

    Add to that the fact that a LOT of keys will interfere either with the regular shortcuts of the browser or the operating system, you end up causing almost more barriers than help. Then there’s the third layer of interferance that screenreader software also have their own set of keyboard shortcuts, and finding the right set of accesskeys for your site is, well… difficult at best.

    I’ve avoided accesskeys like the plague.

  • Skip Wilson

    LOL! The responses to my comments were slightly less religious than I expected, but still didn’t disappoint.

    Jarad – your talk of ‘discrimination’ and ‘the right thing to do’ is as laudable as it is naïve and idealistic. Not coding a web site in a way that makes it accessible to the broadest audience is hardly discrimination. I’m sure there are people that come to our sites who don’t speak English. Are we discriminating against them by not providing a version of the content in their native tongue (e.g. Basque)?

    And ‘the right thing to do?’ That’s a pretty strong black and white ethical statement. It depends on whose yardstick you’re using. My first ethical priority is to the people that work for my company, in particular those who work for and around me. My second ethical priority is to my company as thanks for employing me and helping me provide for my family. My third ethical priority is to the world at large, but I exercise that prerogative by choosing the company I do or don’t work for. I wouldn’t work for a defense contractor. I wouldn’t work for Microsoft. I wouldn’t work for a company that spams or engages in deceptive business practices.

    Like it or not, most web sites represent commercial interests. If I have a team of 5 web developers working for me, that’s at least $350,000 a year in salary and benefits my company has to pay for. That means I need to deliver the highest quality product that serves the most profitable audience as quickly as possible. That means prioritizing the features and quality where it delivers the best return. And yes, as disgusting as it may sound, there is such a thing as ‘opportunity cost’. If we’re diddling around trying to make sure our isht is pixel perfect in every browser for every customer, we’re not working on the next thing that’s going to serve our needs and that of the customer. That is the foundation of truth for any commercially viable site. The happiness and hugs and warm feelings that come from ‘doing the right thing’ are the cherries on top.

    And for the record, no, I don’t care too much about Safari because for most of the large sites I’ve worked for (Yahoo!, WebMD, and JTV.com), Mac users represent less than 3% of our audience (and that’s being generous).

    Speaking of audience…. I love the justification many of you provide. 20% of the population is disabled? Oh wait.. no it’s just a fraction of that whose disability impacts their use of a computer, like 8% right? According to whom? Show me the multiple objective studies funded by someone without an agenda who claims this. Funny…I wonder why the customer service groups of the companies I’ve worked for didn’t get more complaints from the 8 out of 100 people you claim we ‘discriminated’ against.

    SEO friendliness – I hear that – but only so much. Accessible code might help, but not as much as good keyword usage, SEO friendly URLs, good inbound links, and basic semantic HTML.

    Illegal in some cases? Yeah right. *Maybe* if you’re running a government site or one funded by public money, but show me one court case where a web site has been cited for lack of accessibility.

    Works better on mobile devices? There’s something to that I’m sure, but the size of the mobile market right now is fairly tiny, and again, good clean basic semantic HTML will take you pretty far. If anyone wants to dispute the mobile market being small, talk to some of the mobile technology companies struggling for survival right now.

    Again…I’m not saying and was never saying that writing accessible code is some giant burden. It just annoys me that developers get so religious and idealistic about it, pull out unsubstantiated ‘facts’ to prop up their subjective and emotional position, and simultaneously demonize ‘business’ while demonstrating shockingly little insight into the science behind their paycheck.

  • http://www.sitepoint.com/articlelist/487/ Andrew Tetlaw

    @Skip, you could feed a small developing nation for a month on the size of this red herring:

    If we’re diddling around trying to make sure our isht is pixel perfect in every browser for every customer, we’re not working on the next thing that’s going to serve our needs and that of the customer.

    The fact is that for a professional web developer accessibility, standards, compatibility is simply how it’s done, and their services are no more expensive than web developers who don’t care about those things. If you are paying web developers that ignore those issues, you are getting ripped off.

    show me one court case where a web site has been cited for lack of accessibility

    It cost Target 6mil+

  • http://accessibility.net.nz vavroom

    Skip wrote:

    show me one court case where a web site has been cited for lack of accessibility.

    Well, you could look like at the Sydney 2000 Olympics case. Or more recently in the USA you could look at the Target case.

    You’re right, there aren’t many cases listed in case law, simply because most complaints are settled out of court before they ever get to court, hence there’s no “case law”.

    I’m done arguing with you Skip.

  • http://www.visual28.com visual28

    I think that this article though written with good intention is not very accurate. Items like tabindex are not recommended because the break the normal tabbing flow of users. See related article on WebAim: http://www.webaim.org/techniques/keyboard/tabindex.php

  • http://www.sitepoint.com/articlelist/487/ Andrew Tetlaw

    @visual28, I do actually link to the WCAG 2.0 recommendation where it states the same as your WebAim link. Usually the visual order of elements is sufficient. Maybe I should have mentioned that in the article.