Understanding disabilities, visible and non-visible
The word “disability” has many different meanings depending on the context. There are definitions of disability determined by legislation, for example, the Americans with Disabilities Act, social and medical classifications of disability, as well as statutory definitions that are used as a basis for entitlement to benefits programs like Social Security. According to the World Bank, “One billion people, or 15% of the world’s population, experience some form of disability.”
If we live long enough, we’re all going to experience a temporary or permanent disability or some loss of function. Vision, hearing, and mobility disabilities are among the most recognized disabilities. But not all disabilities are visible. Many people live with “non-apparent” or “hidden” disabilities such as seizure disorders, multiple sclerosis, PTSD, or learning disabilities. Moreover, disabilities or functional limitations may be age-related, situational, or temporary—a broken arm, for example.
While working to make your website accessible, it’s important to understand the broad range of disabilities and potential accessibility solutions related to them. It’s equally critical to recognize the diverse abilities and assistive technologies people bring to bear when interacting with websites. People who are blind may use assistive technology such as a screen reader like Jaws to read web content aloud. People with low vision often use magnification software. Those living with disabilities such as amyotrophic lateral sclerosis (ALS or Lou Gehrig’s disease) may use eye tracker software and never use a mouse. And many other users, who you might assume have no disability at all, benefit from alt text, keyboard only navigation and clear link text.
What makes a website accessible?
According to W3C’s Web Accessibility Initiative web accessibility means “…that websites, tools, and technologies are designed and developed so that people with disabilities can use them.” The Web Content Accessibility Guidelines (WCAG) provide a roadmap for making your digital assets as accessible as possible. And there’s really no end point to this effort. Websites and other digital assets are rarely static, so the need to regularly assess their accessibility, while collaborating with users with different abilities, is essential.
Meeting WCAG 2.1 AA standards is the path to making your website more accessible. These guidelines are the international standard for web accessibility. Under the umbrella of multiple guidelines including Text Alternatives, Keyboard Accessible, and Enough Time, you’ll find detailed WCAG Success Criteria and techniques for advancing the accessibility of your website and other digital assets. Achieving web accessibility is a team effort requiring the problem solving skills and creativity of developers, designers or content authors. And remember, while web accessibility is a necessity for some of us, it enhances usability for all of us.
Common website accessibility issues
It makes good sense to prioritize the WCAG Success Criteria you aim to address. Some of the most common accessibility errors have been identified by WebAIM. They include low contrast text, missing alt text, and lack of form input labels. Failure to meet the requirements of these Success Criteria will create barriers for individuals with a variety of disabilities and functional limitations, preventing them from benefiting from all your website has to offer.
- Non-Text Content/Alt-text 1.1.1
Websites and other digital assets are often loaded with images and other non-text content, and they often have missing or inaccurate descriptions – or alternative text (alt text). Well-written alt-text obviously helps people who are blind and don’t see non-text content such as images. If there’s no alt text (or bad alt text), people who use assistive technology like screen readers won’t be able to tell what the images mean or represent. When clear and concise alt text is provided, screen reader users will understand image as they hover over it or interact with it. Alt text is also useful for people with some forms of aphasia and visual processing disorders, who may have trouble grasping the full meaning of complex images, charts, or graphs.
- Distinguishable/Color Contrast (Minimum) 1.4.3
Contrast is the difference in color between something in the foreground and its background. Low color contrast is a common accessibility barrier, and one of the easiest to fix. For people with low vision, it’s often very difficult to read words that don’t stand out enough from the background. Many of us might say the same if it’s late at night and our eyes are overworked from staring at a computer screen all day. And if you have trouble seeing different hues or shades, then contrast becomes even more important.
Many common UX and UI design practices fail WCAG standards when it comes to color contrast, so be alert to them early in the design process. Consider text on a button, for example. If the contrast between the text color and the button color aren’t different enough, a user may not be able to read the text or it may be blurry.
WCAG 2.0 Level AA guidelines require a color contrast ratio of at least 4.5:1 to make most text legible (with a 3:1 ratio for large text). Being aware of this guideline, designing for it where possible, and allowing users to adjust contrast settings, will reduce readability barriers due to low color contrast.
- Keyboard Accessible/Keyboard Only 2.1.1
Keyboard access ensures that a user can benefit from everything your website offers using just the keyboard or a keyboard interface. People who are blind or have low vision, as well as individuals with dystonia, stroke or multiple sclerosis, may find using a mouse difficult or impossible. Tremors or other dexterity issues often don’t allow for the fine muscle control needed to use a mouse. Some people may opt for an adaptive keyboard or voice-to-text software. Check out this video about keyboard compatibility for more information.
When it comes to supporting keyboard access be sure to check the following elements:
- navigation menus and sub-menus
- submission buttons
- media players
- sidebar content
- embedded content (for example, videos, Twitter and Instagram posts)
A user should be able to “tab” to each of these elements in a logical flow (such as left to right and top to bottom). They should also be able to select or activate a feature at any time.
- Enough Time/Timing Adjustable 2.2.1
People who are blind, have low vision or have learning disabilities, and people with mobility/dexterity disabilities, all benefit from having extra time to complete certain online tasks. The same is true for situations where a sign-language interpreter may be relating audio content to a user who is deaf. In fact, all of us may need extra time depending on the task and our ability to concentrate. Regardless of the type of disability or functional limitation, users should be able to complete tasks without unexpected changes in content or context caused by a time limit. It’s therefore critical to try and avoid situations where a user is timed out of an action they’re in the middle of. That said, there are exceptions to the requirement of turning off time limits, for example buying tickets online, where extending the time might invalidate the purchase.
- Navigable/Link Purpose (In Context) 2.4.4
Unclear link text can also make it difficult, if not impossible, for people with several types of disabilities—visual or cognitive, for example—to find the information they’re seeking. Using clear, effective link text is critical to maintaining accessibility. Link text such as “click here” or “Visit this link for more information” convey nothing but confusion, regardless of a user’s abilities. A key element in writing effective link text is letting your users know where a link will take them, or what they will find once they click on it. Having that information also allows not just people who use screen readers, but also people with mobility/dexterity disabilities, to skip over links they aren’t interested in.
- Input Assistance/Labels or Instructions 3.3.2
Software form controls include objects on websites that users interact with, such as buttons, checkboxes, and text fields. Form controls need to be properly labeled so users understand their purpose. Keep in mind, a label may be visually labeled next to the control or hidden and only available for assistive technologies. The goal should be to maintain a close and distinct visual relationship between the label and the form control.
While some controls are clear because of their label (“Next Page” or “Submit” buttons), other controls can create confusion if the labels are missing. For example, a screen reader or other assistive device might not be able to detect how to select a date if the date field or drop-down menu isn’t labeled clearly or accurately. Clear labels and instructions are also helpful for people with learning or cognitive disabilities who benefit from explicit guidance about how to, for example, input a date in the required format. Providing clear instructions on which fields are required also enhances accessibility.
Making your website more accessible by conforming to WCAG requires an understanding of the fact that how people with disabilities interact with technology is as diverse as the disability community itself. The breadth of disabilities and the types of digital barriers associated with them must be taken into consideration when coding, designing, writing, and organizing web content. As developers, designers, and authors, you’ll no doubt discover new techniques for conforming to WCAG that respond to the accessibility requirements of the whole community of individuals with disabilities–those with visible and non-visible disabilities, temporary or permanent disabilities, and the various assistive technologies they may use to navigate the Web.
- Stories of Web Users: How People with Disabilities Use the Web (W3C’s Web Accessibility Initiative)
- The WebAIM Million—WCAG Conformance (WebAIM)
- Meaningful vs. Decorative Images (Digital.gov)
- Contrast and Color Accessibility (WebAIM)
- Five Most Common Accessibility Errors in Software Design and Development (WCAG.com)
- Keyboard Accessible (WebAIM)