The World Wide Web Consortium Web Accessibility Initiative (W3C® WAI) defines web accessibility as “websites, tools, and technologies are designed and developed so that people with disabilities can use them.”

Ensuring that the web remains accessible to people with disabilities–auditory, cognitive, neurological, physical, speech, or visual–ensures that these individuals can more fully use the web and contribute their knowledge and expertise to it as well. They do not become limited to being consumers of content and technologies; rather, they can become developers, designers, and content producers.

While web accessibility resources and tools often focus on the experience of users with disabilities, their benefits extend to everyone, even to those without permanent disabilities.

For instance, captions enable persons with poor hearing to access videos on the web. But these captions help other users as well. If they are watching the video in a noisy area, they can turn on the captions. Those who are not fluent in the language used in the video can also read the captions to fully grasp the content’s message.

Source: Web Accessibility Perspectives – Compilation of 10 Topics/Videos (YouTube)

Another example is the use of alt texts in images. These descriptive texts don’t just help users of screen readers understand what an image contains. Carefully optimized alt attributes also benefit businesses’ image search engine optimization (SEO) strategy, which consequently help them improve conversion rates.

3 Components of Web Accessibility

Making the web accessible involves multiple components. Among these are:

• Web content: Aside from the text, images, audios, and videos, this also includes the forms your users fill out, markup codes, and applications.
• Authoring tools: These refer to software and services designers and developers use to build a business website, other online sites, and web content. Authoring tools include content management systems (CMS), blogs, code editors, and document conversion tools.
• User agents: These are the software which facilitate your users’ access to web content. Examples include browsers (desktop, mobile, voice), plug-ins, multimedia players, and assistive technologies like screen readers and magnifiers, scanning software, and alternative keyboards.

Source: https://www.w3.org/WAI/fundamentals/components/

Each of these three components have an equivalent web accessibility guidelines prepared by the WAI:

• Web Content Accessibility Guidelines (WCAG)
• Authoring Tool Accessibility Guidelines (ATAG)
• User Agent Accessibility Guidelines (UAAG)

3 Conformance Levels

WAI’s three guidelines–WCAG, ATAG, and UAAG–categorize conformance into three levels:

• Level A (lowest): A web page must meet all Level A success criteria or present a conforming alternate version.
• Level AA (middle): In addition to meeting all Level A success criteria, a web page must also meet all Level AA success criteria or have a Level AA conforming alternate version.
• Level AAA (highest): A web page that meets this highest conformance level satisfies all Level A, Level AA, and Level AAA success criteria or has a Level AAA conforming alternate version.

Meeting Level A requirements–which cover basic accessibility features like providing images with alt attributes–is a must.

Meanwhile, Level AA requirements help resolve many common accessibility issues encountered by users with disabilities. Lastly, Level AAA includes more advanced accessibility requirements.

Let’s dive into each of WAI’s guidelines.

The Web Content Accessibility Guidelines (WCAG) 2.1

WCAG 2.1 is organized into guidelines, and each guideline has its own success criteria or accessibility requirement which corresponds to a conformance level (Level A, AA, or AAA).

The WCAG 2.1 guidelines–like the ATAG and UAAG guidelines–are organized around four accessibility principles:

• Perceivable
• Operable
• Understandable
• Robust

Let’s take a closer look at these accessibility principles and guidelines. If you want to know each guideline’s success criteria and conformance levels, check out the full WCAG 2.1 document here.

Principle 1: Information and user interface must be presentable to users in ways they can perceive.

• Provide text alternatives for non-text content so these can be changed into other forms such as braille, symbols, plain language, or huge print.
• Provide captions and alternatives (such as audio descriptions, sign language interpretations) for time-based media like live audios or prerecorded videos.
• Create adaptable content, i.e., content that can be presented in multiple ways (such as a simpler layout) without losing information or structure.
• Make content distinguishable, i.e., it must be easy for users to see and hear the content. This guidelines covers requirements on the use of colors, audio controls, contrast, text resizing, reflow, images of text, and text spacing.

Principle 2: User interface components and navigation must be operable.

• All functionalities are available from the user’s keyboard.
• Users have enough time to read and use content.
• Do not design content in a way that is known to cause seizures and physical reactions (ex., content that flashes more than thrice per second).
• Users can easily navigate, find content, and determine where they are.
• Users can use different input modalities beyond keyboards, such as voice recognition, gestures, and touch activation.

Principle 3: Information and user interface operation must be understandable.

• Make content readable and understandable, such as by allowing web page language and the language used in specific passages to be programmatically determined (i.e., determined by software), and providing the meanings of unusual words and abbreviations.
• Make web pages appear and operate in predictable ways, such as by using consistent navigation mechanisms.
• Help users avoid and correct mistakes, such as by identifying errors and providing suggestions, as well as allowing users to reverse, check, and confirm responses to legal and financial transactions.

Principle 4: Content must be robust enough that it can be interpreted by a wide variety of user agents.

• Maximize compatibility with current and future user agents, such as web browsers and assistive technology.

The Authoring Tool Accessibility Guidelines (ATAG) 2.0

Authoring tools refer to the software and services that web designers, developers, writers, and other “authors” use for creating static web pages, dynamic web applications, and other forms of web content.

Some examples of authoring tools are what-you-see-is-what-you-get (WYSIWG) HTML editors, software for editing source codes or creating mobile web apps, content management systems, social media, forums, wikis, and multimedia authoring tools.

The ATAG 2.0 document aims not just to help authors create accessible web content, but also to enable persons with disabilities to easily use authoring tools. As such, ATAG 2.0 is divided into two parts:

• Part A focuses on making authoring tools accessible, and
• Part B discusses how these tools can help authors create accessible content.

Like the WCAG 2.1, ATAG 2.0 is also organized around principles. Each principle has guidelines that serve as a framework, and each guideline has success criteria (accessibility requirements) at conformance levels A, AA, and AAA. Detailed information on the success criteria, their intent, examples, and conformance levels are available in the W3C Working Group Note on ATAG 2.0.

Part A: Make the authoring tool user interface accessible.

Principle A.1: Authoring tool user interfaces follow accessibility guidelines.

• Ensure that web-based functionality (ex., user interfaces of web-based wikis and help systems) meets the WCAG success criteria.
• Ensure that non-web-based user interfaces (ex., Windows, Mac OS, Android) are accessible.

Principle A.2: Editing-views are perceivable.

• Make alternative content (ex., captions, audio descriptions, sign language) available to authors.
• Ensure that editing-view presentations can be extracted by different software, including assistive technologies.

Principle A.3: Editing-views are operable.

• Provide efficient keyboard access to authoring features.
• Provide authors with enough time. To aid authors who may have difficulty typing or processing information, authoring tools must have auto-save options, adjustable timing, static input components, and allow automatic saving of web content edits.
• Help authors avoid flashing that can cause seizures by providing a static view option.
• Enhance navigation and editing via content structure.
• Enable text search of the content, so authors can easily find the content they want to edit.
• Allow users to save or control their preferred display settings.
• Ensure that content previews are at least as accessible as in-market user agents.

Principle A.4: Editing-views are understandable

• Help authors avoid and correct mistakes by making content changes reversible and enabling settings change confirmation.
• Document the user interface, including all accessibility features, so users can refer to it while operating authoring tool features.

Part B: Support the production of accessible content

Principle B.1: Fully automatic processes produce accessible content.

• Ensure that web content automatically produced by authoring tools are accessible.
• Ensure that accessibility information is preserved during web content transformations, such as restructuring, recording, or copy-pasting content.

Principle B.2: Authors are supported in producing accessible content

• Ensure that users can create WCAG-conforming web content using authoring tools.
• Guide authors in creating accessible content, such as by making accessible options prominent and including mechanisms for setting accessibility properties.
• Help authors manage alternative content for non-text content, such as through automated repair of text alternatives and ensuring that alternative content are editable.
• Assist authors with accessible templates, by offering accessible template options and identifying template accessibility.
• Assist authors with accessible pre-authored content like clip art, user interface widgets, and sample videos.

Principle B.3: Authors are supported in improving the accessibility of existing content

• Assist authors in checking for accessibility problems, such as by locating potential problems, providing instructions, and generating accessibility status reports.
• Assist authors in repairing accessibility problems, such as by providing suggestions.

Principle B.4: Authoring tools promote and integrate their accessibility features

• Ensure that authoring tools have features that support accessible content production. Make sure that these features are turned on by default, and either it cannot be turned off or it can be reactivated.
• Ensure that the documentation promotes the production of accessible content. This can be done by including examples of accessible authoring practices, tutorials, and an index to instructions on accessible content support features.

The User Agent Accessibility Guidelines (UAAG) 2.0

The UAAG documents provide guidelines for ensuring that user agents–browsers, browser extensions, readers, and media players–are accessible to persons with disabilities. The UAAG is primarily targeted at developers of these user agents or applications that render web content.

User agent accessibility features are essential in ensuring that browsers and applications–not just the web content–can provide disabled individuals with a better user experience. For instance, user agents may allow people to customize the text, preferences, and interface for better accessibility.

UAAG 2.0 guidelines are organized around the same principles as WCAG 2.1 and ATAG 2.0. For a detailed look at each guideline’s success criteria, conformance levels, and examples, see W3C’s UAAG 2.0 Reference.

Principle 1: Ensure that the user interface and rendered content are perceivable

• Provide access to alternative content, and enable users to resize and reposition time-based media alternatives such as captions and sign language videos.
• Repair missing content through assistive technologies.
• Provide highlighting for selection, keyboard focus, enabled elements, and visited links.
• Provide text configuration (e.g., allow users to set the text color, style, line spacing, font, size, character spacing, justification, and borders) which users with poor vision, dyslexia, or other disabilities can use to make the content readable for them.
• Provide volume configuration for each audio track relative to global volume.
• Provide synthesized speech configuration (ex., users can specify the speech rate, volume, voice, pitch, and pitch range).
• Enable configuration of user style sheets. This way, users can customize web content rendering (ex., choosing yellow text on black background) to help them read online materials.
• Help users to orient within, and control, windows and viewports.
• Provide alternative views (ex., outline view, source view).
• Provide information on the relationships between elements (ex., form labels, table headers, row and column labels, content hierarchy).

Principle 2: Ensure that the user interface is operable

• Ensure full keyboard access.
• Provide sequential navigation.
• Provide direct navigation and activation.
• Provide text search.
• Provide structural navigation (ex. by headings or content sections, or within tables).
• Configure and store users’ preferred settings.
• Customize display of graphical controls, i.e., users can add, remove, reposition, and assign shortcuts to controls.
• Allow time-independent interaction (i.e., users can adjust time limits).
• Help users avoid flashing that can cause seizures.
• Provide control of time-based media, such as allowing users to navigate by time, utilize playback, and adjust visuals’ contrast and brightness.
• Support other input devices like pointing tools, speech recognition, and onscreen keyboards.

Principle 3: Ensure that the user interface is understandable

• Help users avoid and correct mistakes, such as through spelling checks and auto-fill of basic information.
• Document the user interface, including accessibility features.
• Make the user agent behave in predictable ways.

Principle 4: Facilitate programmatic access

• Ensure that user agents support platform accessibility services, and provide information on controls.

Principle 5: Comply with specifications and conventions

• Browser controls authored in HTML or similar standards must comply with WCAG. Also, user agents must support accessibility features, allow alternative viewers, and enable users to report accessibility issues.

Final words

Making the web inclusive and accessible to all may seem like an overwhelming task.

But it’s a challenge worth taking on, as its benefits extend beyond users with disabilities. Many web users–even those without disabilities–have found features like captions, text resizing, spell checks, documentations, and alt texts helpful. And as these advantages spill over to every web visitor and business online, everyone is able to enjoy a much better user experience.