Websites and stores
WCAG 2.2: checking whether people can use your website
Accessibility starts with an ordinary task: finding information, choosing an option or asking a question. WCAG helps describe barriers and acceptance conditions. A single scanner score cannot establish whether the whole process works for different people.
Define the task and assessment level
WCAG 2.2 is a W3C standard with A, AA and AAA criteria. Specify the version and target level in your brief. A broad claim of “WCAG compliance” is not an acceptance report: you need scope, method and documented results.
Select representative views and complete tasks, including navigation, search, products, checkout and contact. Include errors, confirmation states, third-party elements and mobile devices. Screenshots alone cannot show whether someone can move from one state to the next.
Turn the four principles into a real task
WCAG organises requirements around content being perceivable, operable, understandable and robust. In practice, translate these ideas into questions about one customer process. Can the visitor receive the service information, choose an option and continue? Do they understand conditions and errors? Do the browser and assistive technologies receive meaningful names, roles and states? An attractive screen in a design application cannot answer every question. Assessment needs working behaviour and real content together, including the states visitors encounter when something goes wrong.
For example, a registration form may have readable text but reveal a new field without a useful description after a date is selected. A screen-reader user may not know what changed. Someone else may see an error communicated only through a colour they cannot distinguish. Both issues affect the same task but require different corrections. Record the task and expected human outcome before assigning technical criteria. Code details help the developer; impact explains priority to the website owner and makes the eventual fix easier to assess.
What to review when moving from WCAG 2.1 to 2.2
Version 2.2 adds nine success criteria to 2.1 and removes 4.1.1 Parsing. Requirements have A, AA or AAA levels. The new criteria are not a complete audit by themselves. Existing contrast or keyboard problems still need attention. Record the standard version, target level, languages, processes and test environments in the commission. A statement that the website should comply with WCAG is too imprecise to define the work or establish how its completion will be evaluated by the people responsible for acceptance.
Pay particular attention to fixed bars, small adjacent controls, dragging and authentication. At AA, criterion 2.5.8 specifies a 24 by 24 CSS pixel target minimum with defined exceptions, including spacing. That does not mean every control should be designed exactly at the boundary. For example, a small remove icon beside an increase-quantity control needs practical phone testing as well as a standards assessment. Consider the risk of activating the neighbouring, opposite action. The dimensions of an icon and the clickable area around it are also different things to inspect.
| Criterion | Subject | Level |
|---|---|---|
| 2.4.11 | Focus not obscured - minimum | AA |
| 2.4.12 | Focus not obscured - enhanced | AAA |
| 2.4.13 | Focus appearance | AAA |
| 2.5.7 | Dragging movements | AA |
| 2.5.8 | Target size - minimum | AA |
| 3.2.6 | Consistent help | A |
| 3.3.7 | Redundant entry | A |
| 3.3.8 | Accessible authentication - minimum | AA |
| 3.3.9 | Accessible authentication - enhanced | AAA |
Test the menu, dialog and form without a mouse
Refresh the page and put the mouse aside. Use Tab to move forward and Shift+Tab to move back. Observe focus visibility, order and a way to bypass repeated navigation. Open the menu, expand options and reach the contact route. Check whether controls inside a closed panel remain accidentally available. Try a short browser window as well: a fixed bottom bar may cover the exact control currently in focus. Criterion 2.4.11 addresses components entirely hidden by author-created content when they receive focus.
For a dialog, record the starting location, how it closes and where focus returns. A close icon that merely resembles a button is not sufficient evidence. Reach every field, trigger an error and correct it without using the mouse. If the interface requires dragging, also inspect an alternative that does not require dragging. W3C covers this under criterion 2.5.7, with exceptions for essential actions or unmodified browser behaviour. Keyboard support alone does not resolve every pointer requirement, so record both routes rather than treating one successful interaction method as proof of all others.
Review contrast, enlargement and reading order
Criterion 1.4.3 requires at least 4.5:1 contrast for ordinary text and 3:1 for large text, subject to stated exceptions. Measure the actual foreground and background, including images, dark mode and errors. A colour approved on white may fail in another component. Record the measurement against its real use. Logos and decorative text have different assessment conditions from a paragraph explaining a service, so a single blanket decision for every element is unlikely to provide a reliable review.
Also inspect layout at a width equivalent to 320 CSS pixels. Reflow has exceptions for content requiring two dimensions, such as some tables. In practical terms, try reading a paragraph without repeatedly moving the whole page sideways. A table may need local scrolling but should not unnecessarily widen the website. Review headings, labels and reading order. When columns change order on a phone, the explanation should still make sense. Enlarging text must not turn a button label into an ambiguous clipped fragment that visitors need to infer from surrounding decoration.
Evaluate images and messages in context
A text alternative should fit the image’s function. W3C’s decision tree distinguishes decoration, information and images acting as controls. For example, an invoice screenshot in instructions may need to identify the relevant field, while a paper texture behind a heading adds no information. A non-empty alt attribute alone is not evidence of a useful description. “Image three” explains little, while repeating an entire adjacent paragraph can make listening harder. Ask the editor what someone needs to understand from the image to continue the task.
For forms, inspect labels, instructions before entry and identification of the actual problem. W3C’s notification tutorial covers clear messages connected to fields. For example, an invalid email should identify what needs correction rather than relying on a red border. Check success states too: does the message describe actual acceptance or only a browser action? Try empty submission, invalid input and a server failure using test data. These checks reveal whether someone can understand a failure, correct it and continue.
Inspect login and repeated data entry
Check support for password managers and pasting during authentication. W3C criterion 3.3.8 describes accessible authentication, including assistance mechanisms, alternatives and specific exceptions. It does not simply prohibit passwords. Ask how someone can complete the process without unnecessary remembering or transcription. Inspect registration, confirmation, another login and account recovery, because a barrier may appear only in the final step. An accessible sign-in screen has limited value if a person cannot recover access later or understand how to correct an unsuccessful attempt.
For example, a shop might allow password pasting but block a pasted verification code and require an address already supplied earlier. Assess these parts separately in the actual process. Record where the code comes from, what the visitor must do and the instructions after failure. Do not resolve the problem by removing account protection. Work with the person responsible for security to choose an accessible route. Security and usability require distinct evaluation, but they should be discussed together during design. Fixing one area should not weaken the other or merely move the difficulty into a mandatory telephone call.
Write findings that someone can reproduce and fix
A useful finding includes the address, page state, environment, steps, expected outcome and observed behaviour. Add task impact, the relevant criterion and evidence that avoids customer data. An example is: opening delivery choices with the keyboard prevents returning to the form, so checkout cannot continue. This is more actionable than a label saying ARIA error. The developer should understand the failure, and the reviewer should know how to verify the correction. A screenshot helps, but often does not capture the interaction that produced the barrier.
Prioritise by impact and reach. A shared menu problem may affect many pages, while a single payment issue can block the most important process. Group recurring defects but retain examples. After correction, repeat the dependent task and inspect other uses of the component. Do not close a finding merely because code changed. Distinguish corrected, unresolved and untested areas in the report. Untested does not mean problem-free. The report should tell the owner which customer tasks work and which remain blocked.
Keep accessibility in the publishing process
After the audit, prepare practical guidance for editors and designers: link naming, image descriptions, field labels and new component variants. Revisit recorded tasks before changing checkout, navigation or an external widget. Automation helps with repeatable checks, but human evaluation is still needed. Where possible, involve people with disabilities in task-based testing. Their participation is not automatically a certificate for the entire website; it provides evidence about particular activities and barriers that may be missed when reviewing code or inspecting a static page alone.
Start with a relevant customer process, a test environment and an owner for corrections. Define the audit scope and expected report before commissioning it. When contacting DigiDraft, include the address, important customer tasks, external modules and known problems. That supports a discussion about an assessment suited to the real service. Establish legal requirements separately for the business situation. WCAG is a technical standard; a positive tool result or a prepared declaration does not establish every legal duty. The useful result is a working process, documented corrections and a way to detect the barrier returning after the next update.
Questions and answers
Does a good scanner score prove WCAG 2.2 conformance?
It does not establish conformance for the whole site. A scanner can identify some issues, but manual tests of tasks, error states and assistive technology use are also needed. The report should specify the WCAG version, level, scope and evaluation method.
How do I start testing a website with a keyboard?
Put the mouse aside and use Tab to move through the menu, buttons and form; use Shift+Tab to move back. Check that you can see the focused element, open and close a dialog, and correct a form error. Record where a task becomes impossible to complete.
What should an accessibility issue report include?
Include the address, test environment, steps, expected behaviour and actual result. Explain the effect on the user, such as being unable to choose delivery. After a fix, repeat the full scenario rather than checking only the changed element.