Я рекомендую разработчикам избегать попыток контролировать программы чтения с экрана в этой ситуации.Некоторые причины:
- Пользователи программ чтения с экрана (как правило) хорошо привыкли к подобным измышлениям и будут понимать распространенные слова, такие как «добавить».То, что может показаться огромной проблемой для разработчиков (и тестировщиков QA), может на самом деле быть незначительной проблемой для людей, которые используют программы чтения с экрана весь день.Более длинные или необычные слова могут быть большей проблемой для заглавных букв, но пороговых значений нет.
- Это зависит от разных программ чтения с экрана и может зависеть от того, какой голос (или механизм преобразования текста в речь) используется.,Слова, написанные с заглавной буквы, могут быть записаны в одной программе чтения с экрана и объявлены как слово другой.Большинству разработчиков не о чем беспокоиться.
- Некоторые программы чтения с экрана используют разные подходы с использованием заглавных букв, например, объявляя «cap» или изменяя высоту тона.
- Некоторые программы чтения с экрана предлагают для них пользовательские настройки.На мой взгляд, это главная причина, по которой разработчики избегают микроуправления программами чтения с экрана - мы можем непреднамеренно помешать настройкам пользователя.
- Все это может измениться какв будущем, по мере развития речевых движков и вспомогательных технологий.Попытка контролировать объявления сегодня может помешать вспомогательным техническим возможностям через несколько лет. Директива WCAG 4.1 гласит: «Максимальная совместимость с текущими и будущими пользовательскими агентами, включая вспомогательные технологии» (выделено мной).Я интерпретирую это как означающее, что не стоит пытаться микроуправлять мелкими причудами, подобными этим, в краткосрочной перспективе.
Некоторые ответы здесь предлагают использовать CSS text-transform: uppercase.Это хороший подход, но он также имеет несоответствия между различными программами чтения с экрана.В идеальном мире необработанный текст и преобразование текста могут быть переданы вспомогательным технологиям, чтобы предоставить лучшую информацию речевым движкам, а также с учетом предпочтений пользователя.Мы еще не там, но это обсуждается разработчиками браузера - смотрите это обсуждение в трекере ошибок Chromium для получения дополнительной информации: Соблюдение стилей преобразования текста в дереве a11y?
ДругоеПредлагаемый метод состоит в том, чтобы использовать строчную букву aria-label для дублирования видимого текста, но заставлять браузеры передавать строчную версию вспомогательной технологии.Например <button aria-label="add money">ADD MONEY</button>.Это может работать довольно хорошо во многих случаях, но это пример того, как разработчики могут помешать настройкам пользователя.Например, пользователи, которые хотят, чтобы их программа чтения с экрана сменила высоту речи для столиц, пропустят здесь.Основная задача программы чтения с экрана - передавать то, что на экране , включая заглавные буквы.Техника строчных букв aria-label противоречит этому, на мой взгляд.
Обсуждение всех заглавных букв (в проблеме Drupal CMS) содержит некоторые интересные комментарии пользователей программ чтения с экрана: Читаемостьпроблема с заглавными буквами в основных темах .