Как добросовестные разработчики, мы стремимся к тому, чтобы наши приложения были оптимизированы, понятны и просты в использовании. Мы прилагаем все усилия, чтобы убедиться, что они хорошо выглядят и хорошо подходят для данного рабочего процесса, но часто забываем, что не все воспринимают нашу работу одинаково.
От дислексии и дальтонизма до полного нарушения зрения и проблем с подвижностью, процент населения сталкивается с препятствиями, которые могут сделать использование приложения трудным или даже невозможным. К счастью, как разработчики Flex, у нас есть отличная поддержка, встроенная в выбранную нами платформу для различных решений для обеспечения доступности, и мы можем адаптировать наши приложения несколькими способами, чтобы убедиться, что они работают для всех пользователей.
В конце статьи вы найдете викторину, спонсируемую Adobe. Проверьте себя и посмотрите, насколько хорошо вы делаете.
Доступность — это способность объекта использоваться кем угодно, независимо от его неспособности. Чтобы приложение было доступно, веб-разработчики используют методы и концепции дизайна, которые позволяют пользователям с любым видом нарушений перемещаться по веб-страницам и использовать программное обеспечение. Это может включать изменение структуры компонента, добавление текста для лучшего взаимодействия с программами чтения с экрана, выбор набора цветов с учетом контраста и дальтонизма или предоставление полного доступа с клавиатуры ко всему на экране. Основная идея заключается в том, что ваш веб-сайт или приложение могут использовать те, кто частично или полностью слеп, или у кого есть проблемы с распознаванием одного цвета от другого, или для которых ограничена подвижность, и поэтому использование мыши или жесты затруднены.
Многие люди думают о инвалидных колясках, когда думают об инвалидности, но с точки зрения программного обеспечения это не обязательно является препятствием; большинство людей, прикованных к инвалидной коляске, могут без проблем управлять программным обеспечением компьютера.
Мы используем иногда противоречивый термин «инвалидность» здесь просто как универсальное средство для описания различных физических и психических состояний, нарушений зрения или слуха или других состояний. Это никоим образом не является попыткой описать людей с какими-либо нарушениями как инвалидов; скорее это просто термин, который понимают все.
Инвалидность, которая, скорее всего, повлияет на ваших пользователей, подразделяется на четыре основные категории и представляет свои собственные проблемы для разработчиков (этот список не является исчерпывающим, научным или окончательным; он просто дает вам отправную точку):
- Нарушения зрения
-
Нарушения зрения включают туннельное зрение, дальтонизм и, конечно, юридическую слепоту. Пользователи с ослабленным зрением чаще всего страдают от проблем с доступностью, поскольку все, что делается на компьютере, в некоторой степени визуально. Эти пользователи в значительной степени полагаются на клавиатуру для ввода и управления, и, как правило, избегают использования мыши. Экранная лупа или программа чтения с экрана обеспечивают большую помощь, как и аудио события и подсказки. Некоторые используют дисплей Брайля, чтобы «читать» текст на экране кончиками пальцев.
- дислексия
-
Пользователи с дислексией, вероятно, будут иметь большие трудности с чтением веб-страницы или с большим количеством текстовых элементов управления. В некоторых случаях это также может осложнить ввод данных, например, использование функции поиска. Могут помочь такие стратегии, как логическая страница или структура экрана, а также разработчики, принимающие принципы проектирования, которые делают приложение максимально понятным. Пользователи с дислексией могут также использовать программы чтения с экрана, чтобы помочь с их пониманием.
- Моторные нарушения
-
Моторные нарушения могут варьироваться от дрожания рук или рук, потери конечностей или отсутствия контроля и движения частей тела. В этих случаях необходимо учитывать устройства ввода, учитывая, что пользователи могут быть совершенно не в состоянии управлять мышью. Даже если пользователь не может печатать, существуют другие вспомогательные технологии, которые могут ему помочь. Для этих пользователей необходима полная навигация и управление с клавиатуры.
- Когнитивные нарушения
-
Эта группа, вероятно, самая дальняя. Инвалидность может включать нарушения способности, такие как память, понимание и интерпретация. В некоторых случаях это могут быть временные ситуации; в других они постоянны — и нет простого решения, чтобы удовлетворить их всех. Эта группа лучше всего обслуживается комбинацией методов, используемых для других трех групп, связанных с общей философией дизайна, понимающей, что все больше и больше людей в Интернете не являются фанатами и программистами и поэтому относятся к программному обеспечению не так, как мы ожидаем.
- Другие требования
-
Для некоторых пользователей решение может быть таким же простым, как обеспечение того, чтобы ваше приложение обеспечивало масштабирование шрифта. Даже если пользователь не считает себя слабовидящим, он может быть немного недальновидным или тратить слишком много времени на просмотр экрана, поэтому возможность увеличения экранных шрифтов может значительно облегчить жизнь. Я — постоянный разработчик программного обеспечения и писатель, но у меня проблемы со зрением, поэтому я всегда ценю возможность увеличить размер шрифта в приложении; технически я сам могу попасть в категорию нарушений зрения.
Существует много причин для создания доступного программного обеспечения, о котором мы расскажем здесь:
- экономика
-
Если вы занимаетесь программным бизнесом, который зарабатывает деньги на продаже лицензий, или возглавляете проект по внедрению нового приложения или рабочего процесса в организацию, вы получаете выгоду от большего числа людей, использующих программное обеспечение. Трудно найти статистику пользователей компьютеров с ограниченными возможностями, но организация Blind Citizens Australia приводит статистические данные за 2004-2005 гг. , В которых выявлено свыше 480 000 людей с нарушениями зрения и более 50 000 полностью слепых. Исследование, проведенное Фондом Фреда Холлоуса, упоминает, что, по оценкам Всемирной организации здравоохранения , к 2020 году более 75 миллионов слепых или слабовидящих в мире .
Это много потенциальных пользователей, и это только одна часть нашей целевой аудитории. По оценкам интернет-сайта сообщества инвалидов , около 10 процентов населения мира, или около 650 миллионов человек, живут с какой-то формой инвалидности.
- законодательство
-
Во многих странах существует антидискриминационное законодательство, которое требует, чтобы веб-сайты и приложения включали хотя бы некоторый уровень доступности. Еще более строгие правила могут применяться в государственном и образовательном секторах. Уровень исполнения этих актов сильно варьируется, но всегда есть вероятность потери дохода или оштрафовки и принуждения к перепланировке, если вы не соответствуете требованиям. Обязательно ознакомьтесь с законодательством, регулирующим страны и секторы бизнеса, в которых вы работаете. Это особенно важно, когда программное обеспечение является требованием для получения доступа к любому виду государственного или образовательного обслуживания или поддержки.
- технический
-
Всем известно, что Google и другие веб-пауки являются важными инструментами для продвижения и продажи программного обеспечения и веб-сайтов, но вы можете не осознавать, что стандартные методы обеспечения доступности также могут помочь паукам в индексации ваших страниц. Если вы думаете об этом, движок-паук — по сути слепой пользователь, который читает только текст и код на вашем сайте. Это важно, если вы настраиваете структуру с глубокими ссылками или текстовые альтернативы, и поскольку все больше движков начинают рассматривать сами SWF-файлы, эти методы становятся еще более актуальными.
- Делать правильные вещи
-
Альтруизм не всегда поддается измерению, но вы можете быть уверены, что если вы приложите все усилия, чтобы сделать ваше программное обеспечение доступным, это порадует многих людей; даже те, для кого доступность не является ключевым вопросом, будут помнить ваши усилия. Если чистого альтруизма недостаточно, помните, что счастливые и впечатленные клиенты отсылают других!
Flex предоставляет нам ряд технических решений для обеспечения доступности. Давайте рассмотрим некоторые приемы и приемы, которые вы можете использовать, чтобы ваши приложения обслуживали как можно больше пользователей.
Приложения Flex 3 по умолчанию недоступны, поэтому вам нужно включить специальную доступность самостоятельно (однако обратите внимание на бета-версию Flex 4, поскольку теперь она по умолчанию включает в себя доступность). Это добавит около 8 КБ к вашему SWF-файлу, и есть четыре способа сделать это.
Чтобы автоматически включить доступность для всех приложений Flex, вы можете изменить файл flex-config.xmltrue
<mxml-compiler>… <available> true </ available>… </ mxml-compiler>
Вы можете включить специальные возможности для каждого проекта в Flex Builder, выбрав параметр « Создать доступный SWF-файл» в разделе « Параметры компилятора » диалогового окна « Свойства проекта», показанного на рис. 1 «Создание доступного SWF-файла» .
Чтобы включить специальные возможности при использовании компилятора командной строки, вы можете добавить переменную конфигурации -compiler.accessible-accessible
mxmlc -compiler.accessible /myapp/app.mxml
или
mcml -accessible /myapp/app.mxml
Любой из этих методов изменит файл .actionScriptProperties
<compiler AdditionalCompilerArguments = ”- языковой стандарт en_US” generateAccessible = ”true”>
Если ваше приложение скомпилировано во время выполнения и не установлено для доступности по умолчанию, вы можете включить его на лету, добавив параметр запроса к URL-адресу следующим образом:
http://www.example.com/myapp/app.mxml?accessible=true
В Flex 3 SDK включено 28 доступных компонентов. Полный список их и предоставляемых ими улучшений доступности см. В документе со списком компонентов и контейнеров Adobe Accessible . Если вы хотите сделать свою RIA доступной, вам нужно собрать как можно больше с полностью доступными компонентами. Если вы создаете новые компоненты, вам необходимо добавить поддержку специальных возможностей или, по крайней мере, создать подкласс доступного компонента из SDK. Этот отрывок из документа Adobe Accessibility Best Practices:
Чтобы компонент был доступен, он должен предоставлять информацию о роли и состоянии в соответствии со спецификацией Microsoft Active Accessibility (MSAA). Разработчики, планирующие разработку своих собственных компонентов, должны с самого начала планировать исследовать и внедрять MSAA, чтобы обеспечить согласованное поведение компонентов Flex с другими элементами управления на уровне операционной системы. После того, как поддержка MSAA была добавлена в элемент управления, важно проверить, что компонент работает с вспомогательной технологией, такой как программа чтения с экрана JAWS. Программы чтения с экрана редко реализуют всю спецификацию MSAA, особенно внутри браузера, поскольку веб-приложения обычно полагаются только на 12 базовых элементов управления, включенных в спецификацию HTML. Некоторая степень координации с поставщиками программ чтения с экрана может потребоваться, если пользовательский компонент отличается от подхода, используемого в наборе компонентов Flex по умолчанию, или вводится новый тип элемента управления.
Программы чтения с экрана — это приложения, которые пользователи с нарушениями зрения используют для навигации по веб-сайтам и приложениям. Эти приложения считывают текст и элементы навигации, используя синтезированный голос. Чтобы по-настоящему понять этот опыт, вам необходимо установить устройство для чтения, такое как JAWS , и попытаться перемещаться по приложению с выключенным монитором. Если вы никогда не делали этого раньше, я настоятельно рекомендую это для удивительного понимания трудностей, с которыми сталкиваются некоторые пользователи.
JAWS является стандартом для программ чтения с экрана, поэтому его можно проверить. Это программное обеспечение только для Windows, поэтому, если вы работаете на компьютере Mac или Linux, вам потребуется настроить виртуализацию или двойную загрузку. Мы будем ссылаться на JAWS в остальной части статьи при обращении к программам чтения с экрана.
При кодировании программ чтения с экрана двумя наиболее важными аспектами являются альтернативный текстовый контент и порядок чтения. Как следует из названия, порядок чтения определяет порядок, в котором JAWS будет читать вслух содержимое экрана. Для очень простого приложения это может не быть проблемой, но с любым видом сложной или нестандартной компоновки порядок чтения по умолчанию, вероятно, будет очень запутанным для пользователя JAWS. Это влияет на все, от навигации до ввода данных; например, если ваш порядок чтения неправильный, пользователь может прочитать неправильную метку поля формы JAWS и попытаться ввести неправильные данные в поле, на котором они в настоящее время сосредоточены. По этой причине вы всегда должны запускать свое приложение через JAWS, чтобы понять, как оно читается.
Наиболее важным моментом является поддержание вашего интерфейса простым и беспрепятственным, используя доступные компоненты, такие как аккордеон и навигатор с вкладками. После этого вам нужно присвоить значение tabIndex каждому объекту в вашем интерфейсе, включая текстовые поля и не фокусируемые элементы управления интерфейсом.
Если вы пропустите хотя бы одну вкладку «Индекс», весь лот будет проигнорирован, и Flex вернется к порядку чтения по умолчанию!
Вы также можете добавить инструкции в различных местах, которые программа чтения с экрана может прочитать пользователю вслух. Может быть полезно включить описание, введя текст в свойстве description для приложения или в свойствах всех контейнеров. Имейте в виду, что эти инструкции будут читаться каждый раз, когда пользователь обновляет или перемещается в верхнюю часть приложения, поэтому, если они слишком длинные, они станут громоздкими. Из документа Adobe Best Practices приведен пример, включенный в демонстрационное приложение Blog Reader:
function availableInit () {var desc = createObject ("TextInput", "desc", 0); desc.x = 0; desc.y = 0; desc.width = 0; desc.height = 0; desc.accessibilityProperties = new AccessibilityProperties (); desc.accessibilityProperties.description = 'Инструкции доступа. Flex Blog Reader читает записи из разных блогов в Интернете. Чтобы взаимодействовать с этим приложением, включите режим форм после входа в приложение. ';}
Затем функция вызывается из тега приложения:
<mx: Application xmlns: mx = "http://www.adobe.com/2006/mxml" creationComplete = "availableInit (); ” pageTitle = "Flex BlogReader">…
Вам может понадобиться добавить совершенно отдельный экран для инструкций, предоставляя кнопку или ссылку для их просмотра. Это хорошая идея, чтобы эта кнопка или ссылка была первой деталью, которую читает программа чтения с экрана, чтобы пользователь знал, что он может легко получить помощь.
Все элементы управления должны иметь всплывающие подсказки, содержащие их имя и, при необходимости, краткое изложение того, как их можно использовать. Помните, что подсказки будут считываться программой чтения с экрана, поэтому, если есть какая-то информация, которую пользователь должен знать о элементе управления, поместите ее во всплывающую подсказку. Название и описание любых изображений также должны быть доступны во всплывающей подсказке. Убедитесь, что если вы используете кнопки значков в своем приложении, у них есть всплывающие подсказки, описывающие их функции (это хорошая практика в любом случае). Если вы хотите добавить дополнительную информацию к изображению, вы можете поместить текст в свойство accessibilityProperties Вот еще один пример из документации Adobe:
<mx: Ширина изображения = "60" height = "56" source = "assets / icecreampint.jpg" toolTip = "Пинта мороженого" creationComplete = "event.target.accessibilityProperties = new AccessibilityProperties (); event.target.accessibilityProperties. description = 'Наша прекрасная мороженная пинта - идеальное блюдо для домашнего мороженого' "/>
Когда видео и аудио контент включен, полезно иметь синхронизированный текстовый эквивалент в форме подписей. Вы можете настроить это самостоятельно, но есть несколько отличных инструментов, таких как Hi-Caption Studio от HiSoftware и MAGpie из Национального центра доступных медиа. Они создают специальный XML-файл с данными титров, настроенными специально для Flash, и могут быть объединены с Captionate для доставки титров, связанных с ключевыми точками в видео. Очевидно, что вам нужно добавить элемент отображения в ваш видеоплеер, чтобы показать заголовки, где это необходимо.
Масштабирование шрифта всегда должно быть включено в доступное приложение. Дайте пользователю возможность увеличить шрифт, выбирая масштаб из поля выбора или используя сочетание клавиш. Старайтесь избегать использования каких-либо особо экзотических шрифтов, и любые используемые по умолчанию шрифты должны быть встроены.
Помните о цвете, так как у тех, кто страдает дальтонизмом, могут возникнуть трудности с подбором визуальных сигналов, которые вы воспринимаете как должное. Никогда не делайте цвет единственным средством предоставления информации. Например, столбцы на графике должны иметь альтернативный текст, или контур или граница могут помочь. Цветные кнопки должны иметь подсказки; помните, что дальтоник может не различить зеленую и красную кнопку. При добавлении инструкций убедитесь, что вы включили альтернативные описания для своих элементов управления; например, «Нажмите красную кнопку справа» . В случае ссылок может быть полезно добавить подчеркивание, а также сделать ссылку другим цветом, поэтому, если пользователь не может различить разницу в цвете, они все еще смогут распознать ссылку.
Контрастность также важна для удобства чтения. Подсветка фокуса, фоны и изменения элементов из-за событий наведения мыши должны обеспечивать достаточно сильный контраст, чтобы их могли заметить люди с нарушениями зрения. Если вы используете очень тонкие изменения оттенка в фоновом режиме или контейнерах, например, для разграничения сегментов текста или форм, это может быть невидимым для многих пользователей.
Многие пользователи не используют или не могут использовать мышь, поэтому важно убедиться, что вашим приложением можно управлять с помощью клавиатуры. Доступные компоненты во Flex уже помогают с доступом к клавиатуре, и вы можете включить их в своих компонентах без особой работы. Ключ к этому — сделать события мыши доступными через клавиатуру. Простой способ — добавить нового слушателя в элемент управления и заставить его вызывать ту же функцию щелчка мышью. Помните, что пользователь клавиатуры будет перемещаться по элементам управления на экране, поэтому убедитесь, что (например) нажатие клавиши ввода для элемента управления приведет к тому же результату, что и нажатие на него мышью.
Второе соображение заключается в том, что даже когда пользователь может использовать клавиатуру, ему все равно может быть трудно. Сочетания клавиш могут помочь в этой ситуации; например, сопоставление клавиши для загрузки справки для любого экрана или раздела, на котором сосредоточен пользователь, и добавление элементов навигации, сопоставленных с клавишами. Если вам нравится, вы можете создать глобальный слушатель клавиатуры для сочетаний клавиш, чтобы он перехватывал определенные клавиши или комбинации и работал с ними независимо.
Существует много технических проблем при разработке доступных приложений, но лучший совет, который я могу дать, — это адаптировать философию дизайна, чтобы с самого начала учитывать доступность. Намного легче разработать доступность с самого начала, чем пытаться вставить ее в приложение в конце разработки.
При разработке стремитесь к лучшим практикам, таким как минимальное вложение контейнера; это облегчит настройку программы чтения с экрана. Подумайте об использовании вашего приложения с точки зрения пользователя с ограниченными возможностями; это не только помогает поддерживать доступность, но в конечном итоге делает ваше программное обеспечение более доступным для всех. Протестируйте ваше приложение в черно-белом режиме, а затем выключите монитор во время работы JAWS и посмотрите, насколько хорошо оно работает.
Другой распространенный и полезный путь — предоставить текстовые альтернативы вашим страницам или приложениям. Это не всегда подходящее решение, особенно для корпоративного программного обеспечения, но в случае небольших приложений или областей, где пользователи ищут текст, глубокие ссылки и даже полнотекстовые альтернативы версии Flex могут быть очень полезными. Существуют различные методы, чтобы попытаться обнаружить использование программ чтения с экрана, но на данный момент они могут быть хитами. Проверьте полезную запись в блоге Стива Фолкнера на эту тему .
Конечно, не все программное обеспечение может быть сделано доступным; если это игра с высокой наглядностью, например шутер от первого лица или приложение САПР, некоторые виды инвалидности исключат пользователей, но мы ничего не можем там сделать. Даже в этих случаях мы можем внести изменения, чтобы облегчить жизнь тем, кто может использовать программное обеспечение, но может получить небольшую помощь. В конечном счете, разработка с учетом доступности делает ваше приложение лучше и расширяет вашу аудиторию.
В дополнение к тому, что мы рассмотрели здесь, есть много сайтов, посвященных доступности в той или иной форме, и некоторые предлагают отличные советы. Есть даже онлайн-сервисы и организации, которые проверят сайт или приложение, чтобы вы могли проверить его доступность; Кроме того, когда вы разрабатываете в соответствии с законодательством о доступности, может быть полезно, чтобы эксперт посмотрел ваше программное обеспечение. Если вы собираетесь заплатить компании за обеспечение доступности вашего программного обеспечения, убедитесь, что они знают, что делают, и предоставляют варианты для различных программ чтения с экрана, а также всех аспектов, упомянутых выше. Вот краткий список сайтов, которые вы можете найти полезными:
Вы также можете узнать больше о доступности Flex здесь:
Как ты думаешь, насколько хорошо ты справишься с нашей викториной? Проверьте себя и узнайте!