Bir mobil web sitesi erişilebilirlik geliştirme firması değerlendirilirken yalnızca otomatik tarama raporuna veya genel bir uyumluluk beyanına bakmak yeterli değildir. Asıl değerlendirme; gerçek kullanıcı görevlerinin nasıl test edildiğini, bulunan sorunların tasarım ve kod düzeltmelerine nasıl dönüştürüldüğünü ve teslimden önce hangi kabul kontrollerinin yapıldığını kapsamalıdır. Menü açma, içerik bulma, ürün ya da hizmet seçme, form tamamlama ve hata mesajını anlama gibi kritik mobil akışlar bu incelemenin merkezinde yer alır. Böyle bir yaklaşım, farklı firmaların tekliflerini soyut vaatler yerine kapsam, sorumluluk, test yöntemi ve doğrulanabilir teslim çıktıları üzerinden karşılaştırmayı kolaylaştırır.

01

Erişilebilirlik geliştirme firmasında ilk olarak ne aranmalı?

İlk olarak firmanın erişilebilirliği yalnızca bir denetim işi olarak mı, yoksa denetim, düzeltme ve doğrulama döngüsü olarak mı ele aldığı anlaşılmalıdır. İyi tanımlanmış bir çalışma, sorunları listelemekle kalmaz; hangi kullanıcı görevlerinin etkilendiğini, düzeltmenin hangi ekip tarafından yapılacağını ve sonucun nasıl yeniden test edileceğini de açıklar.

Rapor yerine uygulanabilir geliştirme sürecini inceleyin

Firma görüşmesinde örnek teslim yapısı istenebilir. Bulguların önem derecesi, ilgili ekran veya bileşen, önerilen çözüm, sorumlu ekip ve yeniden test durumu birlikte izlenebiliyorsa proje daha yönetilebilir hale gelir. Bu noktada web sitesi firmalarının erişilebilirlik testlerinin nasıl sorgulanacağı hakkında kullanılan kriterler de sağlayıcının test yaklaşımını karşılaştırmak için yararlı bir çerçeve sunar.

  • Manuel ve otomatik testlerin kapsamını ayrı ayrı sorun.
  • Düzeltme geliştirmesinin teklif içinde olup olmadığını netleştirin.
  • Kritik kullanıcı görevlerinin nasıl seçildiğini öğrenin.
  • Yeniden test ve kabul sürecinin teslimata dahil olmasını değerlendirin.
  • Bulguların tasarım ve yazılım ekiplerine nasıl aktarıldığını inceleyin.
Web'in gücü evrenselliğindedir. Engelden bağımsız olarak herkesin erişimi bunun temel bir yönüdür. - Tim Berners-Lee
02

Firma manuel mobil kullanım testlerini nasıl yapmalıdır?

Manuel test, gerçek bir kullanıcının mobil sitede tamamlaması beklenen görevların farklı etkileşim yöntemleriyle yürütülmesini kapsamalıdır. Otomatik araçlar kod düzeyindeki bazı sorunları yakalayabilir; ancak açılır menünün kullanılabilirliği, odak sırasının anlaşılabilirliği veya bir hata mesajının görev sırasında fark edilmesi gibi deneyimler doğrudan kullanım senaryolarıyla değerlendirilmelidir.

Test senaryolarını iş açısından kritik görevlerle eşleştirin

Sağlayıcıdan yalnızca kaç sayfa test edeceğini değil, hangi görevleri hangi cihaz ve etkileşim koşullarında yürüteceğini açıklaması istenmelidir. Örneğin ana navigasyondan belirli bir hizmete ulaşma, mobil formu tamamlama veya doğrulama hatasından sonra doğru alana dönme ayrı senaryolar olabilir. Mevcut sitenin responsive davranışını daha geniş açıdan değerlendirmek için mobil uyumluluk analizi yaklaşımı erişilebilirlik testleriyle birlikte ele alınabilir.

  • Dokunmatik kullanımda hedef alanların ve kontrollerin davranışını test edin.
  • Klavye veya eşdeğer giriş yöntemiyle odak sırasını kontrol edin.
  • Ekran okuyucuyla başlık, bağlantı ve kontrol anlamlarını inceleyin.
  • Yatay ve dikey ekran kullanımında kritik görevleri tekrar edin.
  • Yakınlaştırma ve farklı görüntüleme koşullarında içerik kaybını gözlemleyin.
03

Denetimde bulunan kod sorunları teklife dahil edilmeli mi?

Denetimde bulunan kod sorunlarının teklife dahil olup olmadığı açıkça yazılmalıdır; çünkü denetim ile erişilebilirlik geliştirme hizmeti aynı teslim değildir. Bir firma yalnızca sorun listesi sunabilir, başka bir firma ise arayüz ve ön yüz kodunda gerekli düzeltmeleri uygulayıp yeniden test edebilir. Tekliflerin sağlıklı karşılaştırılması için bu iki kapsam birbirinden ayrılmalıdır.

Bulgu ile düzeltme arasındaki sorumluluğu tanımlayın

Teklifte her bulgunun nasıl ele alınacağına dair bir iş modeli bulunması yararlıdır. Bazı sorunlar semantik HTML veya etkileşim koduyla, bazıları tasarım sistemiyle, bazıları ise içerik yönetimiyle ilişkili olabilir. erişilebilirlik çalışması için teklif kapsamının tanımlanması, denetim ve uygulama kalemlerini aynı satın alma görüşmesinde netleştirmek açısından doğrudan destekleyici bir adımdır.

  • Denetim raporunun ayrı bir teslim olup olmadığını belirleyin.
  • HTML, CSS ve JavaScript düzeltmelerinin kapsamını yazılı hale getirin.
  • Tasarım değişikliği gerektiren bulgular için sorumluyu tanımlayın.
  • İçerik kaynaklı sorunların kim tarafından giderileceğini kararlaştırın.
  • Yeniden test edilecek bulguların nasıl işaretleneceğini belirleyin.
04

Kritik mobil form ve menü akışları nasıl önceliklenir?

Kritik mobil akışlar, işletme ve kullanıcı açısından görevin tamamlanamaması halinde en yüksek etkiyi oluşturan adımlardan başlanarak önceliklendirilmelidir. Her sayfayı eşit ağırlıkta değerlendirmek yerine ziyaretçinin temel amacına ulaşmasını sağlayan navigasyon, arama, form, üyelik, talep veya satın alma adımları önce incelenmelidir.

Sayfa listesinden önce kullanıcı görevlerini çıkarın

Önceliklendirme çalışması URL envanterinden daha fazlasını gerektirir. Aynı form bile giriş alanları, doğrulama, hata bildirimi, onay ve geri dönüş adımlarından oluşan bir görev zinciridir. Mobil form erişilebilirliği açısından alan etiketleri kadar hatanın nerede ve nasıl bildirildiği de önem taşır. Menüde ise açma, alt seviyeye geçme, odağı koruma ve menüden çıkma davranışları birlikte değerlendirilmelidir.

  • Gelir veya talep oluşturan temel dönüşüm akışlarını belirleyin.
  • Sık kullanılan navigasyon ve arama görevlerini öne alın.
  • Form gönderimini engelleyen sorunları yüksek öncelikte değerlendirin.
  • Tekrarlanan ortak bileşenlerdeki sorunları merkezi olarak ele alın.
  • Düşük trafikli ancak kritik hizmet görevlerini ayrıca işaretleyin.
05

Ekran okuyucu ve klavye testinde neler doğrulanmalıdır?

Ekran okuyucu ve klavye testinde yalnızca teknik olarak bir öğeye erişilebilmesi değil, kullanıcının o öğenin anlamını ve mevcut durumunu anlayarak göreve devam edebilmesi doğrulanmalıdır. Kontrollerin adı, rolü, durumu, odak sırası ve geri bildirimleri birlikte incelendiğinde test gerçek kullanım davranışına daha yakın hale gelir.

Kontrol listesini kullanıcı göreviyle birlikte yürütün

Ekran okuyucu ile web sitesi testi, başlık yapısından form etiketlerine kadar birçok semantik ayrıntıyı ortaya çıkarabilir. Klavye ile mobil web kullanımı ise harici klavye, anahtar cihazlar veya benzer giriş yöntemleri açısından etkileşim engellerini görünür kılabilir. Firma, kullandığı test ortamını ve hangi senaryoda hangi sonucu beklediğini teslim raporunda anlaşılır biçimde belgelemelidir.

  • Bağlantı ve düğmelerin erişilebilir adlarını kontrol edin.
  • Odak göstergesinin görünür ve sırasının mantıklı olmasını doğrulayın.
  • Açılır menü ve modal gibi bileşenlerde odak yönetimini test edin.
  • Form hata mesajlarının alanlarla ilişkilendirildiğini inceleyin.
  • Durum değişikliklerinin yardımcı teknolojilere aktarılmasını kontrol edin.
06

Düzeltmeler teslimde hangi testlerle doğrulanmalıdır?

Düzeltmeler teslim edilirken başlangıçta başarısız olan senaryolar aynı koşullarda yeniden çalıştırılmalı ve sonuçlar izlenebilir biçimde kaydedilmelidir. Sadece kod değişikliğinin tamamlandığını belirtmek yeterli değildir; sorunun kullanıcı görevi üzerindeki etkisinin ortadan kalktığı ve düzeltmenin başka bir akışı bozmadığı da kontrol edilmelidir.

Kabul kriterlerini geliştirme başlamadan tanımlayın

Her bulgu için beklenen davranışın önceden yazılması, teslim tartışmalarını azaltır. WCAG odaklı geliştirme hizmeti sunan ekip, ilgili kriterleri teknik referans olarak kullanabilir; ancak kabul testinin kullanıcı görevini de kapsaması gerekir. Örneğin form hatasının programatik olarak ilişkilendirilmesi teknik bir kontrolken, kullanıcının hatayı anlayıp ilgili alana dönerek işlemi tamamlayabilmesi görev düzeyindeki doğrulamadır.

  • Başlangıç bulgularını yeniden test ederek durumlarını kaydedin.
  • Kritik görevlar için uçtan uca kabul senaryoları çalıştırın.
  • Düzeltmelerin komşu bileşenlerde regresyon oluşturmadığını kontrol edin.
  • Test cihazı ve yardımcı teknoloji bilgisini rapora ekleyin.
  • Açık kalan bulguları gerekçesi ve sonraki adımıyla belgeleyin.
07

Tasarım ve yazılım ekiplerinin sorumluluğu nasıl ayrılır?

Tasarım ve yazılım ekiplerinin sorumlulukları, bulgunun kaynağına ve çözümün uygulanacağı katmana göre ayrılmalıdır. Renk kontrastı, görsel hiyerarşi veya hata sunumu tasarım kararları gerektirebilirken; semantik yapı, klavye davranışı, odak yönetimi ve dinamik durum bildirimleri çoğunlukla geliştirme uygulamasını da gerektirir. Bazı sorunlarda iki ekibin ortak çalışması zorunludur.

Tek sahip yerine ortak kabul mekanizması kurun

Erişilebilir web arayüzü teklifinde yalnızca “tasarım ekibi düzeltir” veya “yazılım ekibi uygular” gibi geniş ifadeler yerine görev bazlı sorumluluk matrisi tercih edilmelidir. Tasarımcı beklenen etkileşim ve görsel durumu tanımlar, geliştirici bunu teknik olarak uygular, test sorumlusu ise kabul senaryosunu doğrular. İçerik editörleri de alternatif metin, başlık yapısı veya bağlantı anlamı gibi sürekli içerik sorumluluklarında sürece dahil edilmelidir.

  • Tasarım kararlarının sahibi ve onaylayıcısını belirleyin.
  • Ön yüz kod düzeltmelerinin geliştirici sorumluluğunu tanımlayın.
  • İçerik kaynaklı erişilebilirlik görevlerini editörlere atayın.
  • Test ve yeniden test sorumluluğunu uygulamadan bağımsız izleyin.
  • Ortak bileşen değişikliklerinde tasarım sistemi sahibini sürece dahil edin.
08

Erişilebilirlik geliştirme teklifleri nasıl karşılaştırılmalıdır?

Erişilebilirlik geliştirme teklifleri toplam vaat üzerinden değil, test kapsamı, düzeltme sorumluluğu, kritik görevlar, teslim belgeleri ve kabul yöntemi üzerinden karşılaştırılmalıdır. Aynı “erişilebilirlik çalışması” ifadesi bir sağlayıcıda yalnızca tarama raporunu, diğerinde manuel test, tasarım revizyonu, kod geliştirme ve yeniden testi kapsayabilir. Bu nedenle kapsam satırlarının karşılaştırılabilir hale getirilmesi satın alma kararının temelidir.

Sağlayıcı görüşmesini ölçülebilir teslimlere bağlayın

Teklif görüşmesinden önce kritik sayfalar, kullanıcı görevleri, kullanılan teknoloji altyapısı ve bilinen sorunlar paylaşılmalıdır. Firmadan hangi işleri kendi ekibinin üstleneceği, hangi girdilere ihtiyaç duyacağı ve kabulün nasıl yapılacağı açıkça istenmelidir. Böylece erişilebilirlik düzeltme projesi belirsiz bir uyumluluk iddiası olmaktan çıkar; sorun, sorumlu, düzeltme, test ve kabul adımlarından oluşan yönetilebilir bir geliştirme sürecine dönüşür.

  • Test edilen sayfa sayısından çok kritik görev kapsamını karşılaştırın.
  • Manuel test ile otomatik taramanın ayrı tanımlanmasını isteyin.
  • Tasarım ve kod düzeltmelerinin teklif kapsamını karşılaştırın.
  • Yeniden test, regresyon kontrolü ve teslim raporunu değerlendirin.
  • Açık bulguların devir ve takip yöntemini sözleşmede netleştirin.

Mobil Erişilebilirlik Kapsamınızı Netleştirin

Mobil sitenizin kritik kullanıcı akışları için erişilebilirlik incelemesi, geliştirme sorumlulukları ve kabul testlerini kapsayan bir çalışma talep edin.

Kapsamlandırılmış Teklif Alın