Web Sitesi Firmasından Erişilebilirlik Çalışması İçin Teklif Alırken Neler Tanımlanmalı?

Erişilebilirlik teklifi ölçülebilir kapsama nasıl dönüşür?

Erişilebilirlik çalışması, genel bir tasarım iyileştirmesi olarak değil, denetlenebilir ve teslim edilebilir iş paketleri olarak tanımlanmalıdır. Teklif talebinde mevcut sitenin durumu, hedeflenen sayfalar, ortak bileşenler, içerik türleri, üçüncü taraf araçlar ve test yöntemi ayrı ayrı yazıldığında firmalar aynı probleme daha yakın bir kapsam üzerinden fiyat verebilir. Bu ayrım, daha sonra ortaya çıkabilecek kapsam değişikliklerinin hangi iş paketini etkilediğini görmeyi ve ek talepleri ana tekliften ayırmayı da kolaylaştırır.

Önce iş paketlerini birbirinden ayırın

Bir firma yalnızca teknik hata düzeltmesini, başka bir firma tasarım ve içerik revizyonlarını da aynı kaleme dahil edebilir. Bu nedenle teklif talebinde denetim, tasarım, geliştirme, içerik, test ve bakımın ayrı başlıklar halinde tanımlanması gerekir. Ayrıca hangi erişilebilirlik standardının veya kurum içi kabul ölçütünün hedeflendiği belirtilmeli; standart adı tek başına bırakılmadan teslimin nasıl doğrulanacağı da açıklanmalıdır.

• Mevcut durum ve erişilebilirlik denetimi
• Sayfa ile bileşen envanteri
• Tasarım ve etkileşim düzeltmeleri
• Ön yüz geliştirme çalışmaları
• İçerik ve belge düzenlemeleri
• Manuel ve araç destekli testler

Web’in gücü evrenselliğindedir. Engellilik durumundan bağımsız olarak herkesin erişebilmesi temel bir unsurdur. - Tim Berners-Lee

İlk erişilebilirlik denetimi teklife nasıl dahil edilir?

İlk denetim, fiyatlandırmanın parçası da olabilir ayrı bir keşif hizmeti olarak da tanımlanabilir; önemli olan bunun teklif öncesinde açıkça belirtilmesidir. Mevcut sitenin kapsamı, şablon çeşitliliği ve teknik borcu bilinmiyorsa sabit geliştirme kapsamına doğrudan geçmek yerine önce denetim teslimi istemek, sonraki iş paketlerini daha gerçekçi biçimde tanımlamaya yardımcı olur.

Denetimin çıktısını ve sınırını yazılı hale getirin

Denetim teklifinde kaç sayfanın veya şablonun örnekleneceği, ortak bileşenlerin nasıl inceleneceği, hangi manuel testlerin yapılacağı ve bulguların nasıl sınıflandırılacağı açıklanmalıdır. Genel teklif hazırlama yaklaşımını yapılandırmak için web tasarım firmasından teklif alırken sorulması gereken başlıklar da erişilebilirlik özelindeki gereksinimleri daha geniş bir satın alma çerçevesine yerleştirmeye yardımcı olur.

• Denetimin ayrı mı dahil mi olduğu
• İncelenecek örnek sayfa sayısı
• Kontrol edilecek ortak bileşenler
• Manuel testlerin kapsamı
• Bulgu önceliklendirme yöntemi
• Denetim raporunun teslim biçimi

Hangi sayfa ve bileşenler fiyatlandırmaya girmelidir?

Fiyatlandırmaya yalnızca tek tek sayfa URL’leri değil, site genelinde tekrar eden şablon ve bileşenler de dahil edilmelidir. Ana sayfa, içerik sayfası veya ürün sayfası gibi şablonlar kadar menü, arama, modal pencere, form, filtre, sekme, akordeon ve hata mesajı gibi etkileşimli bileşenler de erişilebilirlik iş yükünü belirler.

URL listesini bileşen envanteriyle tamamlayın

Yüzlerce URL aynı birkaç şablondan üretilebileceği gibi, az sayıda URL çok sayıda farklı etkileşim içerebilir. Bu yüzden teklif kapsamı sayfa adedine indirgenmemeli; benzersiz şablonlar, bileşenler ve kullanıcı akışları birlikte sayılmalıdır. Yeni site projelerinde tasarım sistemi veya bileşen kütüphanesi varsa, hangi parçaların erişilebilirlik kriterlerine göre yeniden düzenleneceği ayrıca belirtilmelidir. Böyle bir envanter aynı hatanın onlarca sayfada ayrı ayrı fiyatlandırılması yerine kök bileşende çözülüp çözülmeyeceğini de ortaya çıkarır.

• Benzersiz sayfa şablonları
• Global menü ve navigasyon
• Formlar ve doğrulama mesajları
• Modal, sekme ve akordeonlar
• Arama ve filtre bileşenleri
• Dosya ve belge bağlantıları

Tasarım düzeltmeleri teklif içinde nasıl ayrıştırılmalıdır?

Tasarım düzeltmeleri, geliştirme işiyle tek kalemde birleştirilmek yerine hangi ekranların ve bileşenlerin yeniden tasarlanacağını gösterecek şekilde ayrıştırılmalıdır. Renk karşıtlığı, odak görünürlüğü, form etiketleri, hata geri bildirimi, hareketli içerik kontrolü ve etkileşim durumları gibi tasarım kararları kodlama başlamadan önce çözülürse geliştirme kapsamı daha öngörülebilir hale gelir.

Tasarım teslimini yalnızca görsel revizyon saymayın

Erişilebilir tasarım, masaüstü ekran görüntüsünün değiştirilmesinden ibaret değildir. Klavye odağı, hata durumu, boş durum, doğrulama mesajı ve farklı ekran boyutlarındaki davranışlar da tasarım tesliminde gösterilmelidir. Firma tasarım sistemi kullanıyorsa her bileşenin normal, odaklanmış, seçili, devre dışı ve hatalı durumları tanımlanarak geliştirme ekibine tutarlı bir uygulama referansı verilmelidir.

• Renk ve kontrast kararları
• Odak ve etkileşim durumları
• Form etiket ve hata desenleri
• Hareketli içerik kontrolleri
• Responsive kullanım senaryoları
• Bileşen durumlarının tasarımı

Geliştirme ve içerik işleri teklifte nasıl ayrılmalıdır?

Ön yüz geliştirme ile içerik düzenleme işleri ayrı kalemler olarak tanımlanmalıdır çünkü sorumluluk, uzmanlık ve iş yükü birbirinden farklıdır. Semantik HTML, klavye etkileşimi, odak yönetimi ve dinamik bileşen davranışı geliştirme kapsamındayken alternatif metinler, bağlantı açıklıkları, başlık yapısı ve belge düzenlemeleri içerik ekibinin sorumluluğunda olabilir.

Teklif kapsamını sorumluluk matrisiyle netleştirin

Firma hangi içerikleri kendisinin düzelteceğini, hangileri için yalnızca rehber sağlayacağını ve müşteri ekibinden hangi girdileri beklediğini belirtmelidir. Genel web sitesi tekliflerinde tasarım, yazılım ve destek kalemlerini ayırmak için kullanılan web sitesi fiyat teklifinin hangi hizmetleri kapsaması gerektiğini açıklayan çerçeve, erişilebilirlik geliştirmesinin ana proje içindeki sınırını da daha görünür kılar.

• Semantik HTML düzenlemeleri
• Klavye etkileşim davranışları
• Odak yönetimi ve bileşen mantığı
• Alternatif metin ve içerik revizyonları
• Başlık ve bağlantı yapısı
• Dosya ve belge iyileştirmeleri

Üçüncü taraf formlar ve araçlardan kim sorumlu olmalıdır?

Üçüncü taraf form, sohbet, harita, rezervasyon, ödeme veya gömülü içerik araçlarının sorumluluğu teklif aşamasında açıkça belirlenmelidir. Web sitesi firması kendi kodunda düzeltme yapabilse bile dış sağlayıcının kapalı bileşenlerine müdahale edemeyebilir; bu nedenle sorun tespiti, sağlayıcı iletişimi, alternatif çözüm ve kapsam dışı kabul koşulları ayrı ayrı tanımlanmalıdır.

Kontrol alanı ile bağımlılığı birbirinden ayırın

Teklifte her üçüncü taraf araç için kimin teknik sahibi olduğu, erişilebilirlik sorunu bulunduğunda hangi aksiyonun alınacağı ve çözüm mümkün değilse nasıl bir alternatif kullanıcı akışı sağlanacağı yazılmalıdır. Özellikle kritik işlem adımlarında kullanılan dış bileşenler yalnızca “müşteriye ait” denilerek kapsam dışı bırakılmamalı; en azından risk ve uygulanabilir seçenekler raporlanmalıdır.

• Üçüncü taraf araç envanteri
• Teknik sahiplik bilgisi
• Müdahale edilebilirlik sınırı
• Sağlayıcıya bildirim süreci
• Alternatif kullanıcı akışı
• Kapsam dışı kabul koşulu

İyileştirmeler nasıl test edilip teslim edilmelidir?

Erişilebilirlik iyileştirmeleri yalnızca otomatik tarama sonucuyla teslim edilmemeli; otomatik kontroller, klavye ile kullanım testi, odak sırası incelemesi, form davranışları ve uygun olduğunda yardımcı teknoloji kontrolleri birlikte ele alınmalıdır. Teklifte test yöntemi, örneklenen sayfalar, kullanılacak tarayıcı veya cihaz kapsamı ve kabul edilen kalan bulgular açıkça yazılmalıdır. Test kapsamının yalnızca geliştiricinin kendi kontrolü mü yoksa ikinci bir doğrulama turu mu içerdiği de teklif karşılaştırmasında özellikle ayrıştırılmalıdır.

Teslimi hata listesi yerine doğrulama kaydı yapın

Son teslim paketinde yapılan değişikliklerin listesi, tekrar test sonucu, kapatılan bulgular ve henüz giderilmemiş konular bulunmalıdır. Ayrıca hangi bulgunun teknik kısıt, içerik sorumluluğu veya üçüncü taraf bağımlılığı nedeniyle açık kaldığı belirtilmelidir. Böylece müşteri yalnızca “düzeltildi” ifadesine değil, doğrulama adımlarına ve kalan iş kaydına bakarak kabul kararı verebilir.

• Otomatik kontrol sonuçları
• Klavye ile tam kullanım testi
• Odak sırası ve görünürlük kontrolü
• Form ve hata mesajı testleri
• Yardımcı teknoloji doğrulaması
• Kalan bulguların kayıt altına alınması

Sayfalar hangi ölçütlerle önce ele alınmalıdır?

Önceliklendirme, yalnızca en çok ziyaret edilen sayfalara göre yapılmamalı; trafik, işlem önemi, kullanıcı şikâyetleri, kritik dönüşüm adımları ve tekrar kullanılan bileşenlerin etkisi birlikte değerlendirilmelidir. Ortak bir menü veya form bileşenindeki düzeltme çok sayıda sayfayı etkileyebileceği için bazı bileşen iyileştirmeleri tek bir yüksek trafikli sayfadan daha yüksek öncelik taşıyabilir.

İş etkisi ile erişim sorununu aynı matriste değerlendirin

Teklif veren firmanın yalnızca hata sayısına göre değil, kullanıcı üzerindeki etkisine göre de öncelik verebilmesi önemlidir. Sağlayıcının teknik yaklaşımını değerlendirirken web tasarım firmasının teknik yeterliliğini anlamaya yönelik kriterler, erişilebilirlik işlerinde hata kaynağını teşhis etme, bileşen seviyesinde çözüm üretme ve regresyon riskini yönetme kapasitesini sorgulamak için kullanılabilir.

• Trafik ve kullanım yoğunluğu
• İşlem ve dönüşüm kritikliği
• Kullanıcı geri bildirimleri
• Tekrarlanan bileşenlerin etkisi
• Sorunun kullanım üzerindeki ağırlığı
• Teknik bağımlılık ve regresyon riski

Yeni içerikler için bakım desteği nasıl tanımlanmalıdır?

Bakım desteği, yalnızca mevcut hataların tekrar düzeltilmesi olarak değil, yeni sayfa, içerik ve bileşenlerin erişilebilirlik kalitesini koruyan bir süreç olarak tanımlanmalıdır. İçerik editörleri, tasarımcılar ve geliştiriciler için kontrol noktaları oluşturulmadığında ilk proje tamamlandıktan sonra yeni eklemeler aynı sorunları yeniden üretebilir.

Sürekli kontrolün kapsam ve sorumluluğunu belirleyin

Bakım teklifinde periyodik denetimin kapsamı, yeni bileşenlerin kim tarafından test edileceği, içerik ekibine hangi kontrol listelerinin sağlanacağı ve kritik değişikliklerde yeniden doğrulamanın nasıl yapılacağı belirtilmelidir. Teknik teklifleri karşılaştırırken web sitesi geliştirme firmalarının teknik tekliflerini karşılaştırma yaklaşımı, bakım ve destek sorumluluklarını ilk geliştirme kapsamından ayırmak için de kullanılabilir.

• Periyodik yeniden denetim kapsamı
• Yeni bileşen kabul kontrolü
• İçerik editörü kontrol listeleri
• Tasarım sistemi güncelleme kuralları
• Kritik değişiklik sonrası doğrulama
• Bulgu takip ve kapanış süreci

Farklı erişilebilirlik teklifleri nasıl karşılaştırılmalıdır?

Farklı teklifler, toplam bedelden önce aynı iş paketlerini kapsayıp kapsamadığına göre karşılaştırılmalıdır. İlk denetimin durumu, sayfa ve bileşen envanteri, tasarım ile geliştirme sınırı, üçüncü taraf sorumlulukları, test yöntemi, kalan bulguların kaydı ve bakım yaklaşımı ortak bir kontrol listesine dönüştürüldüğünde fiyat farklarının hangi kapsam farkından kaynaklandığı daha görünür olur.

Kararı teslim ölçütleri üzerinden verin

Teklifte yalnızca yapılacak işler değil, hangi koşulda işin tamamlanmış sayılacağı da bulunmalıdır. İlk denetimin ayrı mı dahil mi olduğu, hangi sayfa ve bileşenlerin fiyatlandığı, üçüncü taraf araçlardan kimin sorumlu olduğu, iyileştirmelerin nasıl test edilip teslim edileceği ve yeni içerikler için bakımın nasıl sürdürüleceği açık biçimde cevaplanıyorsa firmalar daha sağlıklı karşılaştırılabilir. Belirsiz kalan başlıklar ise sözleşmeden önce netleştirilmelidir. Aynı kontrol seti tüm aday firmalara gönderildiğinde eksik kapsamlar erken görünür, teklif revizyonları daha kontrollü yürütülür ve satın alma ekibi yalnızca toplam tutara bakmak yerine teslim edilecek gerçek işi karşılaştırabilir.

• Kapsamın aynı temelde karşılaştırılması
• Denetim ile uygulamanın ayrılması
• Sorumlulukların açıkça yazılması
• Test ve kabul yönteminin tanımlanması
• Kalan işlerin kayıt altına alınması
• Bakım modelinin ayrıca belirtilmesi