WCAG против мнения реальных пользователей

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

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

  • Интерфейс переключателя стилей на основе JavaScript. Например. для переключения между цветовыми схемами «черный на белом» и «белое на черном».
  • Альтернативные таблицы стилей. Та же цель, что и JS-переключатель, но другая реализация.
  • Высококонтрастная граница CSS вокруг всех кнопок. (Недостаточно высококонтрастного цвета фона.)
  • Не позволяйте DOM обновляться без вмешательства пользователя (например, из-за удаленного события), даже с aria-live="polite".
  • Никаких цветов фона CSS нигде. (Шутки в сторону.)

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

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

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

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

Можно ли полагаться на WCAG как на правильный и полный контрольный список для веб-доступности? Если да, есть ли у вас какие-либо мысли о том, как это можно согласовать с комментариями пользователей, и какой ответ может быть подходящим, когда они запрашивают такие методы?

Редактировать на основе беседы с Драйденом Лонгом

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


web html css accessibility wcag
person rlkw1024    schedule 28.01.2014    source источник
comment
Проблема с попыткой создать стандарт чего-то вроде доступности состоит в том, что нет двух абсолютно одинаковых видов инвалидности. Существуют разные степени инвалидности, которые различаются от человека к человеку и требуют соблюдения разных наборов правил, что делает невозможным достижение глобального стандарта. Я предлагаю использовать WCAG в качестве основы и внедрять дополнительные правила по вашему усмотрению. Можно ли полагаться на WCAG как на правильный контрольный список? да. Можно ли полагаться на него как на полный контрольный список? Точно нет.   -  person Dryden Long    schedule 29.01.2014
comment
Я согласен с тем, что инвалидность чрезвычайно разнообразна. Тем не менее WCAG утверждает принимает этот факт во внимание. WCAG не предполагает, что ваш сайт будет работать без каких-либо ограничений для любой инвалидности. Скорее, предполагается, что у пользователей будут вспомогательные технологии, соответствующие их потребностям. Таким образом, WCAG нацелен на обеспечение совместимости сайтов с соответствующими стандартами вспомогательными технологиями.   -  person rlkw1024    schedule 29.01.2014
comment
Кроме того, если WCAG неполный, что делать веб-разработчику? Я знаю некоторых людей с ограниченными возможностями, но нет оснований полагать, что я знаю репрезентативную выборку. Так должен ли я просто применять домашние техники тех, кого я знаю? Это кажется довольно произвольным. Если основанный на исследованиях орган, созданный экспертами, такой как WCAG, не может быть полным, ни у одного отдельного разработчика нет даже отдаленного шанса реализовать полное решение для обеспечения доступности.   -  person rlkw1024    schedule 29.01.2014
comment
Они принимают это во внимание, но это не значит, что они могут создать стандарт, применимый к каждому человеку с ограниченными возможностями. Проблема не в WCAG или вспомогательных технологиях, а скорее в идее создания стандарта. Ни одна организация не может предвидеть потребности каждого человека, когда дело доходит до вспомогательных технологий, это просто невозможно, и вы правы, у вас нет ни малейшего шанса реализовать полное решение для обеспечения доступности.   -  person Dryden Long    schedule 29.01.2014
comment
Однако вы можете создать как можно более надежное решение. Часть ответственности за разработку доступных веб-страниц заключается в постоянном обновлении и внедрении новых технологий. Используйте то, что вы знаете, и то, что считаете полезным. Если вы столкнетесь с новыми методами, примените и их. Цель состоит в том, чтобы постоянно развивать то, что вы предлагаете, с точки зрения доступности. Это никогда не будет% 100, но вы можете хотя бы подойти как можно ближе.   -  person Dryden Long    schedule 29.01.2014
comment
Что вам также нужно помнить, так это то, что на WCAG приходится большинство людей с ограниченными возможностями. это означает, что, следуя установленным ими стандартам, вы так или иначе приспособите большинство посетителей своей страницы. К сожалению, всегда будут те, чья инвалидность настолько уникальна, что они не подпадают под стандарты. Здесь вы должны по своему усмотрению решить, какие дополнительные параметры доступности вам нужно включить.   -  person Dryden Long    schedule 29.01.2014
comment
Я согласен со всем, что вы сказали. В конечном итоге меня больше всего беспокоит то, что веб-разработчики, похоже, могут самостоятельно изобретать велосипед. То есть, при отсутствии разумно полного стандарта, ожидается, что каждый разработчик независимо проведет эмпирическое исследование (потенциально затратное кучу денег) и разовьет свои собственные, идиосинкразические методы. Я ожидал, что в результате получится раздробленный ландшафт, где каждый сайт использует свои собственные методы доступности. Это было бы беспорядком как для веб-разработчиков, так и для авторов пользовательских агентов и вспомогательных технологий.   -  person rlkw1024    schedule 29.01.2014
comment
И это беспорядок, но это единственный доступный вариант. ИМО, WCAG является разумно полным стандартом или, по крайней мере, настолько близким к завершению, насколько это возможно. На данный момент я не совсем уверен, что вам сказать. Похоже, вы ожидаете некоего всеобъемлющего стандарта, который учитывает потребности каждого человека, что практически невозможно. Чтобы ответить на ваш исходный вопрос, не полагайтесь только на WCAG. Используйте его как основу и опирайтесь на его рекомендации с предложениями пользователей вашего сайта.   -  person Dryden Long    schedule 29.01.2014
comment
Нет, мне не нужно полностью законченное решение, подходящее для всех. Я понимаю, что это совершенно невозможно. Скорее, я хотел бы надеяться на максимально полный, насколько это практически возможно, стандарт, на который разработчик может положиться, не беспокоясь о том, что он / она создает неприемлемо доступный сайт.   -  person rlkw1024    schedule 29.01.2014
comment
Тогда это и есть WCAG, настолько полный, насколько это практически возможно.   -  person Dryden Long    schedule 29.01.2014
comment
Несколько замечательных комментариев Драйдена Лонга, которые я поддерживаю. Я хотел бы отметить, что совет WCAG - это компромисс. Инвалиды не согласны, как и все мы. Иногда то, что приносит пользу одному человеку, прямо противоречит тому, чего хочет другой. Например, посмотрите, как на странице Навигация по спискам : Быть или не быть Предпочтение Райнхарда Стебнера расходится с общепринятым мнением.   -  person Alohci    schedule 29.01.2014
comment
Во-вторых, отмечу, что авторы WCAG - реалисты. Они хотят поднять сеть, чтобы она была такой же хорошей для людей с ограниченными возможностями, как и для всех остальных, а не доводить сеть до наименьшего общего знаменателя. Так что они не собираются нигде предъявлять требования типа No CSS background colors. потому что это было бы слишком вредно для Интернета в целом.   -  person Alohci    schedule 29.01.2014
comment
Вы знаете, вы можете присоединиться к рабочей группе WCAG и вносить предложения, если чувствуете есть недостатки.   -  person steveax    schedule 30.01.2014

Ответы (2)


arrow_upward
14
arrow_downward

1. Недостатки WCAG 2.0

WCAG 2.0 великолепны. Они являются результатом работы прибл. 200 человек работали над ними в течение нескольких лет, в том числе большинство лучших экспертов по доступности Интернета, представители людей с ограниченными возможностями и т. Д. Они давно обсуждались для достижения консенсуса, отражающего взгляды различных заинтересованных сторон (так что, скажем, доступный контент может быть создан эффективным способом, не жертвуя эстетикой, не создавая большой нагрузки на браузеры и т. д.). Они синтезируют многолетние исследования и преодолевают многие ограничения старой версии WCAG 1.0. Они также получили вклад от сообщества помимо W3C, получая сотни (и даже тысячи) публичных комментариев каждый год через список рассылки публичных комментариев.

Тем не менее, сами WCAG 2.0 признают, что они несовершенны:

Обратите внимание, что даже контент, соответствующий наивысшему уровню (AAA), не будет доступен для людей со всеми типами, степенями или сочетаниями инвалидности, особенно в когнитивной, языковой и учебной областях. Авторам рекомендуется [...] обращаться за соответствующими советами о текущих передовых методах, чтобы обеспечить максимально возможный доступ к веб-контенту для этого сообщества.

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

2. Критерии успеха и методы

В результате этой работы над WCAG 2.0 было написано несколько десятков критериев успеха, которые устанавливают проверяемые требования, которым должен соответствовать доступный контент («доступный» здесь следует понимать как «соответствующее WCAG 2.0»). Эти критерии успеха являются основным, нормативным содержанием WCAG 2.0, не зависят от развития технологии и, следовательно, < сильный> довольно стабильный во времени.

Кроме того, существует несколько сотен методов для реализации этих критериев успеха. Методы зависят от технологии. Они зависят от конкретного типа контента (например, вы используете разные методы для предоставления альтернативного текста на HTML-странице и в PDF-документе), но также от развития браузеров и вспомогательных технологий и, что нет, от развития Интернета. сам дизайн.

Это означает несколько вещей:

  • Методики - это живой документ, они обновляются примерно раз в полтора года с момента утверждения WCAG 2.0. Подсказка: вы можете использовать методы для формы представления WCAG 2.0, чтобы внести свой вклад, если считаете, что полезный метод в настоящее время не рассматривается.
  • # P8 #
    # P9 #
    # P10 #
    # P11 #

Имеет смысл, что методы не являются нормативными, учитывая, что есть (возможно) другие способы достижения соответствия критериям успеха. Представьте себе, например, что пользовательские агенты (браузеры и вспомогательные технологии) начинают поддерживать описания изображений, встроенные в файлы изображений, используя IPTC IIM (модель обмена информацией Международного совета по телекоммуникациям и прессе) . Они вполне могут стать приемлемым способом удовлетворения критерия успеха 1.1.1, но не будут отражены (по крайней мере, на данный момент) ни в одной технике.

3. Соответствие и доступность в использовании

Тестирование с пользователями

Наличие стандартизированной рекомендации для проверки и использования - это здорово, поскольку она концентрирует знания отрасли в одном месте и обеспечивает общее согласие относительно того, что считается "доступным" (эй, для чего нужны стандарты). Однако вовлечение пользователей в оценку веб-доступности является ключом к обеспечению универсальной доступности. Это имеет смысл: как указано в других ответах, разные люди с широким спектром способностей могут иметь разные потребности, которые отражаются только на практике. Я бы добавил, что у разных веб-сайтов разные требования, которые не отражены в едином многоцелевом документе. Тем не менее, вы обычно не оцениваете свой сайт с людьми с ограниченными возможностями, если вы создаете, например, веб-страницу для своей соседской футбольной команды, но вы (в идеале) наверняка это сделаете, если вы разрабатываете веб-сайт Команда Премьер-лиги.

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

Барьеры и хитрости на практике

Люди с ограниченными возможностями привыкли работать с недоступными сайтами. Чем они технически сложнее, тем чаще они прибегают к «уловкам», чтобы получить доступ к другому недоступному содержимому: «Да, вам нужно нажать alt-space, а затем вниз, и меню выскочит», «если вы активируйте эту скрытую опцию в JAWS и активируйте виртуальный курсор, он будет читать поля на этой странице ». Менее технически подкованные пользователи, возможно, не знают такого рода уловок, но они выучивают некоторые уловки наизусть на сайтах, которые используют чаще всего: «Мне нужно набрать« k »дважды, чтобы выбрать King's Station».

Исследования показали, что результаты оценок людей с ограниченными возможностями неизменно превосходят результаты тестирования на соответствие. То есть пользователи преодолевают некоторые барьеры доступности, прибегая к этим «уловкам». Однако это не должно отвлекать внимание от соответствия. Многие люди не будут знать об этих трюках, и даже те, кто знает, будут сталкиваться с плохим юзабилити, будут тратить больше времени на выполнение своих задач и с большей вероятностью уйдут (или выберут сайт конкурента в следующий раз).

С другой стороны, некоторые методы полагаются на поддержку вспомогательных технологий, использование которых может потребовать опыта пользователя. Например, метод C22 касается использования CSS для управления визуальным представлением текста. Идея довольно проста (выделено жирным шрифтом):

Цель этого метода - продемонстрировать, как можно использовать CSS для управления визуальным представлением текста. Это позволит пользователям изменять с помощью пользовательского агента визуальные характеристики текста в соответствии со своими требованиями. Характеристики текста включают такие аспекты, как размер, цвет, семейство шрифтов и относительное размещение.

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

4. Методы, отвечающие вашим требованиям пользователей.

Все вышеперечисленные объяснения почему WCAG 2.0 могут быть недостаточными. Однако многие из представленных вами случаев действительно учитываются текущими методами WCAG 2.0

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

Сообщение на дом

После этого долгого, но необходимого объяснения мой краткий совет:

  1. Лучше ознакомьтесь с критериями успеха WCAG 2.0 и поймите, почему они необходимы. Познакомьтесь с тем, как люди с ограниченными возможностями используют Интернет (замечу, что вы уже это сделали).
  2. разумно применять методы WCAG 2.0. Вы в большинстве случаев будете в безопасности, если будете придерживаться методов WCAG 2.0. Однако всегда принимайте во внимание критерии успеха, на которые они отвечают, и спрашивайте себя, являются ли они лучшим способом им соответствовать. Выберите методы, которые лучше всего подходят для конкретного веб-сайта, аудитории и вашего опыта.
  3. Привлекайте пользователей с различными способностями к разработке, тестированию и обслуживанию веб-сайтов (я также отмечаю, что вы уже делаете это). Вы, вероятно, уже преодолели большинство потенциальных барьеров доступности, но пользовательская оценка, вероятно, будет выделяться еще несколько. В конце концов, если вы получили отзывы пользователей об обнаружении проблемы, исправьте ее.

Тестируйте так же, как и любой другой тест на удобство использования. То есть не сосредотачивайтесь на пользователях, сообщающих, не следует ли указывать цвета фона CSS, а проверяйте, могут ли они легко выполнять задачи, которые, как предполагается, должны выполнять на вашем веб-сайте, или же они в какой-то момент застрянут. То же самое, что и вы не спрашиваете, считаются ли психометрические свойства определенного цвета привлекательными, но проверяете, достигают ли красные кнопки более высокого коэффициента конверсии в A / B-тестах.

Можно ли полагаться на WCAG как на правильный и полный контрольный список для веб-доступности? Ясно, что это не окончательный доказываемый теоремой способ гарантировать, что каждый может получить доступ к вашему веб-сайту на равных условиях. Это вопрос взаимодействия человека и компьютера, и как таковой его нельзя полностью охватить ограниченным набором руководящих принципов. Тем не менее, это надежный источник, который четко охватывает большинство сценариев использования в реальном мире, и при использовании по назначению можно извлечь из него большие преимущества.

person ysmartin    schedule 02.02.2014

arrow_upward
2
arrow_downward

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

Если вы правильно следуете WCAG2, посетители сайта смогут использовать вспомогательные технологии и инструменты для настройки своего опыта. Например, использование относительных единиц, таких как em и проценты, для размеров шрифта означает, что пользователи IE могут полагаться на инструмент изменения размера текста браузера, чтобы сделать текст точного размера, который им нравится (поскольку IE ненавидит размеры в пикселях); Убедившись, что вы не помещаете ценную информацию в фоновые изображения или текст в изображения, означает, что контент сохраняется, если посетитель использует высококонтрастный режим Windows или создает свою собственную пользовательскую таблицу стилей, чтобы получить приятные большие выделения в фокусе. Я действительно думаю, что руководство WCAG для «видимого фокуса» немного мягкое - пунктирный контур по умолчанию считается достаточным, но часто теряется в сложных или красочных дизайнах. Обычно я использую один и тот же эффект для: hover и: focus, поскольку я считаю, что он дает более четкий результат при переходе по странице с помощью табуляции.

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

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

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

person stringy    schedule 29.01.2014