Testing interface availability

1) Why and what we think is "ready"

• WCAG 2 criteria met. 1/2. 2 AA levels for target platforms;
• the interface is completely passed from the keyboard;
• correct work with screen readers;
• contrasts comply with the norms;
• all states/errors/statuses are available out of sight and without a mouse;
• localization, RTL, reduce motion and mobile features are taken into account.

2) Testing strategy (pyramid A11y)

1. Autotests/linters (fast coverage of up to 40-60% of problem classes).
2. Manual pattern checking (keyboard, focus, content, logic).
3. Assistive Tech (AT) sessions: screen readers, scaling, color filters.
4. Field tests with users (if possible).

The goal: to catch systemic defects at the component/pattern level so that they do not multiply in features.

3) Checklist of basic checks (quick run)

• Keyboard: everything is reachable by tab/arrows; the order of focus is logical; there is a trick trap in modals; ESC/Enter/Space are working.
• The focus indicator is visible in any topic/background.
• Contrast: text ≥ 4. 5:1 (regular), ≥ 3:1 (large), icons/controls are readable.
• Semantics: correct tags ('button', 'a', 'label', 'ul/li', 'th/td'), roles and 'aria-' only if necessary.
• Screen reader: titles by hierarchy, meaningful names of buttons/links, alternatives for icons/images.
• Forms: explicit 'label', hints/errors are related ('aria-describby'), error texts are specific.
• Dynamics: Toasts/banners/errors are announced via 'aria-live' ('polite '/' assertive').
• Animations respect 'prefers-reduced-motion'; without "shaking" the interface.
• Localization/RTL: key screens are aligned, numbers/dates/currencies are formatted by utilities.
• Mobility: touch targets ≥ 44 × 44 px, zoom is not prohibited, screen rotation does not break content.

4) Roles, responsibilities and artifacts

Design system: A11y requirements in the description of each component.
Developers: auto-checks, unit/interaction tests with A11y-asserts.
QA: manual scripts + AT sessions; report with severity/frequency.
UX/Content: microcopy of errors/statuses, readability aloud.
Artifacts: checklists, scripts, AT screencasts, list of defects with WCAG references, recommendations.

5) Automated checks

Linters/analyzers: axe, eslint-plugin-jsx-a11y, pa11y, Lighthouse.
In the pipeline: we block PR for critical violations (role/label/contrast/tab traps).
Contrast snapshots: visual tests of themes/states.

6) Manual testing: scenarios

6. 1 Keyboard

Go through the page only with the keyboard (Tab/Shift + Tab/Enter/Space/arrows).
Check: focus visibility, priority, availability of all actions, absence of "traps" and "dead" elements.
In a modal: focus inside, when closed, returns to the initiator.

6. 2 Screen readers (minimum set)

Desktop: NVDA/JAWS (Windows), VoiceOver (macOS).
Mobile: VoiceOver (iOS), TalkBack (Android).
We check: correct headings (H-hierarchy), names of buttons/links, reading tables ('th '/' scope'), declaring statuses, understandable form errors.

6. 3 Content and microcopy

We read critical texts out loud - without ambiguity, without "error 400."

Error = "what's wrong + how to fix + constraint/format."

6. 4 Dynamics and living regions

The toast of success is' aria-live = "polite" ', the error is' assertive '.
Progress/download explained by text; skeleton is preferred to spinner.

7) Forms and errors (in depth)

Each field has an associated label (not a placeholder).
Errors are associated with the field:' aria-invalid =" true"',' aria-describby =" [error id]"'.
Format formulas (date, phone number) are specified in advance; masks do not break the input/insertion.
Summary banner of errors when submit + auto-scrolling and focus on the first error.
Error texts: specific, without technical jargon.

8) Tables, lists, graphs

Tables: headings' th'with' scope = "col/row" ', signatures, resume.
Lists are real 'ul/ol/li', not divas.
Graphs - alternative tables/descriptions; legends are available; colors ≠ a single signal.

9) Multimedia and animations

Video: subtitles/transcript; keyboard control; without autoplay (or with quiet).
GIF/microanimations: turn off when 'prefers-reduced-motion'; avoiding outbreaks.
Vibrations/sounds - optional and duplicated visually/text.

10) Mobile accessibility

Interactive ≥ 44 × 44 px, sufficient intervals.
Do not prohibit scaling (meta viewport without 'user-scalable = no').
Form/keyboard: correct types ('tel', 'email', 'number'), do not hide system capabilities.

Check in dark theme and with system fonts "more."

11) Localization, numbers and RTL

Strings through i18n keys with context; long languages (DE/TR) do not break the layout.
Date/currency formats - utilities, not strings.
RTL mode: mirror the navigation icons, check the order of focus and carriage, bidirectional input.

12) Specificity of critical flow (iGaming)

Payments/Conclusions

Clear instructions, limits/deadlines/commissions - in text.
Provider errors are declared explicitly, without codes; there is an alternative to action.
Operation confirmation: focus on logical CTA, cancelability.

CCM/verification

Step-by-step tips for photos/documents; progress and ETA.
Blurred/glare/truncated errors - with examples of correction.
Neutral tone, no humor.

13) Defect severity assessment

Blocker: Key task (keyboard/screen reader) cannot be completed.
Critical: critical functionality works, but with serious barriers.
Major: gets in the way, there's a workaround.
Minor: cosmetics/non-compliance with guides without affecting the task.

Each defect is a reference to the WCAG criterion and the script being reproduced.

14) Definition of Done (A11y)

Passing the keyboard script without a mouse is 100%.
axe/Lighthouse: no critical/high violations.
AA contrast across all themes/states.
Screen reader-run of key pathways (navbar, molds, modals, toast).
A11y documentation for new components/features (role model, aria, focus, examples).
Regression of A11y tests green in CI.

15) Processes and automation

Before development: A11y-criteria in tasks, layouts with focus/error states.
In development: linters/ahe during local assembly; visual snapshots of contrast/focus.
In CI: pa11y/axe-scan by critical pages; build drop under Blocker/Critical.
After release: quarterly audits, monitoring of user complaints by A11y-tag.

16) Anti-patterns

Placeholder instead of label.
'div'instead of' button '/' a '.

Disabled focus rings "for the sake of beauty."

Color as the only status carrier.
Modals without focus trap/ESC.
No scaling on mobile.
"Error 400/500" without human explanation.

17) Test script templates

Scenario 1 - Keyboard Navigation (Form Page)

1. Tab to the first field, enter the data.
2. Shift + Tab back - Check the correct order.
3. Call validation (submit) - focus moves to the first error.
4. Close the modulator with the ESC key, focus returned to the initiator.

Scenario 2 - Screen Reader (Payment Page)

1. Go to the page header (h1), listen to the sections.
2. Open the selection of the method - the declaration of roles/states is heard.
3. Deliberately make a sum error - the message is read and associated with the field.
4. Successful payment toast declared 'polite'.

Scenario 3 - Dynamics

1. Start the operation with a wait of> 3 seconds - there is text about the process/ETA.
2. In case of a network error - the 'assertive' banner, accessible from the keyboard, there is a "repeat/help" path.

18) Useful micro-templates

Roles/aria for toast

html
<div role = "status" aria-live = "polite"> Payment accepted. Balance updated. </div>
<div role = "alert" aria-live = "assertive"> The payment was denied. Try another method. </div>

Link error to field

html
<label for = "amount "> Amount </label>
<input id="amount" aria-invalid="true" aria-describedby="amount-error">
<div id = "amount-error "> Minimum 100 UAH. Please enter a larger amount. </div>

Modalka (semantic attributes)

html
<div role="dialog" aria-modal="true" aria-labelledby="m-title">
<h2 id =" m-title "> Confirm Payment </h2>
<! -- content -->
<button> Confirm </button>
<button> Cancel </button>
</div>

19) Quick implementation plan for A11y practices

1. Audit of current components/patterns (contrast/focus/role semantics).
2. Design System Edits: Add an A11y partition to each component.
3. Tools: Set up/axe/pa11y/Lighthouse linters locally and in CI.
4. Training: short guides for designers/developers/copywriters.
5. Pilot: fix 3-5 of the most common defects (modals, forms, toast).
6. Regulation: DoD with A11y criteria; quarterly audit.

Final cheat sheet

Check keyboard, focus, contrasts, screen reader, dynamics.
Announce statuses via aria-live; errors - related to fields.
Respect reduce motion, do not prohibit scaling.

Think semantics (tags/roles), not "what it looks like."

Automate checks, but always supplement with manual ones.
Fix defects with reference to WCAG, severity and playback script.