Комментарии 9
В статье о доступности пример html и css кода в картинках… нет слов…
Единственный момент уточню, что если навигация сгруппирована списком, то для быстрого перехода за ее пределы пользователям экранных дикторов достаточно нажать одну клавишу на клавиатуре.
Гораздо хуже когда делают блок навигации без группировки списком.
Гораздо хуже когда делают блок навигации без группировки списком.
Вот, если честно, никогда не обращал внимания на эти вещи. И ни разу не пользовался ссылкой «skip to content», считая ее чем-то ненужным. А вот заголовок h1 (или какой-нибудь другой) непосредственно перед основным содержимым — это то, что я безо всякого сомнения ожидаю на каждой адекватной веб-странице.
На этой он, кстати, тоже есть. Так что фронтендерам хабра большой плюс! В отличие, например, от их коллег из яндекс почты, которые в принципе считают, что заголовки — это зло.
И еще хотелось бы, чтобы выходило больше статей о доступности мобильных приложений. Т.к. в вебе мало приходится наблюдать совсем плохо доступных сайтов, а на мобилках — сплошь и рядом, в т.ч. от крупных компаний.
На этой он, кстати, тоже есть. Так что фронтендерам хабра большой плюс! В отличие, например, от их коллег из яндекс почты, которые в принципе считают, что заголовки — это зло.
И еще хотелось бы, чтобы выходило больше статей о доступности мобильных приложений. Т.к. в вебе мало приходится наблюдать совсем плохо доступных сайтов, а на мобилках — сплошь и рядом, в т.ч. от крупных компаний.
Да, согласен с вами, заголовки важны. И не только h1, а все шесть уровней, при правильном применении.
Мне в этом смысле очень показательной показалась страница документации asyncjs. Она крайне перегружена, на ней одной, фактически, вся документация располагается. Но за счет заголовков и их правильной вложенности, навигация с помощью скринридера осуществляется без проблем. И попасть в нужное место, на самом деле, довольно быстро и просто.
Не вводите людей в заблуждение: полная реализация всех требований WCAG это не простая, а невероятно сложная задача и с лёгкостью может увеличить стоимость UI разработки раз в 10.
Требование навигации с помощью клавиатуры это всего лишь одно из многочисленных требований. Которое не является ни самым сложным ни, пожалуй, самым важным.
На практике, пользователи скорее всего столкнутся со следующими проблемами: дальтонизм, близорукость, дрожащие руки и низкий интеллект (да, доступные сайты это те которыми могут пользоваться даже идиоты).
Профессионально занимался accessibility 2 года и, по-моему, опыту наиболее сложные проблемы c точки зрения трудоёмкости это:
Требование навигации с помощью клавиатуры это всего лишь одно из многочисленных требований. Которое не является ни самым сложным ни, пожалуй, самым важным.
На практике, пользователи скорее всего столкнутся со следующими проблемами: дальтонизм, близорукость, дрожащие руки и низкий интеллект (да, доступные сайты это те которыми могут пользоваться даже идиоты).
Профессионально занимался accessibility 2 года и, по-моему, опыту наиболее сложные проблемы c точки зрения трудоёмкости это:
- Резиновость и мелкие элементы: увеличьте размер шрифта в 2 раза и масштаб в 2 раза, убедитесь что ничего не едет, удельная площадь теста стала больше и горизонтальных скролов нету.
- Иконки: чёткие и яркие, должны соотвествовать размеру текста. Кроме того, вам потребуется ещё 2 комплекта для 2 контрастных режимов в windows. Скорее всего, вам придётся SVG-ировать все иконки
- Костыли и неудачные фреймворки и библиотеки: WCAG предъявлет наивысшие требования к качеству и логичности вёрстки: абсолютно валидный HTML, никаких нестандартных компонентов и табличной вёрстки, внезапных изменений элементов. Генерация всех элементов на лету (аля extjs) – неудачное решение. Возможно вам придётся отказаться от каких-то библиотек/фреймворков и всё переписать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Автостопом по доступности: Ссылки для пропуска навигации и секции