The shop in this post is invented. A small team is about to put a checkout form on the public web. A customer will type a name, an address and a payment card, then press Pay. The team wants to know what to inspect before launch. A person who uses only a keyboard should be able to finish the order. The same is true for a person who listens with a screen reader.
We read the current Web Content Accessibility Guidelines, known as WCAG 2.2. It is a W3C Recommendation. The copy we used is the 12 December 2024 update of the standard first published on 5 October 2023. W3C advises using WCAG 2.2. A page that meets WCAG 2.2 also meets WCAG 2.0 and WCAG 2.1. Below are six checks, each drawn from success criteria in that standard.
These six checks do not prove that a page meets WCAG 2.2. For Level AA, the full page must meet every Level A and Level AA rule, or offer an approved alternate version.
Word key
- WCAG: a W3C standard with testable rules at three levels: A, AA and AAA.
- Screen reader: software that reads the page aloud, or sends it to a braille display.
- Keyboard focus: the control that will receive the next key press. A focus indicator is the visible mark that shows it.
- Accessible name: the text that a screen reader uses to identify a control.
Check 1. Can a person finish the whole checkout with only a keyboard?
2.1.1 Keyboard (Level A): everything must work with a keyboard alone. A mouse is still allowed, but a keyboard path must exist.
2.1.2 No Keyboard Trap (Level A): you must be able to leave any control you can enter. If the usual Tab or arrow keys are not enough, the page must say how to leave.
2.4.3 Focus Order (Level A): the tab order must still make sense as you move through the page.
Our advice: keep your hands off the pointer. Use Tab, Shift+Tab, Enter, Space and the arrow keys to fill every field. Open the address list, then reach Pay. If focus jumps, skips a field, or gets stuck in a date picker, the form is not ready.
Check 2. Can you always see which control has focus, and is it hidden behind a bar?
2.4.7 Focus Visible (Level AA): you must be able to see which control has keyboard focus.
2.4.11 Focus Not Obscured (Minimum) (Level AA): this rule is new in WCAG 2.2. A sticky header, cookie banner or chat bubble must not hide the focused control completely.
Our tip: tab through the form with those bars left on. If Pay or a field is fully covered, keep the focused control at least partly in view. A cookie bar that sits over Pay would fail this check.
Check 3. Does every field have a visible label that matches the name in the code?
3.3.2 Labels or Instructions (Level A): every field that needs input must have a label or a short instruction.
4.1.2 Name, Role, Value (Level A): software must be able to read each control's name and role.
2.5.3 Label in Name (Level A): the name in the code must include the words shown on the screen.
Our advice: a hint that vanishes when typing starts is a weak stand-in for a label that stays in view. If the button reads Pay now, the accessible name should include those words. Then a person who speaks commands can say Pay now.
Check 4. Is the text easy to see, and is color not the only clue?
1.4.3 Contrast (Minimum) (Level AA): normal text needs a contrast of at least 4.5 to 1. Large text may use 3 to 1.
1.4.11 Non-text Contrast (Level AA): buttons, borders and important graphics need a contrast of at least 3 to 1.
1.4.1 Use of Color (Level A): do not use color as the only way to show meaning.
Our tip: a red outline around a bad field is not enough on its own. Pair it with a text message. Measure the body text, the Pay button and the field borders against the ratios above.
Check 5. Do pictures and icon-only buttons have a text alternative?
1.1.1 Non-text Content (Level A): pictures and icons need a short text alternative that serves the same purpose. Decorative images can be hidden from assistive tools.
Our advice: a product photo needs a short description of what is in the picture. A card-brand mark that is only an image needs a name such as Visa. Do not leave the alternative text empty on a meaningful image.
Check 6. When something is wrong, is the problem described in text, and can the buyer review the order first?
3.3.1 Error Identification (Level A): if the form finds a mistake, it must name the field and describe the problem in text. A color change or icon is not enough on its own.
3.3.3 Error Suggestion (Level AA): if a fix is known, the form should suggest it. Do not do this if it would harm security.
3.3.4 Error Prevention (Legal, Financial, Data) (Level AA): a checkout must let the buyer review, fix or undo the order (at least one of these).
2.5.8 Target Size (Minimum) (Level AA): this rule is also new in WCAG 2.2. Buttons should be at least 24 by 24 CSS pixels, or have enough space around them.
Our tip: put Pay and Cancel far enough apart, and at least 24 by 24 CSS pixels. Then a shaky pointer is less likely to hit the wrong one. Then add a review screen before the payment is final.
Tick these off before the form goes live
- [ ] The full checkout can be completed with only the keyboard, with no focus trap and a sensible focus order.
- [ ] The focus indicator stays visible, and a sticky bar does not completely hide the focused control.
- [ ] Every input has a lasting label, and the accessible name contains the visible text.
- [ ] Text meets the 4.5 to 1 contrast ratio, or 3 to 1 for large text. Controls meet 3 to 1, and color is not the only cue.
- [ ] Meaningful images and icon-only buttons have a text alternative. Decorative images can be ignored.
- [ ] Errors are described in text, and known fixes are suggested.
- [ ] Pay and Cancel meet the minimum target size. The buyer can review the order before it is final.
Bring these questions to your product and engineering team
- Which controls still need a mouse, and how will we give them a keyboard path?
- What sticky bars or pop-ups could cover the focused field, and how will we test with them open?
- For each input, what visible label stays on screen, and what name will a screen reader speak?
- Which text and button colors fall short of the contrast ratios, and where do we still rely on color alone?
- After a failed Pay attempt, what text does the buyer hear or read, and can they correct the order on a review screen?
Read the docs yourself
- W3C, Web Content Accessibility Guidelines (WCAG) 2.2, W3C Recommendation 12 December 2024: https://www.w3.org/TR/WCAG22/
- Dated copy of that Recommendation: https://www.w3.org/TR/2024/REC-WCAG22-20241212/
- W3C WAI, WCAG 2 Overview: https://www.w3.org/WAI/standards-guidelines/wcag/
- W3C WAI, What's New in WCAG 2.2: https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/
- W3C WAI, How to Meet WCAG 2 (Quick Reference): https://www.w3.org/WAI/WCAG22/quickref/
- W3C WAI, Easy Checks — A First Review of Web Accessibility (a first look, not a full evaluation): https://www.w3.org/WAI/test-evaluate/preliminary/
Codewave Consulting LLC prepared this checklist from the public WCAG 2.2 Recommendation. It is not a conformance claim for any site, and it is not professional advice on your forms or legal duties. A qualified engineer or accessibility specialist should test your own pages before you go live. We are an E-Verified employer. We proudly support H-1B visa sponsorship for qualified resources. Eligibility is reviewed individually; sponsorship does not guarantee a role, selection or government approval.
What we build: Codewave Consulting LLC is a Direct Vendor for Whirlpool, based in Michigan. Along with IT staffing, we engineer digital products and develop custom software. See more at codewaveconsulting.com.
Top comments (0)