Accessibility в WEB

Оглавление (нажмите, чтобы открыть):

Доступность сайта (accessibility): как повысить?

Наряду с понятием юзабилити (usability) все чаще можно встретить также термин «аксесабилити» (accessibility), что можно перевести как «доступность сайта». Что значит доступность сайта? Кому именно сайт должен быть «доступен»? Как повысить доступность сайта?

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

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

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

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

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

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

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

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

Не откладывайте, закажите удобный и доступный сайт от WebStudio2U прямо сейчас!

Приведение сайта в соответствие со стандартом WAI-WCAG

Мы уже писали про стандарт доступности содержимого WAI-WCAG, поддерживаемый W3C. В настоящей статье рассмотрим требования стандарта более подробно. В процессе описания требований, мы постараемся привести webew.ru в соответствии с ними, что сделает сайт более доступным для пользователей и позволит сайту участвовать в престижном конкурсе рунета «WebHiTech».

Цель стандарта WAI-WCAG (Web Content Accessibility Guidelines) — сделать содержимое веб-сайта более доступным для всех пользователей, независимо от типа ипользуемого браузера (традиционный браузер, голосовой браузер, мобильный телефон и др.), в том числе для пользователей с ограниченными физическими возможностями. Стандарт описан в виде гайдлайнов, содержащих перечень контрольных точек, разделенных на три группы по приоритету:

  • Приоритет 1. Сайт обязан следовать этим положениям, иначе некоторые пользователи не смогут получить доступ к содержимому сайта.
  • Приоритет 2. Сайт должен следовать этим положениям, иначе некоторые пользователи испытают существенные затруднения при доступе к содержимому сайта.
  • Приоритет 3. Желательно, чтобы сайт следовал этим положениям, иначе некоторые пользователи испытают некоторые затруднения при доступе к содержимому сайта.

Трем группам приоритета соответствуют три уровня соответствия стандарту:

  • Уровень A: выполнены все требования, имеющие приоритет 1.
  • Уровень «две A»: выполнены все требования, имеющие приоритет 1 или 2.
  • Уровень «три A»: выполнены все требования, имеющие приоритет 1, 2 или 3.

Гайдлайн 1. Предоставляйте альтернативы звуковому и визуальному содержимому.

  • 1.1 (приоритет 1) Предоставляйте текстовый эквивалент для всех нетекстовых элементов, в том числе для img, map, applet, object, frame, script, звуковых и видео-файлов.

Пожалуй, это наиболее важное требование. На webew в настоящее время нет звуков и видео, поэтому требуется убедиться, что у всех рисунков есть атрибут alt, описывающий содержимое рисунка. Если рисунок представляет собой диаграмму, которую невозможно описать в атрибуте alt, необходимо использовать атрибут longdesc, значение которого представляет собой ссылку на отдельную страницу, описывающую рисунок. Отметим, что атрибут alt является обязательным для тега img, поэтому на его отсутствие укажет html-валидатор. Тем не менее, валидатор удовлетворится и пустым значением атрибута alt, что может будь нарушением стандарта WCAG.

  • 1.2 (приоритет 1) Предоставляйте альтернативные ссылки на каждую активную область на серверной карте изображений.
  • 1.3 (приоритет 1) Пока браузеры не научатся произносить текстовый эквивалент визуального ряда, предоставляйте аудио-эквивалент визуального ряда или мультимедиа презентации.
  • 1.4 (приоритет 1) Синхронизуйте текстовый или аудио-эквивалент с видео по времени. В случае, если используемый формат видео не поддерживает субтитры, сделайте 2 варианта видео — с субтитрами и без.
  • 1.5 (приоритет 3) Пока браузеры не научатся отображать текстовые эквиваленты областей на клиентской карте изображений, предоставляйте дублирующие ссылки на каждую активную область.

Гайдлайн 2. Не полагайтесь только на цвет.

  • 2.1 (приоритет 1) Убедитесь, что вся информация переданная с помощью цвета, также доступна без цветов, например, в форме текста или разметки.
  • 2.2 (приоритет 2 для рисунков, приоритет 3 для текста) Убедитесь, что цвета переднего плана и фона достаточно контрастны при просмотре на черно-белом мониторе, а также людьми с ограниченным цветовым восприятием.

Гайдлайн 3. Правильно используйте разметку и страницы стилей.

  • 3.1 (приоритет 2) Если существует подходящее средство разметки, используйте его, а не изображение для передачи информации.
  • 3.2 (приоритет 2) Создавайте документы, удовлетворяющие формальным требованиям к формату (например, включайте в начало документа ссылку на DTD для простой проверки корректности формата документа).
  • 3.3 (приоритет 2) Используйте стилевые страницы.

Чтобы следовать правилам 3.2 и 3.3, следует регулярно проверять страницы сайта на соответствие стандартам HTML и CSS, например, с помощью валидаторов, предоставляемых w3c. На webew ссылки на валидаторы, размещены вниз каждой страницы для удобства регулярной проверки.

  • 3.4 (приоритет 2) Используйте относительные, а не абсолютные величины в CSS-атрибутах. Например, используйте em или значения в процентах вместо pt или cm. Если использованы абсолютные единицы, проводите детальное тестирование содержимого в различных пользовательских окружениях.

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

  • 3.5 (приоритет 2) Используйте заголовки для оформления структуры документа.
  • 3.6 (приоритет 2) Корректно оформляйте списки элементов (например, с помощью тегов ol, ul и dl).
  • 3.7 (приоритет 2) Корректно оформляйте цитаты. Не используйте элементы q и blockquote для оформления текста, не являющегося цитатой.

На webew.ru следует определить в CSS стили для q и blockquote, чтобы авторы содержимого могли использовать данные элементы.

Гайдлайн 4. Корректно декларируйте язык текста.

  • 4.1 (приоритет 1) Отмечайте изменение языка в тексте (например, в HTML используйте атрибут lang, в XML — xml:lang). Если документ содержит части текста на других языках, явное указание языка позволит звуковому браузеру переключиться на другой язык при чтении данных фрагментов.

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

  • 4.2 (приоритет 3) Приводите разврернутый эквивалент каждой абревиатуры при первом употреблении в тексте (в HTML используйте атрибут title для элементов abbr и acronym).
  • 4.3 (приоритет 3) Объявляйте основной язык документа.

Для соответствия требованию 4.3, на webew элементу html добавлен атрибут xml:lang=’ru-RU’

Гайдлайн 5. Создавайте доступные таблицы.

  • 5.1 (приоритет 1) Выделяйте заголовки строк и столбцов в таблицах с данными (в html — элементы th).
  • 5.2 (приоритет 1) Для таблиц, имеющих два или более уровня заголовков, используйте элементы разметки, чтобы ассоциировать заголовки с содержимым (thead, tfoot, tbody для связи строк, col, colgroup — для связи столбцов, атрибуты axis, scope и headers для описания более сложных взаимосвязей).
  • 5.3 (приоритет 2) Не испрользуйте таблицы, если таблица не имеет смысла в линеаризованном виде или предоставляйте альтернативное представление таким таблицам.
  • 5.4 (приоритет 2) Внутри таблиц не используйте структурные элементы разметки для целей визуального форматирования (например, не используйте th для выделения ячейки, не являющейся заголовком).
  • 5.5 (приоритет 3) Задавайте резюме таблицы с помощью атрибута summary.
  • 5.6 (приоритет 3) Задавайте сокращенные заголовки таблицы (атрибут abbr тега tr). Такие заголовки могут быть полезны, чтобы избежать повторов длинного заголовка при последовательном зачитывании всех ячеек таблицы.

Гайдлайн 6. Убедитесь в доступности страниц, использующих новые технологии.

  • 6.1 (приоритет 1) Убедитесь, что документ может быть прочитан при отключенных стилевых страницах.

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

  • 6.2 (приоритет 1) Убедитесь, что эквивалент динамического содержимого обновляется при обновлении динамического контента.

Данное требование подчеркивает, что WAI-WCAG не просто технический стандарт, за который отвечают разработчики сайта. Стандарт в равной степени адресован авторам содержимого, редакторам и контент-менеджерам, а положения стандарта должны быть закреплены в контент-стратегии сайта.

  • 6.3 (приоритет 1) Убедитесь, что страницы можно использовать при выключенных скриптах, апплетах или других программных элементах.
  • 6.4 (приоритет 2) Убедитесь, что обработчики событий в скриптах и апплетах не зависят от устройства ввода. Cтарайтесь использовать события уровня приложения, такие как onfocus, onblur, onselect. Обработчики событий, зависящие от устройства используйте парно: onmousedown вместе с onkeydown, onmounseup вместе с onkeyup, onclick вместе с onkeypress.
  • 6.5 (приоритет 2) Убедитесь, что динамическое содержание доступно в различных клиентских средах или предоставьте альтернативное представление страницы. Например, во многих случаях, серверные скрипты обеспечивают более высокую доступность, чем клиентские скрипты.

Гайдлайн 7. Дайте пользователю контроль над изменениями страницы, происходящими по таймеру.

  • 7.1 (приоритет 1) Избегайте быстрого мерцания экрана пока браузеры не научатся фильтровать мерцание (людям с фоточувствительной эпилепсией противопоказано смотреть на вспышки с частотой от 4 до 59 Гц).
  • 7.2 (приоритет 2) Избегайте мерцания содержимого (пока браузеры не научатся фильтровать мерцание).
  • 7.3 (приоритет 2) Не размещайте движущееся содержимое на страницах (пока браузеры не научатся останавливать движение). При необходимости использования движения, предоставляйте простой механизм отключения движения на странице.
  • 7.4 (приоритет 2) Не создавайте страниц с автоматическим периодическим обновлением страницы (пока браузеры не научатся блокировать auto-refresh).
  • 7.5 (приоритет 2) Пока браузеры не научатся блокировать клиентский редирект, не используйте его автоматически. Используйте серверный редирект.

Гайдлайн 8. Убедитесь в доступности пользовательского интерфейса.

  • 8.1 (приоритет 1) Сделайте программные элементы доступными для спецбраузеров (см. также гайдлайн 6). Приоритет 1, если элементы являются важными и не имеют альтернативы, приоритет 2 в противном случае.

Гайдлайн 9. Проектируйте интерфейс, не зависящий от клиентских устройств.

  • 9.1 (приоритет 1) Используйте клиентские карты изображений, а не серверные, за исключением случая невозможности геометрического задания областей.
  • 9.2 (приоритет 2) Каждый элемент, имеющий собственный интерфейс должен быть доступен с различных устройств (см. гайдлайн 8).
  • 9.3 (приоритет 2) В скриптах задавайте обработчики логических событий, а не событий, зависящих от устройства ввода (см. гайдлайн 6.4).
  • 9.4 (приоритет 3) Задавайте порядок табуляции для ссылок, объектов и управляющих элементов. См. статью про tabindex.
  • 9.5 (приоритет 3) Задавайте горячие клавиши для важных ссылок и управляющих элементов.

Гайдлайн 10. Используйте временные решения для совместимости со старыми браузерами.

  • 10.1 (приоритет 2) Избегайте использования всплывающих окон или открывания ссылки в новом окне, не предупредив пользователя (пока браузеры не научатся блокировать открывание новых окон).
  • 10.2 (приоритет 2) Пока браузеры не будут корректно отображать явные связи между текстовыми метками и полями ввода, помещайте текстовые метки прямо перед соответствующими им полями ввода в коде страницы.
  • 10.3 (приоритет 3) Давайте альтернативное представление для всех таблиц, которые теряют смысл, будучи прочитаны последовательно (ячейка за ячейкой).
  • 10.4 (приоритет 3) Пока браузеры не будут корректно обрабатывать пустые элементы ввода (INPUT, TEXTAREA), наполняйте элементы ввода заполнителям (некоторые старые браузеры не позволяют пользователю попасть в поле ввода, не содержащее текста).
  • 10.5 (приоритет 3) Пока браузеры (включая спецбраузеры) не будут корректно обрабатывать смежные ссылки, помещайте читаемые символы между соседними ссылками.

Учитывая, что стандарт разработан в 1999 году, большинство требований совместимости устарели. Вторая версия стандарта WAI-WCAG, находящаяся сейчас в черновом варианте будет включать актуальные на сегодня рекомендации совместимости.

Гайдлайн 11. Следуйте стандартам W3C.

  • 11.1 (приоритет 2) Используйте технологии W3C, если они применимы к поставленной задаче. Используйте последние поддерживаемые версии стандартов.
  • 11.2 (приоритет 2) Избегайте использования устаревших возможностей технологий W3C.
  • 11.3 (приоритет 3) Предоставляйте информацию для того, чтобы пользователь мог выбрать удобный ему формат содержимого (язык, тип содержимого и.т.д.). Например, методом переговоров о типе содержимого (content-negotiation), предусмотренным протоколом HTTP.
  • 11.4 (приоритет 1) Если не удалось создать доступную страницу, предоставьте ссылку на страницу с эквивалентным содержимым, написанную в соответствии со стандартами W3C.

Гайдлайн 12. Предоставляйте информацию о контексте.

  • 12.1 (приоритет 1) Давайте заголовок каждому фрейму.
  • 12.2 (приоритет 2) Описывайте назначение каждого фрейма, если заголовок не может вместить достаточного описания (используйте свойство longdesc).
  • 12.3 (приоритет 2) Разделяйте большие блоки информации на легко воспринимаемые куски. Используйте заголовки различного уровня, элементы optgroup, fieldset и др.
  • 12.4 (приоритет 2) Явно ассоциируйте текстовые метки с соответствующими им элементами управления (например, с помощью атрибута for элемента label).

Гайдлайн 13. Создавайте ясные механизмы навигации.

  • 13.1 (приоритет 2) Текст ссылки должен ясно описывать страницу назначения.
  • 13.2 (приоритет 2) Предоставляйте метаданные. Например, используйте RDF для указания автора, типа содержимого и др. Задавайте связи документов с помощью элемента link.
  • 13.3 (приоритет 2) Поддерживайте информацию об общей структуре сайта, например, в форме оглавления или карты сайта.
  • 13.4 (приоритет 2) Поддерживайте удобную навигацию на сайте.
  • 13.5 (приоритет 3) Создайте панель навигации со ссылками на доступные навигационные механизмы.
  • 13.6 (приоритет 3) Группируйте связанные ссылки и предоставляйте пользователь возможность скрыть группу ссылок.
  • 13.7 (приоритет 3) Если на сайте доступен поиск, предложите несколько типов поиска для пользователей с разным уровнем подготовки и с разными предпочтениями.
  • 13.8 (приоритет 3) Помещайте различающуюся информацию в начало заголовков, параграфов, списков.

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

  • 13.9 (приоритет 3) Предоставляйте информацию о коллекциях документов (например, с помощью элемента link или, поместив коллекцию в общий заархивированный файл).
  • 13.10 (приоритет 3) Предоставляйте возможность пропустить многострочные ASCII-рисунки.

Доступность

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

Из этой статьи вы узнаете: — что такое доступность и как она применяется к веб-разработке; — как сделать веб-сайты доступными и полезными для всех; — как обеспечить базовую доступность с минимальным влиянием на разработку; — какие возможности HTML вам доступны, и как использовать их для улучшения доступности; — продвинутые техники для обеспечения максимальной дотсупности.

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

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

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

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

Это, конечно, не совсем так, так что давайте проясним это, прежде чем займёмся чем-то еще. Что мы подразумеваем под доступностью, и чему мы здесь будем учиться?

Что такое доступность?

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

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

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

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

У этой формы несколько проблем с доступностью.

  • Текст должен быть более контрастным, его сложно читать пользователям с плохим зрением.
  • Расположение названий полей слева, а самих полей справа затрудняет ассоциацию их друг с другом, для многих людей, и делает практически невозможной для тех, кому требуется увеличение масштаба для использования страницы; представьте, что глядя на это на телефоне вам приходится панорамно передвигаться по странице, чтобы связать поля с названиеми.
  • Надпись «Запомнить данные?» не связана с переключателем, так что вы должны коснуться или кликнуть только на маленький квадратик, вместо того, чтобы просто кликнуть на надпись; кроме того, у пользователей, использующих устройства чтения с экрана, могут быть проблемы с ассоциацией надписи и переключателя.

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

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

Мастер Йода рекомендует:  Как избежать падения доходов в РСЯ после перехода на RTB

Рекомендации по доступности контента

В этом руководстве мы будем ссылаться на Рекомендации по доступности контента (РПДК) 2.0, набор инструкций и практик собранных экспертами по доступности, чтобы решить что значит «доступность» методическим путем.

РПДК организована вокруг четырёх принципов, часто обозначаемых акронимом ВУПН:

Воспринимаемый: Могут ли пользователи воспринимать контент? Необходимо помнить, что только потому, что что-то воспринимается только одним чувством, таким как зрение, не значит что все пользователи могут воспринимать это.

Управляемый: Могут ли пользователи использовать компоненты пользовательского интерфейса и перемещаться по содержимому? Например, что-то что требует взаимодействия при наведения не может управляться кем-то, кто не может использовать мышь или сенсорный экран.

Понятный: Могут ли пользователи понять содержимое? Могут ли пользователи понять интерфейс и достаточно ли он последователен, чтобы избежать путаницы?

Надежный: Может ли контент использоваться различными агентами пользователей (браузерами)? Он работает с ассистивной технологией?

Хотя РПДК обеспечивает всесторонний обзор того, что значит доступный контент, это так же может быть немного подавляюще. Чтобы помочь смягчить это, WebAIM (Web Accessibility in Mind) группа переработала руководства РПДК в простой перечень, специально предназначенный для веб-контента.

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

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

Понимание разнообразия пользователей

При изучении доступности может помочь понимание разнообразия пользователей в мире и видов специальных возможностей, которые их затрагивают. Для объяснения дальнейшего, ниже представлено интервью с Victor Tsaran — полностью слепым Technical Program Manager в Google.

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

Какие нарушения бывают у пользователей?

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

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

Давайте пройдемся по ним по очереди. Можете привести пару примеров зрительных нарушений?

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

Устройство чтения Брайля

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

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

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

Режим высокой контрастности

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

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

О, и нельзя не упомянуть людей с нарушениями восприятия цвета – около 9% мужчин имеют некую форму нарушения цветового восприятия! Плюс около 1% женщин. Они могут испытывать проблемы с различением красного от зеленого или желтого от синего. Подумайте об этом в следующий раз, при проектировании валидации формы.

Да, нарушения моторики или нарушения ловкости. Эта группа варьируется от тех, кто предпочел бы не использовать мышь, так как у них, возможно, какой-то вид RSI или что-то вроде и такое использование болезненно, до кого-то, кто может быть физически парализован и ограничен в движении определённых частей тела.

Устройство отслеживания глаз

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

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

Отлично, давайте поговорим о нарушениях слуха.

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

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

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

Хорошо, можете рассказать немного о когнитивных нарушениях?

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

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

Итак, как бы вы резюмировали, как вы думаете о доступности?

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

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

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

Ситуативные Временные Постоянные
Зрительные сотрясение мозга слепота
Двигательные ребенок на руках сломанная рука, RSI* RSI*
Слуховые шумный офис
Когнитивные сотрясение мозга

Repetitive Strain Injury: напрмер, кистевой туннельный синдром, теннисный локоть, курковый палец

Следующие шаги

Мы изучили уже довольно много! Вы прочитали

  • о том, что такое доступность и почему она важна для всех
  • о РПДК и WebAIM перечне доступности
  • о различных типах нарушений, которые вы должны учитывать

В оставшейся части руководства мы окунемся в практические аспекты создания доступных веб-сайтов. Мы организуем эту работу вокруг трех основных предметных областей:

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

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

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

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

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Web Accessibility

Developing with Empathy

Start Free Course

Nanodegree Program

Front End Web Developer

Accelerate your career with the credential that fast-tracks you to job success.

About this Course

In this course you’ll get hands-on experience making web applications accessible. You’ll understand when and why users need accessibility. Then you’ll dive into the «how»: making a page work properly with screen readers, and managing input focus (e.g. the highlight you see when tabbing through a form.) You’ll understand what «semantics» and «semantic markup» mean for web pages and add ARIA markup to enable navigating the interface with a range of assistive devices. Finally, you’ll learn styling techniques that help users with partial vision navigate your pages easily and reliably.

This course is also featured in our Full-Stack Web Developer Nanodegree program.

Полезные правила доступности, которые останутся в памяти

Впервые я столкнулся с доступностью ещё в 2015, когда работал на американского розничного гиганта. Тогда компания получила огромный иск из-за сайта, который нарушал Закон об американцах-инвалидах (Americans with Disabilities Act, ADA). После этого мы с командой много работали над приведением сайта в соответствие с нормами ADA. Тогда я и познакомился со многими принципами доступности.

Однако в последующие годы, я постоянно нарушал эти принципы, хотя регулярно с ними сталкивался. Почему-то я не помнил о них во время кодинга. Не хотелось признавать, но я определённо не полностью их усвоил.

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

Эта статья состоит из двух частей: что такое доступность и три полезных правила доступности. В первой части я напомню, что такое доступность, и поделюсь своим опытом. Если хотите перейти к главному, то можете сразу начать со второй части.

Что такое доступность?

Как я уже упоминал, в 2015 году моя компания получила иск за несоблюдение ADA.

ADA — закон о гражданских правах, который:

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

Таким образом, ADA требует, чтобы фирмы, государственные и местные органы власти, а также некоммерческие организации предоставляли инвалидам доступ к сервисам наравне с трудоспособными гражданами. Аналогичным образом федеральные органы власти должны соблюдать федеральный закон, который называется Section 508.

В контексте интернета все публичные сайты США, которые не соблюдают ADA или Section 508, исключают из числа своих посетителей большие группы пользователей с разной степенью нарушений.

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

От переводчика

В России доступность регулируется тремя документами:

  1. Государственный стандарт «ГОСТ Р 52872–2012 Интернет-ресурсы. Требования доступности для инвалидов по зрению». Был введён в 2014. Содержит рекомендации, а не жёсткие требования, как и любой другой ГОСТ.
  2. Приказ министерства связи и массовых коммуникаций России №483 «Об установлении порядка обеспечения условий доступности для инвалидов по зрению официальных сайтов федеральных органов государственной власти, органов государственной власти субъектов Российской Федерации и органов местного самоуправления в сети интернет». Принят в ноябре 2015.
  3. Федеральный закон № 419-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации по вопросам социальной защиты инвалидов в связи с ратификацией конвенции о правах инвалидов». Вступил в силу в январе 2020.

Кому нужна доступность?

Согласно Всемирному докладу об инвалидности (есть версия на русском — прим. редактора), опубликованному в 2011 году Всемирной организацией здравоохранения (ВОЗ), примерно 15% мирового населения живёт с той или иной формой инвалидности. Из них примерно 2–4 % испытывают серьёзные трудности с нормальным функционированием.

В превосходной статье замечательного Эдди Османи «Доступные UI-компоненты для веба», речь идёт о четырёх основных видах нарушений, которые рассматриваются в контексте доступности:

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

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

Если хотите больше об этом узнать, то рекомендую пройти на Udacity бесплатный курс Web Accessibility от Google. Это видео из курса, которое рассказывает об этих видах нарушений:

Хорошо, как обеспечить поддержку доступности?

К тому моменту, как мы получили иск в 2015, уже был проведён аудит, который выявил множество проблем с доступностью. Наша команда прошла однодневный курс по доступности, на котором мы узнали о Web Content Accessibility Guidelines (сокращённо WCAG, сейчас в версии 2.1). Это руководство считается стандартом по доступности.

WCAG разработан группой Web Accessibility Initiative (WAI), которая входит в W3C. Она же разработала Accessible Rich Internet Applications (WAI-ARIA или просто ARIA, актуальная версия 1.1). Это спецификация о том, как сделать страницы доступными путём добавления ролей и атрибутов ARIA в HTML-разметку.

Эти спецификации включают три уровня соответствия и приоритетов:

  • A (можно поддерживать, низший).
  • AA (следует поддерживать, средний).
  • AAA (нужно поддерживать, наивысший).

Многие законы о доступности во всём мире основаны на критериях выполнения WCAG. Например, в январе 2020 года Section 508 был принят в соответствии с критерием AA WCAG 2.0.

Прим. переводчика: Не исключение и «ГОСТ Р 52872–2012 Интернет-ресурсы. Требования доступности для инвалидов по зрению». Он разработан на основе WCAG.

Отлично обобщает все рекомендации чек-лист WebAIM WCGA. В нём для каждого критерия указан уровень соответствия.

Насколько сложно выучить WCAG и WAI-ARIA?

Я хотел бы поделиться своим опытом в изучении доступности.

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

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

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

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

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

Вывод: мы просто позволили этому случиться. Доступность проигнорировали и её ключевые идеи не укоренились в нас.

Другими словами, мы оказались изолированы в пузыре наших представлений. Такое случается, когда мы решаем проблемы, руководствуясь своими предубеждениями, как отмечено в методологии Microsoft Inclusive Design.

Оказываясь в изоляции

Иногда вам нужно что-то испытать на собственном опыте, чтобы лучше это понять. Это и случилось со мной.

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

Обычно сдача донорской крови занимает 10 минут, но забор тромбоцитов длится примерно 90. Так как моя рука была накрыта одеялами (потому что при заборе крови становится холодно), персоналу потребовалось около 20 минут, чтобы заметить, что моя вена повреждена.

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

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

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

И тогда, именно в этот момент, я вспомнил как раньше работал над доступностью и не думал о поддержке клавиатуры. Блин!

Уровни изоляции

В соответствии с Microsoft’s Inclusive 101 Toolkit существует три уровня изоляции:

  1. Постоянная: в ней оказываются люди с такими нарушениями как потеря конечностей, зрения, слуха или речи.
  2. Временная: переживают те, у кого временная травма или трудности, с которыми они сталкиваются непродолжительное время. Например, они посмотрели на яркий свет, носят гипс или заказывают обед в другой стране.
  3. Ситуативная: испытывают те, у кого резко изменились доступные возможности из-за специфичной обстановки, например, плохо слышно из-за шумной толпы, снижен обзор в машине или это молодые родители, у которых свободна только одна рука.

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

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

Пишем код во имя перемен

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

  • Научиться писать код, поддерживающий доступность.
  • Сделать доступность частью регламента разработки своей команды (так же, как вы планируете работать над юнит-тестами или документацией).
  • Обсуждать доступность со своей командой, повышать осведомлённость её участников.
  • Оценивать, пишет ли команда код, отвечающий требованиям доступности, и фиксировать проблемы, которые можно решить.
  • Узнавать у бизнеса о требованиях, которые не отвечают принципам доступности или для которых нужны альтернативные решения.
  • Делиться своим опытом и показывать другим как внедрить доступность в свою практику. Поэтому я и пишу эту статью 🙂

Три полезных правила доступности

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

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

Повторюсь, чтобы научиться доступности, рекомендую ознакомиться на Udacity с бесплатным курсом Web Accessibility от Google:

Developing Accessible Websites

In order to assure that websites and web applications are accessible to and usable by everyone, designers and developers must follow web accessibility guidelines. Each of the following topics address issues that are especially common on UW websites. See also our annotated list of web accessibility Tools and Resources.

Features of Accessible Websites

Additional information is available on the AccessComputing website 30 Web Accessibility Tips.

Checking a Website for Accessibility

You can go a long way toward assuring your website is accessible by following these simple steps:

  1. Validate your HTML. If HTML is used incorrectly, assistive technology can have problems interpreting the page content, which can result in access problems for users. Use an HTML validator to check your code.
  2. Test with a keyboard. Set your mouse aside and use the tab key to navigate through your web pages. You should be able to access all interactive features (e.g., menus, links, form fields, buttons, controls) and operate them by pressing Enter, space, arrow keys or other intuitive keystrokes. If you are unable to access some of your site’s features, your site is likely to have accessibility problems.
  3. Use an accessibility checker. There are several free online tools that will check your web pages for accessibility. See our Tools and Resources page for an annotated list. Also, the UW has an enterprise license for Siteimprove, a powerful tool that scans your site at regular intervals for broken links, spelling errors, and accessibility problems. See the Siteimprove page on this website for more information.
  4. Test with users. You can test your site by simply recruiting and observing users as they interact with your site. To test for accessibility, recruit users who have a variety of skill levels and characteristics, such as those listed below under the heading What Is Accessibility?
  5. Ask for help. The UW community is actively working toward the goal of full accessibility for all visitors to its websites. Since we’re all working together toward this goal, there are many in the community who are happy to help. See Getting Help with Accessibility for more information.
Мастер Йода рекомендует:  Курс «Многопоточный C++»

Developing Accessible Sites Using WordPress

UW Marketing has created a UW WordPress Theme with input from UW-IT Accessible Technology Services. The theme includes a variety of accessible features, and accessibility is an ongoing consideration as features are added or updated. Therefore, web owners are encouraged to use this theme. Free WordPress hosting is also available for UW organizations.

WordPress is an easy-to-use, highly flexible content management system for creating and managing websites. Its functionality can be extended with any of several hundred widgets and plugins that are freely available. However, widgets and plug-ins can also introduce accessibility problems to a site, so you should select these very carefully. See How to Select Accessible WordPress Widgets and Plug-Ins for additional help.

What is Web Accessibility?

People who use the web have a growing variety of characteristics. As web developers, we can not assume that all our users are accessing our content using the same web browser or operating system as we are, nor can we assume they’re using a traditional monitor for output, or keyboard and mouse for input. Consider these user characteristics:

  • Unable to see. Individuals who are blind use either audible output (products called screen readers that read web content using synthesized speech) or tactile output (a refreshable Braille device).
  • Has dyslexia. Individuals with learning disabilities such as dyslexia may also use audible output, along with software that highlights words or phrases as they’re read aloud using synthesized speech.
  • Has low vision. Individuals with low vision may use screen magnification software that allows them to zoom into all or a portion of the visual screen. Many others with less-than-perfect eyesight may enlarge the font on websites using standard browser functions, such as Ctrl + in Windows browsers or Command + in Mac browsers.
  • Has a physical disability. Individuals with physical disabilities that effect their use of hands may be unable to use a mouse, and instead may rely exclusively on keyboard or use assistive technologies such as speech recognition, head pointers, mouth sticks, or eye-gaze tracking systems.
  • Unable to hear. Individuals who are deaf or hard of hearing are unable to access audio content, so video needs to be captioned and audio needs be transcribed.
  • Using a mobile device. Individuals who are accessing the web using a compact mobile device such as a phone face accessibility barriers, just like individuals with disabilities do. They’re using a small screen and may need to zoom in or increase the font size, and they are likely to be using a touch interface rather than a mouse. Also, Apple’s iPhone and iPad do not support Adobe Flash.
  • Limited bandwidth. Individuals may be on slow Internet connections if they’re located in a rural area or lack the financial resources to access high-speed Internet. These users benefit from pages that load quickly (use graphics sparingly) and transcripts for video.
  • Limited time. Very busy individuals may have too little time to watch an entire video or audio recording, but can quickly access its content if a transcript is available.

An accessible website works for all of these users, and countless others not mentioned.

The W3C summarizes web accessibility nicely in their Web Content Accessibility Guidelines 2.0. WCAG 2.0 is organized into the following four key concepts:

  • Web content must be perceivable
  • Web content must be operable
  • Web content must be understandable
  • Web content must be robust

There are many possible approaches to attaining accessibility as defined by these four concepts. The pages of this website were designed to help.

The following video, produced by UW-IT Accessible Technology Services, features university web designers and developers, including several from the UW, discussing the importance of creating websites that are accessible to all users.

Современное решение для слабовидящих — шаблон Аccessibility для сайта на базе Joomla

Дата публикации: 2020-01-24

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

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

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

Какой должна быть версия сайта для слабовидящих?

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

Как создать сайт самому?

Какие технологии и знания необходимы сегодня, чтобы создавать сайты самостоятельно? Узнайте на интенсиве!

Согласно нормам российского ГОСТа, отличительными чертами визуальной составляющей версии сайта для слабовидящих должны быть:

монохромная черно-белая расцветка;

отсутствие ярко выраженных графических элементов и графики как таковой.

То есть, грубо говоря, версия web accessibility для сайта должна представлять собой набор веб-страниц, на которых содержится лишь текст, написанный понятным крупным шрифтом, а также удобная и понятная навигация.

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

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

Создание версии для слабовидящих на Joomla своими руками

Если вы являетесь рукастым специалистом в работе на CMS Joomla и постоянно проходите интернет-курсы по совершенствованию навыков в веб-разработке, то можете попробовать создать переключатель версий сайта самостоятельно. По сути, аналоговый вариант представляет собой не что иное, как дополнительную таблицу стилей CSS. Грубо говоря, все, что вам нужно — это отредактировать текущую версию таблицы стилей под нормы ГОСТа и залить в ядро сайта JavaScript, с помощью которого получилось бы переключать шаблоны между готовыми CSS-файлами.

То есть порядок действий должен быть примерно следующим:

Как создать сайт самому?

Какие технологии и знания необходимы сегодня, чтобы создавать сайты самостоятельно? Узнайте на интенсиве!

Вносите в нынешний CSS id, который позволит движку его определять.

Копируете таблицу стилей и корректируете ее согласно требованиям ГОСТ (убираете изображение, увеличиваете шрифт, изменяете фон).

Вносите в файл пометку, что данная версия действует для слабовидящих.

Пишете код скрипта с помощью функции look() с указанием пути к другому файлу CSS.

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

Если после проделанных операций ваш шаблон accessibility не работает, то лучше верните базовую версию сайта и загрузите на нее готовый шаблон со встроенным accessibility settings согласно приведенной ниже инструкции.

Пошаговая инструкция по установке готового шаблона

А теперь давайте перейдем непосредственно к тому, как установить шаблон accessibility для Joomla. Чтобы вам было проще ориентироваться в дальнейших ступенях информации, для начала можно пройти полезные курсы по веб-дизайну, которые смогли бы заметно усовершенствовать ваши навыки. Ну, а если же не терпится перейти к практике, тогда идем дальше.

Шаг 1. Скачиваете шаблон и плагин

Шаблон представляет собой ту самую картину сайта, которая будет находиться перед людьми со зрительными отклонениями, а благодаря плагину Template Switcher пользователи смогут переключаться с одной версии на другую.

Шаг 2. Разархивируете и устанавливаете файлы

По отдельности установите каждый файл. Установка плагина производится в админке Joomla, в разделе «Менеджер расширений». Не забудьте его активировать.

Шаг 3. Устанавливаете шаблон

Делается это также в админке, в разделе «Менеджер шаблонов». После того как установка будет завершена, вы увидите список загруженных шаблонов, среди которых нужно выбрать Accessibility.

Шаг 4. Донастраиваете шаблон

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

Шаг 5. Настраиваете плагин

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

Шаг 6. Создаете специальный модуль

Это необходимо, чтобы кнопка-переключатель отображалась на сайте. Создать модуль можно в разделе «Расширения» — «Менеджер модулей» в админ-панели. Модуль должен состоять из html-кода, который будет представлять собой путь к альтернативной версии сайта. Не забудьте активировать модуль.

Шаг 7. Создаете еще одну кнопку

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

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

Как создать сайт самому?

Какие технологии и знания необходимы сегодня, чтобы создавать сайты самостоятельно? Узнайте на интенсиве!

Хотите узнать, что необходимо для создания сайта?

Посмотрите видео и узнайте пошаговый план по созданию сайта с нуля!

Accessibility

This accessibility guide is for staff who manage information on the University website. The T4 content management system is designed for people to use without html knowledge. Some accessibility information may require familiarity with technical aspects of web design, but we also include important principles that are helpful for all website editors and developers to understand, regardless of their technical expertise.

What is web accessibility?

Accessible web design is about making sure webpages are not constructed in ways that inadvertently create barriers, making it difficult or impossible for some people to access the pages’ useful content. These barriers can be the result of not using the features of the underlying html code as they are intended, or assuming that all people will ‘see’ our pages as we see them.

How do people view webpages?

People view webpages on all kinds of hardware and software:

  • PCs
  • laptops
  • Macs
  • tablets
  • personal digital assistants
  • mobile phones

Various different browsers (not necessarily the latest versions)

  • Internet Explorer
  • Firefox
  • Chrome
  • Safari
  • Opera
  • and others

People with certain disabilities such as dyslexia, blindness or partial sight, may use assistive software such as:

  • screenreaders
  • screen magnifiers
  • make adjustments to the settings on their browsers
  • text readers
  • speech input software
  • and others

To accommodate this wide range of display methods, we need to make sure our pages are flexible enough to adapt to these differing requirements.

Information resources

We recommend you read the article on the Web Accessibility Initiative website which describes how people with disabilities use the web. This article helps to put the whole area into context by examining some of the practical realities.

If you would like a more wide-ranging introduction to web accessibility, the WebAim introduction to web accessibility is a good place to start.

For those who would like a deeper understanding of this area, the Web Accessibility Initiative has a wealth of resources and materials to help in both understanding and implementing accessibility. They also produce the international standard for web accessibility, the Web Content Accessibility Guidelines.

Why do we need to make our webpages accessible?

It is a legal requirement

  • The Disability Discrimination Act of 1995, extended to include education providers by the Special Educational Needs and Disability Act 2001, places on us as an institution the legal responsibility not to discriminate against disabled students, staff or other users of our services by treating them less favourably in our provision of services and facilities. It also obliges us to make reasonable adjustments to avoid placing people with disabilities at a substantial disadvantage by being denied access to services and facilities that are available to those who are not disabled.
  • Amongst the services we provide to current and prospective students is the provision of information and services, both educational and non-educational, on the University website. We are required by law to make ‘reasonable adjustments’ to enable equal access for all to the information and services we provide via the web.
  • As a university there is a further obligation on us to maintain the accessibility of our website through the QAA’s Code of Practice for the Assurance of Academic Quality and Standards in Higher Education: Section 3 Disabled Students, which states: ‘Websites and any other sources of computer-based information for prospective students, current students and alumni should be designed according to professional standards of accessibility.’
  • The legal obligations on us mean we must:
    • take steps to anticipate and prevent predictable barriers to access to information and services on the website by making appropriate adjustments to avoid potential problems for access
    • respond to the needs of particular individuals who make known to us any specific barriers they encounter when trying to access web-based information and services.

It is a social issue

  • Making information about the University accessible to this wider audience through an accessible website helps to further one of the key strategic themes of the University’s strategic plan — to be ‘tolerant, humane and liberal minded, with the pursuit of truth, openness and equality and diversity at the heart of what we do’.
  • It is essential for our equality and diversity, which is also an important aspect of our corporate social responsibility.
  • Web accessibility focuses on people with all types of disabilities — visual, auditory, physical, speech, cognitive, and neurological disabilities — including older people with age-related impairments. Accessibility barriers to print, audio, and visual media can be much more easily overcome through web technologies, providing people with disabilities with more effective and efficient access to information through accessible websites so they can more actively participate in society.
  • The main focus of web accessibility may be people with disabilities, but accessibility benefits people with or without disabilities. For example:
    • People who are not fluent in English
    • People with low bandwidth connections or using older technologies
    • People using newer technologies, such as web-enabled mobile phones and personal digital assistants
    • People working in a noisy environment
    • People who do not have or are unable to use a keyboard or mouse
    • People with temporary disabilities due to accident, illness or ageing
    • Older people
    • People who have difficulty reading or comprehending text
    • New and infrequent users

It makes our pages more usable for all users

  • Accessible websites are more easily navigable, more flexible and easier to understand.
  • Improving web accessibility has been shown to result in webpages that are more easily findable by search engines. This makes our pages more effective both for the University’s internal search and in the wider web, thereby also increasing the number of users to whom our pages are available.
  • Increased usability means our site allows users to achieve their goals efficiently, effectively and satisfactorily.

It makes good business sense

  • By making sure that the meaningful content of our webpages is freely available to as wide a range of users as possible, we maximise our audience reach, and thus potentially reach a wider market.
  • Greater compatibility and future proofing can help webpages remain accessible as browsing software and web standards change, saving on work needing to be done to amend sites in line with such developments.
  • Simpler, cleaner code and content make pages easier to maintain.
  • If users have a positive experience of our site they are more likely to use it thoroughly, return more often and tell others about our site.

It improves our site’s technical performance

  • For example, the use of stylesheets for presentation and proper mark-up for content outlined in the guidelines means our pages load more quickly, as page file size is reduced, and when developing new pages in the corporate template time and effort is also saved on design.
  • Our pages work more reliably across different browsers and older technology if they are constructed according to published technical standards.

Source material: Developing a Web Accessibility Business Case for Your Organization, S.L. Henry and A.M.J. Arch, eds. World Wide Web Consortium (MIT, ERCIM, Keio), June 2009

Misconceptions about web accessibility

  • Isn’t web accessibility just for blind or partially-sighted people?
  • My page looks fine on my machine! Most people will see it on Internet Explorer using Windows XP anyway.
  • Shouldn’t people view the website the way the designer intended?
  • Don’t accessible websites look a bit boring?
  • We don’t need our pages to be accessible as we are not targeting those audiences.

Don’t discriminate

The last statement in that list is the most mistaken — it is actually discriminatory and therefore illegal. We target a number of different audience groups, amongst whom can be included all manner of people with various disabilities that affect how they use the web — we simply cannot predict, and should not make assumptions. The law states we must not discriminate against people with disabilities by excluding them from our service provision in this way. So we need to design our web pages inclusively.

Be flexible

Legislation that has driven web accessibility focuses on web use by people with disabilities, and many of the examples provided in arguing for accessibility are based on blind users, simply because it’s a disability whose affect on the user’s experience of the web can be fairly easily understood. But a fundamental factor to appreciate is that when we design web pages we do not have control over what machinery our users view them on or how it will appear to them.

Some people may be using specialist assistive software such as screen readers, speech browsers, or screen magnifiers, or they may have to rely on a keyboard or joystick instead of a mouse; others may simply be making use of special settings in their browsers. All users, with or without a disability, can be using any combination of operating system, browser, display settings, internet connection, all of which means they may not see what you see on your screen, and you cannot control this.

That is why we need to provide webpages that can be flexible enough to still be accessible in as many of the ways users are reading them as possible.

Don’t be boring

Accessible webpages certainly do not have to be boring! Adhering to accessibility standards does not prevent the use of multimedia technology that makes the web so dynamic, but we need to ensure that the content of webpages is available even when those newer technologies are not turned on or are unavailable to users.

Мастер Йода рекомендует:  XML в 10 тезисах

Nor is it necessary to produce alternative text-only versions of all your pages (although it may be decided in some cases that this cannot be avoided). Not only is this unnecessary extra work, the text-only version often becomes ‘secondary’ to the main site and isn’t updated as often as the primary pages.

More popular accessibility myths debunked

Some popular misconceptions about what web accessibility means are debunked in this article on web accessibility myths from Nomensa’s Humanising Technology blog.

Standards compliance

  • Valid XHTML and CSS: Our corporate pages are written in valid XHTML 1.0 Transitional and styled using valid CSS2 code. We validate our pages regularly to ensure this standard is maintained.
  • Accessibility: The University recommends compliance with the WCAG 1.0 AA standard, and this is the standard we apply to the corporate webpages. Some of the guidelines require interpretation and we have used informed judgement to implement them with the needs of users foremost in mind. We have working methods in place to try to maintain this level of accessibility.
  • WCAG2.0: We are planning our transition to WCAG 2.0.

Standards and guidelines do not necessarily address all accessibility problems, so we particularly encourage anyone having difficulties using our site to contact us directly so we can fix any outstanding problems. Comments on any matter concerning the University home pages, including the accessibility of our pages, can be sent to the Web Editor.

Navigation a >

We have incorporated the following features into the University site to help you find your way around:

  • Search box
    • A search box allowing you to search the University site is available on every page using the standard University page design.
    • Advanced search options are available from the search results page.
  • Site map
    • If you are having any trouble locating the information you are looking for, a full site map is available.
  • Breadcrumb trail
    • We provide a breadcrumb trail feature above the main content of each page to show you the path from the home page to where you are in the site.
  • Links
    • We try to ensure all our link text is written to make sense out of context.
    • We have used title attributes where appropriate to give further information about the target of a link.
  • Access keys
    • Due to the current lack of a consistent standard for the implementation of access keys, and the resulting unreliability in the way they work, we have decided at this stage not to include them on our pages. We do however feel that they are a useful idea in principle, so we will monitor developments on this issue and hope that in due course a standard will be agreed within the web community, at which point we will be willing to adopt it. In the meantime we will be happy to hear any views you may have on this subject.

Visual design

  • Presentation
    • We use stylesheets for visual layout combined with structured markup of headings, paragraphs and lists to separate content from presentation.
    • The content of our pages is still readable if stylesheets are turned off or unavailable.
    • We have used relative font sizes on our pages to ensure text is resizeable in visual browsers. See instructions for how to resize text in different browsers.
  • Images
    • All content images have alt text prov , which means screen readers ignore the images completely.

Browser compatibility

We test our pages to ensure the information they contain is accessible in a range of different browsers as well as with screenreading software. By adhering to web standards we avoid the use of features specific to one browser. If you experience problems whilst using assistive software to access our site, please do let us know.

Key issues

Wherever there is a query over how or whether to comply with a specific guideline, the rule of thumb is, ‘if we don’t do something about this, will we be making it either impossible or difficult for one or more groups of users to access the information on our pages?’ If the answer is Yes, then you need to find a solution. If you are not sure what to do about a certain issue with your page, contact the Digital Team.

These are the key issues to address from the WAI Priority 1 and 2 guidelines:

  • Images and graphics
    • Include appropriate ALT text with all images, and longer descriptions of complex images and charts.
  • Image maps
    • Use client-side image maps wherever possible.
    • Always specify appropriate ALT text for all linked areas of the image map and for the main image itself.
    • Provide a separate text-based list of links to accompany the image map.
  • Colour
    • Do not rely on colour alone to convey meaning.
    • Use text and background colours that contrast well.
  • Language
    • Clearly identify the language of the page and any changes in language within a page.
    • Use the clearest and simplest language appropriate for your pages and their intended readers.
  • Scripting languages
    • Ensure that pages are usable when scripts, applets or other programmatic objects are switched off or not supported. Otherwise provide equivalent information on an alternative page.
  • Multimedia
    • Ensure that alternative formats accompany multimedia presentations (text transcriptions for audio and video clips, captions for video).
  • PDFs
    • Documents that a particular group of people will want to print out (for example, minutes of University committee meetings) can be published in pdf format only, as long as you can provide an accessible version of the document to anyone who may request it (eg a Word version for use with screen reading software). Provide a link to the Adobe download page for the Acrobat Reader so that users can easily get the latest version if required.
    • If the pdf document contains information that you want to communicate to a much wider audience, you need to seriously consider providing them as HTML webpages, in addition to PDF for printing, since they are much more accessible than PDF files.
    • PDF format has become more accessible, but taking advantage of this accessibility requires the use of the correct software. Acrobat Reader 5.0 has features that allow screen readers to improve their access to PDF documents. However, not all users have this version installed, and not all PDF documents are text−based (some are scanned in as graphics), which renders them useless to many assistive technologies. It is recommended that an accessible HTML version be made available as an alternative to PDF. Please contact the Digital Team if you require advice.
  • Flash
    • Do not rely on Flash and other plug-ins alone. Ensure content is accessible without the plug-ins.
    • Ensure that any Flash plug-ins used follow Macromedia accessibility guidelines.
  • Tables
    • For data tables, identify row and column headers, and if they have two or more logical levels, use markup to associate data cells and header cells.
    • If you use tables for layout, ensure the table makes sense when linearised and avoid complex nested table layouts.
  • Cascading style sheets
    • Use stylesheets as much as possible.
    • Ensure stylesheet elements validate to CSS 2.
    • Ensure your pages can still be read without stylesheets.
  • Valid code
    • Create documents that validate to published formal grammars (see Valid XHTML and CSS).
  • Frames
    • Avoid the use of frames – there is no provision for them in the University’s corporate template design.
  • Movement
    • Avoid flickering and moving images or text. If unavoidable ensure appropriate refresh rates are used.
  • Links
    • Use appropriate link text to ensure it makes sense when read out of context.
    • Use title attributes where appropriate to give further information about the target of a link, but use them carefully. Do not use them to repeat link text.
  • Provide a way to skip repetitive content
    • We have included a ‘Skip to main content’ link at the start of all our standard pages to enable screenreader users and those tabbing through links to bypass the page banner and navigation links and go straight to the main content of each page. This link is designed to be invisible in graphic browsers most of the time, but if you tab through the page links, it will become visible once you focus on it. The link is also available to be read by screenreaders.
  • Divide large blocks of information into manageable chunks
  • Provide clear and consistent navigation – orientation information, navigation bars, a site map, etc. – to increase the likelihood that a person will find what they are looking for at a site.
    • Provide information about the general layout of a site (eg a site map or table of contents).
    • We provide a breadcrumb trail feature above the main content of each page to show you the path from the home page to where you are in the site.

Changing page appearance

How to make the text larger and set the text colour in your web browser.

Microsoft Internet Explorer

  • Newer versions of Internet Explorer include a zoom feature that allows you to increase the whole web page.
    • Use the keyboard by pressing CTRL and ‘ + ‘ to zoom in and CTRL and ‘ ‘ to zoom out.
  • If you are using a mouse with a scrollwheel you can scroll text and images bigger and smaller by holding down the CTRL button on the keyboard and scrolling the scrollwheel at the same time.
  • Or choose the Tools menu at the top of the browser window (Alt+X)
    • A list of options will appear in the drop down menu, choose Internet Options
    • A ‘General’ window will open, with ‘Appearance’ at the bottom of the window.
    • Select ‘Colors’ to change the font colour, or ‘Fonts’ to change the font size.
    • The text in your browser should now appear in the size and colour you have selected.
    • You may need to use the ‘Accessibility’ options to choose to ignore font size and colour set by the website.
  • See the Microsoft website for more information about accessibility options in Internet Explorer.

Chrome

  • Click the ‘Customise and control Google Chrome’ button (the spanner to the right of the address bar).
  • Select the ‘Settings’ option
  • Select ‘Show advanced settings’
  • Scroll down to the ‘Web content’ heading
  • Next to ‘Zoom’ in the menu, click the plus or minus buttons to increase or decrease the text size
  • Alternatively you can use the ‘Customise fonts. ‘ button to change the font size.

Using the keyboard:

  • To increase the text size press Ctrl + + on the numeric keypad (hold down Ctrl and press +), or Ctrl + = on the main keyboard
  • To decrease the text size press Ctrl + —
  • To return to the default font size press Ctrl + 0
  • See the Google website for more information about accessibility features in Chrome.

Firefox

Firefox uses a Zoom feature that resizes the whole web page.

  • You can use the keyboard by holding down the CTRL button whilst pressing the ‘+’ key to zoom in or the ‘-‘ key to zoom out.
  • Or go to View > Zoom > Zoom in OR Zoom out
  • If you are using a mouse with a scrollwheel you can scroll text and images bigger and smaller by holding down the CTRL button on the keyboard and scrolling the scrollwheel at the same time.

The default Zoom setting will automatically resize all the images present on the page as well as the text. So if you increase the size of text, images get bigger and vice versa. Our site makes use of large billboard images with graphic text which can be made larger using this feature. However, if you wish to resize only the text without enlarging the images you can disable automatic image resizing in Firefox.

  • Go to View > Zoom and check ‘Zoom Text Only’.

Firefox will also remember the preferred Zoom text size setting you have used for individual sites you visit and will display them at the same size when you visit them again.

  • To change hte font colour, go to ‘Tools’ and then click on the ‘Content’ tab.
  • Select ‘Colors. ‘ to set the colour.
  • See the Mozilla website for more information about setting fonts and colours in Firefox.

Safari

From the View menu:

  • Select ‘Make text bigger’, or ‘Make text smaller’

Using the keyboard:

  • Hold down COMMAND key and press the ‘+’ key on the keyboard to enlarge the text or the ‘-‘ key to decrease the text size.

Opera

From the View menu:

  • Select Zoom and then the percentage you require to increase or decrease the text.

Using the keyboard:

  • Use the ‘+’ and ‘-‘ keys to increase or decrease the text by 10% at a time.

accessibility Начало работы с доступом

замечания

Понимание доступности — это процесс связывания четырех основных категорий способностей к разработке программного обеспечения. Эти широкие категории:

Для каждой категории необходимо учитывать потребности пользователей. Следует также понимать, что каждый человек обладает рядом способностей, и этот диапазон может очень сильно зависеть от того, что включает возраст человека, его среду и другие виды деятельности, в которых они могут участвовать. Некоторые примеры решений проблем, с которыми сталкиваются люди с способности вне «нормального» диапазона включают:

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

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

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

Лицам с когнитивными нарушениями нужны такие решения, как упрощенная терминология, примеры ввода и унифицированные макеты страниц.

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

Современное решение для слабовидящих — шаблон Аccessibility для сайта на базе Joomla

Дата публикации: 2020-01-24

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

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

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

Какой должна быть версия сайта для слабовидящих?

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

Как создать сайт самому?

Какие технологии и знания необходимы сегодня, чтобы создавать сайты самостоятельно? Узнайте на интенсиве!

Согласно нормам российского ГОСТа, отличительными чертами визуальной составляющей версии сайта для слабовидящих должны быть:

монохромная черно-белая расцветка;

отсутствие ярко выраженных графических элементов и графики как таковой.

То есть, грубо говоря, версия web accessibility для сайта должна представлять собой набор веб-страниц, на которых содержится лишь текст, написанный понятным крупным шрифтом, а также удобная и понятная навигация.

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

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

Создание версии для слабовидящих на Joomla своими руками

Если вы являетесь рукастым специалистом в работе на CMS Joomla и постоянно проходите интернет-курсы по совершенствованию навыков в веб-разработке, то можете попробовать создать переключатель версий сайта самостоятельно. По сути, аналоговый вариант представляет собой не что иное, как дополнительную таблицу стилей CSS. Грубо говоря, все, что вам нужно — это отредактировать текущую версию таблицы стилей под нормы ГОСТа и залить в ядро сайта JavaScript, с помощью которого получилось бы переключать шаблоны между готовыми CSS-файлами.

То есть порядок действий должен быть примерно следующим:

Как создать сайт самому?

Какие технологии и знания необходимы сегодня, чтобы создавать сайты самостоятельно? Узнайте на интенсиве!

Вносите в нынешний CSS id, который позволит движку его определять.

Копируете таблицу стилей и корректируете ее согласно требованиям ГОСТ (убираете изображение, увеличиваете шрифт, изменяете фон).

Вносите в файл пометку, что данная версия действует для слабовидящих.

Пишете код скрипта с помощью функции look() с указанием пути к другому файлу CSS.

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

Если после проделанных операций ваш шаблон accessibility не работает, то лучше верните базовую версию сайта и загрузите на нее готовый шаблон со встроенным accessibility settings согласно приведенной ниже инструкции.

Пошаговая инструкция по установке готового шаблона

А теперь давайте перейдем непосредственно к тому, как установить шаблон accessibility для Joomla. Чтобы вам было проще ориентироваться в дальнейших ступенях информации, для начала можно пройти полезные курсы по веб-дизайну, которые смогли бы заметно усовершенствовать ваши навыки. Ну, а если же не терпится перейти к практике, тогда идем дальше.

Шаг 1. Скачиваете шаблон и плагин

Шаблон представляет собой ту самую картину сайта, которая будет находиться перед людьми со зрительными отклонениями, а благодаря плагину Template Switcher пользователи смогут переключаться с одной версии на другую.

Шаг 2. Разархивируете и устанавливаете файлы

По отдельности установите каждый файл. Установка плагина производится в админке Joomla, в разделе «Менеджер расширений». Не забудьте его активировать.

Шаг 3. Устанавливаете шаблон

Делается это также в админке, в разделе «Менеджер шаблонов». После того как установка будет завершена, вы увидите список загруженных шаблонов, среди которых нужно выбрать Accessibility.

Шаг 4. Донастраиваете шаблон

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

Шаг 5. Настраиваете плагин

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

Шаг 6. Создаете специальный модуль

Это необходимо, чтобы кнопка-переключатель отображалась на сайте. Создать модуль можно в разделе «Расширения» — «Менеджер модулей» в админ-панели. Модуль должен состоять из html-кода, который будет представлять собой путь к альтернативной версии сайта. Не забудьте активировать модуль.

Шаг 7. Создаете еще одну кнопку

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

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

Как создать сайт самому?

Какие технологии и знания необходимы сегодня, чтобы создавать сайты самостоятельно? Узнайте на интенсиве!

Хотите узнать, что необходимо для создания сайта?

Посмотрите видео и узнайте пошаговый план по созданию сайта с нуля!

Добавить комментарий