Водич за програмере за ARIA ознаке које заиста помажу

ARIA ознаке су за називе, не за извињења

ARIA је корисна, али се често користи као закрпа за нејасан HTML. Ту тимови упадају у проблеме.

Најчешћи пример је aria-label. Делује безазлено: додате стринг, задовољите линтер и наставите даље. Али приступачан назив није декорација. То је назив који многе асистивне технологије излажу корисницима када се крећу по дугмадима, линковима, пољима формулара, насловима, оријентирима и контролама.

Ако је тај назив нејасан, дуплиран, застарео или другачији од видљиве ознаке, интерфејс постаје тежи за коришћење. Понекад и горе: aria-label може да надјача бољи текст који је већ био присутан у DOM-у.

Циљ није да се дода више ARIA. Циљ је да назив, улога, стање и сврха сваког елемента интерфејса буду јасни.

Приступачан назив, једноставним језиком

Већина интерактивних елемената има приступачан назив. Читачи екрана користе тај назив да најаве шта је елемент.

На пример:

<button>Save changes</button>

Читач екрана може да најави нешто попут: „Save changes, button.” Улога долази из нативног елемента button. Назив долази из текста унутар њега.

То је идеалан случај: видљиви текст и приступачан назив се поклапају.

ARIA атрибути за означавање постају корисни када видљиви интерфејс не обезбеђује потпун назив, или када назив мора да дође из другог елемента. Главни атрибути су:

• aria-label: обезбеђује стринг директно на елементу.
• aria-labelledby: упућује на један или више елемената чији текст постаје назив.
• aria-describedby: упућује на помоћни описни текст, не на главни назив.

Ова три атрибута су повезана, али нису међусобно заменљива.

Прво правило: предност дајте нативном HTML-у и видљивим ознакама

Ако можете да ставите видљиви текст на контролу, урадите то прво.

Ово је боље:

<button>Delete invoice</button>

Него ово:

<button aria-label="Delete invoice">
  <svg aria-hidden="true" focusable="false">...</svg>
</button>

Други образац је валидан за дугме које има само икону. Али ако дизајн може да поднесе видљиви текст, видљиви текст помаже свима: корисницима читача екрана, корисницима препознавања говора, људима под когнитивним оптерећењем, људима који брзо скенирају садржај и људима који користе алате за превођење.

Ово је тема која се стално враћа у раду на приступачности. Нативни HTML и видљиве назнаке могућности решавају више проблема него скривени метаподаци. Исти принцип важи и шире за семантику дугмади; ако ваш тим ради ревизију UI контрола, наша чек-листа за приступачну веб дугмад добар је пратећи материјал уз овај водич.

Када је aria-label прави алат

Користите aria-label када је елементу потребан приступачан назив, а не постоји одговарајући видљиви текст на који можете да се позовете.

Класичан случај је дугме које има само икону:

<button aria-label="Search">
  <svg aria-hidden="true" focusable="false" viewBox="0 0 24 24">
    <!-- icon -->
  </svg>
</button>

Ово је разумно. Видљива икона сугерише претрагу, али сама SVG путања не обезбеђује поуздан назив. aria-label га додаје.

Други добри случајеви укључују:

• Дугме за затварање представљено само знаком „X”.
• Навигациони оријентир ком је потребан конкретнији назив, као што је aria-label="Product".
• Поновљена контрола код које видљиви контекст није део текста дугмета.

На пример:

<nav aria-label="Primary">
  ...
</nav>

<nav aria-label="Footer">
  ...
</nav>

Оба су навигациони оријентири, али њихове ознаке помажу корисницима да их разликују када се крећу по оријентирима.

Када је aria-label погрешан алат

Не додајте aria-label само зато што тест каже да је елементу потребна ознака. Прво поправите markup.

Лоше:

<div role="button" tabindex="0" aria-label="Submit">Submit</div>

Боље:

<button>Submit</button>

Први пример ствара непотребан посао. Сада морате поново да направите понашање тастатуре, онемогућена стања, понашање формулара и очекивања која нативна дугмад већ обезбеђују.

Такође избегавајте коришћење aria-label за преименовање видљивог текста на начин који мења значење.

<button aria-label="Delete invoice">Remove</button>

Ово делује ситно, али може да збуни кориснике који се ослањају на говорни унос. Ако видљиво дугме каже „Remove”, али је његов приступачан назив „Delete invoice”, корисник који покуша да каже „click Remove” можда неће добити очекивани резултат. WCAG захтев „label in name” постоји управо из тог разлога: видљиви текст би, уопштено, требало да буде садржан у приступачном називу.

Боља верзија:

<button aria-label="Remove invoice">Remove</button>

Често је још боље:

<button>Remove invoice</button>

Посегните за aria-labelledby када видљиви текст већ постоји

Ако је текст ознаке већ на страници, aria-labelledby је обично бољи од aria-label.

Пример:

<h2 id="billing-title">Billing address</h2>
<section aria-labelledby="billing-title">
  ...
</section>

Приступачан назив секције сада долази из видљивог наслова. Избегавате дуплирање стрингова, што смањује грешке у преводу и застареле ознаке.

Ово је посебно корисно за групе формулара:

<fieldset aria-labelledby="shipping-speed-title">
  <legend id="shipping-speed-title">Shipping speed</legend>

  <label>
    <input type="radio" name="shipping" value="standard">
    Standard
  </label>

  <label>
    <input type="radio" name="shipping" value="express">
    Express
  </label>
</fieldset>

У многим случајевима, нативни legend је довољан без ARIA. Поента је да видљиве ознаке треба да воде. ARIA треба да повеже постојеће значење, а не да прави његову другу, приватну верзију.

Користите aria-describedby за помоћни текст, не за назив

Опис није ознака.

Размотрите ово поље:

<label for="password">Password</label>
<input id="password" type="password" aria-describedby="password-help">
<p id="password-help">Use at least 12 characters.</p>

Приступачан назив је „Password”. Опис је „Use at least 12 characters.” Читач екрана може да најави оба, али имају различите сврхе.

Немојте радити ово:

<input type="password" aria-label="Use at least 12 characters">

То поље именује по упутству, не по појму. Корисник који се креће кроз формулар жели прво да зна шта је поље, а затим која ограничења важе.

Ова разлика је важна и у стањима грешке:

<label for="email">Email</label>
<input
  id="email"
  type="email"
  aria-invalid="true"
  aria-describedby="email-error"
>
<p id="email-error">Enter an email address in the format [email protected].</p>

Ознака остаје стабилна. Порука о грешци постаје помоћни контекст.

Поновљене контроле треба да имају јединствене називе

Листе и картице су места где ARIA ознаке често постају неопходне.

Лоше:

<button>Delete</button>
<button>Delete</button>
<button>Delete</button>

Корисник читача екрана који се креће по дугмадима може три пута да чује „Delete, button” без контекста.

Добро:

<button aria-label="Delete report: Q4 revenue">Delete</button>
<button aria-label="Delete report: Hiring plan">Delete</button>
<button aria-label="Delete report: Vendor list">Delete</button>

Ово је легитимна употреба aria-label: видљиви текст остаје сажет, док приступачан назив укључује објекат.

Али користите овај образац пажљиво. Ако је назив објекта видљив у близини, aria-labelledby може бити лакши за одржавање:

<article>
  <h3 id="report-q4">Q4 revenue</h3>
  <button aria-labelledby="delete-q4 report-q4" id="delete-q4">Delete</button>
</article>

Приступачан назив постаје „Delete Q4 revenue.” Тиме се избегава дуплирање наслова извештаја у атрибуту.

Не означавајте све

Није сваком елементу потребна ARIA ознака.

Статички текст обично није. Декоративне иконе нису. Контејнери нису, осим ако имају значајну улогу оријентира или widget-а. Претерано означавање може да учини страницу бучном и тежом за навигацију.

За слике користите модел специфичан за слике: значајним сликама је потребан користан alt; декоративним сликама је потребан празан alt="". Не користите ARIA ознаке као замену за добар текст слике. Ако ваш тим меша те концепте, поново погледајте прагматичан alt текст за слике и раздвојте алтернативе за слике од назива контрола.

Честа грешка је додељивање aria-label сваком SVG-у. Ако је SVG унутар дугмета, а дугме већ има назив, икону обично треба сакрити од асистивних технологија:

<button aria-label="Open menu">
  <svg aria-hidden="true" focusable="false">...</svg>
</button>

У супротном, корисник може да чује сувишне или чудне најаве, у зависности од комбинације прегледача и асистивне технологије.

Проверите израчунати назив, не само код

Грешке у приступачности често преживе ревизију кода зато што markup изгледа уверљиво.

Савремени алати за програмере у прегледачима могу да прикажу израчунато стабло приступачности. У Chrome-у, Edge-у, Firefox-у и Safari-ју, прегледајте елемент и потражите информације о приступачности као што су улога, назив и опис. Проверавате три ствари:

1. Да ли је улога она коју очекујете?
2. Да ли је приступачан назив јасан и конкретан?
3. Да ли је опис користан без замењивања назива?

Затим тестирајте неколико токова са стварним читачем екрана. Не морате да постанете стручњак за асистивне технологије са пуним радним временом да бисте ухватили основе. На macOS-у је VoiceOver уграђен. На Windows-у се NVDA широко користи и бесплатан је. На мобилним уређајима тестирајте са VoiceOver-ом на iOS-у и TalkBack-ом на Android-у, где је релевантно.

Аутоматизовани алати су корисни, али не могу поуздано да кажу да ли је „Open”, „Read more” или „Delete” довољно контекстуално. Третирајте аутоматизацију као мрежу, не као судију. То је слично ревизији перформанси: извештај може да вас упути на сумњива места, али и даље морате да протумачите утицај. Исти смирен приступ који препоручујемо за читање Lighthouse извештаја без панике важи и овде.

Практична чек-листа за преглед

Пре испоруке ARIA ознака, питајте:

• Да ли би ово уместо тога могао да буде нативни HTML?
• Да ли постоји видљиви текст који треба користити као ознаку?
• Ако видљиви текст постоји, да ли га приступачан назив укључује?
• Да ли су поновљене контроле јединствене када се њима креће ван визуелног контекста?
• Да ли је помоћни текст повезан преко aria-describedby, а не насилно убачен у ознаку?
• Да ли су декоративне иконе сакривене од асистивне технологије?
• Да ли је неко проверио израчунати приступачан назив у алатима за програмере у прегледачу?
• Да ли је бар један пролаз стварним читачем екрана урађен за критичан ток?

Ова чек-листа хвата већину проблема са ознакама пре него што постану проблеми за кориснике.

Тиха дисциплина добре ARIA

Добар рад са ARIA ретко је драматичан. Углавном је реч о уздржаности.

Користите права дугмад. Користите праве ознаке. Држите видљиве и приступачне називе усклађеним. Додајте aria-label само када не постоји бољи видљиви извор. Користите aria-labelledby када страница већ садржи прави текст. Користите aria-describedby за помоћна упутства и грешке.

Веб платформа програмерима даје много тога бесплатно када је користимо директно. ARIA је ту за празнине. Вештина је знати када празнина заиста постоји.