Javascript и возможности доступности

Question

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

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

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

Надежда, что помогает

Answer 3

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

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

---

Answer 4

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

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

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

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

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

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

Answer 5

См

• http://juicystudio.com/article/making-ajax-work-with-screen-readers.php
• http://juicystudio.com/article/improving-ajax-applications-for-jaws-users.php
• http://www.paciellogroup.com/blog/?p=15
• http://www-03.ibm.com/able/resources/ajaxaccessibility.html

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

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