Study for the WAS exam by rehearsing decisions between competing techniques: native HTML versus ARIA, alert versus polite announcements, automated versus manual testing. Work short scenarios, name the governing concept, and score yourself against a rubric weekly.
Why success criteria, techniques, and failures are three different things
Success criteria state outcomes, techniques show one way to meet them, and failures document patterns that break them. Confusing these three makes every study question harder, because the same criterion can be satisfied by many techniques and broken in many ways.
When you study a criterion such as one governing non-text contrast or focus visibility, separate the requirement itself from the suggested code patterns. A sufficient technique is an example path, not the definition of passing. This matters in scenario questions because an answer option can use a technique name incorrectly, and you only catch that if you know what the underlying outcome demands.
Failure techniques deserve equal attention. They describe concrete, observable mistakes, such as removing an outline with CSS without providing an alternative indicator. Practicing failures trains a different skill than practicing sufficiencies: you learn to look at a snippet and name the exact harm it causes, rather than vaguely sensing that something is inaccessible. Build a habit of writing one sentence per failure describing who is affected and how.
- Success criterion: the testable outcome, written to be technology-neutral.
- Sufficient technique: one documented way to satisfy the outcome, not the only way.
- Advisory technique: an improvement that goes beyond the minimum requirement.
- Failure: a specific pattern that causes the outcome to be unmet.
- Self-check: for any snippet you study, can you name the criterion and the failure or technique without looking?
ARIA versus native HTML: the first-rule decision
Native HTML elements carry roles, states, and keyboard behavior for free; ARIA adds semantics only when you also implement the behavior yourself. The governing principle is simple to state and demanding to apply: prefer the platform element, then add ARIA only to fill a genuine gap.
A button element gives you focusability, activation with both Enter and Space, and an implicit role without a single line of scripting. Rebuilding that with a div, a role, and a tabindex attribute produces a component that looks equivalent in source code but fails the moment JavaScript fails to load or an author forgets a key handler. Scenario practice works exactly this gap between visual equivalence and behavioral equivalence.
Train the contrast with paired examples. Take an accordion built from headings and region landmarks versus one built entirely from ARIA roles and tabindex, and list what each version gives you automatically: heading structure, disclosure state, focus order. Then take a genuinely custom widget, such as a spreadsheet grid, where no native element fits, and note that ARIA becomes necessary plus an interaction pattern you must implement and verify. The skill to build is recognizing which situation you are in, not reciting the principle.
Worked scenario: the modal dialog that traps the wrong things
Dialog scenarios test focus management, not just roles. A correct answer must address moving focus into the dialog, keeping it inside while open, restoring it on close, and labeling the dialog so assistive technology announces it coherently.
Plausible mistake: an author adds role="dialog" and aria-modal="true" to a styled div but forgets focus handling. Now screen reader users may believe the background is inert while keyboard users can still tab straight into links behind the overlay, and on close, focus falls back to the document start. The role alone changed the announcement but none of the behavior, which is the exact failure mode of treating ARIA as a cosmetic layer.
Better decision: start from the native dialog element where the environment supports it, because it brings the inert background and focus behavior with it; otherwise implement the full contract explicitly, set aria-modal or manage background content, move focus to the first sensible element on open, cycle Tab within the dialog, close on Escape, and return focus to the invoking control. Why it matters: each missing piece produces a distinct, user-visible defect, and a single scenario can bundle several of them, so practice judging the whole contract rather than one attribute.
Live regions and announcements: choosing the right urgency
Dynamic content scenarios ask you to match announcement behavior to the situation: polite for status updates users can absorb later, assertive or alert roles for information that should interrupt. The live region must exist in the document before the update is injected.
Worked scenario: a search page updates its result count after each query. Plausible mistake: the developer injects a fresh status paragraph each time with no live region at all, so screen reader users never learn that results changed, or, swinging the other way, wraps every count in a role="alert", so minor updates interrupt mid-sentence everywhere on the site. Both choices come from not distinguishing the announcement classes.
Better decision: put a persistent, visually hidden polite live region in the markup from the start, and update its text content when the count changes. If a validation error must interrupt typing, that is a different situation and justifies a stronger mechanism. Why it matters: the difference between polite and assertive is not stylistic; it determines whether the user's current reading is interrupted. Practice by reading a component spec and writing down, before coding, what should be announced, when, and how urgently.
A comparison table for choosing a testing method
Each testing method finds a different defect class. Automated scanning, manual keyboard inspection, code inspection, and assistive technology passes are complements; treating any one of them as complete is the core mistake this table exists to prevent.
Use the table to answer scenario questions of the form 'which verification step is missing?' If a team ran only automated checks, contrast issues in custom widgets, keyboard traps, and confusing announcements all remain invisible. If a team ran only a screen reader pass on their own machine, they may have missed issues visible in a different technology combination or in a code review.
The table also doubles as a study index. When you finish a topic, ask which row would catch a defect in that topic and which rows would not. For example, an unlabeled form field is caught by several methods, while a focus order that makes logical sense only to sighted users is caught mainly by manual keyboard inspection. That mapping practice is faster than memorizing lists of what each tool can and cannot do.
| Method | Detects well | Misses | Best use |
|---|---|---|---|
| Automated scanning | Missing labels, absent alt text, some structural and markup problems | Anything requiring judgment: focus order, announcement clarity, meaningful alt text | Fast baseline sweep and regression checks across many pages |
| Keyboard-only inspection | Traps, missing focus indicators, illogical tab order, unreachable controls | Whether announcements make sense when read aloud | Verifying the interaction contract of every custom widget |
| Code inspection | Incorrect roles, states, and name associations before users ever see them | Real-world usability of a technically correct component | Root-causing issues found by other methods |
| Assistive technology pass | End-to-end announcement quality, state changes, and comprehension | Combinations of technologies you did not test | Final confirmation that the experience works as intended |
Accessible names: where the name actually comes from
An element's accessible name is computed from a defined order of sources, and several sources can be present on the same element at once. Build the habit of tracing the computation through labeled examples rather than guessing which source wins.
Worked scenario: an icon-only button has a title attribute, an aria-label, and a visible tooltip written with a CSS ::after pseudo-element. Plausible mistake: assuming the pseudo-element content or the title supplies the name. Tracing the computation shows the aria-label overrides the title, and content generated by CSS is a weaker, less reliable source, so the actual announced name may differ from the visible tooltip. Users who rely on speech input may say what they see and fail to reach the control.
Better decision: give the button a single authoritative name, prefer visible text where possible, and use the same string for the accessible name and any visible label so speech and screen reader users match on identical words. Why it matters: name computation errors are silent; the page looks and clicks fine with a mouse, and the defect only appears through other technologies. Practice by writing, for any control you study, its computed name, role, and value in one line before checking the answer.
An adaptable study sequence with a readiness rubric
Rotate through the topic areas in short cycles, pairing each topic with one worked scenario and one self-scored exercise. The sequence below is adjustable to your starting knowledge; the rubric defines what finished looks like for each cycle.
A workable cycle: weeks one and two, success criteria versus techniques versus failures, plus the native-HTML-versus-ARIA decision, ending in the paired-example exercise. Weeks three and four, dialogs, focus management, and live regions, with one written scenario per week. Week five, testing methods and name computation, using the table to map defects to methods. Week six, organizational integration topics and a full review of your scenario notes. Compress or extend each phase to fit your schedule rather than skipping it.
Keep a scenario log: for every exercise, record the plausible mistake, the better decision, the governing concept, and the reason it matters. Re-reading your own decisions is more efficient than rereading specifications, because it rehearses the judgment the material asks for. Note that the issuer's own site is the source for administrative details about the credential; this guide deliberately avoids restating them.
- Exercise: pick one component (accordion, modal, tab set, or data table) and run three passes: keyboard only, name/role/value inspection, then an assistive technology pass.
- Expected keyboard observations: every control reachable, no traps, focus visible at all times, focus starts and ends in sensible places.
- Expected inspection observations: you can state each control's computed name, role, and state without guessing.
- Expected assistive technology observations: state changes are announced once, at the right urgency, and you can complete the task without listening to the whole page.
- Self-check rubric: 0 = could not complete the task; 1 = completed with a defect you found yourself; 2 = completed cleanly; 3 = completed cleanly and you can explain the governing concept. Revisit any component scoring below 2 after one week.
References and further reading
Use these references to explore the concepts and check the latest information from the relevant organizations.