Угловая доступность

Поддержка стандартов Web A11y в Angular

Давайте поговорим о создании доступных приложений на Angular. Почему? Потому что приложения Angular прекрасны, но те удивительные вещи, которые позволяет вам делать Angular, являются чистым минусом, если вы не можете создать приложение, которое может использовать каждый.

Доступность (иногда сокращенно «a11y») относится к разработке программного обеспечения таким образом, чтобы его могли использовать все пользователи, независимо от их ограниченных возможностей.

Хотя я не являюсь экспертом по специальным возможностям, я могу помочь вам начать работу с специальными возможностями в целом и, в частности, с тем, как следовать методам обеспечения доступности в Angular.

Доступность 101

Прежде чем мы перейдем к проверке ваших приложений на наличие проблем с доступностью, давайте рассмотрим некоторые распространенные нарушения.

Современные HTML-теги

Современные браузеры поддерживают богатый и разнообразный набор значимых HTML-тегов, и тем не менее мощь современных веб-технологий, таких как Angular, позволяет нам просто использовать div элементы повсюду в нашем коде.

Это плохо.

Почему? Потому что программы чтения с экрана и другие специальные программы видят тег div и не понимают, кнопка это, абзац или прямоугольник с рамкой.

Не делай этого.

Вместо <div class="btn">My Button</div>

Использование: <button class="btn">My Button</button>

Это относится и к другим элементам HTML. По возможности используйте семантические элементы HTML, такие как nav, header, footer, section, article и aside.

Использовать атрибуты арии

Иногда вам приходится использовать HTML интересными способами. В настоящее время вам необходимо учитывать role теги, а также стандарты тегов Доступные полнофункциональные Интернет-приложения (ARIA).

Обычно вам нужно обращать внимание на:

Обратите внимание, что если вам нужно привязать значение атрибута aria к чему-то в Angular, вы можете использовать синтаксис, например: <div [attr.aria-expanded]="isExpanded">

Есть еще один тег aria, на который следует обратить внимание: следует использовать регионы, которые будут получать обновления, вставки или удаления в реальном времени. Мы вернемся к этому позже, когда будем обсуждать объявление об изменениях.

Поскольку я не являюсь экспертом по специальным возможностям и здесь я больше сосредоточен на обеспечении доступности в Angular, я рекомендую вам бесплатно ознакомиться с превосходным докладом Яна Форреста о тенденциях доступности в Интернете, доступным на Pluralsight.

Интеграция специальных возможностей в рабочий процесс Angular

Теперь, когда мы обсудили общую доступность, давайте рассмотрим еще несколько конкретных сценариев Angular.

Доступность сборника рассказов

Ранее я писал о том, как мне нравится использовать Storybook для быстрой проверки пользовательских интерфейсов Angular. Storybook - потрясающая библиотека, в которой есть ряд очень хорошо выполненных надстроек, в том числе надстройка доступности, которая может упростить аудит доступности.

Вы можете установить это дополнение, открыв командную строку в приложении Angular и запустив:

npm i @storybook/addon-a11y --save-dev

Это должно установить необходимые зависимости как зависимость времени разработки.

Оттуда вам нужно будет зарегистрировать надстройку в .storybook/main.js файле следующим образом:

module.exports = { 
  stories: ['../src/**/*.stories.ts'], 
  addons: ['@storybook/addon-a11y'], // other addons hidden for clarity 
};

Затем вам нужно добавить withA11y в каждый stories.ts файл, доступность которого вы хотите протестировать следующим образом (отмечая, в частности, строки 4 и 8):

Просмотр и устранение проблем A11y в сборнике рассказов

После настройки addon-a11y в Storybook при выполнении npm run storybook вы должны увидеть вкладку Accessibility, на которой будут выделены все обнаруженные нарушения доступности, как показано ниже:

Здесь надстройка сообщает мне, что у меня есть область экрана, в которой активно отображается полоса прокрутки, но эта область не настраивается с клавиатуры. Это означает, что любой, кто пользуется клавиатурой (например, многие пользователи, которым нужны специальные возможности), не сможет выполнять прокрутку.

В этом случае я могу щелкнуть «Подробнее…», чтобы перейти к невыполненному правилу и просмотреть несколько примеров рекомендуемых исправлений. В этом случае мне нужно добавить tabindex="0" в прокручиваемую область, чтобы. Это и повторный запуск теста решат проблему.

Обратите внимание, что это не будет таким обширным или всеобъемлющим, как надстройка браузера, специально разработанная для тестирования доступности, но если вы уже используете Storybook, это простой способ также использовать его для быстрой проверки доступности. .

Специальные возможности относятся не только к людям, которым нужны программы чтения с экрана. Многие люди страдают различными формами дальтонизма. Надстройка a11y предоставляет нам функцию цветового фильтра (изображенную ниже), которая может имитировать различные формы дальтонизма, чтобы вы могли проверить свои приложения и убедиться, что вы не скрываете информацию на основе цветовой чувствительности.

Aria-Live и обновления контента

Aria-live используется для обозначения области веб-приложения, которая получает периодические обновления.

Использовать aria-live довольно просто: вы добавляете его в любой блок и указываете вежливость. Это относится к тому, насколько срочными будут уведомления для конечного пользователя.

Например, вы можете использовать <div aria-live="polite">, чтобы сообщать о событиях только тогда, когда пользователь бездействует, а assertive будет более агрессивным.

Однако установки aria-live недостаточно. Вам также необходимо использовать LiveAnnouncer, чтобы сообщить о модификации программы чтения с экрана.

Взгляните на этот образец компонента:

Здесь, в строке 20, мы вводим LiveAnnouncer в компонент через механизм внедрения зависимостей Angular.

Затем в методе onEntryAdded, начиная со строки 35, мы вызываем liveAnnouncer с нашими текстовыми событиями. Эти события будут обнаружены программой чтения с экрана и представлены пользователю.

Доступность линтинга

Если вы хотите легко ввести некоторую степень аудита в свою практику разработки, вы можете добавить некоторые правила доступности в файл tslint.json, который поставляется с Angular. Это позволит вам выполнять проверки доступности в процессе линтинга и выявить некоторые распространенные ошибки.

Чтобы включить это, откройте tslint.json и добавьте следующие правила в свою коллекцию правил:

    "template-accessibility-alt-text": true,
    "template-accessibility-elements-content": true,
    "template-accessibility-label-for": true,
    "template-accessibility-tabindex-no-positive": true,
    "template-accessibility-table-scope": true,
    "template-accessibility-valid-aria": true,
    "template-click-events-have-key-events": true,
    "template-mouse-events-have-key-events": true,
    "template-no-autofocus": true,
    "template-no-distracting-elements": true,

Теперь, когда вы запускаете npm run lint для линтинга вашего кода, будут выполняться некоторые базовые проверки доступности. Обратите внимание, что это ни в коем случае не является исчерпывающим, но даже базовые проверки могут помочь уловить ситуацию.

Заключительные мысли

Надеюсь, эта статья дала вам краткое руководство по доступности в целом и некоторые идеи о том, как проводить аудит и решать проблемы доступности в Angular.

Я ни в коем случае не являюсь экспертом в области доступности, и я настоятельно рекомендую вам также рассмотреть специальные инструменты, такие как Wave и другие, если вы действительно хотите серьезно отнестись к аудиту доступности вашего приложения.

Для получения более свежих сведений о доступности Angular посетите официальную страницу документации по специальным возможностям фреймворка.

Первоначально опубликовано на https://killalldefects.com 13 февраля 2020 г.