Inclusive Design: Web Accessibility for Nonprofits

Accessibility Principles and Resources for Web Developers

Many accessibility principles are universal, regardless of the tool used to create the online content. But some accessibility issues can only be addressed by developers or others who are comfortable with HTML, CSS, and JavaScript. If you are not a web developer, you may want to pass this information on to the people who build and maintain your website.

Featured Resource

The Web Accessiblity Fundamentals Guide introduces web accessibility principles like keyboard focus, semantics, alternative text, ARIA, and CSS. If you are comfortable with web development but new to web accessibility, this is a very good primer.

Web Accessibility Fundamentals Guide

In an earlier article, we outlined principles for creating accessible web content like: alternative text, semantics like headings and lists, tables, links, and captions for multimedia. This page covers some advanced accessibility principles that developers are likely to encounter.

Keyboard Accessibility

Anything that can be accomplished with a mouse or touchscreen must also be possible with a keyboard. The way you accomplish the task does not have to be identical--e.g., pinch-to-zoom with a touchscreen and using “+” and “-” buttons with a mouse or keyboard--but the outcome needs to be the same. Keep these principles in mind:

• Make sure every element on the page can receive keyboard focus when navigating with a keyboard. Custom-built widgets must be built to support keyboard accessibility using appropriate JavaScript and standard keystrokes.
• Keyboard users need to see which area of the page has keyboard focus. A browser should add an outline around links when they have keyboard focus, but sometimes the outlines are hidden (usually CSS outline:0), or they have low contrast.
• As the keyboard user presses the Tab key to move around the page, the order of elements on the page should be logical, usually similar to the visual order.
• Users should be able to skip over long lists of links.
• Provide a "skip to main content" link, a proper heading structure (H1, H2, H3, etc.), and HTML5 structural elements (<main>, <nav>, etc.) so users can navigate between areas in the page more easily..

Keyboard Accessibility—This article presents potential keyboard accessibility issues and the correct keystrokes for building and testing many common interactive elements.

Forms

There are four main steps to creating accessible forms.

• Use the correct control type. A single-line text input-<input type="text">-suggests that the user will enter a small amount of text in the field, while a larger <textarea> informs the user they can enter multiple lines of text. A round radio button indicates that the user must pick one option, no more or less, and a checkbox allows the user to select any number of options.
• Give all controls an accessible label. For most forms, the <label> tag should be used to present the same information to everyone, including screen reader users. However, some forms have hidden labels, or more than one string of text that serves as a label. This may require other techniques, like providing labels with ARIA.
• Associate important descriptions. Groups of related form controls (especially checkboxes and radio buttons) sometimes require a higher-level description that is added using <fieldset> and <legend>. Other times, form fields may include information that is not a label but is important enough to be read by a screen reader when navigating to the form control (e.g., formatting requirements for a password). This additional information can be associated to the form field with the aria-describedby attribute.
• Make it easy to recover from errors. The best way to minimize errors is to avoid many potential errors by simplifying forms and identifying required fields. If there is an error, identify the error, suggest how to fix it when possible, and make sure this information is presented in an accessible way. Finally, prevent significant errors by letting users confirm or undo important actions.

Web Accessibility Tutorials: Forms - This W3C resource provides guidance on all the major steps including associating labels, adding instructions, and providing accessible notifications.

Javascript

Make sure JavaScript event handlers are device independent (i.e., everything works with a keyboard, mouse, or touch), and manage keyboard focus so keyboard users can always navigate pop-up windows or menus. If you are using JavaScript to update content dynamically, present this updated content to all users.

Deque University Code Library (Beta)—A collection of JavaScript widgets with enhanced accessibility.

ARIA

Most web pages can be made accessible using the information presented in HTML. But sometimes HTML falls short.

ARIA is a very technical specification and a minor formatting mistake can have significant accessibility impact. Fortunately, there is excellent documentation on how to implement ARIA. Two especially helpful documents are:

• Notes on Using ARIA in HTML—This guide specifically for developers includes five rules of ARIA in use. Developers should understand these rules and why they are fundamental to ARIA use.
• WAI-ARIA Authoring Practices—Probably the most important ARIA reference for developers, this document contains a “design patterns” section that outlines ARIA design patterns and widgets. Each design pattern includes: a description of how this widget should be used, the keyboard controls for these widgets, required and optional ARIA information, and working examples (not available for all widgets).

There are many great resources available on web accessibility, but it is sometimes difficult to tell which resources are outdated or inaccurate. Here are three nonprofit groups with accurate and extensive resources and one for video accessibility:

• W3C Web Accessibility Initiative—These Resources from the creators of WCAG can be filtered by role--designer, developer, evaluator, manager, policy maker, etc.
• WebAIM—This website has web accessibility articles, handouts, and tools. It also has several resources for creating accessible electronic documents (e.g., Word and PDF).
• MDN Accessibility—A very complete, and very technical, web accessibility reference library from Mozilla.
• Adobe—A content creator's guide for producing accessible video.