Pull to refresh

Comments 11

Лучше всего подобное реализовывать с помощью details+ summary habr.com/ru/post/477520, а чтобы было проще разрабатывать доступные сложные компоненты, W3C выпустил authoring practices: www.w3.org/TR/wai-aria-practices-1.1, где можно посмотреть многие примеры.
Хорошая тема, я пропустил первую статью и с интересом ее прочитал.
При планировании интерфейсов рассматриваете ли вы все типа ограничений, или только визуальные? Их обычно выделяют в группы: визуальные, слуховые, возможность работы мышью, возможность работы клавиатурой и т.п. Можно для примера посмотреть VPAT шаблон.

Еще для меня показательный пример страницы Google и Яндекс. Если открыть обе страницы, то фокус будет сразу в поиске — это правильно. После поиска, если нажать tab, то в Google предложат сразу перейти на результаты. А в Яндексе будет фокус скакать по невидимым и невыделяемым ссылкам. Тому кто работает с VoiceOver или не использует мышь, страница Гугл поиска будет предпочтительнее.
UFO just landed and posted this here
На duckduckgo тоже нет правильной поддержки accessibility. Попробуйте по tab перейти к результатам поиска.
можно попробовать минималистичную версию ya.ru
там только поиск, а ненужных ссылок куда меньше чем у Гугла или duckduckgo.com
Нет, в ya.ru и duckduckgo та же проблема с результатами поиска. На странице результатов нельзя просто перейти по Tab на найденные страницы. Фокус перемещается по куче скрытых ссылок.
Попробуйте сами. При поиске на google при нажатии на tab будет окно «перейти к основному контенту?». То есть при использовании клавиатуры переход к результатам поиска в google будет tab, enter
Вряд ли большое количество пользователей скринридеров перемещаются по странице с помощью tab. Это очень медленно. В яндексе результаты поиска выводятся в заголовках 2 уровня. И на них можно сразу перейти по цифре 2 над буквами. У гугла результаты отображаются заголовками 3 уровня. А вот что и правда подстегнуло меня окончательно перейти с яндекса на гугл — это то, что они убрали ссылки из заголовков результатов поиска. Из-за этого клики по ним ведут себя нестабильно.
Я не совсем понял про цифру 2, можете пояснить? Помимо особенностей зрения, есть еще физические ограничения по работе с мышью и клавиатурой.

Для теста проверил. На странице Яндекса для перехода на первый результат поиска нужно нажать tab 27 раз. При этом Narrator будет пытаться читать каждый проходящий элемент.

А чтобы отправить этот коментарий совсем непонятно как использовать tab. Элементы не выделяются при фокусе. Но похоже что 2 раза.
Да, я рассуждаю с точки зрения пользователя скринридера. У людей с другими нарушениями, вероятно, другие алгоритмы работы с веб-страницами.

Скринридеры же обладают большим количеством горячих клавиш навигации по веб страницам. В частности в основных windows скринридерах jaws и nvda цифры 1-6 на буквенном блоке позволяют перемещаться по заголовкам 1 — 6 уровня. У скринридеров других ОС, вероятно, тоже есть что-то подобное.
Поэтому мой типичный кейс поиска в гугле выглядит так:
— ctrl+l — перемещаемся в адресную строку.
— вводим запрос, жмем enter.
— 3 на буквенном блоке — я на первом результате поиска.

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

На ваш комментарий, например, я ответил следующим образом:
— Увидел пришедшее письмо с ответом на мой коммент.
— Перешел по ссылке ответить.
— После загрузки страницы нажал горячую клавишу e для перехода к элементу редактора.
— Нажал пробел для перехода в режим редактирования.
— Написал текст и ctrl+enter.

Спасибо, это интересно. Я не знал о таких возможностях скрин ридеров.

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

Есть еще вариант не городить модальные окна там, где они не требуются, и по нажатию элемента показывать скрытый до этого блок с формой для логина.
Sign up to leave a comment.