What is WCAG?

WCAG, the Web Content Accessibility Guidelines, is the standard that most accessibility requirements point to, whether they come from a law, a procurement contract or an audit. When someone says a wallet or an exchange "needs to be accessible", they almost always mean it needs to meet WCAG at a particular level.

You don't need to memorize the document. This guide explains who writes it, how the versions relate, how a single requirement is structured, and where crypto products tend to fall short, so you can read WCAG with purpose and pick a sensible target.

Who publishes it

WCAG is published by the World Wide Web Consortium (W3C) through its Web Accessibility Initiative (WAI). The Accessibility Guidelines Working Group drafts it in the open, with public review periods, and each finished version becomes a W3C Recommendation, which is the W3C's term for a completed standard. It is free to read. The WAI overview page is the best starting point, and the full text of the current version lives at w3.org/TR/WCAG22.

WCAG is deliberately technology-neutral. It doesn't say "use a <button> element". It says that every function must work from a keyboard and that every control must expose a name, a role and its current state to assistive technology. How you achieve that in HTML, React or a native app is covered in separate supporting material.

Versions

The 2.x versions build on each other instead of replacing one another. Existing criteria keep their numbers and new ones are added, and the W3C states that content conforming to 2.2 also conforms to 2.1 and 2.0. For new work, target 2.2. The changes in WCAG 2.2 are usually small enough to adopt without a redesign.

You will also hear about WCAG 3. It is a working draft with a different structure, not a standard you can conform to today. The same goes for APCA, a contrast method explored for WCAG 3: it is interesting, but it is not part of WCAG 2.x conformance. The APCA comparison guide covers the difference.

How the document is organized

WCAG has four layers, and knowing them makes the text much easier to navigate.

1. Principles. Perceivable, Operable, Understandable, Robust. Every requirement sits under one of these.
2. Guidelines. Thirteen in WCAG 2.2, such as 1.4 Distinguishable and 2.5 Input Modalities. They describe goals and are not testable on their own.
3. Success criteria. Testable statements, each assigned a level (A, AA or AAA). These are what an audit checks, pass or fail.
4. Supporting documents. "Understanding" pages explain the intent of each criterion and its edge cases. "Techniques" list sufficient techniques, advisory techniques and documented failures. These are informative, which means you may meet a criterion in a way the techniques don't describe.

The numbering follows the layers. 1.4.3 Contrast (Minimum) is principle 1, guideline 4, criterion 3. The WCAG 2.2 quick reference lets you filter criteria by level and topic and links each one to its Understanding page, which is usually where your actual questions get answered.

The four principles, in a crypto product

Abstract principles become clearer with familiar failures attached.

Perceivable means people can take in the information through at least one sense. A token selector where each row is identified only by a logo image with no text alternative fails 1.1.1 Non-text Content. A portfolio that shows gains and losses only in green and red fails 1.4.1 Use of Color. Gray "Balance" labels at 3:1 on a dark card fail 1.4.3 Contrast (Minimum), which asks for 4.5:1 for normal text.

Operable means every function can be used, whatever the input method. A connect-wallet modal that can't be reached with the Tab key fails 2.1.1 Keyboard; one that captures focus with no way out fails 2.1.2 No Keyboard Trap. A 14 by 14 pixel copy button pressed right up against an explorer-link button fails 2.5.8 Target Size (Minimum). Removing the focus outline with no replacement fails 2.4.7 Focus Visible.

Understandable means content and behavior make sense. A failed swap that only says "execution reverted" leaves people with no idea what went wrong; 3.3.1 Error Identification and 3.3.3 Error Suggestion address that kind of problem when it comes from user input. Asking someone to type the recipient address again on the review step runs into 3.3.7 Redundant Entry.

Robust means the interface works with browsers and assistive technology, now and later. A custom network dropdown built from div elements, with no role and no expanded state, fails 4.1.2 Name, Role, Value. A transaction row that quietly switches from "Pending" to "Confirmed" without screen readers hearing about it is a 4.1.3 Status Messages problem.

Levels and conformance

Each success criterion has a level. To conform at Level AA, a page must meet every Level A and every Level AA criterion. AA is the usual target, and AAA is rarely required as a whole. Conformance is claimed for full pages and complete processes, so a swap that spans several screens only conforms if every step does. The guide to levels A, AA and AAA goes into what that means for a multi-step flow and for third-party widgets.

Why it matters for crypto products

Crypto interfaces have all the usual web accessibility problems plus a few of their own.

• Many actions are irreversible. Someone who can't read the recipient address, the amount or the network on a confirmation screen can't undo the result afterwards.
• The data is dense. An Ethereum address is 42 characters of hex, amounts can carry 18 decimals, and prices update every few seconds.
• Interfaces lean on icons. Token logos, chain badges, copy buttons and explorer links often appear with no visible text.
• Key steps happen in components you don't fully control, such as wallet connection libraries and the wallet's own signing screens.

There is also the formal side. Laws, public procurement rules and enterprise contracts in many places reference WCAG, usually Level AA of a specific version. In the EU, the European Accessibility Act applies from 28 June 2025. Whether any of this applies to your product is a question for a qualified lawyer; this guide is general information, not legal advice.

Where to start

If your product has never been checked against WCAG, this order finds the most serious problems first:

1. Run an automated checker on your main screens. It catches missing names and many contrast failures, but only a portion of all issues. See tools for testing accessibility.
2. Put the mouse away and complete a real task with the keyboard: connect, pick a token, enter an amount, review and confirm.
3. Check the contrast of secondary text, icons and focus indicators.
4. Give every icon-only button an accessible name.
5. Make sure transaction status changes are announced, not just shown.

Then open the quick reference, filter it to Level A and AA, and work through the criteria that apply to your screens one at a time.