UX availability and interfaces for all

1) Why it matters

Legally and ethically: the interface should not exclude people with visual, hearing, motor, cognitive impairments.
Business effect: more users, higher conversion and retention, better SEO and code quality.

Operationally: Accessibility is a process, not a "random fix."

2) Fundamentals and Principles (POUR)

Perceptible: contrast, alternative texts, subtitles.
Operable: everything is accessible from the keyboard, visible focus, pause/stop animations.
Understanding: predictable navigation, clear errors, simple formulations.
Robust: correct HTML/ARIA semantics, compatibility with assistive technologies.

3) Semantics, titles and ARIAs

Semantic markup before ARIA: '<button>', '<nav>', '<form>', '<table>' - by purpose.
Header hierarchy: one '<h1>' per page, then logical structure '<h2>' - '<h3>'.
Landmarks: '<header>', '<main>', '<aside>', '<footer>', '<nav>' - help screen readers.
ARIA only when needed: 'role', 'aria-label', 'aria-described', 'aria-expanded', 'aria-live'.
States/errors through 'aria-invalid', 'aria-errormessage'.

4) Keyboard and focus management

Full keyboard control: 'Tab/Shift + Tab' - order, 'Enter/Space' - activate, 'Esc' - exit.
Visible focus always; do not disable outline.
Focus traps: in modals - cyclic focus, returning focus to the source after closing.
Hidden elements should not fall into the tab order (' display: none', 'aria-hidden =" true"').
Skip links: "Go to main content" - at the beginning of the page.

5) Color, contrast and typography

Text contrast: at least 4. 5:1 for plain text and 3:1 for large text.
Do not rely only on color: duplicate with an icon/pattern/signature.
Size of clickable targets: at least 40-48 px, sufficient fields around.
Fonts: readable typefaces, line-to-line 1. 4–1. 6, line length 45-90 characters.

6) Motion, animations and epileptogenic flash

Respect the system prefers-reduced-motion flag - add simplified animations/disable parallax.
Avoid flickers> 3 times/sec.
All auto-motions must have Pause/Stop/Hide.

7) Forms, errors and validation

Explicitly bind labels and fields: '<label for = "id">'.
Placeholder is not a label.
Error messages next to the field and in the error summary at the top; bind via 'aria-describedby'.
Explain the input format, example, mask; Specify units and currency.
Do not reset completed fields when an error occurs; keep focus on the problem field.

html
<label for="email">Эл. почта</label>
<input id="email" name="email" type="email" aria-describedby="email-hint email-err">
<div id="email-hint" class="hint">Мы не рассылаем спам</div>
<div id="email-err" class="error" role="alert">Укажите адрес в формате name@example.com</div>

8) Components and interactive: patterns

Buttons vs links: action = '<button>', jump = '<a>'.
Tabs/accordions: navigation arrows, 'aria-controls', 'aria-selected'.
Modals/dialogs: 'role = "dialog"', 'aria-modal = "true"', focus trap, 'Esc' closes.
Tooltip/Popover: keyboard accessibility, timeouts do not interfere with reading.
Drag & Drop: alternatives - move up/down buttons, keyboard arrows; events not just with the mouse.

9) Media: Video/Audio/Graphics

Video: subtitles, transcript, alternative audio description (AD) track.
Audio: text transcript.
Graphs/diagrams: text summary ("what is important"), data table, descriptive labels of axes.
Living areas: 'aria-live = "polite "/" assertive "'- careful not to" scream" too often.

10) Tables and lists

11) i18n, locales and RTL

The'lang 'attribute on the html root; local number/date/currency formats.
RTL support (Arabic/Hebrew): mirroring icons, navigation order, cursors.
Avoid words sewn into icons (text must be translatable).
Simple formulations, avoid jargon; glossary of terms.

12) Time, sessions, captchas and alternatives

Timeouts - with a warning and the ability to extend.
CAPTCHA: prefer alternatives (questions, invisible bot analyzers, confirmation by mail/phone); if you use - a text alternative and not only visual.
Authentication: support for password managers, "show password," WebAuthn.

13) Accessibility for sensory and motor impairments

Gestures must have click/keyboard equivalents.
Do not require long holds/double taps without an alternative.
"Pointer cancellation": the action must be performed on release, not on "press" to give a chance to cancel.

14) States, notices and alerts

Use'role = "status "/" alert" 'for dynamic messages.
Do not cover your focus with sticky banners.
Toast notifications - with pause at focus/hover and access from the keyboard.

15) Test plan (manual and auto)

• Pass all key scripts only with the keyboard.
• Check the focus visibility on each item.
• Zoom up to 200% - the interface remains functional without horizontal scrolling.
• Turn on the system mode "reduce motion" - animations do not interfere.
• Pass the script with a screen reader (NVDA/VoiceOver), make sure that the roles/tags/order are correct.

• Component-level accessibility lints.
• Check for contrast, alternative texts, header order, ARIA validity.
• Snapshots of semantics (role tree) for critical screens.

16) Availability Quality Metrics

A11y Coverage: the proportion of components with completed checklists.
Keyboard-only Pass Rate: percentage of scripts traversed by the keyboard.
Contrast Violations/1k elements.
SR Flow Time: Script run time with screen reader.
User-feedback: complaints about availability, response time and corrections.

17) Component checklist

• Correct semantics/role without redundant ARIA
• Signed labels, 'aria-' correct
• Full keyboard control, visible focus
• Text/icon/border contrast is normal
• Errors and conditions are voiced by the screen reader
• Respect prefers-reduced-motion
• Clickable area size ≥ 40-48 px
• Localization and RTL do not break the layout

18) Anti-patterns

"Div-buttons" without a role/keyboard.
Hides the 'outline: none' focus without an alternative.
Placeholder instead of label.
Errors in color only.
Modals without focus trap and without 'Esc'.
Drag-only without keyboard.
Long auto-scrolling/parallax without the option to disable.

19) Roles and Process

A11y-owner in the command (Product/Design/Dev).
Definition-of-data (DoD) includes availability.
Design review: checking contrast, focus, labels.
Code review: semantics/ARIA, keyboard test.
Regular audits and improvement plan.

20) Implementation by iteration

• Semantics/titles, contrast, focus and keyboard, basic forms and errors.

• Modals, tabs/accordions, tables/graphs with text summary, video subtitles, reduced animation.

• Autotests in CI, RTL/i18n, metrics, regular audits, team training.

21) Templates and snippets

html
<div role="dialog" aria-modal="true" aria-labelledby="dlg-title" aria-describedby="dlg-desc">
<h2 id="dlg-title">Подтвердите действие</h2>
<p id="dlg-desc">Эта операция необратима.</p>
<button>Отмена</button>
<button>Подтвердить</button>
</div>

html
<a class="skip-link" href="#main">Перейти к основному содержимому</a>
<main id="main">...</main>

css
@media (prefers-reduced-motion: reduce) {
{ animation-duration: 0.01ms!important; animation-iteration-count: 1!important; transition: none!important; }
}

22) Mini-FAQ

Do I need a separate "visually impaired version"?
No, it isn't. One adaptive, accessible version for everyone with settings.

Is it enough to check only the contrast?
No, it isn't. Contrast is only part. Need keyboard, focus, semantics, form errors, media, etc.

ARIA will solve everything?
ARIA will not correct incorrect semantics. First correct tags, then ARIA refinements.

Result

Availability is a system discipline: semantics → keyboard/focus → contrast/colour → forms/mistakes → media/schedules → i18n/RTL → test plan and metrics. Make accessibility part of DoD and team culture - and your product will be truly versatile, reliable and convenient for everyone.