что такое сетевая доступность

Высокая доступность проектов. Что такое «пять девяток» и где их взять?

Высокая доступность — это то, что любят демонстрировать в цифрах. Все уже привыкли к маркетинговым ходам и доступность в 99% кажется просто фантастически высокой. Лишь малая часть клиентов понимают, что доступность 98- 99% это очень плохая, местами никуда не годная цифра.

Посмотрите на эти цифры и вы поймете, чем доступность в 90% отличается от доступности в 99,999%:

Посмотрев на таблицу выше вы понимаете, что датацентр, гарантирующий сетевую доступность в 99% может позволить себе 7 часов простоя в месяц. Представьте себе такую ситуацию: весь день в датацентре что-то чинят, ваш сайт недоступен, вы несете убытки, а предъявить претензии датацентру не можете — даже при этой ситуации он обеспечит обещанную доступность.

Я считаю сетевую доступность 99% плохой. Предпочитаю датацентры, обеспечивающие не менее 99,9% сетевой доступности.

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

“Пять девяток” — вот, что такое высокая доступность

Термин “пять девяток” означает доступность 99,999% и встречается в маркетинговой литературе не реже, чем в технической. Считается, что сайт или система с уровнем доступности «пять девяток» — это и есть высокая доступность.

Высокая доступность нужна всем

Из таблицы видно, что 99,999% доступности — это всего 5,3 минуты простоя в год. Но даже те датацентры, которые гарантируют 100% доступность нередко пускаются на маркетинговые ухищрения.
Например, вычитают время регламентного обслуживания из времени доступности. К примеру, дата-центр обещает доступность 99.99%, но в момент, когда проводит плановые работы по замене чего-нибудь пишет “проводятся регламентные работы в течение 2 часов” и не считает это за недоступность. Отсюда вывод — читайте соглашение об уровне обслуживания (SLA) внимательно.

Если вы хотите обеспечить максимально высокую доступность вашему сайту на одном единственном сервере, выбирайте датацентр с хорошей ГАРАНТИРОВАННОЙ SLA (соглашением об уровне обслуживания) доступностью.

Обратите внимание! В SLA должно быть гарантировано время замены неисправного железа. И, в идеале, время реакции на проблему.

Кроме того, ваш админ должен отслеживать работу сервиса и быстро реагировать на недоступность.

Немного о том, из чего складывается высокая доступность

Доступность может быть сетевая и сервиса.

Сетевая доступность — это когда ваш сервер доступен по сети.
Доступность сервиса — это когда ваш сервер может обслуживать клиентов.

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

Доступность сервиса зависит от:

Недоступность складывается из:

И месячную (кроме случаев поломки железа) и уж тем более годовую доступность 99,8% можно обеспечить в хорошем ДЦ на одном сервере без дополнительных мер обеспечения отказоустойчивости. Доступность 99,9% уже требует некоторого везения.

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

Источник

Обеспечение доступности данных и сервисов: показатели RPO, RTO и планирование SLA

Сегодня я постараюсь разъяснить, что такое концепция доступности данных с точки зрения ИТ-специалиста, будь то ИТ-администратор, системный интегратор, консультант по внедрению и т.д. Надеюсь, что эта статья будет полезна читателям при составлении экономического обоснования на внедрение соответствующих программных и\или аппаратных решений, а также соглашений об уровне обслуживания (SLA) – а кому-то поможет сделать эти документы более убедительными.
Для начала в качестве «узелков на память» сформулирую два постулата, с которыми многие, уверен, довольно хорошо знакомы:

Начнем «от печки», то есть с прямой линии вдоль оси времени, где:

Ясно, что все системы в компании работают не просто так, а для различных нужд/целей. Сама же компания зарабатывает (и тратит) деньги. В случае сбоя системы компания, очевидно, деньги теряет. Показатели RTO и RPO – то, что говорит о приемлемых размерах этих потерь.

Из такого графика уже видно, что стоимость простоя сервиса растет со временем: чем дольше не работает система, тем больше денег теряет компания.

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

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

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

Как видно из графика, чем меньше показатели RPO и RTO при потере данных, чем меньшее время простоя сервиса обеспечивает решение по защите, тем дороже такая защита стоит.

Определим точки безубыточности решения по защите

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

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

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

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

Получается, что наши точки безубыточности – уже не точки, а области:

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

Рассматриваем различные классы решений

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

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

Конечно, на картинке всё изображено достаточно схематично. На самом деле нет четких границ между типами решений, как и точных значений в виде точек.

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

2-5 минут на одну ВМ. И такие показатели находятся в рамках RTO для реплик или даже кластеров.

Немного о кластерах

Кластеры, как и DR-решения (и вообще практически все решения по защите от потерь данных или восстановлению работоспособности) имеют свои значения по скорости восстановления данных и объемам данных, которые теряются. Потому они также связаны со своими показателями RTO/RPO.

Говоря, например, про HA-кластер (HA – High Availability), имеем в виду, что его RTO равно времени переключения. Допустим, MSCS для двух нод переключает СУБД за 30 секунд. Значит, целевое RTO, которое можно обеспечить этим видом кластера — от 30 секунд.

А если рассмотреть VMware HA, которое отработает за 2 минуты (с учетом старта виртуальной машины, ее гостевой ОС и приложений)? Значит, такое решение подходит для приложений с целевым значением RTO от 2 минут.

Где же потери для HA-кластера (и соответственно, обеспечение RPO), спросите вы? Когда сервис поднимается, есть вероятность небольших потерь данных. Например, если СУБД проверит состояние базы данных и может откатить своё состояние на некорректно проведенную транзакцию. Или если файловая система вернется к некорректно сохраненной версии файла, и т.д., и т.п.

Вывод: не всегда стоит строить одинаковые решения одно поверх другого, например, HA над HA. Это только излишне усложнит инфраструктуру, усложнит (и удорожает) поддержку работы таких систем.

К предыдущим примерам двух HA. Определите, какое реальное значение RTO необходимо обеспечить для приложения? Для значений больше 2 минут нет смысла стоить еще и HA-кластер для сервисов внутри ВМ.

Обратим внимание еще на ряд факторов:

К примеру, резервное копирование почтового сервера не исключает, но дополняет использование кластера HA для почтовых серверов. Кластер защищает от выхода из строя физического сервера и обеспечивает быстрое переключение на резервный сервер. Но кластер не защищает от потери данных (нежелательного удаленных данных, невозможности запуска ВМ после сбоя оборудования и т.п.). Для этого необходимо применение резервного копирования.

Что при этом дает совместное использование VMware vSphere HA? Быстрое восстановление уровня защиты. Если просто выключился один сервер с одной нодой MS Exchange, то вначале отработает DAG, переключив сервисы на другую ноду, а затем HA VMware загрузит сбойный сервер на другом плече своего кластера. И система готова к работе. (Хотя в этом примере я бы рассматривал применение виртуализации не только для одной функции только кластера, но и для всех остальных преимуществ самой платформы).

Говорим и пишем правильно! Или еще раз про RTO и RPO

Хочу сделать на этом акцент, поскольку я сам периодически совершаю ошибку, потому и остерегаю от этого вас:

RTO ≠ скорость восстановления!
RPO ≠ количество потерянных данных!

RTO и RPO – это целевые значения для информационных систем (ИС), максимальные рамки, в которые мы должны уложиться. И эти целевые значения нам, ИТ-специалистам, сообщает бизнес, точнее, бизнес-владельцы соответствующей ИС, но не наоборот.

То есть:
Нельзя сказать, что RTO функции Instant Recovery – 2 минуты.
Нельзя считать, что резервное копирование раз в сутки и есть RPO 24 часа.
Всё идет в обратную сторону, то есть от бизнеса, и конкретно для RTO будет озвучиваться так:

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

Для базы данных, в случае сбоя СУБД, нужно обеспечить восстановление с допустимой потерей данных сроком не более 24 часов от момента сбоя. Значит, подойдет решение, которое обеспечит гарантированное восстановление базы из точек восстановления, производимых чаще, чем 1 раз в сутки. При этом отмечу, что резервное копирование раз в час, создающее 24 точки восстановления, дает больше гарантий восстановления, чем копирование раз в сутки, делающее только 1 точку.

А вот и практический пример

Казалось бы, можно рассуждать так:

«Применение функции Instant Recovery обеспечит технический процесс восстановления в 2 минуты. »

Но! При этом надо понимать еще несколько моментов:

Поэтому рассуждаем дальше:

«У меня настроен мониторинг для этого сервиса, и оповещение сработает и будет замечено за минуту-две (телефон с полученной СМС надо из кармана достать, или почтовый клиент с новым письмом надо открыть). Я сяду за компьютер, пингану сервис, попытаюсь открыть на нем консоль, посмотрю, что там с гипервизором и железом. Проведу первичную реанимацию (попробую перегрузить машину). На все это я потрачу порядка 15 минут. Если не помогут действия по быстрой реанимации — восстановлюсь из резервной копии. Но так как копироваться из бэкапа данные будут еще минут 15-20, то я воспользуюсь Instant VM Recovery за 2 минуты, а затем запущу онлайн перенос данных машины в продакшен.»

Как видим, в 5 минут мы вряд ли укладываемся.

Теперь подумаем, возможно, нужен HA-кластер со временем восстановления 2 минуты? Но и он не обеспечит нам защиту от всех типов сбоев: рестарт машины в BSoD вполне вероятен, диск ВМ — тоже точка отказа, и т.п. Следовательно нужна дополнительная защита. Значит, продолжаем наши рассуждения:

«В случае кластера я восстановлюсь за 2 минуты. А в дополнение я потрачу, как уже прикинул(а), 15+2 минут при восстановлении из резервной копии, всего 2+15+2=19 минут, и 11 минут ещё остаются в запасе.»

В итоге, ваш ответ бизнес-владельцу ИС будет таким:

«ОК. Я обеспечу RTO в 30 минут. Я включу этот сервис в кластер — для обеспечения 5 минутного RTO, и настрою резервное копирование — для защиты от сбоев с более серьёзными последствиями.»

Очень важно! Самый главный совет: после того, как вы согласовали с владельцем ИС конкретные целевые показатели, договорились – обязательно фиксируйте ваши договоренности с ним в письменном виде, подписывайте с ним соглашение об уровне обслуживания (SLA).

Почему мы называем это «концепцией доступности»?

Заметили, что я пишу постоянно «восстановление данных и восстановление работоспособности сервиса»? Чаще всего пишу вместе, в одном предложении. Это две связанные между собой вещи, которые почти всегда не могу жить друг без друга.

Мы восстановили работу сервиса, но при этом потеряли все его данные – это неприемлемо. Мы восстановили БД, но СУБД не запускается, прочитать данные не могут – это неприемлемо. Именно поэтому мы говорим о доступности и данных, и сервисов. Важны и RPO, и RTO – в совокупности они обеспечивают доступность и того, и другого.

Через 15 минут после сбоя восстановлен доступ к сервису с данными за весь предыдущий период работы (до 1 часа включительно) – это всё про общую доступность.

Вот такой вот дуализм 😉 Вместе дуальная пара RTO и RPO является важным показателем в том самом соглашении об уровне обслуживания (Service Level Agreement, или SLA) для конкретной ИС в части обеспечения доступности её сервисов и данных в случае возникновения сбоя. А подписывается соответствующее соглашение, как я говорил выше, между владельцем ИС (заказчиком услуги), и вами, ИТ-отделом (поставщиком услуги).

Источник

Информационная безопасность для самых маленьких. Часть 1

Вступление.
Многие слышали про взломы различных платежных систем, про новые стандарты в области информационной безопасности, про то, что государство разрабатывает новые нормативы в области персональных данных. Некоторые даже слышали три таинственных слова «конфиденциальность, целостность и доступность», но не многие понимают, что все это означает и зачем все это нужно. Сюда относятся и многие ИТ — специалисты не говоря уже про людей далеких от ИТ.
Хотя в мире, где все основано на информационных технологиях, должны понимать что такое «информационная безопасность». Информационная безопасность – это не только антивирус и файрвол, информационная безопасность это целый комплекс мер.

На Хабре начинается серия публикаций по информационной безопасности, в этих публикациях будут рассмотрены многие важные аспекты ИБ, такие как:
• конфиденциальность, целостность и доступность;
• уязвимости в программных продуктах (также обсудим черный рынок 0-day уязвимостей и эксплоитов);
• технические меры защиты;
• организационные меры (политики, процедуры, инструкции);
• модели доступа;
• стандарты и законы в области ИБ.
А также обсудим другие очень интересные вещи. Как и любой другой предмет начнем с самых основ, то есть теории.
Недавно в Твитере развернулись нешуточные страсти по «бумажной» и «практической» безопасности. Здесь будут рассмотрены как «бумажная» так и «практическая» безопасность, хотя, по моему мнению, эти две составляющие нельзя делить. Если речь идет о серьезном подходе «практика» не может существовать без «бумаги», так как для начальства, аудиторов в первую очередь важны бумажные отчеты Вашей работы. Не говоря уже про такие стандарты ISO и PCI DSS, которые требуют утвержденные руководством «бумажной безопасности».
Конфиденциальность, целостность и доступность.

Именно эти три слова служат прочным фундаментом информационной безопасности. Хотя многие считают что эта «триада» уже устарела, но об этом позже. Чтобы лучше понять значение этих слов необходимо представить следующую картину: три человека обхватили друг друга руками, и каждый сильно откинулся назад, если один из них отпустит руку другого то все упадут. Информационная безопасность достигается соотношением именно этих трех свойств, если у информации нету, хотя бы одной из этих свойств о безопасности говорить не приходиться.
Каждая из этих свойств «триады» обеспечивается рядом мер, причем для обеспечения одного свойства необходимо использовать не одно, а несколько мер. Любая информация обладает, так или иначе, всеми тремя свойствами, давайте разберем каждое значение их этой триады.

Конфиденциальность – свойство информации, гарантирующее, что доступ к информации имеет доступ только определенные лица.
Например. В фирме «Рога и копыта» есть информация, а именно отчет о продажах. Доступ имеют только сотрудники отдела продаж и бухгалтерии. Причем сотрудники отдела продаж имеют ко всей информации (более подробно будет описано ниже), а бухгалтерия только к окончательным расчетам (чтобы рассчитать налоги с продаж.).
Таким образом, конфиденциальность означает не только доступ к информации, но и разграничение доступа к информации, то Петров имеет доступ к одной части информации, Сидоров ко второй, а Иванов ко всей информации.

Целостность – свойство информации, гарантирующее, что только определенные лица могут менять информацию.
Например. Продолжим пример с фирмой «Рога и Копыта» и с их отчетом по продажам. Как было ранее сказано Отдел продаж имеет доступ ко всей информации, а бухгалтерия только к определенной части. Но для безопасности это еще мало. Необходимо еще и разграничить доступ среди Отдела продаж. В отделе есть два специалиста Сидоров и Петров, у каждого свой отчет. Необходимо чтобы каждый мог иметь право записи только в свой отчет. Вдруг Петров занизит продажи Сидорова.
Еще хороший пример.
Фирма «Рога и Копыта» создала и отправила платеж по ДБО в свой банка, однако хакер Вася перехватил платеж и в поле получателя вставил номер своего счета. Это прямое нарушение целостности. Чтобы такого не произошло необходимо предпринимать ряд мер, к примеру, ЭЦП.

Доступность – свойство информации, гарантирующее, что лица имеющие доступ к информации в нужный момент смогут получить доступ.
Например. Генеральный директор фирмы «Рога и Копыта» в понедельник утром пришел на работу, включил компьютер и с удивлением обнаружил, что не может открыть базу отдела продаж по продажам. Так что же произошло? Элементарно, Ватсон! В воскресенье ночью в потолке прорвало трубу, вода попала в компьютер, где хранилась база, и жесткий диск благополучно сгорел. Так как директор никогда не слышал про информационную безопасность, а локальная сеть была создана студентом, не было ни резервной копии, ни избыточности в виде RAID. Это самый простой пример, можно привести кучу примеров, сайт компании не был доступен и клиент не смог открыть сайт одной компании, но открыл сайт другой и естественно купил продукт второй компании.

Это было первым выпуском серии «Информационная безопасность для маленьких».
Продолжение следует.

Источник

Обеспечение доступности веб-контента: стандарты, критерии, пример реализации

Привет, меня зовут Павел. Я занимаюсь изучением и тестированием доступности.

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

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

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

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

Зачем обеспечивать доступность контента

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

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

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

Давайте посмотрим какие аспекты доступности могут быть полезны пользователям в самых разных жизненных ситуациях:

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

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

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

Как доступность регулируется на законодательном уровне

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

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

Всемирный Веб Консорциум (W3C) — это организация, которая разрабатывает и внедряет технологические стандарты для интернета.

В 1997 году Всемирный Веб Консорциум создал инициативу о доступности интернета для людей с ограниченными возможностями WAI.
В рамках этой инициативы W3C разработал техническую спецификацию ARIA, the Accessible Rich Internet Applications, которая предоставляет информацию о ролях, состояниях и фокусах с примерами применения.

Как работать с WCAG — руководством по обеспечению доступности веб-контента

Руководство по обеспечению доступности веб-контента (WCAG) состоит из нескольких уровней, о которых нужно помнить при работе с ним.

Первый уровень: принципы

Второй уровень: гайдлайны

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

Третий уровень: критерии оценивания

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

Четвертый уровень: достаточные и консультативные техники

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

Например, по принципу “Воспринимаемость” есть такой критерий:
1.1.1. Весь нетекстовый контент, представленный пользователю, имеет эквивалентную текстовую версию.

На практике часто это реализуется через атрибут alt, и есть соответствующая техника: “H37: Using alt attributes on img elements” (“Использование атрибутов alt для изображений”).

Пример реализации атрибута alt, чтобы обеспечить соответствие критерию 1.1.1. “Нетекстовый контент”

Как протестировать веб-контент на доступность

Руководство по обеспечению доступности веб-контента WCAG предъявляет 5 требований к реализации веб-контента. Следовательно, чтобы протестировать доступность, нам нужно проверить, что веб-контент удовлетворяет всем 5 требованиям.

Требование 1: Веб-контент должен соответствовать одному из уровней доступности: А, АА или ААА

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

Например, по гайдлайну “Навигация” для соответствия уровню А, контент должен соответствовать одновременно четырем критериям:

Скриншот из русской версии Руководства по обеспечению доступности. Критерии соответствия уровня А по гайдлайну “Навигация”.

Для соответствия следующему уровню доступности (АА), контент должен отвечать всем критериям предыдущего уровня А (см.рис.выше), а также всем критериями рассматриваемого уровня АА (см.рис.ниже).

Критерии соответствия уровня АА по гайдлайну “Навигация”.

Требование 2: Заявленному уровню доступности должна соответствовать вся страница

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

Версия страницы слева не отвечает критерию 1.4.3. “Минимальный контраст”, потому что контрастность текста во втором блоке (отмечен красным) нарушена. Из-за этого блока, страница слева не соответствует требованиям доступности, несмотря на то, что остальные блоки оформлены правильно.

Требование 3: Заявленный уровень доступности поддерживается на протяжении всего процесса (цепочки страниц)

Все страницы из взаимосвязанной серии веб-страниц должны соответствовать заявленному уровню доступности.

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

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

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

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

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

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

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

Требование 5. Невмешательство

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

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

Юзабилити-тестирование

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

Поэтому важную роль в тестировании доступности играет юзабилити тестирование.

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

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

Если после юзабилити-тестирования стало понятно, что веб-контент не соответствует требованиям WCAG, то первое что нужно сделать, это собрать всю информацию об этом, изучить ее и принять решение о возможности доработки.

Пример из практики: обеспечение доступности плеера электронного курса

Бывают ситуации, когда из-за особенностей реализации контента отсутствует возможность удовлетворения всем требованиям WCAG.

Мы с командой столкнулись с такой проблемой, работая над доступной версией плеера, входящего в состав конструктора электронных курсов iSpring Suite. Этот конструктор конвертирует PowerPoint-презентации в веб-контент. Слайды презентации (курса) после конвертации проигрываются в браузере.

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

Мы выбрали второй вариант, и назвали эту версию плеера “доступный скин”.

Пример доступного скина плеера презентаци.

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

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

Так скрин-ридер видит плеер в полной версии. Другими словами, у скрин-ридера нет вариантов перейти куда-то, кроме альтернативной версии.

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

Пример застревания фокуса

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

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

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

Как заявить о доступности

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

Вариант 1: Выложить на сайт заявление о соответствии контента определенному уровню доступности.

В данном варианте информация о доступности предоставляется в более кратком и сжатом формате. Если вы хотите более подробно расписать все критерии, уровни соответствия, методы и технологии, можно выбрать второй вариант:

Вариант 2: Заполнить шаблон добровольного заявления о доступности (Voluntary Product Accessibility Template или VPAT) — и выложить на сайт его.

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

В нашем случае мы опирались на работу популярных читалок (JAWS, NVDA и VoiceOver) и браузеров (Chrome, FF, Safari), потому что они хорошо работают друг с другом, поддерживают много технологий и регулярно обновляются.

Далее заполняется таблица с критериями и с указывается информация об их достижении.

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

Источник