Gerçekten yardımcı olan ARIA etiketleri için geliştirici rehberi

ARIA etiketleri isimler içindir, özürler için değil

ARIA yararlıdır, ancak çoğu zaman belirsiz HTML’i yamamak için kullanılır. Ekiplerin sorun yaşamaya başladığı yer de burasıdır.

En yaygın örnek aria-labeldır. Zararsız görünür: bir metin ekle, linter’ı memnun et, devam et. Ancak erişilebilir ad bir süs değildir. Pek çok yardımcı teknolojinin, kullanıcılar düğmeler, bağlantılar, form alanları, başlıklar, landmark’lar ve kontroller arasında gezinirken kullanıcıya sunduğu addır.

Bu ad belirsiz, yinelenen, güncelliğini yitirmiş ya da görünen etiketten farklıysa arayüzün kullanımı zorlaşır. Bazen daha da kötüsü olur: aria-label, DOM’da zaten bulunan daha iyi bir metni geçersiz kılabilir.

Amaç daha fazla ARIA eklemek değildir. Amaç, her arayüz öğesinin adını, rolünü, durumunu ve amacını netleştirmektir.

Erişilebilir ad, sade bir anlatımla

Çoğu etkileşimli öğenin bir erişilebilir adı vardır. Ekran okuyucular, öğenin ne olduğunu duyurmak için bu adı kullanır.

Örneğin:

<button>Save changes</button>

Bir ekran okuyucu şuna benzer bir şey duyurabilir: “Save changes, button.” Rol, yerel button öğesinden gelir. Ad ise içindeki metinden gelir.

İdeal durum budur: görünen metin ile erişilebilir ad eşleşir.

ARIA etiketleme öznitelikleri, görünen arayüz tam bir ad sağlamadığında ya da adın başka bir öğeden gelmesi gerektiğinde yararlı hale gelir. Başlıca öznitelikler şunlardır:

• aria-label: öğe üzerinde doğrudan bir metin sağlar.
• aria-labelledby: metni ad haline gelecek bir ya da daha fazla öğeye işaret eder.
• aria-describedby: ana ada değil, destekleyici açıklama metnine işaret eder.

Bu üçü ilişkilidir, ancak birbirinin yerine kullanılamaz.

İlk kural: yerel HTML’i ve görünen etiketleri tercih edin

Kontrolün üzerine görünen metin koyabiliyorsanız önce bunu yapın.

Bu daha iyidir:

<button>Delete invoice</button>

Şundan:

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

İkinci kalıp yalnızca ikon içeren bir düğme için geçerlidir. Ancak tasarım görünen metni kaldırabiliyorsa, görünen metin herkese yardımcı olur: ekran okuyucu kullanıcılarına, konuşma tanıma kullanıcılarına, bilişsel yük yaşayan kişilere, hızlıca tarayanlara ve çeviri araçları kullananlara.

Bu, erişilebilirlik çalışmalarında tekrar eden bir temadır. Yerel HTML ve görünen affordance’lar, gizli metaverilerden daha fazla sorunu çözer. Aynı ilke düğme semantiği için daha geniş ölçekte de geçerlidir; ekibiniz UI kontrollerini denetliyorsa, erişilebilir web düğmeleri için kontrol listemiz bu rehbere iyi bir eşlikçidir.

aria-label ne zaman doğru araçtır

Bir öğenin erişilebilir ada ihtiyacı varsa ve referans verilebilecek uygun bir görünen metin yoksa aria-label kullanın.

Klasik örnek yalnızca ikon içeren bir düğmedir:

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

Bu makuldür. Görünen ikon aramayı çağrıştırır, ancak SVG path’in kendisi güvenilir bir ad sağlamaz. aria-label bunu sağlar.

Diğer iyi kullanım örnekleri şunlardır:

• Yalnızca “X” ile gösterilen bir kapatma düğmesi.
• aria-label="Product" gibi daha belirli bir ada ihtiyaç duyan bir navigation landmark’ı.
• Görünen bağlamın düğme metninin parçası olmadığı yinelenen bir kontrol.

Örneğin:

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

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

İkisi de navigation landmark’ıdır, ancak etiketleri kullanıcıların landmark’lar arasında gezinirken bunları ayırt etmesine yardımcı olur.

aria-label ne zaman yanlış araçtır

Bir test bir öğenin etikete ihtiyacı olduğunu söylüyor diye aria-label eklemeyin. Önce işaretlemeyi düzeltin.

Kötü:

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

Daha iyi:

<button>Submit</button>

İlk örnek gereksiz iş çıkarır. Artık yerel düğmelerin zaten sağladığı klavye davranışını, devre dışı durumlarını, form davranışını ve beklentileri yeniden oluşturmanız gerekir.

Ayrıca görünen metni anlamı değiştirecek biçimde yeniden adlandırmak için aria-label kullanmaktan kaçının.

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

Bu küçük görünebilir, ancak konuşma girdisine güvenen kullanıcıların kafasını karıştırabilir. Görünen bir düğmede “Remove” yazıyorsa, ancak erişilebilir adı “Delete invoice” ise, “click Remove” demeye çalışan bir kullanıcı beklenen sonucu alamayabilir. WCAG’nin “label in name” gereksinimi tam da bu nedenle vardır: görünen metin genel olarak erişilebilir adın içinde yer almalıdır.

Daha iyi bir sürüm:

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

Çoğu zaman daha da iyisi:

<button>Remove invoice</button>

Görünen metin zaten varsa aria-labelledby kullanın

Etiket metni sayfada zaten varsa, aria-labelledby genellikle aria-labeldan daha iyidir.

Örnek:

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

Bölümün erişilebilir adı artık görünen başlıktan gelir. Metinleri yinelemekten kaçınırsınız; bu da çeviri hatalarını ve güncelliğini yitirmiş etiketleri azaltır.

Bu özellikle form grupları için yararlıdır:

<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>

Birçok durumda yerel legend, ARIA olmadan yeterlidir. Önemli olan, görünen etiketlerin öncülük etmesidir. ARIA mevcut anlamı bağlamalıdır; bunun ikinci bir özel sürümünü oluşturmamalıdır.

aria-describedby ad için değil, yardım metni için kullanılır

Açıklama etiket değildir.

Şu alanı düşünün:

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

Erişilebilir ad “Password”dır. Açıklama “Use at least 12 characters.”dır. Bir ekran okuyucu ikisini de duyurabilir, ancak farklı amaçlara hizmet ederler.

Bunu yapmayın:

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

Bu, alanı kavramın kendisiyle değil, talimatla adlandırır. Bir formda gezinen kullanıcı önce alanın ne olduğunu, sonra hangi kısıtlamaların geçerli olduğunu bilmek ister.

Bu ayrım hata durumlarında da önemlidir:

<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>

Etiket sabit kalır. Hata mesajı destekleyici bağlam haline gelir.

Yinelenen kontroller benzersiz adlara ihtiyaç duyar

Listeler ve kartlar, ARIA etiketlerinin çoğu zaman gerekli hale geldiği yerlerdir.

Kötü:

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

Düğmeler arasında gezinen bir ekran okuyucu kullanıcısı, bağlam olmadan üç kez “Delete, button” duyabilir.

İyi:

<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>

Bu, aria-label için meşru bir kullanımdır: görünen metin kısa kalırken erişilebilir ad nesneyi içerir.

Ancak bu kalıbı dikkatli kullanın. Nesne adı yakında görünüyorsa, aria-labelledby bakımı daha kolay olabilir:

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

Erişilebilir ad “Delete Q4 revenue” haline gelir. Bu, rapor başlığını bir öznitelikte yinelemeyi önler.

Her şeyi etiketlemeyin

Her öğenin bir ARIA etiketine ihtiyacı yoktur.

Statik metnin genellikle yoktur. Dekoratif ikonların yoktur. Anlamlı bir landmark ya da widget rolü olmadıkça kapsayıcıların da yoktur. Aşırı etiketleme, sayfayı gürültülü ve gezinmesi daha zor hale getirebilir.

Görseller için görsele özgü modeli kullanın: anlamlı görseller yararlı alt metnine ihtiyaç duyar; dekoratif görseller boş alt="" ister. İyi görsel metninin yerine ARIA etiketlerini kullanmayın. Ekibiniz bu kavramları karıştırıyorsa, pragmatik görsel alt metni yazısını yeniden inceleyin ve görsel alternatiflerini kontrol adlarından ayırın.

Yaygın bir hata, her SVG’ye aria-label vermektir. SVG bir düğmenin içindeyse ve düğmenin zaten bir adı varsa, ikon genellikle yardımcı teknolojiden gizlenmelidir:

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

Aksi halde kullanıcı, tarayıcı ve yardımcı teknoloji birleşimine bağlı olarak gereksiz ya da tuhaf duyurular duyabilir.

Yalnızca koda değil, hesaplanan ada bakın

Erişilebilirlik hataları çoğu zaman kod incelemesinden sağ çıkar, çünkü işaretleme makul görünür.

Modern tarayıcı geliştirici araçları, hesaplanan erişilebilirlik ağacını gösterebilir. Chrome, Edge, Firefox ve Safari’de öğeyi inceleyin ve rol, ad ve açıklama gibi erişilebilirlik bilgilerini arayın. Üç şeyi kontrol ediyorsunuz:

1. Rol beklediğiniz rol mü?
2. Erişilebilir ad net ve belirli mi?
3. Açıklama, adın yerine geçmeden yardımcı oluyor mu?

Ardından birkaç akışı gerçek bir ekran okuyucuyla test edin. Temel sorunları yakalamak için tam zamanlı bir yardımcı teknoloji uzmanı olmanız gerekmez. macOS’ta VoiceOver yerleşiktir. Windows’ta NVDA yaygın kullanılır ve ücretsizdir. Mobilde, ilgili yerlerde iOS’ta VoiceOver ve Android’de TalkBack ile test edin.

Otomatik araçlar yararlıdır, ancak “Open,” “Read more,” ya da “Delete” metninin yeterince bağlamsal olup olmadığını güvenilir biçimde söyleyemezler. Otomasyonu bir ağ gibi düşünün, yargıç gibi değil. Bu, performans denetimine benzer: bir rapor sizi şüpheli alanlara yönlendirebilir, ancak etkiyi yine de yorumlamanız gerekir. Paniğe kapılmadan Lighthouse raporu okumak için önerdiğimiz aynı sakin yaklaşım burada da geçerlidir.

Pratik bir inceleme kontrol listesi

ARIA etiketlerini yayına almadan önce şunları sorun:

• Bunun yerine yerel HTML olabilir mi?
• Etiket olarak kullanılması gereken görünen bir metin var mı?
• Görünen metin varsa, erişilebilir ad bunu içeriyor mu?
• Yinelenen kontroller, görsel bağlamın dışında gezinildiğinde benzersiz mi?
• Yardım metni etikete zorlanmak yerine aria-describedby ile bağlanmış mı?
• Dekoratif ikonlar yardımcı teknolojiden gizlenmiş mi?
• Birisi tarayıcı geliştirici araçlarında hesaplanan erişilebilir adı kontrol etti mi?
• Kritik akış için en az bir gerçek ekran okuyucu geçişi yapıldı mı?

Bu kontrol listesi, çoğu etiket sorununu kullanıcı sorununa dönüşmeden yakalar.

İyi ARIA’nın sessiz disiplini

İyi ARIA çalışması nadiren dramatiktir. Çoğunlukla ölçülülüktür.

Gerçek düğmeler kullanın. Gerçek etiketler kullanın. Görünen ve erişilebilir adları uyumlu tutun. aria-labelı yalnızca daha iyi bir görünen kaynak olmadığında ekleyin. Sayfa doğru metni zaten içeriyorsa aria-labelledby kullanın. Destekleyici talimatlar ve hatalar için aria-describedby kullanın.

Web platformu, onu doğrudan kullandığımızda geliştiricilere pek çok şeyi ücretsiz verir. ARIA boşluklar için vardır. Beceri, gerçekten bir boşluk olup olmadığını bilmektir.