Cumhurbaşkanlığı Genelgesi Web Siteleri ve Mobil Uygulamaların Erişilebilirliği Kontrol Listesi - A Seviyesi

Web sayfasında / Mobil uygulamada metinsel olmayan içerikler (görsel¹, grafik, ikon, video, ses, animasyon, CAPTCHA vb.) bulunuyor mu?

(Cevabınız "Hayır" ise Soru 17'ye geçiniz.)

¹ Dipnot 1: Görsel; fotoğraf, afiş, banner ve çizim gibi görsel algı yoluyla bilgi ileten metinsel olmayan içerikleri ifade eder.

Web sayfasında / Mobil uygulamada bilgi sunan metinsel olmayan içerikler (görsel, grafik, infografik, harita, diyagram, veri görselleştirmesi, veri içeren SVG veya canvas içerikleri vb.) bulunuyor mu?

(Cevabınız "Hayır" ise Soru 4'e geçiniz.)

Bilgi sunan metinsel olmayan içerikler için içeriğin amacını ve anlamını uygun şekilde ifade eden ve yardımcı teknolojiler (ekran okuyucular gibi) tarafından algılanabilir metin alternatifleri sağlandı mı?

(Örneğin, web sayfalarında görseller için alt özniteliğinin kullanılması; ikonlar, grafikler veya özel bileşenler için uygun erişilebilir ad ve açıklamaların aria-label, aria-labelledby veya gerekli durumlarda aria-describedby ile sağlanması; karmaşık görseller ve grafikler için <figure> ve <figcaption> etiketlerinin kullanılması veya görselin yakınında düz metin alanlarına yer verilmesi, mobil uygulamalarda ise contentDescription / accessibilityLabel veya platform erişilebilirlik API'leri aracılığıyla erişilebilir ad ve açıklama tanımlanması.)

Web sayfasında / Mobil uygulamada dekoratif amaçlı metinsel olmayan içerikler bulunuyor mu?

(Cevabınız "Hayır" ise Soru 6'ya geçiniz.)

Dekoratif amaçlı metinsel olmayan içerikler, yardımcı teknolojiler tarafından göz ardı edilecek şekilde işaretlendi mi?

(Örneğin, web sayfalarında dekoratif görseller için boş alt özniteliği (alt="") kullanılması, role="presentation" / role="none" tanımlanması, görsellerin CSS arka planı olarak uygulanması veya uygun durumlarda aria-hidden="true" ile erişilebilirlik ağacından gizlenmesi, mobil uygulamalarda ise dekoratif içeriklerin importantForAccessibility="no" / isAccessibilityElement=false / accessible={false} kullanılarak erişilebilirlik ağacından çıkarılması.)

NOT: Dekoratif içerikler kullanıcıya bilgi sunmadığı için yardımcı teknolojiler tarafından algılanmamalı ve okunmamalıdır.

Web sayfasında / Mobil uygulamada test (işitme testi gibi) veya alıştırma (görsel eşleştirme soruları gibi) amacıyla kullanılan metinsel olmayan içerikler bulunuyor mu?

(Cevabınız "Hayır" ise Soru 8'e geçiniz.)

(Örneğin, işitme testlerindeki ses dosyaları, görsel eşleştirme soruları, matematik alıştırmalarındaki grafikler veya sorunun çözümünü destekleyen geometrik şekiller.)

Test veya alıştırma amacıyla kullanılan metinsel olmayan içerikler için sağlanan metin alternatifleri, içeriğin çözümünü veya sonucunu ortaya çıkarmadan, içeriğin amacını ve niteliğini açıklayan bir tanım veya betimleme olarak sunuldu mu?

(Örneğin, "Frekans ayırt etmeye yönelik ses örneği", "Çözüm adımlarını destekleyen diyagram" veya "Şekil eşleştirme sorusuna ait görsel" gibi içeriğin niteliğini tanımlayan ancak testin veya alıştırmanın sonucunu ifşa etmeyen açıklayıcı metinlerin sunulması.)

Web sayfasında / Mobil uygulamada belirli bir duyusal deneyim sunmak amacıyla kullanılan metinsel olmayan içerikler (sanat eseri, senfoni dinletisi gibi) bulunuyor mu?

(Cevabınız "Hayır" ise Soru 10'a geçiniz.)

Belirli bir duyusal deneyim sunan metinsel olmayan içerikler için içeriğin amacını uygun şekilde ifade eden ve yardımcı teknolojiler tarafından algılanabilir tanımlayıcı metin alternatifleri sağlandı mı?

(Örneğin, sanat eserinin adı, fotoğrafın konusu, müzik kaydının başlığı gibi içeriğin niteliğini tanımlayan açıklayıcı metinlerin sağlanması.)

Web sayfasında / Mobil uygulamada CAPTCHA doğrulaması bulunuyor mu?

(Cevabınız "Hayır" ise Soru 13'e geçiniz.)

CAPTCHA için içeriğin amacını tanımlayan ve kullanıcıya doğrulama sürecinin neden uygulandığını açıklayan metin alternatifi sağlandı mı?

(Örneğin, "Bu doğrulama, otomatik işlemleri engellemek amacıyla uygulanmaktadır." veya "Güvenlik doğrulaması: Form gönderimi öncesinde kullanıcı doğrulaması gereklidir." gibi CAPTCHA'nın amacını belirten tanımlayıcı metinlerin sağlanması.)

CAPTCHA için farklı duyusal algı türlerine dayalı alternatif doğrulama yöntemleri veya CAPTCHA dışı erişilebilir doğrulama yöntemleri sağlandı mı?

(Örneğin, web sayfalarında görsel CAPTCHA'ya alternatif olarak sesli doğrulama seçeneği sunulması; doğrulama giriş alanlarının <label>, aria-label veya aria-labelledby ile programatik olarak ilişkilendirilmesi; CAPTCHA yerine erişilebilir doğrulama soruları veya kullanıcı etkileşimine dayalı doğrulama yöntemlerinin ("Robot değilim" işaretleme, davranış analizi gibi) kullanılması, mobil uygulamalarda ise görsel doğrulamaya alternatif sesli doğrulama seçenekleri, erişilebilir doğrulama soruları veya contentDescription / accessibilityLabel ile tanımlanmış erişilebilir doğrulama bileşenlerinin sunulması.)

NOT: Doğrulama mekanizmaları yalnızca tek bir duyusal algı türüne dayanmamalıdır. Yalnızca görsel veya yalnızca sesli CAPTCHA yeterli değildir. Farklı algı türlerine uygun alternatifler sağlanmalıdır.

Web sayfasında / Mobil uygulamada zamana dayalı medya içerikleri (video, film, slayt veya ses kaydı gibi) bulunuyor mu?

(Cevabınız "Hayır" ise Soru 15'e geçiniz.)

Zamana dayalı medya içerikleri için içeriğin ne olduğunu tanımlayan ve yardımcı teknolojiler tarafından algılanabilir bir metin alternatifi sağlandı mı?

(Örneğin, Medya içeriğini tanımlayan erişilebilir adların sağlanması (örneğin: "Kurumsal Tanıtım Videosu", "Ürün Kullanım Eğitimi Videosu", "Podcast Kaydı" gibi); web Sayfalarında: Video veya ses içeriklerinin aria-label veya aria-labelledby kullanılarak erişilebilir şekilde tanımlanması, mobil uygulamalarda ise contentDescription / accessibilityLabel veya platform erişilebilirlik API'leri aracılığıyla medya içeriğinin amacının veya konusunun açıklanması.)

Web sayfasında / Mobil uygulamada metin içermeyen veya yalnızca simge ile sunulan arayüz bileşenleri (form alanları, butonlar, açılır listeler, sekmeler (tabs), menüler, özel tasarlanmış etkileşimli bileşenler gibi) bulunuyor mu?

(Cevabınız "Hayır" ise Soru 17'ye geçiniz.)

Kullanıcı girdisi gerektiren, metin içermeyen veya yalnızca simgeyle sunulan arayüz bileşenleri için bileşenin amacını ifade eden ve yardımcı teknolojiler tarafından algılanabilir bir erişilebilir ad sağlandı mı?

(Örneğin, web sayfalarında ikon butonlar veya grafiksel butonlar için aria-label veya aria-labelledby kullanılması; input type="image" elemanlarında görselin işlevini ifade eden alt özniteliğinin (alt) kullanılması. (Örneğin, yalnızca büyüteç ikonu içeren bir butonun "Arama yap" olarak adlandırılması.), mobil uygulamalarda ise metin içermeyen buton ve kontrol bileşenlerine contentDescription / accessibilityLabel aracılığıyla bileşenin işlevini ifade eden erişilebilir adların tanımlanması. (Örneğin, "Geri dön", "Ayarlar", "Sepete ekle".)

Web sayfasında / Mobil uygulamada yalnızca ses içeren zamana dayalı medya (podcast, ses kaydı, konuşma kaydı gibi) bulunuyor mu?

(Cevabınız "Hayır" ise Soru 19'a geçiniz.)

Yalnızca ses içeren zamana dayalı medya için içeriğin tamamını ve anlamını eşdeğer şekilde sunan bir transkript (metin dökümü) sağlandı mı?

(Örneğin, bir podcast kaydı için konuşmaların metin hâli, sesli duyuru için yazılı açıklama metni veya ses kaydındaki önemli bilgileri içeren metin dökümünün sunulması.)

Web sayfasında / Mobil uygulamada yalnızca görüntü içeren zamana dayalı medya (sessiz video, animasyon, ekran kaydı vb.) bulunuyor mu?

(Cevabınız "Hayır" ise Soru 21'e geçiniz.)

Yalnızca görüntü içeren zamana dayalı medya için içeriğin amacını ve görselde gerçekleşen önemli bilgileri açıklayan eşdeğer bir metin alternatifi veya sesli açıklama sağlandı mı?

(Örneğin, sessiz bir video için görselde gerçekleşen olayları açıklayan metin açıklaması veya sesli anlatım sağlanması.)

Web sayfasında / Mobil uygulamada önceden kaydedilmiş ve hem ses hem görüntü içeren zamana dayalı medya (multimedya) içerikleri bulunuyor mu?

(Cevabınız "Hayır" ise Soru 24'e geçiniz.)

(Örneğin, eğitim videoları, tanıtım videoları, sunum kayıtları, röportajlar, webinar kayıtları vb.)

NOT: Video içeriği, aynı sayfada veya ekranda sunulan metin içeriğinin bire bir alternatifi olarak sunulmuş ve bu durum açıkça belirtilmişse, bu içerik ilgili başarı kriteri kapsamında değerlendirme dışı bırakılabilir.

Önceden kaydedilmiş multimedya içerikleri için konuşmaları ve anlam açısından önemli ses bilgilerini içeren senkronize altyazılar (captions) sağlandı mı?

(Örneğin, altyazı seçeneğinin sunulması veya altyazıların video ile eşzamanlı olarak gösterilmesi.)

Sağlanan altyazılar; konuşmaları, konuşmacı değişimlerini ve anlam açısından önemli ses bilgilerini (örneğin, [kapı çalma sesi], [alkış], [müzik çalıyor] vb.) eksiksiz, doğru ve anlaşılabilir şekilde içeriyor mu?

Web sayfasında / Mobil uygulamada önceden kaydedilmiş video içeriklerinde yalnızca görsel olarak sunulan ve mevcut ses içeriğinde yer almayan ancak içeriğin anlaşılması için gerekli görsel bilgiler bulunuyor mu?

(Cevabınız "Hayır" ise Soru 26'ya geçiniz.)

(Örneğin, videoda gösterilen grafikler, sunum slaytlarında yer alan metinler, gerçekleştirilen işlemler veya bir kişinin gerçekleştirdiği eylemler gibi, sesli anlatımda aktarılmayan görsel bilgiler.)

Video içeriğinde yalnızca görsel olarak sunulan ve mevcut ses içeriğinde yer almayan bilgilerin eşdeğer şekilde sunulabilmesi için sesli betimleme (audio description) veya metin temelli medya alternatifi (ayrıntılı transkript veya açıklayıcı metin) sağlanıyor mu?

(Örneğin, videoda gösterilen grafiklerin sesli olarak betimlenmesi, gerçekleştirilen işlemlerin sözlü olarak aktarılması, videodaki önemli görsel bilgilerin metinle açıklanması.)

NOT: Video içeriğinde tüm görsel bilgilerin mevcut ses içeriğinde de yer alması durumunda (yalnızca konuşmaya dayalı içerikler gibi), sesli betimleme sağlanması zorunlu değildir. Ayrıca içerik, mevcut bir metnin alternatifi olarak sunuluyor ve bu durum açıkça belirtiliyorsa, ek bir medya alternatifi sağlanmasına gerek duyulmaz.

Web sayfasında / Mobil uygulamada bilgi, yapı ve ilişkileri ifade eden arayüz bileşenleri (gezinti bölümleri (navigation), bağlantılar (link), düğmeler (button), form elemanları (form controls), sekmeler (tab), açılır/kapanır bileşenler (accordion/disclosure), iletişim kutuları (dialog), seçim bileşenleri (select/menu), gruplamalar (grouping) ve birlikte anlam kazanan kullanıcı arayüzü bileşenleri² gibi); içerik yapıları (başlıklar (heading), listeler (list), tablolar (table), alıntılar (blockquote), açıklama listeleri (description list) gibi) veya metin içeriğinin yapısal sunumuna ilişkin öğeler (paragraflar (paragraph), metin vurguları (emphasis), kısaltmalar (abbreviation), alıntı vurguları (citation), güçlü vurgu yapıları (strong emphasis) gibi) bulunuyor mu?

(Cevabınız "Hayır" ise Soru 46'ya geçiniz.)

² Dipnot 2: Birlikte anlam kazanan arayüz bileşenleri; tek başına değil, bir grup olarak anlam ifade eden ve birlikte değerlendirilmesi gereken bileşenlerdir. (Örneğin, radyo düğmesi grupları, onay kutusu grupları, sekmeler (tabs), sayfalama bileşenleri, filtre seçenekleri, navigasyon menüleri ve form alan grupları.)

Web sayfasında / Mobil uygulamada içerik yapısını tanımlayan başlıklar bulunuyor mu?

(Cevabınız "Hayır" ise Soru 29'a geçiniz.)

Başlıklar, mantıksal bir hiyerarşi içinde ve programatik olarak tanımlanmış uygun başlık yapıları kullanılarak oluşturuldu mu?

(Örneğin, web sayfalarında <h1>-<h6> başlık etiketlerinin ana başlıktan alt başlıklara doğru mantıksal bir sıra ile kullanılması, web uygulamalarda ise başlıkların accessibilityHeading="true" / accessibilityTraits = .header / accessibilityRole="header" özellikleri kullanılarak tanımlanması ve yardımcı teknolojiler tarafından başlık olarak algılanmasının sağlanması.)

Web sayfasında / Mobil uygulamada liste yapısı (list) bulunuyor mu?

(Cevabınız "Hayır" ise Soru 31'e geçiniz.)

Listeler, bilgi ve ilişkileri programatik olarak belirlenebilir olacak şekilde platforma uygun semantik yapılar kullanılarak tanımlandı mı?

(Örneğin, web sayfalarında sıralı veya sırasız listeler için <ul>, <ol> ve <li> etiketlerinin; tanım listeleri için ise <dl>, <dt> ve <dd> etiketlerinin kullanılması, mobil uygulamalarda ise liste ve ızgara (grid) yapılarının CollectionInfo / CollectionItemInfo / accessibilityContainerType / accessibilityRole="list" gibi erişilebilirlik özellikleri kullanılarak tanımlanması ve listedeki öğe sayısı ile öğelerin konum bilgilerinin yardımcı teknolojilere aktarılması.)

Web sayfasında / Mobil uygulamada tablolar (table) bulunuyor mu?

(Cevabınız "Hayır" ise Soru 36'ya geçiniz.)

Web sayfasında / Mobil uygulamada yer alan tablolar, veri tablosu niteliğinde mi?

(Cevabınız "Hayır" ise Soru 36'ya geçiniz.)

NOT: Tablolar yalnızca görsel düzen veya yerleşim amacıyla kullanılmamalıdır. Bu tür durumlarda web sayfalarında CSS tabanlı yerleşim yöntemleri, mobil uygulamalarda ise LinearLayout / ConstraintLayout / UIStackView / UICollectionView / UITableView / View / FlatList / SectionList veya platforma uygun eşdeğer yerleşim (layout) yapıları tercih edilmelidir.

Veri tabloları, bilgi ve ilişkiler programatik olarak belirlenebilir olacak şekilde doğru semantik yapılar kullanılarak tanımlandı mı?

(Örneğin, web sayfalarında tablo yapısı için <table> ve <tr> etiketlerinin kullanılması; veri hücrelerinin (<td>) ilgili satır veya sütun başlıklarıyla (<th>) programatik olarak ilişkilendirilmesi, mobil uygulamalarda ise veri tablolarının CollectionInfo / CollectionItemInfo / accessibilityContainerType / accessibilityRole="table" kullanılarak tanımlanması; satır ve sütun ilişkilerinin yardımcı teknolojiler tarafından algılanabilir şekilde sunulması.)

Veri tablolarında, tablonun amacını ve içeriğini tanımlayan erişilebilir bir başlık / açıklayıcı bir ad sağlandı mı?

(Örneğin, web sayfalarında <table> etiketi içerisinde tablonun amacını belirten bir <caption> etiketinin kullanılmlası veya tablo yapısının aria-labelledby ya da aria-label ile tanımlanması, mobil uygulamalarda ise tablo yapısına contentDescription / accessibilityLabel veya eşdeğer erişilebilirlik API'leri kullanılarak tablonun ne hakkında olduğunun belirtilmesi.)

Veri tablolarında, satır veya sütun başlıkları, bilgi ve ilişkileri gösterecek şekilde programatik olarak tanımlandı mı?

(Örneğin, web sayfalarında başlık hücreleri için <th> etiketinin kullanılması; başlık hücresinin hangi satır veya sütun için geçerli olduğunu belirtmek amacıyla scope="col" ve scope="row" özniteliklerinin veya karmaşık tablolarda headers ve id özniteliklerinin kullanılması, mobil uygulamalarda ise satır ve sütun başlıklarının CollectionItemInfo / rowIndex / columnIndex / isHeading / accessibilityTraits = .header / accessibilityContainerType = .table / accessibilityRole="header" gibi platforma özgü erişilebilirlik özellikleri kullanılarak tanımlanması.)

Web sayfasında / Mobil uygulamada gezinti (navigasyon) bağlantılarının bulunduğu bir bölüm bulunuyor mu?

(Cevabınız "Hayır" ise Soru 38'e geçiniz.)

Gezinti bölümleri, platforma uygun semantik yapı veya rol kullanılarak tanımlandı mı?

(Örneğin, web sayfalarında Ana menü, alt menü veya yan menü gibi gezinti alanları için <nav> etiketinin kullanılması veya bu alanlara role="navigation" özniteliğinin atanması, mobil uygulamalarda ise gezinti yapılarının NavigationView, BottomNavigationView, UIAccessibilityTraitTabBar, accessibilityRole="tab" / accessibilityRole="menu" gibi platforma özgü erişilebilirlik özellikleri ve standart gezinti bileşenleri kullanılarak tanımlanması.)

Web sayfasında / Mobil uygulamada form elemanları (metin alanı, onay kutusu, radyo düğmesi, seçim listesi, arama alanı, buton ve birlikte sunulan form alan grupları gibi) bulunuyor mu?

(Cevabınız "Hayır" ise Soru 40'a geçiniz.)

Form elemanlarının etiketleri, ilgili form alanlarıyla doğru şekilde ilişkilendirilmiş ve bu bilgi ile ilişkiler yardımcı teknolojiler tarafından programatik olarak algılanabilir şekilde sağlandı mı?

(Örneğin, web sayfalarında etiketler için <label> etiketinin kullanılması ve for ile id öznitelikleri aracılığıyla ilgili form alanıyla ilişkilendirilmesi; görsel etiketin bulunmadığı durumlarda aria-label kullanılması veya mevcut bir metnin aria-labelledby ile ilgili form alanına bağlanması, mobil uygulamalarda ise form alanlarına contentDescription / accessibilityLabel veya benzeri erişilebilirlik özellikleri aracılığıyla erişilebilir ad tanımlanması; bir metin bileşeninin labelFor / accessibilityLabelledBy veya platforma özgü eşdeğer özellikler kullanılarak ilgili form alanının etiketi olarak ilişkilendirilmesi.)

Web sayfasında / Mobil uygulamada birbiriyle ilişkili form alan grupları (radyo düğmesi grupları, onay kutusu grupları, seçenek grupları gibi) bulunuyor mu?

(Cevabınız "Hayır" ise Soru 42'ye geçiniz.)

Birbiriyle ilişkili form alanları, anlamlı şekilde gruplandırılmış ve grup başlığı yardımcı teknolojiler tarafından algılanabilir olacak biçimde programatik olarak tanımlandı mı?

(Cevabınız "Hayır" ise Soru 42'ye geçiniz.)

(Örneğin, web sayfalarında ilişkili form alanlarının <fieldset> ve <legend> etiketleriyle gruplandırılması veya uygun durumlarda role="group" ile grup yapısının tanımlanması; mobil uygulamalarda ise grup başlığının ve grup yapısının accessibilityHeading / accessibilityTraits = .header / accessibilityRole / contentDescription / accessibilityLabel / accessible={true} gibi erişilebilirlik özellikleri kullanılarak yardımcı teknolojiler tarafından algılanabilir şekilde tanımlanması.)

NOT: Grup başlığı yalnızca görsel olarak sunulmamalı; ekran okuyucu gibi yardımcı teknolojiler tarafından da algılanabilir olmalıdır.

Web sayfasında / Mobil uygulamada paragraf yapısına sahip metin içerikleri bulunuyor mu?

(Cevabınız "Hayır" ise Soru 44'e geçiniz.)

Metin içerikleri, platforma uygun semantik yapılar kullanılarak paragraf hâlinde programatik olarak tanımlandı mı?

(Örneğin, web sayfalarında metinlerin satır kırma amacıyla <br> etiketi yerine anlamlı paragraf yapıları oluşturacak şekilde <p> etiketi kullanılarak sunulması; mobil uygulamalarda ise metin bloklarının görsel olarak parçalanmak yerine platformun standart metin bileşenleri (TextView / UILabel / Text) kullanılarak ve bölünmüş metinlerin gerektiğinde accessible={true} / accessibilityLabel veya platforma özgü eşdeğer erişilebilirlik özellikleri kullanılarak yardımcı teknolojiler tarafından tek bir bütün olarak algılanmasının sağlanması.)

Web sayfasında / Mobil uygulamada bilgilerin yalnızca görsel biçimlendirme (örneğin, renk, kalın veya italik) kullanılarak vurgulandığı içerikler bulunuyor mu?

(Cevabınız "Hayır" ise Soru 46'ya geçiniz.)

(Örneğin, yalnızca kalın yazı ile önemli bilgi verilmesi, yalnızca renk ile anlam ifade edilmesi veya yalnızca italik yazı ile vurgu yapılması.)

Metin vurguları, bilgi ve ilişkilerin programatik olarak belirlenebilir olmasını sağlayacak şekilde semantik yapılar kullanılarak sunuldu mu?

(Örneğin, web sayfalarında yalnızca görsel kalınlaştırma veya eğik yazı (<b>, <i>, CSS gibi) yerine anlam taşıyan vurgular için <strong> ve <em> etiketlerinin kullanılması, mobil uygulamalarda ise görsel vurgunun taşıdığı anlamın SpannableString / NSAttributedString gibi zengin metin (rich text) yapıları veya contentDescription / accessibilityLabel kullanılarak yardımcı teknolojiler tarafından algılanabilir hâle getirilmesi.)

Web sayfasında / Mobil uygulamada içeriğin anlamının doğru şekilde iletilebilmesi için belirli bir sırayla okunması gereken bir yapı bulunuyor mu?

(Cevabınız "Hayır" ise Soru 49'a geçiniz.)

(Örneğin, talimat adımları, form alanlarının sırası, çok sütunlu içerikler, makale yapısı, adım adım yönlendirmeler, mobil uygulamalarda ise sıralı içerik akışları.)

İçeriğin programatik okuma sırası (web sayfalarında DOM sırası, mobil uygulamalarda ise erişilebilirlik ağacı) görsel sunumdan bağımsız olarak anlamı koruyacak şekilde mantıklı ve doğru bir sırayla sağlandı mı?

NOT: Web sayfalarında ekran okuyucu ile gezinildiğinde içerik mantıklı bir sırayla okunmalı ve CSS ile (örneğin flex-direction: reverse, grid-row, position: absolute gibi yöntemlerle) görsel olarak yeniden sıralanan içeriklerde anlam ve okuma hiyerarşisi bozulmamalıdır. Mobil uygulamalarda ise ekran okuyucu ile gezinildiğinde odak sırasının accessibilityTraversalBefore / accessibilityTraversalAfter / accessibilityElements dizilimi gibi erişilebilirlik özellikleri kullanılarak görsel düzenle uyumlu ve anlamlı olacak şekilde ilerlemesi sağlanmalıdır.

Görsel düzen dikkate alınmadığında (web sayfalarında CSS devre dışı bırakıldığında veya mobil uygulamalarda ise ekran okuyucu ile doğrusal gezinme yapıldığında), içerik mantıksal ve anlaşılabilir bir okuma sırasını koruyor mu?

(Örneğin, web sayfalarında DOM sırası ile görsel sıralamanın çelişmemesi, içerik sırasının mantıklı şekilde oluşturulması ve gerekli durumlarda tabindex kullanımının doğru yapılandırılması, mobil uygulamalarda ise bileşenlerin erişilebilirlik sırasının (accessibility traversal order) doğru tanımlanması, accessibilityTraversalBefore / accessibilityTraversalAfter / accessibilityElements dizilimi gibi erişilebilirlik özellikleri kullanılarak ekran okuyucu odak sırasının anlamlı şekilde ilerlemesinin sağlanması.)

Web sayfasında / Mobil uygulamada kullanıcıya bir içeriği veya arayüz öğesini bulması ya da kullanması için yönlendirme veya kullanım talimatı veriliyor mu?

(Cevabınız "Hayır" ise Soru 51'e geçiniz.)

(Örneğin, işlem adımları, form doldurma talimatları, yönlendirme metinleri.)

Kullanıcıya verilen yönlendirme veya talimatlar, yalnızca duyusal özelliklere (renk, şekil, boyut, görsel konum, yön veya ses gibi) dayalı olmayacak şekilde açık ve anlaşılır biçimde sunuluyor mu?

(Örneğin, "Sağdaki düğmeye basın" yerine "Başvuruyu Tamamla düğmesine basın" ifadesinin kullanılması; "Kırmızı alanı seçin" yerine "E-posta adresi alanını doldurun" gibi alanın adıyla yönlendirme yapılması.)

NOT: Yalnızca renk, konum, şekil, boyut veya ses gibi duyusal özelliklere dayalı ifadeler tek başına kullanılmamalıdır.

Web sayfasında / Mobil uygulamada bilgi, durum, kullanıcı yanıtı veya kullanıcı tarafından gerçekleştirilen bir eylemin renk kullanılarak ifade edildiği içerikler bulunuyor mu?

(Cevabınız "Hayır" ise Soru 54'e geçiniz.)

Örnekler:

• Bilgiye örnek: Bir tabloda en yüksek değerin yalnızca yeşil renkle gösterilmesi, takvimde bugünün tarihinin yalnızca renk farkıyla belirtilmesi,
• Duruma örnek: Haritada riskli bölgelerin kırmızı alanlarla gösterilmesi, bir işlemin başarılı olduğunun yalnızca yeşil arka plan ile belirtilmesi,
• Kullanıcı yanıtına örnek: Sınav sonucunun yalnızca yeşil (✓) ve kırmızı (✗) ikonları kullanılarak gösterilmesi, seçilen cevabın doğruluğunun yalnızca renk değişimi ile belirtilmesi,
• Kullanıcı eylemine örnek: Hata durumunda yalnızca kırmızı bir çerçeve gösterilmesi, yükleme tamamlandığında yalnızca renk değişimi ile bilgi verilmesi.

İçerikte, bilgi, durum, kullanıcı yanıtı veya kullanıcı tarafından gerçekleştirilen bir eylem yalnızca renk kullanılarak ifade edildi mi?

(Cevabınız "Hayır" ise Soru 54'e geçiniz.)

(Örneğin, hata durumunun yalnızca kırmızı çerçeve ile gösterilmesi, doğru/yanlış bilgisinin yalnızca renk ile ifade edilmesi, bağlantıların yalnızca renk farkı ile ayırt edilmesi, grafiklerde veri kategorilerinin yalnızca renk ile ayrılması, zorunlu alanların sadece renk ile belirtilmesi.)

Yalnızca renk kullanılarak ifade edilen bilgi, durum, kullanıcı yanıtı veya eylem için; renge ek olarak metin, ikon, şekil, desen veya benzeri ayırt edici alternatif ipuçları sağlandı mı?

(Örneğin, hata mesajı metninin gösterilmesi, ikon ile durum belirtilmesi, bağlantıların altının çizili olması, grafiklerde renk yanında etiket veya desen kullanılması, zorunlu alanların metin veya simge ile belirtilmesi.)

Web sayfasında / Mobil uygulamada kullanıcı tarafından başlatılmadan otomatik olarak başlayan ve 3 saniyeden uzun süren ses içeriği bulunuyor mu?

(Cevabınız "Hayır" ise Soru 56'ya geçiniz.)

(Örneğin, sayfa veya uygulama açıldığında otomatik başlayan video sesi, arka plan müziği veya otomatik oynayan sesli reklam.)

Otomatik olarak başlayan ses içeriği için kullanıcıya sesi durdurma veya kapatma ya da sistem ses seviyesinden bağımsız olarak ses düzeyini ayarlama imkânı sağlanmış mı?

(Örneğin, "Durdur", "Sessize Al", "Sesi Kapat" düğmesinin bulunması veya medya oynatıcı üzerinde ayrı bir ses düzeyi kontrolü sağlanması.)

Web sayfasında / Mobil uygulamada klavye veya platforma uygun eşdeğer giriş yöntemleri ile kullanılabilmesi gereken etkileşimli bileşenler³ bulunuyor mu?

(Cevabınız "Hayır" ise Soru 69'a geçiniz.)

³ Dipnot 3: Etkileşimli bileşenler; örneğin medya oynatıcı kontrolleri, açılır menüler, diyalog kutuları, pop-up pencereler, odaklanma veya üzerine gelme durumunda görsel durumu değişen bağlantılar, sürükle-bırak işlevleri gibi bileşenleri kapsar.

Web sayfasında / Mobil uygulamada medya oynatıcı bileşenleri (video, ses veya benzeri medya oynatma bileşeni gibi) bulunuyor mu?

(Cevabınız "Hayır" ise Soru 59'a geçiniz.)

Medya oynatıcısında gerçekleştirilen işlemler (oynat, durdur, duraklat, ses ayarı, ileri/geri sarma gibi) klavye veya platforma uygun eşdeğer giriş yöntemleriyle kontrol edilebiliyor ve kapatılabiliyor mu?

(Örneğin, web sayfalarında medya kontrol düğmelerinin <button> etiketiyle oluşturulması ve Enter / Space ile çalıştırılabilmesi, mobil uygulamalarda ise medya kontrollerinin contentDescription / accessibilityTraits = .button / accessibilityLabel / accessibilityRole="button" / accessible={true} kullanılarak erişilebilir giriş yöntemleriyle kontrol edilebilmesi.)

Web sayfasında / Mobil uygulamada açılır menüler (dropdown menu) bulunuyor mu?

(Cevabınız "Hayır" ise Soru 61'e geçiniz.)

Açılır menüler, klavye veya platforma uygun eşdeğer giriş yöntemleriyle açılabiliyor ve menü seçenekleri arasında gezinme ile seçim yapılabiliyor mu?

(Örneğin, web sayfalarında açılır menünün açık/kapalı durumunun aria-expanded ile belirtilmesi, menünün Enter veya Space tuşlarıyla açılabilmesi ve yön tuşlarıyla seçenekler arasında gezinilebilmesi, mobil uygulamalarda ise açılır menü ve menü seçeneklerinin contentDescription / accessibilityLabel / accessibilityTraits = .button / accessibilityTraits = .selected / accessibilityRole="menu" / accessibilityRole="menuitem" / accessible={true} gibi erişilebilirlik özellikleri kullanılarak yardımcı teknolojiler tarafından algılanabilir ve erişilebilir giriş yöntemleriyle seçilebilir hâle getirilmesi.)

Web sayfasında / Mobil uygulamada diyalog kutuları (dialog box) bulunuyor mu?

(Cevabınız "Hayır" ise Soru 63'e geçiniz.)

Diyalog kutuları klavye veya platforma uygun eşdeğer giriş yöntemleriyle kontrol edilebiliyor ve kapatılabiliyor mu?

(Örneğin, web sayfalarında diyalog kutusunun role="dialog" / aria-modal="true" ile tanımlanması; odak yönetiminin sağlanması ve Escape ile kapatılabilmesi, mobil uygulamalarda ise diyalog içeriğinin accessibilityPaneTitle / accessibilityViewIsModal / accessibilityRole="dialog" / accessible={true} kullanılarak erişilebilir şekilde sunulması ve kapatma düğmesinin erişilebilir giriş yöntemleriyle çalıştırılabilmesi.)

Web sayfasında / Mobil uygulamada otomatik açılır pencereler (pop-up) bulunuyor mu?

(Cevabınız "Hayır" ise Soru 65'e geçiniz.)

Otomatik açılan pencereler, klavye veya platforma uygun eşdeğer giriş yöntemleriyle kontrol edilebiliyor ve kapatılabiliyor mu?

(Örneğin, web sayfalarında pencerenin odak alabilmesi, içerik içinde Tab / Shift+Tab ile gezinilebilmesi, tüm etkileşimli bileşenlerin Enter veya Space ile çalıştırılabilmesi ve pencereden çıkışın (Escape ile kapatma gibi) sağlanabilmesi, mobil uygulamalarda ise pencerenin erişilebilir odak alabilmesi, yardımcı teknolojiler ile gezinilebilmesi ve contentDescription / accessibilityLabel / accessibilityRole="button" / accessible={true} gibi erişilebilirlik özellikleri kullanılarak erişilebilir kapatma yöntemleriyle kapatılabilmesi.)

Web sayfasında / Mobil uygulamada işaretleme aygıtı (fare gibi) veya dokunma (touch) ile etkileşimleri (üzerine gelme (hover), odaklanma (focus), dokunma veya tıklama gibi) sonucunda durumu değişen ya da ek içerik veya işlev ortaya çıkan bağlantılar veya arayüz bileşenleri bulunuyor mu?

(Cevabınız "Hayır" ise Soru 67'ye geçiniz.)

(Örneğin, web sayfalarında üzerine gelindiğinde (hover) veya odaklanıldığında (focus) alt menü açan bağlantılar, açıklama balonu (tooltip) gösteren bileşenler ya da tıklama ile açılan menüler, mobil uygulamalarda ise dokunma veya uzun basma ile ek içerik, menü veya işlem seçenekleri gösteren bileşenler ya da kullanıcı etkileşimi sonucunda içerik veya bileşen durumunu değiştiren arayüz öğeleri.)

Etkileşim sonucunda (fare ile üzerine gelme, dokunma veya tıklama gibi) ortaya çıkan veya durumu değişen bağlantılar ve arayüz bileşenleri, klavye veya platforma uygun eşdeğer giriş yöntemleriyle de odaklanılabilir ve kontrol edilebilir durumda mı?

(Örneğin, web sayfalarında fare ile açılan bir alt menünün :focus / :focus-within veya aria-expanded kullanılarak klavye odağıyla da açılabilmesi, mobil uygulamalarda ise dokunma ile açılan bir içeriğin contentDescription / accessibilityLabel / accessibilityRole / accessible={true} gibi erişilebilirlik özellikleri kullanılarak yardımcı teknolojiler veya erişilebilir giriş yöntemleri ile erişilebilir olması.)

Web sayfasında / Mobil uygulamada sürükle-bırak (drag-and-drop) işlevleri bulunuyor mu?

(Cevabınız "Hayır" ise Soru 69'a geçiniz.)

Sürükle-bırak işlevleri, klavye veya platforma uygun eşdeğer giriş yöntemleriyle de gerçekleştirilebiliyor mu?

(Örneğin, web sayfalarında sürükle-bırak ile taşınan bir öğenin klavye ile seçilebilmesi ve Enter, Space, yön tuşları veya taşıma düğmeleri kullanılarak farklı bir konuma taşınabilmesi, mobil uygulamalarda ise sürükle-bırak işlevlerinin AccessibilityAction / accessibilityCustomActions / accessibilityActions veya eşdeğer erişilebilirlik eylemleri kullanılarak yardımcı teknolojiler aracılığıyla gerçekleştirilebilmesi.)

Web sayfasında / Mobil uygulamada kullanıcı etkileşimi veya sistem tarafından tetiklenen ve kullanıcı tarafından kontrol edilmesi gereken içerik veya işlemler (uyarı / bilgilendirme mesajları, otomatik açılır pencereler vb.) bulunuyor mu?

(Cevabınız "Hayır" ise Soru 71'e geçiniz.)

Kontrol gerektiren içerik veya işlemlerden klavye veya platforma uygun eşdeğer giriş yöntemleriyle erişildikten sonra, klavye kilitlenmesi⁴ oluşmadan bu bileşenlerden aynı yöntemlerle çıkabiliyor mu?

(Örneğin, web sayfalarında Tab veya Shift+Tab ile bileşen dışına çıkılabilmesi, Escape ile diyalog kutusunun kapatılabilmesi, odak yönetimi için tabindex kullanımının doğru yapılandırılması veya odaklanan bir bileşenden klavye ile ayrılabilmesi, mobil uygulamalarda ise yardımcı teknolojiler ile gezinirken odaklanan bir bileşenden ayrılabilmesi, açılan bir bileşenin erişilebilir şekilde kapatılabilmesi veya accessibilityPaneTitle / accessibilityViewIsModal / accessibilityRole="dialog" gibi erişilebilirlik özellikleri ya da platform erişilebilirlik API'leri kullanılarak odak yönetiminin doğru şekilde sağlanması.)

⁴ Dipnot 4: Klavye kilitlenmesi (keyboard trap); web sayfalarında kullanıcının klavye ile bir arayüz bileşenine girdikten sonra aynı yöntemlerle bu bileşenden çıkamaması ve odağın bileşen içinde sınırlı kalması durumudur. Mobil uygulamalarda ise kullanıcının yardımcı teknolojiler veya platforma uygun eşdeğer giriş yöntemleri ile bir bileşene eriştikten sonra aynı yöntemlerle bileşenden çıkamaması veya odağın bileşen içinde sıkışıp kalması durumudur.

Web sayfasında / Mobil uygulamada tek bir karakter (harf, sayı, noktalama işareti veya sembol) kullanılarak tetiklenen klavye veya platforma uygun eşdeğer giriş yöntemi kısayolları bulunuyor mu?

(Cevabınız "Hayır" ise Soru 73'e geçiniz.)

(Örneğin, yalnızca "S", "K", "/" veya bir sayı tuşuna basıldığında bir işlemin gerçekleşmesi; harici klavye veya platforma uygun eşdeğer giriş yöntemleri kullanılırken tek karakter ile işlem yapılabilmesi.)

Tek karakterle tetiklenen klavye veya platforma özgü kısayollar için aşağıdaki değerlendirme kriterlerinden en az biri sağlanıyor mu?

Değerlendirme Kriterleri:

1. Tek karakterli klavye veya platforma özgü kısayollar devre dışı bırakılabiliyor olmalı,
2. Klavye veya platforma özgü kısayollar, yazdırılamayan tuşlar (Ctrl, Alt, Command gibi) veya eşdeğer giriş kombinasyonları kullanılarak değiştirilebiliyor olmalı,
3. Bir arayüz bileşeni odaklandığında, yalnızca o bileşenle ilişkili klavye veya platforma özgü kısayollar aktif hâle gelmeli.

(Örneğin, web sayfalarında tek karakterli kısayolların ayarlar menüsü üzerinden devre dışı bırakılabilmesi, Ctrl+S gibi çoklu tuş kombinasyonları kullanılması veya keydown / onkeydown olaylarının yalnızca ilgili bileşen odaklandığında çalıştırılması, mobil uygulamalarda ise harici klavye kısayollarının kullanıcı tarafından değiştirilebilmesi / devre dışı bırakılabilmesi KeyEvent / UIKeyCommand / onKeyDown gibi platform API'leri ve klavye olay mekanizmaları kullanılarak yalnızca ilgili bileşen odaklandığında etkin hâle gelmesinin sağlanması.)

Web sayfasında / Mobil uygulamada kullanıcı arayüzünde gerçekleştirilen işlemler için zaman sınırlaması bulunuyor mu?

(Cevabınız "Hayır" ise veya aşağıdaki istisnai durumlardan biri geçerliyse Soru 75'e geçiniz.)

İstisnai Durumlar:

1. Zaman sınırlaması, gerçek zamanlı bir etkinliğin parçasıysa ve buna makul bir alternatif sunulması mümkün değilse (örneğin, açık artırmalar),
2. Zaman sınırlamasının uzatılması işlemi geçersiz kılıyorsa (örneğin, biletleme sistemleri),
3. Zaman sınırı 20 saatten uzunsa.

(Örneğin, oturum süresinin dolması, belirli süre içinde form doldurma zorunluluğu veya güvenlik nedeniyle işlem süresinin sınırlı olması.)

İstisnai durumlar haricinde zaman sınırlaması bulunan işlemler için aşağıdaki değerlendirme kriterlerinden en az biri sağlanıyor mu?

Değerlendirme Kriterleri:

1. Kullanıcı zaman sınırlamasını durdurabiliyor olmalı,
2. Kullanıcı zaman sınırlamasını varsayılan sürenin en az on katına kadar uzatabiliyor olmalı,
3. Kullanıcı, zaman sınırlaması sona ermeden en az 20 saniye önce uyarılmalı ve basit bir işlemle (örneğin, tek tuşla veya tek dokunuşla) süreyi en az 10 kez uzatabiliyor olmalı.

Web sayfasında / Mobil uygulamada otomatik olarak başlayan ve başka bir içerikle eş zamanlı sunulan hareket eden, kayan, yanıp sönen veya otomatik güncellenen bir bilgi ya da arayüz bileşeni bulunuyor mu?

(Cevabınız "Hayır" ise Soru 79'a geçiniz.)

(Örneğin, otomatik dönen banner/slider'lar, kayan metinler, kaydırmalı içerikler (carousel), otomatik güncellenen duyuru alanları, canlı veri akışları (borsa, skor vb.) veya yanıp sönen uyarılar.)

Bu içerik, 5 saniyeden daha uzun süre boyunca kesintisiz olarak devam ediyor mu?

(Cevabınız "Hayır" ise Soru 79'a geçiniz.)

Bu içerik, duraklatılması, durdurulması veya gizlenmesi durumunda sayfanın veya uygulamanın temel işlevini yerine getirmesini engelleyecek zorunlu bir işlevin parçası (zaman sınırlı sınavlar, geri sayım gerektiren işlemler veya canlı sistem durumu göstergeleri gibi) mı?

(Cevabınız "Evet" ise Soru 79'a geçiniz.)

Otomatik olarak başlayan veya güncellenen içerik, sayfanın veya uygulamanın temel işlevinin zorunlu bir parçası değilse; kullanıcının içeriği duraklatabilmesi, durdurabilmesi, gizleyebilmesi veya otomatik güncellenen içeriklerde güncelleme sıklığını kontrol edebilmesi seçeneklerinden en az biri sağlanıyor mu?

(Örneğin, web sayfalarında slider/carousel bileşenleri için "Duraklat" düğmesi sağlanması, otomatik kayan içeriklerin kullanıcı tarafından durdurulabilmesi, canlı güncellenen içeriklerde aria-live="off" gibi özellikler kullanılarak güncellemelerin kontrol edilebilmesi veya yenileme sıklığının ayarlanabilmesi, mobil uygulamalarda ise otomatik güncellenen içeriklerin erişilebilir kontrol düğmeleri, AccessibilityAction / accessibilityLiveRegion / accessibilityCustomActions veya eşdeğer erişilebilirlik API'leri kullanılarak durdurulabilmesi, gizlenebilmesi ya da güncellemelerin kontrol edilebilmesi.)

Web sayfasında / Mobil uygulamada yanıp sönme (flashing)⁵ etkisi içeren bilgi veya arayüz bileşenleri bulunuyor mu?

(Cevabınız "Hayır" ise Soru 82'ye geçiniz.)

(Örneğin, hızlı yanıp sönen animasyonlar, reklam banner'ları, uyarı ışığı efektleri, video içerikleri.)

⁵ Dipnot 5: Yanıp sönme (flashing), kısa süre içinde gerçekleşen ani parlaklık veya renk değişimlerini ifade eder.

Bu içerik, herhangi bir 1 saniyelik zaman aralığında saniyede 3 kereden fazla ışık çakması (parlama/flashing) içeriyor mu?

(Cevabınız "Hayır" ise Soru 82'ye geçiniz.)

Saniyede 3 kereden fazla yanıp sönen bu içerik, genel yanıp sönme eşiğini veya kırmızı yanıp sönme eşiğini aşan ya da yüksek kontrastlı ani parlaklık (lüminans) değişimleri neden olan ışık çakmaları barındırıyor mu?

(Örneğin, geniş alan kaplayan yüksek frekanslı yanıp sönmeler veya kırmızı ağırlıklı ve yüksek kontrastlı ani ışık geçişleri gibi.)

ÖNEMLİ: Bu soruya "Evet" cevabı verilmesi, içeriğin sağlık riski taşıdığını gösterir. 3 saniyeden fazla yanıp sönen her türlü tasarımlardan kaçınılması önerilir.

Teknik Açıklama:

• Yanıp sönme etkisinin bitişik alanı, görme alanında yaklaşık 0.006 steradyan sınırını aşmamalıdır. (Referans: 1024 × 768 çözünürlükte yaklaşık 21.824 bitişik piksel)
• Yanıp sönme, baskın kırmızı içeren (R / (R+G+B) ≥ 0.8) geçişler içermemelidir.
• Yüksek kontrastlı parlaklık (lüminans) Saniyede 3 kereden fazla gerçekleştiğinde risk oluşturabilir.

Web sayfasında / Mobil uygulamada farklı sayfalarda veya ekranlarda tekrar eden içerik blokları bulunuyor mu?

(Cevabınız "Hayır" ise Soru 84'e geçiniz.)

(Örneğin, ana menü, üst gezinme çubuğu, yan menü, site başlığı veya tekrar eden navigasyon bağlantıları.)

Kullanıcıların tekrar eden içerik bloklarını atlayarak ana içeriğe veya bir sonraki anlamlı bölüme doğrudan erişebilmesini sağlayan bir mekanizma sunuluyor mu?

(Örneğin, web sayfalarında "Ana içeriğe geç" bağlantısı (skip link), klavye ile erişilebilen sayfa içi atlama bağlantıları veya <main>, <nav> gibi bölge (landmark) etiketleri ile eşdeğer yöntemler, mobil uygulamalarda ise ana içeriğe hızlı erişim sağlayan erişilebilir navigasyon mekanizmaları, yardımcı teknolojilerle doğrudan geçiş sağlayan eşdeğer yöntemler veya accessibilityHeading / accessibilityTraits = .header ve erişilebilir odak yönetimi özellikleri kullanılarak bölüm geçişlerinin sağlanması.)

Web sayfasında / Mobil uygulamada her bir sayfa veya ekran için bir başlık bulunuyor mu?

(Cevabınız "Hayır" ise Soru 86'ya geçiniz.)

Sayfa veya ekran başlıkları, içeriğin konusunu veya amacını açık, doğru ve ayırt edici biçimde tanımlıyor mu?

(Örneğin, web sayfalarında <title> etiketi ile tanımlanan başlıkların içeriğin konusunu veya amacını açık şekilde ifade etmesi, mobil uygulamalarda ise ekran başlığının accessibilityPaneTitle / accessibilityHeading / accessibilityTraits = .header / accessibilityLabel / accessibilityRole="header" gibi platform erişilebilirlik API'leri aracılığıyla yardımcı teknolojiler tarafından algılanabilir ve ayırt edilebilir şekilde sunulması.)

Web sayfasında / Mobil uygulamada klavye veya platforma uygun odaklama yöntemiyle erişilebilen etkileşimli öğeler (bağlantılar, butonlar, form alanları, menüler vb.) bulunuyor mu?

(Cevabınız "Hayır" ise Soru 88'e geçiniz.)

Etkileşimli öğeler arasında klavye veya platforma uygun odaklama yöntemiyle gezinildiğinde, odak sırası kullanıcı için mantıklı, tutarlı ve anlamlı bir sırayı takip ediyor mu?

(Örneğin, web sayfasında Tab / Shift+Tab tuşlarıyla gezinildiğinde odak sırasının kaynak kod (DOM) sırası ve görsel tasarımla uyumlu şekilde ilerlemesi, odak yönetimi için pozitif tabindex değerlerinden kaçınılması; mobil uygulamalarda ise ekran okuyucu ile gezinildiğinde odak sırasının görsel düzen ve kullanıcı beklentisiyle uyumlu ilerlemesi, bunun için accessibilityTraversalBefore / accessibilityTraversalAfter / accessibilityElements dizisi veya görünüm/bileşen hiyerarşisinin (component tree) doğru yapılandırılması gibi yöntemlerle odak sırasının yönetilmesi.)

Web sayfasında / Mobil uygulamada iç sayfalara, uygulama içi ekranlara veya farklı kaynaklara yönlendiren bağlantılar bulunuyor mu?

(Cevabınız "Hayır" ise Soru 95'e geçiniz.)

Bağlantı metni veya erişilebilir bağlantı adı, tek başına değerlendirildiğinde bağlantının amacını açık ve anlaşılır biçimde ifade ediyor mu?

(Cevabınız "Evet" ise Soru 91'e geçiniz.)

(Örneğin, web sayfalarında bağlantı metninin "Erişilebilirlik Raporu (PDF)" veya "Başvuru Formunu İndir" gibi açıklayıcı yazılması, yalnızca "Tıklayınız" / "Devamı" gibi belirsiz bağlantı metinleri kullanılıyorsa aria-label / aria-labelledby ile bağlantının amacının tanımlanması, mobil uygulamalarda ise bağlantı veya bağlantı işlevi gören bileşenlerin amacını açık şekilde ifade etmesi için contentDescription / accessibilityLabel / accessibilityTraits = .link / accessibilityRole="link" özelliklerinin kullanılması.)

NOT: "Tıklayınız", "Devamı" veya "Buraya tıklayın" gibi belirsiz ifadeler tek başına yeterli değildir.

Bağlantının amacı, bulunduğu bağlam (başlık, paragraf, liste öğesi, tablo hücresi veya ilişkili içerik gibi) ile birlikte programatik olarak belirlenebilir mi?

(Örneğin, web sayfalarında "Detay" bağlantısının "2026 Erişilebilirlik Raporu" başlığı altında yer alması, bir tablo satırında belge adı ile birlikte sunulması veya aria-labelledby kullanılarak ilişkili içerikle programatik bağ kurulması, mobil uygulamalarda ise bağlantının bir içerik kartı veya liste öğesi içinde yer alması ve bağlamın ekran okuyucuya bir bütün olarak sunulabilmesi için kapsayıcı bileşenlerin gruplandırılması, bunun için focusable="true" / shouldGroupAccessibilityChildren / accessible={true} gibi özellikler kullanılarak bağlantının ilgili metinle programatik olarak ilişkilendirilmesi.)

NOT: Bağlam; kullanıcı tarafından algılanabilir içerik üzerinden değerlendirilmelidir. Yalnızca title özniteliği ile veya kullanıcıya görünmeyen açıklamalar ile sağlanan bilgiler yeterli kabul edilmez.

Web sayfasında / Mobil uygulamada yalnızca simge ile sunulan veya görsel olarak kısa tutulan bağlantılar bulunuyor mu?

(Cevabınız "Hayır" ise Soru 93'e geçiniz.)

Yalnızca simge ile sunulan veya görsel olarak kısa tutulan bağlantılar için bağlantının amacını açıklayan erişilebilir bir ad sağlandı mı?

(Örneğin, web sayfalarında yalnızca ikon ile sunulan bağlantılar için açıklayıcı metin, aria-label veya aria-labelledby ile erişilebilir ad tanımlanması, mobil uygulamalarda ise simge ile sunulan bağlantı veya bağlantı işlevi gören bileşenlere amacını belirtmek için contentDescription / accessibilityLabel / accessibilityTraits = .link / accessibilityRole="link" özellikleri kullanılarak erişilebilir ad atanması.)

Web sayfasında / Mobil uygulamada aynı bağlantı metnine veya erişilebilir bağlantı adına sahip birden fazla bağlantı bulunuyor mu?

(Cevabınız "Hayır" ise Soru 95'e geçiniz.)

Aynı bağlantı metnine veya erişilebilir bağlantı adına sahip bağlantılar bulunduğunda, her birinin amacı bağlamı ile birlikte kullanıcı tarafından ayırt edilebilir mi?

(Örneğin, web sayfalarında aynı "Detay" bağlantılarının farklı içerik başlıkları altında yer alarak hangi içeriğe ait olduğunun anlaşılabilmesi, bir liste veya tablo içinde ilgili içerik adıyla birlikte sunulması ya da aria-labelledby kullanılarak ilişkili içerikle bağ kurulması, mobil uygulamalarda ise aynı metne sahip düğmelerin ilgili içerik başlığı veya içerik kartı ile birlikte aynı bileşen içinde yer alması ya da contentDescription / accessibilityLabel özellikleri kullanılarak ayırt edilebilir şekilde tanımlanması.)

Web sayfasında / Mobil uygulamada birden fazla işaretçi hareketi veya belirli bir hareket (gesture) gerektiren işaretçi⁶ etkileşimleri bulunuyor mu?

(Cevabınız "Hayır" ise Soru 97'ye geçiniz.)

(Örneğin, web sayfalarında sürükle-bırak (drag-and-drop), uzun basılı tutma veya fare ile çizim yapma gibi birden fazla adımlı etkileşimlerin bulunması, mobil uygulamalarda ise kaydırma (swipe), çimdikleme (pinch-to-zoom), çoklu dokunma (multi-touch) veya sürükle-bırak gibi karmaşık işaretçi hareketleri gerektiren etkileşimlerin yer alması.)

⁶ Dipnot 6: İşaretçi; fare, dokunmatik ekran, stylus ve benzeri işaretleme yöntemlerini kapsar.

Bu işlevler için aynı sonucu sağlayan ve karmaşık işaretçi hareketi gerektirmeyen alternatif bir etkileşim yöntemi sunuluyor mu?

(Örneğin, web sayfalarında harita yakınlaştırmak için çimdikleme (pinch-to-zoom) yerine "+ / –" düğmelerinin bulunması, sürükle-bırak işlemleri yerine tıklanabilir yön okları veya menülerin sunulması, mobil uygulamalarda ise kaydırma (swipe) yerine tek dokunuşla çalışan ileri/geri düğmelerinin bulunması veya ekran okuyucu kullanıcıları için AccessibilityAction, / accessibilityCustomActions / accessibilityActions özellikleri kullanılarak bu işlevlere alternatif erişim sağlanması.)

Web sayfasında / Mobil uygulamada işaretçi (pointer) ile tetiklenen işlemler bulunuyor mu?

(Cevabınız "Hayır" ise veya aşağıdaki istisnai durumlardan biri geçerliyse Soru 99'a geçiniz.)

İstisnai Durumlar:

1. Eylemin işlevi gereği anında gerçekleşmesinin zorunlu olduğu durumlar (örneğin, piyano uygulamasında tuşa basıldığı anda ses üretilmesi),
2. İşlemin iptal edilmesinin mümkün olmadığı durumlar. (örneğin, joystick ile oyunlarda karakter hareketinin kontrol edilmesi).

NOT: Kullanıcı arayüzü bileşenlerinin çoğunda işlemlerin iptal edilmesi veya geri alınması teknik olarak mümkündür. Bu nedenle yalnızca eylemin doğası gereği anında gerçekleşmesinin zorunlu olduğu ve gecikmenin işlevi ortadan kaldırdığı durumlar istisna olarak değerlendirilmelidir.

İstisnai durumlar haricinde, işaretçi ile tetiklenen işlemler yanlışlıkla tetiklenmeyi önleyecek şekilde aşağıdaki koşullardan en az birini sağlıyor mu?

1. İşlem yalnızca işaretçinin veya parmağın bırakılması (up-event) ile tetikleniyor olmalı,
2. İşlem tamamlanmadan önce iptal edilebiliyor olmalı
3. İşlem tamamlandıktan sonra geri alınabiliyor olmalı,
4. İşlem, yalnızca işlevi gereği zorunlu olan istisnai durumlarda işaretçinin basılması veya dokunma anında (down-event) tetikleniyor olmalı.

NOT: Yalnızca işaretçinin basılması veya dokunma anında (down-event) tetiklenen işlemler, istisnai durumlar dışında uygun değildir.

Web sayfasında / Mobil uygulamada kullanıcıya görünür metin etiketleri (label) ile sunulan arayüz bileşenleri bulunuyor mu?

(Cevabınız "Hayır" ise Soru 101'e geçiniz.)

(Örneğin, butonlar, bağlantılar, form alanları, arama kutuları, menü öğeleri.)

Görünür etiket (label) bulunan arayüz bileşenlerinde, erişilebilir ad; görünür etiket metniyle aynı mı veya görünür etiket metniyle başlıyor mu?

(Örneğin, web sayfalarında <label> etiketi, aria-label veya aria-labelledby öznitelikleri ile sağlanan erişilebilir adın görünür etiket ile aynı olması veya görünür etiket metniyle başlaması, mobil uygulamalarda ise erişilebilir adın contentDescription / accessibilityLabel özellikleri kullanılarak görünür etiket ile aynı olması veya görünür etiket metniyle başlayacak şekilde ayarlanması.)

Web sayfasında / Mobil uygulamada kullanıcı arayüzünde cihazın hareket ettirilmesine (sallama, döndürme, eğme gibi) veya yön değiştirmesine bağlı olarak gerçekleştirilen herhangi bir işlem bulunuyor mu?

(Cevabınız "Hayır" ise veya aşağıdaki istisnai durumlardan biri geçerliyse Soru 104'e geçiniz.)

İstisnai Durumlar:

1. Yardımcı teknolojiler tarafından uygulanan veya erişilebilirlik amacıyla kullanılan hareketler,
2. Kullanıcı tarafından kasıtlı olarak yapılan el hareketleri (örneğin, sağlık uygulamasındaki adımsayar kullanımı veya bir haritada yönü belirlemek amacıyla yapılan hareketler),
3. Konum veya yön sensörleri tarafından algılanan ve içeriğin temel işleviyle doğrudan ilişkili olan hareketler.

Cihaz hareketiyle gerçekleştirilen bu işlemler için hareket kullanılmadan aynı sonucu sağlayan alternatif bir yöntem sunuluyor mu?

(Örneğin, cihazı sallayarak (shake) veya eğerek (tilt) yapılan bir işlemin (örneğin "Geri Al" işlevi) aynı zamanda arayüzdeki erişilebilir bir düğme ile de gerçekleştirilebilmesi; web sayfalarında işlemlerin ekrandaki düğmeler veya klavye ile gerçekleştirilebilmesi; mobil uygulamalarda ise fiziksel hareket yerine ekranda erişilebilir bir düğmenin sunulması veya ekran okuyucu kullanıcıları için AccessibilityAction, / accessibilityCustomActions / accessibilityActions özellikleri kullanılarak bu işlevlere programatik alternatif sağlanması.)

Cihaz hareketiyle tetiklenen işlevler kullanıcı tarafından devre dışı bırakılabiliyor mu?

(Örneğin, cihaz sallandığında tetiklenen bir işlem için bu özelliğin ayarlar üzerinden kapatılabilmesi veya hareketle kontrol edilen bir işlevin düğme, anahtar (switch) ya da erişilebilir alternatif bir yöntemle kullanılabilmesi.)

Web sayfasında / Mobil uygulamada sunulan içeriğin varsayılan dili programatik olarak tanımlandı mı?

(Örneğin, web sayfalarında lang özniteliği kullanılarak sayfanın varsayılan dilinin belirtilmesi, mobil uygulamalarda ise içeriğin varsayılan dilinin erişilebilirlik API'leri veya platform dil ayarları aracılığıyla tanımlanması.)

Web sayfasında / Mobil uygulamada odaklanılabilen (klavye veya platforma uygun yöntemlerle erişilebilen) arayüz bileşenleri bulunuyor mu?

(Cevabınız "Hayır" ise Soru 107'ye geçiniz.)

(Örneğin, metin kutuları (text box), seçenek düğmeleri (radio button), arama alanları (search field), site içi gezinme bağlantıları (breadcrumb), sayfalama (pagination), bildirim menüleri veya menüler.)

Bir arayüz bileşenine yalnızca odaklanılması sonucu, kullanıcı tarafından ek bir işlem (tıklama, onaylama gibi) yapılmadan bağlam değişikliği gerçekleşiyor mu?

NOT: Web sayfalarında klavye ile Tab tuşu kullanılarak (onfocus olayı tetiklendiğinde), mobil uygulamalarda ise ekran okuyucu ile odak alındığında (onFocusChange / accessibilityElementDidBecomeFocused / onFocus olayları tetiklendiğinde), otomatik olarak yeni bir sayfaya veya ekrana yönlendirme, pop-up açılması ya da içeriğin aniden değişmesi gibi durumlar olmamalıdır.

Web sayfasında / Mobil uygulamada kullanıcı bir arayüz bileşenine girdi verdiğinde (bir seçenek seçtiğinde, bir alanın değerini değiştirdiğinde veya bir form alanına veri girdiğinde) bağlam değişikliği⁷ gerçekleşiyor mu?

(Cevabınız "Hayır" ise Soru 109'a geçiniz.)

⁷ Dipnot 7: Bağlam değişikliği; yeni bir sayfaya veya ekrana yönlendirme, formun ya da işlemin otomatik olarak başlatılması veya yeni bir pencerenin ya da diyalog kutusunun açılması gibi durumları ifade eder.

Kullanıcı arayüz bileşenlerine girdi verilmesi sonucunda gerçekleşen bağlam değişikliği için aşağıdaki değerlendirme kriterlerinden en az biri sağlanıyor mu?

Değerlendirme Kriterleri:

1. Bağlam değişikliği, kullanıcı tarafından başlatılan açık bir işlem (örneğin, "Gönder", "Devam Et" veya "Onayla" düğmesi) sonucunda gerçekleşiyor olmalı,
2. Bağlam değişikliği gerçekleşmeden önce kullanıcı bu değişiklik hakkında açık bir şekilde bilgilendiriliyor olmalı.

(Örneğin, web sayfalarında bir açılır menüden seçim yapıldığında sayfanın otomatik yenilenmesi yerine <button> etiketiyle oluşturulmuş "Devam Et" düğmesinin kullanılması veya aria-describedby ile kullanıcıya bu davranış hakkında önceden bilgi verilmesi; mobil uygulamalarda ise seçim sonrasında otomatik ekran değişikliği yerine erişilebilir bir onay düğmesi kullanılması veya bileşen üzerinde contentDescription / accessibilityHint özellikleri kullanılarak ekran veya bağlam değişikliği bilgisinin kullanıcıya önceden iletilmesi.)

Web sayfasında / Mobil uygulamada aşağıda yer alan yardım mekanizmalarından herhangi biri bulunuyor mu?

1. İletişim Sayfaları / Ekranları veya İletişim Bilgileri (Telefon Numarası, E-posta adresi, Adres gibi.),
2. İnsan Etkileşimli Yardım Kanalları (İletişim Formu, Canlı Destek, Sosyal Medya gibi.),
3. Sıkça Sorulan Sorular (SSS), Destek Sayfaları / Ekranları, Yardım İçerikleri veya Kendi Kendine Yardım Bölümleri,
4. Otomatik Sohbet (Chatbot) sistemleri.

(Cevabınız "Hayır" ise Soru 111'e geçiniz.)

Bu yardım mekanizmaları, web sayfası veya mobil uygulama içinde farklı sayfalar ve ekranlar arasında tutarlı ve öngörülebilir bir konumda sunuluyor mu?

(Örneğin, yardım bağlantısının her sayfada aynı menü içinde yer alması veya yardım/destek düğmesinin tüm sayfa ve ekranlarda kolay bulunabilir bir konumda sunulması.)

Web sayfasında / Mobil uygulamada kullanıcının veri girişi yapmasını gerektiren ve hata yapma olasılığı bulunan bir işlem bulunuyor mu?

(Cevabınız "Hayır" ise Soru 115'e geçiniz.)

(Örneğin, form alanları, kayıt/başvuru sayfaları veya ekranları, arama alanları ya da doğrulama gerektiren girişler.)

Kullanıcı veri girişinde hata yaptığında, hata durumu kullanıcıya metinsel bir hata mesajı ile bildiriliyor mu?

(Örneğin, web sayfalarında hatalı alanların <input> ile ilişkilendirilmiş görsel hata mesajları ve aria-invalid="true" veya aria-describedby kullanılarak kullanıcıya bildirilmesi, mobil uygulamalarda ise hata mesajlarının ekranda erişilebilir metin olarak sunulması ve hatalı bileşenle ilişkilendirilmesi için setError / contentDescription / accessibilityLabel / accessibilityValue / accessibilityLabel / accessibilityState={{ invalid: true }} gibi erişilebilirlik özellikleri kullanılarak yardımcı teknolojilere aktarılması.)

Hata mesajı, hatanın nedenini kullanıcı tarafından anlaşılabilir şekilde açık ve net olarak ifade ediyor mu?

(Örneğin, "Hata var" yerine "E-posta adresi geçerli formatta girilmelidir" gibi açıklayıcı hata mesajlarının sunulması; web sayfalarında bu hata metinlerinin aria-describedby ile ilgili form alanıyla ilişkilendirilmesi, mobil uygulamalarda ise açıklayıcı hata metninin ilgili form bileşeniyle ilişkilendirilmesi için setError / contentDescription / accessibilityValue / accessibilityLabel veya benzeri erişilebilirlik özellikleri kullanılarak yardımcı teknolojilere aktarılması.)

Hata mesajı, hatanın hangi giriş alanıyla ilgili olduğunu kullanıcıya açıkça bildiriyor mu?

(Örneğin, web sayfalarında hata mesajının görsel olarak ilgili alanın yakınında gösterilmesi ve aria-describedby kullanılarak giriş alanı ile programatik bağ kurulması, mobil uygulamalarda ise hata mesajının görsel olarak giriş alanıyla birlikte sunulması ve hatanın ilgili bileşenle ilişkilendirilmesi için setError, contentDescription, accessibilityLabel, accessibilityValue / accessibilityHint gibi erişilebilirlik özellikleri kullanılarak yardımcı teknolojilere aktarılması.)

Web sayfasında / Mobil uygulamada kullanıcıdan veri girişi veya seçim yapılması istenen alanlar ya da arayüz bileşenleri bulunuyor mu?

(Cevabınız "Hayır" ise Soru 121'e geçiniz.)

(Örneğin, form alanları, seçim kontrolleri, arama alanları, tarih seçiciler, onay kutuları veya radyo düğmeleri.)

Kullanıcıdan veri girişi veya seçim yapılması istenen alanlar ve arayüz bileşenleri için istenen bilginin amacını açıkça ifade eden anlamlı ve açıklayıcı etiketler veya gereken durumlarda veri girişi öncesinde sunulan talimatlar sağlanıyor mu?

(Örneğin, web sayfalarında "Ad Soyad", "E-posta adresi" veya "Telefon numarası" gibi açıklayıcı etiketlerin <label> etiketi ile sunulması, format kuralları gibi talimatların aria-describedby ile ilişkilendirilmesi, mobil uygulamalarda ise veri giriş alanlarının ve talimatların hint / contentDescription, accessibilityLabel / accessibilityHint gibi erişilebilirlik özellikleri kullanılarak açık ve anlaşılır şekilde tanımlanması.)

NOT: Web sayfasında yer tutucu metin (placeholder), alan etiketi yerine kullanılmamalıdır. Mobil uygulamalarda ise yalnızca yer tutucu metin veya ikon ile sunulan alanlarda, erişilebilir adın açıkça tanımlanması zorunludur.

Web sayfasında / Mobil uygulamada belirli bir formatta veya kurala bağlı veri girişi gerektiren alanlar bulunuyor mu?

(Cevabınız "Hayır" ise Soru 119'a geçiniz.)

(Örneğin, parola, tarih, e-posta, kimlik numarası veya telefon numarası alanları.)

Bu alanlar için veri girişi yapılmadan önce kullanıcıya açık, anlaşılır ve erişilebilir talimatlar sunuluyor mu?

(Örneğin, web sayfalarında parola kurallarının, tarih formatının "GG/AA/YYYY" biçiminde veya e-posta formatı bilgilerinin alan ile ilişkilendirilmiş şekilde aria-describedby kullanılarak sunulması, mobil uygulamalarda ise format ve kural bilgilerinin hint / contentDescription / accessibilityHint / accessibilityLabel gibi erişilebilirlik özellikleri kullanılarak ekran okuyucu tarafından algılanabilir şekilde sunulması.)

Web sayfasında / Mobil uygulamada zorunlu doldurulması gereken alanlar bulunuyor mu?

(Cevabınız "Hayır" ise Soru 121'e geçiniz.)

Zorunlu alanlar kullanıcıya açık ve anlaşılır şekilde belirtildi mi?

(Örneğin, web sayfalarında "Zorunlu alan" ifadesi, <label> ile birlikte metinsel olarak sunulması veya aria-required="true" kullanılarak zorunlu alan bilgisinin yardımcı teknolojilere aktarılması; mobil uygulamalarda ise zorunlu alan bilgisinin görünür metinle sunulması ve bu durumun contentDescription / accessibilityLabel metinlerine dâhil edilerek yardımcı teknolojilere aktarılması.)

NOT: Yalnızca yıldız (*) işareti (açıklaması sayfa başında veya sonunda metin olarak verilmemişse) veya yalnızca renk (örneğin kutunun kırmızı gösterilmesi) kullanımı yeterli değildir.

Web sayfasında / Mobil uygulamada aynı adımlar dizisi içerisinde, kullanıcıdan daha önce girdiği bir bilgiyi tekrar girmesi isteniyor mu?

(Cevabınız "Hayır" ise veya aşağıdaki istisnai durumlardan biri geçerliyse Soru 123'e geçiniz.)

İstisnai Durumlar:

• Güvenlik amacıyla tekrar girilmesi gereken bilgiler (örneğin, parola veya doğrulama kodu),
• Bilginin doğruluğunu teyit etmek amacıyla yapılan tekrar girişler (örneğin, e-posta teyidi),
• Geçerliliğini yitirmiş veya güncellenmesi gereken bilgiler

(Örneğin, teslimat adresi ile fatura adresinin ayrı ayrı girilmesinin istenmesi, çok adımlı bir form veya işlem içinde aynı kimlik bilgisinin tekrar istenmesi ya da kullanıcı profilinde mevcut bilgilerin yeniden girilmesinin istenmesi.)

İstisnai durumlar haricinde, aynı adımlar dizisi içerisinde kullanıcıdan daha önce alınmış bilgiler, aynı işlem süreci içinde otomatik olarak dolduruluyor veya bu bilgilerin yeniden kullanılmasına imkân tanınıyor mu?

(Örneğin, web sayfalarında autocomplete özniteliği kullanılarak otomatik doldurma sağlanması veya "Fatura adresi teslimat adresi ile aynı" gibi bir seçenek sunulması; mobil uygulamalarda ise daha önce girilen bilgilerin yeniden seçilebilir şekilde sunulması veya platformun otomatik doldurma (autofill) mekanizmalarının autofillHints / textContentType / autoComplete veya benzeri erişilebilirlik ve otomatik doldurma özellikleri aracılığıyla desteklenmesi.)

Web sayfasında / Mobil uygulamada kullanıcı arayüzü bileşenleri (form alanları, bağlantılar, butonlar, açılır listeler, sekmeler, menüler veya özel tasarlanmış etkileşimli bileşenler gibi) bulunuyor mu?

(Cevabınız "Hayır" ise kontrol listesi tamamlanmıştır.)

Kullanıcı arayüzü bileşenlerinin ad (name) ve rol (role) bilgileri programatik olarak belirlenebilir mi?

(Örneğin, web sayfalarında bir butonun erişilebilir adının "Kaydet" olarak tanımlanması (name) ve rolünün "button" olarak belirlenmesi (role), form kontrollerinin standart semantik HTML ile oluşturulması, erişilebilir adın <label>, aria-label veya aria-labelledby ile tanımlanması ya da özel (custom) bileşenlerde uygun ARIA rol ve özelliklerinin kullanılması; mobil uygulamalarda ise erişilebilir ad ve rol bilgilerinin contentDescription / accessibilityLabel / accessibilityTraits / accessibilityRole gibi erişilebilirlik özellikleri kullanılarak yardımcı teknolojilere doğru şekilde iletilmesi.)

Kullanıcı arayüzü bileşenlerinin durum (state), özellik (property) ve değer (value) bilgileri programatik olarak belirlenebilir ve yardımcı teknolojiler tarafından doğru şekilde algılanabilir mi?

(Örneğin, web sayfalarında bir onay kutusunun işaretli/işaretsiz olması bir akordeon menünün açık/kapalı durumu veya bir kaydırıcının mevcut değerinin aria-checked / aria-expanded / aria-valuenow gibi erişilebilirlik özellikleri ile yardımcı teknolojilere aktarılması, mobil uygulamalarda ise bileşenlerin durum ve değer bilgilerinin AccessibilityNodeInfo / RangeInfo / accessibilityTraits / accessibilityState / accessibilityValue gibi erişilebilirlik özellikleri kullanılarak yardımcı teknolojilere doğru şekilde iletilmesi.)

Kullanıcı etkileşimi sonucunda kullanıcı arayüzü bileşenlerinde meydana gelen durum veya değer bilgilerinde meydana gelen değişiklikler, yardımcı teknolojiler tarafından programatik olarak algılanabilir şekilde güncelleniyor mu?

(Örneğin, web sayfalarında sekme, açılır menü, onay kutusu, anahtar (switch) veya kaydırıcı (slider) gibi bileşenlerle etkileşime girildiğinde aria-expanded, aria-selected, aria-checked / aria-valuenow gibi ARIA özelliklerinin anlık olarak güncellenmesi, mobil uygulamalarda ise bileşenlerin seçili, işaretli, açık/kapalı veya mevcut değer bilgilerinin AccessibilityNodeInfo, RangeInfo, accessibilityTraits, accessibilityValue, accessibilityState veya benzeri erişilebilirlik özellikleri kullanılarak yardımcı teknolojilere doğru şekilde aktarılması.)

(Kontrol listesi tamamlanmıştır.)