Mac VoiceOver ограничивает свою функциональность в Chrome / Firefox? - PullRequest
0 голосов
/ 11 января 2019

Я провожу тестирование доступности на сайте моей компании. Я проводил большую часть тестирования программы чтения с экрана с помощью инструмента VoiceOver для Mac в сочетании с Chrome. По большей части, это сработало, однако сегодня я добавил несколько ярлыков и ролей ARIA в пользовательский элемент (построенный в основном из div), и, похоже, он работает только в Safari ...

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

Если мой сценарий недостаточно ясен, пожалуйста, дайте мне знать, и я предоставлю больше информации / деталей. Спасибо!

1 Ответ

0 голосов
/ 11 января 2019

Ответ, скорее всего, будет противоположен тому, как вы сформулировали вопрос.

Ограничивает ли Mac VoiceOver свою функциональность в Chrome / Firefox?

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

Программы чтения с экрана не читают веб-страницы напрямую. Вместо этого программы чтения с экрана (и другие вспомогательные технологии) взаимодействуют с веб-браузерами (и другими собственными приложениями) через API специальных возможностей, предоставляемый операционной системой. Программа чтения с экрана может сообщать только то, что было сказано веб-браузером. Веб-браузеры должны передавать метаданные о доступности операционной системе, которая, в свою очередь, доступна для программы чтения с экрана. В частности, Firefox плохо работает с API доступа к macOS.

WCAG использует термин « доступность поддерживается » для описания этого. По сути, все эти утки должны быть в одном ряду:

  • Разработчик веб-страницы правильно использует HTML и ARIA. Обратите внимание, что у ARIA есть модель контента; Ожидается, что некоторые роли / свойства будут использоваться в сочетании с другими свойствами и ролями детей.
  • Веб-браузер правильно реализует семантику HTML и ARIA и предоставляет доступ к API-интерфейсам доступности в операционной системе хоста с правильными сопоставлениями.
  • API доступа, предоставляемые операционной системой хоста, также должны моделировать ту же информацию.
  • Вспомогательная технология (средства чтения с экрана и т. Д.) Использует это, чтобы информировать пользователя о том, что находится на экране, и передавать свои взаимодействия обратно по обратному маршруту. Программы чтения с экрана разрабатывают различные подходы к проектированию того, как лучше всего это представить: они предоставляют предпочтения пользователя для управления такими вещами, как многословие и пунктуация; и инструменты для проверки структуры документа или списка ссылок.

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

Дополнительная информация:

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...