Canvas API: обычное применение и конфиденциальность

Canvas API позволяет веб-странице с помощью JavaScript рисовать графику на элементе canvas в HTML. Это обычный инструмент браузера для диаграмм, иллюстраций, анимации, игровой графики и мультимедийных возможностей. Размышляя о конфиденциальности Canvas API, начните с назначения страницы: что человек должен увидеть или сделать, какие данные нужны для получения результата и что должно оставаться доступным, если визуальный слой нельзя использовать.

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

О методе отслеживания и его влиянии на конфиденциальность рассказано в статье о сборе отпечатка Canvas. Обычное применение Canvas API все равно требует понятных пользователю результатов, доступных альтернатив и учета контекста, в котором браузер отображает содержимое. Более широкий контекст связи браузера, сайта, аккаунта и сети описан в руководстве о конфиденциальности браузера в разных средах.

Понимайте назначение Canvas

Элемент canvas в HTML предоставляет растровое изображение, которое скрипты могут обновлять по мере работы страницы. В стандарте HTML WHATWG он описывается как зависящая от разрешения поверхность для динамического отображения графиков, игровой графики, рисунков и других визуальных образов. В MDN Canvas API также описывается как способ рисовать графику с помощью JavaScript и элемента canvas, прежде всего двумерную. Эти описания служат полезной отправной точкой: Canvas нужен для создания видимого содержимого и взаимодействий на странице.

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

Анимация тоже является обычным способом применения Canvas. Страница может со временем обновлять сцену, чтобы показать изменения или движение либо сделать взаимодействие более отзывчивым. Движение может пояснять переход, но также отвлекать или вызывать дискомфорт. Ответственный интерфейс позволяет приостановить или уменьшить необязательную анимацию и не делает важные инструкции зависимыми только от просмотра движения. Остановленная анимация не должна мешать пониманию страницы.

В играх и интерактивных иллюстрациях Canvas позволяет перерисовывать сцену в ответ на действия человека. Визуальная область может включать игровое поле, движущиеся объекты или меняющийся счет. При этом вокруг нее нужен понятный интерфейс для управления и отображения состояния. Человек должен понимать, как начать, приостановить и продолжить игру, а также как интерпретировать результат. Если важно управление с клавиатуры, страница должна связывать видимые интерактивные области с элементами управления, к которым можно перейти, а не считать, что одних пикселей достаточно.

Canvas можно использовать и в приложениях для фотографий или видео в реальном времени. Страница может показывать кадр, применять видимый эффект или накладывать графику на мультимедиа. Цель функции должна быть понятна пользователю, особенно когда мультимедиа снимается, преобразуется или сохраняется. Объясните, когда страница использует изображение с камеры, когда выполняется обработка и сохраняется ли результат или отправляется в другое место. Не заставляйте человека догадываться об этом только по движущемуся изображению.

В каждом случае начните с результата и ожидаемого действия пользователя. Нужно ли постоянно менять изображение? Должны ли пользователи выбирать или перемещать его части? Будет ли проще использовать статичное изображение или семантический HTML? Canvas полезен, когда рисование или частые обновления соответствуют задаче. Он не всегда подходит для содержимого, которое можно понятно представить текстом, таблицей или обычными элементами страницы.

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

Сделайте визуальный результат доступным

Содержимое Canvas по своей сути представляет собой растровое изображение. Браузер может отображать его пиксели, но сам рисунок автоматически не передает вспомогательным технологиям значение каждого отдельного объекта. Диаграмма, состоящая только из пикселей, может выглядеть понятной, но не предоставлять экранному диктору никаких полезных значений. Текст, нарисованный на изображении, также бывает сложно увеличить, выделить, перевести или оформить иначе. Заранее предусмотрите равноценное представление, а не добавляйте его после завершения визуальной части.

Для диаграммы предоставьте странице исходные значения или краткое текстовое описание. Таблица данных позволяет просматривать точные значения, а краткое пояснение может передавать главную закономерность или вывод. Эти варианты должны отражать ту же информацию, что и рисунок, и оставаться актуальными при его изменении. Если пользователи могут фильтровать диаграмму, текст или таблица должны соответствовать выбранному представлению, а не описывать другое состояние.

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

Для игры или интерактивной сцены определите действия и результаты, к которым человеку нужен доступ. Согласно стандарту HTML, интерактивным областям на интерактивном canvas должны соответствовать доступные для фокусировки области один к одному. В практическом проектировании видимые элементы должны иметь понятные средства управления и обратную связь. Пользователям клавиатуры нужен способ выполнять те же значимые действия, а фокус должен быть заметен. Счет, предупреждение или сообщение о завершении не должны передаваться только цветом или кратким визуальным изменением.

Где уместно, используйте семантический HTML для подписей, инструкций, кнопок и сообщений о состоянии. Canvas может обеспечивать особый визуальный слой, а обычные элементы HTML предоставят структуру и доступные названия. Такое разделение помогает и в случаях, когда рисунок не загрузился, скрипт недоступен или человек пользуется средством, которое не интерпретирует растровое изображение. Доступная страница не требует, чтобы все люди одинаково воспринимали один и тот же визуальный слой.

Учитывайте контрастность, размер текста, зависимость от цвета, движение и масштабирование. Различайте ряды диаграммы не только цветом и делайте важные подписи читаемыми при фактическом размере просмотра. Позволяйте приостанавливать анимацию и сохраняйте доступность основных средств управления при изменении размера рисунка. В интерактивных сценариях показывайте состояние и доступные действия так, чтобы человеку не нужно было следить за постоянно меняющейся сценой. Это решения о продукте и рисунке, а не функции, которые Canvas предоставляет автоматически.

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

Предусмотрите полезное резервное содержимое

Резервное содержимое представляет собой альтернативу, которую страница предоставляет, если визуальное представление на canvas недоступно. Стандарт HTML описывает, как canvas может предоставлять такое содержимое, когда элемент нельзя отобразить как растровое изображение. Эта альтернатива должна быть полезна сама по себе: она может объяснять назначение изображения, содержать важные данные или вести к равноценному интерфейсу. Пустая область или общее сообщение не позволяют выполнить задачу.

Поддерживайте соответствие резервной информации текущему рисунку. Если данные диаграммы обновились, альтернативный текст, таблица или описание не должны оставаться в прежнем состоянии. Если анимация приостановлена, страница должна по-прежнему сообщать нужное состояние. Если игровая сцена изменилась после действия, доступные средства управления и сообщения о состоянии должны описывать текущий результат. Считайте альтернативное содержимое еще одним представлением функции, которым нужно управлять и обновлять так же, как самим canvas.

Резервное содержимое и доступность связаны, но это не одно и то же. Содержимое, показываемое только при неподдерживаемом Canvas, может быть недоступно экранному диктору, если canvas успешно отображается. И наоборот, доступное название элемента canvas не обязательно описывает подробную диаграмму или интерактивную сцену внутри него. Предусмотрите подходящую альтернативу для обоих случаев: полезное резервное поведение и равноценный интерфейс для тех, кто не может воспринимать растровое изображение в представленном виде.

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

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

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

Соблюдайте границы безопасности браузера

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

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

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

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

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

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

Ответственно проектируйте функции Canvas и поддерживайте их

Начинайте планирование функции с краткого описания результата, видимого пользователю. Укажите, почему здесь уместен Canvas, какие данные и мультимедийные входные данные нужны задаче, меняется ли результат со временем и какое представление без Canvas доступно. Это проясняет охват функции для дизайнеров, разработчиков и пользователей. Кроме того, обсуждение конфиденциальности остается связанным с реальной задачей, а не расплывчатыми утверждениями о технологии.

Отдавайте предпочтение наименее сложному представлению, подходящему для цели. Таблицу или диаграмму на семантическом HTML может быть проще проверять и адаптировать, чем собственное растровое изображение. Динамический рисунок может подойти для игры, анимации или интерактивной визуализации. При выборе учитывайте взаимодействие, отзывчивость интерфейса, доступность и поддержку, а не только внешний вид или удобство реализации.

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

Поддерживайте согласованность визуального и альтернативного представлений интерфейса. Подписи, элементы управления, состояние и резервное содержимое должны использовать одинаковые названия и описывать одно и то же состояние. При обновлении изображения должны обновляться и его текстовый вариант, и обратная связь о взаимодействии. Если пользователь приостанавливает анимацию или меняет представление, сообщайте об этом состоянии не только с помощью пикселей.

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

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

Публичные источники

• Стандарт HTML WHATWG: элемент canvas
• MDN: Canvas API