M

MLOG

Türkçe

Erişilebilir toast bildirimleri oluşturmaya derinlemesine bir bakış. Küresel bir kitle için kapsayıcı geçici mesajlar oluşturmak üzere WCAG prensiplerini, ARIA rollerini ve UX en iyi uygulamalarını öğrenin.

Toast Bildirimleri: Erişilebilir, Kullanıcı Dostu Geçici Mesajlar Oluşturma

Dijital arayüzlerin hızlı dünyasında, bir sistem ile kullanıcısı arasındaki iletişim çok önemlidir. Eylemlerimizin sonuçlarını anlamak için görsel ipuçlarına güveniriz. Bu geri bildirim için en yaygın UI desenlerinden biri 'toast' bildirimidir; geçici bilgi sağlayan küçük, modal olmayan bir açılır pencere. İster "Mesaj gönderildi" onaylamak, ister "Dosya yüklendi" bildirmek veya "Bağlantınızı kaybettiniz" uyarısında bulunmak olsun, toast'lar kullanıcı geri bildiriminin ince işçileridir.

Ancak, geçici ve ince doğaları iki ucu keskin bir kılıçtır. Bazı kullanıcılar için minimum düzeyde rahatsız edici olsa da, bu özellik onları genellikle diğerleri, özellikle de ekran okuyucular gibi yardımcı teknolojilere güvenenler için tamamen erişilemez hale getirir. Erişilemeyen bir toast bildirimi sadece küçük bir rahatsızlık değildir; sessiz bir başarısızlıktır ve kullanıcıları belirsiz ve hayal kırıklığına uğratır. "Ayarlar kaydedildi" mesajını algılayamayan bir kullanıcı, ayarları tekrar kaydetmeyi deneyebilir veya değişikliklerinin başarılı olup olmadığından emin olmadan uygulamadan ayrılabilir.

Bu kapsamlı kılavuz, gerçekten kapsayıcı dijital ürünler oluşturmak isteyen geliştiriciler, UX/UI tasarımcıları ve ürün yöneticileri içindir. Toast bildirimlerinin doğasında var olan erişilebilirlik zorluklarını keşfedecek, ARIA (Erişilebilir Zengin İnternet Uygulamaları) kullanarak teknik çözümlere derinlemesine inecek ve herkese fayda sağlayan tasarım en iyi uygulamalarını özetleyeceğiz. Bu geçici mesajları erişilebilir bir kullanıcı deneyiminin kalıcı bir parçası haline getirmeyi öğrenelim.

Toast Bildirimleri ile Erişilebilirlik Zorluğu

Çözümü anlamak için önce sorunu derinlemesine anlamalıyız. Geleneksel toast bildirimleri, temel tasarım prensipleri nedeniyle genellikle birden fazla erişilebilirlik cephesinde başarısız olur.

1. Onlar Geçici ve Zamana Dayalıdır

Bir toast'ın tanımlayıcı özelliği, geçici varlığıdır. Birkaç saniye görünür ve sonra zarif bir şekilde kaybolur. Gören bir kullanıcı için bu genellikle mesajı taramak için yeterli süredir. Ancak, bir ekran okuyucu kullanıcısı için bu önemli bir engeldir. Bir ekran okuyucu içeriği doğrusal olarak duyurur. Kullanıcı bir form alanına odaklanmışsa veya okunan başka bir içeriği dinliyorsa, toast görünebilir ve ekran okuyucu ona ulaşmadan kaybolabilir. Bu, temel bir erişilebilirlik ilkesini ihlal ederek bir bilgi boşluğu yaratır: bilgi algılanabilir olmalıdır.

2. Odak Almıyorlar

Toast'lar müdahaleci olmayacak şekilde tasarlanmıştır. Kullanıcının mevcut görevinden odağı kasıtlı olarak çalmazlar. Gören bir kullanıcı, "Taslak kaydedildi" mesajı görünürken bir metin alanına yazmaya devam edebilir. Ancak, yalnızca klavye kullanan kullanıcılar ve ekran okuyucu kullanıcıları için odak, birincil gezinme ve etkileşim yöntemleridir. Toast hiçbir zaman odak sırasında olmadığı için, doğrusal bir gezinme yolu için görünmezdir. Kullanıcı, varlığını bile bilmediği bir mesaj için tüm sayfayı manuel olarak aramak zorunda kalacaktır.

3. Bağlam Dışı Görünüyorlar

Toast'lar genellikle ekranın ayrı bir bölgesinde, sağ üst veya sol alt köşede, onları tetikleyen öğeden (örneğin, bir formun ortasındaki bir 'Kaydet' düğmesi) uzakta görünür. Bu mekansal kopukluk, görme yoluyla kolayca köprülenir, ancak ekran okuyucular için mantıksal akışı bozar. Duyuru, gerçekleşirse, kullanıcının son eyleminden rastgele ve bağlantısız hissedilebilir ve bu da kafa karışıklığına neden olur.

WCAG'ye Bağlanma: Erişilebilirliğin Dört Temel İlkesi

Web İçeriği Erişilebilirlik Yönergeleri (WCAG) dört ilke üzerine kurulmuştur. Erişilemeyen toast'lar bunların birkaçını ihlal eder.

Teknik Çözüm: ARIA Canlı Bölgeler Yardımımıza Koşuyor

Toast bildirimlerini erişilebilir hale getirmenin anahtarı, ARIA spesifikasyonunun güçlü bir bölümünde yatmaktadır: canlı bölgeler. Bir ARIA canlı bölgesi, bir sayfada 'canlı' olarak belirlediğiniz bir öğedir. Bu, yardımcı teknolojilere bu öğenin içeriğindeki herhangi bir değişikliği izlemesini ve bu değişiklikleri kullanıcının odağını hareket ettirmeden duyurmasını söyler.

Toast bildirimlerimizi canlı bir bölgeye sararak, kullanıcının odağı nerede olursa olsun, içeriklerinin göründüğü anda ekran okuyucular tarafından duyurulmasını sağlayabiliriz.

Toast'lar için Temel ARIA Nitelikleri

Üç ana nitelik, toast'lar için etkili bir canlı bölge oluşturmak için birlikte çalışır:

1. role Nitelik

role niteliği, öğenin anlamsal amacını tanımlar. Canlı bölgeler için dikkate alınması gereken üç temel rol vardır:

2. aria-live Nitelik

role niteliği genellikle belirli bir aria-live davranışını ima etse de, daha fazla kontrol için açıkça ayarlayabilirsiniz. Ekran okuyucuya değişikliği *nasıl* duyuracağını söyler.

3. aria-atomic Nitelik

Bu nitelik, ekran okuyucuya canlı bölgenin tüm içeriğini mi yoksa yalnızca değişen kısımlarını mı duyuracağını söyler.

Hepsini Bir Araya Getirme: Kod Örnekleri

Bunu nasıl uygulayacağımızı görelim. En iyi uygulama, sayfa yüklemede DOM'da bulunan özel bir toast kapsayıcı öğesine sahip olmaktır. Daha sonra bu kapsayıcının içine tek tek toast mesajlarını dinamik olarak ekler ve kaldırırsınız.

HTML Yapısı

Bu kapsayıcıyı <body> etiketinizin sonuna yerleştirin. CSS ile görsel olarak konumlandırılmıştır, ancak DOM'daki konumu ekran okuyucu duyuruları için önemli değildir.

<!-- Standart bildirimler için kibar bir canlı bölge -->
<div id="toast-container-polite" 
     role="status" 
     aria-live="polite" 
     aria-atomic="true">
  <!-- Toast'lar buraya dinamik olarak eklenecek -->
</div>

<!-- Acil uyarılar için iddialı bir canlı bölge -->
<div id="toast-container-assertive" 
     role="alert" 
     aria-live="assertive" 
     aria-atomic="true">
  <!-- Acil toast'lar buraya dinamik olarak eklenecek -->
</div>

Kibar Bildirim için JavaScript

İşte kibar bir toast mesajı göstermek için vanilya JavaScript işlevi. Bir toast öğesi oluşturur, kibar kapsayıcıya ekler ve kaldırmak için bir zaman aşımı ayarlar.

function showPoliteToast(message, duration = 5000) {
  const container = document.getElementById('toast-container-polite');

  // Toast öğesini oluştur
  const toast = document.createElement('div');
  toast.className = 'toast';
  toast.textContent = message;

  // Toast'ı kapsayıcıya ekle
  container.appendChild(toast);

  // Toast'ı kaldırmak için bir zaman aşımı ayarla
  setTimeout(() => {
    container.removeChild(toast);
  }, duration);
}

// Örnek kullanım:
document.getElementById('save-button').addEventListener('click', () => {
  // ... kaydetme mantığı ...
  showPoliteToast('Ayarlarınız başarıyla kaydedildi.');
});

Bu kod çalıştığında, role="status" olan div güncellenir. Sayfayı izleyen bir ekran okuyucu, bu değişikliği algılayacak ve kullanıcının iş akışını kesintiye uğratmadan "Ayarlarınız başarıyla kaydedildi" mesajını duyuracaktır.

Gerçekten Kapsayıcı Toast'lar için Tasarım ve UX En İyi Uygulamaları

ARIA ile teknik uygulama temeldir, ancak mükemmel kullanıcı deneyimi düşünceli tasarım gerektirir. Erişilebilir bir toast aynı zamanda herkes için daha kullanılabilir bir toast'tır.

1. Zamanlama Her Şeydir: Kullanıcılara Kontrol Verin

3 saniyelik bir toast bazıları için iyi olabilir, ancak okumak için daha fazla zamana ihtiyaç duyan düşük görüşlü kullanıcılar veya bilgileri işlemek için daha fazla zamana ihtiyaç duyan bilişsel engelli kullanıcılar için çok kısadır.

2. Görsel Açıklık ve Yerleşim

Bir toast'ın nasıl göründüğü ve nerede göründüğü, etkinliğini önemli ölçüde etkiler.

3. Açık ve Özlü Mikro Kopya Yazın

Mesajın kendisi bildirimin özüdür. Önemli hale getirin.

4. Kritik Bilgiler için Toast'ları Kullanmayın

Bu altın kuraldır. Kullanıcının bir mesajı *görmesi* veya mesajla etkileşimde bulunması gerekiyorsa, bir toast kullanmayın. Toast'lar, tamamlayıcı, kritik olmayan geri bildirimler içindir. Kritik hatalar, kullanıcı eylemi gerektiren doğrulama mesajları veya yıkıcı eylemlerin (bir dosyayı silmek gibi) onayları için, modal bir iletişim kutusu veya odak alan satır içi bir uyarı gibi daha sağlam bir desen kullanın.

Erişilebilir Toast Bildirimlerinizi Test Etme

Uygulamanızın, kullanıcılarınızın gerçekten kullandığı araçlarla test etmeden erişilebilir olduğundan emin olamazsınız. Manuel test, toast'lar gibi dinamik bileşenler için vazgeçilmezdir.

1. Ekran Okuyucu Testi

En yaygın ekran okuyuculara aşina olun: NVDA (ücretsiz, Windows için), JAWS (ücretli, Windows için) ve VoiceOver (yerleşik, macOS ve iOS için). Bir ekran okuyucu açın ve toast'larınızı tetikleyen eylemleri gerçekleştirin.

Kendinize sorun:

2. Yalnızca Klavye ile Test

Farenizi çıkarın ve sitenizde yalnızca klavyeyi (Tab, Shift+Tab, Enter, Spacebar) kullanarak gezinin.

3. Görsel ve Kullanılabilirlik Kontrolleri

Sonuç: Her Seferinde Bir Bildirimle Daha Kapsayıcı Bir Web Oluşturmak

Toast bildirimleri, kullanıcı deneyiminin küçük ama önemli bir parçasıdır. Yıllardır, web erişilebilirliğinde yaygın bir kör nokta olmuş ve yardımcı teknolojilerin kullanıcıları için sinir bozucu bir deneyim yaratmıştır. Ama böyle olmak zorunda değil.

ARIA canlı bölgelerinin gücünden yararlanarak ve düşünceli tasarım ilkelerine bağlı kalarak, bu geçici mesajları engellerden köprülere dönüştürebiliriz. Erişilebilir bir toast sadece teknik bir onay kutusu değildir; *tüm* kullanıcılarla net iletişime bağlılıktır. Herkesin, yeteneklerine bakılmaksızın, aynı kritik geri bildirimi almasını ve uygulamalarımızı güven ve verimlilikle kullanabilmesini sağlar.

Erişilebilir bildirimleri endüstri standardı yapalım. Bu uygulamaları tasarım sistemlerimize ve geliştirme iş akışlarımıza yerleştirerek, gerçekten küresel bir kitle için daha kapsayıcı, sağlam ve kullanıcı dostu bir web oluşturabiliriz.