10 Easy Things All Web Developers Should Do For Web Accessibility

If you don’t know anything about ARIA or web accessibility, or even 508 compliance, but you still want to make it possible for all users to use your website, well, you’ve come to the right place.  We’ll explore ten easy things that all web developers should get used to doing – it’d make the world a better place.

1. Use labels, fieldsets and legends.

This one is simple, but requires some explanation.  When making forms, a big boon to accessibility is to use labels.  Screen readers automatically wire up the text of the label to the element itself, meaning that whenever it reads the input, it will read the label as well.  It’s easy to make the label too:

1
2
3
4
<label for="textbox">Name Of Cat</label>
<input id="textbox" type="text"/>
 
<label><input type="text" required><label>Social Security Number</input></label>
<label for="textbox">Name Of Cat</label>
<input id="textbox" type="text"/>

<label><input type="text" required><label>Social Security Number</input></label>

Just make sure your label’s for attribute is the same as your input’s id attribute.  You can tell if it worked correctly by being able to click on the label text – if it gives focus to the input, you’re in business.  One neat thing about labels is that the text itself is divorced from the presentation – thus, you can have the labels be anywhere in a page, not even near the input tags themselves, and the screen reader should still be able to read the labels when reading the input tags.

All input and  select will work with labels, but not  option .

Now, what about radio fields or a set of check boxes?  This is complex, because each radio field can be related – what’s your favorite color, with radio buttons being black, blue, white, red, for instance.  It would help if the label for all the radio buttons themselves will repeat – remember, that information might get lost in context with someone using a screen reader.

This:

1
2
3
4
<p>What is your favorite color?</p>
<input type="radio" name="color" value="r" id="red"><label for="red">Red</label></input>
<input type="radio" name="color" value="g" id="green"><label for="green">Green</label></input>
<input type="radio" name="color" value="y" id="yellow"><label for="yellow">Yellow</label></input>
<p>What is your favorite color?</p>
<input type="radio" name="color" value="r" id="red"><label for="red">Red</label></input>
<input type="radio" name="color" value="g" id="green"><label for="green">Green</label></input>
<input type="radio" name="color" value="y" id="yellow"><label for="yellow">Yellow</label></input>

will allow the user to jump directly to Red, Green or Yellow.  When a screen reader says it, it will just say “Red” or “Green”.  If a user is able to choose which form field to go to through a menu, it will just say “Red” or “Green”.

Now, compare that result to this:

1
2
3
4
5
6
<fieldset>
<legend>What is your favorite color?</legend>
<input type="radio" name="color" value="r" id="red"><label for="red">Red</label></input>
<input type="radio" name="color" value="g" id="green"><label for="green">Green</label></input>
<input type="radio" name="color" value="y" id="yellow"><label for="yellow">Yellow</label></input>
</fieldset>
<fieldset>
<legend>What is your favorite color?</legend>
<input type="radio" name="color" value="r" id="red"><label for="red">Red</label></input>
<input type="radio" name="color" value="g" id="green"><label for="green">Green</label></input>
<input type="radio" name="color" value="y" id="yellow"><label for="yellow">Yellow</label></input>
</fieldset>

Now the legend of the fieldset will appear nicely along with the other elements, and even better the screen reader will repeat the legend before repeating the label of each input.  ”Red” becomes “What is your favorite color.  Red.” and when you choose it from the menu, you’ll see “What is your favorite color.  Red.” on the menu itself, which is more accessible as the previous approach.

2. Stack your h tags correctly & name them descriptively.

All you need to do is to use your h tags (<h1>, <h2>, <h3>...) in order.  Don’t jump from <h1> to <h6>.  This is important because screen reader users can jump to different sort of headings.  If you have them in a logical order, it makes that sort of navigation much easier to do.

3. Use the HTML5 required attribute or/and ARIA required attribute.

HTML5 has a new attribute called “required”, which means that a field is required.  This obviously helps alert the user that this field is required and they need it.

1
<input type="text" required><label>Social Security Number</label></input>
<input type="text" required><label>Social Security Number</label></input>

Most screen readers can understand this and will alert the user that the field is required.  Much more accessible than having an asterisk in front of the input’s label.

There are some cases in which you may not want to use the HTML5 required attribute – for instance, Firefox will add a style for inputs with that element, which might break your page.  Or maybe you want to cover your bases, because there are some screen readers that don’t understand the HTML5 required attribute.  In that case, use the aria-required attribute.

1
<input type="text" aria-required="true"><label>Social Security Number</label></input>
<input type="text" aria-required="true"><label>Social Security Number</label></input>

One big thing to remember is that aria-required attribute requires an input of some kind in order for it to be valid.  I generally use “true” because it makes sense.

4. Don’t touch the tab index, order your markup – or if you do need to use tab index, use it smartly.

Days of handling tab index have gotten much better.  I remember on one of my first websites, I had about 100 elements on the screen at one time.  I wanted to make the tab order consistent, so I set the tab index in order from 1 – 100 on each of these elements.  Whenever I had to add a new element, yep, I had to rewrite the tab order.

Now, a screen reader or keyboard user will mostly likely tab through depending on the source. So, you’re tabs can still get dolefully out of order if you’re doing crazy HTML/CSS stuff.  If this is the case, I urge you for anyone who might inherit your code to simplify and re order through the source  as opposed to slapping a tabindex on there.

Or, perhaps, at least using the tab index using the tab index smartly.  What tab index allows you to do is set tabbing priority.  However, it’s actually by group.  Tab Index 0 is the default “group” – it’s essentially by source.  Leaving out the tabindex in tabbable elements will automatically put them in group 0.  What if you wanted to add priority to a set of form fields so that they come before the group?  Use tabindex=1.  So forth and so one.  After the first group is done with in the tab index, it’ll move back to 0 or go to group 2.  Tabbing within the group itself is done in source order, so you might have to do some reorganization.

By using tabindex this way, you can both use the power of tabindex, as well as make your code a bit easier to follow and understand.

5. Use Fangs

You may not have time to use or even learn how to use a screen reader, but I bet you do have time to use Fangs.  Fangs is an add on for Firefox that will generate a text representation of what a screen reader might read out when it’s at your site.  It’s an invaluable tool, and incredibly simple to use.

6. Go through the site with just your keyboard

If you don’t even have the time to go through Fangs, at least check on your keyboard accessibility.  Sit at your desk, and go through your website like a regular user, and see if you can accomplish basic tasks without using a mouse.  For instance, if I was checking this blog, I’d be sure I am able to visit a post, comment on a post, be able to visit a page archive, be able to see if I can go and visit a link within the post without touching the mouse at least once.

This is important because screen reader users operate the screen reader and the screen reader cursors with just a keyboard.  If you can’t navigate your site with just a keyboard, then how can they?

7. Use the role attribute, especially for links and buttons or the HTML5 sectioning tags.

The ARIA role attribute allows you to dictate what an element is – is it navigation?  Your main content?  Here are the ones that you should know well.  I should also note that some roles have html5 “landmark” elements.  If you use these, you don’t need the ARIA role.  This is because of ARIA’s goal of filling in semantic information for an element that may not be used for it’s semantic purpose.

  • role=link (use when you have an outgoing link.  Or just use <a href>)
  • role=button (use when you have a link that doesn’t go anywhere (like <a href="#">).  Or just use  the <button> and attach a click handler to it)
  • role=banner (use when you have your site’s name in huge letters at the top of the page.  You might be able to use the HTML5 <header> tag )
  • role=navigation (use for links that allow you to visit pages within the site itself.  Or use the HTML5 <nav> tag)
  • role=main (use for the actual main content of the page.)
  • role=complementary (use for sidebars, advertisements on the side, anything on the page that can be removed without removing the specific purpose of the page.  You can use the HTML5 <section> tag too.)
  • role=form (use for…well, forms!  You can also use the <form> tag)*
  • role=search(use for a search form on the page.)
  • role=contentinfo (use for a section that describes the content itself.  For instance, on an image viewing website like Flickr, this would be the section that contains the size of the image, what camera it was taken on, where it was taken, etc.)
  • role=region (any specific specialized section of the page that don’t really go into the above seven.)

The last seven on this list are landmark tags, meaning that they make navigation of the page on a screen reader so much easier, because they can jump to specific landmarks. They don’t need to know you named your search form something crazy – your search form is the search landmark, so they can just jump there.

*- this illustrates a great point about ARIA.  Some AJAX forms have their forms within <div> tags.  In that case, you would need use role=form.  If the AJAX forms were not within <div> tags, then you wouldn’t need to use that aria role.

8. Use Javascript when appropriate

Javascript is not accessible.  Don’t use special Javascript to determine that a form is required or not.  A data attribute won’t help you here.  Whenever you have the option of doing something Javascript-y to solve an accessibility problem, always check to make sure that ARIA or even simple HTML doesn’t solve it first.

 

(Changed 12/28/2012): Javascript can be accessible, and generally is a useful tool for web accessibility (focus managing, dynamic ARIA, etc.).  However, there are times in which it’s not the right tool for the job.  Don’t use client side validation that keeps tabs on which fields are required, disabled or invalid in only the script itself – this isn’t very accessible, and really not good usability for the disabled user using a screen reader either.  Another example is hiding elements from form readers, despite the fact that it’s trivial to do in CSS. It just adds more complexity to the product, and introduces possible over-engineering the issue.

I recommend that when you come across an accessibility issue, make sure that there isn’t some ARIA attribute, HTML  markup or CSS that will fix the issue before using Javascript, because often the first three might have more simpler solutions to the issue.  Sometimes you just need a corkscrew, not a swiss army knife.

9. Use the alt attribute where appropriate.

This is important, and one I already talked about a lot, so I’m going to copy and paste what I’ve said:

You shouldn’t have alt text for all images, but you SHOULD for all images that are relevant to your content.  If you turn images off, and a piece of content doesn’t make any sense without the image, then add alt text for that image.  Then do that until your content makes sense.  If you relay status of something through an image, you should use an alt text there – but only if it’s information pertinent to the content of the page.

Finally, you also have to write good alt text.  Don’t write what the image is (“red dot”, “a stop sign”, “a fancy clock with golden hands and blue numerals”).  Describe what the image relays or represents (“The build failed”, “Don’t do this”, “It is 7:01 pm”).

I’ll be writing more about this later, since I think a lot of developers misunderstand this one.

10.Make sure your site is accessible for the common person.

Lastly, if your site is just not plain usable, it won’t be accessible.  Make sure your site is usable.  Show it to other people and see if they can use your website.  If it’s not, then how can you ever make it accessible?

Take the archtypical MySpace page.  You usually have some flashy background, hard to read text, and even worse, music playing loudly.  It’d be a very long page that would require scrolling through hundreds of pictures (many with alt tags!) just to get to that person’s Wall, or whatever it was called in MySpace days. That’s not useable for anyone.

Is there any hope of getting that archtypical MySpace page working for users that require special accessibility tools like a screen reader?  No, and I wouldn’t even consider doing it without massive revamping.

If your site is not usable, there’s no chance of it in being accessible. These concepts go hand in hand.  The reason why Apple is popular among both the disabled and the abled is due to the fact they produce accessible software – this goes hand in hand with usability.  While I’m not a huge fan of Apple’s software, I do recognize how goddamn usable it is.

Compare the accessibility in iOS to something like Windows 8.  While I do like Windows 8, it’s not very useable at first and requires a pretty major learning curve in order to get it to be useable.  It’s also not very accessible.  

There you go.  That was 10 things that all web developers can do to make sure they’re work is accessible.  Easy right?  And you only had to learn just a little bit of ARIA.  I think I’m going to quit harping on the alt text point, and my next article will be about the basics of ARIA and useful ARIA attributes.

EDITS on 12/28/2012: Fixed some code examples that didn’t work due to haste.  Rewrote section 8 to make the point that Javascript is accessible, but sometimes it may not be the right tool for the job.

24 comments on “10 Easy Things All Web Developers Should Do For Web Accessibility

  1. In your #1, the and tags are reversed – the label element should encompass the input element, not the other way around.

  2. Oops, I see that this comment field strips HTML :)

    My comment above should be:

    “In your #1, the <label> and <input> tags are reversed – the label element should encompass the input element, not the other way around.”

  3. “What is your favourite color?” — radio buttons are grouped by having the same name attribute. Your radio buttons have different name attributes, and no value. So you could select every colour as your favourite. They should have the same name attributes, and different value attributes.

    If you intended the user to be able to select multiple colours as their favourite, then you should be using checkboxes not radio-buttons. As in, use the right UI element to express the constraints.

  4. I’m disabled and I’m not feeling a whole lot of love here. My disability is that my hands are broken and I need to use speech recognition. fundamentally, most of the accessibility features developed for accessibility interfaces are usually wrong because they are written by people who don’t live the life of a disabled person.

    Maybe a better solution would be to allow an accessibility interface access to the internals of an application and be able to provide a really useful aural or speech driven interface.

  5. Good points, everyone. I think I was being too harsh (generalizing?) when saying that Javascript is not accessible – you are correct, it can be – however, I still think that there are better ways of handling that accessible. I might just rewrite that section.

    Also, thanks for catching my mistakes on the code examples.

    Speaker – just out of curiosity, in case you see this, what do you for speech recognition?

  6. Pingback: Tyler Merrick

  7. Pingback: Tweet Parade (no. 52 Dec 2012) | gonzoblog

  8. Pingback: Remembering to use ARIA roles - northern div

  9. Pingback: Web | Annotary

  10. Thanks for the good (easy to understand) article, Lane! In the past, I’ve tried to incorporate accessibility in my sites using some of the methods you’ve mentioned, but others I hadn’t heard of yet before. I look forward to making my sites more usable for all in the future.

  11. Pingback: 10 Easy Things All Web Developers Should Do For Web Accessibility – Links - Marcus Kazmierczak

  12. Pingback: 10 Easy Things All Web Developers Should Do For Web Accessibility | ebeab

  13. Pingback: Accessibility Related Reading List – March 6 2013 | Recreate Web

  14. Pingback: Accessibility Related Reading List – March 7 2013 | Recreate Web

  15. Pingback: Tweet Heat - The hottest Tweets of the Month [Dec 2012] • Inspired Magazine

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code lang=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" extra="">