Сегодняшний веб-контент невероятно богат. Он варьируется от стандартного HTML до сложных веб-приложений, полных мультимедиа; такие как анимация, визуализация данных, видеоигры, смешанная реальность и VR и многие другие. Такой контент часто недоступен или плохо доступен, что означает нарушение взаимодействия с пользователем для тех, кто полагается на вспомогательные технологии для взаимодействия с веб-сайтами. Этот опыт может в лучшем случае раздражать, а в худшем - пустые веб-страницы. Иногда веб-авторы даже предоставляют этим пользователям альтернативный контент. Излишне говорить, что это не всегда равнозначно. Какой альтернативный контент для видеоигр существует?
Веб-сайты создаются недоступными не только потому, что мультимедийный контент очень динамичен, что делает его нетривиальным описать его семантику, но и потому, что в Интернете нет подходящей технологии для передачи такой семантики контента вспомогательным технологиям. Вы можете задаться вопросом, почему при всех технологиях для создания веб-контента у нас нет такой, чтобы сделать его доступным? Вот объяснение.
ВЕБ-СТАНДАРТЫ
Ключевой веб-технологией, делающей контент доступным, является ARIA. ARIA означает доступное полнофункциональное Интернет-приложение. Это веб-стандарт, который определяет набор атрибутов, которые вы можете разместить в элементе DOM, чтобы указать роль, свойства и состояние. Например, ‹div role =” button ”aria-disabled› семантически превратит элемент HTML: div в отключенную кнопку, что заставляет пользователей вспомогательных технологий воспринимать элемент div как кнопку.
Справедливо сказать, что ARIA обычно считается полным набором семантических аннотаций, доступных веб-разработчикам. Другими словами, когда дело касается доступности, ARIA формирует словарный запас веб-автора.
ARIA - действительно замечательная технология, и у нее есть хорошая история успеха. Это делает доступным большое количество веб-сайтов. Однако в этой истории есть один важный момент: словарь ARIA в целом воспроизводит семантику HTML. Конечно, он предоставляет множество дополнительных интересных вещей, таких как элементы управления сеткой или деревом, но не позволяет вам выходить далеко за рамки.
Так что, если у вас есть вариант использования, который не соответствует стандартному HTML? Во-первых, вы можете работать с альтернативным контентом, который можно отобразить в HTML. Вы можете добиться успеха или нет, это зависит от сложности вашего дела. Во-вторых, вы можете предложить расширение ARIA. Это не так плохо, как может показаться. Есть хорошие прецеденты, например, расширение ARIA-DPUB. Я знаю, что это медленный процесс, но он работает. Вам лучше иметь хороший вес в отрасли, чтобы это произошло.
API ПЛАТФОРМЫ: ВЗГЛЯД НА ИСТОРИЮ
Словарь ARIA - не единственная проблема. Есть еще одна часть загадки, заключающаяся в том, что API специальных возможностей никогда не создавался для того, чтобы предоставлять такой непохожий контент вспомогательным технологиям.
Все API доступности берут свое начало пару десятилетий назад, когда недоступные элементы управления JavaScript были уникальной проблемой, которую нужно было решить. Со временем HTML повзрослел и превратился в HTML5, приобретя огромное количество новых функций. Он призвал поставщиков API специальных возможностей скорректировать API, чтобы сделать новые функции доступными. Также были предприняты некоторые усилия, чтобы сделать доступным графический контент, такой как рисунки SVG и HTML canvas. Однако большинство, если не все инициативы, были вдохновлены сценариями использования, подобными HTML.
В случае содержимого, отличного от HTML, например математики, прорыва не произошло. Похоже, что ни один из поставщиков API не предпринял достойных шагов для решения проблемы в целом. Согласны, были некоторые заметные исключения, такие как OS X API, у которого есть дополнительные математические свойства, но вы знаете, что исключение просто подтверждает правило.
Можно сказать, что это происходит по какой-то причине, например, нет особого интереса к такому низкому объему контента - действительно, для этого нужно приложить огромные усилия, чтобы продвинуть все вперед, и всегда есть рыба покрупнее, которую нужно поджарить. Но факт остается фактом: ожидания веб-авторов не оправдались. В результате веб-авторы пытались повторно использовать существующие ноу-хау для раскрытия математического содержания, которое в основном касалось создания удобочитаемых аннотаций, что-то вроде «a плюс b, деленное на ноль». Некоторые программы чтения с экрана начали самостоятельно разбирать MathML для извлечения семантики. Излишне говорить, что это скорее хитрые обходные пути, чем изящные решения.
По общему признанию, за последнее десятилетие был достигнут хороший прогресс в обеспечении доступности Интернета. Однако общая тенденция заключалась в использовании существующего опыта в новых платформах и технологиях. Это позволяло сохранить доступным традиционно доступный контент, но в основном оставляло без внимания все другие виды контента, как давних знакомых, так и новичков, появившиеся несколько лет назад и распространившиеся по современной сети.
КОНЦЕПЦИИ ДОСТУПНОСТИ
Все API специальных возможностей построены на схожих концепциях, если не сказать на одних и тех же концепциях. Эти концепции позволяют авторам описывать и идентифицировать блоки контента и связывать блоки друг с другом. Браузер предоставляет эти блоки вспомогательным технологиям через API специальных возможностей, а вспомогательные технологии преобразуют их в формат, который пользователи могут воспринимать, понимать и использовать.
Вот краткий обзор концепций доступности для обеспечения контекста. Если вам скучно, прокрутите страницу вниз до конца :)
Роль - это краеугольное понятие в семантическом описании блока. Это основная характеристика блока, служащая для определения типа блока. Например, это кнопка или это абзац. Он также охватывает набор возможных свойств и состояний и определяет модели поведения. Например, это выбранный пункт меню или текстовое поле, на котором можно сфокусироваться. Или это ячейка сетки; он имеет индексы строк и столбцов, что помогает пользователю перемещаться по сетке. Также блок может иметь удобочитаемую метку - первое, что услышит пользователь, когда фокус переместится на блок.
Еще одно ключевое понятие - отношения, которые описывают связи между блоками, то есть то, как блоки связаны друг с другом. Например, большинство блоков связаны через родительско-дочерние отношения, такие как сетка и ее ячейки. Или сообщение об ошибке, отображаемое, если пользователь неправильно ввел пароль, связано с полем пароля. Отношения позволяют пользователю перемещаться между блоками в зависимости от типа контента и его состояния по усмотрению пользователя.
И последнее, но не менее важное - это действия. Это поведенческое понятие, используемое для описания взаимодействий, которые пользователь может предпринять с блоком. Если это, например, кнопка, то вы можете щелкнуть по ней и так далее.
Короче говоря, блок описывается ролью, состояниями и атрибутами, что позволяет пользователю воспринимать блок. Действия блока позволяют пользователю взаимодействовать с контентом, а отношения предназначены для навигации.
Кроме того, веб-контент может изменяться со временем, что означает, что блоки могут создаваться, удаляться или изменяться, а также отношения между ними. Все изменения передаются вспомогательным технологиям через механизм событий API специальных возможностей. Это не 100% отдельная концепция доступности, но это неотъемлемая часть, о которой стоит упомянуть для дальнейшего разговора.
УНИВЕРСАЛЬНЫЙ ЯЗЫК
Вы можете найти это удивительным, но эти концепции достаточно универсальны, чтобы описать практически любой вид контента, который вы можете увидеть в Интернете сегодня. В самом деле, пока вы можете описывать контент словами, вы можете вписать эти словесные описания в концепции доступности - все, что вам нужно, это назвать объекты, перечислить их свойства, определить отношения и объяснить, как взаимодействовать.
Нужен пример? Конечно. Скажем, у вас есть круговая диаграмма - это то, что выпадает из стандартного HTML, и поэтому вам обычно приходится использовать множество уловок, чтобы сделать ее доступной. Однако концепции здесь идеально подходят. Ведь пирог - это роль, его название - это ярлык. Круговая диаграмма состоит из секторов, каждый из которых также имеет заголовок, и все сектора связаны отношениями, определяющими, какой из них будет следующим. Таким образом, пользователь может читать круговую диаграмму, перемещаясь по всем секторам один за другим.
Или давайте рассмотрим видеоигру, в которой плюшевый мишка учит вас танцевать. Медведь показывает танцевальные движения, такие как поворот пятки, натяжение пятки, дос-а-дос. Камеры отслеживают ваше положение и оценивают, насколько хорошо вы выступаете. Итак, с точки зрения концепций, инструкции медведя - это блоки ограниченного жизненного цикла с ярлыками, которые вам рассказывают. Позиции конечностей - это еще один набор блоков, которые характеризуются скалярным значением в диапазоне от 0 до 100% и описывают, насколько вы были близки к желаемой позиции. Итак, пока медведь танцует, вам говорят «поворот пятки, тяга пятки», и когда вы двигаетесь, вы слышите, насколько совершенным было ваше движение. Вы также можете добавить сюда фактор обратной связи, который подскажет, как можно улучшить ваши движения, например, попробуйте в следующий раз наклониться вперед и т. Д.
Не стоит ограничиваться этими примерами. Думаете открыть онлайн-магазин нотных листов? Вы точно не хотите никого оставлять позади. Вам нужно будет сделать ноты доступными, чтобы пользователи вспомогательных технологий также могли ими пользоваться. Использует ли ваше веб-приложение формулы химического кольца, математические уравнения или что-нибудь еще из любого другого предмета, о котором вы можете подумать? Итак, вы определенно можете описать все эти символы и формулы своему другу, чтобы ваш друг мог их понять, верно? Таким образом, вы также должны уметь выражать их в концепциях доступности. Вы можете потренироваться самостоятельно, чтобы увидеть, как все пройдет.
СОЗДАЙТЕ ИДЕЮ
Вернемся на землю.
Концепции доступности были изобретены много лет назад, и, что удивительно или нет, они хорошо подходят для современной сети. Однако веб-авторам все еще трудно сделать веб-приложения доступными. Вы задаетесь вопросом, как же так получилось, что какой части не хватает? Ответ довольно прост: у веб-авторов нет подходящей технологии для описания веб-контента, или в веб-терминах нет подходящих имен тегов и атрибутов или хуков JavaScript, подходящих для описания значения контента. . Допустим, вы создали веб-приложение, которое выглядит потрясающе и весьма полезно, но ваше творчество не ограничивалось стандартным HTML. Скорее всего, машина не знает, о чем приложение, и, следовательно, не может успешно преобразовать его в формат, который могут усвоить вспомогательные технологии.
В этом смысле веб-технология для описания контента является важной частью, но даже если бы она у вас была, ирония заключается в том, что API специальных возможностей все равно не справились бы с этим, потому что они не были предназначены для этого.
Давайте резюмируем эту головоломку из двух частей. Первая часть состоит в том, что веб-автору нужен технический словарь для описания смысла контента, а второй - платформы должны иметь механизм доставки для передачи этих описаний вспомогательным технологиям.
Так как же будет выглядеть технология, которая решает эту головоломку?
Давайте подумаем вслух. Скажем, у вас есть классное веб-приложение или вы являетесь поставщиком уникального контента, и наверняка оно особенное, чтобы вписаться в стандартный HTML. Затем, конечно, вы можете объяснить это своим друзьям, чтобы они все поняли - конечно, как они могли бы использовать ваше приложение в противном случае? Затем вы вставляете формулировку в концепции доступности, как указано выше, что также означает разбиение ее на блоки таким образом, чтобы они могли быть обработаны программным обеспечением.
Вся суть в построении блоков заключается в том, что веб-авторам нужен глубокий контроль над ними - а это именно то, чего сегодня не хватает в сети. Конечно, если авторы создают контент, их выразительные возможности объяснять контент не должны ограничиваться технологиями.
Давайте представим, что веб-авторы получают по-настоящему гибкий инструмент, который позволяет им манипулировать блоками контента так, как они хотят, когда автор отвечает за определение новых ролей, состояний, свойств и связывание блоков друг с другом любыми отношениями, которые вы можете себе представить. . Затем все это передается вспомогательным технологиям через API платформы (да, это, вероятно, единственное требование к API, чтобы иметь возможность передавать такие данные). И вуаля, это все, что нам нужно!
Поставщик контента (веб-автор) знает значение контента. Вспомогательные технологии знают, как представить контент пользователю, а браузер знает, как доставлять его вспомогательным технологиям.
В этом сценарии браузер служит мостом, соединяющим веб-автора и вспомогательные технологии. Браузеру не обязательно понимать семантику контента, который проходит через него. Браузер действует как агент, который заставляет автора и вспомогательную технологию общаться напрямую.
Звучит потрясающе? Да! Звучит фантастично? Нет, но производители браузеров и API-интерфейсов должны приложить все усилия, чтобы это произошло.
Я считаю, что Интернету нужна новая гибкая и расширяемая технология, позволяющая веб-авторам контролировать контент, который они создают. И это навсегда изменит Интернет!
