WCAG 3.3.7: Gereksiz Girdi

Bu Kuralın Anlamı

WCAG 3.3.7 Redundant Entry, WCAG 2.2 ile tanıtılan Seviye A başarı ölçütüdür. Şöyle der: "Kullanıcı tarafından daha önce girilmiş veya kullanıcıya sağlanmış ve aynı süreçte yeniden girilmesi gereken bilgiler, ya otomatik olarak doldurulur ya da kullanıcının seçebilmesi için sunulur." Basitçe ifade etmek gerekirse, bir kullanıcı bir oturum sırasında e-posta adresini, teslimat adresini, doğum tarihini veya herhangi başka bir bilgiyi zaten yazdıysa, arayüzünüz aynı süreç veya akış içinde bu bilgiyi tekrar yazmasını istememelidir.

Bu ölçüt, bir adımda toplanan verilerin daha sonraki bir adımda tekrar gerekebileceği her türlü çok adımlı form, ödeme süreci, kayıt sihirbazı, randevu alma akışı veya benzeri diziler için geniş biçimde geçerlidir. Etkilenen davranışlar, metin girişleri, açılır menüler, onay kutuları, radyo düğmeleri ve kullanıcıdan veri toplayan diğer tüm form kontrollerini içerir. Aynı bilginin yeniden istenmesi gerektiğinde, bu bilgi ya daha önce sağlanan değer kullanılarak otomatik olarak doldurulmalı ya da kullanıcıya yeniden girmek yerine onaylayabileceği seçilebilir bir seçenek olarak sunulmalıdır.

Bu ölçüt için bir başarılı örnek şuna benzer: Kullanıcının önceki ekranda girdiği teslimat adresiyle önceden doldurulmuş bir fatura adresi formu veya kullanıcının daha önce girdiği e-posta adresini salt okunur bir alanda gösteren bir onay adımı. Başka bir başarılı örüntü, "Fatura adresim teslimat adresimle aynıdır" etiketli ve işaretlendiğinde değerleri otomatik olarak kopyalayan bir onay kutusudur. Bir başarısızlık ise şuna benzer: 1. adımda e-posta adresi isteyen ve 3. adımda ikinci alanı önceden doldurmadan tekrar e-posta isteyen çok adımlı bir kayıt akışı veya sigorta talep formunda, talep sahibinin adını ve poliçe numarasını otomatik doldurma olmaksızın birden fazla ayrı ekranda istemek.

WCAG 3.3.7 iki resmi istisap tanımlar. İlk istisna, bilginin yeniden girilmesinin süreç için zorunlu olduğu durumlarda geçerlidir — örneğin, "Yeni şifrenizi doğrulayın" alanı, yazım hatalarına karşı bir güvenlik önlemi olarak kullanıcıların aynı şifreyi bilerek iki kez yazmasını ister ve bu, zorunlu bir güvenlik kontrolü olarak kabul edilir. İkinci istisna, daha önce girilen bilginin artık geçerli olmadığı durumlarda geçerlidir — örneğin, bir oturumun süresi dolduysa veya bir ürün stoktan çıktıysa ve kullanıcının süreci güncel verilerle yeniden başlatması gerekiyorsa. Bu istisnalar dışında, gereksiz tekrar giriş bir uygunluk ihlalidir.

Neden Önemli

Gereksiz tekrar giriş, yazmayı yavaş, acı verici, hataya açık veya bilişsel olarak zorlayıcı hale getiren durumları olan kullanıcıları orantısız biçimde zorlar. Kimlerin etkilendiğini anlamak, geliştiricilerin ve tasarımcıların bu ölçütün yalnızca bir konfor özelliği değil, birçok kişi için gerçek bir engel olduğunu kavramasına yardımcı olur.

Motor bozuklukları olan kullanıcılar, örneğin titremeleri, omurilik yaralanmaları veya ALS ya da multipl skleroz gibi durumları olanlar, metin girmek için anahtar erişimi, ağız çubukları, göz takibi yazılımları veya sesle kontrol gibi araçlara güvenebilir. Bu kullanıcılar için kısa bir adresi yazmak bile birkaç dakika ve ciddi fiziksel çaba gerektirebilir. Bu girdiyi tekrar etmelerinin istenmesi yalnızca can sıkıcı değildir — fiziksel acıya neden olabilir veya görevi tek bir oturumda pratikte imkansız hale getirebilir.

Bilişsel engelleri olan kullanıcılar, disleksi, dikkat eksikliği bozuklukları, travmatik beyin hasarı ve demansla ilişkili durumlar dahil, üç adım önce ne girdiklerini hatırlamakta zorlanabilirler. Bilgiyi hafızadan veya bir kağıt belgeden birden fazla kez doğru şekilde aktarmak, hata oranlarını ve süreci yarıda bırakma olasılığını büyük ölçüde artırır. Dünya Sağlık Örgütü’ne göre, dünya genelinde 1 milyardan fazla insan bir tür engelle yaşamaktadır ve bilişsel engeller, erişilebilirlik planlamasında en büyük ve en az hizmet alan kesimlerden birini temsil eder.

Üst uzuv farklılıkları olan kullanıcılar, doğuştan veya sonradan uzuv farklılıkları olanlar dahil, çok daha yavaş yazar ve alternatif giriş cihazları kullanabilirler. Gerekli her ek tuş vuruşu, bu kullanıcılar üzerindeki yükü katlar.

Gerçek bir senaryoyu düşünün: Romatoid artriti olan bir kullanıcı, bir hastanenin çevrimiçi portalı üzerinden tıbbi randevu alıyor. 1. ekranda T.C. kimlik numarasını, adını, doğum tarihini ve iletişim telefon numarasını giriyor. 3. ekranda portal, hasta kaydını doğrulamak için adını ve doğum tarihini tekrar istiyor. Bu kullanıcı, yalnızca iki ekran önce verdiği bilgileri zahmetle yeniden yazmak zorunda kalıyor, kayıtların eşleşmemesine yol açabilecek yazım hataları riski taşıyor ve gereksiz fiziksel zorlanma yaşıyor. Bu alanların basit bir ön doldurulması veya otomatik doldurulması, engeli tamamen ortadan kaldırırdı.

Erişilebilirliğin ötesinde, gereksiz tekrar girişin ortadan kaldırılması, dönüşüm oranlarını artırır, form terk edilmesini azaltır ve veri girişi hatalarından kaynaklanan destek taleplerini düşürür — kapsayıcı tasarımla birlikte ölçülebilir iş değeri sağlar.

İlgili Axe-core Kuralları

WCAG 3.3.7, manuel test gerektiren bir ölçüttür. Şu anda gereksiz tekrar giriş ihlallerini güvenilir biçimde tespit edebilen otomatik bir axe-core kuralı yoktur; çünkü otomatik araçlar, dinamik bir süreçte birden fazla adım veya sayfa boyunca girilen veriler arasındaki anlamsal ilişkiyi anlayamaz. Önceki adımda hangi bilgilerin toplandığı, mevcut adımda hangi bilgilerin istendiği veya bu iki bilginin mantıksal olarak özdeş olup olmadığı konusunda farkındalıkları yoktur. Yalnızca tüm akışı baştan sona gezen bir insan testçi, aynı verinin ön doldurma olmadan iki kez istenip istenmediğini gözlemleyip değerlendirebilir.

• Manuel test gerekli (WCAG 2.2 yeni): axe-core ve diğer otomatik erişilebilirlik tarayıcıları, tek seferde yalnızca bir sayfa durumunun DOM’unu analiz eder. Birden fazla sayfa yüklemesi veya form adımı boyunca kullanıcı tarafından girilen değerleri takip edemez, adımlar arasında alan etiketlerini karşılaştıramaz ve anlamsal tekrarları tespit edemez, ayrıca bir ön doldurma mekanizmasının doğru çalışıp çalışmadığını değerlendiremez. Testçilerin çok adımlı süreçleri manuel olarak baştan sona geçmesi, her adımda girdikleri verileri kaydetmesi ve sonraki her adımda daha önce sağlanan verilerin otomatik doldurulup doldurulmadığını veya seçilebilir olup olmadığını doğrulaması gerekir. 3.3.7 ihlallerini otomatik olarak tespit ettiğini iddia eden herhangi bir araç, son derece yüksek bir yanlış negatif oranına sahip olacaktır ve tek test yöntemi olarak güvenilmemelidir.

Nasıl Test Edilir

1. Başlangıç noktası olarak otomatik tarama: Çok adımlı sürecinizin her bir adımında axe DevTools, Lighthouse veya Accsible denetleyicisini çalıştırın. Bu araçlar 3.3.7 ihlallerini doğrudan işaretlemese de, genellikle birlikte görülen eksik autocomplete öznitelikleri, etiketlenmemiş form alanları ve diğer 3.3.x ölçütü hataları gibi ilgili sorunları ortaya çıkaracaktır. Her adımda bulduğunuz tüm form alanlarını belgeleyin.
2. Adımlar arasındaki veri gereksinimlerini eşleyin: Manuel testten önce, süreçteki her adımı ve topladığı tüm veri alanlarını listeleyen basit bir tablo veya hesap tablosu oluşturun. Ardından, birden fazla adımda görünen her alan etiketini veya veri türünü belirleyin. Bu eşleme çalışması, tarayıcıyı açmadan önce bile olası ihlalleri ortaya çıkarır.
3. Manuel geçiş — masaüstü: Standart fare ve klavye kullanarak, tüm çok adımlı süreci (örneğin ödeme, kayıt, talep gönderimi) tamamlayın. Her alana gerçekçi değerler girin. Haritanızda yinelenen alan olarak görünen bir adıma geldiğinizde, alanın önceki girişinizle önceden doldurulup doldurulmadığını veya önceki girişinizi sunan seçilebilir bir seçenek olup olmadığını kontrol edin. Hiçbiri yoksa, bir başarısızlık kaydedin. Bu testi bir ekran okuyucu (Firefox ile NVDA, Chrome ile JAWS, Safari ile VoiceOver) ile tekrarlayarak, önceden doldurulmuş değerlerin düzgün şekilde duyurulduğunu ve daha önce girilen değerler için seçim kontrollerinin klavye ile erişilebilir olduğunu doğrulayın.
4. Manuel geçiş — mobil: Aynı akışı iOS’ta (VoiceOver + Safari) ve Android’de (TalkBack + Chrome) tamamlayın. Uygulamanın, geliştirici autocomplete’in yardımcı olmasını amaçlamış olsa bile, yerel otomatik tamamlama veya otomatik doldurma özelliklerini bastırıp bastırmadığına dikkat edin; bu, istemeden gereksiz tekrar giriş engelleri oluşturabilir.
5. İstisnaları test edin: Bilerek tekrar giriş isteyen alanları (örneğin şifre doğrulama, e-postayı yeniden gir) belirleyin. Bunların WCAG istisnası kapsamında zorunlu güvenlik veya doğrulama kontrolleri olarak nitelendiğini ve yalnızca kaldırılması veya önceden doldurulması gereken gereksiz alanlar olmadığını doğrulayın.
6. Autocomplete devre dışıyken test edin: Bazı kullanıcılar gizlilik nedenleriyle tarayıcı otomatik tamamlamayı devre dışı bırakır. Uygulamanın kendi ön doldurma mekanizmasının (sunucu taraflı veya JavaScript tabanlı) tarayıcı otomatik tamamlaması kapalıyken de doğru çalıştığını test edin; böylece ölçütün tarayıcı davranışından bağımsız olarak karşılandığından emin olun.

Nasıl Düzeltilir

Çok adımlı ödeme — aynı adres iki ekranda isteniyor — Hatalı

<!-- Step 1: Shipping Address -->
<form id='shipping-form'>
  <label for='ship-name'>Full Name</label>
  <input type='text' id='ship-name' name='shipping_name'>

  <label for='ship-street'>Street Address</label>
  <input type='text' id='ship-street' name='shipping_street'>

  <label for='ship-city'>City</label>
  <input type='text' id='ship-city' name='shipping_city'>
</form>

<!-- Step 2: Billing Address — user must type everything again -->
<form id='billing-form'>
  <label for='bill-name'>Full Name</label>
  <input type='text' id='bill-name' name='billing_name'>

  <label for='bill-street'>Street Address</label>
  <input type='text' id='bill-street' name='billing_street'>

  <label for='bill-city'>City</label>
  <input type='text' id='bill-city' name='billing_city'>
</form>

Çok adımlı ödeme — aynı adres iki ekranda isteniyor — Doğru

<!-- Step 2: Billing Address — pre-fill option provided -->
<form id='billing-form'>
  <!-- Checkbox allows user to confirm same address rather than re-type it -->
  <input type='checkbox' id='same-as-shipping' name='same_as_shipping'>
  <label for='same-as-shipping'>My billing address is the same as my shipping address</label>

  <div id='billing-fields'>
    <!-- Fields are pre-populated server-side with shipping values;
         JavaScript can also copy values when checkbox is unchecked -->
    <label for='bill-name'>Full Name</label>
    <input type='text' id='bill-name' name='billing_name' value='Jane Doe' autocomplete='billing name'>

    <label for='bill-street'>Street Address</label>
    <input type='text' id='bill-street' name='billing_street' value='123 Elm Street' autocomplete='billing street-address'>

    <label for='bill-city'>City</label>
    <input type='text' id='bill-city' name='billing_city' value='Ankara' autocomplete='billing address-level2'>
  </div>
</form>

Gerekçe olmadan e-postayı iki kez isteyen kayıt sihirbazı — Hatalı

<!-- Step 1 collected email. Step 3 asks again with no pre-fill. -->
<fieldset>
  <legend>Confirm Your Details</legend>
  <label for='confirm-email'>Email Address</label>
  <input type='email' id='confirm-email' name='confirm_email'>
  <!-- No value pre-populated; user must type the same email entered on step 1 -->
</fieldset>

Kayıt sihirbazı — e-posta oturum verisinden önceden doldurulmuş — Doğru

<!-- Server renders the previously collected email into the value attribute -->
<fieldset>
  <legend>Confirm Your Details</legend>
  <label for='confirm-email'>Email Address</label>
  <!-- value is injected from server-side session; user can correct if needed -->
  <input type='email' id='confirm-email' name='confirm_email'
         value='[email protected]' autocomplete='email'>
</fieldset>

Randevu alma — özet adımında hasta bilgileri tekrar isteniyor — Hatalı

<!-- Summary step re-asks for date of birth already entered in patient info step -->
<label for='dob-confirm'>Date of Birth</label>
<input type='date' id='dob-confirm' name='dob_confirm'>
<!-- Empty field requires user to re-enter DOB from memory or paper -->

Randevu alma — doğum tarihi salt okunur onay olarak gösteriliyor — Doğru

<!-- Previously entered DOB displayed in a read-only field for review;
     a hidden input carries the value for form submission -->
<label for='dob-confirm'>Date of Birth (from your patient record)</label>
<input type='date' id='dob-confirm' name='dob_confirm'
       value='1985-04-12' readonly aria-describedby='dob-hint'>
<span id='dob-hint'>This value was entered earlier. Contact support if it is incorrect.</span>

Yaygın Hatalar

• Çok adımlı formları, ortak oturum durumu olmayan bağımsız sayfalar olarak oluşturmak, böylece önceki adımlarda girilen değerleri ileri taşımaya yönelik hiçbir mekanizma olmaması — 3.3.7 başarısızlıklarına yol açan en temel mimari hata.
• "Teslimat adresiyle aynı" onay kutusu sunmak ama işaretlendiğinde fatura alanlarını gerçekten doldurmamak, böylece kullanıcılar eşleşmesi gerektiğini belirtmelerine rağmen adres ayrıntılarını hâlâ elle yazmak zorunda kalır.
• Alanları sayfa yüklenirken önceden doldurmak ama ardından doğrulama hatasında temizlemek, böylece daha sonraki bir adımda hata yapan bir kullanıcı, düzeltmek için geri döndüğünde daha önce sağladığı tüm verileri yeniden girmek zorunda kalır.
• Oturum verilerini güvensiz biçimde depolamak ve güvenlik sorununu düzeltmek yerine oturum depolamayı devre dışı bırakmayı seçmek, bu da teknik olarak 3.3.7 başarısızlığı oluşturan bozuk bir ön doldurma deneyimiyle sonuçlanır.
• Şifre doğrulama istisnasını, kullanıcılara e-posta adreslerini yeniden yazdırmak için gerekçe olarak kullanmak, oysa e-posta doğrulaması zorunlu bir güvenlik kontrolü değildir ve WCAG istisnası kapsamına girmez.
• Sunucu taraflı oluşturulan formlarda, taşınan değerleri gizli girdiler aracılığıyla iletmemek, böylece kullanıcı tarayıcı geçmişi düğmelerini kullanarak adımlar arasında ileri geri giderken önceden doldurulmuş değerlerin kaybolmasına neden olmak.
• Bu ölçütü karşılamak için yalnızca tarayıcı otomatik doldurmaya güvenmek, uygulama düzeyinde ön doldurma uygulamamak — gizlilik nedenleriyle otomatik doldurmayı devre dışı bırakan kullanıcıların süreçte uygun bir yolu kalmaz.
• Bir alanı önceden doldurmak ama readonly yerine disabled olarak ayarlamak, bu da çoğu tarayıcıda değerin form gönderimine dahil edilmemesine, sürecin bozulmasına ve potansiyel olarak tekrar giriş zorunluluğuna yol açar.
• Dragon NaturallySpeaking gibi sesle giriş yazılımlarını kullanan kullanıcılarla uçtan uca akışı test etmemek, burada gereksiz alanlar, aynı sözlü dikte komutunun birden fazla kez tekrarlanmasını gerektirebilir; bu, geliştirici testlerinde gözden kaçması kolay olan önemli bir yüktür.
• Bu ölçütü yalnızca adres alanlarına uygulanır gibi görmek, oysa aynı ölçüt, süreç içinde birden fazla kez istenen adlar, telefon numaraları, T.C. kimlik numaraları, poliçe numaraları, tarihler ve diğer tüm kullanıcı tarafından sağlanan veriler için de geçerlidir.

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

21 Haziran 2025 tarihli ve 32933 sayılı Resmî Gazete’de yayımlanan Türkiye Cumhurbaşkanlığı Genelgesi 2025/10, Türkiye’de faaliyet gösteren çok geniş bir kamu ve özel sektör kuruluşu için web erişilebilirliği uygunluğunu zorunlu kılmaktadır. WCAG 3.3.7 Redundant Entry, WCAG 2.2 kapsamında Seviye A ölçütüdür ve bu genelgeye göre Seviye A uygunluğu zorunlu asgari düzeydir. Bu, kapsamdaki herhangi bir kuruluşun işlettiği web sitesi, web uygulaması veya dijital hizmetin, kullanıcıların aynı süreç içinde daha önce sağladıkları bilgileri yeniden girmesini — istisnasız — talep etmemesi gerektiği, aksi halde uyumsuzluk riski taşıdığı anlamına gelir.

Genelge, kademeli bir uygulama takvimi belirler: kamu kurumları genelgenin yayımlanmasından itibaren bir yıl içinde uygunluk sağlamak zorundayken, kapsamdaki özel sektör kuruluşlarının uyum için iki yılı vardır.

Genelge kapsamındaki kuruluş türleri oldukça geniştir ve e-ticaret platformları ve pazar yerleri, tüm kamu kurumları ve devlet daireleri, bankalar ve finansal hizmet sağlayıcıları, hastaneler ve sağlık portalları (hem kamu hem özel), 200.000 veya daha fazla abonesi olan telekomünikasyon şirketleri, lisanslı seyahat acenteleri, özel ulaşım şirketleri ve Millî Eğitim Bakanlığı (MoNE) tarafından yetkilendirilmiş özel okulları içerir. Bu kuruluşların tümü için, e-ticaret sitelerindeki ödeme akışları, hastane portallarındaki hasta kayıtları, bankacılık platformlarındaki hesap açma süreçleri, okul web sitelerindeki kayıt formları gibi çok adımlı dijital süreçler, gereksiz tekrar girişin herhangi bir örneğini ortadan kaldırmak üzere denetlenmeli ve düzeltilmelidir.

Uygulamada, bu düzenleme WCAG 3.3.7 uygunluğunu, Türkiye’nin dijital ekonomisindeki tedarik, ürün ve hukuk ekiplerinin doğrudan sorumluluk alanına yerleştirir. Örneğin, çok adımlı bir ödeme sürecinde bir ekranda teslimat adresi, sonraki ekranda ise ön doldurma veya kopyalama seçeneği sunmadan fatura adresi isteyen bir Türk e-ticaret platformu, hem WCAG 2.2 Seviye A’ya hem de Cumhurbaşkanlığı Genelgesi’ne açıkça aykırıdır. Benzer şekilde, bir devlet hastanesinin randevu alma portalının, hastalardan kimlik numaralarını veya doğum tarihlerini birden fazla ekranda yeniden girmelerini istemesi de uyumsuzdur. Genelge kapsamındaki kuruluşlar, uygunluk yol haritalarının bir parçası olarak tüm çok adımlı süreçlerin uçtan uca denetimini önceliklendirmeli ve gereksiz tekrar girişin ortadan kaldırılmasını isteğe bağlı bir iyileştirme değil, zorunlu bir mühendislik görevi olarak ele almalıdır.