İyi Bir Arayüzün Görünmeyen Kuralları: Bileşenler, Etkileşimler ve Erişilebilirlik

Mobil UX/UI Tasarım Rehberi — Bilimden Ekrana · Makale #02

Bir düğmeye dokundunuz. Rengi değişti, küçük bir halka döndü, ardından ekran eski görünümüne döndü. Bir an beklediniz. İşlem tamamlandı mı? Bağlantı mı kesildi? Yeniden dokunursanız aynı kayıt iki kez mi oluşacak? Ekran hareket etti, fakat size en gerekli bilgiyi vermedi: yaptığınız işlemin sonucunu.

Bu belirsizlik küçük bir ayrıntı değildir. Kullanıcı ya sonucu tahmin ederek devam eder ya da emin olmak için aynı işi tekrar yapar. Arayüz, bir dokunuşu algıladığını göstermiş olabilir; şimdi bunun neye dönüştüğünü de anlatmalıdır.

İyi bir arayüzün görünmeyen kuralları burada devreye girer: aynı eylemin her yerde anlaşılır davranması, beklemenin açıklanması, hatadan sonra bir çıkış yolu bulunması ve metin büyüdüğünde işlevlerin kullanılabilir kalması. Bunları tek bir ekran görüntüsünde görmek zordur. Ürünü kullanırken ise güvenimizi bu ayrıntılar üzerinden kurarız.

Serinin ilk yazısında mobil UX/UI tasarımının temellerini görev, keşfedilebilirlik ve bilgi mimarisi üzerinden ele aldık. Şimdi tek bir ekranın düzeninden, farklı durumlarda anlamını koruyan arayüz davranışına geçiyoruz. Bu yazıyı bağımsız okuyabilirsiniz; örneklerdeki amaç, bir alışkanlığı işaretlemek gibi sıradan bir görevin arkasındaki tasarım kararlarını görünür kılmak.

Bileşen Tasarımı: Görünüşle Birlikte Davranışı Tanımlamak

Bir bileşen, tekrar kullanılan arayüz parçasıdır: düğme, metin alanı, alışkanlık kartı veya açılır menü. Tasarım dosyasında aynı kartı çoğaltmak başlangıç olabilir. Tutarlı bir sistem kurmak için kartın hangi bilgileri taşıdığını, hangi eylemleri sunduğunu ve kullanıcının girişine nasıl yanıt verdiğini de tanımlamak gerekir.

Örneğin “Tamamla” düğmesinin üç ekranda aynı renkte görünmesi tek başına yeterli değildir. Bir yerde kaydı değiştirmesi, başka yerde ayrıntı açması, üçüncü yerde açıklama göstermesi ortak görünümün anlamını bozar. Önce bileşenin görevini yazın; sonra görünüşünü bu göreve bağlayın. Benzer bir sorunda var olan bileşeni kullanmadan önce davranışın gerçekten aynı olup olmadığını kontrol edin.

Ortak değerlerden ortak kararlara

Renk, boşluk ve tipografi değerlerini ortak isimlerle yönetmek bakım işini kolaylaştırır. “Koyu mavi” yerine “ana eylem”, “küçük gri yazı” yerine “yardımcı açıklama” gibi roller, değerin neden kullanıldığını anlatır. Ancak hata, başarı ve seçim gibi anlamları tek renge yüklememek gerekir. Metin ve simge desteği de bileşenin tanımına girmelidir.

Her temel bileşen için kısa bir kullanım kaydı hazırlayabilirsiniz. Ne işe yarar, üzerinde ne yazar, klavyeyle nasıl kullanılır, beklerken ve hata verdiğinde nasıl görünür? Ekran okuyucuya iletilecek adı ve durumu da bu kayda ekleyin. Uzun Türkçe metin, boş veri ve büyük yazı örnekleriyle başlayın. Böylece aynı bileşeni başka ekranda kullanırken önceki kararları yeniden keşfetmek zorunda kalmazsınız.

Bileşen Durumları: Dokunmak ile Kaydetmek Aynı Şey Değildir

Bir düğmenin basılı görünmesi, parmağın veya başka bir giriş yönteminin algılandığını anlatır. Verinin kaydedildiğini kanıtlamaz. Google’ın etkileşim belgeleri, basma, bırakma ve iptal gibi olayları ayırır. Ürünün “bekliyor”, “kaydedildi” veya “eşitlenemedi” durumlarını ayrıca tasarlamak gerekir.

Odaklanmış, basılı, seçili ve devre dışı durumlar da birbirinin yerine geçmez. Klavye odağı, sıradaki komutun hangi denetime gideceğini belirtir. Seçili durum, örneğin etkin filtrenin hangisi olduğunu anlatır. Bir düğme hem odaklanmış hem seçili olabilir. Bunları tek görsel varyanta indirgemek yerine, birlikte oluştuklarında anlamın korunup korunmadığına bakın.

Geçişleri olay ve sonuçla yazın

İkili bir alışkanlık için basit bir akış tasarlayalım: “Henüz tamamlanmadı → işlem başlatıldı → kayıt doğrulandı → tamamlandı.” Başarısızlıkta son doğrulanmış durumu korumayı ve yeniden deneme sunmayı seçebiliriz. Bu, öğretici bir tasarım örneğidir. Miktar eklenen bir alışkanlıkta ikinci dokunuş yeni bir miktar kaydedebilir; aynı akışı her türe uygulamadan önce eylemin anlamını netleştirmek gerekir.

Her geçiş için üç soruyu yanıtlayın: Onu ne başlatıyor, kullanıcı ne görüyor, hangi veri değişiyor? Sonra işlemin iptal edilmesini, art arda dokunmayı, başka ekrana gidip geri dönmeyi deneyin. Tasarımın açıklığa en çok ihtiyaç duyduğu anlar, çoğu zaman bu kesintilerde ortaya çıkar.

Devre dışı bırakılmış bir düğmenin gerekçesi de anlaşılmalıdır. “Kaydet” kullanılamıyorsa eksik alanı yakında açıklayın. Kullanıcıyı düğmenin neden çalışmadığını keşfetmeye zorlamayın. Özellikle devre dışı denetim klavye odağı almıyorsa, açıklamaya yalnızca o denetimin üzerine gelerek ulaşılabilmesi yeterli bir çözüm değildir.

Boş durumları da birbirinden ayırın. Henüz hiç alışkanlık oluşturulmamış olması, seçili filtrede sonuç bulunmaması ve verinin yüklenememesi aynı ekranı gerektirmez. İlkinde oluşturma yolu sunabilirsiniz; ikincisinde filtreyi değiştirmeyi önerebilirsiniz; üçüncüsünde erişim sorununu açıklamak gerekir. Üçüne de “Henüz bir şey yok” yazmak, kullanıcıyı yanlış çözüme yöneltebilir. Her durum metninin yanında, o durumda yapılabilecek gerçek bir eylem tanımlayın.

Geri Bildirim ve Hata Önleme: Kullanıcıya Devam Edecek Bir Yol Vermek

Geri bildirim iki soruyu yanıtlamalıdır: Ne oldu ve şimdi ne yapabilirim? Gönderimin başarısız olduğu biliniyorsa “Kayıt gönderilemedi. Yeniden deneyebilirsiniz” mesajı, genel bir hata uyarısından daha kullanışlıdır. “Verileriniz güvende” demek içinse kaydın gerçekten korunduğundan emin olmak gerekir. Mesajın dili, ürünün bildiğinden fazlasını vaat etmemelidir.

Bazı uygulamalarda kayıt önce cihazda tutulur, sonra sunucuyla eşitlenir. Böyle bir yapıda “Bu cihazda kaydedildi; eşitleme bekliyor” açıklaması iki aşamayı ayırabilir. Bu mesaj ancak cihazdaki kayıt başarılıysa kullanılmalıdır. İşlemin ne kadarının tamamlandığı bilinmiyorsa yüzde göstermek yerine, neyin beklendiğini söylemek daha dürüst bir geri bildirimdir.

Hata mesajını hatalı alanla ilişkilendirin

Bir form hedef miktarı bekliyorsa birimi girişten önce gösterin: dakika, kilometre veya tekrar. Alan boşken kullanıcı henüz yazmaya başlamadan sert bir hata göstermek yerine, gerekli bilgiyi zamanında sunmayı değerlendirin. Gönderim başarısız olduğunda girilmiş geçerli değerleri korumak da toparlanmanın parçasıdır.

Kırmızı çerçeve bir sorun olduğunu gösterebilir; neyin eksik olduğunu açıklamaz. “Hedef miktarı eksik” mesajını ilgili alanın yanında göstermek ve alanla ilişkilendirmek, kullanıcıya düzeltme için bir başlangıç verir. A düzeyindeki WCAG 3.3.1, otomatik saptanan giriş hatasında ilgili öğenin belirtilmesini ve hatanın metinle açıklanmasını ister; mesajın alan yanında bulunması ise burada önerdiğimiz yerleşim kararıdır.

Korumanın biçimini işlemin sonucuna göre seçin. Günlük bir işaretlemeyi düzeltmek için geri alma yolu yeterli olabilir; çok sayıda kaydı silerken kapsamı açıkça gösteren bir onay gerekebilir. AA düzeyindeki WCAG 3.3.4, kapsadığı hukuki, mali ve veri işlemlerinde geri çevrilebilirlik, giriş kontrolü veya sonlandırmadan önce gözden geçirme ve onay mekanizmalarından en az birini ister. Her basit kaydetmede onay penceresi açılması gerektiğini söylemez.

Geri alma için de yalnızca bir düğme çizmek yetmez. Kullanıcı bu sırada başka bir kaydı değiştirdiyse hangi işlem geri alınacak? İşlem geçmiş veriyi etkiliyorsa ne geri gelecek? Kısa süre sonra kaybolan bildirimin dışında düzeltme yolu var mı? Bu soruları ürünün veri davranışıyla birlikte yanıtlayın. “Geri al” eyleminin kapsamını tarif edemiyorsanız görsel tasarım tamamlanmış olsa da etkileşim kararı henüz tamamlanmamıştır.

Görsel Hiyerarşi ve Bilişsel Yük: Değişen Ekranda Önceliği Korumak

İlk yazıda öğelerin önem sırasını ele aldık. Buradaki yeni soru, ekran değiştiğinde bu sıranın korunup korunmadığıdır. Bir hata mesajı açıldığında ana eylem kayboluyor mu? Kaydetme sırasında kartın yüksekliği değişip başka bir hedef parmağın altına geliyor mu? Başarı bildirimi, kullanıcının bir sonraki adımını kapatıyor mu?

Fotoğraf kompozisyonunda kadrajdaki parlak bir bölge ana konuyla yarışabilir. Arayüzde de büyük bir sayı, renkli rozet veya hareketli öğe gereksiz rekabet yaratabilir. Bu bağlantıyı bir düşünme aracı olarak kullanabiliriz; fotoğrafa bakmakla görev tamamlamak aynı etkinlik değildir. Arayüzde hangi bilginin önce görülmesi gerektiğini kullanıcının o anki amacı belirler.

Bir alışkanlık kartında ad, günlük durum ve eylem birlikte okunmalıdır. Seri bilgisiyle günlük tamamlanma birbirinden ayrılmalıdır; beş günlük seri, bugünün kaydedildiğini tek başına söylemez. Beklenmedik bir hata olduğunda da mesajın hangi karta ait olduğu belli kalmalıdır. Ekranın tepesindeki bağlamsız bir uyarı, çok sayıda kart arasında bu ilişkiyi kurmayabilir.

Bu durumda bilişsel yükü değerlendirmek için kişinin neleri aklında tutması gerektiğine bakabilirsiniz. Eski değerle yenisini karşılaştırmak için başka ekrana gitmesi gerekiyor mu? Hangi kartın kaydedilemediğini hatırlaması mı bekleniyor? Bağlamı ilgili yerde göstermeyi deneyin ve görevin anlaşılmasına etkisini gözlemleyin. Ekrandaki öğeleri azaltmak, bu soruları kendiliğinden çözmez.

Tipografi ve Metin Ölçeklendirme: Kartın Değil, Metnin İhtiyacını İzlemek

Tipografik sistemin sınavı kısa örnek metinle bitmez. “Su” etiketine uygun görünen bir kart, “Akşam yemeğinden sonra yirmi dakika yürüyüş” adıyla sorun çıkarabilir. Türkçe karakterler, çok satırlı açıklamalar ve farklı sayı biçimleriyle çalışın. Başlık, durum ve hata açıklamasının aynı anda bulunduğu en yoğun örneği özellikle deneyin.

Bir ad sığmadığında yazıyı sürekli küçültmek, kullanıcının büyütme tercihine karşı çalışabilir. Önce satır kaydırmayı, kabın büyümesini ve yardımcı içeriğin yerleşimini değerlendirin. Kısaltma gerekiyorsa karar vermek için gereken anlamın görünür kalıp kalmadığını ve tam içeriğe erişimin bulunup bulunmadığını kontrol edin.

Metin alanlarını yalnızca boyutla ayırmaya da çalışmayın. Kart adı, hedef ve hata mesajı aynı büyüklükte olsa bile konum, ağırlık ve anlaşılır sözcüklerle farklı roller taşıyabilir. Yardımcı bilgiyi geri plana almak için aşırı soluklaştırmak okunabilirliği bozabilir. Uzun bir hata açıklamasının satır aralığını, yanındaki simgenin hizasını ve düğmeyle ilişkisini birlikte inceleyin. Okunabilirlik, seçilmiş yazı karakterinden daha geniş bir yerleşim sorusudur.

Büyütme ve yeniden akış ayrı denetimlerdir

WCAG 1.4.4, altyazılar ve metin görüntüleri istisnalarıyla metnin yüzde 200’e kadar içerik veya işlev kaybı olmadan büyütülebilmesini ister. 1.4.10 yeniden akış ölçütü ise yatay yazılan içerik için 320 CSS piksel genişliğe eşdeğer alanda iki yönlü kaydırma gereksinimini ele alır; anlaşılması veya işlevi için iki boyutlu düzen gerektiren içerik bölümleri istisnadır. İkisi de AA düzeyindedir.

Apple’ın Dynamic Type açıklaması, destekleyen uygulamalarda metin stilleri aracılığıyla kişinin yazı boyutu tercihine yanıt vermeyi anlatır. Web’deki büyütme farklı bir mekanizmayla çalışır. Her ikisini değerlendirirken aynı pratik sorudan başlayabilirsiniz: yazı büyüdüğünde kart adı, durum ve eylem birlikte kullanılabilir kalıyor mu?

Mikro Etkileşimler ve Animasyon: Anlamı Zamana Yaymak

Mikro etkileşim, bir denetimin etkinleşmesi veya kaydın güncellenmesi gibi küçük bir görevin çevresindeki yanıttır. Her mikro etkileşim animasyon gerektirmez. Bir onay işareti, kısa durum metni veya uygun bir dokunsal geri bildirim aynı görevin farklı parçalarını destekleyebilir. Ses ve titreşim kullanılıyorsa kritik bilgi yine görsel ve erişilebilir biçimde bulunmalıdır.

Animasyon için önce neyi anlattığını yazın. Bir öğenin ayrıntıya dönüşmesi ilişkiyi gösterebilir; tamamlanma işareti yeni durumu belirginleştirebilir. Aynı anda bütün kartların sıçraması ise kullanıcının takip ettiği noktayı değiştirebilir. Süreyi seçerken de yalnızca tasarım dosyasındaki akıcılığa bakmayın: yavaş cihazda, hızlı tekrar girişinde ve kesilen geçişte davranışın anlaşılır kalması gerekir.

Hareketi azaltırken sonucu koruyun

Hareket azaltma, yani reduced motion tercihi etkin olduğunda aynı görevi yeniden deneyin. WCAG 2.3.3, etkileşimle tetiklenen hareket animasyonlarının, işlev veya iletilen bilgi için zorunlu olmadıkça kapatılabilmesini ister. Bu ölçüt AAA düzeyindedir ve özellikle etkileşim kaynaklı hareketi ele alır.

Web’de `prefers-reduced-motion` tercihine yanıt verirken yalnızca stil dosyasındaki geçişleri değil, kodla başlatılan hareketleri de inceleyin. Apple’ın Reduced Motion değerlendirme rehberi, rahatsızlık yaratabilecek hareketleri kaldırmayı veya değiştirmeyi, anlam taşıyan geri bildirimi ise korumayı önerir. Bir halkanın dolma hareketi kaldırıldığında “Tamamlandı” bilgisi kaybolmamalıdır.

Erişilebilirlik: Görsel Durumun Ötesindeki Arayüz

Kontrastı yalnızca varsayılan ekranın bir özelliği olarak ölçmeyin. Açık ve koyu temayı, seçili öğeyi, hata metnini ve odak göstergesini ayrı inceleyin. Bir kartın arka planı değiştiğinde daha önce okunabilen yardımcı metin yetersiz kalabilir.

WCAG 1.4.3, normal metinde en az 4,5:1; büyük metin tanımını karşılayan metinde 3:1 oranını ister. Büyük metin eşiği en az 18 punto veya kalın yazıda 14 puntodur; burada CSS punto ölçüsü söz konusudur. Ölçütün logo ve etkin olmayan denetim metni gibi istisnaları vardır. Metin dışı kontrast ise denetimleri ve durumlarını tanımak için gerekli görsel bilgide, belirtilen istisnalar dışında, komşu renklere karşı 3:1 ister. Ölçümü, anlamı taşıyan bilgi üzerinden yapın; her dekoratif çizgi bu kapsamda değildir.

Klavye odağı, erişilebilir ad ve durum bildirimi

Mobil ürünlerin klavyeyle kullanılabileceğini hesaba katın. WCAG 2.1.1, işlevleri klavye arayüzüyle kullanabilmeyi ister; hareket yoluna bağımlı temel işlevler için sınırlı bir istisna tanımlar. Kartlar arasında gezinirken mantıklı odak sırasını, görünür odağı ve menüden çıkınca devam edilecek yeri kontrol edin. AA düzeyindeki 2.4.11, odaklanan bileşenin yazarın oluşturduğu içerik tarafından tamamen örtülmemesini ister. Bileşeni bütünüyle görünür tutmak daha iyi bir tasarım hedefidir.

Web’de uygun yerleşik HTML denetimleriyle başlamak, davranışın temelini sağlar. Bir kutuya `role=”button”` eklemek klavye davranışını kendiliğinden getirmez; WAI-ARIA uygulama rehberi bu sorumluluğu açıkça anlatır. Düğme örüntüsü Enter ve Space ile etkinleştirmeyi tanımlar. İki durumlu düğmede `aria-pressed` kullanılacaksa etiketin sabit kalması gibi ayrıntılar da tasarım kararına dahildir.

Ekranda beliren “Kaydedildi” mesajının ekran okuyucuya iletilmesi ayrıca düşünülmelidir. WCAG 4.1.3, kapsamındaki durum mesajlarının odak almadan yardımcı teknolojiye sunulabilecek şekilde programatik belirlenmesini ister. Her güncellemede odağı mesaja taşımak veya bütün kartları tekrar okutmak kullanıcıyı bölebilir. Bildirimin ilgili kaydı ve sonucu kısa biçimde anlatmasını, gerçek ekran okuyucuyla sınayın.

RY Tracker Vakası: Onaylanmış Kararı Uygulanmış Özellikten Ayırmak

RY Tracker, alışkanlık takibine yönelik bir uygulama. Bir alışkanlığı bulmak, günlük kaydı değiştirmek ve ilerlemeyi anlamak gibi görevler, bu yazıdaki ilkeleri birlikte düşünmek için uygun bir örnek sunuyor.

Uygulama için kabul edilen tasarım kararlarından biri, normal Today görünümünde sekiz kartlı 2×4 düzen ve yatay sayfalama kullanılması. Büyük metin veya erişilebilirlik ihtiyacında ise kartların büyümesi, içeriğin kırpılmaması ve gerektiğinde dikey kaydırma sağlanması hedefleniyor. Bu, bir tasarım kararıdır; uyarlamanın çalışan üründe bütünüyle uygulandığı ve gerçek cihazda doğrulandığı bu makalede ileri sürülmüyor.

Bir davranışın kabul edilmesi, kodda uygulanması ve gerçek cihazda doğrulanması ayrı aşamalardır. Kabul edilen karar neyin hedeflendiğini söyler. Kod incelemesi bunun nasıl uygulandığına kanıt sağlayabilir. Cihaz sınaması ise belirli bir sürümün belirli koşullardaki davranışını gösterir. RY Tracker’ın kaynak kodu ve çalışan sürümü bu makale çalışmasında test edilmedi; örnekleri sınanacak sorular olarak ele alıyoruz.

Uzun bir alışkanlık adıyla metni büyüttüğünüzü düşünün. Kart genişlediğinde tamamlanma eylemi erişilebilir mi? Hata açıklaması açıldığında komşu kartla karışıyor mu? Ekran okuyucu alışkanlığın adını ve günlük durumunu ayırt ediyor mu? Miktar ekleme ile ikili tamamlamanın farklı geçişleri varsa, her birini kendi görevi içinde sınamak gerekir.

Başka bir tasarım kararı da genel günlük ilerlemenin görsel filtrelerden bağımsız kalması; kategori ilerlemesinin ayrıca gösterilebilmesidir. Bu yaklaşımda kategori seçmek, bütün güne ait toplamın anlamını değiştirmemelidir. Kullanıcıya “Bu sayı bütün günü mü, seçili kategoriyi mi anlatıyor?” sorusunu sorun. Yanıt belirsizse etiketi, konumu ve filtre geçişini birlikte değerlendirin. Bir sayının doğru hesaplanmasıyla kapsamının anlaşılması farklı meselelerdir.

Tasarım Kararlarını Gerçek Kullanımda Sınamak

Bir değerlendirmeye ekranların güzel görünüp görünmediğiyle başlamayın. Önce gözlenebilir bir görev seçin: kaydı oluşturmak, başarısız işlemi fark etmek, yanlış kaydı düzeltmek. Ardından aynı görevi normal metin, büyük metin, klavye, ekran okuyucu ve hareket azaltma koşullarında deneyin. Her koşulda aynı cihazı varsaymak yerine hedef platformları kaydedin.

Bağlantı gecikmesi, bağlantı kaybı ve saklama hatası farklı sorunlardır; hepsini aynı hata ekranına zorlamayın. Kullanıcı beklerken tekrar etkinleştirdiğinde ne olduğunu ve uygulamaya geri dönünce hangi durumu gördüğünü gözlemleyin. İlk bakışta başarılı görünen işlemin ardından kaydın gerçekten korunup korunmadığını ayrıca kontrol edin.

Gözlem kaydına görev sonucu, yardım ihtiyacı, yanlış eylem, anlaşılmayan mesaj ve veri sonucu ekleyin. “Erişilebilirlik kontrolü geçti” yerine hangi sürümde, hangi giriş yöntemiyle, hangi adımın denendiğini yazın. Otomatik araçların bulduklarını elle yapılan görev kontrolü ve yardımcı teknoloji denemesiyle tamamlayın. Bir denetim kaydını değerlendirilebilir kılan, sonucun hangi koşulda elde edildiğinin açık olmasıdır.

Sonuçları değerlendirirken gözlemle yorumun arasını açık tutun. “Katılımcı düğmeye üç kez bastı” bir gözlemdir; “bekleme durumunu anlamadı” ise ayrıca araştırılması gereken yorumdur. Ardından “Kaydediliyor açıklamasını eylemin yanında tutarsak tekrar giriş azalır” gibi bir hipotez kurabilirsiniz. Değişiklikten sonra aynı görevi karşılaştırılabilir koşullarda yeniden deneyin. Tek kişinin bir kez başarılı olması, bütün durumların çözüldüğünü göstermez; başarısızlık da hangi koşulda ortaya çıktığı kaydedildiğinde tasarım için kullanılabilir bilgiye dönüşür.

Kendi Arayüzünüz İçin Beş Adımlık Uygulama Kontrolü

Tek bir ekran ve tek bir görev seçin: örneğin bugünkü alışkanlığı kaydetmek. Bu kısa kontrolü çalışan bir prototipte veya kendi ürününüzde uygulayın. Her adımda gördüğünüz sorunu ve sonraki denemede neyi değiştireceğinizi not edin.

1. Bileşenin durumlarını çıkarın. Başlangıç, odak, basma, bekleme, başarı ve hata durumlarını gerektiği yerde gösterin. İkinci kez etkinleştirmeyi ve işlemi yarıda bırakmayı deneyin. Durumun adıyla verinin gerçek sonucu birbirini karşılıyor mu?
2. Geri bildirimi ve hata yolunu izleyin. Bir girişi eksik bırakın veya güvenli bir test ortamında gönderimi başarısız kılın. Mesaj ne olduğunu ve nasıl devam edileceğini söylüyor mu? Geçerli bilgiler korunuyor mu? Geri alma varsa hangi işlemi etkilediği açık mı?
3. Metni büyütün. Web’de yüzde 200’e kadar büyütmeyi ve dar alandaki yeniden akışı ayrı ayrı inceleyin; yerel uygulamada sistemin metin boyutu ayarını kullanın. Uzun Türkçe adlarla durum ve eylemin görünür kaldığını kontrol edin. Sığdırmak için metnin yeniden küçülmediğinden emin olun.
4. Klavye ve yardımcı teknolojiyle tamamlayın. Fareyi bırakıp odak sırasını izleyin. Denetimler kullanılabiliyor mu, odak görülebiliyor mu? Ekran okuyucuyla adları ve durum bildirimlerini, hareket azaltma açıkken sonucun anlaşılmasını kontrol edin. Kontrastı da kullanılan renk çiftleri üzerinden ölçün.
5. Gerçek kullanım koşulunda yeniden sınayın. Hedef cihazda aynı görevi, gerekirse bağlantı gecikmesi veya kesintisiyle tekrarlayın. Görev başarısını, yardım ihtiyacını ve kaydın korunmasını ayrı not edin. Bir sorun için değişiklik yaptıysanız aynı koşula dönerek sonucunu karşılaştırın.

Bir seferde tek bileşen seçmek bu çalışmayı yönetilebilir kılar. Açılıştaki düğmeye geri dönün: kullanıcı dokunduğunda ne olduğunu anlayabiliyor ve işine güvenle devam edebiliyor mu? Bir sonraki tasarım kararınızın gerekçesi, bu soruya verdiğiniz gözlenebilir yanıtta olsun.

Kaynaklar

Kaynaklar 28 Ekim 2026 tarihinde kontrol edildi. Aşağıdaki belgeler teknik iddiaları destekler; örnek akışlar ve değerlendirme önerileri editoryal uygulamalardır. W3C Understanding belgeleri açıklayıcıdır; normatif ölçütler WCAG metnindedir. Platform rehberleri WCAG uygunluk belgesi değildir.

• W3C. Web Content Accessibility Guidelines (WCAG) 2.2. Erişilen Recommendation sürümü: 12 Aralık 2024.
• Google / Android Developers. Handling user interactions. Etkileşim olayları ve bileşen geri bildirimi.
• W3C / WAI. Error Identification — SC 3.3.1 ve Error Prevention — SC 3.3.4.
• W3C / WAI. Animation from Interactions — SC 2.3.3.
• Apple. Reduced Motion evaluation criteria.
• W3C / WAI. Resize Text — SC 1.4.4 ve Reflow — SC 1.4.10.
• Apple. Scaling fonts automatically. Dynamic Type ve metin stilleri.
• W3C / WAI. Contrast (Minimum) — SC 1.4.3 ve Non-text Contrast — SC 1.4.11.
• W3C / WAI. Keyboard — SC 2.1.1 ve Focus Not Obscured (Minimum) — SC 2.4.11.
• W3C / WAI, ARIA Authoring Practices Guide. Read Me First ve Button Pattern.
• W3C / WAI. Status Messages — SC 4.1.3.
• Proje belgesi, kamuya açık kaynak değil. RY Tracker — UX/UI Design Register V1.1, 28 Ekim 2026; UX-002, UX-003, UX-008 ve kanıt sınırları. Onaylanmış tasarım kararları ve uygulama/doğrulama ayrımı için proje bağlamı.