Comments 36
Меня просто убивают кнопки типа сделать хорошо для тех, кто плохо видит. В 40 лет у меня зрение подсело и я предпочитаю иногда выкрутить ручку масштаба, чтобы шрифт стал читаемого для меня размера. Очень радуюсь, когда пропадают бессмысленные блоки слева и справа. Но когда нажимаешь на кнопку для плохо видящих начинается какая-то дичь. Сайт просто невозможно читать. В лучшем случае просто пропадает цвет и текст становится контрастным. Это мне не мешает. Но часто там такая вёрстка…
Моё мнение. Этим должны заниматься браузеры. А требования должны предъявляться к разработчикам, чтобы их дизайн без проблем отображался в соответствующих режимах браузера.
Выбор не между красиво и юзабельно, а между правильно (по стандартам W3C и проч.) и «у меня все работает, значит ОК». Правильно сделанный макет если и требует доработки под WCAG, то обычно минимальной. Лобовов пример — табличная верстка, которая проще и удобнее блоковой (для верстальщика), но неправильная и «на дистанции» вызывает больше проблем, чем решает.
А под рекомендацией не стремиться всегда к ААА, WCAG понимает, что это не всегда оправдано и даже не всегда возможно. Скажем, на сайте выложены разные исполнения Шестой симфонии Малера. Грубо говоря, кровень А требует объяснения, почему тут 20 разных файлов с одной симфонией. Уровень ААА — донести до глухого всю разницу между ними, хотя смысл этой затеи на современном этапе развития технологий — околонулевой: всего объема информации, что передается звуком, другими средствами передать не получится.
А так да, если заведомо не думать про WCAG, естественно будет сайт не оптимизированный для скринридеров. Здесь разногласий у нас с вами нет.
Но если думать про WCAG, то можно реализовывать требования разными путями и сделать основной интерфейс доступным может быть не самой лучшей идеей, например соблюдение требований к контрастности может помешать правильно расставить цветовые акценты в интерфейсе (неважное сделать малоконтрастным) и т.д.
Я считаю, что оптимизация основного интерфейса для WCAG имеет свои пределы, можно до какой-то степени улучшать интерфейс, но в какой-то момент надо остановиться, чтобы его не портить для здоровых потребителей.
Альтернатива — специально-оптимизированный интерфейс, без всего лишнего. Но его сложно делать и поддерживать в актуальном состоянии, этим будут заниматься только отдельные создатели продаваемого ПО и это не массовая история.
А массовая — это включил плагин в Битриксе и вот у тебя типа доступный режим появился.
Flexbox до сих пор CR, а не Rec, поэтому лично для меня не существует. А насчет табличной верстки… и не такое видал в 2020 ;)
А про свои настройки — я могу только сказать что в современных динамичных интерфейсах это все работать не будет ибо не мешать — это не задавать (оставить по-умолчанию), чтобы пользовательские стили переопределили.
На такое никто не готов.
Если пользователю таки надо что-то переписать из стилей — пусть плагин использует, которые в уже готовую страницу свои стили инжектирует.
Вон: codereview.chromium.org/66383005
И вон: www.opennet.ru/opennews/art.shtml?num=50743
Как раз то, о чем писал, что такие цвета из user agent stylesheet не катят и дизайнеры их переопределят.
support.mozilla.org/ru/kb/izmenenie-shriftov-i-cvetov-ispolzuemyh-veb-sajtam
Не поясните какой неправильно переведённый термин стал основанием для упомянутого решения суда?
Ок, скажу более резко, раз вы встаёте в такую позицию: ваша статья состоит из бессмысленных придирок к "трудностям перевода", спекуляций и кликбейта.
В данном случае, это не продолжение перечисления, а другой вариант, т.е. дословно так: ввод указателем — устройство ввода, которое может быть нацелено на определенные координаты (или набор координат) на экране, такое как «мышь» или стилус, либо касательный контакт. Дальше уже вопрос литературности перевода без потери изначального смысла.
Но как не переводи, никакого «активного указателя» в оригинале нет, это из другой оперы; координаты указываются (задаются), а не направляются на них, в том числе — путем прикосновения частью тела пользователя (пальцем), а не «устройством палец пользователя» ;)
Под определением pointer input есть ссылка на документ Pointer events. В его введении еще раз это описано, где уже однозначно пунктуация относит тач к перечислению (цитата ниже) и «рисунок 1» это еще раз подтверждает:
A pointer can be any point of contact on the screen made by a mouse cursor, pen, touch (including multi-touch), or other pointing input device.
Впрочем, о чем мы спорим? Что палец — это не устройство? Или что pointer input это ни секунды не «активный указатель» и не «устройство ввода»?
Time-based media is content that is determined by time. For example, audio or video. But it could also be a presentation (eg. Power Point) that has timings set. Not time-based media would be something like an image without animations (eg. not an animated GIF).
Такое пояснение к этому термину дали авторы WCAG в переписке. Так что да, игру можно назвать «динамичным медиа-контентом». Другой вопрос, может ли она в принципе соответствовать WCAG и можно ли целую игру рассматривать как единый медиа-контент в рамках WCAG…
В общем, time-based media — это контент, который, по задумке автора, технически не может быть представлен одномоментно без изменения смысла/восприятия: аудио, видео, интерактив, анимированный GIF, презентация с заданной сменой слайдов и т.п. Т.е. мы можем разложить, скажем, видеоролик на составные кадры и показать их все сразу (раскадровку), но тогда теряется смысл/задумка. Еще веселее с аудио: сразу — в виде спектрограммы или нот — это уже не то.
Если есть свежии идеи, как это можно обозвать по-русски — добро пожаловать!
Почему российские сайты не будут соответствовать ГОСТу по доступности