10 Simple Web Accessibility Tips You Can Do Today

Dec 3 2009 by Jacob Gube | 36 Comments

One of the most overlooked aspects in designing a website that we often brush off is web accessibility. There’s a misconception that web accessibility requires sacrifices to aesthetics, or that it’s not worth the effort.

Image with text that says Web Accessibility Tips

But, with a growing number of ways that users access the web, creating highly-accessible and universal designs that can be viewed in as many ways as possible is critical to the success of a website.

And here’s the good news: it isn’t as hard as you think.

Most web accessibility guidelines already go hand-in-hand with website development practices. In this article, we’ll explore 10 quick and easy ways to improve your site’s accessibility.

1. Use meaningful title attributes

Think of title attributes as short summaries that describe where the hyperlink will take the user who clicks on it.

It doesn’t help if the title attribute is the same as the link text, such as in the following example:

<a href="portfolio.html" title="Portfolio">Portfolio</a>

Why is that? Because for screen reader users, it’s redundant and gives them no added value.

In the above example, even though web accessibility and Section 508 validators won’t let you pass their automated tests without it, it’s actually better to leave out the title attribute.

A better title attribute to the example above is:

<a href=" portfolio.html" title="Some artwork of the artist">Portfolio</a>

2. Place important interactive elements higher up the web page

Here’s a simple web accessibility exercise for you: identify important hyperlinks and user interface controls that your users need access in one of your web pages. Then count how many times you have to press the Tab key to get to it.

Did you get to it fast enough? Or did you have to press the Tab key like crazy? Were you able to see which hyperlink of interface control was currently focused on when you pressed the Tab key?

Now imagine yourself in the situation where you can’t use a conventional point-to-interact device like a mouse; a situation where, in order to get to a desired interactive element, you have to traverse the ones the come before it on the web page. This gives you a partial picture how people who have limited or no hand functions interface with a web page.

Easy enough: place important links and other interactive elements higher up your web pages. It’s good practice anyways since most website users, regardless of physical or mental ability, expect important items closer to the top of a web page.

3. Don’t begin title attributes with the same text

You’ll often see hyperlink elements with title attributes that look like this:

<a href="/" title="Link to home">Home</a>
<a href="/products" title="Link to products">Products</a>
<a href="/contact" title="Link to contact">Contact</a>

This can be a result of default content management system configurations, or someone who did not want to take too much time with title attributes.

Users who use screen readers such as JAWS often rely on title attributes to find web links on a page. JAWS, for instance, has a feature for pulling together a list of links on a web page sorted in alphabetical order. If title attributes begin with the same text, it’s harder to use search functions that are built into screen readers.

4. Use headings correctly

Heading tags allow screen reader users to jump to the sections they’re interested in. Headings on a web page is an outline of the web page; using an <h2> right after an <h1> element denotes a section that is a subsection of the preceding <h1>.

Many of us neglect headings, including me. In every single instance where I’ve misused heading elements, I couldn’t find a reasonable explanation for doing so – and neither will you.

This simple web accessibility guideline can do wonders for people with vision deficiencies that use screen-reading technology.

Breaking up a long web page into logical subsections with headings makes it easier to get to your location of interest. Imagine that while reading the first paragraph of an article, that you immediately wanted to leave a comment, and the comment form is located somewhere at the bottom of a web page. For sighted users, this would be a snap: you just need to scroll down and visually locate the web form.

But on content-heavy sites such as the one you’re viewing now, the comment form is actually somewhere in the middle of the HTML structure even though visually, it’s right at the bottom of the web page. Without section headings that indicate where the web form begins, screen reader users would have to wade through a lot of content in order to get to the form. On Six Revisions, the level 3 heading "Leave a Comment" will allow screen reader users to quickly jump to it.

5. Use distinct and meaningful page titles

The first thing a screen reader user will encounter right after the web page fully loads is the text in between your <title> tags. The worst thing you can do, aside from not having the <title> tag, is having them all the same in all of your web pages. This makes it difficult for users who rely on your HTML markup to determine what page they’re on, or if the link they clicked on is the same web page they were previously on or not.

If your page titles are the same, or if you don’t have page titles, screen reader users will always have to read the content before determining that they’re on web page they want to be on. Keep page titles succinct and meaningful.

Good page titles to use that include repeating text are:

<head>
  <title>About Us - Six Revisions</title>
</head>
<head>
  <title>All Articles: Six Revisions</title>
</head>
<head>
  <title>Six Revisions: Home</title>
</head>

6. Use skip navigation

Screen reader users have to read HTML documents from top to bottom, without the ability to scan the web page for the information they’re interested in.

Skip navigation allows screen reader users and persons who can’t use a mouse to skip long lists of links, such as the primary navigation on a website.

Skip navigation is simply a link right at the top of your web page that, when clicked, positions you to the content section. You can hide this link from able-bodied users by moving the link outside of the browser viewport using CSS.

Here’s an example: let’s say that you have the HTML structure below and you want to have a skip nav that positions the reader on the main content area (div#content).

<ul id="nav">
  <li><a href="home.html" title="">Home</a></li>
  <li><a href="about.html" title="">About</a></li>
  <li><a href="blog.html" title="">Blog</a></li>
  <li><a href="portfolio.html" title="">Portfolio</a></li>
  <li><a href="contact.html" title="">Contact</a></li>
</ul>
<div id="leftCol">
  <h1>My friends</h1>
  <ul>  
    <li><a href="http://blogofafriend.com/" title="">Blog of a friend</a></li>
    <li><a href="ttp://friendofablog.com/" title="">Friend of a blog</a></li>
  </ul>
</div>
<div id="#content">
  <h1>Page  Title</h1>
  ...
</div>

You would place your skip navigation link right above your unordered list, like so:

<a id="skipnav" href="#content" title="Jump to content">Skip Navigation</a>
<ul id="nav">
  <li><a href="home.html" title="">Home</a></li>
  <li><a href="about.html" title="">About</a></li>
  <li><a href="blog.html" title="">Blog</a></li>
  <li><a href="portfolio.html" title="">Portfolio</a></li>
  <li><a href="contact.html" title="">Contact</a></li>
</ul>
<div id="leftCol">
  <h1>My friends</h1>
  <ul>  
    <li><a href="http://blogofafriend.com/" title="">Blog of a friend</a></li>
    <li><a href="ttp://friendofablog.com/" title="">Friend of a blog</a></li>
  </ul>
</div>
<div id="#content">
  <h1>Page  Title</h1>
  ...
</div>

Some sites decide to keep the skip navigation link visible, but if you’d rather hide it from sighted users, you can use CSS to indent the link outside of the web browser viewport:

#skipnav {
  position:absolute; 
  top:-10000px;
}

The downside of the above technique is that, although it will work for screen reader users, it won’t help users who can’t use a mouse since they won’t be able to use the Tab key to navigate to the skip navigation link. An improvement to the method above can be found on WebAIM: Links that become visible with keyboard focus.

Skip navigation is easy to implement, but very useful to have in web pages with a lot of content above the primary content area.

WebAIM has a very thorough discussion of skip navigation that includes several techniques (and their pro’s and con’s) that you should read.

7. Label your form elements

HTML web forms are the primary way of interacting with a website. Because of the importance of web forms, making sure that you use correct markup is crucial for universal design.

Label your input elements with meaningful and descriptive text. This makes it clear to the user what information they should be providing.

<label for="searchbox">Enter key words to search:</label>
<input id="searchbox" name="searchbox" type="text" />

With CSS, you can style that label element into an icon or hide it from plain view by pushing it out of the browser viewport, if you really must.

8. Test your web pages with CSS and JavaScript disabled

One of the simplest ways to determine how access-friendly a website is to users that can’t see content in a computer monitor, is to turn off CSS and JavaScript. Why?

With CSS, we can position elements wherever we want, regardless of where they are in the actual document object model.

With JavaScript, we can manipulate page elements by hiding, removing, and showing them, based on a user’s action.

Disabling these two web technologies allows you to see whether or not all of your web page content is accessible. It also shows you whether your web pages are organized in an optimum manner.

9. "See" what it’s like to use assistive technologies

Perhaps the best way to fully understand universal design on the web is to see an actual person use a website with assistive technologies. If you don’t know of a person with a form of disability that affects their ability to use the web, there are many simulators online that will help you at least get a partial picture of how assistive technologies render and interface with a website.

For screen reader simulations, try out WebAnywhere, a web tool created through a collaboration between University of Michigan and University of Rochester. If you want to feel how it’s like to be blind and interacting with a website: memorize a few keyboard shortcut keys the WebAnywhere uses. Navigate to your site using WebAnywhere. Turn off your monitor and unplug your mouse. Finally, try to read and interact with the web page you’re on.

To see if the colors you’ve chosen are universally accessible to individuals with vision impairments, check out the list of tools for evaluating colors I’ve put together a while back.

Additionally, there are many tools out there that will help you validate your work against common web accessibility standards and guidelines. There are many of them, and most of the good ones are free. See the article: 10 Tools for Evaluating Web Design Accessibility.

10. Web accessibility is not about degrading the overall user experience

The final tip I’d like to share is more of a philosophical viewpoint to designing with web accessibility in mind.

Many of us think that reaching a high level of web accessibility means that it’s at the cost of the general/average user experience. It’s not. It’s about offering multiple access points with varying levels of complexity.

I learned this lesson while looking at all-inclusive playground equipment.

I noticed that it’s not about lowering the difficulty of obstacles in a playground equipment (such as the one featured below), but that it’s about giving several point of access with varying levels of difficulty.

Study the Jungle Jim below that provides its users several points of access.

Photo of an accessible playground equipment.Photo from APE

There are several potential points of access to the play equipment. Able-bodied children who want a higher level of challenge can use the more difficult routes, while children with mobility impairments can use the access route.

What’s the implication of this concept to web design?

It means that it’s not about not using Flash content because of it’s notoriety for being inaccessible, it’s about making sure that users that have difficulty interacting with Flash content have an alternative way of getting the same information.

It’s not about not using Ajax because screen readers can’t parse asynchronous DOM manipulation by client-side scripts (e.g. content changes without a page reload), it’s about providing an explanation to the user that the page will update upon performing a certain action and they may not see it, or offering an alternative experience for them (just like the Jungle Jim).

Keeping in mind these tips will ensure at least partial access to your websites and webapps. If there’s one thing you should take away from reading this, it’s that web accessibility isn’t that hard to integrate with your processes, and most, if not all of these tips, should already be a part of your web design and web development best practices.

Recommended Reading

There are many methods involved in making websites universally-accessible, with varying levels of difficulty for integration. I’ve just touched on a few of them. Even if you take just a few hours of your time today to read the following resources, I promise you that you’ll learn a lot about web accessibility.

Introduction to Web Accessibility

The W3C Web Accessibility Initiative group has an introductory level document for those who want to learn about web accessibility, but don’t know where to start.

WebAIM

WebAIM (Web Accessibility In Mind) promotes universal design on the web and has plenty of articles on web accessibility; just studying the site’s design and HTML/CSS source code can give you an idea of what a web accessible site is.

Dive Into Accessibility

This online book was designed as a 30-day course that educates its readers about one accessibility technique per day, but you can read it all in one sitting, and an average reader can probably get through it in about a few hours.

How People with Disabilities Use the Web

A document on W3C that gives readers an overview of how persons with handicaps use the web.

Related Content

About the Author

Jacob Gube is the Founder and Chief Editor of Six Revisions. He’s also a web developer/designer who specializes in front-end development (JavaScript, HTML, CSS) and PHP development. If you’d like to connect with him, head on over to the contact page and follow him on Twitter: @sixrevisions.

36 Comments

Selinap

December 4th, 2009

Idea #2 is pretty hard to implement. In my opinion, the level importance of items is very immanent. It may be important to person A, but, not for person B. For example, we might want the ads to be at the top, but is that what the user want to see first?

Brad Davis

December 4th, 2009

Nice article Jacob, I like the info about the skip nav, something for me to check a little more over the weekend.

Eric B.

December 4th, 2009

Excellent tips. Accessibility is a commonly overlooked aspect of web design.

Another way to improve accessibility a bit is to use tabindex on form fields, so that they can be tabbed through in a logical order.

Senthil Ramesh

December 4th, 2009

Simply rocks. I must admit that I have not read any such tips recently.

Katie Dixon

December 4th, 2009

Excellent tips! I’d never heard of #7 (the “for” part), but I will certainly use it in the future. Thanks!

Andy

December 4th, 2009

Re. point 8 – disabling CSS & JS is a good idea when testing, but it’s a misconception that disabling JS somehow gives you an idea of how a user of assistive technology will use the page. Most screen readers today interpret javascript, and a sighted keyboard-only user will most likely have javascript enabled too. So, you have to make sure *all* your functionality – including all javascript events and AJAX – are accessible for screen readers and keyboard users. I’m afraid disabling javascript isn’t going to give you the full picture of your site’s accessibility, and unfortunately it’s a misconception that’s still prevalent.

hadean

December 4th, 2009

Enter key words to search:
<< u know that the for-attribute is relating to the ID of an Form Element?
Im relating to http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_forms .

Louis

December 4th, 2009

Nice article, Jacob. Especially liked the recommended reading links. I hadn’t seen a few of those before.

Ian

December 4th, 2009

7: the label’s for attribute is related to the input’s id, not the name. You have to name the id of the input the same as the for attribute. If users click on the label, the right input will get the focus. Good post for the rest :-)

Adam Wood

December 4th, 2009

When I was a teacher I would periodically go to workshops about making your classroom/curriculum/teaching better for special needs kids- whether gifted and talented or learning disabled. I was always struck by the fact that the recommendations were things which actually were better for “regular” kids as well.

This excellent list feels the same way. Just about everything you talk about will improve accessibility and usability for “regular” visitors as well. Also, a few good SEO practices are in there too.

Great job!

Nico

December 4th, 2009

Great article, we have purchased a copy of the IBM Screen reader software to ensure that the code we develop is accessible, and all this accessibility comes at a small cost to development time, to be exact 1% of the total development time of a site.

Note: LOL… great to see your human. In your code above you forgot to close your title tag… Skip Navigation it should read… Skip Navigation

Andy

December 4th, 2009

@Eric B. ‘Another way to improve accessibility a bit is to use tabindex on form fields’

Tabindex is best avoided. If your form fields are in a logical order in the source, then keyboard & screen reader users will naturally tab/move to the next field. Start using tabindex and you can potentially disrupt the natural flow through the document, and give yourself a world of pain if you ever decide to add new elements/fields, and are faced with revising all the tabindex values…

Web Axe

December 4th, 2009

Cheers on #1! “Redundant title attributes” are a pet peeve of mine. Also, I too recommend skip to links, but soon won’t be needed with implementation of ARIA and proper headings.

Jared Smith

December 4th, 2009

+1 to Andy – avoid tabindex. Instead, structure your page and forms so the default tab order is logical.

In regards to #1 and #3, the title attribute is VERY rarely read on links. Screen readers have an setting to read the screen text (the blue underlined text inside the link), the title attribute, or the longer of these two. The default is screen text and I’ve only very rarely seen users change this so that the title attribute is read. So, while it’s OK to use title attribute to provide additional advisory information (that’s what the HTML spec says title is for), do not rely on it for accessibility and don’t count on it ever being seen or ready by a screen reader.

Russell Heimlich

December 4th, 2009

It is worth mentioning that most screen readers don’t read title attributes by default. That has to be turned on manually. Tip #1 is misguided as screen readers would read the contents of the <a> tag. People with disabilities aren’t stupid, they know what a portfolio is so your title attribute isn’t really any more helpful.

If you were on a site about animals wouldn’t this look silly:
bear ?

vimal

December 4th, 2009

Nice article. I like the skip navigation idea and headers. Useful article

Adam

December 5th, 2009

This article is quite useful. I liked how you related the article to a jungle jim :)

Sebastiaan Stok

December 5th, 2009

About point 8: Its better to first specify the title of ‘the page’ and then the website name.

This is also better for search engines to, since they only read the first 30 characters. And when bookmarking, the title is truncated as well.
So ‘Sixrevisions: 10 Simple Web Accessibility Tips You Can Do Today’ will become ‘Sixrevisions: 10 Simple Web …’

Using an title that from the beginning is always the same is pad practice.

Good article.

Jules

December 7th, 2009

Re: #5

I recommend having the page description before the site name (such as About Us: Six Revisions) so that if the page description is long, more of it is visible on a search engine page than if the page description followed the site name.

esteban

December 7th, 2009

i really like it. Sorry for my lenguaje but im from Argentina. I always check de blog its very interesting, its in my fedd right now. congratulations!

Poakpong

December 8th, 2009

Great article, Thanks for share.

dev0347

December 8th, 2009

Some excellent points raised.

Perhaps, though, the very simplest thing that you can do to improve accessibility is to avoid the use of justified text. That will benefit all users with dyslexia and other similar learning difficulties, as well as those who use screen readers.

See: RNIB site

SMA

December 8th, 2009

nice article… will try your tips it the weekend.

Jamie

December 8th, 2009

Not a bad article, but not quite correct either. Using meaningful title attributes on links is not a point of Section 508, nor is it required for WCAG. Title links should only be used when the link itself is not clear when read in context. Link text _should_ be descriptive, but even the ubiquitous “click here” is acceptable if the context makes sense. It is still poor practice to use “click here” though.

Disabling CSS and JavaScript is also unnecessary. Newer screen readers do take these elements of a page into consideration and many will properly execute JS. The problem is that many screen readers do _not_ notify the user that the page has changed. As such, it is important to recognize that JS should also be accessible. For instance, lightboxes are quite popular these days, but most append the code to the bottom of the page. A person using a screen reader may click on your image / link which creates a lightbox, but they have no idea that anything has happened. Better to pass focus to the new element and return focus to the correct place when the user closes the lightbox.

Accessibility is a journey, not a destination. With over a decade of web development and three years of accessibility experience in a Federal agency, even I learn new techniques all the time.

Jamie

December 8th, 2009

An ammendment to my above statement on disabling JS and CSS… it is still a good idea to check your site without them, but don’t assume that people with accessibility tools won’t have access to them. Your site should be accessible either way.

Mark Carter

December 9th, 2009

Very nice summary of very practical steps …. thanks for sharing this on accessibility.

Rhyno

December 9th, 2009

Excellent article. It is difficult for some web developers and designers to believe in accessibility, often thinking it is a huge cost with little payoff. I like to compare it to having a bricks-and-mortar business with a ladder to get into the front door. Sure – most people can still get in. But would you really do that and turn away business because you thought an accessible front door costs too much or didn’t look as interesting?

Charles

December 10th, 2009

That’s really wow I say because this would be a source of getting inspiration and that is all what is required to start the things, thank you.

Savannah W

December 11th, 2009

The most valuable part of this post (thank you for mentioning it) is the “skip navigation” – So often overlooked, and if any of your visitors use screen readers, it’s very useful.

Don’t know if your visitors use screen readers? Take a look at your analytics reports and peek at the user agents. Don’t know what to look for? Google is your friend!

devolved

December 11th, 2009

Not sure why but every article on accessibility immediately starts to talk as if it’s a disability issue …

it isn’t

Accessiblity is about making your content *accessible* to the widest possible audience so #1 should really be THINK.

Big images, no ie6 support, poor colour/contrast use, lack of suitable indications that things are links …

These are real issues, not just the product of lazy mark up.

Jacob Gube

December 11th, 2009

@devolved: That’s strange, because the second paragraph says:

But, with a growing number of ways that users access the web, creating highly-accessible and universal designs that can be viewed in as many ways as possible is critical to the success of a website.

I didn’t open up with “web accessibility is only a disability issue”.

cancel bubble

March 18th, 2010

To piggyback on those commenting on screenreaders and JavaScript, 10% have it disabled according to an October, 2009 WebAIM survey (http://webaim.org/projects/screenreadersurvey2/#javascript)

Also, here’s a good article, “Easy Accessibility Testing with the NVDA Screen Reader”. NVDA is free but only available on the Windows platform, I think.

http://developer.yahoo.net/blog/archives/2009/12/easy_accessibility_testing_with_the_nvda_screen_reader.html

Vincent

June 16th, 2010

Cool article, Jacob. I’m really interested about this kind of articles. Accessibilty is a very important thing, and everyone should know at least the basics.

Thanks for sharing

Arun

June 16th, 2010

thanks Jacob, tahnks So much sharing it:)

Prakash

September 6th, 2011

Very Simple summary of very practical steps. Good Job.

sorol say

December 10th, 2011

Very nice article, Jacob. I’m really interested about this kind of articles

Leave a Comment

Subscribe to the comments on this article.