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

Question

Я некоторое время изучал некоторые из JavaScript-фреймворков, таких как Backbone.js и Batman.js, и хотя они мне действительно нравятся, у меня есть одна вещь, к которой я постоянно возвращаюсь. Эта проблема - доступность.

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

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

Может быть, я просто слишком ревностен в этом вопросе и не ценю, как далеко зашли вещи с точки зрения доступности.

Answer 1

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

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

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

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

2. Первоначально: все ссылки (страница сведений о продукте, разбиение по страницам, сортировка, фильтрация) являются реальными URL-адресами на стороне сервера (без ссылок на хэш-банг) ​​

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

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

5. JS-включен - при загрузке:

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

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

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

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

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

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

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

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

Answer 2

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

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

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

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

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

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

Answer 3

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

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

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

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

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

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

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

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

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

Answer 4

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

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