Тема: accessibility
-
Игровые сигналы при нарушениях цветового зрения: передавать состояние не только оттенком
Сочетайте цвет с постоянными символами, узорами и подписями и проверяйте целый сигнал в игровом масштабе, не полагаясь лишь на готовую палитру.
-
Интерфейс с учётом локали: Intl, формы множественного числа, даты и разметка справа налево
Форматируйте числа, даты и относительное время объектами Intl браузера, а не операциями со строками; выбирайте формы по категориям Intl.PluralRules вместо n == 1, используйте логические свойства CSS, чтобы документ с dir=rtl зеркально перестраивался, и оставляйте место для текста, удлиняющегося при переводе.
-
Lesbarer Fliesstext: Zeilenlänge, Zeilenabstand und Kontrast
Drei Eigenschaften entscheiden, ob langer Text bequem lesbar ist: die Zeilenlänge (das AAA-Kriterium der WCAG deckelt sie bei 80 Zeichen), der Zeilenabstand (mindestens das 1,5-Fache der Schriftgrösse muss möglich sein, ohne dass das Layout bricht) und der Kontrast (4,5:1 für normalen Text, 3:1 für grossen). In relativen Einheiten setzen, damit Nutzende Text vergrössern und neu spationieren können.
-
Значки SVG: встроенная разметка, спрайт с use или элемент img
Встроенный SVG можно оформлять через currentColor и CSS, но его байты повторяются при каждом использовании. Спрайт с того же источника, подключённый через use, кэшируется один раз и наследует цвет текста; img кэшируется, но его содержимое недоступно CSS. Выбирайте способ по роли значка, скрывайте декоративные значки от вспомогательных технологий и задавайте размеры каждого, чтобы загрузка спрайта не сдвигала страницу.
-
Readable body text: measure, line height and contrast
Three properties decide whether long text can be read comfortably: line length (WCAG's AAA criterion caps it at 80 characters), line spacing (at least 1.5 times the font size must be possible without breaking the layout) and contrast (4.5:1 for normal text, 3:1 for large text). Set them in relative units so users can resize and re-space the text.
-
Dark mode with prefers-color-scheme, color-scheme and light-dark()
Dark mode has three parts: the prefers-color-scheme media query to detect the user's choice, the color-scheme property (and meta tag) to tell the browser which schemes the page supports so form controls, scrollbars and the canvas follow, and light-dark() or custom properties to swap palette values without duplicating rules.
-
Стабильные селекторы и автоматическое ожидание в сквозных браузерных тестах
В нестабильных браузерных тестах преобладают две причины: ломающиеся или неверно выбирающие элемент селекторы и паузы, основанные на предположениях о времени. Ищите элементы по роли, подписи или тестовому идентификатору, требуйте ровно одного совпадения и синхронизируйтесь повторяемыми проверками и проверками готовности к действию, а не временем.
-
Доступные формы: подписи, сообщения об ошибках и автозаполнение
Дайте каждому элементу управления подпись, связанную через for и id, отмечайте обязательные поля текстом и атрибутом, задавайте токены autocomplete, чтобы браузеры и вспомогательные технологии понимали назначение поля, и показывайте сводку ошибок вместе с сообщениями у полей, связанными через aria-describedby.
-
dialog versus popover: modal behaviour, the top layer and light dismiss
dialog with showModal() is modal: top layer, inert page, ::backdrop, Escape, closedby and form method=dialog; the popover attribute makes any element a non-modal top-layer overlay that a button toggles without script, light-dismissed in auto state. Use dialog for blocking prompts and forms, popover for menus, tooltips and toasts.
-
Игровые субтитры и звуковые подписи: сохранять смысл, время и читаемость
Представляйте диалог и важные звуки временными подсказками, явно обрабатывайте наложения и обеспечивайте читаемое отображение до первой сцены с речью.
-
What do people who enable reduced motion expect to be removed: all animation, large movement or only autoplay?
Open question: the reduced-motion setting says reduce, not none, and guidance suggests keeping small meaningful transitions while removing parallax, zooms and autoplay; is there evidence about what users who enable the setting actually want, and whether their expectations differ by reason (vestibular disorder, distraction, battery, preference)?
-
ARIA roles: why a native HTML element beats a div with a role
The W3C's first rule of ARIA use is to prefer a native HTML element or attribute that already has the semantics and behaviour required; ARIA only changes what assistive technology is told, never what the element does. A div with role=button still needs focusability, key handling and states added by hand, and every mistake is invisible in visual testing.
-
Keyboard navigation in composite widgets: roving tabindex, arrow keys and Escape
Tab and Shift+Tab move between components; arrow keys move inside a component such as a tab list, toolbar, menu or radio group. Implement this with a roving tabindex (one item at tabindex=0, the rest at -1) or aria-activedescendant, close transient surfaces with Escape, and never trap focus without an advertised way out.
-
Focus management in single-page interactions: dialogs, route changes and removed elements
When a page changes without a full load, keyboard focus must be moved on purpose: into a dialog when it opens and back to its trigger when it closes, to the new view's heading after a client-side route change, and to a sensible neighbour when the focused element is deleted. Otherwise focus falls to the document body and screen-reader users are sent back to the top.
-
prefers-reduced-motion: which animation to reduce and how
The prefers-reduced-motion media feature reports whether the user has asked the operating system for less motion; its values are no-preference and reduce. Honour it by replacing large movement (parallax, zooms, slides, autoplaying motion) with fades or instant changes, while keeping small state transitions that carry meaning, and apply the same rule to script-driven animation.
-
Карты действий Unity: контексты, схемы управления и сохранение переназначений
Группируйте смысловые действия по игровому контексту, отличайте схемы устройств от активации карт и проектируйте полный цикл переназначения.
-
Barrierefreiheit: die vier WCAG-Grundsätze praktisch angewendet
Die WCAG 2.2 ordnen alle Erfolgskriterien vier Grundsätzen zu: wahrnehmbar, bedienbar, verständlich, robust. Wer pro Grundsatz die häufigsten Verstösse kennt (fehlende Textalternativen, Tastaturfallen, zu wenig Kontrast, unbeschriftete Felder, zu kleine Ziele), findet viele Barrieren ohne Spezialwerkzeug; Stufe AA ist das übliche Ziel.
-
What share of accessibility defects found in manual audits or by users had passed the automated checks in CI, and which kinds escaped?
Open question: the W3C WAI guidance on evaluation tools states that some accessibility checks cannot be automated and require manual intervention; for sites that run an automated checker on every build, what share of the defects later found in a manual audit or reported by users had passed that checker, and which defect types account for the gap?
-
Touch targets and pointer types: sizing controls for fingers and mice
WCAG 2.2 requires pointer targets of at least 24 by 24 CSS pixels at level AA, with exceptions for spacing, inline links and equivalent controls, and 44 by 44 at level AAA. The pointer and hover media features report whether the primary input is coarse or fine and whether it can hover, so a design can enlarge controls and drop hover-only interactions where a finger is the pointer.
-
Accessibility fundamentals: perceivable, operable, understandable, robust
WCAG organises requirements under four principles; the most common failures on content sites are missing text alternatives, colour-only signalling, keyboard traps, low contrast and unlabeled controls.
Машиночитаемо: JSON