Прагматические правила веб-доступности, которые запомнятся вам

1656518667 pragmaticheskie pravila veb dostupnosti kotorye zapomnyatsya vam

Тьяго Ромеро Гарсия

1*n8wSWsgY5iNzLCqNOIdRIQ
«Паралимпийские игры – это превращение нашего восприятия в мир». — Стивен Хокинг
То же можно было бы думать веб-доступность.

Я в первый раз начал работать с веб-доступностью еще в 2015 году в американском розничном гиганте. Как только он получил серьезный иск, поскольку его веб-сайт не соответствовал Закону об американцах с инвалидностью (ADA). После этого мы с командой активно работали над соответствием ADA, когда я ознакомился со многими принципами веб-доступности.

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

В конце концов я решил, что пора вкладывать свое время в сведение всего к простым, прагматичным правилам, которые легко запомнить. Наконец-то я это сделал, и с тех пор они для меня хорошо работают.

Эта статья состоит из 2 разделов: Что такое веб-доступность? и 3 прагматических правила веб-доступности. В первой главе я расскажу о веб-доступности и поделюсь своим опытом. Но если вы хотите перейти к погоне, то просто перейдите ко второму сеансу: 3 прагматических правила веб-доступности.

Что такое веб-доступность?

Как я уже упоминал, в 2015 году на мою компанию подали в суд за невыполнение ADA.

ADA – это закон о гражданских правах

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

Таким образом, ADA требует этого предприятия, государственные и местные органы власти, а также некоммерческие поставщики услуг создавать условия для людей с ограниченными возможностями для доступа к тем же услугам, что и для трудоспособных посетителей. так же, федеральные государственные учреждения обязаны соответствовать федеральному закону под названием Раздел 508.

В контексте Интернета любой общедоступный веб-сайт в США, не отвечающий требованиям ADA или раздела 508, исключает несколько групп пользователей с различной степенью нарушения.

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

Кого может поддержать a11y?

Согласно Всемирному докладу об инвалидности, опубликованному в 2011 году Всемирной организацией здравоохранения (ВОЗ), по оценкам, 15% населения планеты живет с определенной формой инвалидности. Из них от 2 до 4% испытывают значительные затруднения в функционировании.

Замечательная статья великого Адди Османи «Доступные компоненты пользовательского интерфейса для Интернета» описывает четыре основные сферы инвалидности, которые следует рассматривать в контексте a11y:

1. Визуальные проблемы: может варьироваться от неспособности различать цвета до полного отсутствия зрения.

2. Проблемы со слухом: означает, что пользователь может испытывать проблемы с чувством звука со страницы.

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

4. Когнитивные проблемы: означает, что пользователю могут понадобиться вспомогательные технологии, чтобы помочь ему с чтением текста, поэтому важно убедиться, что есть альтернативы тексту.

Имейте в виду, что это очень широкий спектр нарушений. Это означает, что не требуется серьезных нарушений, чтобы нуждаться в поддержке.

Чтобы узнать больше, я рекомендую пройти бесплатный курс Web Accessibility на Udacity от Google. Вот видео с курса, охватывающего эти сферы инвалидности:

Хорошо, как мы можем оказать поддержку a11y?

В то время, когда мы получили иск в 2015 году, был проведен аудит, который выявил несколько проблем. Наша команда прошла курс обучения доступности в течение дня, где мы узнали об Инструкциях по доступности веб-контента (WCAG, сейчас в версии 2.1), общепринятых как стандарт соответствия a11y.

WCAG поддерживается Инициативой доступности в Интернет (WAI) Консорциума World Wide Web (W3C). Эта же группа создала доступные богатые Интернет-приложения (WAI-ARIA или просто ARIA, сейчас в версии 1.1), являющиеся спецификацией относительно того, как увеличить количество веб-страниц с помощью добавления в HTML в качестве ролей и атрибутов ARIA.

Эти рекомендации делятся на три уровня соответствия:

  • A (должен поддерживать)
  • AA (должен поддерживать) и
  • AAA (может поддерживать).

Многие законы о доступности во всем мире основаны на уровнях WCAG. К примеру, в январе 2017 года раздел 508 принял соответствие с уровнем AA WCAG 2.0.

Большой результат инструкций можно найти в контрольном списке WCGA 2 от WebAIM, где каждый критерий указывает на соответствующий уровень соответствия.

Как трудно изучить WCAG и WAI-ARIA?

Я хотел бы использовать момент, чтобы поделиться своим опытом обучения a11y.

Хотя наше обучение было достаточно комплексным и проводилось очень осведомленными людьми, мы просто сидели там часами, просматривая всю спецификацию WCAG, пункт за пунктом. Их горка была огромной, и мы быстро двигались по горкам. Скажу честно: это было громоздко, поскольку WCAG точно не маленький.

Короче говоря, мы смогли записать много действий и мы немедленно начали работать над этими исправлениями. Однако вскоре это стало чем-то повторяющимся, механическим, реакцией на раздражители. Истории входят, код выходят. Мы тонули в море a11y.

Все знали, насколько хорошо мы стали в 11y, поэтому никто не оспаривал нашу работу. Истории a11y перестали поступать, и мы получили другие приоритеты. Ожидали, что мы перенесем то, чему научились, что действительно происходило довольно долго.

Шло время, кто-то ушел, кто-то присоединился, и пришло новое руководство. Рынок быстро двигается. Мы сменили фокус и наш командный дух. Излишне говорить, что мы настолько увлеклись новыми вещами, что наше соответствие требованиям a11y отошло далеко на задний план.

Это было так плохо, что через полгода мы провели еще один аудит, но обнаружили, что все еще сидим в большом ворохе нарушений a11y! Вскоре мы поняли, что, устранив исходные проблемы, прошедшие аудит, большинство нового кода, который мы написали, было столь же плохим для a11y. Более того, мы никогда не использовали a11y как часть нашего контрольного списка для разработки, а новичков никогда не учили по этому вопросу.

Вывод: Мы просто допустили это — a11y пренебрегали, а ключевые идеи не были укоренены в нас.

Другими словами, мы творили исключениечто происходит, когда мы решаем проблемы, используя собственные предубеждения, согласно Microsoft Inclusive Design.

Переживание исключения

1*PrdvH8QWWSO4296p_3eREg
«Отчуждение никогда не является путем вперед на наших общих путях к свободе и справедливости». – Десмонд Туту

Иногда для того чтобы лучше их понять, нужно пережить что-то самому. Вот что со мной счастливо произошло.

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

Обычно обычные сдачи крови длятся примерно 10 минут, но донорство тромбоцитов длится около 90 минут. Нам понадобилось около 20 минут, чтобы заметить, что у меня продула вена, поскольку моя рука была покрыта одеялом (потому что возвращающаяся кровь заставляет вас почувствовать холод).

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

Теперь я старался делать все правой рукой. Вдруг я заметил, что постоянно чередовать клавиатуру и мышь было неэффективно, и я хотел бы выполнить все задачи, используя только клавиатуру или мышь.

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

И тогда, именно в этот момент, я вспомнил прошлое, работавшее с a11y и пропускавшее эти исключения. О, человек!

Уровни исключений

Согласно набору инструментов Microsoft Inclusive 101, существует три уровня исключений:

  1. Постоянный: от которых страдают люди с такими пороками, как потеря конечностей, зрения, слуха или речи.
  2. Временный: испытывают те, кто имеет кратковременную травму или испытывает определенные события в течение короткого времени, например, смотреть на яркий свет, носить гипс или заказывать ужин в чужой стране.
  3. Ситуационный: испытывают те, чьи способности могут резко меняться в определенных условиях, например, неспособность хорошо слышать в громкой толпе, инвалидность по зрению в автомобиле или новые родители, выполняющие задание одной рукой.

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

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

Кодировка для изменений

Наконец я понял: ввести a11y означает внести вклад в a более инклюзивный мир! Вот несколько вещей, которые мы можем делать как инженеры:

  • Научиться писать код, поддерживающий a11y.
  • Добавьте соответствие a11y как часть своего контрольного списка разработки (так же, как вы работали бы над модульным тестированием и документацией).
  • Поговорите об a11y со своей командой, чтобы повысить осведомленность.
  • Оценка того, создает ли ваша команда доступный код, и регистрация 11-ти проблем как дефектов, которые команда должна решить.
  • Подвергая сомнению требования бизнеса, не охватывающие a11y, и требуя доступных альтернатив.
  • Делившись своим опытом и показывая своим сверстникам, как практически принять a11y, именно поэтому я пишу статью. 🙂

3 прагматические правила веб-доступности

Вот я со своей миссией разложить a11y на 3 практических правила, которые запомнятся вам. Из этих правил вы сможете получить остальные знания и найти рекомендации по внедрению a11y в свой проект.

Отказ от ответственности: Эти правила не заменяют необходимости учить a11y. Они также не исчерпывающие. Они просто предоставят вам базовую, но эффективную основу, чтобы вы могли самостоятельно пройти оставшийся путь.

Опять же, чтобы научиться a11y, я искренне рекомендую пройти бесплатный курс Web Accessibility на Udacity от Google:

Веб-доступность Udacity
Получите практический опыт создания веб-приложений. Вы поймете, когда и почему пользователям нужна доступность…www.udacity.com

Теперь до 3 прагматичных правил веб-доступности. Надеюсь, вы сможете взять их с собой и применять их каждый день на работе:

1) Настаивайте на семантических элементах HTML или DIY

1*YNNi0BjugGN3ouENT2g-Dw
«Семантическая паутина не сложна по своей сути. Язык семантической сети, по сути, очень и очень прост. Речь идет только об отношениях между вещами». – Тим Бернерс-Ли

Этот для меня есть золотое правило доступностируки вниз.

Семантический элементы – это те, которые передают определенное значение вместе с содержимым, которое они представляют, как <buttна>, &lt;inпуt>;, &lt;a>,

и

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

Они отличаются от нейтральный элементы, такие как <div>; and pan>, или прэсентационный элements like &lt;center> и не предоставляющих такой контекст пользовательскому агенту.

Семантические элементы в большинстве своем уже доступны (и удобны для SEO). Это означает, что они уже полностью охватывают многие аспекты a11y, например:

  • обработка фокус правильно с помощью клавиши Tab.
  • отвечая на события клавиатуры (как Enter, Esc, пробел, клавиши со стрелками).
  • представляет семантический информацию (имя, роль, состояние и ценность), чтобы вспомогательные технологии могли ее понять.
  • в соответствии с цветовой контраст требования со стилем по умолчанию.

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

Это означает, что вам нужно будет сделать такие вещи, как:

  • добавить tabindex="0" поэтому компонент будет частью природного порядка табуляции и использования. focus(), display: none или aria-hidden чтобы избежать фокусных ловушек. Узнайте о tabindex на странице Использование tabindex.
  • присоединить слушателей для ожидаемого события клавиатуры. Проверьте ожидания от компонента на шаблонах и виджетах WAI-ARIA Design.
  • использовать а роль чтобы придать некоторую семантику и ценность SEO. Узнайте все возможные роли с помощью категоризации ролей WAI-ARIA.
  • предоставить Атрибуты ARIA описать состояние и ценность Узнайте, какие атрибуты ARIA используют каждую роль в определении ролей WAI-ARIA.
  • следите за цветовой контраст и индикатор фокусаособенно при использовании outline: 0 (что не рекомендуется).

Что же касается семантических элементов, то следует помнить о еще нескольких вещах:

  • используйте теги разделения, чтобы структурировать свою страницу на разделы, иначе вам нужно предоставить роль ориентиров.
  • используйте теги заголовков для организации текстового содержимого, чтобы вы могли выразить связь между разделами и их порядок важности. Для записи: должен быть только один <h1> на каждой странице.
  • использовать <label for="...»> с полем формыds as &lt;input&gt;, &lt;select&gt; и