Skip to content

Instantly share code, notes, and snippets.

@davatron5000
Created January 18, 2013 01:43
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save davatron5000/4561610 to your computer and use it in GitHub Desktop.
Save davatron5000/4561610 to your computer and use it in GitHub Desktop.
layout title description categories
post
How-to: Future proof your accessibility efforts.
Ways to make your accessibility effort as future proof as possible.
How-tos

Adapting good accessibility on a web site may add additional cost to the development, so it's important that you future proof your efforts as much as possible. Doing this will help support current and future user agents, such as assistive technologies. WCAG 2.0 recommendation 4.1: Compatible includes two sections, Parsing and Name, role, value, that specifies how to easily accomplish this without adding too much extra work.

The main goal with the Parsing criterion is to ensure that user agents and assistive technologies are able to read and navigate your web site correctly. This is easily achieved when following the official specifications for the markup language you choose to use. E.g. making sure to close open tags (<div class="a-class">...</div>) and using unique IDs. Validating your web pages with a tool like The W3C Markup Validator can take you a long way when trying to find problems and errors in your markup.

Name, role, value on the other hand, are mainly aimed at developers that design and/or script their own interface components and controls. This is because all standard HTML controls already meet this criterion, if used following the specification. It's recommended that you read up on this guideline if you are working with a lot of custom designed or scripted interface components.

While these are only two recommendations to make your site more accessible, it should have a good spot in every web developers workflow. Use of checklists, like the one we have composed here on The Accessibility Project, can help keeping the task under control.

(If you are looking for more information on this subject, the articles Understanding Success Criteria 4.1.1: Parsing and Understanding Success Criteria 4.1.2: Name, role, value are good places to start.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment