Доступность уровня представления

В случае консоли входа в учетную запись для WaMu обычный веб-пользователь взаимодействует с расширенной формой DHTML (верхнее изображение), в то время как программа чтения с экрана все еще получает понятную модель взаимодействия (нижнее изображение), все из той же разметки. Окончательный HTML для формы входа WaMu включает один Fieldset , а легенду , описывающую содержимое FIELDSET и этикетки метки в паре с соответствующими входами.

Выгоды

[img_assist | nid = 2807 | title = | desc = | link = none | align = right | width = 244 | height = 351] Помимо предоставления вспомогательных технологий с логическими структурами контента, написание семантического HTML также улучшает SEO (поисковая оптимизация ) предоставляя контент, отформатированный в соответствии с его функциональной ролью. Например, теги заголовков H1, H2, H3 должны описывать заголовки разделов контента, чтобы поисковые пауки могли легко идентифицировать и индексировать их релевантность.

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

Масштабирование текста

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

Большинство современных веб-браузеров оснащены функцией масштабирования текста как часть встроенного движка браузера. Самая большая проблема, стоящая перед дизайнерами и разработчиками пользовательского интерфейса, заключается в создании гибкого пользовательского интерфейса с компонентами, которые могут реагировать и корректироваться при увеличении или уменьшении размеров шрифта. Кроме того, производители браузеров до сих пор по-разному обрабатывали масштабирование текста, что усложняло управление им. Браузеры на основе Gecko (Firefox, Netscape и т. Д.) По умолчанию разрешают неограниченное масштабирование текста в любом направлении, в то время как Internet Explorer (версия 6) допускает только два уровня масштабирования в любом направлении (и только в том случае, если значения шрифта были установлены с использованием относительного измерения).Internet Explorer (версия 7) попытался облегчить проблемы с помощью алгоритма бикубической интерполяции, который не только увеличивает размер шрифта, но и все остальное на странице. Идея состоит в том, чтобы сохранить намеченный дизайн веб-страницы. Хотя IE7 не идеален (часто появляется горизонтальная полоса прокрутки), IE7 прошел долгий путь к удовлетворению потребностей пользователей в доступности.

Для редизайна WaMu клиент хотел увеличить масштабирование текста по умолчанию в браузере с помощью встроенного виджета масштабирования текста, который находится в правом верхнем углу пользовательского интерфейса. Этот подход кажется излишним, поскольку люди с требованиями к зрению знают, как использовать функцию масштабирования текста в браузере. Тем не менее, виджет отображается заметно на каждой странице и обеспечивает контролируемый подход, определяя, какие части страницы будут реагировать на масштабирование текста, сохраняя тем самым предполагаемый дизайн пользовательского интерфейса:

[Img_assist | NID = 2808 | название = | убывание = | ссылка = нет | Align = нет | ширина = 611 | высота = 422]

Выгоды

Очевидно, что основным преимуществом масштабирования текста является удобочитаемость. По словам Якоба Нильсона *, известного гуру юзабилити, пожилые люди — один из самых быстрорастущих сегментов пользователей Интернета. У них, как правило, есть деньги, чтобы потратить время на свои руки, и они могут испытывать трудности при передвижении. Этот архетипный веб-пользователь, как правило, нуждается в визуальной читаемости, связанной с возрастом. Удовлетворение этих потребностей может привлечь постоянных клиентов, которые ценят эти усилия.

* См. Http://www.useit.com/alertbox/high-roi.html.

Клавиатура навигации

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

В случае с WaMu мы назначаем определенный порядок TAB на страницах, которые могут иметь большое количество полей формы. Например, на странице «Оплатить счета и займы», где показана сводная информация обо всех получателях на банковском счете данного лица, пользователи могут вводить сумму платежа для каждого получателя. Мы присвоили атрибут TABINDEX динамически каждой строке получателя и еще более усилили идею, динамически применяя визуальную подсказку (серый фон) к каждой строке, когда пользователь перемещается вниз по странице:

[img_assist | nid = 2809 | title = | desc = | link = none | align = none | width = 573 | height = 243]
В таблице Pay Bills and Loans используется JavaScript для выделения фона строки, когда пользователь
нажимает на вход поле или использует клавишу TAB для навигации.

Другой пример управления клавишей TAB можно найти на консоли входа в учетную запись, где мы использовали JavaScript для активации раскрывающегося списка консоли (с фокусом, автоматически помещенным в первое поле), когда пользователь нажимает клавишу TAB в первый раз. Это позволяет пользователю войти в банковское приложение без необходимости использования мыши. Пользователь просто нажимает на вкладки, чтобы запустить раскрывающийся список, вводит свои учетные данные, просматривая каждое поле и, наконец, нажимает клавишу ВВОД, чтобы отправить форму. Используемая функция JavaScript проста:

function handleTab(evt) {
    var e = evt || window.event;

    if (e.keyCode == 9) {
        if (getElementsByClass('form','loginbox')[0]) {
            showLoginBox(getElementsByClass('form','loginbox')[0]);
        }
        if (getElementsByClass('input','usernamefield')[0]) {
            getElementsByClass('input','usernamefield')[0].focus();
        }
        else if (getElementsByClass('input','passwordfield')[0]) {
                 getElementsByClass('input','passwordfield')[0].focus();
        }
        return false;
    }
}

Прогрессивное улучшение, AJAX и валидация

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

Проблема с AJAX

Недавние исследования показывают, что не существует стандартной методологии для создания доступных приложений AJAX. По сути, проблема заключается в неспособности многих программ чтения с экрана распознавать событие onreadystatechange (способ обработки асинхронных запросов к серверу в AJAX). Несколько обходных путей были предложены; однако ни один из них не работает одинаково для различных программ чтения с экрана и веб-браузеров на рынке.

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

1. Используйте JavaScript для установки document.location = #response после получения responseText и обновления страницы. Эта опция работает только для некоторых программ чтения с экрана.
2. Используйте JavaScript, чтобы установить response.focus () для измененного содержимого. Установите tabindex рассматриваемого HTML-элемента на -1, что позволяет фокусироваться на элементах, которые обычно не могут получать фокус. IE и Firefox поддерживают эту технику (Safari не поддерживает).
3. Используйте JavaScript, чтобы поместить ответ в окно предупреждения : alert (request.responseText) . Этот метод работает для большинства программ чтения с экрана, но, очевидно, это довольно навязчивый подход. Один из обходных путей — предоставить браузерам программы чтения с экрана опцию флажка для получения ответов AJAX в окне предупреждений.

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

• AJAX и программы чтения с экрана: когда это может работать? Джеймс Эдвардс
• Заставить Ajax работать с программами чтения с экрана Gez Lemon и Steve Faulkner
• AJAX и средства чтения с экрана — вопросы доступа к контенту Стив Фолкнер

Проверка

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

Для правильных задач важно использовать правильные инструменты. Отличным (и бесплатным) онлайн-инструментом для проверки доступности является WatchXire WebXACT, который аналогичен валидатору W3C в том, что он сканирует исходный код веб-страницы, но дает результаты с критериями, которые в частности учитывают потребности в доступности и конфиденциальности.

Вывод

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

об авторе

Как архитектор уровня представления, графический алхимик и специалист по веб-стандартам в Avenue A | Razorfish, опыт Фредерика Велтерлина и основные направления его работы включают в себя проектирование, разработку архитектуры и программирование шаблонов на стороне клиента, предоставление интерактивных и технических рекомендаций, а также разработку стандартов и процессов для лучших в своем роде веб-разработок. Фредерик имеет одиннадцатилетний опыт работы в качестве дизайнера и разработчика пользовательского интерфейса, отвечающего за концептуальную и практическую разработку дизайна для широкого спектра потребностей бизнеса и отрасли.

Рекомендации

• Увеличение страницы в IE7
• Сравнение масштабирования браузера
• Инициатива веб-доступности
• AJAX и программы чтения с экрана: когда это может работать?
• Aking Aking Работа с программами для чтения с экрана
• AJAX и средства чтения с экрана — проблемы с доступом к контенту