Интерактивный сайт: что это и что проверить заказчику

Коротко: определения «интерактивного сайта» в MDN, Khronos и W3C нет. Студия BITSPARK так называет услугу и описывает её словами «WebGL, motion и нестандартные интерфейсы». По MDN, WebGL рисует двухмерную и трёхмерную графику в элементе canvas, и ему нужны две вещи: браузер с поддержкой WebGL и оборудование на устройстве посетителя. Что увидит посетитель без этого, стоит записать в задание заранее. Для содержимого canvas и для управления на странице WCAG 2.2 называет критерии 1.1.1 и 2.1.1.

Заказчик слышит от подрядчика слова «интерактивный сайт» и WebGL и решает три вещи: что вписать в задание, что спросить заранее и что проверить при приёмке. Дальше идут услуга «Интерактивный сайт» с главной страницы BITSPARK, страницы MDN и Khronos о canvas, WebGL, WebGL 2 и WebGPU, поведение страницы на устройстве без поддержки графики, критерии WCAG 2.2 и вопросы для задания и приёмки.

Сведения приведены по страницам источников на 21.10.2026. Khronos, W3C и MDN пишут по-английски, кроме одной русской страницы MDN о WebGL. Английские цитаты даны с переводом, перевод наш.

Цитаты даны дословно, пропуски обозначены знаком (...). Длинное тире в цитатах заменено дефисом. Пример вымышленный: магазин керамики с сайтом example.ru.

Что такое интерактивный сайт?

Коротко: открытые страницы MDN, Khronos и W3C не определяют «интерактивный сайт» как вид сайта, поэтому чужую классификацию за термин выдавать нельзя. Известна формулировка студии BITSPARK: так называется четвёртая услуга на её главной странице. Расшифровки слов «motion» и «нестандартные интерфейсы» на главной нет, и в задании их заменяет описание экранов и действий посетителя.

Источники статьи описывают технологии, из которых собирают такие страницы, и эти описания разобраны в следующих разделах. Для услуги студии источник один: главная страница bitspark.ru. В списке «Что мы делаем» четвёртая услуга названа «Интерактивный сайт» и описана так:

«Индивидуальная оценка - WebGL, motion и нестандартные интерфейсы.»

• BITSPARK, главная страница, раздел «Что мы делаем»

Цены у этой услуги нет, на главной стоит «Индивидуальная оценка». В разделе «О нас» на той же странице сказано, что студия создаёт «рабочий адаптивный продукт - от статического сайта до сложного интерактивного интерфейса». Что такое статический сайт по определению MDN, разбирает статья о статическом и динамическом сайте.

Слово «движение» на главной стоит в описании шага «Дизайн»: «Формируем характер проекта: типографику, композицию, движение и систему интерфейса.» О том, как проверять движение на странице, пишет статья об анимации на сайте. Здесь анимация разбирается только там, где она связана с графикой WebGL.

Из чего сделана графика на таком сайте?

Коротко: MDN описывает canvas как элемент, в котором рисуют скриптом, и отдельно WebGL, который рисует в том же элементе двухмерную и трёхмерную графику с аппаратным ускорением. WebGL 2 назван крупным обновлением WebGL. WebGPU на 21.10.2026 помечен на MDN как Limited availability и «not Baseline».

Страница MDN о Canvas API открывается словами: «The Canvas API provides a means for drawing graphics via JavaScript and the HTML <canvas> element.» Перевод наш: Canvas API даёт средство для рисования графики через JavaScript и HTML-элемент <canvas>. Дальше на странице сказано, что Canvas API сосредоточен на двухмерной графике («largely focuses on 2D graphics»), а WebGL «draws hardware-accelerated 2D and 3D graphics», то есть рисует аппаратно ускоренную двухмерную и трёхмерную графику. Аппаратное ускорение здесь означает, что страница использует графическое ускорение, которое даёт оборудование устройства (так сказано на английской странице MDN о WebGL).

Русская страница MDN о WebGL, переведённая сообществом, определяет технологию так:

«WebGL (Web Graphics Library) - программная библиотека для языка JavaScript предназначенная для визуализации интерактивной трёхмерной графики и двухмерной графики в пределах совместимости веб-браузера без использования плагинов.»

• WebGL - Интерфейсы веб API | MDN, страница изменена 29 апреля 2026 года

Английская страница WebGL: 2D and 3D graphics for the web - Web APIs | MDN изменена 15 июля 2025 года. Она называет WebGL «a JavaScript API for rendering high-performance interactive 3D and 2D graphics within any compatible web browser without the use of plug-ins». Перевод наш: JavaScript-интерфейс для высокопроизводительной интерактивной трёхмерной и двухмерной графики в любом совместимом браузере без плагинов. В таблице собраны формулировки источников по четырём названиям.

Перевод оговорки по WebGPU: не работает в некоторых из самых распространённых браузеров. Спецификация WebGL 2.0 на странице latest помечена как черновик редактора (editor's draft), поэтому статья берёт из неё только то, что она описывает, и её статус. Какой из четырёх вариантов выбрать, источники не говорят. На главной странице BITSPARK о выборе технологий сказано так: «Технологии выбираем под задачу.»

Что будет, если браузер или устройство не поддерживают WebGL?

Коротко: по MDN метод getContext возвращает null, если тип контекста не поддерживается. Для WebGL браузеру мало поддержки самой технологии, нужно ещё подходящее оборудование. При создании контекста можно включить параметр failIfMajorPerformanceCaveat, и тогда создание контекста завершится неудачей, если реализация сочтёт производительность резко сниженной. Что покажет страница в каждом из этих случаев, задаёт задание.

Чтобы нарисовать что-то в canvas, скрипт на странице запрашивает у элемента контекст отрисовки, то есть объект, через который идёт рисование. Для этого служит метод getContext. Страница HTMLCanvasElement: getContext() method - Web APIs | MDN (изменена 2 июля 2025 года) пишет:

«The HTMLCanvasElement.getContext() method returns a drawing context on the canvas, or null if the context identifier is not supported, or the canvas has already been set to a different context mode.» Перевод наш: метод возвращает контекст отрисовки на canvas, либо null, если идентификатор контекста не поддерживается или для canvas уже выбран другой режим контекста.

• HTMLCanvasElement: getContext() method - Web APIs | MDN

Контекст «webgl» та же страница описывает как «only available on browsers that implement WebGL version 1», то есть доступный только в браузерах, которые реализуют первую версию WebGL. Такая же оговорка стоит у «webgl2» (про вторую версию) и у «webgpu» (про WebGPU).

Вторая причина отказа названа на странице MDN о WebGL. Там сказано: «Support for WebGL is present in all modern browsers (see the compatibility tables below); however, the user's device must also have hardware that supports these features.» Перевод наш: поддержка WebGL есть во всех современных браузерах (см. таблицы совместимости ниже), но у устройства пользователя должно быть и оборудование, которое поддерживает эти возможности.

Русская страница MDN говорит то же: «(...) помимо поддержки WebGL браузером, необходима также его поддержка графическим процессором клиента.»

Третий случай описан в параметре failIfMajorPerformanceCaveat. На странице getContext о нём сказано: «A boolean value that indicates if a context will be created if the system performance is low or if no hardware GPU is available.» Перевод наш: логическое значение, которое показывает, будет ли создан контекст, если производительность системы низкая или аппаратного GPU нет.

Подробнее его описывает WebGL Specification (Editor's Draft от 30 июня 2026 года) в разделе о параметрах контекста:

«If the value is true, context creation will fail if the implementation determines that the performance of the created WebGL context would be dramatically lower than that of a native application making equivalent OpenGL calls.» Перевод наш: если значение true, создание контекста завершится неудачей, когда реализация решит, что производительность созданного контекста WebGL будет резко ниже, чем у родного приложения, делающего равноценные вызовы OpenGL.

• WebGL Specification, раздел WebGLContextAttributes, параметр failIfMajorPerformanceCaveat

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

«Applications that require high performance may set this parameter to true, and if context creation fails then the application may prefer to use a fallback rendering path such as a 2D canvas context. Alternatively the application can retry WebGL context creation with this parameter set to false, with the knowledge that a reduced-fidelity rendering mode should be used to improve performance.» Перевод наш: приложения, которым нужна высокая производительность, могут задать этот параметр true, и если создание контекста не удалось, приложение может перейти на запасной путь отрисовки, например на двухмерный контекст canvas. Либо приложение может повторить создание контекста WebGL с параметром false, зная, что для сохранения производительности нужно использовать режим с пониженным качеством отрисовки.

• WebGL Specification, раздел WebGLContextAttributes

Для заказчика отсюда следует вопрос к подрядчику: как поведёт себя страница, когда у посетителя контекст не создался. Спецификация называет два пути (запасная отрисовка на 2D canvas и режим с пониженным качеством), и выбор между ними или иной вариант записывают в задании. Источники такого вопроса прямо не формулируют.

Почему WebGL-сайт работает не на каждом устройстве?

Коротко: страница MDN «WebGL best practices» предупреждает разработчиков, что возможности и пределы системы разработчика отличаются от систем посетителей. Страница советует по возможности делать расширения WebGL необязательными, а один из режимов точности вычислений в WebGL 1 необязателен, и без запасного пути сайт может не заработать на старом мобильном оборудовании. Для элемента canvas на устройствах iOS MDN называет предел размера 4096 на 4096 пикселей.

Страница WebGL best practices - Web APIs | MDN (изменена 7 октября 2026 года) обращена к разработчикам, и заказчику читать её целиком не нужно. Три места из неё касаются вопроса, который заказчик может задать подрядчику.

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

О расширениях, то есть о дополнениях к WebGL, там сказано: «The availability of most WebGL extensions depends on the client system. When using WebGL extensions, if possible, try to make them optional by gracefully adapting to the case there they are not supported.» Перевод наш: доступность большинства расширений WebGL зависит от системы клиента; если возможно, делайте расширения необязательными, аккуратно подстраиваясь под случай, когда их нет.

Ещё один пример касается точности вычислений в шейдерах, то есть в программах, которые обрабатывает графический процессор (так MDN называет шейдеры на странице WebGPU). В WebGL 1 поддержка высокой точности («highp float») во фрагментных шейдерах необязательна. По MDN, безусловное использование highp не даст содержимому работать на некотором старом мобильном оборудовании. Для заказчика это ещё одна причина проверять сцену на старом телефоне.

О размере самого элемента canvas пишет страница 0 HTML graphics canvas element - HTML | MDN (изменена 24 апреля 2026 года): «notably iOS devices limit the canvas size to only 4,096 x 4,096 pixels». Перевод наш: устройства iOS ограничивают размер canvas всего 4096 на 4096 пикселей. Там же: «Exceeding the maximum dimensions or area renders the canvas unusable - drawing commands will not work.» Перевод наш: превышение максимальных размеров или площади делает canvas непригодным, команды рисования не сработают.

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

Про старые браузеры и про пример MDN с 3D-туром, где часть возможностей в таких браузерах теряется, пишет статья о кроссбраузерности сайта. Пример здесь не повторяется.

Что такое потеря контекста WebGL и зачем она заказчику?

Коротко: браузер может потерять буфер отрисовки WebGL, и тогда страница получает событие webglcontextlost. Спецификация пишет, что реализации используют потерю и восстановление контекста для управления энергией и памятью. После восстановления созданные раньше ресурсы недействительны, и приложению нужно восстановить состояние и ресурсы. Для заказчика это пункт приёмки: подрядчик показывает, что сайт после потери продолжает работать.

Страница MDN HTMLCanvasElement: webglcontextlost event - Web APIs | MDN (изменена 28 июля 2026 года) открывается так: «The webglcontextlost event of the WebGL API is fired if the user agent detects that the drawing buffer associated with a WebGLRenderingContext object has been lost.» Перевод наш: событие webglcontextlost возникает, если браузер обнаруживает, что буфер отрисовки, связанный с контекстом WebGL, потерян. Буфер отрисовки спецификация WebGL определяет в разделе «The Drawing Buffer» как буфер, в который отрисовываются вызовы интерфейса.

Причины потери страница MDN не перечисляет. Спецификация WebGL в описании параметра powerPreference пишет, что реализации WebGL используют события потери и восстановления контекста, чтобы регулировать потребление энергии и памяти, независимо от значения этого параметра.

Для запроса высокой производительности там же есть предупреждение разработчикам: «Applications that request high-performance should test and maintain robust context loss handling, as User Agents are very likely to decide to lose background high-performance contexts.» Перевод наш: приложения, запрашивающие высокую производительность, должны проверять и поддерживать надёжную обработку потери контекста, поскольку браузеры очень вероятно будут терять фоновые высокопроизводительные контексты.

В разделе о событии восстановления контекста спецификация описывает последствия. Первая фраза: «Once the context is restored, WebGL resources such as textures and buffers that were created before the context was restored are no longer valid.» Вторая: «The application will want to restore all modified state and destroyed extensions and resources.» Перевод наш: после восстановления контекста ресурсы WebGL, например текстуры и буферы, созданные до восстановления, перестают быть действительными; приложению потребуется восстановить все изменённые состояния и уничтоженные расширения и ресурсы. Эту работу спецификация возлагает на приложение.

На странице «WebGL best practices» об ошибках сказано: «The only errors a well-formed page generates are OUT_OF_MEMORY and CONTEXT_LOST.» Перевод наш: единственные ошибки, которые создаёт правильно написанная страница, - OUT_OF_MEMORY и CONTEXT_LOST, то есть нехватка памяти и потеря контекста.

На странице MDN о событии есть пример, как смоделировать потерю: расширение WEBGL_lose_context позволяет вызвать событие специально. Заказчик не обязан запускать этот код сам, но может попросить подрядчика показать результат такой проверки при приёмке.

Какой запасной вариант страницы записать в задание?

Коротко: источники называют несколько вариантов: запасную отрисовку на 2D canvas, режим с пониженным качеством, содержимое внутри элемента canvas для браузеров без поддержки canvas или с отключённым JavaScript. Какой вариант нужен сайту, решают заказчик и подрядчик. В задании стоит назвать каждый случай отказа и то, что видит посетитель.

Страница MDN об элементе canvas описывает запасное содержимое: «You should provide alternate content inside the <canvas> block. That content will be rendered both on older browsers that don't support canvas and in browsers with JavaScript disabled.» Перевод наш: внутри блока canvas нужно дать альтернативное содержимое; оно показывается и в старых браузерах без поддержки canvas, и в браузерах с отключённым JavaScript. В примере кода на той же странице внутри элемента стоит «An alternative text describing what your canvas displays», то есть текст, описывающий, что показывает canvas.

Страница не говорит, что это содержимое показывается, когда браузер поддерживает canvas, но контекст WebGL не создался. Для такого случая спецификация WebGL называет запасную отрисовку на 2D canvas и режим с пониженным качеством.

Пример: магазин керамики с сайтом example.ru хочет показать вазу в 3D, которую посетитель вращает. В задании для вазы можно записать четыре случая и ответ на каждый:

1. WebGL недоступен на устройстве (метод getContext вернул null). Что видит посетитель? Например, фотографию вазы с описанием.
2. Контекст создан, но устройство слабое. Включён ли параметр failIfMajorPerformanceCaveat, и что показывает страница при отказе?
3. Контекст потерян во время просмотра. Остаётся ли ваза на экране, и как она возвращается после восстановления?
4. JavaScript отключён. Какой текст и какая картинка стоят внутри элемента canvas?

Ответы в этом примере придуманы для иллюстрации. Какие варианты нужны именно вашему сайту, решаете вы вместе с подрядчиком. Полный список вопросов для задания - в разделе «Что записать в задание на интерактивный сайт?», а что входит в такой документ, разбирает статья о техническом задании на сайт.

Что с доступностью: как canvas и WebGL связаны с WCAG?

Коротко: MDN пишет, что canvas - растровая картинка, которая не сообщает вспомогательным технологиям, что на ней нарисовано. WCAG 2.2 в критерии 1.1.1 требует текстовую альтернативу для нетекстового содержимого, а в критерии 2.1.1 - управление всей функциональностью с клавиатуры, кроме действий, где важен путь движения. Соответствует ли конкретная сцена критерию, показывает проверка по тексту критерия, и эта статья её не заменяет.

Страница Canvas API - Web APIs | MDN в разделе «Accessibility concerns» пишет:

«The <canvas> element is just a bitmap and does not provide information about any drawn objects. (...) Canvas content is not exposed to accessibility tools like semantic HTML is. In general, you should use canvases like images and avoid using them to render significant content without accessible backing markup.» Перевод наш: элемент canvas - всего лишь растровое изображение, и он не даёт информации о нарисованных объектах. (...) Содержимое canvas не доступно инструментам доступности так, как семантический HTML. В целом canvas нужно использовать как изображения и избегать с его помощью выводить значимое содержимое без доступной подложки из разметки.

• Canvas API - Web APIs | MDN, страница изменена 17 сентября 2026 года

Там же: текст, написанный на canvas, может быть плохо читаем при экранном увеличении, потому что пиксели canvas не масштабируются и при увеличении размываются. В таблице даны два критерия стандарта Web Content Accessibility Guidelines (WCAG) 2.2 (рекомендация W3C от 12 декабря 2024 года), которые касаются этой темы напрямую.

Исключения из критерия 1.1.1 перечислены в самом тексте: элементы управления и ввод, мультимедиа по времени, тест или упражнение, особое чувственное впечатление, CAPTCHA, оформление. Страница Understanding Success Criterion 2.1.1: Keyboard | WAI | W3C поясняет границу критерия: рисование от руки требует ввода, зависящего от пути, а перетаскивание объектов в место, когда путь к нему не важен, такого ввода не требует. О содержимом, которое создаёт особое чувственное впечатление, пишет Understanding Success Criterion 1.1.1: Non-text Content | WAI | W3C: «text alternatives at least identify the non-text content with a descriptive label and where possible, additional descriptive text.» Перевод наш: текстовые альтернативы как минимум обозначают нетекстовое содержимое описательной подписью, а где возможно, дают и дополнительный описательный текст.

Ещё два критерия относятся к движению на странице: 2.2.2 Pause, Stop, Hide (уровень A) и 2.3.3 Animation from Interactions (уровень AAA). Их тексты, настройку уменьшения движения (prefers-reduced-motion) и вспышки разбирает статья об анимации на сайте, здесь они не повторяются.

Какие требования доступности обязательны для сайтов в России, в этой статье не рассматривается. Начать можно со статьи о версии сайта для слабовидящих.

Что записать в задание на интерактивный сайт?

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

Список составлен по разделам статьи. Источники такого общего списка не дают. Что ещё входит в техническое задание, разбирает статья о техническом задании.

1. Какие экраны и действия посетителя строятся на canvas или WebGL? Слова «интерактивный сайт» и «нестандартные интерфейсы» источники не определяют, поэтому в задании их заменяет описание: что видит посетитель и что он может сделать.
2. Какая технология выбрана и почему: canvas, WebGL, WebGL 2 или WebGPU? Для WebGPU MDN указывает Limited availability, поэтому для него отдельно спросите, что увидят посетители браузеров без поддержки.
3. Что видит посетитель, если getContext вернул null? MDN: метод возвращает null, если тип контекста не поддерживается.
4. Включён ли failIfMajorPerformanceCaveat и что тогда показывает страница? Спецификация WebGL называет запасную отрисовку на 2D canvas и режим с пониженным качеством.
5. Что происходит при потере контекста? Спецификация предупреждает о потере фоновых контекстов с запросом высокой производительности и о том, что ресурсы после восстановления недействительны.
6. Что стоит внутри элемента canvas для браузеров без поддержки и без JavaScript? MDN советует дать альтернативное содержимое.
7. Как задана текстовая альтернатива сцены и как названы элементы управления? Критерий WCAG 2.2 1.1.1.
8. Все ли действия доступны с клавиатуры? Критерий WCAG 2.2 2.1.1.
9. Что делает страница при включённой в системе настройке уменьшения движения и есть ли пауза для движения? Критерии 2.2.2 и 2.3.3, подробности в статье об анимации.
10. На каких устройствах и в каких браузерах сцена должна работать полностью? Выбор списка разобран в статье о кроссбраузерности, про разные размеры экрана пишет статья об адаптивном сайте.

Что проверить при приёмке на телефоне и на компьютере?

Коротко: шаг «Запуск» на главной странице BITSPARK описан словами «Проверяем desktop и mobile, скорость, формы и ключевые сценарии - затем запускаем». Для сайта с графикой к этому добавляются проверки, следующие из источников статьи: второе устройство, запасной вариант, клавиатура, увеличение текста, потеря контекста. Что пройдёт приёмку, определяют условия задания.

Пятый шаг процесса на главной странице называется «Запуск». Для интерактивного сайта к его описанию стоит добавить проверки, которые следуют из источников статьи:

1. Откройте сайт на телефоне и на компьютере. Шаг «Запуск» называет обе проверки. Откройте сайт и на устройстве, где его не разрабатывали: страница «WebGL best practices» предупреждает, что пределы системы разработчика отличаются от систем клиентов.
2. Попросите показать запасной вариант страницы. Сравните увиденное с ответами на вопросы задания о getContext, failIfMajorPerformanceCaveat и содержимом внутри canvas.
3. Попросите показать потерю контекста. MDN приводит способ смоделировать событие webglcontextlost через расширение WEBGL_lose_context, и подрядчик может показать, что сцена после потери продолжает работать.
4. Пройдите страницу с клавиатуры. Переходите по элементам клавишей Tab и убедитесь, что каждое действие, которое выполняется мышью или касанием, можно выполнить и с клавиатуры (критерий 2.1.1).
5. Увеличьте масштаб страницы. MDN пишет, что текст на canvas при увеличении может стать нечётким, поэтому значимый текст проверьте отдельно.
6. Включите в системе настройку уменьшения движения и посмотрите, как изменилась сцена. Что должно произойти, написано в статье об анимации на сайте.
7. Пройдите ключевые сценарии, формы и скорость загрузки. Это остальные пункты шага «Запуск». Общий порядок проверок до запуска разбирает статья о тестировании сайта.

Результат каждой проверки записывают рядом с вопросом из задания. Расхождения с заданием передают подрядчику до запуска.

Источники

Дата обращения к страницам: 21.10.2026.

• BITSPARK - цифровая студия: сайты с настоящим присутствием - услуга «Интерактивный сайт», шаги процесса, раздел «О нас».
• WebGL - Интерфейсы веб API | MDN - определение WebGL на русском языке (страница изменена 29 апреля 2026 года).
• WebGL: 2D and 3D graphics for the web - Web APIs | MDN - определение WebGL, оборудование устройства, WebGL 2 (страница изменена 15 июля 2025 года).
• WebGL best practices - Web APIs | MDN - пределы системы, расширения, точность highp, ошибки (страница изменена 7 октября 2026 года).
• HTMLCanvasElement: getContext() method - Web APIs | MDN - значение null, failIfMajorPerformanceCaveat (страница изменена 2 июля 2025 года).
• HTMLCanvasElement: webglcontextlost event - Web APIs | MDN - событие потери контекста (страница изменена 28 июля 2026 года).
• Canvas API - Web APIs | MDN - определение, отметка Baseline, замечания о доступности (страница изменена 17 сентября 2026 года).
• 0 HTML graphics canvas element - HTML | MDN - альтернативное содержимое, предел размера (страница изменена 24 апреля 2026 года).
• WebGPU API - Web APIs | MDN - Limited availability, защищённый контекст (страница изменена 2 сентября 2026 года).
• WebGL Specification - параметры контекста, события потери и восстановления (Editor's Draft от 30 июня 2026 года).
• WebGL 2.0 Specification - назначение и статус документа (Editor's Draft от 30 июня 2026 года).
• Web Content Accessibility Guidelines (WCAG) 2.2 - критерии 1.1.1, 2.1.1, 2.2.2, 2.3.3 (рекомендация W3C от 12 декабря 2024 года).
• Understanding Success Criterion 1.1.1: Non-text Content | WAI | W3C - пояснение к критерию (страница обновлена 6 сентября 2026 года).
• Understanding Success Criterion 2.1.1: Keyboard | WAI | W3C - пояснение к критерию (страница обновлена 11 мая 2026 года).

Обсудить проект в Telegram: t.me/billioniks