Имеет ли смысл использование aria-extended на панели навигации?

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

В настоящее время я сосредоточен на использовании новых семантических элементов HTML5. Я обнаружил, что шаблон начальной загрузки ASP.NET Core по умолчанию не использует элемент <nav> для панели навигации, и поэтому искал, как его правильно применить.

шаблон навигационной панели по умолчанию в Bootstrap действительно рекомендует использовать <nav>. Однако я не понимаю, какова цель примененного к нему атрибута aria-expanded. После того, как узнал о преимущества, которые он предлагает для программ чтения с экрана (с указанием, свернута панель навигации или нет, в данном случае, когда размер экрана небольшой, например, для смартфонов), я все еще не понимаю, должна ли она быть там на все. (И следует ли применять aria-controls, что не является t в шаблоне начальной загрузки по умолчанию.)

Позволь мне объяснить:

  • Некоторые из этих атрибутов арии, кажется, описывают визуальное поведение. Есть ли вообще смысл описывать незрячим то, чего они не видят?
  • При правильном применении семантических элементов <nav> и <main>, разве программы чтения с экрана не имеют под рукой всю необходимую информацию, чтобы быстро пропустить панель навигации (эквивалент ее скрытия для видящих)?

Разве не лучшей альтернативой было бы просто скрыть механизм переключения навигации для незрячих людей? Тогда у меня будет вопрос, как это сделать. Можно ли скрыть кнопку с помощью role="presentation" и / или aria-hidden="true"?


html twitter-bootstrap-3 accessibility wai-aria semantic-markup
person Steven Jeuris    schedule 15.02.2017    source источник
comment
У вас есть функциональный пример, который мы можем увидеть? На первый взгляд, вы задаете обоснованный вопрос о необходимости представлять что-либо в ARIA, когда это всего лишь визуальный эффект. Загвоздка в том, что контекст является ключевым фактором, конечно же, как и кодирование. На примере я могу загрузить его в программу чтения с экрана или посмотреть код и дать вам конкретный отзыв.   -  person aardrian    schedule 15.02.2017
comment
@aardrian Может быть, официальный пример панели навигации Bootstrap? К сожалению, эта веб-страница не содержит элемента <main>, на который я ссылаюсь в своем вопросе, но он может соответствовать вашим целям. Также должно быть достаточно легко добавить его после панели навигации (используя F12).   -  person Steven Jeuris    schedule 15.02.2017
comment
@aardrian Что касается контекста: панель навигации в начальной загрузке по умолчанию может быть свернута или развернута на экранах меньшего размера, например, на смартфонах. На экранах большего размера он отображается постоянно, и переключатель панели навигации не отображается. (Я также добавил этот контекст к вопросу.)   -  person Steven Jeuris    schedule 15.02.2017

Ответы (2)


arrow_upward
1
arrow_downward

Используя пример, который вы цитируете на https://getbootstrap.com/examples/navbar/, необходимо aria-expanded.

В большем окне просмотра «раскрывающееся» меню скрывает все подпункты. Они скрыты не только визуально, но и для программ чтения с экрана. aria-expanded помогает дать пользователю контекст, доступно ли больше, а также дает некоторое представление о том, куда последующие табуляторы могут привести пользователя.

В более узком окне просмотра, где навигация превращается в гамбургер, это все еще применимо. Вдвойне, поскольку это относится и к самому гамбургеру.

Этот контекст важен, поскольку aria-controls поддержка - это какашка (цитирую Хейдона).

Бывают случаи, когда каждый элемент в меню доступен с помощью вкладок, даже если его нет визуально. В этом случае aria-expanded не так важно, но aria-controls будет иметь большее значение.

Отдельно, это меню нуждается в лучшей :focus подсветке для зрячих пользователей клавиатуры и в DOM-последовательности для меню по сравнению с логотипом в узком окне просмотра (на мой взгляд).

person aardrian    schedule 15.02.2017
comment
Я изучал, как Bootstrap изменяет DOM, чтобы скрыть эти элементы, и мне неясен механизм. Как получается, что он скрыт и визуально и для программ чтения с экрана? Кроме того, что больше соответствует моему первоначальному вопросу, почему вообще нужно скрывать его от программ чтения с экрана? Возможно, я не совсем понимаю, как «на практике» aria-expanded помогает обход (в данном случае вложенных списков) DOM. Кроме того, мне интересно, является ли поведение табуляции для программ чтения с экрана таким же, как в обычных браузерах. - person Steven Jeuris; 15.02.2017
comment
Поведение вкладок в программах чтения с экрана такое же, как и в обычных браузерах, поскольку программы чтения с экрана полагаются на обычные браузеры. Программы чтения с экрана добавляют дополнительную поддержку ориентиров, элементов управления и т. Д. Программы чтения с экрана уважают display:none, поэтому с помощью этого стиля легко что-то скрыть от программы чтения с экрана. В этом случае разработчик решает, почему он скрыт. По крайней мере, это менее многословный опыт. - person aardrian; 15.02.2017
comment
@StevenJeuris Продолжайте спрашивать, я бы предпочел, чтобы вы получили точное представление о том, как работают SR. Я также могу предоставить примеры, ресурсы и т. Д., Если хотите. Вариантов предостаточно. - person aardrian; 15.02.2017
comment
Спасибо за информацию о поведении табуляции. Это как-то объясняет это! Однако я не замечаю, что Bootstrap вводит display: none (по-видимому, ::before и ::after управляются, что я не понимаю, как это работает), но независимо от используемого механизма табуляция больше не останавливается на «скрытых» элементах, поэтому я понимаю необходимость ария атрибуты немного лучше. Возможно, тогда ответ на мой основной вопрос можно будет получить, если я лучше пойму, почему программы чтения с экрана полагаются на браузеры так, как они это делают сейчас. - person Steven Jeuris; 15.02.2017
comment
Например, разделение поведения табуляции или возможность его изменения (например, с помощью атрибутов aria) кажется мне более подходящим подходом для повышения доступности веб-сайтов. Для зрячих табуляция больше не останавливается на элементах, поскольку они больше не видны, но для незрячих это не аргумент. Разве не было бы разумнее иметь возможность пропускать контент на основе семантической группировки, которая уже достигается путем обертывания элементов в родительский элемент? - person Steven Jeuris; 15.02.2017
comment
Это особенно верно в случае панели навигации с обычными ссылками (без раскрывающихся списков); Основная причина скрытия навигационных ссылок - нехватка места на экране. Это то, что я называю «не аргументом» для незрячих. - person Steven Jeuris; 15.02.2017
comment
Лучший способ сделать веб-сайт доступным - это с использованием правильного HTML. Если все сделано правильно, ARIA потребуется только для сложных элементов управления (вкладки , деревья, карусели,…). Программы чтения с экрана позволяют переходить к содержанию на основе ориентиров ( <nav>, <main>, <footer>,…), но все равно получают те же преимущества от скрытых элементов, что и зрячие пользователи. Также не все пользователи SR слепы, поэтому визуальные эффекты должны совпадать. - person aardrian; 15.02.2017
comment
Ресурс для тестирования SR: webaim.org/articles/screenreader_testing Быстрая демонстрация использования SR: youtube.com/watch?v=q_ATY9gimOM - person aardrian; 15.02.2017

arrow_upward
1
arrow_downward

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

Этот вопрос должен быть первым в любом руководстве по ARIA.

При правильном применении семантических элементов <nav> и <main>, разве программы чтения с экрана не имеют под рукой всю необходимую информацию, чтобы быстро пропустить панель навигации (эквивалент ее скрытия для видящих)?

А этот - второй.

Edit: Когда я прочитал эти вопросы, я подумал, что «этот парень уже все понял». Учебники ARIA редко отвечают на эти вопросы, потому что они зависят от контекста, но постановка этих вопросов должна быть первым шагом перед использованием ARIA. Например. Карусели изображений для слепых - это совершенно другой пользовательский опыт. Присвоение атрибута aria-controls кнопке «предыдущая» не дает большей интеллектуальности системе, основанной на визуальных эффектах. ARIA - это не чудесная панацея.

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

aria-expanded может обеспечить удобство использования программ чтения с экрана, сообщая, можно ли открыть элемент для отображения дополнительных элементов (например, в раскрывающемся меню).

Вы не можете применить aria-expanded непосредственно к элементу nav, потому что он должен быть установлен на интерактивном элементе (например, button), чтобы сообщить, что это контролирует видимость другого элемента внутри того же контейнера (, который может быть < / em> nav).

Лучшая альтернатива, которую я вижу, - это ничего не скрывать, чтобы помочь людям, не использующим программы для чтения с экрана. Вместо того, чтобы сворачивать панель навигации при небольшом разрешении экрана, вполне возможно:

  1. всегда показывай это
  2. отображать постоянный значок меню для перехода к строке меню (или временно отображать его внутри области просмотра)

Это дает возможность прокручивать строку меню (для людей, не понимающих, что может означать этот значок с тремя параллельными линиями) и позволяет пользователям программ чтения с экрана перечислять все внутренние ссылки.

Конечно, все обстоит совсем иначе, если вы создаете веб-приложение, а не простой веб-сайт, и ARIA может быть более полезной в этом контексте.

person Adam    schedule 16.02.2017
comment
Вы утверждаете, что на эти вопросы есть ответы в большинстве руководств по ARIA, или что они должны быть, а не? Я не понимаю, как ваш ответ дает точный ответ на эти два вопроса. - person Steven Jeuris; 16.02.2017
comment
Я отредактировал свой ответ (короче, это зависит от контекста). Фактически, эти вопросы уже сами по себе являются ответом. Наилучший выбор - заставить пользователей программ чтения с экрана игнорировать ожидаемый визуальный эффект и обеспечить им лучший пользовательский интерфейс. ARIA часто является импровизацией, пытаясь прояснить то, что изначально не ясно. Кому действительно нравится раскрывающееся меню со скрытыми подпунктами? Предоставляет ли свернутая / развернутая информация больше информации, чем "Открыть меню" на простом английском языке? Мы можем использовать ARIA для улучшения навигации, но мы должны в первую очередь сосредоточиться на том, чтобы сделать веб-сайты доступными без ARIA. - person Adam; 17.02.2017