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

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

Вдоль этих строк, в какой степени JavaScript, в частности AJAX, и использование таких пакетов, как jQuery, для таких вещей, как отображение модальных диалогов, всплывающих окон и т.д., поддерживаемых современным программным обеспечением доступности, таким как JAWS, Orca и т.д.? Раньше в правиле было что-то вроде "Если это не будет работать в Lynx, это не сработает для чтения с экрана". Является ли это еще верным, или был ли прогресс в этих областях?

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

Ответ 1

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

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

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

Ответ 2

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

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

Пример ($ (document).ready call опущен для ясности и краткости:

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

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

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

Ответ 3

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

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

Ответ 4

См.

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

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

Ответ 5

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

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

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

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

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

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