React ve Flutter UI incelemeleri için erişilebilirlik istemleri

İnsanların bir UI'yi erişilebilir hale getirmeye çalışırken kaçırdığı şeyler

Çoğu erişilebilirlik sorunu “büyük yeniden tasarım” meselesi değildir. Kullanılabilirliği belirleyen küçük ayrıntılardır. Bir ayrıntı eksikse, biri UI'nızı hiç kullanamayabilir.

Genellikle ilk bozulan şeyler şaşırtıcı derecede tutarlıdır. Bir sayfa görsel olarak düzgün görünebilir, hızlı bir görsel kontrolden geçebilir ama yine de klavyeyle ya da ekran okuyucuyla kullanması zor olabilir.

İşte UIlarda en sık başarısız olunan ilk yerler:

• Klavye erişimi: ana kontrollere ulaşamama veya bir modale sıkışıp kalma
• Odak sırası ve odak durumları: odak zıplıyor veya nerede olduğunuzu göremiyorsunuz
• Etiketler ve adlar: inputlar ve butonların anlaşılır ya da erişilebilir adları eksik
• Bildirimler: dinamik güncellemeler oluyor ama ekran okuyucular bilgilendirilmiyor
• Kontrast ve netlik: metin, ikonlar ve hata durumları görmek güç

İşin zor yanı, gerilemenin ne kadar kolay olduğu. Küçük bir değişiklik (bir butonu ikona çevirmek, bir kartı gesture handler içine sarmak veya özel bir dropdown eklemek) klavye desteğini kaldırabilir, odak sırasını bozabilir veya bir etiketi fark edilmeden düşürebilir.

Yaygın bir senaryo: bir React formuna input içine yeni bir “temizle” ikonu eklenir. Görsel olarak yardımcı görünür ama ikon fokuslanabilir değildir, bir adı yoktur ve tıklama olaylarını çalar. Artık klavye kullanıcıları onu etkinleştiremez, ekran okuyucu kullanıcıları ise isimsiz bir kontrol duyar.

Bu yazı size iki şey veriyor: kopyalanabilir istemler (React ve Flutter için) ve dakikalar içinde çalıştırılabilecek tekrarlanabilir bir inceleme akışı. Amaç ilk günde mükemmellik değil; gerçek kullanıcıları engelleyen sorunları yakalamak.

Eğer ürün ekranları oluşturuyorsanız ama erişilebilirlik uzmanı değilseniz, bu sizin için. Koder.ai gibi hızlı değişikliklerin olduğu araçlar kullanan ekipler için de uygundur; hızlı ve tutarlı kontrollere ihtiyacınız olduğunda pratik bir başlangıç noktası sağlar. Bu erişilebilirlik istemleri, her UI gönderdiğinizde tekrar kullanabilmeniz için tasarlandı.

Çoğu sorunu hızlıca yakalayan 5 kontrol

Bir ekranı incelemek için yalnızca 15 dakikanız varsa, bu kontroller insanların en sık takıldığı problemleri bulur. Hem React hem Flutter için çalışır ve erişilebilirlik incelemeleri için kullanılacak istemlerle iyi uyum sağlar.

1) Sadece klavye ile kullanabiliyor musunuz?

Sayfa üzerinde fare kullanmadan ilerlemeyi deneyin. Gezinmek için Tab ve Shift+Tab, etkinleştirmek için Enter ve Space, menü, sekme veya liste gibi görünen bileşenlerde ok tuşlarını kullanın.

Hızlı bir gösterge: eğer bir modalin içinde sıkışıyorsanız ya da “Kapat” gibi önemli bir kontrole ulaşamıyorsanız, bir sorun var demektir.

2) Odak sırası mantıklı mı ve odak görünür mü?

Tab ilerlerken odak görsel düzeni (yukarıdan aşağı, soldan sağa) takip etmeli ve hiçbir zaman gizli alanlara atlamamalı. Odak ayrıca belirgin olmalı. Tasarım ince konturlar kullanıyorsa, bunların açık ve koyu arka planlarda hâlâ görünür olduğundan emin olun.

3) Kontrollerin net isimleri var mı?

Her etkileşimli öğe için ekran okuyucunun faydalı bir ad duyurması gerekir. Sadece “Buton” demek yeterli değil. İkonların erişilebilir etiketi olmalı, form alanlarının etiketleri placeholder kaybolsa bile bağlı kalmalı.

4) Kontrast ve yazı boyutu uygun mu?

Küçük metinleri, devre dışı bırakılmış metinleri ve renkli butonlardaki metni kontrol edin. Ayrıca büyütmeyi test edin: yazı boyutunu artırıp düzenin içerikleri üst üste getirmediğinden veya kesmediğinden emin olun.

5) Değişiklikler net şekilde duyuruluyor mu?

Bir şey değiştiğinde (hata, yükleniyor, başarı), kullanıcıların tahmin etmesine gerek olmamalı. Alan yakınında inline hata metni kullanın, form hatalarını duyurun ve yükleniyor durumlarını açıkça gösterin.

Koder.ai ile ekran inşa ediyorsanız, ona “bu sayfa için yalnızca klavye akışını, odak sırasını ve ekran okuyucu etiketlerini doğrula” diyebilir ve ardından yukarıdaki adımları kullanarak sonucu gözden geçirebilirsiniz.

UI'yi değiştirmeye başlamadan önce inceleme kapsamınızı belirleyin

Herhangi bir bileşene dokunmadan önce neyi incelediğinize ve "yeterince iyi"nin ne anlama geldiğine karar vermek erişilebilirlik işini hızlandırır. Sıkı bir kapsam, erişilebilirlik istemlerinin daha kullanışlı olmasını sağlar; model gerçek ekranlara ve gerçek etkileşimlere odaklanabilir.

Önemli yolculukları seçin

Tüm ürünü değil, 2–4 kritik kullanıcı yolculuğuyla başlayın. İyi seçimler, insanların tamamlaması gereken ve başarısız olursa kullanıcıları kilitleyebilecek akışlardır.

Çoğu uygulamada bu; oturum açma, birincil “oluştur veya satın al” akışı (ödeme, rezervasyon, gönderim) ve ayarlar veya profil gibi bir hesap alanıdır.

Sonra her yolculuktaki tam ekranları yazın (5–8 ekran kadar olsa bile). Ara durumları da ekleyin: hata mesajları, boş durumlar, yüklenme durumları ve onay diyalogları. Bu durumlar odak ve ekran okuyucu çıktısının sık bozulduğu yerlerdir.

Somut bir örnek: küçük bir CRM ekranı inşa ediyorsanız, Koder.ai içinde kapsamı "oturum aç → Kişileri aç → kişi ekle → kaydet → başarı mesajını gör" şeklinde belirleyin. Bu tek akış formları, doğrulamayı, diyalogları ve bildirimleri kapsar.

"Geçti" ne demek karar verin

Pratik olun. WCAG AA beklentilerini hedefleyin ama bunları hızlı uygulanabilecek sade kontroller haline getirin: klavye uçtan uca çalışmalı, odak görünür ve mantıklı olmalı, adlar ve etiketler anlaşılır olmalı ve kontrast okunabilir olmalı.

Tartışmaya zaman harcamamak için basit bir geç/kalır not formatı kullanın. Her ekran için şu bilgileri kaydedin:

• Kontrol: (klavye, odak sırası, etiketler, kontrast, duyurular)
• Sonuç: Geç veya Kalır
• Kanıt: olan biteni bir cümleyle açıklayın
• Muhtemel düzeltme: muhtemelen hangi bileşen, prop veya stil değişecek
• Yeniden test: düzeltmeden sonra ne denenmeli

Bu, React ve Flutter arasında incelemeyi tutarlı kılar ve sorunları başkasına devrederken yeniden açıklamayı gereksiz kılar.

React bileşenleri için kopyalanabilir istemler (klavye, etiketler, roller)

Bir erişilebilirlik incelemesi istediğinizde, en hızlı kazanımlar spesifik olmaktan gelir: hangi bileşen, hangi kullanıcı eylemi ve "iyi"nin nasıl görünmesi gerektiği. Bu istemler, bileşen kodunu ve UI'nın ne yapması gerektiğini kısa bir açıklama ile yapıştırdığınızda en iyi sonucu verir.

Sohbet tabanlı bir oluşturucuyla (ör. Koder.ai) çalışıyorsanız, ekranı veya bileşeni ürettikten hemen sonra bu istemi ekleyin ki sorunlar uygulama geneline yayılmadan düzeltilebilsin.

Review this React component for keyboard navigation issues. 
- Can every interactive element be reached with Tab and activated with Enter/Space?
- List the exact problems you see in the code.
- Propose fixes with small code edits.

Check focus order and focus visibility.
- Describe the expected focus order for a keyboard-only user.
- Point out where focus could get lost (modals, menus, drawers).
- Tell me exactly where to add :focus-visible styles (which elements, which CSS).

Find missing accessible names.
- Identify inputs, buttons, and icons without clear labels.
- Suggest label + htmlFor, aria-label, aria-labelledby, or visible text.
- If there is helper/error text, connect it with aria-describedby.

Identify interactive elements that are not buttons/links.
- Find div/span with onClick, custom dropdowns, and clickable cards.
- Suggest correct semantics (button/a) or add role, tabIndex, and keyboard handlers.

List screen reader announcements that will be confusing.
- Predict what a screen reader will announce for key controls.
- Rewrite UI text to be shorter and clearer.
- Suggest aria-live usage for status changes (loading, errors, saved).

İstem göndermeden önce bu detayları ekleyin ki yararlı düzeltmeler alınsın, genel tavsiyeler değil:

• Bileşenin ne olduğu (örneğin: "giriş formu", "fiyat geçişi", "ayarlar modalı").
• Kullanıcıların takip etmesi gereken klavye yolu (başlangıç ve bitiş noktası).
• Kullanılan UI kütüphanesi (MUI, Chakra, Radix, özel bileşenler).
• Test edilecek durumlar (yükleniyor, hata, devre dışı, boş sonuç).
• Bir somut kullanıcı hedefi (örneğin: "planı değiştir ve onayla").

Flutter widget'ları için kopyalanabilir istemler (Semantics, odak, jestler)

Tutarlı sonuçlar istiyorsanız bir widget ağacını (veya tüm ekranı) yapıştırın ve belirli kontroller isteyin. Bu istemler en iyi sonuç verdiğinde widget ağacı, ekrana nasıl ulaşıldığı ve varsa özel jestler dahil edilir.

İncelemeye yapıştırılabilecek istemler

Review this Flutter widget tree for keyboard navigation and focus traversal.
Call out focus traps, missing focus order, and places where Tab/Shift+Tab will feel confusing.
Suggest exact widget changes (Focus, FocusTraversalGroup, Shortcuts, Actions).

Check this screen for missing Semantics labels, hints, and tap targets.
Point to the exact widgets that need Semantics(label/hint), tooltip, or exclusion.
Also flag controls under 48x48 logical pixels and suggest fixes.

Find custom gestures that break accessibility (GestureDetector/Listener).
Replace them with accessible widgets or add keyboard + semantics support.
If a gesture is required, describe how a keyboard user triggers the same action.

Audit error messages and validation on this form.
What should be announced to a screen reader, and when?
Suggest how to expose errors via Semantics and focus movement after submit.

Propose a consistent focus highlight style across screens.
It should be obvious on dark/light themes and work with keyboard navigation.
Show a small code example using FocusTheme/ThemeData.

Asistanın önermesi gereken hızlı düzeltmeler

Bekleyin ki yanıtlar birkaç somut desen içersin:

• Ana içeriği FocusTraversalGroup ile sarın ve yalnızca gerektiğinde FocusTraversalOrder ayarlayın.
• Bileşik kontroller için Semantics (veya MergeSemantics) kullanın, aynı etiketin tekrarlanmasından kaçının.
• Mümkünse GestureDetector yerine InkWell, IconButton, ListTile, SwitchListTile tercih edin.
• Metin dışı girişler için Shortcuts + Actions ekleyin (örneğin, Enter ile etkinleştirme, Escape ile kapama).

Özel bir kartı buton gibi davranacak hale getirmenin minimal örneği:

Semantics(
  button: true,
  label: 'Add payment method',
  hint: 'Opens the add card screen',
  child: Focus(
    child: InkWell(
      onTap: onPressed,
      child: Card(child: child),
    ),
  ),
)

Adım adım: basit bir klavye ve odak inceleme akışı

Hızlı bir klavye ve odak incelemesi, aynı zamanda ekran okuyucuları ve anahtar cihazları etkileyen sorunları bulur. Bunu gerçek bir sayfa akışında (tek bir buton değil) yapın ve yolu tekrar kontrol edebilmek için not tutun.

5 adımlı akış

İlk olarak bir "mutlu yol" (ör. oturum açma, ayarlar ekranını açma, kaydetme) seçin.

1. Tam akışı yalnızca klavyeyle yapın. Fareyi kenara koyun. İlerlemek için Tab ve Shift+Tab, etkinleştirmek için Enter ve Space, mantıklı olduğu yerde ok tuşlarını kullanın. Herhangi bir şey tıklama veya kaydırma gerektiriyorsa, işaretleyin.
2. Odak her zaman belirgin olmalı. Odak her hareket ettiğinde nerede olduğunu anında görebilmelisiniz. İnce halkaların karanlık arka planda kaybolması, CSS ile odak halkalarının kaldırılması veya Flutter widget'larının aktif gözüküp odak göstermemesi gibi durumlara dikkat edin.
3. Sıra gördüğünüzle eşleşmeli. Odak görsel düzeni ve okuma sırasını takip etmelidir. Yaygın uyarılar: ayağa atlayıp altbilgiye gitme, yan menüde sıkışma veya bir alanın focuslanamaması.
4. Açılırları zorlayın. Menüleri, diyalogları ve çekmeceleri açın. Odak açılırın içine gitmeli, açıkken içinde kalmalı ve kapandığında mantıklı bir yere dönmelidir. Gerekliyse Escape ile kapatma çalışmalıdır.
5. Her değişiklikten sonra yeniden test edin. Bir sorunu düzeltin, sonra aynı yolu tekrar çalıştırın. Özellikle odak sırası değişiklikleri ve yeni “ölü sonlar” görünmüş mü diye not alın.

Yol boyunca kaydedecekleriniz

Basit tutun: sayfa adı, hangi tuşa bastığınız, ne olduğu ve ne beklediğiniz. Bu küçük günlük, bir React refaktörünün veya Flutter widget değişiminin klavye erişimini sessizce bozup bozmadığını doğrulamayı kolaylaştırır.

Ekran okuyucu dostu isimler, etiketler ve bildirimler

Ekran okuyucular UI'nızı "görmez". İsimlere, rollere ve ne değiştiğini kısaca açıklayan mesajlara ihtiyaç duyarlar. İsim eksik ya da belirsizse uygulama tahmin işine döner.

Form alanlarıyla başlayın. Her inputun gerçek bir etiketi olmalı ve alan dolduğunda bile geçerli kalmalı. Placeholderlar ipuçlarıdır, etiket değildir; kullanıcı yazmaya başlar başlamaz kaybolurlar.

İkon-only eylemler sıkça atlanır. Çöp kutusu ikonu, kalem ya da üç nokta menüsü anlamlı bir ad gerektirir—işlemi açıklayan. "Projeyi sil" şekil yerine aksiyonu anlatır.

Başlıklar ve bölüm etiketleri önemlidir; bunlar sayfa ana hatlarını oluşturur. Ekran okuyucu kullanıcıları "Faturalandırma" veya "Ekip üyeleri" gibi başlıklara atlayarak gezinir; bu yüzden başlıklar içerikle uyumlu olmalı.

Hata mesajları spesifik ve uygulanabilir olmalı. "Geçersiz giriş" yeterli değil. Ne yanlış olduğunu ve sonraki adımı söyleyin: "Şifre en az 12 karakter olmalı" veya "E-posta adresinde @ işareti eksik" gibi.

Kopyalanabilir inceleme istemleri (React ve Flutter)

Bu istemleri bir ekranı incelerken veya Koder.ai gibi bir araca bileşenleri güncellettirirken kullanın:

• "Bu ekranı gez ve her metin girişinin görünür bir etikete sahip olduğunu, erişilebilir adın bununla eşleştiğini doğrula (React: label + htmlFor, aria-labelledby; Flutter: InputDecoration.labelText)."
• "İkon-only butonları bul ve her birine eylemi açıklayan erişilebilir bir ad ver (React: aria-label; Flutter: Tooltip veya Semantics(label: ...))."
• "Başlıkları kontrol et: React'te uygun heading seviyelerini kullanın, Flutter'da bölüm başlıklarını net tutun ki yapı doğru okunsun."
• "Doğrulama hatalarını yeniden yazın: ne olduğunu ve nasıl düzelteceğini söyleyen bir metin yazın; hatanın göründüğünde duyurulduğundan emin olun."

Dinamik güncellemeler için duyurular

Birçok ekran sayfa yenilenmeden değişir: profil kaydetme, öğe ekleme, sonuçlar yükleniyor. Bu güncellemelerin duyurulduğundan emin olun.

React için aria-live bölgesi tercih edin (kaydetme için polite, kritik hatalar için assertive). Flutter'da Semantics kullanın ve durumu görünür kılın (ör. banner veya SnackBar). Hızlı bir kontrol: "Kaydet" tetikleyin ve butondan odak ayrılmadan kısa bir "Değişiklikler kaydedildi" mesajını duyabildiğinizi doğrulayın.

Çok zaman almayan kontrast ve görsel netlik kontrolleri

Küçük metin, ikonlar, odak halkaları ve durum renklerine odaklanırsanız çoğu kontrast sorununu dakikalar içinde yakalarsınız. Bu pratik kontroller hem React hem Flutter incelemelerine kolayca dahil edilebilir.

10 dakikalık kontrast geçişi

Bir ekranı %100 yakınlaştırmada ve sonra %200'de tarayın. Bir şey okunması zorlaşıyorsa genellikle kontrast, yazı ağırlığı veya boşluk sorunudur.

İlk bakılacak beş yer:

• Gövde metni, altyazılar ve yardım metinleri (özellikle açık gri üzerine beyaz)
• Devre dışı bırakılmış durumlar (devre dışı görünmeli ama okunabilir olmalı)
• Etiketsiz ikonlar (soluk bir ikon birçok kullanıcı için aslında görünmezdir)
• Odak göstergeleri (halkaların arka plandan ayrılması gerekir)
• Hata ve başarı mesajları (sadece renge bağlı kalmayın; metin ve ikon olsun)

Pratik bir kural: kaşlarını çatırsanız kullanıcılar da çatar. Renk çiftinden emin değilseniz, metni geçici olarak saf siyah veya saf beyaz yapın. Okunabilirlik artıyorsa kontrast çok düşüktür.

Odak görünürlüğü sıkça kaçırılır. Odak halkasının yeterince kalın olduğundan ve arka planla aynı renkte olmadığından emin olun. Bir listede "seçili" durumunuz varsa, gri tonlamada bile farklı görünmesini sağlayın: ikon, alt çizgi veya net bir sınır ekleyin.

Mobil netlik: hedefler ve temalar

Mobilde görsel netlik dokunmatik hedeflerle de ilgilidir. Butonların ve ikon-only eylemlerin dokunma hedefleri yeterince büyük ve aralıklı olmalı ki yanlış kontrol vurulmasın.

Hızlı bir tema kontrolü yapın: karanlık modu açın ve varsa yüksek kontrast ayarlarını kontrol edin. Yüzeylerdeki, ayırıcı ve odak halkasındaki metinleri tekrar kontrol edin. Yaygın hata: karanlık modda odak halkasının kaybolması veya devre dışı ikonun arka planla neredeyse aynı renge gelmesi.

Koder.ai'de hızlı UI üretiyorsanız, ilk düzenlemeden sonra "kontrast ve odak halkası geçişi" isteği ekleyin.

Sürekli tekrar eden yaygın hatalar

Çoğu erişilebilirlik hatası küçük UI düzenlemeleri gibi hissettikleri için tekrar eder. İncelemelerde bu kalıplara ilk bakın.

Placeholder metin etiket değildir. Placeholder kullanıcı yazmaya başlar başlamaz kaybolur ve birçok ekran okuyucu bunu alan adı olarak değerlendirmez. Alan boş, dolu ve hata durumunda anlaşılır olmak için gerçek görünür bir etiket veya açık erişilebilir ad kullanın.

Odak stilleri estetik kaygılarla kaldırılır. Bu genellikle klavye kullanıcılarını kaybettirir. Varsayılan halkayı değiştiriyorsanız, eşdeğer derecede net bir gösterge koyun: güçlü bir halka, arka plan değişikliği veya yeterli kontrast.

Bir diğer tekrarlayan suçlu sahte butonlardır. React'te div ile onClick kullanmak veya Flutter'da Container ile GestureDetector kullanmak cazip olabilir. Doğru semantik, klavye desteği ve ekran okuyucu desteği vermezler. Native kontroller (button, a, TextButton, ElevatedButton) size odak, rol, devre dışı durumu ve etkinleştirme davranışını otomatik verir.

Diyalog ve form odak hataları incedir ama can yakıcıdır. Modal kapandıktan sonra veya form kaydedildikten sonra odak genellikle sayfanın en üstüne atlar veya kaybolur. Bu, odak tetikleyiciye geri verilmediğinde ya da kaydetme ekranı yeniden render edip odağı düşürdüğünde olur. Kullanıcılar sonra nerede olduklarını bulmak için tekrar başlamak zorunda kalır.

ARIA (veya Flutter Semantics) aşırı kullanımı da sorun yaratabilir. Her yere roller ve etiketler eklemek, native öğenin zaten sağladıklarını çakıştırabilir ve çift duyurulara veya yanlış adlara yol açabilir.

İncelediğiniz bir ekranda sorulan hızlı "tekrar eden sorunlar" kontrolü:

• Her inputun kalıcı bir etiketi var mı, sadece placeholder değil mi?
• Her etkileşimli öğe gerçek bir kontrol mü ve doğru role sahip mi?
• Odak her zaman görünür mü ve replacement olmadan kaldırılmıyor mu?
• Diyaloglar, toastlar ve kaydetmelerden sonra odak tetikleyiciye geri dönüyor mu?
• ARIA/Semantics yalnızca native kontrollerin sağlayamadığını ekliyor mu?

Eğer UI'ı sohbetten üretiyorsanız (ör. Koder.ai), bu maddeleri kabul kriterleri olarak isteme ekleyin ki ilk taslak bu tuzaklardan kaçınsın.

Örnek yürütme: bir ekran, uçtan uca

Basit bir Ayarlar ekranı hayal edin: bir profil formu (Ad, E-posta), iki geçiş (E-posta bildirimleri, Karanlık mod), bir "Değişiklikleri Kaydet" butonu ve kaydetme sonrası görünen bir toast.

Klavye ile başlayın. Beklenen odak sırası görsel sıraya uymalıdır: yukarıdan aşağı, soldan sağa. Tablama hiçbir zaman toasta, altbilgiye veya gizli menüye atlamamalı.

Çoğu inceleme için hızlı bir geçiş:

• Üstten Tab ile başlayın: odak Ad alanına, sonra E-posta, sonra E-posta bildirimleri geçişine, sonra Karanlık moda, sonra Değişiklikleri Kaydet'e gelmeli.
• Shift+Tab ile geri gelmenin düzgün çalıştığını doğrulayın.
• Geçişlerde Space ile değiştirme çalışmalı. Ok tuşları odak tuzağı yaratmamalı.
• Değişiklikleri Kaydet ile Enter gönderme yapmalı ve gönderim sonrası odak kaybolmamalı.
• Toast göründüğünde odak olduğu yerde kalmalı; toast'ın bir eylemi (örn. "Geri Al") yoksa odak toast'a gitmemeli.

Şimdi ekran okuyucunun ne duyurduğunu kontrol edin. Her kontrol net bir isim, rol ve durum duyurmalı: örn. "Ad, metin alanı, zorunlu" ve "E-posta bildirimleri, anahtar, açık". E-posta alanında bir hata varsa, alan odaklandığında ve hata göründüğünde duyurulmalı (ör: "E-posta, metin alanı, geçersiz, Geçerli bir e-posta girin"). Kaydet butonu "Değişiklikleri Kaydet, buton" şeklinde okunmalı ve neden devre dışıysa bu da iletilmeli.

Kontrast için normal metin, placeholder ve hata mesajlarını kontrol edin. Odak halkasını her iki tema için de kolayca görmek gerek. Hata durumları sadece kırmızıya bağlanmamalı; ikon veya net metin de ekleyin.

Bulgularınızı kısa bir düzeltme listesine çevirin:

• Odak sırasını düzenle, görsel sırayla eşleşsin.
• Geçişler ve ikonlar için eksik erişilebilir adları ekle.
• Hataları alana bağlayarak duyur (sadece banner değil).
• Odak stillerini ve düşük kontrastlı placeholder/hata metinlerini iyileştir.
• Toast'ı bloklayıcı yapma; sadece eylem içeriyorsa fokuslanabilir olsun.

Koder.ai içinde oluşturuyorsanız, ekran açıklamasını ve bulgularınızı sohbete yapıştırın ve React veya Flutter UI'ını beklenen klavye ve ekran okuyucu davranışına uygun olarak güncellemesini isteyin.

Sonraki adımlar: bu kontrol listesini yeniden kullanın ve iş akışınıza dahil edin

Eğer bu erişilebilirlik istemlerinin faydasını görmek istiyorsanız, bunları tek seferlik temizlik değil tekrarlanabilir bir alışkanlık olarak ele alın. Amaç her yeni ekran veya bileşen eklediğinizde aynı küçük kontrolleri çalıştırmak.

UI değişiklikleri için tek bir "yapım tanımı" tutun. Herhangi bir şey gönderilmeden önce klavye, odak, adlar ve kontrastı hızlıca kontrol edin. Sık yaptığınızda dakikalar sürer.

Hemen hemen her UI için çalıştırabileceğiniz hızlı kontrol listesi:

• Klavye: her etkileşimli öğeye fare olmadan ulaşabiliyor musunuz?
• Odak: odak görünür mü ve mantıklı sırada mı hareket ediyor?
• Etiketler: her alan ve butonun net bir adı var mı (ikonlar dahil)?
• Duyurular: durum değişiklikleri duyuruluyor mu (hatalar, yükleniyor, başarı)?
• Kontrast: metin okunabilir mi ve devre dışı durumlar anlaşılabilir mi?

En iyi istemlerinizi şablon olarak kaydedin. Basit bir yol: her değişiklik isteğinin sonuna yapıştıracağınız bir "React inceleme istemi" ve bir "Flutter inceleme istemi" saklayın. Sonra yeni bileşen veya özel davranışı (modal, adım gösterge, sonsuz kaydıran liste) kısaca açıklayan bir satır ekleyin.

Her yeni bileşende aynı kontrolleri tekrar çalıştırın; tekrar etmesi sıkıcı gelebilir ama erişilebilirlik sorunları genellikle küçük düzenlemelerle gelir: yeni bir ikon-only buton, özel dropdown, toast mesajı veya diyalogta odak tuzağı.

Koder.ai ile inşa ediyorsanız, istemleri sohbete yapıştırın ve belirli düzeltmeler isteyin, genel iyileştirmeler değil. Sonra değişiklikleri uygulamadan önce etkisini planlama modunda gözden geçirin. Erişilebilirlik geçişi öncesi bir anlık görüntü alın; düzeltme düzeni bozarsa geri almayı kullanın. Bu, odak sırasını ve semantics'ı iteratif olarak düzeltmeyi güvenli kılar.

Erişilebilirlik geçişinizden sonra bunu bir sürüm kontrol aşaması gibi ele alabilirsiniz: kaynak kodu repo iş akışınıza dışa aktarın veya uygulamayı dağıtıp barındırın ve sonuçtan memnunsanız özel bir etki alanı bağlayın.