Ярлыки клавиш обязательны для соответствия 508

Ответ 1

Я частично согласен с тонким, но соглашусь с первыми двумя предложениями комментария слева.

К предложениям, которые я имею в виду, относятся:

Они должны быть доступными - клавиатурой для 508. Я делаю упор на разницу между ярлыком и достижимым

Крикс сказал:

Самое большое, что дизайнеру UI/UX говорят, что сочетания клавиш для выпадающего меню NEEDS позволяют сочетать быстрые клавиши со скоростью 508.

Вам нужно прояснить это. Вы имеете в виду простой <select> или выпадающий список для меню навигации? Как сказал Тенис в комментариях, в разделе 508 говорится, что нужно достичь цели. Возникает вопрос:

Как добавляете в свой аккаунт ярлыки? Вы добавляете их через атрибут accesskeys или как Gmail/Yahoo Mail добавляет сочетания клавиш?

Я думал, что сделал ответ о AccessKeys, но не могу его найти. По сути, accesskeys звучит как замечательная вещь, но если вы посмотрите на ключи, которые вам разрешено использовать, которые не мешают ни с помощью браузера, ни с помощью клавиш Assistive Technology, вы совершенно ограничены. Gez Lemon сделал обзор AccessKeys и их проблемы. Если вы хотите использовать метод Yahoo! Mail, вам нужно сделать немного больше работы. Тодд Клоотс сделал презентацию о ARIA, которая может быть полезна. Это приводит меня во вторую часть. Если вы сильно используете JavaScript на сайте для работы, люди используют и 1194.21 (программное обеспечение/ОС) и 1194.22 (веб) стандарты для оценки сайта. Если сайт использует JS для создания navmenu (пример меню YUI), поведение выпадающего списка должно быть доступно с клавиатуры. Я бы сказал, что это подпадает под:

§ 1194.21 Программные приложения и операционные системы.
(a) Когда программное обеспечение предназначено для работы в системе с клавиатурой, функции продукта должны выполняться с клавиатуры, где текстовая функция может распознаваться самой функцией или результатом выполнения функции.

и

(c) Должна быть обеспечена четкая отображаемая на экране индикация текущего фокуса, которая перемещается между элементами интерактивного интерфейса при изменении фокуса ввода. Фокус должен быть программно открыт, чтобы вспомогательные технологии могли отслеживать изменения фокусировки и фокусировки.

Я говорю, что оба стандарта используются, потому что (а) говорит, что вы должны иметь возможность войти в навигационную зону с клавиатуры. (c) вступает в игру, потому что некоторые меню вы можете tab ко всем родительским элементам, но вы не можете попасть в выпадающую часть без мыши. Я видел меню, что вы можете tab в подменю, но меню не открывается. Поэтому, если вы просто используете клавиатуру (imersion) мобильности, а не используя JAWS, вы не будете знать, где вы находитесь.

Я вижу приложения Windows Forms, имеющие это, но для веб-разработки я не думаю, что это обязательно, чтобы быть "совместимым"

Я бы сказал, что фактические приложения, такие как Word, Outlook и т.д., содержат ярлыки для часто используемых команд. Если вы делаете это для веб-приложения, я бы подумал о том, сколько вы делаете. Это не обязательная часть, которая будет соответствовать требованиям. Если вы делаете навигационную панель, я рекомендую использовать роли ARIA, в частности role="navigation", для родительского элемента как наилучшую практику.

Ответ 2

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

Единственное упоминание, которое я могу найти в стандартах 508, которые упоминают использование клавиатуры это (verbatim):

Раздел B - Технические стандарты

§ 1194.21 Программные приложения и операционные системы.

(a) Когда программное обеспечение предназначено для работы в системе с клавиатурой, функции продукта должны исполняться с клавиатуры, где самой функцией или результатом выполнения функции может быть различались по тексту.

Мое вращение на этом:

• Комбинация клавиш для параметров навигации может быть непрактичной, учитывая количество операций/функций, которые может содержать данный раздел. Важно, чтобы они были доступны - как-то - с клавиатуры.
• С точки зрения UX, ключевые функции должны иметь ярлыки "только потому, что" это хорошая практика UX. Но для быстрого доступа все идет от одной канавы к другой.
• 508!= доступность, но если вы работаете на gov/edu, скорее всего, это в вашем PD, чтобы быть совместимым.

Другим концом спектра является WCAG, который в значительной степени связан с соблюдением 508, и в моей книге лучше определено: Материал клавиатуры находится под операцией в WCAG.

В двух словах: Это хорошая практика для UX иметь пользовательские сочетания клавиш для важных функций. Но не имеет никакого отношения к 508 соблюдению. (За исключением того, что функциональность должна быть доступна клавиатурой - как-то -).

Ответ 3

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

Изменить. Считыватели читают некоторые скрытые элементы. Один из методов - абсолютно позиционировать элемент над экраном с отрицательной верхней позицией. Другим является использование свойства клипа. http://adaptivethemes.com/using-css-clip-as-an-accessible-method-of-hiding-content/ Но если вы используете display: none, высоты ноль и javascript, многие сканеры не будут говорить об этих элементах.

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

Вы не найдете окончательную документацию по навигации по клавиатуре. Причина, по которой никто не будет точно указывать, что делать, заключается в том, что существует так много потенциальных конфликтов - с браузером, ОС и т.д. Также нет стандартов, хотя Ария добивается прогресса: http://www.w3.org/TR/wai-aria-practices/#keyboard

Я бы не поместил accessKeys в меню, если это то, что вы имели в виду.
Вместо этого посмотрите: http://www.w3.org/TR/wai-aria-practices/#aria_ex_widget

Я бы сохранил фактические accessKeys для таких важных вещей, как "Поиск" и "Домой". Добавление кривой обучения на ваш сайт не поможет делу, если у вас есть accessKey для всего. Если вы положили, например, "О нас" accessKey = A, и у вас было 20 accessKeys, назначенных буквам, было бы плохо.

Я занимаюсь 508 сайтами в течение длительного времени, и лично я просто не использую выпадающие списки. Намного проще добавлять меню подстраниц. И я лично ненавижу кликать по выпадающим спискам. Выпадающие страницы требуют точности нажатия, что просто раздражает меня, и не помогает в доступности, потому что помните, что доступность также включает людей, которые не очень хорошо нажимают. Кроме того, выпадающие списки ограничены количеством уровней, которые вы можете иметь, а не технически, а с точки зрения UX.

Что я использую:

• Индексы вкладок.
• Тщательно расположенные меню, чтобы пользователь не получал огромный список ссылок, прежде чем услышать основную идею сайта или страницы.
• В некоторых проектах деревовые меню с соответствующей навигацией по страницам со стрелкой последовательно.
• Accesskeys H для дома и S для поиска, если необходимо.

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

Luck.:)