Доступность и все эти рамки JavaScript

Ответ 1

Я использую js-framework (spine.js в моем случае) на моем последнем сайте. Тем не менее я убеждаюсь, что браузеры не-js (конечно, не слишком усердные: думаю, SEO) могут перемещаться по моему сайту и переваривать содержимое.

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

PREREQ: используйте шаблон-движок, который может отображать серверную и клиентскую стороны. (Я использую Усы). Это гарантирует, что вы можете отображать модели без js- через серверные шаблоны и рендерить модели с помощью js с помощью шаблонов на стороне клиента.

• Изначально: рендеринг продуктов с использованием уст-шаблона на стороне сервера. Также включите "bootstrapJSON" -объект, который содержит те же продукты в формате JSON.

• Изначально: все ссылки (страница с деталями продукта, пейджинг, сортировка, фильтрация) - это настоящие серверные URL-адреса (без URL-адресов хеш-бэнга)

• Конечный результат - это страница, которая может быть переведена на 100% с помощью поискового вызова, сортировки, фильтрации без использования JS.

• все поисковые вызовы, сортировка, фильтрация URL-адресов приводят к запросу на сервер, что, в свою очередь, приводит к созданию нового набора продуктов. Здесь ничего особенного.

• JS-enabled - on domload:

  • выберите bootstrapJSON и сделайте из него модели продуктов (для этого используйте функции js-framework).
  • После этого повторно запустите продукты, используя тот же шаблон-усы, но теперь делайте это на стороне клиента. (Опять же, используя js-framework).
  • Визуально ничего не должно измениться (после того, как обработка на стороне сервера и на стороне клиента была сделана на тех же моделях с одним и тем же шаблоном), но по крайней мере теперь есть привязка между клиентской моделью и представлением.
  • преобразуйте URL-адреса в hashbang-urls. (например:/products/# sort-price-asc) и использовать функции js-framework для проводки событий.

• теперь каждый (фильтр, пейджинг, сортировка) url должен привести к изменению состояния на стороне клиента, что, вероятно, приведет к тому, что ваша js-инфраструктура сделает ajax-запрос серверу для возврата новых продуктов (в JSON-формат). Повторное повторение этого действия на клиенте должно привести к обновленному представлению.

• Логическая часть кода для обработки ajax-запроса в 6. на стороне сервера на 100% идентична коду, используемому в 4. Различия между ajax-вызовом и обычным запросом и выплевыванием продукты в JSON или html (с использованием серверной части усы) соответственно.

РЕДАКТИРОВАТЬ: ОБНОВЛЕНИЕ JAN 2013 Поскольку этот вопрос/ответ получает некоторое разумное сцепление, я думал, что поделился бы некоторыми связанными аха-моментами прошлого года:

• Выплевывая JSON и предоставляя его клиентской стороне с вашим клиентским mvc выбора (шаги 6 и 7. выше), может быть довольно дорогостоящим cpu-wise. Это, конечно, особенно заметно на мобильных устройствах.

• Я провел некоторое тестирование, чтобы возвращать html-фрагменты в ajax (используя рендеринг усы на основе серверной стороны) вместо того, чтобы делать то же самое на стороне клиента, как это было предложено в моем ответе выше. В зависимости от вашего клиентского устройства он может быть в 10 раз быстрее (1000 мс → 100 мс), конечно, ваш пробег может отличаться. (практически никаких изменений кода не требуется, так как шаг 7 уже мог сделать оба)

• Конечно, когда JSON не возвращается, MVC-клиент не может создавать модели, управлять событиями и т.д. Итак, зачем вообще поддерживать клиентский MVC? Честно говоря, даже с очень сложными поисковыми записями в ретроспективе у меня мало пользы для клиентского mvc. Единственное реальное преимущество для меня в том, что они помогают четко разделить логику на клиенте, но вы уже должны это делать по своему собственному imho. Следовательно, удаление клиентской части MVC происходит в todo.

• О да, я торговал в Усах с Hogan (тот же синтаксис, немного больше функциональности, но больше всего чрезвычайно исполнитель!) Был в состоянии сделать это, потому что я переключил бэкэнд из java на Node.js(который скалы imho)

Ответ 2

Поскольку я являюсь пользователем с нарушениями зрения и веб-разработчиком, я буду звонить здесь.

Эти рамки, по моему опыту, не были проблемой, если были приняты соответствующие меры в отношении доступности.

Многие читатели на экране понимают JavaScript, и мы, как разработчики, можем улучшить опыт, используя такие вещи, как атрибут aria-live в HTML5, чтобы предупреждать читателей экрана о том, что все меняется, и мы можем использовать атрибут role, чтобы предоставить дополнительные подсказки для чтения с экрана.

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

Выполнение полного сайта Backbone.js или нокаута с нуля без учета доступности приведет к чему-то вроде "нового Twitter", который очень сильно не справляется со многими программами чтения с экрана. Но у Твиттера есть прочная основа, поэтому мы можем использовать другие средства для доступа к платформе. Grafting Backbone на существующий сайт, который имеет хорошо продуманный API, вполне выполним и очень интересен.

Таким образом, в основном эти структуры сами по себе не являются проблемой доступности, чем сам jquery - разработчику необходимо создавать пользовательский интерфейс, который работает для всех.

Ответ 3

Любая веб-страница, которая требует javascript для того, чтобы получить контент из него, скорее всего, будет связана с проблемами, связанными с доступностью. Доступность фреймворков JavaScript определенно является проблемой конкуренции, хотя на самом деле любое веб-приложение испытывает недостатки, когда контент предоставляется динамически, независимо от используемой структуры.

Нет никакой серебряной пули, чтобы гарантировать, что ваш сайт будет доступен, и, конечно же, я не могу учитывать каждую инфраструктуру JavaScript. Вот несколько соображений о том, как вы можете запретить вашему сайту быть полностью недоступным при использовании JavaScript:

• Следуйте рекомендациям WCAG 2.0 на клиентских сценариях и WCAG 2.0 в вообще.

• Избегайте фреймворков, требующих создания пользовательского интерфейса страницы, элементов управления и/или контента полностью через javascript, например Uki.js, или тех, которые используют свои собственные проприетарную разметку, например Jo. Чем ближе вы можете придерживаться статического (-ish), семантического содержимого HTML, тем лучше вы будете.

• Рассмотрите возможность использования роли ARIA, например role="application" и aria-live, чтобы указать области вашей страницы, которые являются динамическими. Все больше и больше ролей арии поддерживаются вспомогательными устройствами с течением времени, поэтому использование этих атрибутов арии имеет смысл, если вы можете добавить их в свое приложение соответствующим образом.

  В терминах JS-библиотек проверьте их источник и посмотрите, не выдают ли какие-либо роли арии. Они могут быть недоступны, но они продемонстрируют, что они рассматривают вспомогательные устройства.

• По возможности, рассматривайте JavaScript как усовершенствование, а не необходимость. Попробуйте предоставить альтернативные методы или рабочие процессы для доступа к важной информации, которая не требует динамических обновлений страниц.

• Протестируйте и подтвердите свое приложение с помощью своих пользователей! Проводите некоторые сеансы пользовательского тестирования с людьми, которые используют вспомогательные устройства или имеют другие трудности, используя веб-программное обеспечение. Ничто не поможет вам доказать, что ваш сайт доступен больше, чем смотреть, как реальные люди его используют.

Последний пункт является самым важным, хотя многие пытаются его избежать. Независимо от технологии, остается фактом, что вы разрабатываете приложение, которое люди будут использовать. Никакая машина или теория никогда не смогут полностью подтвердить ваше приложение как пригодное для использования, но вы все равно не создаете его для машин. Правильно?:)

Ответ 4

Крис Блуч (AOL) и Ханс Хиллен (TPG) провели хорошую презентацию по этому вопросу в отношении jQuery, включая работу, которую они проводят в обзоре доступности. Создание богатых интернет-приложений, доступных через JQuery Это и другая связанная с этим презентация о доступности HTML5 и богатых интернет-приложений (http://www.paciellogroup.com/training/CSUN2012/).

Мои деньги находятся на выборе наиболее доступной структуры: jQuery обеспечивает большую изящную деградацию или постепенный откат улучшений, а также общую привлекательную ориентацию на доступность. Кроме того, косвенно я помогаю тестировать и анализировать несколько систем, которые используют jQuery (общедоступные сайты и сайты Intranet Drupal), так что обнаружены дефекты, обнаруженные для доступности, и перенаправляются обратно в проект для исправлений.