Javascript и доступность - PullRequest
       11

Javascript и доступность

21 голосов
/ 06 ноября 2008

Как веб-разработчик, ряд проектов, над которыми я работаю, подпадают под действие правительственных зонтиков и, следовательно, подчиняются 508 правилам доступности , а иногда правилам доступа к W3C . В какой степени можно использовать JavaScript, все еще удовлетворяя этим требованиям?

Кроме того, в какой степени JavaScript, в частности AJAX, использует пакеты, такие как jQuery, для выполнения таких задач, как отображение модальных диалогов, всплывающих окон и т. Д., Поддерживаемых современными программами обеспечения доступности, такими как JAWS, Orca и т. Д.? В прошлом правило звучало так: «Если оно не будет работать в Lynx, оно не будет работать для программы чтения с экрана». Это все еще правда, или в этих областях был достигнут больший прогресс?

РЕДАКТИРОВАТЬ: Похоже, консенсус заключается в том, что javascript в порядке, пока есть не-javascript откатов, однако он все еще не уверен в поддержке AJAX в программном обеспечении для чтения с экрана. Если у кого-то есть определенный опыт с этим, это было бы очень полезно.

Ответы [ 6 ]

14 голосов
/ 06 ноября 2008

Если доступность является вашей главной задачей, всегда запускайте веб-сайт, используя соответствующий стандартам (выберите определение типа документа и придерживайтесь его) HTML. Если это веб-приложение (отправка форм и т. Д.), Убедитесь, что формы будут работать, используя только HTTP GET и POST. Когда у вас есть полноценный веб-сайт / приложение, вы можете добавить кусочки CSS и JavaScript, пока сайт все еще функционирует, с одним или обоими выключенными.

Наиболее важной концепцией здесь является Прогрессивное улучшение . Вы добавляете дополнительные функции, используя CSS / JavaScript, но ваш веб-сайт / приложение будет отлично работать без .

Отличный инструмент для тестирования 508 , WAI , CSS отключен, JavaScript отключен, попробуйте использовать плагин Web Developer для Firefox.

2 голосов
/ 25 ноября 2008

См.

Вы также можете взглянуть на FlashAid, хотя это далеко не идеальное решение. (Но если вы использовали прогрессивное улучшение и использовали AJAX только при наличии Flash, а пользователь не использовал API специальных возможностей, у вас может быть разумное решение ... для Windows.)

В долгосрочной перспективе WAI-ARIA - это решение. Он в некоторой степени поддерживается в JAWS 10 (бета) и Firevox, но этого явно недостаточно для всех современных пользователей.

2 голосов
/ 06 ноября 2008

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

По мере взросления AJAX появляются способы сделать его доступным. Посмотрите на WAI-ARIA для современных методов обеспечения доступности AJAX и Google's AxsJAX для хорошего способа его реализации.


2 голосов
/ 06 ноября 2008

Я думаю, что ответ на самом деле в том, как вы строите вещи. JQuery обладает способностью быть ненавязчивым и, следовательно, доступным. Хитрость заключается в том, чтобы иметь избыточность вокруг ваших вызовов AJAX, чтобы браузеры без JavaScript все еще могли использовать ваш сервис. Другими словами, везде, где у вас есть JavaScript-ответы, диалоги и т. Д., Вы должны иметь ухудшенный эквивалент.

Если вы имеете в виду доступность и правильно тестируете оба варианта использования (JavaScript и не-JavaScript), вы сможете писать приложения, ориентированные на обе аудитории.

Пример ($ (документ). Готовый вызов опущен для ясности и краткости:

<script>
  $("#hello").click(function(){
    alert("Hi");
  });
</script>
<a href="/say_hello.htm" id="hello">Say Hello</a>

Тривиальный пример, но в основном он оценивает событие JavaScript клика, только если JavaScript поддерживается. В противном случае он будет работать как обычная ссылка и перейдет к say_hello.htm - ваша задача как разработчика заключается в том, чтобы убедиться, что оба результата обработаны соответствующим образом.

Надеюсь, это поможет!

0 голосов
/ 10 августа 2018

Я думаю, что принятый ответ, хотя и хорош для своего времени, сейчас устарел. (Буквально десятилетие на момент написания этого ответа. WCAG 2.1 был завершен несколько недель назад ...)

Документ W3I WAI-Authoring Design Patterns Practices содержит различные примеры распространенных виджетов, которым требуется javaScript для передачи правильной семантики, состояний и ролей вспомогательным технологиям.

AJAX можно сделать доступным, если вы осторожны, чтобы дать читателям экрана соответствующие семантические подсказки о том, каким будет обновление на странице, прежде чем пользователь активирует его. Вам также может потребоваться уведомить программу чтения с экрана о том, что фактически изменилось впоследствии, например, в регионе, живущем в арии, может быть объявлено «20 новых предметов загружено» или что-то в этом роде. Это достигается с помощью javaScript.

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

0 голосов
/ 08 ноября 2008

JQuery обладает способностью быть ненавязчивым и, следовательно, доступным. Хитрость заключается в том, чтобы иметь избыточность вокруг ваших вызовов AJAX, чтобы браузеры без JavaScript все еще могли использовать ваш сервис. Другими словами, везде, где у вас есть ответы, диалоги и т. Д., JavaScript должен иметь ухудшенный эквивалент.

Один из способов сделать это для повторного использования вашего кода - это заставить вашу "простую" страницу вызывать "функцию" (или что-либо, что вы используете для логики на стороне сервера), которая может вызываться сама по себе, возвращая JSON или XML. *

Например: /static/myform.asp (на стороне сервера «включает» ту же логику, что и /ajax/myform.asp) таким образом вы будете использовать asp в качестве шаблонов django.

Конечно, с полнофункциональной структурой звонков и свистков вы могли бы сделать это намного проще (подумайте о наличии html и xml 'шаблона' для того же представления в django), но применима та же идея.

Сделав это, перебрав все якоря в документе, готовом с использованием jQuery, и добавив события onclick, используя собственную ссылку якоря, перестановка / static / ajax / может упростить вашу жизнь.

Может ли кто-нибудь придумать, почему это слишком обременительно? Хотелось бы узнать, есть ли какой-нибудь серьезный недостаток в этой «дизайнерской идее».

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