Web Accessibility for Developers
As a web developer, you should keep the following accessibility concepts in mind as you create pages, templates, and sites.
One of the most common issues with websites is the lack of keyboard accessibility. You should be able to access the links and controls using the keyboard only. To get started with testing with a keyboard, click in the location bar of your browser then set your mouse aside. Use the tab key to start going through the page. Shift-tab will move you backwards.
The full evaluation methodology is defined under the page getting started with web evaluation. WCAG Guidelines that apply include: Bypass Blocks, Keyboard Only, No Keyboard Trap, Focus (visible), Focus Order.
Undefined Keyboard Focus Indicator
Many stylesheets use a "reset" style, that essentially removes all formatting. In doing so, the keyboard focus indicator is not defined, which prevents keyboard users from seeing what item on the page currently has the keyboard focus. Sometimes the focus is set, but it conflicts with the other colors and is not visible.
See the section on web evaluation, particularly Section 5 for keyboard testing.
Keyboard Activation Of Custom Controls
Putting onclicks event handlers on LI, div, span, and other elements without coding for keyboard accessibility as well can create barriers for keyboard users. Unlike anchor tags, buttons, and some other elements, these HTML elements are not natively keyboard focusable. Putting onclicks on these elements will cause them to be useable only by a mouse. The options to resolve this issue depends on your intended functionality for these elements: if you intend them to show additional content, to open up sub menus, or to function as a pseudo-checkbox or button.
Some users, especially those with specific disabilities, may rely heavily on using keyboards or other devices to change focus. For instance, a user might change locations in a web page using a tab key, and this would be a change of "focus." As the user moves around the page using the keyboard controls, there should be a visual indicator showing the element with the current focus.
Having a focus strategy will improve the experience for all website users but especially helps support people with visual and motor disabilities. A focus strategy starts at the beginning of a web development project with keeping focusable content within a logical order in the DOM.
- Do not change the order of the DOM without taking into consideration the website experience for keyboard users.
- Include styles to highlight focusable content in your CSS files. (OIT base templates have this styling already included.)
- Only add focus behavior to interactive controls like buttons, links or anything else that requires user input
- Avoid using tabindex equal to anything greater than "0"
- Include "skip-link" option for navigation so users can go straight to content. Make sure this link is visible when it receives keyboard focus.
For futher information, see WCAG 2.0 success criteria 2.1.1 on Keyboard Operability.
When we read a website (or a newspaper, or other content), we often skip around, skimming over some content or reading something in-depth when the title has caught our interest. Accessible websites provide the ability for all users to easily access and jump to the content they need. Using semantic HTML such as headings provides the information about how the content is ordered.
Semantic markup is a big topic. To illustrate the importance of semantic markup, watch this YouTube video from Udacity.com demonstrating how someone uses a text reader to navigate a website. Pay special attention to the fact that assistive technology follows the DOM order of a web page regardless of how the page is rendered visually.
In general, OIT suggests developers:
- label input elements
- provide useful text alternatives
- use heading (h1-h6) in a logical outline-form
- give links useful names (avoid "click here or read more")
- The OIT base template takes care of many of these considerations for you, but developers who are not using the base temaplate and content contributors still need to understand and practice good semantic markup.
The WCAG success critera that requires symantic HTML is 4.1.2, which states, "For all user interface components, the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set."
If you haven't thought about landmarks on your website, chances are they need some improvement. Assistive technology users can navigate your page using the landmark structure. The type of landmark is provided to these users, along with the name of the landmark if it is provided. If you have content on your page that is not contained within a landmark, then users may miss this content if they are navigating with landmarks.
The emerging standard is that all of the content on your page should be contained within a landmark. Your page should contain at least one navigation landmark, and one "main" landmark. If you have a landmark type that is repeated on the page, such as two different sets of controls that are within a navigation landmark, those two landmarks should be identified with distinct names. The Web Content Accessibility Guidelines provides additional details on landmarks.
ARIA is an acronym meaning Accessible Rich Internet Applications, and is a standard developed by the W3C. Developers add ARIA to web code to provide additional information to assistive technologies, such as screen readers. When used appropriately, ARIA will greatly increase the accessibility of your website and helps meet WCAG 2.0 guidelines. However, just adding ARIA to your code is not going to fix all of the accessibility issues of your website; in fact, an overuse of ARIA can introduce blocks and issues that did not exist before.
ARIA provides semantic information to assistive technology about elements on the webpage. ARIA provides a way to include roles and states of elements on your webpage, such as "expanded," "collapsed."
ARIA also provides design patterns for interactive "widgets," such as drop-down menus, expandable accordions, etc. These design patterns specify how ARIA should be used and also which keyboard commands should be used and what they should do. Typically, the keyboard commands are the arrow keys, the enter and space keys, and escape.
The full ARIA specification is available from the World Wide Web Consortium.