An adventurer’s guide to W3C specs

2019 has been a landmark year for web standards milestones: the World Wide Web Consortium (W3C) turned 25 this October, and it published the first version of the Web Content Accessibility Guidelines (WCAG) 20 years ago in May 1999. Across these past couple decades, the standards body has published quite a few sets of guidelines for implementing and using accessible technologies. As a person who makes websites, it can be a bit confusing to understand how all these guidelines are connected, and who they are for. If you, like me, have wanted to read up a bit more on accessibility-related standards but weren’t sure where to start, here’s a quick primer on some of the core documents.

Note: links in this article typically point to Editors’ Draft versions of documents, so that future readers can get up-to-date links; these drafts are the newest versions of specifications, so they may contain details that are not yet implemented in browsers or have not yet been fully ironed-out in the standards process.

The W3C: a group of groups

Before we dive into particular specifications, it may be useful to know a bit about the structure of the W3C standards body. The W3C is made up of several types of groups with varying objectives and responsibilities. Working groups build mature standards from experimental ideas, and there are a few such groups involved in accessibility-related specifications:

• The Accessibility Guidelines Working Group (AG WG) writes guidelines (the previously-mentioned WCAG) for creating accessible web content.
• The Accessible Platform Architectures Working Group (APA WG) is responsible for horizontal review of other W3C specifications, to ensure they can be implemented accessibly. The APA writes notes reviewing various web technologies and techniques, and also publishes specifications for Personalization of web semantics.
• The Accessible Rich Internet Applications Working Group (ARIA WG) is responsible for specifying ARIA roles, states, and properties. It publishes a couple other related documents as well.
• The Education and Outreach Working Group (EOWG) considers how to educate folks on accessibility initiatives.

Collectively, these groups are part of the Web Accessibility Initiative (WAI) at the W3C, and can collaborate with each other and with groups across the W3C. Additional working groups are responsible for determining the accessible semantics of their technologies—more on that later.

Let’s start with some guidance that is particularly helpful to the people who make websites.

Technology-agnostic accessibility guidance

If you’ve taken an interest in web accessibility, you may have come across the Web Content Accessibility Guidelines, or WCAG. While these guidelines are not exhaustive, they provide a great set of criteria for ensuring web content is perceivable, operable, understandable, and robust. WCAG is typically technology-agnostic: it doesn’t tell you how to use this or that attribute, but rather provides guidance like “information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text”.

That said, the Accessibility Guidelines Working Group (AG WG) does supplement these guidelines with technology-specific techniques in How to Meet WCAG. This document gives examples for meeting individual WCAG criteria—as well as examples which fail the guidance. Techniques for WCAG lists out the same techniques that are referenced from How to Meet WCAG, but are grouped here by technology instead of by criterion. If instead you’d like to dig into the “why” of WCAG guidance, Understanding WCAG can help.

It’s worth following along with the development of new WCAG versions via Web Accessibility Initiative (WAI) news or on the WCAG Github repo, as the criteria evolve to cover more use cases. For example, versions 2.1 and 2.2 focus in part on criteria supporting people with cognitive disabilities. Early insight can help you prepare your web content for new guidance.

Definition of accessibility-related technologies

While accessibility-centric groups at the W3C generate plenty of guidance for web professionals, the standards body at large is perhaps better known for the definition of web technologies. W3C Working Groups write charters where they declare which technologies they are responsible for designing. These technologies are then defined in separate specifications (often abbreviated as “specs”). A few specs related to accessibility include:

• Accessible Rich Internet Applications (WAI-ARIA): defines roles, states, and properties to provide semantic information to assistive technologies. There are additional modules of ARIA for more specific sets of use cases, such as Digital Publishing WAI-ARIA Module and WAI-ARIA Graphics Module.
• Personalization: provides further semantics to enable further user-driven personalization of web content; for example, assistive technologies (AT) could render a “home” icon next to a link marked as pointing to a home page. This draft specification is made up of separate modules which break down various different buckets of personalization: Personalization Semantics Content Module, Personalization Help and Support, and Personalization Tools.
• Pronunciation: the Pronunciation Task Force within the APA WG is considering how to bring better speech support to HTML.

Arguably, the primary use case of these specifications is to define a web technology specifically enough that 1) it can be implemented consistently across user agents (browsers) and 2) that standards folks can write tests to ensure the implementation is, in fact, consistent. Therefore, these specs tend to be fairly dense and a bit dry (with respect to W3C collaborators *wink*).

If you can get past the straightforward tone, it can be pretty useful to web developers to read these specs, as they codify how a feature will be interpreted by underlying technologies.

Some tips for reading specs as a web developer:

• If the spec includes a “Read Me First” section, spending time with this section can help clear up questions which often arise later.
• Some spec editors try to take a stepped approach towards spec complexity. They’ll start each section with high-level feature design information, then use the subsections to go deeper into the weeds. This can be a handy pattern to be aware of, if you find yourself reading information that’s deeper than you care to go. You can skip ahead to info at a higher heading level.
• “Authors” is what the W3C uses to refer to web developers, so any time you come across “authors must”, “should”, or “may”, those are particularly pertinent details for using the technology in your content.
• The ends of specs tend to house further implementation details and web standards housekeeping, and may only be worth a quick skim for any relevant information.

Guidance on the use of these technologies

To complement the definition of accessibility-related technologies, the W3C also publishes guidance on how web developers should use them. ARIA in HTML specifies the interaction between HTML and ARIA semantics (side note: ARIA is meant to extend the semantics of web languages like HTML; it’s best to use native HTML semantics wherever you can!). This includes documenting which ARIA roles, states, and properties may be used with which HTML elements and attributes. Incorrect use of ARIA in HTML could be flagged as an error in a conformance checker.

Some guidance is not necessarily meant to be treated as a binding standard, despite the connotation of a W3C logo displayed on the page. WAI-ARIA Authoring Practices is a “Note” in W3C parlance, and is meant to illustrate how to use ARIA with practical examples. The Authoring Practices do not cover all use cases, nor do they guarantee assistive technology (AT) or user agent (UA) support. They allude to how AT may enable interaction with a particular pattern, but do not lay out requirements for AT developers. Those who build assistive technologies, such as screen readers or braille displays, can innovate on top of accessibility platforms at their discretion, though many basic behaviors are similar between AT of a particular type.

Implementation details

Because the web platform functions as an intermediary layer between web developers and assistive technologies, web standards also specify how web semantics are mapped to accessibility APIs. These are platform-level APIs that AT use to retrieve and interact with the semantic content of a user application (such as a browser). “Semantics to Screen Readers” outlines further details on how this all works.

In W3C-land, these implementation details are called Accessibility API Mappings, or AAMs. The various languages and attribute suites have their own AAMs:

Some trivia: individual working groups have been responsible for providing a mapping spec for their technology. Accordingly, HTML-AAM, SVG-AAM, and the ARIA AAMs have traditionally been published by different working groups. Participants in the W3C have been rethinking this model, so the ARIA WG will soon own HTML-AAM. SVG-AAM and CSS-AAM will likely follow suit.

AAMs have tables that describe how elements or attributes should be reflected into various platform accessibility APIs. They can also include element-specific requirements for calculating an element’s name and description. The Accessible Name and Description Computation spec provides a generalized algorithm for this calculation, and is cross-referenced by naming rules in AAMs like HTML and SVG.

These documents primarily contain implementation details, and as a result are less useful to read if you’re making websites rather than writing browser or AT code. Where they could be helpful is if you run across something that seems like a bug in a particular browser. In this case, these specs could help you confirm whether that’s the case, or determine whether you need to adjust your code to get the accessible name or semantics you expect. Of course, what you read is up to you: if you want to geek out on the details, go for it! On the flip side, consulting the AAMs is not a requirement for filing a bug against a browser.

Whether you’d like to go deep on the details or start with overarching guidelines, the W3C specifications can be a great resource for building knowledge in web accessibility—alongside testing your experiences with assistive technologies (especially with AT users!). If you come across a use case that isn’t covered by available web technologies today, come join the web standards party by proposing a feature on the WICG Discourse forum! Inclusive web standards are ever-evolving, and you can be a part of that evolution.

Appendix: all referenced documents

Accessibility guidelines and supporting documents

• Web Content Accessibility Guidelines
• Supporting documents
  • How to Meet WCAG
  • Techniques for WCAG
  • Understanding WCAG
  • WCAG 2 Documents

ARIA and HTML

• Accessible Rich Internet Applications (WAI-ARIA)
• Digital Publishing WAI-ARIA Module
• WAI-ARIA Authoring Practices
• ARIA in HTML
• Using ARIA

Mapping specifications

• Accessible Name and Description Computation
• Core Accessibility API Mappings (AAM)
• dPub-AAM
• Graphics-AAM
• HTML-AAM
• SVG-AAM

Personalization

• Personalization Semantics Explainer
  • Personalization Semantics Content Module
  • Personalization Help and Support
  • Personalization Tools