Многие из нас учат, чтобы наши сайты могли использоваться с клавиатуры. Почему это и что на практике? Крис Эштон сделал эксперимент, чтобы узнать.

        

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

Кто использует клавиатуру для навигации?

В целом, есть три типа пользователей клавиатуры:

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

Сколько пользователей мы говорим?

Я тратил сеть на статистику использования клавиатуры, и я ничего не мог найти. Шутки в сторону. Не одно исследование.

Большинство сайтов для обеспечения доступа к клавиатуре просто считают само собой разумеющимся, что «многие пользователи» полагаются на клавиатуру, чтобы обойти. Любой, кто пытается получить приблизительное число, обычно увольняется с «статистикой неважно — ваш сайт должен быть доступен, период».

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

  

. Самое близкое к числу, которое я могу найти, это статья о PowerMapper, в которой говорится, что 7% взрослых трудоспособного возраста в США, Великобритании и Канаде имеют «серьезные трудности ловкости». Это сделало бы их «Вряд ли использовать мышь и вместо этого полагаться на клавиатуру».

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

«Людям, которые слепы, нужен полный доступ к клавиатуре. Период. "

— Дэвид Макдональд, соредактор использования WAI ARIA в HTML5

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

2,3% американских людей (всех возрастов) имеют визуальную инвалидность, не все из которых обязательно гарантируют использование устройства для чтения с экрана. В 2016 году Адди Османи подсчитал, что фактическое использование читателя экрана составляет от 1 до 2%. Если мы будем учитывать эти пользователи с нашими пользователями с ограниченными возможностями и пользователями, использующими клавиатуру, использование клавиатуры будет составлять значительный процент глобальной аудитории. Поэтому забота о доступности клавиатуры — это не просто правильная моральная вещь (и юридически — многие страны требуют, чтобы сайты были доступны по закону), но она также имеет хороший бизнес-смысл.

С учетом всего этого, каково сегодня состояние Интернета? Время узнать!

Эксперимент

Что делают все, когда у них впереди стоит запугивающая работа? Procrastinate! Я направился к youtube.com. У меня было определенное видео в памяти, и я был благодарен за то, что мне не нужно будет вставлять в основное окно поиска, поскольку оно по умолчанию сосредоточено на загрузке страницы.

Автофокус Атрибут

Я предположил, что это будет сфокусировано на JavaScript при загрузке окна, но на самом деле он обрабатывается браузером с атрибутом автофокуса на входном элементе.

Как явный пользователь клавиатуры, я нашел это чрезвычайно полезным. Будучи пользователем слепого экрана, я не уверен, хочу ли я этого или нет. По-видимому, консенсус заключается в том, что разумное использование автофокуса в порядке, в тех случаях, когда единственной целью страницы является взаимодействие с формой (например, целевая страница Google или контактная форма сайта).

По умолчанию Focus Styles

Я искал некоторые чья линия это все равно? добро, и не мог не заметить, что YouTube не определил никаких пользовательских стилей : focus вместо этого полагаясь на браузер нативный стиль, чтобы визуально указать, с какими элементами я переходил.

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

Я даже зашел довольно далеко назад:

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

. Это говорит о том, что вы можете с полным основанием предположить, что каждый браузер поставляется с базовым стилем : focus . Все в порядке, чтобы браузер выполнял работу. То, что вы рискуете, - несогласованность: все элементы стиля браузеров тонко по-разному, а некоторые настолько тонкие, что они не особенно визуально доступны.

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

Многие сайты подавляют стили фокуса по умолчанию, но не обеспечивают пользовательские стили, что приводит к недоступным событиям. Если ваш сайт использует сброс CSS Эрика Мейера, он может быть недоступен; этот обычно используемый файл сбрасывает стили по умолчанию : focus но инструктирует разработчика писать свои собственные, и многие не могут определить инструкции.

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

Почему смущает? Ну, посмотрите этот анимированный формат карусели на BBC. Есть две кнопки навигации - следующая и предыдущая - и пользователю клавиатуры полезно, чтобы фокус оставался на них в течение всего повествования. Но для пользователя мыши может быть довольно запутанным, что нажатая кнопка по-прежнему «фокусируется» после перемещения курсора.

: селектор CSS [вид сзади]

Если вы хотите лучшее из обоих миров, вам может понадобиться изучить псевдо-класс CSS4 : focus-visible который позволит вам обеспечить различный стиль фокусировки в зависимости от контекста. : focus-visible стилирует только те элементы, которые были сосредоточены на клавиатуре, а не на клике мыши. Это супер здорово, но в настоящее время поддерживается только в Firefox. Его можно включить в Chrome, включив флаг «Экспериментальные веб-платформы».

Видео на YouTube и доступ к клавиатуре

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

Что мне не понравилось, так это полезные ярлыки, такие как текст «Mute», который появляется при наведении курсора на значок отключения звука , не отображаются в фокусе.

Еще одна область, которая позволяет YouTube вниз, состоит в том, что она подавляет некоторый фокус. Здесь я пытался нажать кнопку «Показать больше».

Я случайно вставил вкладку прямо из кнопки «Показать больше», потому что я не видел никакого стиля : focus применяемого, будь то пользовательский или собственный. Я понял, что родной стиль был переопределен контурной шириной :

Доступность клавиатуры GitHub

Хорошо, время работы. Где лучше работать, чем в домашнем коде, github.com?

Я заметил три вещи о GitHub: один великий, один разумный и один плохой.

Во-первых, хорошо.

Ссылка «Пропустить к контенту»

GitHub предлагает ссылку Перейти к содержимому которая пропускает главное меню.

Если вы нажмете ENTER сосредоточившись на ссылке «Пропустить к контенту», вы пропустите все пункты меню в верхней части страницы и можете начать вкладку в пределах основная область содержимого, экономия времени при навигации. Это общий шаблон доступа, который очень полезен для пользователей клавиатуры и экрана. Около 30% пользователей программы чтения с экрана будут использовать ссылку пропуска, если вы ее предоставите.

В качестве альтернативы, некоторые сайты предпочитают размещать основное содержимое сначала в порядке чтения, над навигацией. Этот подход вышел из моды, поскольку он нарушает руководство по тому, как ваш контент DOM соответствует визуальному порядку (если ваша навигация не отображается внизу). И хотя этот подход означает, что нам вообще не нужна ссылка «Пропустить навигацию», нам, вероятно, понадобится ссылка «Skip на ].

Вкладка для просмотра

Одна особенность, я заметил, что по-разному работать с версией «без клавиатуры» был индикатор пробоя кода.

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

Это на самом деле не представляется необходимым — я бы с удовольствием включил цветную полосу и нажал ENTER но это другое поведение не вызывает никаких вред.

Невидимые ссылки

Одна из проблемных вещей, с которыми я столкнулся, была в том, что была ссылка «невидимая» после того, как она прошла мимо моего профиля в правом верхнем углу. Мой порядок вкладок будет отображаться на картинке, затем на эту невидимую ссылку, а затем на кнопку «Смотреть» на репо (см. Gif ниже). Я понятия не имел, что делает невидимая ссылка, поэтому, когда я узнал, что я был на ней, я нажал ENTER и был немедленно выведен из системы!

При ближайшем рассмотрении похоже, что я перешел к форме «только для чтения с экрана» ( sr-only — это общее имя класса считывателя экрана), которое имеет функцию «Выход».

Эта ссылка на выезд дополнительно к ссылке выключения в раскрывающемся меню вашего профиля:

Я не уверен, что необходимы две отдельные ссылки для выписки HTML, так как пользователь экранного чтения должен иметь возможность вызывать раскрывающийся список и перейти к основной ссылке на выход. И если мы хотели сохранить отдельную ссылку, я бы рекомендовал применить стиль : focus к содержимому экрана-считывателя, чтобы зрячие пользователи случайно не вызволили себя!]

Как сделать ярлык «Пропустить к контенту»

Итак, как мы воссоздаем ярлык «Пропустить к контенту»? Это довольно просто реализовать, но может быть обманчиво сложным, чтобы стать идеальным — вот что я считаю Святым Граалем решений для пропущенных ссылок.

«Пропустить ссылку» альтернативно называют «Пропустить навигацию», «Пропустить основную навигацию», «Пропустить навигационные ссылки» или «Перейти к основному контенту». «Перейти к основному контенту», вероятно, самый ясный, поскольку он говорит вам, куда вы переходите, а не то, что вы пропускаете.

Ссылка на ярлык должна идеально отображаться сразу после открытия тега. Он может появиться позже в DOM, даже после нижнего колонтитула, если у вас есть атрибут tabindex = "1" чтобы заставить его стать первым интерактивным элементом в порядке табуляции. Однако использование tabindex с номером больше нуля, как правило, является плохой практикой и часто приводит к предупреждению при использовании таких инструментов проверки, как Lighthouse.

Нельзя надежно полагаться на tabindex так как вы можете иметь более одной ссылки с tabindex = «1» . В этих случаях это первая ссылка, которая сначала получит фокус вкладки, а не какие-либо более поздние ссылки. Подробнее об использовании атрибута tabindex здесь, но помните, что вам всегда лучше физически перемещать вашу ссылку в начало DOM, чтобы быть в безопасности.

  
  Перейти к основному содержанию

 

Ссылка «Пропустить к основному контенту» ограничена для знакомых пользователей, которые уже могут пропустить навигацию, используя свои глаза. Таким образом, пока некоторые сайты постоянно сохраняют видимость перехода, соглашение в настоящее время заключается в том, чтобы сохранить связь скрытой до тех пор, пока вы не введете ее в нее, и в этот момент она находится в фокусе и получает стиль, применяемый : focus ] Псевдоселектор.

  .screen-reader-shortcut {
  позиция: абсолютная;
  top: -1000em;
}

.screen-reader-shortcut: focus {
  позиция: фиксированная;
  top: 0;
  left: 0;
  z-index: 999;
  / * ... и теперь любой приятный стиль, который вы хотите применить ... * /
  padding: 1em;
  background-color: rgb (114, 105, 105);
  белый цвет;
  text-decoration: none;
}
 

Итак, к чему мы на самом деле переходим? Что такое # основное содержание ? Это действительно может быть что угодно:

1. Inline content
   т.е. id вашего h1 тега:


   .

2. Контейнер
   например. идентификатор контейнера вокруг вашего основного содержимого, например
   .
3. Якорь сиблинга
   Вы можете ссылаться на именованный тег чуть выше основного содержимого, например. . Этот подход обычно описан в старых учебниках — я бы не рекомендовал его в наши дни.

Для максимальной совместимости со всеми программами чтения с экрана я бы рекомендовал ссылку на тег h1 . Это делается для того, чтобы содержимое считывалось, как только вы использовали ссылку пропуска. Связывание с контейнерами может привести к смешному поведению, например. считыватель экрана начал считывать все содержимое внутри контейнера.

В вашем # основном тексте также должен быть tabindex из -1 чтобы он программно был сфокусирован. В некоторых случаях некоторые устройства чтения с экрана могут не подчиняться пропуску.

  
 Это название страницы 
 

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

Почему мы изобретаем колесо?

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

С HTML5 у нас были семантические элементы, такие как