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.
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 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
- Adobe Flash Accessibility: Best Practices for Design
- 10 Tools for Evaluating Web Design Accessibility
- 14 Brilliant Tools for Evaluating Your Design’s Colors
- Related categories: Usability/Accessibility and User Interface