Новый (и простой) способ скрыть доступный контент

Когда я хочу скрыть доступный контент, я всегда обращаюсь к Фрагмент Джонатана Снука.

.element-invisible {
  position: absolute !important;
  height: 1px; width: 1px;
  overflow: hidden;
  clip: rect(1px 1px 1px 1px); /* IE6, IE7 */
  clip: rect(1px, 1px, 1px, 1px);
}

Но вчера я случайно наткнулся на Скотта О’Хара. статья о сокрытии контента. Скотт говорит, что мы хотим скрыть контент только в трех разных контекстах:

  1. Скрыть это полностью
  2. Скрыть это визуально
  3. Скрыть это от программ чтения с экрана

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

Тогда у меня появилась идея

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

.hide-accessibly {
  opacity: 0;
}

Я поднял его на ступеньку выше, добавив position: absolute. Это убирает элемент из потока документов; и позволяет нам стилизовать другие элементы так, как будто скрытого содержимого там нет.

.hide-accessibly {
  position: absolute !important;
  opacity: 0;
}

Я подумал, что этого достаточно, и спросил об этом Джонатана.

Вот что он ответил:

Хотя он вытягивает его из потока, он может скрывать интерактивные элементы. Вы можете добавить к нему `pointer-events: none;`. Я не знаю, как программы чтения с экрана ведут себя с отключенными событиями указателя; я не проверял это

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

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

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

— Снук (@snookca) 24 апреля 2019 г.

Мне было любопытно, поэтому я проверил pointer-events: none и обнаружил, что он работает с кликами, генерируемыми клавиатурой, кликами, генерируемыми программой чтения с экрана, и кликами, генерируемыми JavaScript.

Вот Codepen, который я использовал для своего теста:

См. перо

Я сообщил о своих выводах Джонатану, и он сказал, что у нас может быть победитель!

Похоже, тогда у нас может быть победитель!

Фрагмент

Вот фрагмент, если вы хотите использовать этот метод.

.hide-accessibly {
  position: absolute !important;
  opacity: 0;
  pointer-events: none;
}

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Этот метод все еще невероятно нов. Я тестировал его только на последних версиях Firefox, Safari и Chrome. Мне пока не удалось запустить тест в Edge и других браузерах.

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

В остальном: пока не рекомендую использовать этот фрагмент в продакшене. (Нет, пока я не получу подтверждение от экспертов по доступности).

ОБНОВИТЬ : многие разработчики высказали свое мнение, опасения и эксперименты в Twitter. Я хотел поделиться с вами тем, что я закрепил и узнал.

Вначале обсуждались все три свойства.

Во-первых, поговорим о opacity.

Проблема с непрозрачностью?

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

у меня нет результатов тестирования на руках/время для тестирования прямо сейчас, но вкратце: да, по крайней мере, в некоторых комбинациях браузера/программы чтения с экрана непрозрачность ниже определенного значения приводит к тому, что контент не объявляется. предложите придерживаться проверенных и проверенных (хотя и немного длинных) стилей sr-only

Но Джонатан нашел некоторые исследования, которые предполагают, что opacity хорошо. Далее Патрик провел несколько тестов и согласился, что opacity хорошо.

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

Скотт О’Хара также затронул первоначальную проблему с opacity

Раньше ChromeVox полностью игнорировал opacity: 0; по сути обрабатывал его так же, как display: none. это было несколько лет назад с версией расширения для браузера. Потребуется настоящий хромбук, чтобы проверить, остается ли это проблемой в современной сборке.

Вердикт на данный момент:

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

Далее поговорим о pointer-events потому что это вторая самая хлопотная вещь.

Pointer-события

Скотт О’Хара отметил, что пользователи iOS Voiceover не смогут инициировать щелчок, если элемент pointer-events: none. Я проверил то, что сказал Скотт, и обнаружил, что это правда.

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

Это означает, что мы не можем использовать pointer-events универсально на всех элементах.

Мой следующий вопрос был: если мы не можем использовать pointer-eventsа если мы установим z-index к -999? Это предотвратит скрытие элементов, на которые можно щелкнуть, скрытым элементом.

.hide-accessibly {
  position: absolute !important;
  opacity: 0;
  z-index: -999;
}

Ну, Скотт сказал, что мы не должны использовать z-index: -999 на кнопках, потому что визуально скрытые кнопки не будут корректно работать на iOS Voiceover.

его не следует использовать на кнопках, так как визуально скрытые кнопки также не будут корректно работать с iOS VO. Как упомянула @letrastudio, это также может привести к неправильному чтению VoiceOver на рабочем столе, в зависимости от стиля интерактивного элемента, который он использует в реальном мире.

Я буду честен. я не понимаю почему z-index: -999 не будет правильно работать с iOS Voiceover, поэтому у меня нет правильного вывода. Я не проверял это.

MacOS Voiceover читает содержимое не в исходном порядке

Скотт и Жоао Белеза Фрейре (@letrastudio, упомянутые выше) указали на заслуживающую внимания ошибку, из-за которой macOS Voiceover считывала контент не в порядке исходного кода.

Даже для статического текста VoiceOver иногда может читать скрытый контент не по порядку (он пытается следовать визуальному порядку, а не исходному порядку). И, к сожалению, это решение не является непроницаемым для этой проблемы. Вот тест:

Я провел свой собственный тест, но ошибка, о которой сообщил Жоао, похоже, не возникает на моем компьютере, хотя мы использовали одно и то же устройство!

Ха, это странно. Я сделал еще несколько тестов, macOS 10.14.4: — Последние версии Safari и Chrome действуют одинаково: ошибка в примере 1, исправлено в 2 — Firefox правильно читает 1 и дает сбой в 2! — Safari Tech Preview читает оба правильно. Вот что я называю \*привередливым\*

Скотт О’Хара поделился дополнительной информацией о том, когда возникает эта ошибка:

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

Оказывается, куча экспертов (включая Скотта) уже обсуждали эту ошибку macOS Voiceover с 2017 года. Стоит прочитать всю статью. Тема выпуска о проблеме.

Из того, что я читал, кажется, что проблема возникает, когда position: absolute используется. Когда вы используете position: absolute и вы возитесь с позиционированием CSS, оно путается с положением кольца фокусировки Voiceover, которое меняет порядок чтения.

Изображение с подробным описанием экспериментов Джо Уоткина по изучению того, как CSS влияет на кольца фокусировки.

Это означает ЛЮБОЕ решение, в котором есть шанс, что macOS Voiceover испортит ЛЮБОЕ решение, содержащее position: absolute.

😱

И весь этот вопрос касается только озвучки. Мы не рассмотрели, как position: absolute может сделать его странным для других программ чтения с экрана.

и все это было связано только с VoiceOver. там ничего о том, как position: absolute может создавать неудобные объявления при использовании в интерактивных элементах с программами чтения с экрана ПК … мораль всего этого в том, что в настоящее время здесь нет серебряной пули.

Решение в HTML Boilerplate

Некоторые люди предложили использовать sr-only фрагмент из HTML5 Boilerplate. Они считали, что это лучший метод, потому что многие эксперты объединились, чтобы создать его.

.sr-only {
  border: 0;
  clip: rect(0, 0, 0, 0);
  height: 1px;
  margin: -1px;
  overflow: hidden;
  padding: 0;
  position: absolute;
  white-space: nowrap;
  width: 1px;
  /* 1 */
}

Однако это то же самое решение, которое вызвало Тема выпуска Я упоминал выше! Эксперты, такие как Скотт О’Хара, работают над этим с 2017 года, и на сегодняшний день не существует решения.

На данный момент лучшее решение было предложено Joe Watkin:

.visuallyhidden {
    border: 0;
    clip: rect(0 0 0 0);
    height: auto; /* new - was 1px */
    margin: 0; /* new - was -1px */
    overflow: hidden;
    padding: 0;
    position: absolute;
    width: 1px;
    white-space: nowrap; /* 1 */
}

На момент написания это решение не было официально интегрировано в HTML5 Boilerplate. Примите к сведению.

Опять же, стоит пройти через разговоры в теме темы если вы ботаник в этой области. Это бесценно. (Кстати, я узнал, что aria-label является игнорируется переводчиками Google и Microsoft! 😱).

Заключительные слова

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

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

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

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

К сожалению, это то, что мне сейчас не по карману. Если вы хотите подойти и поучаствовать в беседе, я уверен, что Джонатан, Скотт и многие другие будут рады поболтать!

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

Похожие записи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *