Communication is a fundamental social process, a basic human need and the foundation of all social organization. It is central to the Information Society. Everyone, everywhere should have the opportunity to participate and no one should be excluded from the benefits the Information Society offers.
— Geneva Declaration of Principles, United Nations World Summit on the Information Society
The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.
— Tim Berners-Lee, Inventor of the World Wide Web
What is web accessibility?
Web accessibility is the practice of making web content accessible and usable for people with disabilities.
Who needs accessibility?
Another way to put this question is: Who is disabled?
Since the web is primarily a visual medium, many people only think of blind users. However, a number of physical and cognitive impairments can create barriers to access.
Low-vision users may not be able to read text that is too small, or which has a low contrast ratio with its background.
Dyslexic users may have trouble with text that is too small or poorly typeset.
Color blind users may not be able to distinguish hyperlinks from surrounding text based on color alone, or interact with color-coded interfaces.
Deaf and hard-of-hearing users may not be able to hear or understand audio content, including speech (video, podcasts) or audio cues (alarms, bells).
Users with mobility or motor issues may not use a mouse to navigate onscreen content — they might use a keyboard, a single button, or an eye-tracking device.
In addition to users with long-term or permanent disabilities, many people experience periods of reduced ability. For example, someone with a broken arm may not be able to use a mouse.
Temporarily disabled users present a special hurdle. People with lifelong disabilities have often learned to use assistive technologies, developing strategies for handling online tasks. Users with new or temporary disabilities may not have the skills needed to compensate.
Elderly users also frequently experience difficulties with vision, hearing, and dexterity. Text size and color contrast are especially important issues for the aging. Older users also frequently do not have the tools or skills to compensate for their impairments.
It is difficult to say with certainty how many people have disabilities which hinder typical access to web content. The most frequently cited estimate is 20% (one in five).
Understanding Web Accessibility Needs
The foundation of effective accessibility practices is empathy. To design an accessible experience, you need to understand how users with disabilities are going to actually interact with your content.
Try It Out
One of the most profound things that you can do to understand the needs of disabled users is to actually try to use the web the way they do.
Try to navigate your website without a mouse.
Close your eyes interact with your content using a screen reader.
Look at your content in a text only browser.
Fill out a form using only your keyboard.
Resize the text or change the display font on a website.
Wear sunglasses or sit away from your monitor to approximate low-vision or reduced color clarity.
Use apps that simulate color blindness.
None of these practices will make you fully aware of accessibility issues, but they will make many of the most common problems immediately obvious.
Talk to People with Disabilities
There is no substitute for including a variety of people with a variety of disabilities into your design and review process. This isn’t feasible for every blogger and independent publisher, of course. But, if you are doing any sort of user testing at all, your user testing should include disabled people using web assistive technologies.
Basic Best Practices for Web Accessibility
There are a number of basic design decisions that can be made which will eliminate or greatly reduce the most common barriers to usability. More can always be done, but these will make a big difference.
Good alt Descriptions
You already know that you should add alt descriptions to your images. But are you writing good, helpfulalt descriptions?
Describe the image, without reference to the image.
Bad: A picture of George Washington.
Better: George Washington
Provide a description of the content, not just a title.
OK: George Washington
Better: George Washington, in his army uniform, standing in the snow at Valley Forge, surrounded by soldiers.
Mention aspects of the image which are meaningful to the surrounding content.
In an article about military costume: George Washington at Valley Forge, in his dark blue tricorn hat and lighter blue wool cloak with red lining.
In an article about the psychology of war: George Washington at Valley Forge, looking downward, while his starving soldiers sit on the ground in the background.
In most cases, the alt attribute is required for valid HTML5, so make it good.
Make infographics accessible with longdesc
If you have an image that contains a lot of information — such as a chart, infographic, or document photo — you can make the content of the image available using the longdesc attribute.
In HTML5, longdesc is used to specify a hyperlink to the text description of the image. This could be a link to separate document, but it is better (for SEO and usability) to link to a section of the current page.
Sensible Document Structure with Semantic Markup
HTML5 added several sectional elements for structuring pages appropriately.
Some version of this basic outline works for all content sites, with minor adaptations. For example, a blog index page might have multiple <article> elements inside of <main>, each with an <h2> header. A page with comments might place them inside of individual <article> elements, inside an <aside>element, inside <main>.
Web apps require more variety, but many of the same principles apply:
exactly <h1> and one <main> on page;
<header>, <footer>, and <nav> used to identify site content that isn’t part of this specific document;
<article> defines a single piece of self-contained content;
<aside> defines secondary content related, but not integral to, its sibling.
Pages with clear structure and appropriate markup are easier for someone using a keyboard to navigate around the page. People using a screen reader can quickly jump to the relevant section without having to listen as a voice synthesizer lists all the navigation links in your menu. (Adding a skip to main content linkhelps with this as well.)
Within your articles or form, you can make your content more accessible by also making it more skimmable — small sections, meaningful headlines and sub-headlines, and well-organized lists contribute to easier keyboard navigation. Generous use of id tags (at least on all <h*> headlines) creates a linkable document outline that improves usability of everyone.
Make Your Structure Even More Accessible with ARIA Landmarks
ARIA landmarks are a set of attributes which assistive technologies use to identify the purpose of various document sections. There is overlap between ARIA landmarks and the new HTML5 sectioning element, but not a perfect overlap. It is best to use both.
Relevant Anchor Text for Links (no “Click Here”)
It’s really easy to make a link and tell people to click here. Unfortunately, this is not accessible.
“Click here” is device dependent; not everyone clicks. Some people will tap, others will press enter, and still others will focus their eyes.
“Click here” provides no information about the content of the linked page. This reduces usability in at least three ways:
The user has to understand the surrounding text in order to understand “click here.” This increases cognitive load (bad for users with cognitive or neurological disabilities), and is difficult for those using screen reader technology.
If the surrounding text isn’t clear enough, the user has to open the page to find out what is there. For someone using assistive technology, this is a non-trivial operation.
Blind and low-vision users with screen readers cannot scan a document quickly the way sighted users can. They often skim through a page by jumping to headings and links to discover the page structure. “Click here,” breaks this interaction pattern.
Don’t Rely on Color
Color blind users will have difficulty when information is communicated only with color.
color coded alerts and badges in web apps
form labels that use color alone to indicate required and optional fields
charts and data visualizations that use color to identify components
hyperlinks that are distinguished from the surrounding text using only color (that is, without the default underlining)
Whenever possible, make sure that color-coded information is provided another way.
Color Contrast
Your dark gray text on a light gray background might look sleek and modern, but it’s also really hard to read. Color blind, the elderly, and low vision users will all have difficulty if the color contrast between text and background is too low.
The readability of various color combinations might seem a bit subjective, but there are clear color contrast standards in place.
AA (Minimally accessible)
4.5:1 for normal text
3:1 for large text (14pt with bold, or 18pt normal weight)
AAA (Highly accessible)
7:1 for normal text
4.5:1 for large text
You can use an online color contrast checker to ensure you are conforming to the readability standard.
Headers on Tables
Row and column labels in tables should use the <th> element (table header), and not the <td> (table data) element. Additionally, table data cells should be explicitly associated with their headers. This makes it much easier for screen readers to properly interpret a table.
Make Your Forms Accessible
Form accessibility is a big topic. If you design and build form-heavy sites or form-based web applications, you need to become familiar with the WAI-ARIA recommendation and associated best practices.
However, you can fix the majority of form accessibility issues with a few simple practices.
Every form element should have a label. Do not rely on placeholder text instead of a label. Do not use <h*>, <strong> or anything else for labels — use the proper <label> element.
Use the for attribute to associate the label explicitly to the form control. This is clearer for screen readers, and easier to select for those using certain types of assistive devices.
Use standard HTML5 form controls. Do not “roll you own” form control designs with images and clever JavaScript. You can style your elements with CSS all you want, but the underlying markup should be straightforward.
Don’t use tabindex>0. It is tempting to use tabindex to set the order in which form elements are accessed via keyboard tabbing. However, this feature is fundamentally broken. Instead of usingtabindex to set the tab order of your elements, make sure that your elements appear in your markup in the proper order.
Make Everything Available in HTML
Flash animation can be made accessible, but it is much easier to simply use standards-compliant, modern HTML5 and let assistive devices do the work. Similarly, embedding PDFs, PowerPoint slides, or other non-HTML ways of presenting content create a barrier between disabled users and that content.
Whenever possible (and it almost always is), provide your content in HTML. If there is a compelling reason to offer PDFs or PPTs, make sure that the content is also available in HTML. (PDFs can also be made more accessible, but HTML is easier.)
Moving Forward with Web Accessibility
Implementing these basic practices will go a long way towards making your web content accessible to the users with disabilities. But you can go even further. Web accessibility is a complicated, and evolving topic that cannot be summed up in a handful of tips.
For more information on Web Accessibility:
W3C – Web Design Accessibility Standards
WAI — Web Accessibility Initiative
Intro to Web Accessibility
Web Accessibility Resources from Mozilla Developer Network
Blogs on Accessibility
Adrian Roselli
The Paciello Group
Web Accessibility in Mind
The #a11y hashtag on Twitter