1. Все скринридеры довольно сильно отличаются друг от друга — намного сильнее, чем обычные браузеры. Конечное звучание зависит и от скринридера, и от браузера, и от версии операционной системы.
2. Ни один скринридер не поддерживает WAI-ARIA на 100%. Многие приёмы и примеры с официального сайта могут работать в реальном скринридере не совсем корректно.
3. При включении скринридера браузеры переходят в особый режим работы. В этом режиме клавиатурное взаимодействие начинает определяться aria-разметкой, поэтому тестировать навигацию с клавиатуры нужно обязательно при включённом скринридере.
4. Внедрять поддержку доступности для сайта или сервиса лучше всего ещё на этапе дизайна. UX-составляющей в этом процессе очень много. Дизайнер должен учитывать поведение скринридера, взаимодействие компонентов сайта, цветовую палитру, размеры шрифтов.
5. Есть множество нюансов дизайна. Например, нельзя показывать изменение некоторого состояния элемента одним лишь цветом. Нужно или рисовать иконку, или добавлять текстовое описание.
6. Доступная цветовая палитра — это боль. Официальная формула расчёта контрастности не совсем удачна и может выдавать странные результаты для многоцветных изображений. Например, контрастность белого текста на цветной кнопке или плашке может оказаться недостаточной.
7. Если планируется аудит доступности сайта или сервиса сторонней компанией-аудитором, то следует знать, что это весьма непростой процесс: аудитор будет придираться даже к чтению графиков и карт.
8. Кстати говоря, встраиваемые гуглокарты, в отличие от сайта Google Maps, сами по себе не поддерживают чтение. Нужно дорабатывать их самостоятельно.
9. Аналогично, библиотеки для рисования графиков сами по себе не учитывают скринридеры. В каждом конкретном случае нужно придумывать своё решение этой проблемы.
10. Если аудитор проверил страницу, то это ещё не значит, что она теперь точно доступна на 100%. Попросите его проверить её ещё раз, и она вам найдёт новые ошибки. Это следует учитывать, когда аудит изначально заказан клиентом, а вы заказываете у аудитора предварительные проверки.
А можно раскрыть более подробно личный опыт реализации accessibility. В настоящий момент разрабатываем магазин и честно говоря, я задаюсь этим вопросом. Но с какого конца начать, нет понимания. С командой сошлись на том, что минимум титры к видеоматериалам. Возможно синхронист, но нет понимания востребованности. Но, это пока в сторону людей с ограничением по слуху, а с ограничением по зрению...
Мысли ... В России все плохо и с доступной средой и с материалами для уникальных людей. Если посмотреть на прогрессивные страны - редкий концерт даже реп исполнителей обходиться без сурда, а потенциал лояльной аудитории огромный.
Из личного опыта реализации accessibility:
1. Все скринридеры довольно сильно отличаются друг от друга — намного сильнее, чем обычные браузеры. Конечное звучание зависит и от скринридера, и от браузера, и от версии операционной системы.
2. Ни один скринридер не поддерживает WAI-ARIA на 100%. Многие приёмы и примеры с официального сайта могут работать в реальном скринридере не совсем корректно.
3. При включении скринридера браузеры переходят в особый режим работы. В этом режиме клавиатурное взаимодействие начинает определяться aria-разметкой, поэтому тестировать навигацию с клавиатуры нужно обязательно при включённом скринридере.
4. Внедрять поддержку доступности для сайта или сервиса лучше всего ещё на этапе дизайна. UX-составляющей в этом процессе очень много. Дизайнер должен учитывать поведение скринридера, взаимодействие компонентов сайта, цветовую палитру, размеры шрифтов.
5. Есть множество нюансов дизайна. Например, нельзя показывать изменение некоторого состояния элемента одним лишь цветом. Нужно или рисовать иконку, или добавлять текстовое описание.
6. Доступная цветовая палитра — это боль. Официальная формула расчёта контрастности не совсем удачна и может выдавать странные результаты для многоцветных изображений. Например, контрастность белого текста на цветной кнопке или плашке может оказаться недостаточной.
7. Если планируется аудит доступности сайта или сервиса сторонней компанией-аудитором, то следует знать, что это весьма непростой процесс: аудитор будет придираться даже к чтению графиков и карт.
8. Кстати говоря, встраиваемые гуглокарты, в отличие от сайта Google Maps, сами по себе не поддерживают чтение. Нужно дорабатывать их самостоятельно.
9. Аналогично, библиотеки для рисования графиков сами по себе не учитывают скринридеры. В каждом конкретном случае нужно придумывать своё решение этой проблемы.
10. Если аудитор проверил страницу, то это ещё не значит, что она теперь точно доступна на 100%. Попросите его проверить её ещё раз, и она вам найдёт новые ошибки. Это следует учитывать, когда аудит изначально заказан клиентом, а вы заказываете у аудитора предварительные проверки.
А можно раскрыть более подробно личный опыт реализации accessibility.
В настоящий момент разрабатываем магазин и честно говоря, я задаюсь этим вопросом. Но с какого конца начать, нет понимания. С командой сошлись на том, что минимум титры к видеоматериалам. Возможно синхронист, но нет понимания востребованности. Но, это пока в сторону людей с ограничением по слуху, а с ограничением по зрению...
Мысли ... В России все плохо и с доступной средой и с материалами для уникальных людей. Если посмотреть на прогрессивные страны - редкий концерт даже реп исполнителей обходиться без сурда, а потенциал лояльной аудитории огромный.
Ни один скринридер не поддерживает WAI-ARIA на 100%
а почему так, это технически невозможно? хотя почему тогда стандарт существует..