WCAG 2.5.5: Hedef Boyutu (Gelişmiş)

Bu Kuralın Anlamı

WCAG 2.5.5 Hedef Boyutu (Gelişmiş), WCAG 2.2 kapsamında Etki Düzeyi AAA olan ve etkileşimli öğeler için katı bir minimum boyut belirleyen bir ölçüttür. Özellikle, herhangi bir kullanıcı arayüzü bileşeninin tıklanabilir veya dokunulabilir alanı olan hedefin boyutunun hem genişlik hem yükseklik olarak en az 44’e 44 CSS piksel olmasını şart koşar. Bu, fare tıklamaları, dokunmatik ekran dokunuşları ve kalem girişi dahil tüm işaretçi tabanlı etkileşimler için geçerlidir.

Bu bağlamda “hedef”in tam olarak neyi ifade ettiğini anlamak önemlidir. Hedef, yalnızca görsel temsil değil, kontrolün etkinleştirilebilir alanının tamamıdır. Küçük bir simge görsel olarak 16×16 piksel olabilir, ancak etrafındaki iç boşluk (padding) tıklanabilir alanı 44×44 piksele genişletiyorsa, ölçüt yine de karşılanmış olur. Bu, geliştiricilerin görsel tasarımı dramatik biçimde değiştirmeden gereksinimi karşılamak için padding’i stratejik olarak kullanabileceği anlamına gelir.

Ölçüt, bir başarıyı hedef alanı en az 44×44 CSS piksel olan herhangi bir etkileşimli öğe olarak tanımlar. Bir başarısızlık ise, etkileşimli bir öğenin etkinleştirilebilir alanı herhangi bir boyutta bu eşik değerin altına düştüğünde ortaya çıkar — örneğin, 44 piksel genişliğinde ancak yalnızca 20 piksel yüksekliğinde bir bağlantı yine de başarısız sayılır.

WCAG 2.5.5, 44×44 gereksiniminin uygulanmadığı birkaç resmi istisna sunar. Bunlar şunlardır:

• Boşluk: Yetersiz boyuttaki hedefler, yeterli boşlukla diğer tüm hedeflerden ayrılıyorsa kabul edilebilir. Hedef, merkezine 44×44 CSS piksel boyutunda bir daire yerleştirildiğinde, bu dairenin başka hiçbir hedefle veya başka bir hedefin 44×44 dairesinin sınırlayıcı kutusuyla kesişmeyeceği şekilde konumlandırılmalıdır. Bu istisna, bitişik kontroller doğası gereği küçük ama iyi ayrılmış olduğunda, kuralın yerleşim değişikliklerini zorunlu kılmasını engeller.
• Eşdeğer: Aynı sayfada aynı işlevi yerine getiren ve minimum boyut gereksinimini karşılayan alternatif bir kontrol bulunur.
• Satır içi (inline): Hedef bir cümlenin içindedir veya boyutu, hedef olmayan metnin satır yüksekliği tarafından kısıtlanmaktadır. Örneğin, gövde metni paragrafı içindeki köprüler, yeniden boyutlandırılmaları metin akışını bozacağı için bu kuraldan muaftır.
• Kullanıcı aracısı kontrolü: Boyut tamamen tarayıcı veya işletim sistemi tarafından belirlenir ve yazar tarafından değiştirilemez. Stil verilmemiş durumdaki yerel tarayıcı form kontrolleri bu kategoriye girebilir.
• Temel/Esensiyel: Hedefin belirli bir sunumu, iletilen bilgi için esastır. Bu, hedef boyutunun değiştirilmesinin anlamı veya işlevselliği temelden değiştireceği dar kapsamlı bir istisnadır.

Bu ölçüt WCAG 2.2’de tanıtılmış ve işaretçi hedefleriyle ilgili önceki, daha az katı rehberin yerini almıştır. Eşlik eden ölçütü olan WCAG 2.5.8 Hedef Boyutu (Minimum) Düzey AA’da, boşluk temelli bir hesaplamayla 24×24 CSS piksel gibi daha düşük bir eşik belirler, ancak 2.5.5, gelişmiş erişilebilirlik için altın standart olmaya devam eder.

Neden Önemlidir

Motor ve beceri (el-göz koordinasyonu) bozuklukları, dünya nüfusunun önemli bir bölümünü etkiler. Dünya Sağlık Örgütü’ne göre, yaklaşık 1,3 milyar insan — yani dünya nüfusunun %16’sı — önemli bir engellilik haliyle yaşamaktadır ve motor ile kas-iskelet sistemi rahatsızlıkları en yaygın olanlar arasındadır. Parkinson hastalığı, esansiyel tremor, serebral palsi, multipl skleroz, inme kaynaklı hemipleji ve tekrarlayan zorlanma yaralanmaları gibi durumların tümü, kişinin hassas işaretçi hareketleri yapma yeteneğini azaltır. Mobil cihazlarda, engeli olmayan kullanıcılar bile eldiven kullanırken, elleri ıslakken veya telefonu tek elle kullanırken küçük hedeflerle zorlanabilir.

Somut bir gerçek dünya senaryosunu düşünün: Romatoid artriti olan bir kişi, ilaç satın almak için dokunmatik ekranlı bir tablet üzerinden bir Türk e-ticaret platformunda gezinmektedir. Ödeme akışında küçük radyo düğmeleri, dar açılır menüler ve 24×18 piksel boyutunda bir “Siparişi Onayla” düğmesi bulunmaktadır. Her yanlış dokunuş ya yanlış seçeneği işaretler ya da hiçbir şey yapmaz, bu da kullanıcının defalarca denemesine neden olur. Bu hayal kırıklığı sadece rahatsız edici olmakla kalmaz — satın alma işlemini tamamen yarıda bırakmasına yol açabilir ve bir erişilebilirlik hatasını doğrudan gelir kaybına dönüştürebilir.

Motor bozuklukların ötesinde, yeterli boyuttaki hedefler geniş bir kullanıcı yelpazesine fayda sağlar. Yaşlı yetişkinler genellikle hem ince motor kontrolünde azalma hem de görme keskinliğinde düşüş yaşar, bu da küçük hedefleri iki kat zorlaştırır. Bilişsel engeli olan kullanıcılar, işaretçiyi konumlandırmak için daha fazla zamana ihtiyaç duyabilir ve hedefler sıkışık olduğunda bitişik kontrolleri yanlışlıkla tetikleme olasılıkları daha yüksektir. Hatta gören ve bedensel engeli olmayan kullanıcılar bile mobil cihazlarda daha büyük hedeflerden fayda görür — bu gerçek, büyük teknoloji şirketlerindeki tasarım geleneklerini yıllardır yönlendirmektedir. Apple’ın Human Interface Guidelines dokümanı minimum 44×44 puanlık dokunma hedefi önerirken, Google’ın Material Design yönergeleri aynı nedenlerle en az 48×48 yoğunluktan bağımsız piksel önermektedir.

SEO ve kullanılabilirlik açısından, Google’ın Core Web Vitals metriği olan “Interaction to Next Paint” (INP), kullanıcı etkileşimlerinin hızlı ve doğru şekilde kaydedildiği arayüzleri ödüllendirir. Yetersiz boyuttaki hedeflerin neden olduğu yanlış dokunuşlar, etkileşim başarısızlık oranlarını ve görev tamamlama süresini artırır, hemen çıkma oranlarını yükseltir — bunların tümü dolaylı olarak arama sıralamasını etkileyebilen sinyallerdir. Bu nedenle, işaretçi düzeyindeki erişilebilirlik iyileştirmelerinin, uyumluluğun ötesinde ölçülebilir ticari sonuçları vardır.

İlgili Axe-core Kuralları

WCAG 2.5.5 manuel test gerektirir. Bu gelişmiş ölçüt için tüm hedef boyutu ihlallerini güvenilir biçimde işaretleyen tam otomatik bir axe-core kuralı yoktur. Otomatik araçların burada zorlanmasının nedeni çok yönlüdür: Etkin hedef boyutu, padding, margin ve görünüm alanına, cihaz piksel oranına ve dinamik işlenmeye göre değişen pseudo-element boyutları dahil hesaplanmış CSS yerleşimine bağlıdır. Ayrıca, boşluk istisnası, bitişik hedefler arasındaki geometrik ofsetin hesaplanmasını gerektirir — bu da tam işlenmiş yerleşim ağacını ve yakınlık analizini gerektiren, otomatik DOM ayrıştırma araçlarının her durumda doğru şekilde gerçekleştiremeyeceği bir hesaplamadır. Dahası, bir öğenin “inline” veya “equivalent” istisnasına girip girmediği, otomatik kural motorlarının ötesinde anlamsal ve bağlamsal bir anlayış gerektirir.

• target-size (axe-core experimental): Axe-core, etkileşimli öğeleri WCAG 2.5.8 Düzey AA eşiği olan 24×24 CSS piksel ve boşluk ofsetlerine göre kontrol eden target-size adlı deneysel bir kural içerir. Bu kural bazı daha küçük ihlalleri ortaya çıkarabilse de, 2.5.5 tarafından gerekli olan daha katı 44×44 eşiğini zorunlu kılmaz ve padding veya pseudo-elementlerin, DOM anlık görüntüsünün yakalayamadığı şekillerde işlenmiş tıklama alanını etkilediği ihlalleri kaçırabilir. Bu kuraldan gelen sonuçları tam bir denetim değil, başlangıç noktası olarak değerlendirin.
• Manuel görsel inceleme: Hiçbir otomatik kural 2.5.5’i tam olarak kapsamadığından, test uzmanları etkileşimli hedefleri tarayıcı geliştirici araçları, CSS piksel cetvelleri veya erişilebilirlik tarayıcı uzantıları kullanarak görsel olarak incelemeli ve ölçmelidir. Buna, padding’in tıklama alanına dahil edildiğini ve boşluk istisnalarının gerçekten karşılandığını — sadece varsayılmadığını — kontrol etmek de dahildir.

Nasıl Test Edilir

1. Temel olarak otomatik bir tarama çalıştırın: Test edilen sayfada Chrome DevTools içinde axe DevTools veya Lighthouse’u açın. axe DevTools’ta, deneysel kurallar altında mevcutsa sonuçları “target-size”a göre filtreleyin. İşaretlenen öğeleri not edin, ancak bu taramanın tüm 2.5.5 ihlallerini yakalamayacağını ve 44×44 piksel yerine 2.5.8 eşiğine atıfta bulunabileceğini unutmayın. Lighthouse’un erişilebilirlik denetimini kullanarak ilgili işaretçi-hedef uyarılarını arayın.
2. Hedef boyutlarını tarayıcı DevTools ile ölçün: Chrome veya Firefox DevTools’u açın ve Öğeler (Elements) panelini kullanarak her etkileşimli öğeyi — düğmeler, bağlantılar, form girdileri, onay kutuları, radyo düğmeleri, özel kontroller ve yalnızca simge içeren kontroller — inceleyin. Hesaplanan stiller (Computed) panelinde işlenmiş genişlik ve yüksekliği kontrol edin. Padding’in blok düzeyindeki öğelerde tıklama hedefine dahil edildiğini, ancak satır içi öğelerde her zaman dahil olmayabileceğini unutmayın. Hesaplanan tıklama alanının en az 44×44 CSS piksel olduğunu doğrulayın.
3. Tarayıcının yerleşik erişilebilirlik araçlarını kullanın: Chrome DevTools’ta Rendering sekmesini açın ve “Emulate a focused page” seçeneğini etkinleştirin veya Accessibility Tree’yi kullanarak öğeleri inceleyin. Firefox için, etkileşimli öğeleri belirlemek ve sınırlayıcı kutu boyutlarını karşılaştırmak için Accessibility Inspector’ı kullanın.
4. Gerçek dokunmatik cihazlarda test edin: Fiziksel bir iOS cihazı bağlayın ve VoiceOver’ı etkinleştirerek test edin (yan düğmeye üç kez basarak etkinleştirin). Dokunarak gezin ve etkileşimli öğeler arasında gezinmek için rotor’u kullanın. Küçük hedefleri etkinleştirmeye çalışın ve bitişik öğelerin ne sıklıkla yanlışlıkla tetiklendiğini not edin. Aynı testi, TalkBack kullanarak bir Android cihazda tekrarlayın (gezinmek için sağa kaydırın, etkinleştirmek için çift dokunun). Özellikle <div> veya <span> öğelerinden oluşturulmuş özel bileşenlere dikkat edin.
5. Boşluk istisnalarını manuel olarak test edin: 44×44 pikselden küçük olup boşluk istisnasına dayanan herhangi bir hedef için, bu hedefin merkezine 44×44 piksel boyutunda hayali bir sınırlayıcı kutu çizin ve bu kutu içine başka hiçbir etkileşimli öğenin girmediğini görsel olarak doğrulayın. Sınırlayıcı kutular çizen tarayıcı uzantıları veya bindirme araçları bu konuda yardımcı olabilir.
6. Klavye ve ekran okuyucu doğrulaması: NVDA + Firefox ve JAWS + Chrome ile tüm etkileşimli öğeler arasında sekme (Tab) ile gezinerek test yapın. Klavye odağı doğrudan işaretçi hedef boyutunu test etmese de, herhangi bir kontrolün erişilebilir olup olmadığını belirlemeye yardımcı olur ve işaretçi boyutlarını karşılaştıracağınız öğe envanterini doğrular. macOS’ta VoiceOver + Safari, özel kontrollerin kendilerini doğru şekilde duyurduğunu ve işaretçi tıklamasıyla etkinleştirildiğinde yeterli etkinleştirme alanına sahip olduğunu doğrulamak için kullanılabilir.
7. Birden fazla görünüm alanı boyutunda test edin: Hedef boyutları, masaüstü ve mobil yerleşimler arasında değişebilir. Özellikle hamburger menüler, karuseller ve veri tablosu eylem sütunlarında, duyarlı tasarımların tüm kırılma noktalarında 44×44 minimumunu koruduğunu doğrulamak için 320px, 768px ve 1280px görünüm alanı genişliklerinde test yapın.

Nasıl Düzeltilir

Yetersiz boyutta yalnızca simge içeren düğme — Hatalı

<!-- A close button rendered as a small SVG icon with no padding.
     The rendered size is approximately 16x16 CSS pixels, far below the 44x44 minimum. -->
<button class='close-btn'>
  <svg width='16' height='16' aria-hidden='true'>
    <use href='#icon-close'></use>
  </svg>
  <span class='sr-only'>Close dialog</span>
</button>

<style>
.close-btn {
  background: none;
  border: none;
  padding: 0;
  cursor: pointer;
}
</style>

Yetersiz boyutta yalnızca simge içeren düğme — Doğru

<!-- Padding is added to expand the hit area to at least 44x44 CSS pixels
     while preserving the visual icon size. The button itself has explicit
     min-width and min-height to guarantee compliance across browsers. -->
<button class='close-btn'>
  <svg width='16' height='16' aria-hidden='true'>
    <use href='#icon-close'></use>
  </svg>
  <span class='sr-only'>Close dialog</span>
</button>

<style>
.close-btn {
  background: none;
  border: none;
  padding: 14px; /* 16px icon + 14px * 2 padding = 44px total hit area */
  min-width: 44px;
  min-height: 44px;
  cursor: pointer;
  display: inline-flex;
  align-items: center;
  justify-content: center;
}
</style>

div’den oluşturulmuş özel onay kutusu — Hatalı

<!-- A visually styled custom checkbox that is too small to meet the target size
     requirement. The div has no padding and renders at 20x20 pixels. -->
<div role='checkbox' aria-checked='false' tabindex='0' class='custom-check'></div>

<style>
.custom-check {
  width: 20px;
  height: 20px;
  border: 2px solid #333;
  border-radius: 3px;
  cursor: pointer;
}
</style>

div’den oluşturulmuş özel onay kutusu — Doğru

<!-- The visual box remains 20x20 pixels but is wrapped in a label element
     whose total clickable area is expanded to 44x44 via padding.
     Using a native input element is strongly preferred over role=checkbox
     because it provides built-in keyboard and pointer behavior. -->
<label class='check-wrapper'>
  <input type='checkbox' class='sr-only'>
  <span class='custom-check' aria-hidden='true'></span>
  Subscribe to newsletter
</label>

<style>
.check-wrapper {
  display: inline-flex;
  align-items: center;
  gap: 8px;
  min-height: 44px; /* entire label row is at least 44px tall */
  cursor: pointer;
  padding: 12px 0; /* vertical padding expands the hit area */
}
.custom-check {
  width: 20px;
  height: 20px;
  border: 2px solid #333;
  border-radius: 3px;
  flex-shrink: 0;
}
.sr-only {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip: rect(0,0,0,0);
  white-space: nowrap;
  border: 0;
}
</style>

Dar aralıklı araç çubuğu gezinme bağlantıları — Hatalı

<!-- Toolbar links rendered as small inline elements.
     Each link is approximately 32px wide and 24px tall,
     and they are spaced only 4px apart — failing both size and spacing exceptions. -->
<nav aria-label='Secondary navigation'>
  <a href='/help' class='nav-link'>Help</a>
  <a href='/settings' class='nav-link'>Settings</a>
  <a href='/logout' class='nav-link'>Logout</a>
</nav>

<style>
.nav-link {
  font-size: 12px;
  padding: 2px 4px;
  margin: 0 2px;
}
</style>

Dar aralıklı araç çubuğu gezinme bağlantıları — Doğru

<!-- Each link now has padding that expands its hit area to at least 44x44 px.
     The gap between links is also increased so the spacing exception would
     apply even if sizing were relaxed in future. -->
<nav aria-label='Secondary navigation'>
  <a href='/help' class='nav-link'>Help</a>
  <a href='/settings' class='nav-link'>Settings</a>
  <a href='/logout' class='nav-link'>Logout</a>
</nav>

<style>
.nav-link {
  font-size: 14px;
  display: inline-flex;
  align-items: center;
  min-height: 44px;
  padding: 0 16px; /* horizontal padding extends width well past 44px */
  margin: 0 4px;
  text-decoration: underline;
}
</style>

Yaygın Hatalar

• Görsel sınırlayıcı kutunun tıklama alanına eşit olduğunu varsaymak: Bir düğmenin içindeki simge görseline width: 44px; height: 44px vermek, düğmenin kendisini 44×44 yapmaz — doğru tıklama alanını oluşturmak için bu boyutları veya eşdeğer padding’i doğrudan <button> öğesine eklemek gerekir.
• Telafi edici minimum boyut olmadan tarayıcı stillerini sıfırlamak için padding: 0 kullanmak: CSS reset’leri genellikle düğmelerden ve girdilerden tüm padding’i kaldırır. Bir reset’ten sonra, etkinleştirme alanını geri kazandırmak için her zaman yeterli padding veya açık min-width ve min-height değerlerini yeniden uygulayın.
• Hedef yüksekliğini artırmak için yalnızca line-height’a güvenmek: line-height değerini artırmak metin aralığını etkiler, ancak her zaman bir bağlantının veya düğmenin tıklanabilir alanını genişletmez. Bunun yerine padding-top ve padding-bottom kullanın.
• Yeterli boşluk olmadan yan yana birden fazla küçük simge düğme yerleştirmek: Yalnızca 2px kenar boşluğuna sahip 24×24 boyutunda bir dizi sosyal medya paylaşım simgesi, hem boyut gereksinimini hem de boşluk istisnasını ihlal eder; çünkü her simgenin merkezine yerleştirilen 44px’lik daireler komşularıyla çakışacaktır.
• Satır içi metin istisnasını gezinme bağlantılarına yanlış uygulamak: İstisna, akıcı bir cümle veya paragraf içindeki bağlantılar için geçerlidir. Gezinme menüleri, araç çubukları ve bağlantı listeleri satır içi metin değildir ve display: inline kullansalar bile bu istisnaya girmezler.
• <span> üzerinde role='button' kullanarak özel kontroller oluşturmak ve span’i boyutlandırmayı unutmak: Ekran okuyucular span’i bir düğme olarak duyuracaktır, ancak varsayılan işlenmiş boyutu yalnızca metin içeriği tarafından belirlenecek ve bu genellikle 44×44 pikselin çok altında olacaktır. Her zaman display: inline-flex, min-width, min-height ve padding ekleyin.
• Gerçek dokunmatik cihazlarda, gerçek görünüm alanı boyutunda test etmemek: Piksel ölçümlerini yalnızca masaüstü DevTools’ta yapmak yeterli değildir. CSS piksel yoğunluğu ve işletim sistemi düzeyindeki dokunma hedefi tıklama alanı davranışı, simüle edilen ve fiziksel cihaz ortamları arasında farklılık gösterebilir.
• Dinamik olarak işlenen kontrolleri gözden kaçırmak: Araç ipuçları (tooltip), tarih seçici gün hücreleri, otomatik tamamlama öneri öğeleri ve modal kapatma düğmeleri, genellikle JavaScript kütüphaneleri tarafından sabitlenmiş küçük boyutlarla eklenir. Üçüncü taraf bileşen çıktısını denetleyin ve gerekirse stillerini geçersiz kılın.
• Boşluk istisnasını ölçmeden iddia etmek: Boşluk istisnası geometrik ve kesindir. Kontrollerin yeterince uzak göründüğünü varsaymak yeterli değildir — her yetersiz boyuttaki hedef için 44px daire testi uygulanmalı ve hiçbir çakışma olmadığından emin olunmalıdır.
• Duyarlı kırılma noktası değişikliklerinden sonra doğrulamayı unutmak: Masaüstünde 44×44 olan bir düğme, yüzde genişlikler veya flexbox küçülmesi nedeniyle 375px mobil görünüm alanında 30×30’a düşebilir. Hedef boyutlarını her önemli kırılma noktasında yeniden test edin.

Türkiye’nin Erişilebilirlik Mevzuatıyla İlişkisi

Türkiye’nin 2025/10 sayılı Cumhurbaşkanlığı Genelgesi, 21 Haziran 2025 tarihli ve 32933 sayılı Resmî Gazete’de yayımlanarak WCAG 2.2 standardına dayalı zorunlu web ve mobil erişilebilirlik gereksinimlerini belirlemiştir. Genelge, Türkiye’de faaliyet gösteren belirli bir kurum ve kuruluş grubuna uygulanmakta ve belirli WCAG düzeylerine uyum için yasal yükümlülükler getirmektedir.

Genelge kapsamındaki kuruluş türleri şunları içerir: merkezi ve yerel düzeydeki kamu kurum ve kuruluşları; Bankacılık Düzenleme ve Denetleme Kurumu (BDDK) tarafından düzenlenen bankalar ve finansal kuruluşlar; hem kamu hem özel hastaneler ve sağlık hizmeti sunucuları; 200.000 veya daha fazla abonesi olan telekomünikasyon işletmecileri; belirli ciro veya işlem hacmi eşiklerini aşan e-ticaret platformları; çevrimiçi rezervasyon hizmeti sunan seyahat acenteleri; dijital biletleme veya rezervasyon sunan özel ulaşım şirketleri ve Millî Eğitim Bakanlığı (MoNE) tarafından yetkilendirilmiş özel okullar ve eğitim kurumları.

WCAG 2.5.5 Hedef Boyutu (Gelişmiş), Düzey AAA ölçütüdür ve ağırlıklı olarak Düzey A ve AA uyumuna odaklanan genelgeyle belirlenen asgari zorunlu gereksinimler arasında yer almaz. Ancak genelge, özellikle kamuya, sağlık hastalarına ve öğrencilere hizmet veren kapsamdaki kuruluşları, mümkün olduğunda AAA uyumunu hedeflemeye açıkça teşvik eder; zira bu düzey, en iyi erişilebilirlik uygulamasını temsil eder.

Türkiye’deki kuruluşlar için WCAG 2.5.5’in uygulanması, çeşitli bağlamlarda özel stratejik değer taşır. Yaşlı vatandaşlara hizmet veren kamu portalları, kronik rahatsızlığı olan hastalar tarafından kullanılan randevu sistemleri ve motor bozukluğu olan kişilerce erişilen bankacılık uygulamaları, 44×44 piksel hedef boyutlarından önemli ölçüde fayda sağlar. Türkiye hızla yaşlanan bir nüfusa sahiptir ve Türkiye İstatistik Kurumu (TÜİK), 65 yaş ve üzeri vatandaşların 2040 yılına kadar nüfusun %16’sından fazlasını oluşturacağını öngörmektedir — bu da işaretçi hedef boyutunun kritik bir kullanılabilirlik faktörü olduğu bir demografidir.

AAA düzeyi yasal olarak zorunlu olmasa bile, WCAG 2.5.5’i gönüllü olarak karşılayan kuruluşlar, dava riskini azaltan, erişilebilirlik dokümantasyonu gerektiren kamu ihale süreçlerinde tedarik uygunluğunu güçlendiren ve e-ticaret ile fintech gibi rekabetçi pazarlarda kullanıcı memnuniyeti metriklerini iyileştiren bir taahhüt sergiler. Accsible’ın SDK’sı, kuruluşların bu ölçütü karşılamasına veya yaklaşmasına yardımcı olabilecek yapılandırılabilir dokunma-hedefi iyileştirme özellikleri sunar ve bu tür çabaların dokümantasyonu, kurumsal tedarik süreçlerinde talep edilen Erişilebilirlik Uyum Raporu (ACR) veya VPAT sunumlarının bir parçasını oluşturabilir.