Accessibility guidelines

Introduction: Accessibility guidelines

The World Wide Web Consortium (W3C) Web Accessibility Initiative (WAI) develops web accessibility standards:

• Web Content Accessibility Guidelines (WCAG) addresses web content
• Authoring Tool Accessibility Guidelines (ATAG) addresses authoring tools
• Accessible Rich Internet Applications (WAI-ARIA) addresses web applications, dynamic content and advanced user interface controls

Web Content Accessibility Guidelines (WCAG)

The Web Content Accessibility Guidelines is technical standard document that explains how to make web content more accessible to people with disabilities.

Web “content” generally refers to the information in a web page or web application, including:

• natural information such as text, images, and sounds
• code or markup that defines structure, presentation, etc.

WCAG addresses barriers faced by a wide range of people with disabilities, including those with visual, auditory, physical, speech, cognitive and neurological disabilities.

These guidelines also address accessibility of web content on desktops, laptops, tablets and mobile devices. As well, these guidelines will make web content more usable to all users in general.

Versions

1. First introduced as version WCAG 1.0 in 1999. WCAG 2.0 standard was released in 2008. The current WCAG 2.1 standard was published in 2018.
2. WCAG 2.2 is scheduled to be completed and published in 2021. All criteria from 2.0 and 2.1 are included in 2.2. WCAG 2.2 has 9 additional criteria
3. WCAG 3.0 draft was published first published on Jan 2021. It introduces new conformance model: bronze, silver and gold.

WCAG 2.1 layers of guidance

Principles – There are 4 principles that provide the foundation for Web accessibility: perceivable, operable, understandable, and robust.

Guidelines - Under each principle are guidelines. The 13 guidelines ensure that content is directly accessible to as many people as possible, and capable of being re-presented in different forms

Success criteria - Under each guideline, there are Success criteria that describe what must be achieved to conform to WCAG. Success criteria are written as testable (true or false) statements that are not technology-specific. All Success criteria are important access issues for people with disabilities. Each success criteria is assigned a conformance level A, level AA (better), level AAA (best).

There are 50 Level A and AA success criteria in WCAG 2.1.

ESDC WCAG conformance level target

WCAG 2.1 at a glance

This section provides a paraphrased summary of WCAG 2.1.

Perceivable

• Provide text alternatives for non-text content.
• Provide captions and other alternatives for multimedia.
• Create content that can be presented in different ways, including by assistive technologies, without losing meaning.
• Make it easier for users to see and hear content.

Operable

• Make all functionality available from a keyboard.
• Give users enough time to read and use content.
• Do not use content that causes seizures or physical reactions.
• Help users navigate and find content.
• Make it easier to use inputs other than keyboard.

Understandable

• Make text readable and understandable.
• Make content appear and operate in predictable ways.
• Help users avoid and correct mistakes.

Robust

• Maximize compatibility with current and future user tools.

Information in this section is from the Web Accessibility Initiative (WAI) document: WCAG 2.1 at a Glance (W3C). Shawn Lawton Henry and Wayne Dick, eds. Copyright © 2018 W3C® (MIT, ERCIM, Keio). Status: Updated 5 June 2018.

Authoring Tool Accessibility Guidelines (ATAG)

What is ATAG?

The Authoring Tool Accessibility Guidelines (ATAG) 2.0 became W3C recommendation on 24 September 2015 which is now part of the World Wide Web Consortium - Web Accessibility Initiative (W3C-WAI). Authoring tools can help developers and assist users in the creation of accessible web content through proper design standards.

What are authoring tools?

Authoring tools are software and services used to create web content, including:

• Software tools for website management like Content management systems (CMS) platforms
• Tools designed to produce web content (e.g., What-you-see-is-what-you-get (WYSIWYG) HTML, XML editors)
• Websites that let users add content, such as blogs and wikis
• Tools that convert documents into web formats (e.g,, word processors)

How ATAG and WCAG are inter-related

Web developers usually use authoring tools and evaluation tools to create web content.

People use web browsers, media players, assistive technologies, or other “user agents” to get and interact with the content.

ATAG 2.0 at a glance

ATAG 2.0 is divided into two parts.

• Part A relates to the accessibility of authoring tool user interfaces to authors with disabilities.
• Part B relates to support by authoring tools for the creation of web content that is more accessible to end users with disabilities.

Part A) Make the authoring tool user interface accessible

1. Ensure both web-based and non-web-based functionality is accessible.
2. Editing views are perceivable by making alternative content available to authors
3. Ensure editing views are operable such as keyboard access to authoring features, provide text search of content, help authors avoid flashing content etc.
4. Ensure editing views are understandable by documenting the user interface, including all accessibility features and help authors avoid and correct mistakes.

Part B) Support the production of accessible content

1. Ensure that automatically specified content is accessible and is preserved.
2. Ensure content product is accessible by guiding and assisting authors in producing and managing accessible content and templates.
3. Ensure authors are supported in improving the accessibility of existing content by checking and repairing accessibility problems
4. Ensure that the authoring tools promotes proper documentation and integrate features in production of accessible content.

Information in this section is from the Web Accessibility Initiative (WAI) document: ATAG at a Glance. Shawn Lawton Henry and Wayne Dick, eds. Copyright © 2021 W3C ® (MIT, ERCIM, Keio, Beihang). Status: Updated 1 July 2020. First published July 2005.

Accessible Rich Internet Applications (WAI-ARIA)

WAI-ARIA, the Accessible Rich Internet Applications Suite, defines a way to make Web content and Web applications more accessible to people with disabilities. It especially helps screen reader users and keyboard users with dynamic content and advanced user interface controls developed with HTML, JavaScript, and related technologies.

WAI-ARIA provides a framework for adding attributes to identify features for user interaction, how they relate to each other, and their current state. With WAI-ARIA, developers can identify different regions of the page to enable screen reader users to easily move between regions. They can also create widgets such as buttons, drop-down lists, carousels, calendar functions, tabs, sliders, disclosures (show/hide), and others.

WAI-ARIA 1.2 technical specification, provides features to define accessible user interface elements and to improve the accessibility and interoperability of web content and applications. The WAI-ARIA technical specification is an occasional reference, for something like the definition of an ARIA attribute. It’s oriented primarily at user agent implementers.

ARIA Authoring Practices Guide, recommends approaches to help web application developers make widgets, navigation, and behaviours accessible using WAI-ARIA attributes (roles , states, and properties, described later in the course). The WAI-ARIA Authoring Practices is a commonly-referenced how-to manual with thorough design patterns for widgets, including expected keyboard interaction and behaviour and working examples with complete HTML, CSS and JavaScript.

Web Accessibility Toolkit (WET) equivalent widgets

The Web Accessibility Toolkit (WET) is an award-winning front-end framework of flexible and themeable templates and reusable components that are accessible, usable, interoperable, mobile friendly and multilingual.

WET implements widgets mostly in line with the patterns described in the WAI-ARIA Authoring Practices. Always check WET for a widget before designing one from scratch.

Web Experience Toolkit (WET) - Working examples - Web Experience Toolkit (wet-boew.github.io)