Skip to main content
LibreTexts - Ukrayinska

4.9: Перевірка розмітки

  1. Last updated
  2. Save as PDF
  • Page ID
    103725

    • \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \) \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)\(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\) \(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\)

    Багато інструментів редагування HTML матимуть вбудовану перевірку розмітки, тому ви можете перевірити валідність коду під час його створення, але оскільки більшість сайтів є динамічно зібраними частинами, ці вбудовані валідатори мають обмежену корисність. Необхідно перевірити розмітку після того, як код був згенерований на веб-сторінці за допомогою таких інструментів, як HTML-валідатор W3C. Це інструмент, який ви повинні додати до свого інструментарію.

    Інструментарій: Закладка W3C Markup Validation Service, щоб додати його до вашого інструментарію.
    Технічні: Наступний вміст призначений для технічної аудиторії.

    Настанова WCAG 2.0, яка стосується перевірки розмітки, є настановою 4.1.1. Зверніть увагу, що синтаксичний аналіз є вимогою рівня А, тому, незважаючи на те, що деякі «необережні» код може обійтися без впливу на доступність, перевірка розмітки повинна бути виконана для того, щоб відповідати WCAG 2.0. Керівництво відтворюється нижче для довідки.

    4.1.1 Розбір: У вмісті, реалізованому за допомогою мов розмітки, елементи мають повні початкові та кінцеві теги, елементи вкладені відповідно до їх специфікацій, елементи не містять повторюваних атрибутів, а будь-які ідентифікатори унікальні, за винятком випадків, коли специфікації дозволяють ці функції. (Рівень А)

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

    Навіщо виконувати перевірку розмітки?

    Перевірка розмітки гарантує, що HTML веб-вмісту добре сформований і використовується таким чином, що відповідає специфікаціям HTML. Важливо, щоб HTML був чистим і правильно структурованим з наступних причин:

    • Допоміжні технології, такі як екранні читання, зазвичай покладаються на HTML для правильної інтерпретації вмісту. Технології намагатимуться виправити помилки розмітки самостійно, але є деякі помилки розмітки, які призводять до появи допоміжних технологій, таких як комірки таблиці, які не закриті, або дублікати ідентифікаторів, які використовуються на сторінці.
    • Чиста розмітка є ознакою якісної роботи, і перевірка HTML повинна бути те, що розробники роблять послідовно.
    • Чиста розмітка гарантує, що бар'єри не вводяться ненавмисно через зламаний код.

    Коли виконувати перевірку розмітки?

    Перевірку розмітки слід проводити якомога раніше в процесі аудиту доступності веб-сторінок. Це може допомогти виключити очевидні бар'єри при тестуванні вмісту за допомогою допоміжних технологій, тому корисно перевірити HTML перед тим, як проводити будь-яке тестування екранного читання. Детальніше про тестування екранної читалки ми поговоримо в розділі Тестування програми Screen Reader.

    Помітні обмеження перевірки розмітки

    Насправді може бути важко досягти 100% перевірки, а іноді може знадобитися відпустити помилки розмітки. Нижче наведено кілька прикладів ситуацій, які можуть вимагати рішення розробника та/або аудитора.

    ARIA в документі XHTML: Розробники можуть захотіти використовувати ARIA в XHTML документі, який не буде перевіркою, оскільки ARIA не є частиною специфікації XHTML (це частина HTML5). Використання ARIA в XHTML може покращити доступність, тому як аудитор ви можете ігнорувати ці помилки перевірки.

    Елементи HTML5: Якщо елементи HTML5, такі як NAV використовуються для створення панелі навігації, перевірка буде виробляти попередження, якщо роль ARIA = «навігація» використовується в цьому елементі. Елемент навігації, як передбачається, вже має роль навігації. Однак насправді існує непослідовна підтримка елемента nav, тому розробники часто додають role="navigation» як запасний варіант для технологій, які неправильно ідентифікують nav. З точки зору доступності, це не завадить мати зайві ролі в елементах HTML5.

    Зовнішні послуги: Інша поширена проблема перевірки виникає, коли розробники використовують зовнішні послуги в розмітці, яка вводить HTML третьої сторони в код сайту. Наприклад, оголошення Google від Adwords, як правило, містять помилки перевірки, хоча ці помилки не впливають на доступність.

    У всіх вищезазначених випадках необхідно судження, щоб вирішити, чи створює недійсна розмітка потенційний бар'єр чи ні, і чи слід повідомляти про ці помилки в аудиті доступності Інтернету. Такі помилки можуть призвести до невдачі сайту на рівні А, що може мати юридичні наслідки в юрисдикціях, які вимагають дотримання рівня А. Вони також можуть мати наслідки для аудиторів, які вирішили ігнорувати ці помилки та пройти сайт на рівні А, незважаючи на те, що HTML не перевіряється.

    Ключовий момент: Якщо сайт має рівень А відповідність будь-якій з цих помилок перевірки, пояснення повинно бути надано у звіті про аудит.

    Як працюють валідатори

    Подібно до автоматичних засобів перевірки доступності, можливо, щоб валідатор оцінював розмітку за допомогою URL-адреси, завантаження файлів або вставлення в HTML. Зверніть увагу, що HTML повинен бути повноцінним HTML-документом, з усіма необхідними компонентами, включаючи декларацію DOCTYPE, що відкриває HTML-елемент, елемент HEAD і Title, а також відкривають і закривають елементи BODY і закриває HTML-елемент в кінці документа.

    При запуску валідатора є безліч налаштувань, які можна регулювати, хоча стандартних налаштувань зазвичай достатньо. Один з варіантів, який ви можете увімкнути, - це «Показати джерело», який друкує HTML сторінки, що полегшує визначення того, де саме виникають проблеми на сторінці. Цей параметр та інші параметри показані на знімку екрана валідатора W3C, який наведено нижче. W3C Validator також визначатиме деякі проблеми зі спеціальними можливостями, такі як зображення, відсутні альтернативний текст або використання дублікатів ідентифікаторів всередині вмісту.

    Екран відкриття служби перевірки розмітки W3C

    Малюнок: Екран відкриття служби перевірки розмітки W3C, з різними параметрами відображаються

    ★ Повернутися до початку