Вы правы в том, что отличная доступность сайта — это прежде всего качественная реализация «под капотом», а не наличие красивого заявления. Фундаментально, сайт может быть полностью доступен и без этого документа.
Однако наличие заявления о доступности — это гораздо больше, чем просто галочка в чек-листе. Это мощный коммуникационный инструмент, который работает в нескольких плоскостях:
Сигнал о приоритетах. Для пользователей это явный маркер того, что команда держит вопрос инклюзивности в фокусе. Сам факт его наличия формирует доверие и демонстрирует зрелый подход к разработке.
Окно прозрачности. В заявлении можно четко обозначить:
Стандарты: На какие руководства (WCAG, ГОСТ) ориентируется команда.
Инструменты: Какие технологии и методы используются для обеспечения и тестирования доступности.
Ограничения: Это ключевой момент — честно указать известные проблемы, над которыми ведется работа, и временные ограничения.
Канал для диалога. Самый важный аспект — это предоставление прямого и понятного способа для обратной связи. Он превращает монолог в диалог, позволяя пользователям сообщать о проблемах и тем самым помогать вам делать продукт лучше.
Таким образом, заявление о доступности — это не про «должен» по правилам, а про «целесообразно» для построения доверительных и открытых отношений со всеми пользователями без исключения.
Проанализировал ваш сайт. Проблем действительно много, вот то, что бросается в глаза в первую очередь, особенно для мобильных устройств.
Ошибки доступности (прошел бегло)
Картинки без альтернативных текстов. Если изображения декоративные (что скорее всего), обязательно проставьте им role="presentation" или aria-hidden="true". Это очистит дерево доступности для скринридеров.
Низкая контрастность. Цветовые пары #777 на белом, белый на #f44 и белый на #46a0ea не соответствуют рекомендуемому уровню WCAG AA. Соотношение контраста недостаточное для комфортного чтения многими пользователями.
Непонятные ссылки в каталоге. Элементы special-product__href — это ссылки без текстового содержимого, растянутые на всю карточку товара. Это критическая проблема. Скринридер озвучит это просто как «ссылка», не давая пользователю ни малейшего представления о том, на какой товар она ведет.
Заблокированный зуминг. В метатеге viewport установлены maximum-scale=1.0, user-scalable=no, что лишает пользователей возможности приблизить контент для чтения. Это нарушает базовые принципы доступности.
Проблемы мобильного UX и дизайна
Проблемы с доступностью тесно переплетены с общим устаревшим пользовательским опытом.
Отсутствие УТП на главной. При входе на сайт нет приветственного баннера, который бы сразу показывал вашу ценность: лого, слоган, ключевые преимущества (сертификаты, качество, доставка, опыт на рынке). Сейчас пользователь сразу проваливается в каталог, не понимая, куда попал.
Неудобное гамбургер-меню.
Контент под меню не затемняется, создавая визуальный шум.
Меню схлопывается только кнопкой, а не по тапу на затемненную область, что не соответствует современным поведенческим паттернам.
Некорректные «хлебные крошки». Элементы наезжают друг на друга, что говорит о проблемах в верстке.
Рекомендация
Вам не хватает системного подхода. Проблемы кроются не только в верстке, но и в дизайне. Настоятельно рекомендую привлечь дизайнера-фрилансера (достаточно уровня middle) на part-time, чтобы он переработал UI, особенно мобильные шаблоны. Это решит большую часть проблем с UX и заложит основу для технических правок по доступности.
Текущий UI vs UI переработанный ИИ с УТП но на тех же визуальных шаблонах, как пример
Отсутствие заявления ≠ отсутствие обязанностей. Доступность (a11y) - это не «функционал», как, например, ночной режим. Это - базовое требование к веб-интерфейсу, обеспечивающее равный доступ к услугам. Во многих странах это закреплено на законодательном уровне (например, ADA в США, Директива EU 2016/2102 в Европе). Банковские услуги - это критически важная часть жизни, и лишать их доступа целые группы населения - это дискриминация.
Цель аудита. Я проверял не «наличие заявления», а соответствие интерфейса общепринятым стандартам (WCAG). Это такие же стандарты, как и для безопасности или кроссбраузерности. Мой анализ показывает, где именно интерфейс не соответствует этим техническим нормативам, создавая барьеры для реальных людей.
Про холестерин и пептиды. Это ложная аналогия. Доступность - это не абстрактный «химический состав», а измеримая характеристика юзабилити. Проверять на контрастность или семантическую разметку — это так же логично, как проверять скорость загрузки сайта. И то, и другое напрямую влияет на пользовательский опыт.
О «бесполезности». Задача такого аудита - не подать жалобу, а показать проблему и пути ее решения. Многие компании просто не осознают масштабов несоответствия, пока им его не продемонстрируют. Этот материал — руководство к действию для самих разработчиков Приорбанка и других компаний, которые хотят улучшить свой продукт.
Ваше предложение о работе через ассоциации - верное, но оно не отменяет ценности технического анализа. Профессиональное сообщество (разработчики, дизайнеры) - это как раз тот канал, через который можно донести проблемы и решения напрямую, без долгих бюрократических процедур.
Есть еще один интересный кейс, когда идет комбинация ::before с content:'' и ::first-letter. Как ни странно, Firefox считает '' буквой))) и он такой опять же единственный.
Подробнее описал тут. Может автор статьи этот кейс тоже подсветит в UPD
Смотря какая логика. Формальная логика это раздел философии, исчисление предикатов или булева алгебра это к математике. Я бы так однозначно не классифицировал логику :)
В пирамиде и в заголовке есть аббревиатура DDD, однако она нигде не расшифровывается и никак не упомянается. Зачем вы так обижаете Эрика Эванса и Domain-Driven-Design? :)
Статья Джейка хороша, все верно, у каждого браузера свой js-движок, и реализация event loop своя, тут же речь о платформе Node.js, т.е. это не про браузеры, а про серверную js-технология. Она использует V8 (js-движок, тот же, что и в Chrome) и libuv для организации event loop и работы с файлами, сокетами, сетью, ОС и т.е.
К примеру, функций setImmediate (разве что нестандартизированная в FF) и process.nextTick в брузерах не найти, они характерны только Node.js платформе и ее событийному циклу.
libuv используется не только в node.js, есть и другие платформы.
Полезно ли знать это или нет — решать вам, решать каждому, я считаю, что полезно, затем и опубликовал заметку.
А про абстракции, это, как я понял, отсылка к Джоелю Спольскому. И он, как раз в рассуждениях на этот счет, пример приводит с тем, что не достаточно нанять программиста, который знает только Visual Basic, К&Р тоже может понадобиться. Аналогия с libuv и node.js вполне себе.
И тем не менее, когда у вас сломаются часы, вы пойдете к этому старику. Я восторгаюсь и снимаю шляпу перед людьми, которые посвятили жизнь одному ремеслу. Да, они не универсальные солдаты, но настоящие профи и эксперты своего дела. Будь то плотник, кузнец или часовщик…
Поддерживаю ответ Fen1kz
До кучи, этот вопрос, как правило, идет следующим после вопроса о микро и макро задачах, которые как раз js-прикладник и использует в повседневной жизни.
Т.е. из разряда: «Чей обратный вызов сработает раньше setTimeout или setImmediate? Когда стоит применить то, а когда это?»
Или тот же вопрос, но с примером кода, где вы увидите лесенку асинхронных вложенностей из process.nextTick и setTimeout.
Странно, что страйки многопоточности до сих пор летят в сторону JavaScript. В чисто виде, конечно же, таких механизмов в языке нет, но в браузере вы всегда сможете найти Web Workers, а в Node.js многопроцессорность с IPC и child_process. И это все, если очень хочется. Однако не надо забывать, что каждый «молоток» для своих «гвоздей».
«Компьютер — это конечный автомат. Потоковое программирование нужно тем, кто не умеет программировать конечные автоматы»
Алана Кокс, один из ведущих разработчиков ядра Linux
Вы правы в том, что отличная доступность сайта — это прежде всего качественная реализация «под капотом», а не наличие красивого заявления. Фундаментально, сайт может быть полностью доступен и без этого документа.
Однако наличие заявления о доступности — это гораздо больше, чем просто галочка в чек-листе. Это мощный коммуникационный инструмент, который работает в нескольких плоскостях:
Сигнал о приоритетах. Для пользователей это явный маркер того, что команда держит вопрос инклюзивности в фокусе. Сам факт его наличия формирует доверие и демонстрирует зрелый подход к разработке.
Окно прозрачности. В заявлении можно четко обозначить:
Стандарты: На какие руководства (WCAG, ГОСТ) ориентируется команда.
Инструменты: Какие технологии и методы используются для обеспечения и тестирования доступности.
Ограничения: Это ключевой момент — честно указать известные проблемы, над которыми ведется работа, и временные ограничения.
Канал для диалога. Самый важный аспект — это предоставление прямого и понятного способа для обратной связи. Он превращает монолог в диалог, позволяя пользователям сообщать о проблемах и тем самым помогать вам делать продукт лучше.
Таким образом, заявление о доступности — это не про «должен» по правилам, а про «целесообразно» для построения доверительных и открытых отношений со всеми пользователями без исключения.
Проанализировал ваш сайт. Проблем действительно много, вот то, что бросается в глаза в первую очередь, особенно для мобильных устройств.
Ошибки доступности (прошел бегло)
Картинки без альтернативных текстов. Если изображения декоративные (что скорее всего), обязательно проставьте им
role="presentation"илиaria-hidden="true". Это очистит дерево доступности для скринридеров.Низкая контрастность. Цветовые пары
#777на белом, белый на#f44и белый на#46a0eaне соответствуют рекомендуемому уровню WCAG AA. Соотношение контраста недостаточное для комфортного чтения многими пользователями.Непонятные ссылки в каталоге. Элементы
special-product__href— это ссылки без текстового содержимого, растянутые на всю карточку товара. Это критическая проблема. Скринридер озвучит это просто как «ссылка», не давая пользователю ни малейшего представления о том, на какой товар она ведет.Заблокированный зуминг. В метатеге viewport установлены
maximum-scale=1.0, user-scalable=no, что лишает пользователей возможности приблизить контент для чтения. Это нарушает базовые принципы доступности.Проблемы мобильного UX и дизайна
Проблемы с доступностью тесно переплетены с общим устаревшим пользовательским опытом.
Отсутствие УТП на главной. При входе на сайт нет приветственного баннера, который бы сразу показывал вашу ценность: лого, слоган, ключевые преимущества (сертификаты, качество, доставка, опыт на рынке). Сейчас пользователь сразу проваливается в каталог, не понимая, куда попал.
Неудобное гамбургер-меню.
Контент под меню не затемняется, создавая визуальный шум.
Меню схлопывается только кнопкой, а не по тапу на затемненную область, что не соответствует современным поведенческим паттернам.
Некорректные «хлебные крошки». Элементы наезжают друг на друга, что говорит о проблемах в верстке.
Рекомендация
Вам не хватает системного подхода. Проблемы кроются не только в верстке, но и в дизайне. Настоятельно рекомендую привлечь дизайнера-фрилансера (достаточно уровня middle) на part-time, чтобы он переработал UI, особенно мобильные шаблоны. Это решит большую часть проблем с UX и заложит основу для технических правок по доступности.
Отсутствие заявления ≠ отсутствие обязанностей. Доступность (a11y) - это не «функционал», как, например, ночной режим. Это - базовое требование к веб-интерфейсу, обеспечивающее равный доступ к услугам. Во многих странах это закреплено на законодательном уровне (например, ADA в США, Директива EU 2016/2102 в Европе). Банковские услуги - это критически важная часть жизни, и лишать их доступа целые группы населения - это дискриминация.
Цель аудита. Я проверял не «наличие заявления», а соответствие интерфейса общепринятым стандартам (WCAG). Это такие же стандарты, как и для безопасности или кроссбраузерности. Мой анализ показывает, где именно интерфейс не соответствует этим техническим нормативам, создавая барьеры для реальных людей.
Про холестерин и пептиды. Это ложная аналогия. Доступность - это не абстрактный «химический состав», а измеримая характеристика юзабилити. Проверять на контрастность или семантическую разметку — это так же логично, как проверять скорость загрузки сайта. И то, и другое напрямую влияет на пользовательский опыт.
О «бесполезности». Задача такого аудита - не подать жалобу, а показать проблему и пути ее решения. Многие компании просто не осознают масштабов несоответствия, пока им его не продемонстрируют. Этот материал — руководство к действию для самих разработчиков Приорбанка и других компаний, которые хотят улучшить свой продукт.
Ваше предложение о работе через ассоциации - верное, но оно не отменяет ценности технического анализа. Профессиональное сообщество (разработчики, дизайнеры) - это как раз тот канал, через который можно донести проблемы и решения напрямую, без долгих бюрократических процедур.
Подробнее описал тут. Может автор статьи этот кейс тоже подсветит в UPD
"которые позволяют сделать эти вещи сделать"
"Это де прекрасно!" — же
К примеру, функций setImmediate (разве что нестандартизированная в FF) и process.nextTick в брузерах не найти, они характерны только Node.js платформе и ее событийному циклу.
libuv используется не только в node.js, есть и другие платформы.
Полезно ли знать это или нет — решать вам, решать каждому, я считаю, что полезно, затем и опубликовал заметку.
До кучи, этот вопрос, как правило, идет следующим после вопроса о микро и макро задачах, которые как раз js-прикладник и использует в повседневной жизни.
Т.е. из разряда: «Чей обратный вызов сработает раньше setTimeout или setImmediate? Когда стоит применить то, а когда это?»
Или тот же вопрос, но с примером кода, где вы увидите лесенку асинхронных вложенностей из process.nextTick и setTimeout.