Web Accessibility Standards: A Detailed Overview for Designers

Web Accessibility Standards: A Detailed Overview for Designers

The World Wide Web Consortium Web Accessibility Initiative (W3C® WAI) defines web accessibility as designing and developing websites, tools, and technologies so people with disabilities can use them.

It is crucial to ensure that the web remains accessible to people with disabilities, including those with auditory, cognitive, neurological, physical, speech, or visual impairments. This helps them to fully use the web and contribute their expertise to it. They can be developers, designers, and content producers rather than just being limited to being consumers of content and technologies.

The benefits of web accessibility extend beyond people with disabilities. Web accessibility resources and tools often focus on the experience of users with disabilities. However, everyone can benefit from them. For example, captions enable persons with poor hearing to access videos on the web. But these captions help other users as well. They can turn on the captions while watching the video in a noisy area. Those who are not fluent in the language used in the video can also read the captions to understand the content’s message thoroughly.



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 helps 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, audio, and videos, this includes the forms your users fill out, markup codes, and applications.
  • Authoring tools refer to software and services designers and developers use to build business websites, other online sites, and web content. These tools include content management systems (CMS), blogs, code editors, and document conversion tools.
  • User agents are the software that facilitates your users’ access to web content. Examples include browsers (desktop, mobile, voice), plug-ins, multimedia players, assistive technologies like screen readers and magnifiers, scanning software, and alternative keyboards.

How the components relate

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


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

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

Web Accessibility

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.

It is essential to meet Level A requirements, which cover basic accessibility features like providing images with alt attributes.

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 success criteria or accessibility requirement corresponding 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 examine these accessibility principles and guidelines in more detail. For each guideline’s success criteria and conformance levels, see the full WCAG 2.1 document here.

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 and sign language interpretations) for time-based media like live audio 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. These guidelines cover requirements on the use of colors, audio controls, contrast, text resizing, reflow, images of text, and text spacing.

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.

3: Information and user interface operation must be understandable.

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

4: Content must be robust enough to be interpreted by various 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 web designers, developers, writers, and other “authors” use to create 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 (WYSIWYG), 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 use authoring tools easily. 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.

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.

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.

A.3: Editing views are operable.

  • Provide efficient keyboard access to authoring features.
  • Provide authors with enough time. Authoring tools must have auto-save options, adjustable timing, static input components, and the ability to automatically save web content edits to aid authors who may have difficulty typing or processing information.
  • Help authors avoid flashing that can cause seizures by providing a static view option.
  • Enhance navigation and editing via content structure.
  • Enable text search for 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.

A.4: Editing views are understandable

  • Help authors avoid and correct mistakes by reversing content changes 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

B.1: Fully automatic processes produce accessible content.

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

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 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 options and identifying template accessibility.
  • Assist authors with accessible pre-authored content like clip art, user interface widgets, and sample videos.

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.

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 cannot be turned off or 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 primarily targets developers of these user agents or applications that render web content.

User-agent accessibility features ensure that browsers and applications—not just 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.

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) that 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).

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 the 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.

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.

4: Facilitate programmatic access

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

5: Comply with specifications and conventions

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

Final words

Ensuring that the web is inclusive and accessible to everyone can seem daunting, but it’s a challenge that’s worth undertaking.

The benefits extend beyond users with disabilities, as many web users without disabilities have found helpful features such as captions, text resizing, spell checks, documentation, and alt texts. When these advantages are available to all visitors and businesses online, everyone can enjoy a better user experience.

Table of Contents

Leave a Reply

Comment policy: We value comments and the time that visitors to our blog spend to give feedback. Please note that all comments are manually moderated and any deemed to be spam or promotional will be deleted.