Pull to refresh

Comments 23

Приношу извинения первым читателям за не работавшие ссылки, всё уже исправил.
Интересно. Всегда задавался вопросом, где нужны заголовки и какого уровня. Название сайта/компании нет смысла делать заголовком? Вроде как с него начинается страница.
Далее, на примере с DNS. В подвале есть три заголовка второго уровня (компания, покупателям, магазины) и ссылки с ними. Они помогают при навигации или мешают? Нужны ли еще подзаголовки?

С точки зрения верстальщика, когда воспринимаешь только картинку, сложно прокрутить в голове другие способы использования сайта.
Да, делать название сайта или компании заголовком, на каждой странице бессмысленно, это будет только мешать. Более того, экранные чтецы заботятся об информировании пользователя, при открытии новой вкладки или окна браузера они сообщают название этой самой вкладки, где очень часто фигурирует название сайта или компании. Иногда даже они информируют по два раза, поскольку первый раз они сообщают о том, что такая вкладка открыта, а второй раз, когда она загружена и следом подсчитывают количество заголовков и ссылок. Ещё они сообщают название вкладки, если страница перезагружается или заголовок меняется. Таким образом пользователь никогда не забывает, где он находится. Что касается подвала сайта dns, то там всё довольно грамотно сделано. Все эти три заголовка полезны, если требуется получить информацию по ссылкам, которые под ними находятся. С любой страницы сайта можно быстро перейти туда и получить необходимую информацию, особенно мне нравится заголовок «Магазины» и ссылки, хранящиеся под ним, очень редко увидишь такую заботу о клиентах. Сразу можно перейти на интересующий адрес узнать телефон и посмотреть номер дома. На мой взгляд, там не требуются подзаголовки, ведь заголовки нужны, чтобы быстро перемещаться по большим страницам, а если каждый второй элемент делать заголовком, то вся суть их и уникальность теряется. В общем там всё в меру.
Еще вопрос. Какие впечатления от динамических сайтов? С использованием AJAX и подобных технологий? В частности, Angular. Обычные пользователи видят результат — нажал на ссылку, покрутилась анимация загрузки, появился новый блок с текстом. А незрячим как, понятно, что что-то изменилось и что именно?
Ajax — это вообще минное поле accessibility, которое заголовками не разминируется.

У таких страниц есть две основные проблемы: отсутствие достаточного объёма мета данных у элементов управления и рассинхронизация визуального и невизуального отображения интерфейса.

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

Вторая проблема, когда экранный чтец не распознаёт изменение страницы и не «отрисовывает» её новое состояние пользователю, решается с двух сторон: с одной стороны, средствами WAI-ARIA можно дать понять вспомогательной технологии, что вы перерисовали интерфейс, с другой, сам пользователь тоже должен иметь определённые навыки работы с rich internet application и уметь обновлять отображение страницы вручную и знать общие принципы работы своего чтеца с динамическим контентом.

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

Если я правильно понял, навигация по странице происходит сразу с выдачи списка заголовков и после выбора заголовка выдается список элементов под ним?

Разделяется хоть как то тип элемента на страницах, просто текст, ссылки, элементы форм — селекты, кнопки, текстбоксы?
Вот не поверите! Сегодня днём думал об написании статьи на тему доступности хабра. Удобство зависит от реализации. Тут, на хабре, всё достаточно удобно реализовано, я бы даже сказал, что этот сайт уютен по-своему. Есть некоторые вещи, которые недоступны или как-то недоделаны, но их мало.

Нет, принцип навигации вы поняли абсолютно неверно. Заголовки не являются ключевым, базисным пунктом опоры и навигации. Пользователь самостоятельно решает каким образом ему удобнее изучать или пользоваться страницей (зависит от страницы и от привычек). После загрузки страницы пользователь может попытаться найти заголовки, посещённые ссылки, кнопки поля форм и другие элементы, может вывести список ссылок, заголовков, полей форм и кнопок. Пользователь может по старинке двигаться, перебирая каждый видимый и невидимый элемент на странице, от начала к концу (линейная навигация). А может использовать средства быстрой навигации, прыгая через пол страницы к интересующему его элементу.

Конечно кнопки, поля форм, флажки, радиокнопки – все эти элементы отличаются и по ним можно производить быструю навигацию, перескакивая прямом на них.
Про хабр я бы так не сказал — для меня по 5 бальной шкале уверенная 3. Кому бы поставил 5 — даже не припомню, может быть я брюзга, но вот удобных сайтов днем с огнем не сыщешь. Везде косяки, перегруженность лишней информацией, по просту захламленными ссылками, рубрикатор, история, контекстная реклама и прочая, чему ни счесть числа…

Хорошим выходом иногда бывает мобильная версия сайта, но с движухой на адаптивность и mobile first рассчитывать на это редко приходиться
А в чём, на ваш взгляд, заключаются неудобства хабра?
я хабром пользуюсь только для чтения статей и редких комментов, планирую статью, когда выпущу новую версию своего продукта (думаю меня ждет немало странного на пути к реализации этого желания на хабре), то бишь rss + страница статьи + комменты. Это далеко не весь сайт. И так:

— шапка как всегда ухабистая, при открытии сразу страницу вниз, чтобы ее не читать. Описанный метод навигации по загловкам пригрывает — я почти сразу на контенте. Ситуацию бы решила первая ссылка/кнопка со стилем из bootstrap sr-only на главный контент

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

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

Слишком много букв, надеюсь без продолжения от меня
Да, эти формы для ввода текста со всякими визуальными примочками очень ненадёжны. Поэтому блокнот или notepad лучше них намного. Кнопка для быстрого перехода к контенту очень не помешала бы.
Для быстрого перехода по комментариям можно использовать переход по параграфам. Будет прочитываться рейтинг коммента, затем имя, затем какая-то безымянная ссылка, затем коммент, затем ссылка для ответа. И так до конца, немного экономит время, особенно если быстро пролистывать ссылки и рейтинги.
> У Хабра есть проблемы с accessibility, но не одну из них вы здесь не назвали, а то, что вами было названо, показывает лишь недостаточное владение вами той вспомогательной технологией, которую вы используете. Судя по всему, это JAWS.

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

Если мне, продвинуттому пользователю, неудобно чем то пользоваться это означает как правило плохой инструмент. Пишу это как разработчик.
Ситуацию бы решила первая ссылка/кнопка со стилем из bootstrap sr-only на главный контент


На Хабре вы итак можете перейти к главному контенту нажатием 1, если я правильно понял, какой screenreader вы используете.
Более того, если у вас настроено автоматическое чтение загружаемой страницы, то после перехода по 1 к основному контенту вам не надо будет вручную запускать чтение, тогда как анкерной ссылкой вам этого не достичь и нужны будут дополнительные команды.

Приходится извращаться и переход к следующему тексту коммента делать через поиск строки «избранн» Вот ни хера это не удобно


Нажимайте кнопку N. Если в теле комментариев не будет ссылок, то это в точности переход между коментами.

По привычке набираю коммент в а-ля блокноте, чтобы копипаст потом.


Ну это вообще к проблемам Хабра не имеет никакого отношения.

У Хабра есть проблемы с accessibility, но не одну из них вы здесь не назвали, а то, что вами было названо, показывает лишь недостаточное владение вами той вспомогательной технологией, которую вы используете. Судя по всему, это JAWS.

К сожалению, автор статьи по компетенциям также не на высоте. Я бы не советовал разработчикам адаптировать интерфейсы по рекомендациям из его постов. В действительности, заголовки — это лишь малая часть, причём, далеко не всегда первостепенная. Сводить адаптацию к поддержке только одного экранного чтеца (а автор сам признаётся в незнании альтернатив) — это просто глупо. Более того, в рамках даже одного чтеца существует несколько типовых сценариев взаимодействия, поэтому адаптация должна осуществляться с учётом разных вариантов работы. В общем даже просто ознакомительное чтение WCAG и WAI-ARIA будет более информативно и полезно, чем эти рекомендации.

Увы, незрячесть человека автоматически не делает его экспертом в accessibility. Точно также, как обычный пользователь мало чему может научить дизайнера, просто потому, что зачастую не воспринимает картину в целом и с техническими нюансами
> На Хабре вы итак можете перейти к главному контенту нажатием 1, если я правильно понял, какой screenreader вы используете.

Переход будет на заголовок страницы, после которого идут ссылки на рубрики этой статьи. Ссылкой можно достичь непосредственно текста, но чтобы скринридир (уменя jaws) начал правильно переходить по таким сылкам в теге назначения нужно дополнительное шаманство. Зачастую jaws некоректно обрабатывает переход по внутристраничным ссылкам. Хороший кайд есть в доке по bootstrap — ребята молодцы, сразу дают правильные советы.

> Нажимайте кнопку N. Если в теле комментариев не будет ссылок, то это в точности переход между коментами.

Спасибо — помогло. Я уже не молод и новые команды jaws до меня доходят долго. Вот открыл почитать справку по jaws — узнал еще пару вещей

> Ну это вообще к проблемам Хабра не имеет никакого отношения.

Да, наверно. Я ведь не занимался экспертизой хабра. С формами комментирования через блокнот поступаю везде — давлет негативный опыт на других сайтах при наборе текста, когда вдруг выяснялось, что текст не набирался (хз почему), коммент отправлялся после клавиши ввод, когда как мне требовалась новая строка, браузер начинал так сильно тормозить, что помогало только снятие задачи через диспетчер заддач. Тестировать хабр на предмет этих проблем не входило и не входит в сферу моих интересов
Здравствуйте, Никита.

Я очень вам благодарен за ваш полезный комментарий. Статью я уже немного поправил. Да, я не являюсь экспертом в области доступности веб-страниц, я лишь хотел передать определённые впечатления, основанные на собственном опыте использования экранного диктора, от использования заголовков на веб-страницах на примере некоторых страниц людям, которые занимаются разработкой и созданием этих самых страниц. Перед собой я не ставил задачи написать руководство или рекомендации, но, к сожалению, можно сделать вывод из вашего комментария, что у меня получились именно рекомендации.
Навязчивой контекстной рекламы я давно не видел. А излишние ссылки и куча оформительских элементов — это неизбежно, потому что кто-то считает это полезным и удобным. А всем не прикажешь.
Сейчас вроде как рекомендуют вместо явных уровней заголовков просто делать вложенные секции, которые всегда в качестве первого заголовка используют h1. С такой вложенностью читалки построят правильную иерархию?

<article>
  <h1>Какой-то заголовок (1)</h1>
  <section>
    <h1>следующий уровень (2?)</h1>
  </section>
  <section>
    <h1>Такой же уровень (2?)</h1>
    <h2>Уровень ниже (3?)</h2>
  </section>
</article>
Пожалуйста, продолжайте, очень интересно
Не согласен с автором — у меня другой опыт. Заголовки на странице не использую — мне на них наплевать потому, что на них наплевать создателям сайтов, то есть они несут мало информации. На каждой странице просматриваю список ссылок и ориентируюсь в основном на него. Переход на первое последнее поле ввода/формы insert+ctrl+home/end заголовки никаким припеком. На сайты с 900 ссылок рекомендую просто забить — ну к чему они вам? Конкретно про им — рекомендую алиэкспресс, уж цены подешевле, хоть и сайт у них тоже чмошный :)
Вы по всей видимости не поняли сути статей. Перед собой я ставил задачу не передать свой опыт использования экранного чтеца, потому что большинству людей, бывающих на этом сайте этот опыт девать некуда просто, а пояснить специфику использования заголовков. Объяснить актуальность и востребованность использования заголовков в различных местах сайта. Список ссылок тоже очень полезная вещь, это отрицать просто глупо, особенно, когда в нём есть поиск по первым буквам и фильтр посещённых ссылок, но этим списком я пользуюсь только когда нет другой альтернативы. Вот, например, на хабре, зачем мне вызывать громоздкий список ссылок, когда достаточно лишь нажать дважды клавишу, перейти сразу на заголовок статьи, далее стрелочками пропустить список хабов и читать спокойно. А что касается больших, неграмотно построенных страниц, конечно, когда есть альтернатива, то их можно избегать, но вот альтернативы сайту никса, о котором велась речь в статье, я пока не видел.
Из статьи мне не было понятно, что ставилась миссионерская задача.
Учту при будущей деятельности.
Sign up to leave a comment.

Articles