Accessibility and Inclusive Design Guidelines

Let users obtain information, complete operations, understand consequences, express decisions, and continue after an error or interruption. Accessibility is the quality of a complete task, not an add-on toolbar or a checklist score.

These guidelines apply to Web, native applications, and devices with a digital interaction interface, covering content, controls, flows, assistive technology, personal settings, and service pathways. Permanent, temporary, and situational impairments are all within design scope; users are not required to first declare age, health condition, or disability status.

The full text is organized into 55 rules across nine categories of design object. Each answers three questions: what design must decide, what implementation must guarantee, and how the user knows it has taken effect. The companion Design Token expresses reusable parameters, and Reference Sources states the basis and evidence boundaries.

Web adopts WCAG 2.2's A and AA requirements as the baseline target; Appendix A selects criteria that are easily misused and cannot substitute for a full standards assessment. Native applications and devices implement item by item per the target platform's accessibility mechanisms, and CSS px is not treated directly as dp or pt. This document's requirements for complete tasks, inclusiveness, and assistance are product design requirements; they do not constitute a determination of legal conformance, medical diagnosis, or legal-representative qualification.

1. Principles and rule index¶

2. Use and judgment¶

MUST / MUST NOT are the baseline once the applicable condition holds; SHOULD is a recommended requirement, and deviation MUST have the reason, alternative measure, and verification recorded; MAY indicates an optional implementation. Examples do not restrict the component or architecture used. Standard thresholds, platform recommendations, and these guidelines' product requirements are each labeled separately and must not impersonate one another.

Select the complete task first, then judge applicability clause by clause. Any inapplicability or standard exception MUST have the object, condition, basis, affected users, and effective alternative recorded; "no relevant users," "a third party built it," and "the tool reported no error" do not constitute an exemption. Turning off a capability through configuration can only lift that capability's conditional obligation — it cannot cancel base reachability.

Acceptance items use pass/fail/unverified/not-applicable + reason. Judgment is based on actual behavior and scope evidence; missing material must not be filled in as pass, and a known blocker cannot be offset by another item's score. User research supports a usability judgment for a specific task and use context; it does not extrapolate that everyone can use it.

Look up rules by task¶

3. Rules in detail¶

AC1 Information is perceivable¶

Let information remain complete, timely, and distinguishable across different sensory conditions.

AC1-1Information does not depend on a single perceptual attribute¶

Applies tostate, result, alert, classification, and operating instructions.

Requirement: Information conveyed only through color, position, orientation, or sound MUST be supplemented with text, shape, or structure; visual content MUST have semantics that assistive technology can convert. Equivalence is judged by meaning and task outcome, not by the number of cue forms. Pure decoration carries no information obligation.

Design applicationAn error gives the field name, cause, and marker together; it states "choose Submit," not just "press the green button on the right."

Verification

• User side: with sound off and color differences removed, the result and next step can still be recognized.
• Implementation side: check the meaning, carrier, semantics, and alternative entry for every item in the state list; there must not be only another color.

CounterexamplesUnder-delivery: a red/green light is the sole success indicator; over-delivery: every success simultaneously vibrates, rings, and flashes the screen.

AC1-2Alternative text conveys purpose and content¶

Applies toimages, icons, charts, canvases, and text in images.

Requirement: A text equivalent MUST be provided per purpose; decorative images are excluded from assistive-technology reading, and functional images state the action. A complex chart provides a summary and traversable data or structure, preserving units, trends, anomalies, and uncertainty. When text can be expressed as real text, it is not replaced with an image; an automatically generated critical description MUST be verified.

Design applicationA trend chart provides its main conclusion and a data table; a button name states "download the bill," not "down arrow."

Verification

• User side: the same decision can be made without seeing the image, and the data supporting the conclusion can be found.
• Implementation side: check that the alternative content is consistent with the chart's source data, filter conditions, language, and update state.

CounterexamplesUnder-delivery: a chart's description is just "image"; over-delivery: adding a read-aloud description to every decorative line.

AC1-3Media provides equivalent content by information type¶

Applies toprerecorded, live, audio-only, video-only content, and players.

Requirement: Captions, transcripts, and audio description MUST be distinguished. When Web adopts the AA target, prerecorded video with audio provides synchronized captions, live synchronized media provides real-time captions, and important visual information not stated in the audio track of prerecorded video is given audio description; audio-only and video-only content each provide an alternative for their own information. A transcript must not universally substitute for captions or the audio description required for AA. Record the specific exceptions the standard allows; "captions to be added later" is not treated as a pass.

Design applicationCaptions include the speaker and meaningful non-speech sound; the player's pause, captions, volume, and seeking can be operated by keyboard and assistive technology.

Verification

• User side: follow along muted; understand the operating steps without seeing the picture; for live content, know whether captions are delayed or failed.
• Implementation side: check synchronization, occlusion, proper names, numbers, and audio-description coverage section by section; record media-asset and player testing separately.

CounterexamplesUnder-delivery: the narration says "as shown" with no description; over-delivery: producing lengthy captions for a decorative animation that carries no information.

AC1-4The meaning of an alert is obtainable and reviewable¶

Applies tosound, vibration, light, screen notifications, and screenless products.

Requirement: The meaning, urgency, follow-up action, and use context covered by each path of an alert MUST be defined. At least one path not dependent on vision and one not dependent on hearing MUST be supported; when coverage of multiple sensory impairments is declared, tactile, braille, or another feasible path MUST additionally be verified. Alert encodings MUST be queryable; sensing a vibration must not be taken as understanding the message.

Design applicationThe device retains an accessible event record alongside the alert; when away from the device, a vibration is not recorded as delivered.

Verification

• User side: test the combinations of muted, invisible, not-held, and any declared coverage separately, confirming the meaning and a handling entry can be found.
• Implementation side: check that the three states — transmitted, presented, and read-confirmed — are not conflated; once a user turns off a channel, follow that choice.

CounterexamplesUnder-delivery: two short pulses and one long pulse mean a fault, with no query entry; over-delivery: forcibly enabling every channel with no way to turn them off.

AC1-5Text and controls are distinguishable¶

Applies totext, graphics, control boundaries, and each interaction state.

Requirement: The applicable contrast baselines in Appendix A MUST be met; tested against the actual foreground-background combination and the composited result of transparency, covering light, dark, selected, hover, error, and focused states. Placeholder text is prohibited as the sole label. Exempted elements MUST be documented item by item; a usable control with low contrast must not be marked disabled to evade detection.

Design applicationColors are defined in pairs by usage; an error includes text; text over a background image has a stable backing color.

Verification

• User side: a low-vision user can identify necessary information; selection and focus remain distinguishable under forced-colors mode.
• Implementation side: compute the contrast of the actually rendered combination and check the boundary; an isolated color value in the palette alone must not be verified.

CounterexamplesUnder-delivery: the input placeholder is too light to read; over-delivery: bolding every decorative divider until it seizes attention.

AC1-6Equivalent content stays synchronized with the facts¶

Applies tosummaries, charts, captions, translations, exported files, and alternative paths.

Requirement: When the primary content changes, every equivalent expression carrying the same task fact MUST be updated in sync. Content that failed to generate or has not been verified MUST be marked unavailable or pending verification, with an effective alternative provided; stale content must not be treated as the current equivalent information. Third-party components and exported documents MUST be included in the task scope.

Design applicationFiltering a chart updates the data table in sync; a report download preserves headings, table relationships, and reading order.

Verification

• User side: after switching a filter, the same result is read from both visual and non-visual paths.
• Implementation side: check against the source object, generation state, and publication; record the blocker and workaround when synchronization is not possible.

CounterexamplesUnder-delivery: the chart has updated while the description still references old data; over-delivery: re-announcing every meaningless layout change.

AC2 Operations are completable¶

Give every task a discoverable, exitable, complete path that does not depend on fine motor control.

AC2-1A task has a complete keyboard and alternative-input path¶

Applies totasks with an operable interface, including sign-in, settings, submission, undo, and exit.

Requirement: A Web function MUST be operable through a keyboard interface and MUST NOT require a specific key timing; a native product MUST support the declared platform's assistive input. The path MUST cover the entire process — "the home page works" must not be taken to imply third-party payment also works. An exception is recorded only for the part whose function is essentially dependent on a movement path; companion settings and submission MUST still be reachable.

Design applicationFirst draw a complete task path without using the mouse, then check switch control and voice control.

Verification

• User side: complete the task and exit using only the target input method, with no step that requires finding someone to click on the user's behalf.
• Implementation side: check event bindings, disabled states, and third-party embeds; verify it is not merely adding a focusable attribute to an element.

CounterexamplesUnder-delivery: the form can be filled in but the CAPTCHA can only be dragged; over-delivery: putting every static paragraph into the Tab sequence.

AC2-2Focus is visible and not obscured¶

Applies tokeyboard input focus, the active item of a composite control, floating bars, and the on-screen keyboard.

Requirement: Input focus and a container's active item MUST be managed separately, without forcibly syncing the assistive-technology reading position. Keyboard focus MUST have a clear visual indicator and be programmatically determinable. Web AA MUST NOT at minimum be entirely obscured by author-created content; these guidelines further require that necessary operation targets be fully visible, actively accommodated when an overlay, on-screen keyboard, or fixed bar appears. The AAA threshold for focus appearance must not impersonate the AA condition.

Design applicationAdjust the scroll position when an input field receives focus; mark focus with an outline or shape in addition to color.

Verification

• User side: navigate item by item after zooming in, always knowing the current position and the action that will trigger.
• Implementation side: check the focus rectangle against obscuring regions; test high-contrast color schemes, nested scrolling, and screen edges.

CounterexamplesUnder-delivery: focus sits behind a fixed footer; over-delivery: forcibly scrolling continuously to follow the reading position.

AC2-3Order and structure are consistent¶

Applies tomulti-column layouts, menus, toolbars, forms, and composite controls.

Requirement: Focus order MUST preserve meaning and the order of operation; visual rearrangement must not break comprehension. An ordinary page uses natural order; a composite control uses arrow keys and active-item management per its role; structure must not be patched with a batch of positive tabindex values. Static content is reached through reading navigation, and a necessary heading target may be programmatically focused.

Design applicationA toolbar provides one Tab entry per mode plus arrow keys within the group; heading order reflects the hierarchy.

Verification

• User side: the next focus can be predicted and repeated navigation is skipped, with no need for dozens of Tab presses to reach the body content.
• Implementation side: check the DOM/semantic tree, visual order, and keyboard sequence against each other; cover narrow screens and changes in language direction.

CounterexamplesUnder-delivery: the visually first item is the last to receive focus; over-delivery: breaking a menu's arrow-key operation to unify Tab behavior.

AC2-4A modal is exitable and focus is not seized¶

Applies todialogs, drawers, editors, media, and embedded content.

Requirement: Focus MUST NOT be seized by an advertisement, background refresh, or ordinary notification. When a genuine modal opens, place focus in a suitable position, restrict background interaction and assistive-technology access, and provide an operable way to exit; after closing, return to the triggering control or a reasonable substitute position. A non-modal overlay must not hide the whole page's semantics merely because it is visually covering it.

Design applicationA dialog can be closed with a close button and, where applicable, Escape; a long explanation may focus its heading first.

Verification

• User side: enter from the original location, operate, cancel, and return to the original task; the same input method can both enter and exit.
• Implementation side: check the modal layer stack, background-inert behavior, embed boundaries, and post-close focus; a mask drawn visually alone is not sufficient.

CounterexamplesUnder-delivery: focus enters a third-party editor and cannot get out; over-delivery: an ordinary tooltip also locks the whole page.

AC2-5Content changes leave a reasonable landing point¶

Applies todeletion, pagination, step transitions, partial loading, and dynamic lists.

Requirement: When a user action causes a structural change, the next focus MUST be defined; after deleting the current item, land on the adjacent item or the list container, a step transition lands on the new step, and when the trigger disappears choose a meaningful substitute point. Expanding inline content usually keeps the trigger point and does not always jump in. A background change preserves the current position, and a necessary result is notified through a status message.

Design applicationAfter deleting the last item, focus the newly added entry in the empty state; after pagination, land at the start of the list.

Verification

• User side: after the operation, know what happened and be able to continue, without being returned to an unrelated page top.
• Implementation side: verify focus, the active item, and announcement de-duplication after node unmounting, per change event.

CounterexamplesUnder-delivery: focus is dropped onto the body after a deletion; over-delivery: moving focus to the success message on every auto-save.

AC2-6A complex action has a simple alternative¶

Applies todragging, multi-touch, path gestures, long-press, and device motion.

Requirement: Dragging MUST provide both a keyboard path and a single-pointer no-dragging path; the two must not substitute for each other. A multi-touch or path gesture provides a simple single-pointer operation, motion-actuated input can be turned off with a control alternative, and an exception essential to the function or to the assistive technology's own operation is recorded separately. The alternative may be several simple taps; not every task is required to be compressed into one step.

Design applicationReordering provides "move up/move down" or choosing a target position; a map provides zoom buttons.

Verification

• User side: complete the same operation separately by keyboard and by single-pointer tap, with the alternative entry discoverable.
• Implementation side: test that the result is consistent after gestures are turned off; timing-determination parameters follow platform settings or have a non-time-limited alternative. The keyboard path and the single-pointer non-drag path each form their own evidence and do not substitute for each other; automated scanning can find only some marking errors and cannot substitute for focus comprehension, screen-reading order, and assistive-operation testing across a complete task; retain a scope statement for uncovered devices and assistive technologies, and do not extrapolate full accessibility from one combination.

CounterexamplesUnder-delivery: only dragging and a keyboard shortcut exist, with no click alternative; over-delivery: removing every convenient gesture in the name of being gesture-free.

AC2-7A target is hittable and a mis-tap is cancelable¶

Applies tobuttons, icons, links, sliders, and touch interaction.

Requirement: The actual hit area MUST meet the platform baseline in Appendix A and must not overlap another. A single-pointer operation completes on release by preference, with movement-out cancellation allowed after press-down; a necessary action triggered on press-down MUST provide cancellation or undo with the reason recorded. Enlarging a hit area must not cover an adjacent control.

Design applicationA small icon keeps its visual size but has an enlarged hit area; a delete operation executes on release and can be undone.

Verification

• User side: a target can still be selected with unsteady hands; moving away after pressing down does not cause a mistaken submission.
• Implementation side: measure the actual hit area rather than the icon size; cover target adjacency, edges, scroll conflicts, and pointer cancellation.

CounterexamplesUnder-delivery: invisible hot zones of adjacent icons overlap; over-delivery: expanding the hot zone without limit, causing mis-taps on blank space.

AC2-8Shortcuts and hover content are controllable¶

Applies tocharacter-key shortcuts, tooltips, hover cards, and focus-triggered popovers.

Requirement: A shortcut triggered by character keys alone MUST be able to be turned off, remapped to include a non-character key, or take effect only while the corresponding control is focused. Additional hover content MUST be dismissible, hoverable into, and persist until the user moves away or actively dismisses it, once the applicable conditions hold; the user must not be required to chase the content within a brief time window.

Design applicationVoice input does not trigger a global "delete" key; a popover can be closed with Escape and can be moved into and its links clicked.

Verification

• User side: read, move into, and operate the popover after zooming in; dictated text does not mistakenly trigger a function.
• Implementation side: verify the trigger scope and dismissal under keyboard, pointer, and assistive input; retain the necessary exceptions the standard permits.

CounterexamplesUnder-delivery: saying a single letter triggers a shortcut; over-delivery: disabling every platform shortcut.

AC3 Semantics are understandable¶

Give assistive technology accurate semantics, and notify changes at the pace of the task.

AC3-1Semantics match actual behavior¶

Applies tonative and custom-built controls.

Requirement: Native semantics suited to the purpose MUST be used preferentially. Once a custom-built control declares a role, it MUST implement the corresponding keyboard behavior, state, and value; missing interaction must not be patched with an ARIA name. A still-focusable element must not be hidden, and a decorative element must not be made operable.

Design applicationA switch has a name, a switch role, and a switch state together; a custom menu implements expected navigation.

Verification

• User side: the announced role matches the result of the key operation.
• Implementation side: check the semantic tree and actually operate it — both the role declaration and the listened event are verified.

CounterexamplesUnder-delivery: a div declares "button" but does not respond to space; over-delivery: overriding a native button's semantics to turn it into a menu item.

AC3-2A name includes the visible label and necessary context¶

Applies tobuttons, fields, repeated list operations, and voice control.

Requirement: The accessible name MUST state the purpose, in the full word order that includes the visible label; object context may be appended. The same action can reuse a name, but when the objects differ, they MUST be distinguishable by name and programmatic context. Required, invalid, expanded, selected, disabled, and value MUST be genuinely obtainable — state must not be forced into a name that cannot stay in sync.

Design application"Delete Zhang San's address" retains the visible "Delete"; a field label stays persistently present.

Verification

• User side: speaking the name seen is enough to locate it; a screen reader can distinguish the objects of multiple delete buttons.
• Implementation side: check the source of the computed name and its state, and re-verify after switching language and state.

CounterexamplesUnder-delivery: the screen shows "Save" while the screen reader announces "Continue"; over-delivery: the name repeats the role and a whole paragraph of description aloud.

AC3-3State-change notification is proportionate¶

Applies toasynchronous submission, progress, errors, notifications, and background completion.

Requirement: A necessary status message that does not move focus MUST be perceivable by assistive technology. An ordinary result is queued for notification; only an urgent event needing immediate handling interrupts. Progress may be aggregated, but a final result, error, or pending item must not be swallowed. Provide a persistent query location, avoiding duplicate announcement between a focus notification and a live region.

Design applicationA successful submission is politely announced once with the receipt retained; a failure announces the reason and a retry entry.

Verification

• User side: not repeatedly interrupted by a percentage while filling in, but still informed when submission fails.
• Implementation side: test the actual screen-reader output and state events; check that the busy state ends, announcements are de-duplicated, and the empty-to-non-empty transition is handled.

CounterexamplesUnder-delivery: an error appears visually with no semantic update; over-delivery: every notification uses assertive.

AC3-4Structure and relationships are traversable¶

Applies toheadings, regions, forms, tables, lists, and long pages.

Requirement: A genuine heading hierarchy, regions, and skippable repeated content MUST be provided; field labels, descriptions, errors, group headings, and header relationships MUST be programmatically determinable. A complex data table preserves row-column context, and a layout container is not disguised as a data table. Cross-page search or a table of contents SHOULD help users locate long content.

Design applicationA form uses group headings; an error summary can jump to the corresponding field; a data table states its units.

Verification

• User side: can navigate by heading and understand values by header, without traversing the entire page item by item.
• Implementation side: check whether relationship IDs are valid, table merge relationships, and jump targets; a mobile layout still preserves meaning.

CounterexamplesUnder-delivery: a table is just a number of aligned divs; over-delivery: making every small card a top-level landmark.

AC3-5Language, direction, and input purpose are determinable¶

Applies tomultilingual pages, mixed language, bidirectional text, and personal-information forms.

Requirement: Web MUST declare the language of the page and any necessary passages; native applications use the platform's corresponding mechanism. A language switch MUST keep the name, description, and error in sync. Dates, numbers, and addresses are formatted explicitly per context; bidirectional text is correctly isolated, and an amount or account number must not be reversed. A field whose input purpose is recognizable provides the appropriate autofill semantics without restricting reasonable forms of name and address.

Design applicationA name field allows reasonable characters; an international phone number states the area code explicitly; example dates explain the year-month-day order.

Verification

• User side: a screen reader correctly reads different languages; a user can enter their real name and the format is recognized.
• Implementation side: check lang, dir, autocomplete, or the platform-equivalent attributes, testing long translations and mixed direction.

CounterexamplesUnder-delivery: a Chinese page is read as English; over-delivery: forcibly switching the voice for every foreign proper name.

AC3-6Streaming and virtualized content is navigable¶

Applies tolive logs, chat, streaming generation, infinite lists, and virtual grids.

Requirement: A stable current reading item and operation target MUST be preserved; the user's position must not be lost because an off-screen node was recycled. Streaming content is notified by complete semantic segment or stage, with follow-pause, review, the final result, and an abort state provided — it must not be announced character by character. A virtual list exposes a reasonable position and total; an unknown total MUST be represented truthfully, and a usable pagination or load-on-demand path is provided where necessary.

Design applicationAuto-stick-to-bottom stops once the user scrolls up to read; new messages are indicated with a "new content" entry.

Verification

• User side: reading old content is not stripped of position by new content, and the final result remains fully accessible.
• Implementation side: simulate high-frequency updates, node recycling, stream interruption, and recovery; verify the active-item reference always remains valid.

CounterexamplesUnder-delivery: a node being read is reused for another message; over-delivery: freezing the result forever just to keep the position stable.

AC3-7Third-party components and fix-ups carry the same requirement¶

Applies tocomponent libraries, embedded controls, overlays, and automatic semantic fixes.

Requirement: The final interaction and semantics MUST be accepted for review — usability must not be declared just because a tool was installed. A fix must not override a user preference or create a duplicate control; the base task MUST still be reachable after an optional assistive layer is turned off. When a third party blocks a critical path, it MUST be fixed, replaced, or given an equivalent entry — stating the limitation does not substitute for a completed path.

Design applicationTest the keyboard and captions before procuring a player; replace an inaccessible CAPTCHA.

Verification

• User side: registration and submission still work after an assistive plugin is turned off.
• Implementation side: check the semantic tree, events, and focus conflicts before and after injection, and track the party responsible for the defect.

CounterexamplesUnder-delivery: a toolbar is used in place of fixing the form; over-delivery: forcibly overlaying a whole second interface on a usable native control.

AC4 Comprehension and recovery are sustainable¶

Let users understand and decide at their own pace, and come back from interruption or error.

AC4-1Time limits are adjustable and progress is not lost on expiry¶

Applies toauthentication validity, business deadlines, and draft retention.

Requirement: The three kinds of deadline and their starting points MUST each be stated separately. An adjustable time limit provides a path meeting the applicable standard — turning off, adjusting, or extending before expiry; a non-adjustable item records the actual exception, such as a real-time event or necessity, item by item — "security requires it" alone is not sufficient. Perceivable notice is given before expiry; an expired authentication does not continue to use a stale credential, and after re-authentication, permitted non-sensitive input is restored.

Design applicationA countdown and an "extend" entry can be discovered by a screen reader; a draft is not destroyed together with the authentication.

Verification

• User side: can continue after pausing or switching apps; does not have to refill the entire form when re-signing-in is required.
• Implementation side: inject a near-expiry condition with a controllable clock, checking the extension count, the warning window, and state preservation.

CounterexamplesUnder-delivery: it clears automatically with no notice; over-delivery: keeping an expired authorization valid just to preserve progress.

AC4-2Information is not requested again across steps¶

Applies tomulti-step forms, comparison, and confirmation.

Requirement: Information already entered or provided within the same process MUST be auto-filled or offered for selection; an exception for task necessity, security, or information that has become invalid MUST be explicitly recorded. Information that needs comparing is available at the current location; "enter it again" must not be treated as the default confirmation method.

Design applicationThe confirmation page shows an editable summary, retaining the chosen address rather than forcing the user to remember it.

Verification

• User side: can review and edit without transcribing or repeatedly recalling numbers.
• Implementation side: check data binding between prior and later steps, its source, invalidation judgment, and retention after going back.

CounterexamplesUnder-delivery: the next step asks for the same address again; over-delivery: auto-carrying in all unrelated historical data.

AC4-3Authentication does not rely on a cognitive test as the only path¶

Applies tosign-in, multi-factor authentication, account recovery, and human verification.

Requirement: A valid path requiring no memorization, transcription, or puzzle-solving MUST be supported, or an assistive mechanism that can complete that cognitive step MUST be provided; password managers, autofill, and pasting are allowed, and a verification code supports full pasting or platform fill. Each step is verified separately. An auditory puzzle must not simply be added alongside a visual one. These guidelines prefer a path that does not depend on recognizing images; a standard-permitted image-recognition exception must not be called fully usable.

Design applicationPassword fields have correct semantics; an accessible credential or device-confirmation path and account recovery are provided.

Verification

• User side: can sign in without memorizing a password or hand-copying a verification code, and can recover when a device is unavailable.
• Implementation side: check paste interception, split input boxes, multi-factor redirects, and the alternative entry after a risk-control block.

CounterexamplesUnder-delivery: pasting is disabled and only a memorized verification code works; over-delivery: cancelling all identity verification in the name of accessibility.

AC4-4Explanations are clear and respectful of the user¶

Applies totask copy, terminology, confirmation, error, and content expression.

Requirement: Necessary conditions and consequences MUST be stated at the point of action, not hidden in a long agreement; terms SHOULD be explained in familiar words and explicit actions. Simplified wording must not drop restrictions, cost, or uncertainty; age, capability, or language level must not be used for a derogatory or infantilizing label. Important information SHOULD allow expand-on-demand and repeated reading.

Design application"The address is missing a house number, please add it" replaces "invalid parameter"; a technical abbreviation is explained the first time it appears.

Verification

• User side: a target user can state what will happen and what to do next.
• Implementation side: check every button, description, and actual action against each other; check comprehension through task interviews, not a readability score alone.

CounterexamplesUnder-delivery: only an internal error code is shown; over-delivery: hiding a critical risk in the name of "simplicity."

AC4-5An error can be located, corrected, and retried¶

Applies toinput validation, submission failure, and partial success.

Requirement: The object in error, the cause, and a workable next step MUST be stated, and a programmatic relationship between the error and the field MUST be established. After submission, the error summary or the first error may be focused, avoiding repeated interruption; other valid input is preserved during correction. When the result is unknown, check the actual state before retrying — a false failure report must not lead to a duplicate charge or submission.

Design applicationThe error summary links to the field; an unknown result shows a query and recovery entry.

Verification

• User side: can fix errors independently without redoing everything; knows which items already succeeded.
• Implementation side: inject validation failure, network disconnection, and partial submission, checking the persistent state and the duplicate-prevention mechanism.

CounterexamplesUnder-delivery: a red box with no explanation clears the form; over-delivery: interrupting the read-aloud to report every character typed as an error.

AC4-6Distraction is suppressible and flashing is constrained¶

Applies toanimation, carousels, sound, auto-refresh, and dynamic backgrounds.

Requirement: Movement, flashing, or scrolling content that starts automatically, lasts more than 5 seconds, and runs alongside other content MUST be pausable, stoppable, or hideable, with a necessary-activity exception requiring proof; auto-updating information provides control per the standard. Automatic sound lasting more than 3 seconds MUST have a pause, stop, or independent volume control. These guidelines default to not auto-playing sound. When motion is reduced, a static state and progress are preserved; flashing follows the limits in Appendix A.

Design applicationLoading uses static copy or a low-disturbance progress indicator; a carousel provides pause, and decorative displacement stops when motion is reduced.

Verification

• User side: does not have to endure prolonged motion or sound before finding the off entry.
• Implementation side: check that information is consistent before and after motion is turned off; check each auto-playing and flashing asset individually.

CounterexamplesUnder-delivery: reduced motion just speeds up the animation; over-delivery: hiding the loading state along with it.

AC4-7A brief notice can be retrieved again, and undo does not depend on speed¶

Applies totoasts, notification bars, confirmation receipts, and undo.

Requirement: A critical result and necessary disclosure MUST have a persistent location; a notice disappearing must not become the undo deadline. Impact risk and reversibility are judged separately, with the applicable withdrawal scope and time limit stated before execution; an unconfirmable result shows pending verification. A high-consequence action has at minimum an applicable undo, a pre-submission check, or confirmation protection — avoid requiring multiple confirmations for every action uniformly.

Design applicationA deletion can still be undone from the history after the notice disappears; canceling a future subscription is explicitly distinguished from reversing an already-charged payment.

Verification

• User side: a slow reader can still find the result and an available correction action.
• Implementation side: check that the notification TTL is independent of the business undo deadline, and that the receipt matches the execution state.

CounterexamplesUnder-delivery: the undo entry disappears permanently after three seconds; over-delivery: repeatedly confirming even a low-risk choice.

AC4-8Recovery after interruption does not presume incapacity¶

Applies tolong flows, saving, incoming calls, switching apps, and temporary departure.

Requirement: The save scope, retention time, and recovery entry MUST be stated explicitly; a user's pause, help-seeking, or retry must not itself be treated as abandonment, insufficient capability, or a basis for automatic degradation. Recovery shows the current step and completed content, and re-checks any facts that have become invalid; sensitive content may go unretained but MUST be disclosed in advance with a workable way to re-enter it.

Design applicationAfter restoring a draft, show "filled through to contact information," without resubmitting an action already executed.

Verification

• User side: knows where to continue after an interruption, and can edit the saved content.
• Implementation side: simulate exiting, going offline, authentication expiry, and repeated recovery, checking that drafts and already-executed results are kept separate.

CounterexamplesUnder-delivery: it clears just by leaving the page; over-delivery: permanently saving sensitive input without the user's choice.

AC4-9A high-consequence flow can be previewed, and help can be started directly¶

Applies topayment, authorization, deletion, complex applications, and a step where the user is stuck.

Requirement: A preview or rehearsal without real consequence SHOULD be provided, clearly distinguished from actual execution. A help entry that does not require describing technical detail MUST exist, and general help can be initiated while signed out when a sign-in failure occurs; accessible authentication is used only once private data is involved. The help entry's location is consistent, and the context handed off carries only necessary, already-disclosed information.

Design application"Trouble at this step" automatically attaches the step identifier; the end of a rehearsal states that nothing was submitted.

Verification

• User side: can ask for help without knowing an error code; does not mistake a rehearsal for something actually completed.
• Implementation side: confirm a rehearsal makes no real write; help requested while signed out cannot read another person's information, and the shared scope is checked before handoff.

CounterexamplesUnder-delivery: unable to sign in, yet sign-in is required to contact support; over-delivery: every user is first forced through a tutorial.

AC5 Preference and capability are respected¶

Let users adjust by effect of choice, while retaining full task capability.

AC5-1Respond to platform preferences without fabricating a choice¶

Applies totext size, reduced motion, contrast, forced colors, and assistive technology.

Requirement: The relevant preference MUST be read or inherited through a public platform mechanism, with support for changes at runtime. Platform-not-provided, read failure, and user-not-chosen MUST be recorded separately and not uniformly treated as "all enabled." A user's chosen assistive-technology settings must not be overridden; an explicit product preference controls only the attributes it supports and must not turn off platform forced-colors mode or intercept browser zoom.

Design applicationFollows the system by default; when the motion preference fails to read, a low-motion presentation is used, but it is not recorded as a user choice.

Verification

• User side: the product responds after the system setting is changed; the user is not required to re-declare a disability or assistive-technology usage.
• Implementation side: check the source, resolved value, unknown reason, and change event; borders and state remain under forced-colors mode.

CounterexamplesUnder-delivery: the system has already reduced motion but the product keeps parallax; over-delivery: inverting colors and enlarging all text just because a read failed.

AC5-2Zooming, reflow, and text spacing do not lose content¶

Applies topages, popups, labels, tables, text, and forms.

Requirement: Web MUST meet Appendix A's text-scaling, reflow, and spacing-override tests; native applications support platform text scaling. A user must not be prevented from zooming, and a fixed font-size ceiling must not be used to dodge layout problems. An area genuinely requiring two-dimensional layout may scroll locally with an explanation — the whole page must not be made to scroll horizontally on this basis; captions, long names, and error messages are checked the same way.

Design applicationA container grows with its content; button text can wrap; a data table scrolls within its own region.

Verification

• User side: can still read, confirm, and cancel after zooming in; long translations and user letter-spacing are not clipped.
• Implementation side: run text enlargement, narrow-viewport reflow, and spacing override separately — the three tests are not merged into a single screenshot check.

CounterexamplesUnder-delivery: the confirm button is clipped at 200% font size; over-delivery: shrinking the font in reverse just to fit one screen.

AC5-3Settings are discoverable, composable, and recoverable¶

Applies toadjustable items and presets the product provides.

Requirement: Settings MUST be named by effect and adjustable item by item, not entered through "select senior/disability mode first." At least a setting reachable within the current task, or an explicit platform-setting pointer, MUST be provided; current input and the return position are preserved. Temporary settings are distinguished from persisted preferences, with support for reverting to follow the system; a combined preset does not lock a single item.

Design application"Enlarge text" and "reduce motion" can be chosen separately; a temporary adjustment is not written into the account default.

Verification

• User side: can adjust when running into difficulty and return to where they were, without being forced to lose a draft.
• Implementation side: check that the settings entry is reachable, the storage subject, sign-out, and shared-device clearing behavior.

CounterexamplesUnder-delivery: only one large-text mode exists, and it turns off every advanced feature; over-delivery: a full settings page pops up at every single step.

AC5-4Adaptation does not reduce rights or function¶

Applies tolarge text, simplified layout, assistive input, low bandwidth, and alternative paths.

Requirement: Enabling an accessibility setting must not reduce task completability, content timeliness, quota, or service treatment, nor add an unrelated charge, identity proof, or data collection. A simplified presentation still provides a reachable entry to full capability; an objective limitation MUST be stated with an effective alternative that does not require turning off a necessary setting.

Design applicationLarge-text mode can complete the same business as default mode, with complex options expandable on demand.

Verification

• User side: the same task produces the same result and service conditions under different settings.
• Implementation side: compare function, cost, limits, update timeliness, and data requirements using a task checklist.

CounterexamplesUnder-delivery: payment is disabled once the screen reader is turned on; over-delivery: refusing to let users rearrange content just to keep the layout identical.

AC5-5Treatment does not change based on a presumed identity¶

Applies toassistive-technology detection, behavioral analysis, recommendation, and automatic adaptation.

Requirement: The presence of assistive technology, a pause, a mistake, or a help request must not be inferred as insufficient capability and used to downgrade function or treatment, and health proof must not be demanded to enable an adjustable item. Necessary compatibility adaptation SHOULD be limited to implementation differences; user data collection MUST have a clear, minimized purpose. A system-proposed adjustment MUST be refusable and must not override an explicit preference.

Design applicationSuggest "you can enlarge the text" rather than "you seem to have a vision problem"; assistive technology is not judged an automated attack.

Verification

• User side: can decline a suggestion and continue, without being repeatedly asked again.
• Implementation side: check automated branches and the source of risk-control input, testing normal assistive-technology input and appeal against false blocking.

CounterexamplesUnder-delivery: a long pause automatically enters a reduced-function interface; over-delivery: refusing to even follow the system font size in the name of "not distinguishing between users."

AC5-6Adapts to language, culture, and use context¶

Applies tocross-region forms, direction, device posture, and constrained networks.

Requirement: Unnecessary restriction to a single language, writing system, name structure, or device orientation MUST be avoided; orientation lock is adopted only when essential to the function, with an explanation. Critical tasks SHOULD be checked under low bandwidth, one-handed use, temporary impairment, noise, and bright-light conditions. A user should not need to disclose a capability or cultural identity to obtain basic capability.

Design applicationReasonable names and addresses are allowed; a long form keeps an offline draft, and error messages do not rely on voice alone.

Verification

• User side: can proceed using real information, completing the task in the declared supported postures and environments.
• Implementation side: cover language, direction, input method, disconnection, and device rotation; check whether an exception is genuinely required by the task.

CounterexamplesUnder-delivery: every name must fit two Latin-alphabet segments; over-delivery: automatically choosing a capability tier for the user based on nationality.

AC6 Usability has evidence¶

Support conclusions jointly with rule checks, assistive-technology operation, and real user tasks.

AC6-1The three kinds of evidence are obtained separately¶

Applies todesign delivery, implementation acceptance, and external claims.

Requirement: Automated checks, manual rule and assistive-technology checks, and target-user task testing MUST be distinguished. An automated check can find some defects but cannot independently prove conformance or task usability; a user completing a task also does not exempt a detectable rule defect. Every conclusion MUST bind its test scope and evidence — a tool score is not treated as the overall usability rate.

Design applicationA form task checks semantics, keyboard, and real-person completion at the same time.

Verification

• User side: real users can complete the task and understand the result, and problems are not hidden by a tool passing.
• Implementation side: establish the association among rule items, execution records, and user observations, retaining failed and unverified states.

CounterexamplesUnder-delivery: zero scanner errors is declared fully accessible; over-delivery: skipping rule checks just because real-person testing was done.

AC6-2Critical tasks cover real combinations¶

Applies toregistration, sign-in, primary business, editing, undo, help-seeking, and exit.

Requirement: The task's start point, end point, and success condition MUST be explicitly listed, covering the assistive technology, input method, language, and device combinations actually in use. Recruit people with relevant lived experience, including cognitive, auditory, or motor needs who do not use assistive tools — simulated disability must not be a substitute. Independent completion, completion after a prompt, and completion by a proxy operator are recorded separately; research participation conditions and compensation are fair.

Design applicationCover target combinations such as screen reader, magnification, keyboard, and switch control, recording the basis for the selection.

Verification

• User side: users complete real tasks using their everyday methods and can report a barrier without a researcher performing it on their behalf.
• Implementation side: record the sample, environment, configuration, task, blocking point, assistance, and limitations; do not extrapolate everyone from a few people.

CounterexamplesUnder-delivery: only a developer tries the screen reader once; over-delivery: requiring every device to be exhausted before a known defect may be fixed.

AC6-3A severe barrier is not offset by an average score¶

Applies toacceptance judgment and release gating.

Requirement: Where a critical path cannot be completed, a focus trap, necessary information is missing, a timeout loses work, a mis-tap produces a major consequence, or adaptation causes a discriminatory restriction, the affected scope is judged fail as soon as it occurs. A restricted use with a clear boundary may be recorded, but that scope must not be claimed as passed on this basis; an alternative approach requires actual verification and must not add unreasonable burden.

Design applicationList "pass/fail/unverified/not-applicable with basis" separately, assigning an owner and retest condition item by item.

Verification

• User side: a user is not excluded from a fix just because their path has few users.
• Implementation side: the release check looks at blocking items and evidence, not an aggregated average score.

CounterexamplesUnder-delivery: a screen-reader registration failure is offset by other high scores; over-delivery: exaggerating a minor, non-blocking defect into "unusable on every path."

AC6-4Claims and feedback can be checked¶

Applies toaccessibility statements, the help center, and feedback channels.

Requirement: Tested tasks, supported environments, known limitations, and help paths MUST be stated. Feedback itself MUST be accessible, offering a way that complements sensory dependence, and including an entry that does not require freeform technical writing; confirmation, disposition, and progress query are recorded. A low volume of feedback must not be taken as few barriers, and a conformance statement must not substitute for real-person testing.

Design applicationA user can select the step where the error occurred and submit, or seek help by voice, callback, or similar means.

Verification

• User side: can report a barrier and learn of subsequent handling, without first passing an inaccessible CAPTCHA.
• Implementation side: spot-check that feedback enters the defect workflow, and that every external conclusion traces back to a test record.

CounterexamplesUnder-delivery: the feedback form itself cannot be submitted; over-delivery: forcing users to disclose diagnostic information to prove the problem.

AC6-5Re-verify after an affected mechanism changes¶

Applies tochanges to style, semantics, content, flow, authentication, third parties, and platform behavior.

Requirement: The affected task MUST be re-checked; a test conclusion that is no longer applicable must not continue to be used. A retest MUST cover at minimum the change itself and its knock-on effects on focus, semantics, preference, and recovery; indiscriminately redoing every test is not required. Convert a real blocking report into a reproducible case, noting the environment and trigger condition.

Design applicationAfter adjusting a button style, retest contrast, focus, and target size; after replacing an authentication component, walk through sign-in end to end again.

Verification

• User side: the fix genuinely resolves the barrier in the everyday combination without introducing a failure on another path.
• Implementation side: check the change's impact, retest scope, and uncovered items; keep the execution evidence.

CounterexamplesUnder-delivery: a past passing conclusion is still cited after a component replacement; over-delivery: a copy-text typo fix triggers an unrelated full-scale study.

AC7 A service path stays reachable¶

Keep a reachable, hand-off-able, verifiable service path available when a user is stuck.

AC7-1Help entries and guidance correspond to the current task¶

Applies tohelp, tutorials, term explanations, and operating instructions.

Requirement: A repeatedly appearing help entry MUST keep its relative order, with guidance consistent with the actual interface and pointing to a location the user can access. Stale instructions MUST be corrected or explicitly marked no longer in use; a user must not be left to complete a flow based on a button that no longer exists. Help SHOULD be reachable within the task without clearing input.

Design applicationHelp for that step is offered next to the error; a tutorial supports text and accessible media.

Verification

• User side: can find the real entry by following the guidance and return to the original task.
• Implementation side: spot-check guidance links, control names, language, and the operating path.

CounterexamplesUnder-delivery: the instructions ask the user to click an entry that no longer exists; over-delivery: forcing the tutorial to be watched again every time.

AC7-2Basic services provide a workable alternative channel¶

Applies togovernment services, medical appointments, public utilities, and other basic services with an already-committed human channel.

Requirement: A workable human, phone, in-person, or other alternative MUST be listed per critical task, stating the scope handled, availability conditions, and remaining barriers; the absence of an alternative MUST be truthfully recorded with the exclusion risk addressed — it must not be marked "covered." Phone is not a universal alternative for a deaf or hard-of-hearing user, and in-person is not a universal alternative for someone with limited mobility.

Design applicationState per task the channels actually able to handle it and a help-seeking method with no text description required.

Verification

• User side: can initiate the process without the blocked digital path, and is not bounced between channels.
• Implementation side: actually test channel connectivity and handling scope, comparing extra cost, wait time, and information requirements.

CounterexamplesUnder-delivery: the so-called alternative channel just sends the user back to the app; over-delivery: requiring every online operation to be confirmed in person.

AC7-3A handoff preserves necessary progress and accountability¶

Applies toself-service-to-human escalation, remote assistance, cross-entry continuation, and service interruption.

Requirement: A handoff MUST state who it is going to, what information travels with it, and how to continue next; the scope transferred is the minimum necessary, chosen with the user's informed consent. The handoff is not claimed complete before the receiving party confirms it has taken over; on failure, a queryable request and recovery entry are retained, and the user must not be required to re-provide material that could be safely reused.

Design applicationGenerate an accessible summary of the case that the user can trim of unnecessary content before handing it to support staff.

Verification

• User side: can know who is handling it, without retelling everything from scratch, and can stop the sharing.
• Implementation side: simulate a failed handoff, a timeout, and repeated takeover, checking ownership, data, and submission state.

CounterexamplesUnder-delivery: everything is lost after escalating to a human; over-delivery: the entire account record is sent by default.

AC8 Assistance does not replace the person¶

Make help visible and revocable, and let the person decide through an accessible means.

AC8-1An assistance session is perceivable and terminable¶

Applies toremote-viewing or proxy-operation capability the product provides.

Requirement: The assisting party's identity, scope of capability, and an end entry MUST be continuously presented; the person MUST be able to terminate it using their own input method, and the assisting party must not hide the entry or prevent termination. Connected, in progress, and terminated MUST reflect the real state — a disconnected screen is not equated with authority having been revoked. The product does not need to identify a bystander present in the physical room.

Design applicationThe session bar can be located by a screen reader, and there is a receipt after it ends.

Verification

• User side: the session can be ended without depending on the assisting party's consent.
• Implementation side: check the control message and the server-side session state; restrict the assistant from continuing to operate when disconnected.

CounterexamplesUnder-delivery: the other party still has control after the window is closed; over-delivery: requiring camera recognition of bystanders even when there is no remote capability.

AC8-2Authority is granted per task and genuinely revoked¶

Applies toremote assistance, proxy filling, family collaboration, and sub-accounts.

Requirement: No proxy-operation authority exists by default; a grant is bound to the assisting person, object, action, and duration, and does not automatically include payment, authorization, account security, or export. Subsequent operation is blocked on end, expiry, or revocation; an action already submitted states its result and the remediable scope. A shared device does not mean all authority is shared, and assistance must not be achieved by sharing a password.

Design applicationOnly the currently requested fill-in authority is granted; submission still returns to the person's confirmation.

Verification

• User side: can understand who can do what, and revoke it at any time.
• Implementation side: check server-side authority, in-flight requests, and the revocation race condition, preventing a mere front-end button from being the only thing turned off.

CounterexamplesUnder-delivery: a single instance of assistance leaves standing authority; over-delivery: re-authorizing for every ordinary field filled in.

AC8-3The person's decision has an accessible means of expression¶

Applies topayment, signing, authorization, account closure, and changes to key identity data.

Requirement: These decisions MUST be expressed by the person in an attributable way — the assisting party's claim of consent alone is not sufficient. A switch, voice, or other assistive input is allowed; "the person's decision" is not equated with the person being able to tap it by hand. Unconfirmed, it is not executed; legal representation applies independent authorization verification and a genuine identity record and must not be disguised as the person's own action.

Design applicationAfter the assisting party fills it in, the person confirms a clear summary using their own accessible control method.

Verification

• User side: can express or refuse the decision without independently performing every action.
• Implementation side: check the decision's subject, authorization source, operating subject, and receipt — the operator's device is not substituted for evidence of intent.

CounterexamplesUnder-delivery: a child tapping on behalf of a parent is recorded as the person's own confirmation; over-delivery: recognizing only a finger tap and rejecting switch input.

AC8-4Assistance opens only necessary information¶

Applies toremote sharing, assisted forms, and support-staff handoff.

Requirement: Sensitive information unrelated to the task is hidden by default, and opening a single item requires the person's choice at that time. A password, verification code, or authentication secret is not shown to the assisting party; the user's own assistive technology and password manager are allowed to handle authentication normally, and the person's own screen reader must not be blocked at the same time as the assisting party is masked.

Design applicationThe shared view masks balance and credentials, while the person can still operate their own secure local input.

Verification

• User side: the assisting party can help without seeing unrelated information, and the person can still complete authentication.
• Implementation side: check the person's own presentation, remote transmission, logs, and screen recording separately, rather than adding only a visual mosaic.

CounterexamplesUnder-delivery: the picture is masked but the DOM or network traffic still leaks it; over-delivery: hiding the person's own input from every assistive technology as well.

AC8-5An action is auditable and the subject is not conflated¶

Applies toproxy-operation receipts, records, and dispute queries.

Requirement: The actual operator, decision-maker, object, time, and result MUST be recorded; the person can query it independently, and the assisting party cannot delete or alter it. The retention scope is disclosed and data is minimized — full screen recording is not the default. In a shared-account scenario, an unidentifiable operator must not be labeled as a verified person.

Design applicationDisplay "filled in by the assisting party, confirmed by the person, application submitted."

Verification

• User side: the person can review afterward what happened and how to seek help.
• Implementation side: check that the record is associated with the actual request, access authority, and sensitive-field masking.

CounterexamplesUnder-delivery: the record is visible only to the assisting party; over-delivery: recording every password entry and family conversation just to keep a trail.

AC9 Commitments are obtained clearly¶

Do not trade a user's cognitive or operational impairment for a commitment they did not intend to make.

AC9-1No manipulation or disguise is used¶

Applies toregistration, marketing, subscriptions, promotion, and system prompts.

Requirement: Consent MUST NOT be obtained through a fake countdown, fear-based copy, a pre-checked upsell, a disguised close control, or repeated pestering; third-party content MUST have a perceivable source label and must not impersonate a system prompt. A genuine deadline may be stated but must not be falsely reset.

Design applicationDecline and close controls are discoverable and actually take effect; an ad label can be read by a screen reader.

Verification

• User side: can accurately distinguish product disclosure, third-party content, and promotion.
• Implementation side: review the critical conversion path, defaults, click areas, and close-button result clause by clause.

CounterexamplesUnder-delivery: clicking close opens the purchase page instead; over-delivery: not disclosing even a genuine deadline, causing the user to miss the process.

AC9-2Cost and authorization facts are available before confirmation¶

Applies topayment, renewal, permissions, and standing arrangements.

Requirement: The amount, the object, and the applicable cycle, subsequent price, charge timing, and cancellation method MUST be presented directly at the confirmation step; a one-time operation does not have a fabricated cycle filled in. An authorization MUST state its subject, scope, duration, re-delegation, and revocation. One-directional scrolling after zooming is allowed; text is not shrunk to "fit on one screen"; when information is missing, no executable confirmation is offered.

Design applicationThe confirmation page presents the promotional period and the subsequent price together; when a necessary field is unavailable, this is stated and the flow stops at preview.

Verification

• User side: can state who will be paid how much, for how long, and how to cancel.
• Implementation side: check that the summary matches the actual submission parameters, and that it remains accessible with long content and large font size.

CounterexamplesUnder-delivery: only the first-month price is highlighted; over-delivery: cramming the entire agreement into every single confirmation.

AC9-3Cancellation and refusal are not artificially made harder¶

Applies tounsubscribing, unlinking, revocation, refusal, and account closure.

Requirement: The entry MUST NOT be hidden, an explanation MUST NOT be forced, retention attempts MUST NOT be repeated, and steps MUST NOT be artificially added; compare the total burden of discovery, comprehension, operation, and waiting, not merely the click count. When a genuine settlement or identity-verification need exists, state the reason, time, and progress. Canceling a future arrangement is stated separately from reversing an existing result; an unexpressed choice does not constitute new consent.

Design applicationThe cancellation entry sits alongside subscription management, and an optional explanation can be skipped.

Verification

• User side: does not have to turn off accessibility settings or make a phone call just to cancel an online service.
• Implementation side: walk through sign-up and cancellation using the same assistive input, checking that it actually takes effect and any pending state.

CounterexamplesUnder-delivery: sign-up is one click online while unsubscribing requires listening through a voice menu; over-delivery: removing a necessary funds check just to match the same step count.

AC9-4Browsing and automatic progression do not create a new commitment¶

Applies topage visits, focus, option changes, countdowns, and automatic flows.

Requirement: Browsing, scrolling, focusing, dwelling, or closing MUST NOT trigger payment, authorization, or subscription. An input change does not unexpectedly change the context, and a necessary automatic change is disclosed in advance; a step that would create a new commitment requires an explicit action. Automatic fulfillment within an already-valid authorization scope may continue, but it MUST stop once out of scope or after revocation, with unfinished items checked.

Design applicationCompleting an upload can show the result, without auto-checking and submitting the next service.

Verification

• User side: can read every option without worrying about accidental execution.
• Implementation side: test onfocus, onchange, timers, and retry events; browsing history is not treated as consent.

CounterexamplesUnder-delivery: dwelling for ten seconds counts as accepting the terms; over-delivery: an already-authorized periodic task repeats requesting the same confirmation on every execution.

AC9-5A standing arrangement can be confirmed and canceled independently¶

Applies tosubscriptions, auto-debit, password-free payment, biometric binding, and standing authorization.

Requirement: The user MUST be able to identify each standing consequence, actively choose it, and cancel it independently, without it being bundled with ordinary browsing or a one-time transaction. Confirmation quality depends on the facts and intent, not on mechanically increasing the click count. When scope, object, duration, or cost exceeds an already-confirmed condition, the decision MUST be obtained again — a broader authority is not inherited.

Design applicationPayment does not check auto-debit by default; a complete summary and an explicit action are given before enabling it.

Verification

• User side: knows the difference between a one-time payment and a standing arrangement, and can turn off the latter independently.
• Implementation side: check the actual authorization boundary, the point cancellation takes effect, and interception of subsequent calls.

CounterexamplesUnder-delivery: payment enables password-free debit as a side effect; over-delivery: a single clear confirmation is turned into five consecutive confirmations.

AC9-6Authenticity can be checked and conclusions are not overstated¶

Applies tomessages, notifications, calls, and charges sent by the product.

Requirement: An independently reachable official query or support entry MUST be provided; the check result distinguishes confirmed-from-this-product, not-found, and undeterminable. A genuine source does not mean the content or transaction carries no risk, and coverage of external fraud must not be claimed. High-consequence verification MUST use an actually usable, independent basis for verification, while still guaranteeing an accessible recovery path.

Design applicationVerify a notification from the in-app message record, without requiring a click on a suspicious link.

Verification

• User side: can find the check entry independently and understand an unknown result.
• Implementation side: check the coverage scope, data freshness, impersonation scenarios, and recovery method of the source query.

CounterexamplesUnder-delivery: not-found is declared absolutely safe; over-delivery: any ordinary prompt demands multi-device authentication from the user.

4. Terminology¶

Appendix A: Measurable Baselines and Applicability Boundaries¶

The following is an implementation summary of selected criteria; the complete success criteria and exceptions are governed by the linked standard's original text. A value labeled "product default" is a design starting point, not a new conformance level; meeting the value still requires the complete task to be verified.

Appendix B: Joint Acceptance and Delivery¶

Minimal design record¶

One record per task is sufficient; a separate document is not required for every rule:

Fault-injection checklist¶

The check looks not only for "under-delivery" but also "over-delivery": repeated announcements, forced multiple confirmations, automatically rewritten preferences, excessive collection in the name of helping, and breaking the whole task for the sake of a single numeric threshold.

Evidence boundaries¶

This document states design and acceptance requirements; it has not conducted assistive-technology testing or user research on any specific product. Sample size, caption-quality target, announcement-aggregation window, draft retention period, and service response deadline MUST be determined by the project based on task risk and the target use context, with the measurement method stated; a unified value with no source must not substitute for verification. For the full sources and the distinction among standards, explanatory material, and this product's design choices, see Reference Sources.

---

Implementation acceptance scenarios¶

The following scenarios turn existing clauses into re-checkable acceptance input, without setting a separate universal performance threshold. Select per the product's applicable capabilities, supplementing real devices, users, input sequences, and evidence; record the reason when not applicable, and do not record as passed what was not executed.

Each scenario separately checks the configuration's effective value, the execution record, and a result the user can understand. Retain the version, target, event timing, failure scope, and recovery result; an unknown external result is not filled in as either success or failure.