DesignDevelopment

Building an Accessible Website

By May 6, 2014 No Comments

At Web Ascender we strive to build websites that everyone can enjoy. I have outlined some of the key components to building a highly accessible website. By following these guidelines even website visitors with disabilities will be able to enjoy your content, products and services.

When I talk about accessibility, I am talking about creating a website or application that can be used by anyone, even someone with a disability. The most common disabilities considered are vision impairment and deafness. The goal of accessible web design in respect to those who may have bad vision or no vision at all is to ensure that the web application can be interacted with using voice commands and that text on the page can be read to the user with a screen reader. For those that are deaf it means that any audio or video content must also be transcribed and have appropriate captions.

Why do you want to make accessible websites?

The biggest reason is that you want everyone to be able to enjoy the content, products and services that you produce. People with disabilities are no different than most of us. They have questions, they want answers and they head to the internet to learn more about the world. They should be able to access and use the same systems that everyone else does and have a right to access the same information.

If you need another reason, then you can read about the specific laws that were created to help ensure this equal right. Typically when accessibility is discussed as it pertains to regulation and compliance, you will here terms such as:

  • Section 508
  • ADA compliance
  • Web Content Accessibility
  • W3C Accessibility Standards

Let’s take a look at some of these in more detail:

Section 508

The Rehabilitation Act of 1973 was amended in 1998 to include an updated section 508.  Section 508 required Federal agencies to make their electronic and information technology accessible to people with disabilities.The overall idea is that systems shouldn’t be created in such a way that makes them unusable to individuals with disabilities such as hearing or vision loss.  Essentially it states that all individuals have equal right and need to access technology.

Americans with Disabilities Act

The Americans with Disabilities Act of 2010 covers many standards that must be complied with in order to meet accessibility standards.  This document contains specifics regarding curbs, ramps and compliance to many technologies and even ATMs.

W3C Accessibility

The Web Accessibility Initiative (WAI) was designed to enable all people with disabilities to be able to participate equally on the web.  It is an initiative from the World Wide Web Consortium (W3C).

 

How do I make a website accessible?

Even though there are different regulations and compliance guidelines, majority of the actions you need to take to make an accessible website are the same.  After you have put yourself in the shoes of someone who is visually impaired or deaf, you can start to design better websites for those with disabilities. The good news is that you can do quite a bit to re-enact how someone with a disability might interact with your website.  If you are on a Mac with OS X, you can enable VoiceOver. This is going to read information on websites and applications to you as you interact with them.  By using VoiceOver, you can see if it is skipping critical information on your site and if it is moving through your content in a logical way.  If it’s skipping around or you are unable to navigate with the keyboard or by tabbing around the site, you may need to reconsider changing some things.  To this day, the most popular screen-reader for Windows is still JAWS.

When inspecting how your site interacts with those that have issues with hearing, it’s a little easier to turn your sound off and use your site to simulate how it would operate for those with hearing loss.  The primary concerns are video and audio components of your site. Can you still use your site and understand your promotional videos without sound?

In both situations you want to make sure that critical information is available on your site in a plain text format that both your visitors and screen-readers can understand.  After you have gone through this process a handful of times you will start to recognize issues before they become issues, and when you enter the testing phase, the amount of changes you are making are at a minimum.

However, like many things here at Web Ascender it is good to follow a process or checklist to ensure you test the right things.  This also helps to instill good habits in new employees who may not be as familiar with accessibility as some of the veteran web developers.

 

The most important elements to website accessibility

The best way to ensure that your website or application is user-friendly for everyone is to go through a checklist. I have outlined an easy to follow list that will catch majority of your website accessibility issues.  You’ll want to review this list before you start your project and also at the end to make sure everything has been reviewed and tested.

Website Accessibility Checklist

  • Website Accessibility Checklist
  • Text equivalent to all non-text media.  This would be achieved using an “alt” or “longdesc” tag.
  • Video productions have synchronized captions.
  • Color is not used to convey important information. For example, you should not use a red background color in a table cell to represent that row item as failed.  If you are going to use color to represent something you must also use text to allow the visitor to read that incase they are colorblind.
  • Provide sufficient contrast between elements. You wouldn’t want to use a black background with grey text. This contrast may not be significant enough for everyone to read.
  • Style sheets are used to format your text and are not critical to the functioning of your product. If the visitor viewed your website with CSS turned off in their web browser the site must still be readable and usable.
  • Data tables use appropriate semantic markup including <th> elements.
  • Frames need to use title tags to be appropriately identified.
  • The site should not flicker or have any repeating rapid movement that might induce a seizure.
  • Be conscious of how you use scripting and javascript to ensure interaction with a screen reader can still trigger necessary elements.  Dynamically hiding or showing content can be an issue if the content is pulled remotely via AJAX.
  • When linking to other media such as PDF and PowerPoint slides those too must be accessible.
  • If you are linking to media that requires a plugin or download, you must provide a link to where that plugin can be found for download.
  • Form fields have descriptive labels and are appropriate markup.
  • A link is provided at the very top of the site to skip over the common navigation structure.
  • Don’t override or have specific auto-focus on form fields as it may interfere with assistive technology.
  • Are you able to interact with your website exclusively with a keyboard, not requiring a mouse for inputs?
  • Do form fields and navigation logically flow when using the “tab” key to move to the next field or item?
  • Avoid linking text such as “click here” because it does not give the user any idea of what content exists beyond that link.

 

How do you test your accessibility?

I mentioned above how you can manually do a lot of accessibility testing.  However, there are also specific tools that have been created to help test majority of the accessibility issues that websites face.  A great website accessibility testing tool is http://wave.webaim.org/.  Web Ascender also has a product that will automatically test your website accessibility monthly.

Chances are your website isn’t going to be 100% which is not always a big deal. The biggest problem with most sites is the lack of “alt” text on images.  It’s helpful for the user to know what images are on your site if they convey a true intent or point. However, many times images are just supplemental to the content and actually do not provide any additional value to the visitor.  So the occasional missing alt tag on an image isn’t the end of the world.

I went ahead and ran a website accessibility test on www.whitehouse.gov to see how it stacked up and was surprised with the results:

  • 15 Errors
  • 13 Contrast Errors

White House Website

However, majority of the errors are not that big of a deal. They are missing alt tags on images that weren’t really providing any context and purpose.  Even with the amount of errors the Whitehouse website had, it still performed pretty well and would be considered “accessible” in my book.

As with the White House website, the WebAIM tool is also going to check and test on more things then what are actually outlined in most compliance documents and even the checklist above.  This tool evolves more rapidly than the laws and legislation to contain realistic elements of accessibility compliance.

Ultimately, remember that your goal isn’t necessarily to be 100%, 0 error compliant.  Your goal is to provide equal opportunity to all to access and use your website.  As long as all the critical content and functionality on the site is easy to access and interact with then it is accessible.

Executive's Guide to Web Development

80 pages of topics and tips to navigate your way to a better website.

Leave a Reply