Комментарии 36
НЛО прилетело и опубликовало эту надпись здесь
Гайд WCAG перевели на русский язык и утвердили законодательно?
НЛО прилетело и опубликовало эту надпись здесь
Стандарт разве делает что-то обязательным? Обязывает закон или договор в целом.
Кому пришла в голову публиковать документы в картинках? Надеюсь, что формат публикации документов на сайте Федерального Агенства, тоже приведут в соответствии с этим ГОСТом.
4.1.1 Положение 1.1 Текстовая версия
Необходимо предоставить текстовую версию любого нетекстового контента так, чтобы ее можно было преобразовать в другие формы, необходимые пользователям, например увеличенный шрифт, шрифт Брайля, речь...
НЛО прилетело и опубликовало эту надпись здесь
Если публиковать ГОСТ в виде текста, его могуть украсть на другие сайты.
Не надейтесь. Помнится, в ГОСТе, который требовал, чтобы математические константы в нормативных документа (например ГОСТах), обозначались НЕ курсивом, в следующей же фразе "например e, π, i"(цитирую по памяти).
выпущен ГОСТ, предъявляющий требования к интернет-контенту и сам же не выполняющий данные требования. Всё по канонам
Получается если сайт не работает без скриптов его автора можно будет привлечь к ответственности?
Судя по всему — нет. Должен быть закон делающий использование стандарта обязательным для тех или иных видов деятельности. Или хотя бы подзаконный акт, типа постановления Правительства или того же Роскомнадзора, если уже есть закон, наделяющих им полномочиями делать вводить обязательные требования для всех субъектов
НЛО прилетело и опубликовало эту надпись здесь
Нужно дополнение к браузеру чтобы автоматизировать процесс отправки жалобы.
Даже если так, если любой сайт без версии для слабовидящих незаконен (кстати, а с полностью невидящими что? должен ли любой сайт иметь аудио-версию? А со слепоглухонемыми — что? Или некоторая дискриминация позволительна), то из этого никак не следует что он должен соответствовать обсуждаемому стандарту.
Да с чего вы берете, что нужны какие-то специальные сайты. Или тем более аудио версии сайтов. Ничего отдельного не надо. Незрячие люди пользуются теми же сайтами, что и зрячие с помощью программ экранного доступа. Просто сайты надо разрабатывать по стандарту, как положено, используя теги HTML по назначению. Например, если вы хотите добавить кнопку на сайт, пускай даже по дизайну без текстовой надписи, а только с иконкой. Тогда просто надо не использовать тег div, а затем на нее вешать JavaScript обработчик, а использовать тег button и назначить ему текстовую метку, которую визуально видно не будет, но скринридеры ее подхватят и озвучат.
Ну и со всем прочим также. Для начала можно почитать что-то типа такого: HTML: Хорошая основа для доступности
Так что если какие-то разработчики сделали недоступный сайт, это не значит, что они должны еще сделать специальную версию. Это означает, что они сделали плохую, не качественную верстку.
Сколько эта тема мусолиться, а всегда всплывает один и тот же вопрос: почему бизнес должен создавать специальные версии. Та не должен, просто надо создавать качественную версию сайта, одну для всех.
Ну и со всем прочим также. Для начала можно почитать что-то типа такого: HTML: Хорошая основа для доступности
Так что если какие-то разработчики сделали недоступный сайт, это не значит, что они должны еще сделать специальную версию. Это означает, что они сделали плохую, не качественную верстку.
Сколько эта тема мусолиться, а всегда всплывает один и тот же вопрос: почему бизнес должен создавать специальные версии. Та не должен, просто надо создавать качественную версию сайта, одну для всех.
Но ведь тогда значительная часть «фронтэндеров» вынуждена будет покупать еду в магазинах просрочки. Чем занять этих «специалистов»?
НЛО прилетело и опубликовало эту надпись здесь
Платить больше за вёрстку по стандартам рыцарям в штате. И заказывать аудит работ веб-студий у профессионалов.
НЛО прилетело и опубликовало эту надпись здесь
В такой ситуации я бы обратился к экспертам по доступности поневоле — в какое-нибудь общество людей с особыми потребностями. На хабре точно несколько статей было технических от таких авторов — попробовал бы с ними договориться о, например, отборе исполнителеей и/или периодическом аудите.
НЛО прилетело и опубликовало эту надпись здесь
Насчет организаций я бы не был так уверен. Не знаю как в России, а в Украине общество УТОС — это полный мрак. Никто из молодых и действительно разбирающихся практически не бывает там. Они не хотят сидеть в тех организациях, они хотят работать, развиваться и жить как все. Вот только крайне трудно найти работу им. Обычно компании не хотят связываться с незрячими, хотя они также могут не только тестировать, но и писать код вполне также, и backend и frontend. Надеюсь эта тенденция все же будет меняться. А так да, их можно встретить и на хабре, и на других ресурсах.
> Как мне определить, может ли исполнитель верстать по стандартам?
Можно дать ему тестовое задание или попросить пример работы по предыдущим проектам и проверить страницу автоматическим валидатором доступности, типа Axe.
Несмотря на то, что автоматизированные валидаторы доступности не могут полностью заменить ручное тестирование, они позволяют увидеть базовые ошибки.
Тут же можно попросить исполнителя прокомментировать отчёт автоматического валидатора и по общему впечатлению оценить, насколько он плавает или не плавает в теме.
> Как мне определить аудитора, который нормально проверит работу верстальщика?
Реальная проблема контроля качества возникает в основном только в отношении доступности, основанной на альтернативном способе восприятия, то есть невизуальная работа с визуальным интерфейсом. Проще говоря, доступность для слепых. Для зрячего это контринтуитивная история, поэтому тут нужны специальные знания и навыки.
Контрастность, размер текста, клавиатурную навигацию и пр. вы сможете примерно оценить сами, проглядев базовые критерии в стандарте. Да и многие вещи из этого уже заложены в общее понимание хороших интерфейсов, которые часто есть на интуитивном уровне, например, нежелательность жёлтого текста на белом фоне, что понятно на глаз без расчёта конкретного коэффициента контрастности.
Как минимум, аудитор должен уметь работать с технологиями на пользовательском уровне. Причём, не с какой-то одной, а со всеми основными. Кстати, очень вредно, когда веб-доступность разработчики тут же проверяют на своей macOS, потому что подавляющая часть аудитории будет на Windows.
У нас сейчас доступность — это очень хайповая тема на конференциях. Появилась куча самопровозглашённых экспертов.
Очень простой тест: кладёте на стол 5000 руб., и предлагаете такому эксперту сделать тоже самое.
Далее запускаете на компьютере браузер, программу экранного доступа и завязываете эксперту глаза, после чего засекаете 5 минут, за которые он должен, например, заказать на сайте пиццу.
Если он справится или же обосновано объяснит, что за 5 минут не удалось найти доступный Интернет-магазин, то он забирает 10000 руб., если же он просто эти 5 минут будет слепо тыкаться по странице поисковика и даже не сможет найти нужный сайт, то 10000 руб. забираете вы.
Большая часть экспертов по доступности со всяких конференций при оглашении таких условий пари сразу сливаются, хотя перед этим с умным видом поучали всех, как работает весь этот стек технологий. Да и с оставшейся частью вы, скорей всего, по деньгам останетесь в плюсе.
Вторая линия — это не просто способность на базовом уровне работать со вспомогательной технологией, но и понимать, в чём именно проблема, а также знать все стратегии, которые используются пользователями с ограниченными возможностями.
Тут уже обратная история, когда можно попасть, например, на обычного незрячего человека, который уже по факту своей инвалидности считает себя экспертом. Причём, часто чем меньше компетенций, тем больше гонора, часто с рекомендациями, завязанными на очень спорный субъективный опыт. Попытки взаимодействовать с общественными организациями инвалидов и различными НКО обычно приводят именно к такому.
В действительности, есть несколько подходов к взаимодействию с веб-интерфейсом, и при экспертизе нужно учитывать их все, равно как и специфику разных конфигураций ПО, так как сочетания разных браузеров и вспомогательных технологий имеют свои нюансы. Любимых браузеров или программ экранного доступа в этих вопросах быть не должно.
Кроме того, отзыв «а тут я не смог» мало полезен. От Аудитора всё-таки желательно получать хотя бы примерную техническую рекомендацию. Без способности её предоставить он замедлит и усложнит весь процесс обеспечения доступности.
По большому счёту, если надо сделать хорошо, то нужен не чисто аудитор, а консультант по технологиям, который курирует и контролирует процесс разработки, итеративно тестируя результат и объясняя разработчику, где он не дотянул. Консультант по технологиям также сможет придумать и предложить какие-то обходные пути или компромиссы, когда ситуация сложная.
Если у кого-то есть реальный интерес и конкретная потребность с перспективой внедрения, то я готов пообщаться на тему аудита доступности для программ экранного доступа, в том числе для проектов, которые мне покажутся социально значимыми, и чисто на общественных началах.
> И правда ли, что несмотря на то, что сообществу программистов-фронтендеров, начиная с гугла и мозиллы, глубоко пофиг на эти стандарты, и они их соблюдают только там, где им выгодно, есть отличный от нуля шанс найти рыцаря кода и разметки, а не костылей и велосипедов?
Да, такие люди встречаются, но чаще это происходит, когда уже в большом проекте сытый разработчик, ощущающий стабильность своего положения, начинает интересоваться дополнительными вещами и погружается в тему доступности из любви к технологиям или от скуки.
Также есть компании, ориентированные на разработку доступных интерфейсов, например, из-за работы на образовательный или государственный сектор стран, где есть достаточно жёсткие нормы в этом отношении. Внутри таких компаний разработчики просто привыкают учитывать какие-то вещи хотя бы на базовом уровне.
Ну а заказывая вёрстку за сотню долларов где-нибудь по-быстрому на фрилансерской потогонке, вряд ли стоит рассчитывать, что вам попадётся такой разработчик.
Вёрстка на div'ах — это ведь прямое следствие быстрого входа в профессию. Люди узнают основы и уже начинают верстать, в том числе устраиваясь на работу. Добившись первых заработков или полноценного трудоустройства, многие просто уже не доходят в своём образовании до полного понимания концепций семантичности веб-интерфейсов, потому что формально уже пришли к успеху и дальнейшее изучение представляется чем-то излишним.
Впрочем, кнопка на div тоже может быть доступной:
<div tabindex="0" role="button" aria-label="Название"></div>
Но вот это как раз уже и требует специальных знаний, которые правда описываются не в WCAG, а в WAI-ARIA. Да и в любом случае до такого лучше не доводить. Это обычно когда мы чиним доступность интерфейса, боясь чихнуть в структуре вёрстке, чтобы ничего не поломать.
В действительности правильная вёрстка в подавляющем большинстве случаев доступна уже из коробки. Соответственно у грамотного верстальщика доступность во многом должна выходить автоматически, а значит никак и не удорожать процесс. Это также, как написать «молоко» или «малако»: усилия одни и те же, просто одно правильно, а другое нет. Вот только с копирайтерами, которые пишут «малако», никто не хочет работать, а верстальщиков на div'ах берут даже крупные компании.
Поэтому давайте выпьем за то, чтобы мы все дожили до тех времён, когда делать кнопку через div будет также стыдно, как сейчас написать «малако»!
Через несколько дней будет GAAD, так что это хороший повод начать со своих собственных проектов.
Согласен с вами. И если рассматривать откуда их брать, чисто мое мнение, у всех студий таких должен быть опытный в этом деле один или несколько человек, которые будут через обучение и контроль их работ пропускать juniorов перед тем как доверять им самостоятельную разработку. А то возьмут таких «специалистов», что наговнокодят дивами, повешают им планки senjor, а потом те по всем компаниям разносят свой «опыт». Ну то конечно так, всего лишь мое мнение, наверняка найдутся и те, кто будет утверждать работает и хорошо, бизнесу надо быстрее, а то что потом такое подделие будет дороже и труднее поддерживать и развивать никто не думает.
Стандарт явно ориентирован на использование основных средств доступа типа браузера — очень многие требования явно содержать визуальную часть: контрастность, размеры шрифтов, строк, расстояния и т. п., предоставление альтернатив владкльцем ресурса и т. д.
И нужно расделять две задачи, которые заказчик может поставить перед разработчиком:
- минимальными средствами (семантическая вёрстка, aria аттрибуты и т. п.) повысить доступность без влияния на основную идею и функциональность
- сделать ресурс соответствующим обсуждаемому стандарту или его аналогам в, например, США или ЕС
И если первую задачу ответственный разработчик может поставить себе сам, делая некоторые вещи даже на автомате, то вторая — это, обычно, совсем другой уровень принятия решений. Разработчик может быть даже уволен по профнепригодности, если решит вторую по собственной инициативе просто потому, что результат не будет соответствовать дизайн-макету.
Да, но если сделать первый вариант, по минимуму, но как положено — это уже сделает сайт если не на 100%, то наверное процентов на 70-80 доступным. Повторюсь еще раз, когда сайт полностью недоступен — это очень плохая некачественная верстка, так как даже при минимуме усилий, но правильной верстке большинство становится доступным сразу прямо из коробки, что собственно незрячие и пытаются всегда доносить, что им не нужны специальные версии, просто надо писать более качественный код.
Скорее всего будет требование для гос-ресурсов, наподобие того что есть во многих странах.
Скрипты тут не причем: есть длинная портянка рекомендаций, которым надо удовлетворять.
Скрипты никто не банит, а вот хитрые манипуляции с контентом, не позволяющие пользоваться assistive technology придётся переделать.
Скрипты тут не причем: есть длинная портянка рекомендаций, которым надо удовлетворять.
Скрипты никто не банит, а вот хитрые манипуляции с контентом, не позволяющие пользоваться assistive technology придётся переделать.
Полагаю в процессе изготовления такого сайта неожиданно окажется не нужным такое количество стилей и бесполезных скриптов. Сейчас огромное количество страниц которые просто разваливаются если отключить js, а так быть не должно. Каждый сайт это прежде всего текст и картинки. Безусловно есть исключения. Допустим карты на чистом html это проблема. Но большинство сайтов должно работать без стилей и js.
Пробежался по стандарту — ничего про скрипты не говорит. Более того, на первый взгляд скриптов должно стать больше, чтобы обеспечить выполнение требовани стандарта.
WCAG — штука полезная, но может легко увеличить стоимость разработки раз в 10, увы
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Вступил в силу новый ГОСТ для цифровых ресурсов: все платформы должны быть доступны для инвалидов