The reasons why a user may need accessibility assistance when visiting a website are as diverse as the users themselves. Making sure a website is accessible isn’t just a social (and oftentimes legal) responsibility, it is fundamental for any business or organization that wants to reach as broad an audience as possible. The same logic that drives usability for non-impaired visitors should apply to impaired users – if users can’t experience the intended content then the site may as well not be on the web.
What do we mean by “web accessibility”?
Accessibility is defined by WCAG 2.0, an ISO standard that calls on web pages to follow four principles:
Perceivable – -Does the user know that there is content available and can they be reasonably confident that no information is hidden from the sense they are using to experience the site (vision, hearing, etc).
Operable – Can someone with a disability use the interface and interact with any actionable elements such as buttons and forms?
Understandable – Are the mechanisms for experiencing and interacting with the site obvious to the user, is it reasonably straightforward for them to figure out how the page is organized?
Robust – Users must be able to access the content as technologies advance (as technologies and user agents evolve, the content should remain accessible).
The degree of accessibility is defined by three levels: A(lowest), AA, and AAA(highest).
Proper, semantic markup to meet standards
Fortunately, there is near perfect overlap between proper coding and coding for accessibility. Some of the key practices include:
Proper headings – One h1(though technically you can have more than one), properly nested h2, h3, etc. that actually describe the content
Clear link text – Rather than
<a href=“example.html”>Learn More</a>, either do something like
Learn More <a href=“example.com”>about carrot cake.</a> or use a class with a span like
<a href=“example.com”>Learn More <span class=“sr-only”>About Carrot Cake.</span></a>
Proper table markup – with <th> with the scope of col or row for table headers
Alt tags for images
Forms should use labels for form elements with tab indexes. Modal windows can use tabindex=”-1″ or set focus on the modal.
<ol> and
<ul> for lists of things
Use clickable elements with CSS like a link or button rather than <div> or <span> that is made clickable with javascript.
Use HTML5’s <header>,<nav>,<footer>, and <main> so they can be skipped rather than divs. Combine them with WAI-ARIA roles and properties to help screen readers understand a page.
How do we test for accessibility?
The availability of good online tools makes testing for accessibility fairly easy.
WAVE Toolbar Extension for Chrome or
http://wave.webaim.org/ lets you test for WCAG 2.0 A, or AA, and color contrast. You can validate your markup with a tool available from W3C. And Spectrum Chrome Extension works well to test for color perception to aid users with color blindness.
Web Accessibility Resources
How to Meet WCAG 2.0 w/project filters
Team Treehouse – Two different courses. The Aisha Blake course is an unintimidating intro
UW IT Accessibility Guide
VoiceOver Quick Reference
WAI-ARIA
WAI-ARIA techniques
WCAG 2.0 Guidelines
