Одна из базовых составляющих любого аудита — методология. Особенно, когда в команде нет специалистов по доступности. С ним легче подстроить процесс тестирования под нужды компании и избежать сложностей и пробелов только ручного или автоматического тестирования.
Кроме этого, у любого аудита есть чёткая методология, по которой он проводится. Благодаря этому подходы к доступности станут прозрачными, знания будет проще передавать и распространять среди членов команды, а будущие аудиты станет легче и быстрее проводить. Можно попросить помощи у экспертов по доступности с инвалидностью. Также есть компании, которые сами подберут подходящих респондентов. Заявление о соответствии (Conformance Claims) описывает уровень соответствия сайта рекомендациям из WCAG. В странах Евросоюза заявление о доступности обязательно должно быть у сайтов и мобильных приложений государственных органов.
Понимает Процесс Тестирования
Для того, чтобы определить элемент, вызывающий ошибку, требуется некоторая охота. Это также имеет удобный эффект отображения любых частичных элементов пользовательского интерфейса, которые визуально скрыты с помощью CSS. Другой результат для браузеров мобильных устройств может быть, когда есть отдельная мобильная версия, либо если сайт был взломан и содержит вирус или переадресацию на вредоносный сайт. Второй вариант встречается редко, но наносит серьёзный ущерб позициям и репутации сайта. Поэтому если Вы знаете, что отдельной мобильной версии сайта нет, то стоит провести анализ результата. Откройте содержимое ответа сервера и проанализируйте – нет ли там майнеров, вредоносных скриптов или содержания.
Не любой человек с особыми потребностями подойдёт на роль респондента для проверки конкретно вашего продукта. Например, человек с глухотой не поможет выявить проблемы с доступностью трекера задач. Взаимодействие с интерфейсом такого респондента не отличается от поведения других людей.
В статье I Used The Web For A Day With Just A Keyboard Крис Эштон приводит такой пример span, который должен быть ссылкой. К слову, упростить работу тестировщика по отладке поможет расширение для браузера Chrome LT Debug. https://deveducation.com/ появилось еще в 1997 году, но не получило широкого распространения в современном веб-дизайне.
Net
Различные мифы удерживают людей от его внедрения на своих проектах. Интересная особенность TAW — способность генерировать поднаборы WCAG 1.0 и тестировать сайт на соответствие им. На accessibility testing это самом деле, сложно достичь идеального состояния доступности. По этой причине нам необходимо убедиться, что мы располагаем только самой актуальной информацией, предоставляемой пользователю.
Такой продукт должен быть доступен и удобен в использовании всем, в том числе пользователям с особенными потребностями. Например, люди с нарушениями зрения, слуха и другими физическими или когнитивными проблемами. В результатах показываются нарушенные на странице правила. Основные функции панели инструментов — обнаружение компонентов веб-страницы, предоставление доступа к альтернативному представлению контента страницы и облегчение использования сторонних онлайн-приложений.
Если это не ваш сайт, обратитесь к ним публично – игнорирование доступности противоречит закону, и в 2019 году в США было подано 2256 исков о доступности. Если вы хотите услышать озвучку нефокусируемых элементов, воспользуйтесь кнопками курсора “вверх” и “вниз” (это называется “режим браузинга”). NVDA также озвучивает содержимое элементов, если вы навели на них курсор. Для тех, кто столкнулся с ними впервые, они могут смотреться угрожающе – их так много! Но не отчаивайтесь – приступить к тестированию доступности действительно очень просто!
Рассмотрим некоторые популярные инструменты для автоматизированного тестирования доступности. Отметим, что в США необходимость тестирования веб-доступности закреплена на законодательном уровне. Accessibility Testing переводится как «тестирование доступности». Это проверка программ на пригодность к использованию людьми с нарушениями слуха, зрения, двигательной активности. Таким образом, речь идёт не об изменении приложения, а только о его улучшении для обеспечения нужного уровня доступности и удобства использования для этой категории пользователей. Тестирование мобильной доступности с учётом правил A11Y — тема, которая обсуждается всё чаще.
Что Такое Мобильные Приложения Для Людей С Ограниченными Возможностями?
В самом конце сравнивают результаты проверки структурированной и случайной выборок, если их было две. Появление новых типов контента или выводов — сигнал о том, что случайная выборка получилась нерепрезентативной. В этом случае нужно вернуться к третьему и второму шагу, чтобы расширить выборку с учётом новых типов и состояний. Это нужно повторять до тех пор, пока обе выборки не будут хорошо отражать контент и структуру сайта.
После этих исправлений давайте возьмем их за другое вращение в инструментах тестирования. AXe оценивает влияние a11y-проблем по-разному на WAVE, в этом примере проблема с альтернативным текстом имеет решающее значение, проблема tabindex серьезна, а другие умеренные. Стоит отметить, что эта презентация заставляет меня разрешать все нарушения, потому что она говорит мне, что их девять, а не WAVE, сообщивших мне, что есть одна ошибка и девять предупреждений. Блокировку трафика из других стран иногда включают, чтобы избавится от угрозы во время DDOS-атаки, но если она включена постоянно, то это может привести к потере части трафика.
Пробуйте различные инструменты и технологии, соберите набор для тестирования доступности, который подходит вам наилучшим образом. Думаю, что автоматизированные инструменты вроде Lighthouse будут важной частью этого набора, но они не всемогущи – рано или поздно вам придется закатать рукава и заняться ручным тестированием. Ручное и автоматизированное тестирование доступности можно и нужно проводить, принимая во внимание рекомендации Руководства по доступности веб-контента (WCAG). При этом, чтобы избежать возможных проблемных вопросов, рекомендуется внедрять этот вид тестирования на ранних стадиях жизненного цикла разработки ПО. Web Accessibility Inspector – инструмент для тестирования доступности десктопных приложений. На экране браузера отобразится веб-страница с отмеченными проблемными элементами.
Например, во WCAG 2.1 (Web Content Accessibility Guidelines, Руководство по обеспечению доступности веб-контента) контрольная точка — это выполнен или нет критерий успешности. Это полезная практика, благодаря которой каждый сможет вживую увидеть, как респондент взаимодействует с продуктом, поговорить с ним лично и «на месте» зафиксировать проблемы в рамках своей зоны ответственности. Если тестируемый продукт предназначен для широкой аудитории, приглашайе на тестирование незрячих и слабовидящих пользователей и людей с нарушением моторики.
Убедитесь, что респондент понимание цели и процесс тестирования. Линтеры и плагины помогут автоматизировать проверку кода, а также легче и быстрее интегрировать цифровую доступность в веб. С ним можно найти много базовых ошибок доступности, достаточно сделать скриншот или запись экрана.
Как Сделать Приложение Оптимизированным Для Людей С Ограниченными Возможностями?
Пока я просто собираюсь использовать ngrok для создания временного общедоступного URL-адреса для моего локального хоста и предоставить эту ссылку для Tenon. Tenon отличается, поскольку это веб-сервис, который вы можете использовать так же, как W3C HTML Validator, которого мы все знаем и любим, но для доступности. Просто дайте ссылку или вставьте разметку вашего пользовательского интерфейса, и она создаст отчет для вас. Есть несколько (платных) способов интеграции Tenon с инструментами сборки или CI-серверами, но это мясо для другого сообщения в блоге. Во-первых, давайте посмотрим, что каждый инструмент говорит нам, прежде чем мы вносим какие-либо изменения.
Если при этом разница будет существенной, то сайт с большой вероятностью будет понижен в результатах поиска за клоакинг, даже если это было сделано неумышленно или для благих целей. Чтобы продукт всегда оставался доступным, нужно наладить внутренние процессы. Например, самостоятельный, внешний, автоматический или подробный.
Не забывайте про регулярное автоматическое и ручное тестирование. Это поможет заранее отлавливать ошибки и быстро их исправлять. Ещё полезно периодически проводить тестирование с клавиатуры. Так можно найти часть потенциальных проблем со скринридерами. Если нужно провести юзабилити-тестирование, то сценарий хорошо составить таким образом, чтобы тест выявлял только проблемы с доступностью, а не общие проблемы юзабилити. Автоматическое, экспертное и другие виды ручного тестирования могут пропустить некоторые важные и неочевидные проблемы.
Еще один способ проверить базовые ошибки — это использовать фреймворки. Самые распространенные среди них — UBKAccessibilityKit и GSCX. Онлайн-валидатор W3C поможет понять, насколько верстка соответствует международным стандартам цифровой доступности.
А перед этим лучше исправить критичные ошибки, которые обнаружили автоматические инструменты. Это ускорит пользовательское тестирование и поможет избежать лишних расходов. Выявление (и исправление) проблем доступности – важная часть навыков любого фронтэнд-разработчика, но зачастую сложно отделить полезные инструменты и техники от менее полезных.
По завершении аудита появляется итоговая оценка и свод рекомендаций, которые помогут повысить уровень доступности сайта. TAW – это инструмент автоматизации тестирования доступности, разработанный компанией CTIC Centro Tecnólogico на основе WCAG 1.0 и 2.zero. Достаточно ввести URL вашего сайта и TAW, как и aXe, выявит проблемы доступности и предложит решения по ним. WAVE – это инструмент, разработанный компанией WebAIM для оценки доступности веб-приложений. Он представляет собой панель инструментов для браузера Firefox. WAVE оценивает доступность при помощи браузера и ничего не хранит на сервере.
- За исключением одного шамболического усилия, все инструменты дали довольно последовательные результаты для этого, по общему признанию, ограниченного теста UI.
- Уровень доступности активно развивающихся больших продуктов постепенно снижается из-за постоянных изменений.
- Также стоит подумать об основных функциях, которые есть в продукте.
- Он включает заполненный VPAT, информацию о продукте или услуге, поддерживаемых вспомогательных технологиях и другие детали.
Так что начинать оценку хорошо с автоматического аудита, но не стоит на нём останавливаться. В этой категории типы выделены на основе того, какой вид тестирования преобладает. В этом разделе мы собрали самые распространённые типы и сгруппировали их так, чтобы было проще в них разобраться и выбрать походящий. В процессе тестирования не стесняйтесь задавать респонденту дополнительные вопросы — комфортно ли ему взаимодействовать с продуктом, понятен ли контент и интерфейс, какие изменения можно было бы внести на его взгляд. Прежде чем предлагать сценарий респондентам, пройдите его со скринридером и без использования мыши. Узнайте, как респонденту будет удобнее добраться до места тестирования.
Отчет Firefox не заменяет Lighthouse, а наоборот — лучше использовать оба инструмента для аудита. Так увеличится шанс найти и исправить максимальное количество возможных ошибок. Не все пользуются страницей при помощи мыши, трекпада или тачскрина – некоторые используют клавиатуру. HTML поддерживает навигацию с клавиатуры по умолчанию, если она верно сделана, и так повелось с зарождения Интернета. Однако где-то по дороге значительное количество разработчиков или забыли об этом, или никогда об этом и не узнавали.
