Текст книги "Шаблоны проектирования веб-приложений"

ACCESSIBLE TABLES (ДОСТУПНЫЕ ТАБЛИЦЫ)

Проблема

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

Решение

Отложите использование тегов <table> для представления табличных данных и используйте таблицы стилей для разметки страницы (см. шаблон TABULAR LIST в главе 7). Разместите табличные данные таким образом, чтобы заголовки таблицы, заголовки столбцов и заголовки строк было легко определить. Это поможет экранным дикторам понять и сообщить о связях между данными в таблице.

Это не говорит о том, что форматирование страницы тегами <table> уменьшает ее доступность. Можно проектировать доступные страницы и с использованием таблиц таким образом, чтобы контент был «линеаризован», т. е. были удалены все связанные с таблицей теги и контент был представлен в порядке его появления в разметке (Andrew and Shafer, 2006). В результате порядок расположения контента соответствует ожиданиям пользователей, и страница доступна для пользователей вспомогательных средств. Однако того же визуального и структурного результата можно достигнуть, используя таблицы стилей, поэтому больше нет оправданных причин для использования тегов <table> для наложения. Кроме того, использование таблиц для наложения нарушает принципы шаблона SEMANTIC MARKUP, который предлагает размечать контент при помощи тегов только в структурных целях, а не для того, чтобы достигнуть определенных визуальных эффектов.

Примечание

С новыми браузерами, поддерживающими таблицы CSS, которые используют свойства table, table-row и table-cell, скоро практически не останется причин для использования HTML тегов <table> для послойной разметки страниц (Andrew and Yank, 2008).

Зачем

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

Как

Самое главное – четко выделите заголовки, указывающие, что представляют собой данные в ячейках (фактические значения). Это достигается путем разметки заголовков (как столбцов, так и строк) тегами <th> и значений данных тегами <td>.

Используйте теги <CAPTION> и параметр SUMMARY, чтобы выделить контекст

Используйте теги <caption>, чтобы предоставить короткий описательный заголовок, указывающий цель таблицы (рис. 11.17). Информация внутри этих тегов отображается для пользователей и форматируется таблицами стилей.

Рис. 11.17. Используйте теги <caption> для краткого описания смысла табличных данных

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

Рис. 11.18. Использование параметра summary позволяет пользователям узнать, какие данные релевантны и наиболее важны в таблице, что улучшает общее понимание информации, предоставленной в таблице

Определите заголовки строк и столбцов таблиц данных

Убедитесь, что значения данных правильно связаны со своими заголовками при помощи параметра scope.

Поскольку так пользователи вспомогательных средств смогут узнать, с чем связаны данные: с заголовками столбцов <th scope="col">, заголовками строк <th scope="row"> или и тем и другим (рис. 11.19).

Рис. 11.19. Зная пределы заголовков, пользователи могут точно определить, что продажи в 2005 году составляли 1 200 000 долл.

Используйте параметр HEADERS на ячейках комплексных таблиц данных

Используйте атрибут headers, чтобы определить связи между заголовками для данной ячейки в комплексных таблицах.

Это выполняется путем присваивания параметра id какой-либо ячейке, которую вы хотите сделать заголовком, а затем добавлением идентификаторов полученных ячеек-заголовков в параметр headers (рис. 11.20).

Рис. 11.20. В данном примере идентификаторами заголовков столбцов являются meals, hotel и transportation, а заголовков строк – august-25, august-2 6, а также total. Ячейка во 2-й строке, 3-м столбце будет иметь заголовок hotel august-25, или august-25 hotel, или любой другой с таким же смыслом

Связанные шаблоны проектирования

Представление таблицы данных может быть улучшено с использованием таблиц стилей так, чтобы связи между значениями данных и заголовками были ясны и тем, у кого нет проблем со зрением (см. Christie, 2008, чтобы узнать, как использовать CSS для эффектного представления табличных данных). Это важно для зрячих пользователей, поскольку такие параметры, как summary, scope и headers не отображаются веб-браузерами. Однако необходимо использовать именно ненавязчивые таблицы стилей (UNOBTRUSIVE STYLE SHEETS), чтобы обеспечить независимое наложение слоев разметки и представления, как было указано в шаблоне PROGRESSIVE ENHANCEMENT.

ACCESSIBLE NAVIGATION (ДОСТУПНАЯ НАВИГАЦИЯ)

Проблема

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

Решение

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

Зачем

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

Как

Создайте ссылку вверху страницы, позволяющую пропускать навигационные ссылки. Ссылки «пропуска навигации» или «перехода к основному контенту» – это HTML-ссылки, созданные при помощи тегов <a>. Если дизайнер не хочет оставлять ссылку видимой, он может использовать каскадные таблицы стилей, чтобы скрыть ее (рис. 11.21).

Рис. 11.21. При использовании такого подхода ссылка скрыта для пользователей без нарушений зрения, но при этом считывается экранными дикторами и доступна для текстовых браузеров, таких как Lynx. Как показано, в привязке ссылки «перехода» содержание текста необязательно

Примечание

Для сайтов с основной и дополнительной навигацией выгодно предоставлять отдельные, «пропускающие навигацию» ссылки: одна для главной (основной и вспомогательной), а другая – для дополнительной навигации. Первая ссылка тогда должна называться «Пропустить основную навигацию» или «Пропустить главную навигацию», а вторая – «Пропустить внутреннюю навигацию», которая перенесет пользователей к основному контенту страницы.

Другой способ сделать ссылку видимой – когда на ней фокусируются (рис. 11.22). Это делает ссылку доступной тем, кто управляет страницей, используя клавиатуру.

(а)

(б)

Рис. 11.22. По умолчанию сайт Molly не показывает пользователям ссылку Skip to the Content (Перейти к содержанию страницы) (а). Однако когда пользователи передвигаются к ссылке, используя клавиатуру (или наводя указатель мыши), ссылка становится видимой (б)

Используйте заголовки в разметке, чтобы установить структуру страницы

Устанавливайте разделы на странице, используя заголовки разметки при помощи тегов от <h1> до <h6>. Это позволяет пользователям с экранными дикторами и браузерами передвигаться по странице с помощью клавиатуры (например, в браузере JAWS для Windows пользователи могут использовать клавишу H для передвижения по контенту страницы).

Связанные шаблоны проектирования

Так же важно, чтобы основное, побочное и/или вспомогательное меню навигации были соответствующим образом размечены семантической разметкой (SEMANTIC MARKUP). С помощью рабочих черновых версий ARIA расставьте атрибуты role в размечаемых элементах навигации (см. раздел «Доступность и многофункциональные вебприложения» далее в этой главе).

ACCESSIBLE ALTERNATIVE (ДОСТУПНЫЙ ВЫБОР)

Проблема

Иногда также невозможно сделать веб-приложение доступным из-за используемой технологии (например, RIA) или способа программирования.

Решение

Создайте доступную альтернативу для веб-приложения, которая предложит тот же контент и функциональность, и предоставьте ссылку на это альтернативное приложение. Так гласят рекомендации WCAG 1.0, в которых говорится:

Если даже после максимальных усилий вы не можете создать доступную страницу, предоставьте ссылку на альтернативную страницу, которая использует принципы W3C, имеет расширенный доступ, имеет эквивалентную информацию (или функциональность) и обновляется с той же частотой, что недоступная (исходная) страница.

А так же выдержка из рекомендаций WCAG 2.0 (см. Требования совместимости на сайте www.w3.org/TR/2007/WD-WCAG20-20070517/#conformance):

Если веб-страница не отвечает всем критериям успеха на заданном уровне, то механизм создания альтернативной версии, отвечающей необходимым критериям, может быть получен из несовместимого контента или его URI (Universal Resource Identifier, Универсальный идентификатор ресурса), тогда этот механизм будет отвечать всем критериям успеха для данного уровня совместимости.

Зачем

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

Богатые веб-приложения – это хороший пример. Они предлагают широкие возможности и выигрывают в производительности (например, Google Maps, Gmail). Однако когда используются вспомогательные средства, мобильные устройства или браузеры с отключенной поддержкой JavaScript и каскадных таблиц стилей, они становятся малодоступными. Кроме того, могут существовать юридические требования, согласно которым можно использовать только точную копию документа, а делать изменения в оригинальном документе – запрещено. В подобных случаях вместо того чтобы уменьшать количество посетителей, лучше создать альтернативную версию приложения с тем же контентом и функциональностью.

Как

Когда альтернативная версия разработана, необходимо, чтобы она удовлетворяла двум важным требованиям WCAG 2.0:

1. Доступная версия предоставляет то же самое содержание, даже учитывая компромиссы в дизайне и функциональности.

2. Ссылка на версию с расширенным доступом предоставляется в начале страницы недоступной версии.

Виды подходов, подобные этим, использующиеся для того, чтобы включить ссылку «пропуска навигации» в разметку страницы, могут быть использованы для предоставления ссылки на альтернативную версию (см. шаблон ACCESSIBLE NAVIGATION ранее в этой главе).

Связанные шаблоны проектирования

Если использование Ajax или JavaScript делает приложение недоступным, используйте подходы, указанные в шаблонах UNOBTRUSIVE JAVASCRIPT и PROGRESSIVE ENHANCEMENT, чтобы сделать приложение настолько доступным, насколько это возможно.

Доступность и многофункциональные веб-приложения

В подходах развивающихся многофункциональных веб-приложений (см. главу 8) широко используют динамический HTML (DHTML) и Ajax, чтобы предложить больше интерактивности и богатых впечатлений. Однако доступность таких веб-приложений существенно снизится. Например, если контент страницы изменяется без ее перезагрузки, новый контент может быть недоступен для людей, полагающихся на экранные лупы или экранные дикторы. Многофункциональные вебприложения так же используют элементы управления комплексного интерфейса, такие как ползунок, индикатор выполнения, вкладка, древо и т. п., которые изначально не поддерживаются в текущих версиях разметки HTML/XHTML.

Организация W3C-WAI работала над тем, чтобы направить эти требования в программу ARIA (WAI-ARIA; см. www.w3.org/WAI/intro/aria). Цель WAI-ARIA состоит в том, чтобы предложить способ связать поведение и структуру с интерактивными элементами управления, используемыми на многофункциональных веб-страницах, сохраняя разметку, чтобы сделать веб-приложение доступным для пользователей с ограниченными возможностями. Это происходит путем соединения ролей, состояний и свойств в уже существующей разметке.

Роли позволяют дизайнерам RIA накладывать надлежащую семантику на пользовательские элементы управления, чтобы увеличить их доступность. Например, как описано в шаблоне SEMANTIC MARKUP, навигация страницы должна быть размечена с использованием списков. Однако если на странице содержится несколько других типов списков, пользователям будет трудно различать списки навигации и другие списки. Спецификация ARIA состоит в помощи в определении ролей, предоставляющих информацию о том, какой элемент управления не зависит от разметки HTML и использующихся, чтобы создать его. Например, неупорядоченный список, используемый для передвижения, может быть размечен следующим образом:

<ul role="navigation">

<li>Строка навигации 1</li>

…

</ul>

Роли подразделяются на роли интерфейсных элементов и структурные роли. Роли элементов интерфейса включают стандартные элементы интерфейса в RIA, такие как progressbar, slider, combobox, tree, alert, dialog и др. Структурные роли подразумевают роли таких элементов, как menubar, toolbar, breadcrumbs, search, liveregion (в котором содержимое страницы подвергается изменению без перезагрузки страницы), tab, navigation и т. д. Особое значение для активных веб-приложений имеет роль liveregion, позволяющая читать текст в оперативной области без активизации соответствующих элементов интерфейса. Таким образом, пользователь будет информироваться о любых обновлениях в пределах области, отмеченной как liveregion, не теряя место в тексте, на котором он остановился.

В то время как роли предоставляют информацию об используемом элементе управления, модуль состояний и свойств ARIA добавляет в семантику информацию о связях и современных состояниях. Например, элемент бегунок может иметь такие свойства, как valuenow, valuemin и valuemax; поле liveregion может быть «занято»; элемент combobox может иметь свойство autocomplete; древо может быть «расширено» элементом treeitem, имеющим атрибут level и т. д.

В настоящее время такие вспомогательные программы, как Window Eyes 5.5+, Jaws 7.0+, и ZoomText, имеют поддержку согласованной с WAI-ARIA разметки браузера Firefox 2 и следующих версий; а программа Orca 2.20 – разметки Firefox 3. Поэтому дизайнеры могут начать добавлять соответствующие параметры WAI-ARIA в свою разметку, чтобы увеличить доступность многофункциональных веб-приложений. Так как дополнительные атрибуты будут проигнорированы браузерами, не поддерживающими WAI-ARIA, то риск их использования минимален. Поскольку поддержка браузеров и вспомогательных технологий все больше растет, доступность RIA все больше увеличивается.

Глава 12
Визуальное проектирование

Введение

Хотя веб-приложения спроектированы с целью облегчения выполнения задач, их визуальное проектирование не следует игнорировать. Визуальное проектирование не только играет важную роль в том, насколько удобным воспринимается приложение (Kurosu and Kashimura, 1995; Tractinsky, 1997), но также влияет на то, насколько надежным считают его пользователи (Fogg et al., 2002).

Одно из первых решений, принимаемых проектировщиками вебприложений, должен ли контент приложения быть отрегулирован по ширине окна браузера (LIQUID-WIDTH LAYOUT) или оставаться неизменным вне зависимости от его ширины (FIXED-WIDTH LAYOUT). Несмотря на то, что автомасштабируемые макеты в целом более удобны в использовании и доступны, эстетика страницы нередко снижается, если ширина окна браузера слишком велика или мала. Использование прогрессивного макета (PROGRESSIVE LAYOUT) с установленной минимальной и максимальной шириной – это разумный компромисс, потому что он не только может помочь сохранить эстетическую целостность, но и больше подходит пользователям, имеющим мониторы с высоким или низким разрешением.

Следующий важный шаг связан с размещением и выравниванием элементов страницы путем обеспечения четкой визуальной структуры страницы (GRID STRUCTURE, VISUAL HIERARCHY). Проектировщики также могут выделить определенные элементы страницы (HIGHLIGHT) или использовать изображения, указывающие на важные состояния и операции (ICONS) для оказания дополнительной помощи пользователям в навигации по страницам и доступе к объектам.

Визуальное проектирование предполагает тщательный баланс отдельных компонентов: макета, цветов, графики, шрифтов, контраста и т. д. О теории и практике применения этих компонентов для веб-дизайна написано несколько книг (например, Baird, 2007; Lidwell et al., 2003; McIntire, 2008; Wroblewski, 2002). В этой главе однако уделяется внимание визуальным шаблонам проектирования, которые значимы для веб-приложений. Лучшие методы эффективного включения других элементов для создания эффективного проекта (например, цвета, размер и пропорция, структура, гарнитура шрифта), хотя и не обсуждаются, важны и должны быть рассмотрены для всех проектов.

LIQUID-WIDTH LAYOUT (АВТОМАСШТАБИРУЕМЫЙ МАКЕТ)

Проблема

Контент веб-страницы (например, табличные данные со многими колонками, графические редакторы, приложения портала с макетами, состоящими из нескольких столбцов и т. д.) требует значительного горизонтального пространства. При отображении с использованием заданной ширины (FIXED-WIDTH LAYOUT) контент либо будет казаться пользователям с большими мониторами слишком нагроможденным, либо вынудит пользователей с маленькими мониторами прокручивать страницу по горизонтали, что, как правило, они делать не любят (Nielsen, 2005).

Решение

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

(а)

(б)

Рис. 12.1. Веб-приложение почты gowebtop использует автомасштабируемый макет и регулирует контент в соответствии с размером окна браузера

Зачем

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

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

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

Хотя Бернард и Ларсен (Bernard and Larsen, 2001) в своем исследовании не обнаружили существенных различий в работе пользователей с макетами с изменяемой или фиксированной шириной при чтении и выполнении поисковых задач, большинство пользователей предпочитают изменяемые макеты. Можно было бы утверждать, что заключение Бернарда и Ларсена устарело потому, что они использовали монитор с разрешением 1024x768, а почти 40 % пользователей Интернета сегодня пользуются мониторами с разрешением выше, чем 1024x768 и могут иметь другие предпочтения (см. w3schools, www.w3schools.com/browsers/browsers_display.asp). Однако использование мониторов с более высоким разрешением не обязательно означает, что большинство пользователей максимально увеличивают окно браузера в соответствии с максимальным разрешением экрана, а 60 % пользователей сети Интернет все еще используют разрешение экрана 1024x768 или ниже.

Как

При проектировании макетов с изменяемой или фиксированной шириной необходимо, чтобы компоненты страницы – по крайней мере, те, которые занимают основную область контента – имели определенную ширину по отношению к ширине окна браузера, что обычно осуществляется путем проектирования страниц с использованием процентных значений. Например, общий контент может быть установлен на 100 %, основное содержание может занимать 62 %, а содержание боковой панели – 38 % (Clarke, 2007).

Осуществите возможность установки фиксированной ширины области навигации

Для больших окон не обязательно расширять пропорционально все области макета. Элементы страницы, такие как навигация, боковые панели и выноски, можно сохранить определенной фиксированной ширины, сохранив при этом гибкими области, занимаемые основным контентом (рис. 12.2). Это сводит к минимуму прыжки и регулирование компонентов страницы при изменении пользователями размера окна браузера.

Рис. 12.2. Gmail оставляет панель навигации фиксированной при расширении других областей контента

Регулируйте элементы страницы под размер окна браузера

При использовании макетов с изменяемой шириной, элементы страницы, применяющие фоновые цвета или изображения, должны быть заполнены надлежащим образом при расширении или сужении ширины окна браузера. Относительное расположение элементов страницы – компонентов, выровненных по левому и правому краю, таких как заголовки, панели навигации, колонтитулы и т. д., – также должно сохраниться при изменении ширины окна (рис. 12.3).

(а)

(б)

Рис. 12.3. Когда пользователи сужают (а) или расширяют (б) окно браузера, Basecamp регулирует цвет фона областей тела, заголовка и контента по мере необходимости. Служебные средства навигации (в заголовке), логотип компании (в нижнем колонтитуле) и выпадающий список «…закреплен за» при изменении ширины окна браузера остаются выровненными по правому краю

Связанные шаблоны проектирования

Как уже отмечалось, высокие разрешения экрана становятся распространенными, и проектировщики начали обращаться к прогрессивным макетам (PROGRESSIVE LAYOUT), чтобы гарантировать, что читаемость контента страниц не пострадает, когда пользователи максимально увеличат размер окна браузера.