The Basics of Web Accessibility

How big of a problem is it, really?

When you hear the phrase "web accessibility," what comes to mind? Many people assume that it's a highly technical field that only benefits a small percentage of online users. The truth might shock you. In the United States alone, there are:

  • More than eight million people with visual impairments.

  • More than seven million people who are hearing impaired.

  • More than two million people who have seizures or epilepsy.

  • Almost twenty million people who are mobility-impaired.

Keep in mind, these numbers only apply to those who have reported chronic disabilities. Often, disabilities are under-reported, especially among the elderly population. Declines in vision, hearing, and dexterity are quite common as people age but are rarely included in disability statistics. If we also factor in users with temporary disabilities (for example, when someone breaks their wrist and is mobility-impaired until it heals), the numbers grow even larger.

Which disabilities impact website use?

To begin understanding the types of barriers website users may encounter, it's essential to learn about some of the most common disability types. This list is not exhaustive but does cover four of the largest categories.

Hearing Impairments
Users with hearing impairments may have slight or complete hearing loss. Creating readable text alternatives to any content that has an audio component is an important way to make your digital content more accessible for these users.

Visual Impairment
Users with visual impairments may have limited vision or total vision loss. Boosting your website’s contrast, using easy-to-read fonts, making sure content can be enlarged via their browser’s zoom feature, using alt text, and creating text that is simple for screen readers to interpret are helpful ways to make your content accessible for these users.

Mobility Impairment
Users with mobility impairments have limited or no use of one or more of their extremities. This includes (but is not limited to) users with missing limbs, paralysis, and tremor disorders. Often, these users are unable to work with a mouse or a touchscreen. Making sure your website can be navigated using the keyboard, foot pedals, or a sip-and-puff tube can help these users to access your content.

Cognitive Impairment
Of these categories, cognitive impairment is simultaneously the largest and most varied but also the least understood. It is also the category with the least developed best practices. It encompasses issues like ADHD, dyslexia, epilepsy, and low literacy, and each user requires different online accommodations.

What are some common accessibility issues?

If you’re having a tough time envisioning what a digital accessibility issue might look like, here are a few scenarios to help.

Low Contrast
An online store receives a call from a retiree trying to place an order on their website. He attempted to fill out the order form but reports that the order page doesn't have any text boxes where he can add his information. After a long conversation with customer service, both sides discover that the textboxes were actually just too faint for him to see.

The store needs to increase the contrast on its order form (and likely other parts of its website) to ensure that users can see and use the form easily. Otherwise, they will lose out on potentially valuable sales.

Poor Functionality
A mother contacts her child's school to report that the classroom website is nearly impossible for her to read. Since the font is so small, she is forced to zoom the screen to 200% and now has to scroll right and left in order to read each line. She often loses her place and can't easily get the information she needs.

The school should ensure that their website reflows responsively and that the standard font is larger.

Chaotic Structure
A backpacker with dyslexia is researching different points of interest along his travel route. He finds a restaurant that he’d like to try, but due to fancy fonts, flashy banners, long and dense text passages, and random popups, he is unable to wade through the website's information to figure out if it's even open when he's in town.

The restaurant needs to declutter their site and make everything clearer for the person to read. By choosing easy-to-read fonts, breaking up long passages into smaller paragraphs, increasing the line spacing, and reducing unnecessary distractions, they can help visitors to find the information they need.

Screen Rotation
A Paralympic athlete is trying to order new gear from a website. Since her tablet is affixed to her wheelchair, she needs the website to rotate in order to display properly. However, the brand’s site is only designed to be viewed in one device orientation.

The restaurant needs to declutter their site and make everything clearer for the person to read. By choosing easy-to-read fonts, breaking up long passages into smaller paragraphs, increasing the line spacing, and reducing unnecessary distractions, they can help visitors to find the information they need.

Of course, these are just a few sample scenarios. Accessibility issues are far-reaching and can come in many forms. It's important to remember that every disability requires special considerations, and there are a number of variations within each category. This means that digital accessibility needs to be customizable so that each user can access the support they need.

What website elements create barriers for users?

Since there are so many types of disabilities that can impact web use, it’s not surprising that making a website accessible can be a daunting task. Most websites contain the following types of content and functionalities:

  • Text

  • Links

  • Images

  • Navigation

  • Forms

  • Video

  • Audio

Consider, for example, a simple hyperlink. It’s one of the most basic but vital types of interactive content on the web, yet it can present many issues:

  • Depending on the color scheme, users with color blindness may not be able to distinguish links from static text if they are differentiated only by color.

  • Also, depending on the color scheme, users with low vision will need adequate contrast between the link text and the background color for the link to be readable.

  • Both blind and mobility-impaired users will need link text that describes what will happen if they activate that link (not just stating, “click here”).

Another good example is a website’s contact form.

  • Users with low vision will need adequate contrast between the form controls and labels versus the background for the form to be readable.

  • Users with color blindness may need a visual indicator other than color to identify required fields versus optional fields.

  • Users with mobility impairment will find navigating the form easier if fields are stacked on top of each other rather than side by side.

  • Blind users will need clear labels and, in some cases, supplementary instruction within the flow of the form (not off to one side where they may not hear the screen reader communicate it when they need to or may never hear it at all).

  • Both blind and mobility-impaired users will need easy and standardized keyboard navigation to move around the fields and to operate them.

As you can see, there’s a lot to consider when it comes to accessibility. But there is good news — you don’t have to learn absolutely everything before you get started. Each enhancement that you learn about and implement begins to help users the minute it goes live.

Who creates web accessibility standards?

You might be wondering where all of the digital accessibility rules and regulations come from and who keeps track of them. Since the web evolves rapidly and new innovations frequently emerge, accessibility guidelines also must be updated. There are many sources of information (see Appendix B), but the most comprehensive are the World Wide Web Consortium’s Web Content Accessibility Guidelines, commonly known as WCAG.

The World Wide Web Consortium is an international body that publishes what are generally considered to be the official specifications for HTML, CSS, and several other web technologies. Since 1999, they have also produced the Web Content Accessibility Guidelines (WCAG). WCAG has undergone revisions and currently stands at version 2.1.

Since there are so many types of disabilities that can impact web use, it’s not surprising that making a website accessible can be a daunting task. Most websites contain the following types of content and functionalities:

The guidelines are broken down into three levels:

  • Level A — This is the lowest level and includes relatively easy enhancements to make. This level represents the bare minimum of accessibility.

  • Level AA — This is the intermediate level and contains enhancements that are more difficult to implement but also increase accessibility.

  • Level AAA — This is the highest level of standards, and they are the most difficult to meet. However, they do yield the greatest accessibility for end-users.

A cautionary note for newcomers to WCAG: the language of the guidelines — on the surface, at least — veers toward being academic and can be off-putting. If you dig one level deeper to the lengthier text descriptions, they are far more reader-friendly. Other accessibility authorities provide checklists and tutorials in plain language that may be easier to understand. See Appendix A for a concise overview of WCAG.

Section 508
In addition to WCAG within the United States, there are also Section 508 guidelines. These guidelines are rooted in law, the Rehabilitation Act of 1973 to be specific, and require federal agencies to make their websites highly accessible. Via a trickle-down effect, the Section 508 guidelines are also often used in state and local governments as well as within the nonprofit and education spaces, especially those that work closely with the government.

Historically, however, the Section 508 guidelines suffer from two problems:

  • They are not as comprehensive as WCAG.

  • They have often lagged well behind WCAG in getting updated and, thus, even further behind the ever-evolving web itself.

Any developer or site creator who adheres to WCAG standards will automatically follow Section 508 as well.

What are some common misconceptions about accessibility standards?

Whether discussing WCAG or Section 508, certain misconceptions are common and should be corrected in order to adopt a healthy and realistic mindset about accessibility. Here are a few of the most common misconceptions:

First, “meeting standards” and “achieving compliance” can convey that accessibility is a finite pursuit. It’s not.

Accessibility is an ongoing pursuit and requires permanent changes to your web workflow. As new content and new functionalities are added to any site, they need to be made accessible before going live. Although many organizations and developers face an initial learning curve, the changes to the workflow are not nearly as daunting once new habits are formed.

Second, compliance is “a line in the sand that we have to get across.” No, it’s not.

Accessibility is a spectrum, and every site sits somewhere on it. Every time an accessibility enhancement is made, it pushes a website higher on that spectrum and immediately benefits users. That’s true even before “compliance” of any kind is achieved.

Many organizations and developers see accessibility as disheartening because it can be a long road before they even achieve WCAG level A (let alone AAA). That’s the wrong way to think about it. A better way is that if you make any accessibility enhancement today, your users will benefit today. Make another accessibility enhancement tomorrow, and users will likewise begin to benefit as soon as it’s live.

Third, if we achieve “compliance,” then we’ll be on strong legal ground. Perhaps...or perhaps not.

The entire concept of compliance has many organizations looking in the wrong direction for trouble. Currently — and with the possible exception of certain government agencies — there is no authoritative body that enforces accessibility guidelines. The real threat is lawsuits. The WCAG guidelines (or others) help to attain a high level of accessibility. Still, organizations should keep their focus where it belongs — on ensuring their users do not encounter barriers when visiting their website.

Are accessibility lawsuits a real risk?

In the last twenty years, there have been many high-profile accessibility lawsuits. Recently, the pace of litigation has increased and impacted prominent brands, including Target, Amazon, Bank of America, and Five Guys.

It’s unfortunate that litigation has been one of the more effective ways to raise awareness about accessibility and to get companies to take action. Some of that interest is, of course, out of fear. But there’s also a positive wave of interest about accessibility taking hold in the zeitgeist.

Although Section 508 may be referenced in some lawsuits, most are rooted in the Americans with Disabilities Act (1990). Its intent is to prohibit discrimination against individuals with disabilities and to ensure that they have the same rights and opportunities as everyone else. While legal action often ensures those rights, we hope that the positive shift toward website owners and designers baking accessibility in from the beginning will become more popular.

Why do I need an accessibility statement?

The goal of accessibility is to provide equivalent information to users with and without disabilities. One of the most helpful additions any site creator can put on their site is meta-level information about the accessibility of the website in the form of an Accessibility Statement.

An Accessibility Statement alerts users to the current state of accessibility on the site. It can be used to explain accessibility goals as well as the methods being used to achieve that target. It can also acknowledge areas where targets are unmet and convey the plan for resolving those issues.

Although it might seem counter-intuitive to advertise accessibility weaknesses that may still be present on a given site, it can also serve as a powerful gesture of transparency. The information you provide about ongoing enhancements also makes a bold statement about your commitment to inclusiveness.

What is the future of accessibility?

Technology evolves at a fast pace and will continue to do so indefinitely. In some cases, new technologies will help with accessibility. However, new challenges will also arise.

WCAG 2.1 was developed as a response to new technologies — mobile, especially — and the accessibility challenges that they create. Issues that now exist due to mobile devices include:

  • Sequencing content so that important elements appear without needing to scroll.

  • Supporting both landscape and portrait orientations.

  • Clearly indicating which elements are interactive.

  • Changing interactive elements to activate on ‘mouse up’ and ‘touch end’ events (rather than ‘mouse down’ and ‘touch start’ events).

Just as mobile phones presented new accessibility challenges, other technologies will do the same. WCAG 3.0 is currently under development and will address emerging issues involving the Internet of Things (IoT) which includes devices such as:

  • Cars

  • TVs

  • Wearables

  • Appliances

  • Small screens

  • 3D Touch & Pressure

With increased awareness, ongoing education, and the use of helpful innovations like the AccessWay widget, we can create a web that works for everyone. The most important step is the first step. If you are already pursuing accessibility, keep going. If you're just getting started, well, just get started. We can get there together, one step at a time.

Appendix A: Brief overview of WCAG

1.1 Provide text alternatives

Provide equivalent alternative text for all non-text content (images, etc.).

1.2 Provide alternatives to audio and video

At lower level (A), provide transcripts or captions as alternatives to audio content for hearing impaired-users.

At higher levels (AAA), provide captioning for live audio and sign language interpretation for prerecorded audio for hearing-impaired users.

At lower level (A), provide text or audio description of visual content within video for visually impaired-users.

At higher levels (AA, AAA), provide an alternative soundtrack with extended audio description for visually-impaired users.

1.3 Provide adaptable content and functionality

At lower level (A), help visually-impaired users by providing alternative means of communicating important information conveyed by visual formatting (bold, color, bullets, etc.). Also, sequence information carefully for those who take it in linearly.

At higher levels (AA and AAA), program form fields to clearly identify purpose and program regions, buttons, and links with supplementary instructions or description to communicate their purpose.

1.4 Make content easily distinguishable regardless of ability or disability

At the lower levels (A and AA), do not rely on color alone to convey important information. Do not automatically play audio without providing an easy means to pause or reduce volume. Set adequate contrast between text and background colors (4.5:1) and adequate contrast between other adjacent colors (3:1). Use adequate text spacing for easy reading. Avoid relying on mouse hover for displaying or hiding important content like menus. Employ responsive design or other techniques to allow zooming in to 200% without loss of functionality and without requiring scrolling. Avoid using graphics of text (or, at least, providing equivalent alternative text).

At the highest level (AAA), use higher contrast between text and background (7:1). Avoid background audio altogether (or leave at very low volume). Avoid long lines of text and full justification (alignment). Completely avoid using images of text.

Note: The AccessWay widget can be installed on any site to enable many of these solutions such that users can control them and without requiring permanent code changes to the site.

2.1 Allow keyboard navigation and operation

At lower level (A), make basic and critical functionality operable using only a keyboard with no keyboard traps (where users are unable to escape a given situation without using a mouse or touchscreen).

At higher level (AAA), make all functionality operable using only a keyboard.

2.2 Provide adequate time

At lower level (A), if time limits are an issue, make them reasonable. If timeouts are an issue, warn users beforehand. Allow pausing, hiding, and stopping of any blinking, scrolling, or auto-updating content.

At the highest level (AAA), allow users should to stop interruptions, retain data entered after re-authenticating in a security timeout situation, and warn users about any data loss in the case of timeout.

2.3 Avoid blinking content and allow user control of motion content

At low levels (A), avoid rapidly blinking content (or avoid blinking content altogether) for users with photo epilepsy or other seizure disorders.

At higher levels (AAA), allow users to initiate and stop all motion content (video, animations, etc.).

2.4 Provide ways to help users navigate, find content, and determine where they are

At lowest level (A), provide high quality page titles and link text for visually-impaired users. Ensure that tabbing through a page follows a logical and meaningful sequence for keyboard users. For keyboard and visually-impaired users, provide a means (like skip links) to skip over repetitive content on each page like banners, menus, etc.

At the middle level (AA), provide a visual indication of where focus is located for keyboard users who tab through pages. For visually impaired users, provide high quality headings. Provide an accessible search mechanism or a site map so that users have multiple options for finding a given page within a site in addition to the main navigation (menu, typically).

At the highest level (AAA), provide breadcrumbs so that users can retain their bearings within the site. Also provide high quality section headings.

2.5 Allow multiple input and operation methods

For some users, using a mouse or touchscreen is not possible. At the lower level (A), provide alternate means of performing functions in addition to mouse- or touchscreen-oriented gestures like clicking, dragging, pinching, two finger swipe, etc. Program controls to operate on ‘mouse up’ and ‘touch end’ events (rather than ‘mouse down’ and ‘touch start’ events) and offer alternative mechanisms for motion-actuated processes.

At the highest level (AAA), offer target sizes of adequate size and allow all functionality to be performed via non-mouse and non-touchscreen methods like external keyboards with tablets.

2.6 Make web pages appear and operate in predictable ways

At the lowest level (A), avoid actions that automatically trigger when an element receives focus, like submitting a form or launching a new window (among others) and instead forewarn users and allow them to initiate such actions. Make interactive content predictable by forewarning users if entering data will trigger changes to the content (e.g., typing a phone number area code will automatically advance focus to the next field).

At the medium level (AA), make navigation that occurs on multiple (or all) pages consistent and identify elements that share the same functionality consistently.

At the highest level (AAA), all actions like submitting forms, launching windows, advancing to the next field, etc., are initiated by the user (or automatic behavior can be turned off).

2.7 Input Assistance: Help users avoid and correct mistakes

At the lowest level (A), identify errors in forms and other interactive content and describe the error in text. Provide labels or instructions when user input is required.

At the higher levels (AA, AAA), if suggestions to remedy errors are available to any users, provide them in text for all users. Offer context-sensitive help. Take extra care to prevent errors before non-reversible actions, especially if legal or financial consequences are involved — offering “review and submit” confirmations before final submission serve as one powerful example.

2.8 Compatible: Maximize compatibility with current and future user agents, including assistive technologies

At the lowest level (A), use standards-based markup with complete tags, correct nesting, no duplicate attributes, and unique IDs. Give interactive components correct names and roles; states, properties, and roles can be changed by user and such changes are reported to assistive technologies.

At higher level (AA), status messages are made available to assistive technologies.

Compatible: Maximize compatibility with current and future user agents, including assistive technologies

At the lowest level (A), use standards-based markup with complete tags, correct nesting, no duplicate attributes, and unique IDs. Give interactive components correct names and roles; states, properties, and roles can be changed by user and such changes are reported to assistive technologies.

At higher level (AA), status messages are made available to assistive technologies.

Appendix B: Additional Sources