Управління заголовними рівнями в системах проектування

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

Застосування правильного рівня заголовка - це питання контексту. Наприклад, два послідовних заголовки того самого рівня описують два розділи, які містяться в однорідному документі. Якщо другий з наступних заголовків є вищим рівнем, він описує підрозділ, що належить до розділу першого заголовка.

alt text = на зображенні є два поля один за одним, позначені як побратими на рівні h2. Всередині другого поля - третє поле, позначене як підрозділ рівня h3.

HTML5 пообіцяв автоматизувати ці відносини, відклавши алгоритм введення в

s (або інші елементи секціонування). Ідея полягала в тому, що, буквально вкладаючи батьківські
елементи в DOM, рівні їх заголовків будуть безкоштовно коригуватися в дереві доступності. (Дерево доступності - це інтерпретація DOM, що передається такому програмному забезпеченню, як зчитувачі екрану.)

<секція>
  

Заголовок розділу

  <секція>     ` для читачів екрану ->     

Заголовок підрозділу

  

На жаль, на сьогоднішній день жоден великий постачальник браузера не змістовно реалізував цей так званий "алгоритм викладки документів". І якщо веб-переглядач не відкриває його, читачі екранів не можуть його передавати. Останній приклад коду просто не працював.

Тим, хто нас зацікавив у створенні доступних контурів документів, тому застрягли, вибираючи рівні заголовка (

до

) незалежно від
s, який ми можемо використовувати.

<секція>
  

Заголовок розділу

  <секція>     

Заголовок підрозділу

  

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

alt text = На зображенні показано, що компонент може бути повторно використаний у різних контекстах сторінки. Залежно від контексту, компонент повинен мати рівень h2 або h3 заголовка.

Підсилювач рівня

Такі API, як React і Vue, дозволяють нам вручну включати властивості (або "реквізити") для наших компонентів під час інстанції. Вони дозволяють застосувати певні налаштування до екземпляра компонента, щоб їх використовувати внутрішньо.

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

 

Всередині нам потрібно взяти встановлений рівень і використовувати його для збільшення принципового заголовка компонента. Є кілька способів зробити це. Перший спосіб полягає у використанні певної логіки, яка обирає для нас правильний елемент заголовка (

до

). У React ми можемо використовувати компонент як змінну:

render () {
  const H = 'h' + this.props.level;
  повернути (
    
       Заголовок деякого рівня       

Lorem ipsum тощо.

    
  ); }

Це швидко стане непростим при підтримці структури декількох заголовків всередині компонента (див. Поданий розділ). Натомість ми можемо безпосередньо змінити рівень елемента заголовка в дереві доступності через властивість рівня арії.

Дві речі, які слід зазначити:

  • Елемент

    використовується як "розумний дефолт". Усі підрозділи першого рівня, що відповідають заголовку сторінки

    на сторінці, мають бути другого (

    ) рівня. Якщо опора рівня не передбачена, рівень арії не застосовується, а неявний другий рівень виступає за замовчуванням (нульове значення означає, що атрибут не надається).

  • вже має неявну роль заголовка, тому використання role = "header" було б зайвим. Якби ми використовували
    для визначення свого заголовка, роль = "заголовок" знадобилася б поряд із рівнем арій. Це не рекомендується, оскільки підтримка відносно мізерна. Принаймні там, де рівень арії не підтримується, у нас все ще є заголовок

    - навіть якщо це не правильний рівень. Заголовками будь-якого рівня можна переміщуватися між екранами, як NVDA або JAWS, за допомогою клавіші h.

Кілька заголовків

У деяких випадках піддерево, що становить наш компонент, може містити кілька заголовків, що описують мікроструктуру в документі. Жорстке кодування кожного рівня за допомогою власної опори було б багатослівним і схильним до помилок з боку автора.


 

Натомість ми можемо підтримувати ту саму структуру, застосовуючи просту арифметику.

Текст заголовка

Lorem ipsum.

Текст підзаголовка

Lorem ipsum.

Вкладений текст підзаголовка

Lorem ipsum.

Тепер автору залишається лише застосувати один рівень на момент інстанції (якщо це потрібно!), І вся структура зміщується відповідно. Простий, але ефективний.

Повна автоматизація

Чи знаєте ви, що елемент був спочатку зафіксований ще в 1991 році, і він би автоматизував рівні заголовків таким чином, як передбачається "Алгоритм контуру документа"? Насправді це все ще обговорюється.

Як мені продемонструвала видатна Софі Альперт, можна наслідувати цю автоматизовану поведінку контуру за допомогою відносно нового API контексту React.

Краса контексту полягає в тому, що ви можете - цитувати документи - "передавати дані через дерево компонентів без необхідності передавати реквізити вручну на кожному рівні". На практиці це означає, що ми можемо регулювати значення рівня, просто вклавши компоненти.

Спочатку треба ініціалізувати контекст.

const Level = React.createContext (2);

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

функція Розділ (реквізит) {
  повернути (
     {level =>
      
        {props.children}
      
    } 
  );
}
функція H (реквізит) {
  повернути (
     {level => {
      const Heading = 'h' + Math.min (рівень, 6);
      повернути <Заголовок {... реквізит / /;
    }} 
  );
}

Розділ споживає значення рівня для цього рівня гніздування (через Level.Consumer), а потім коригує рівень для будь-яких дітей (рівень + 1).

Якщо будь-який елемент Н споживає контекстний рівень, Math.min забезпечує, щоб не відображалися заголовки вищого рівня, ніж 6. або не слід інтерпретувати браузер як заголовок, що спричиняє розбір і, отже, недоліки доступності.

Окрім капіталізації (і React!), Ми можемо зараз структурувати щось дуже близьке до того, що TimBL спочатку уявляв:

функція Документ (реквізит) {
  повернути (
    
      

Автоматизація глибини заголовка

      <Розділ>          рівень 2          Близький рівень 2         <Розділ>            3 рівень                        рівень 2       

Lorem ipsum dolor sit тощо.

    
  ); }

Будь-який компонент, що використовує Level.Provider та Level.Consumer, може бути зроблений з дотриманням контуру, усвідомленого контекстом. Для компонентів, які містять вміст, але їх не можна вважати семантичними підрозділами, рівень можна просто пропустити та повторно використовувати, як є - не збільшувати.

Стилізація

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

є найбільшою чи найвизначнішою.

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

h1, [aria-level = "1"] {font-size: 3rem}
h2, [aria-level = "2"] {font-size: 2.25rem}
h3, [aria-level = "3"] {font-size: 1.75rem}
/ * тощо * /

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

 Заголовок тексту 

Використовуючи бібліотеку на зразок стильових компонентів, ви створювали б нові заголовки на основі семантичного компонента H та безпосередньо стилювали їх. Вам просто потрібно продовжити H:

const Heading = H.extend`
  розмір шрифту: 2rem;
`;

Заголовки все ще мають значення

Деякі розробники веб-додатків мають звичку видавати все, що вони вважають, "з епохи простих документів". Це правда, що заголовки походять із традиції маркування статичних, прозаїчних документів, таких як ті, які ви можете написати в MS Word чи подібних. Але думати, що в інтерфейсі програми немає необхідної структури звукових заголовків - це неправильно зрозуміти, що саме є заголовками.

Заголовки - це мітки для розділів (або "областей", якщо вам зручніше), що складають інтерфейс. Вони можуть позначати розділ інформації або набір інтерактивних елементів керування. Це все одно. Позначення розділів інтерфейсу так само важливо, як і маркування окремих елементів управління. Без етикетки люди просто не знають, для чого це потрібно.

Для користувачів зчитувачів екранів заголовки - це не просто мітки, а механізм "байпас", який дозволяє їм переходити між різними областями. Без заголовків вони повинні по черзі перебирати кожен елемент, щоб дістатися з одного місця в інше. Напружений і неприхований.

Користувачі клавіатури, які не мають зчитувач екрана, що підтримує ці ярлики, можуть вважати їхній досвід досить важким - особливо там, де існує величезна кількість інтерактивних елементів керування. На щастя, на допомогу доступне розширення браузера від Метка Аткінсона. Він надає ярлики не до заголовків, а до знакових елементів (

,
,
тощо), але також враховується підтримка заголовків. Найкращі структури документів (та програми!) Включають як орієнтири, так і заголовки. Пояс і брекети.

Більш детальну інформацію про інклюзивні системи дизайну та дизайну див. Https://inclusive-components.design/ та слідкуй за включенням компонентів у Twitter.