Geliştirici Erişilebilirlik Hizmetleri
Tasarım ekibiniz her mockup'ı onaylayabilir, QA ekibiniz her sürümü geçirebilir; ürününüz yine de WCAG'den kalabilir. Uyumluluk kodda belirlenir. Bir bileşenin nasıl işaretlendiğine, odağın nasıl hareket ettiğine ve bir formun kendi hatalarını nasıl bildirdiğine bağlıdır.
Bu açığı üretime ulaşmadan kapatmak için doğrudan geliştiricilerinizle, sizin kod tabanınızın içinde çalışıyoruz.

Bize güvenen kurumlar daha erişilebilir dijital deneyimler kuruyor.
Geliştirici erişilebilirliği nedir?
Geliştirici erişilebilirliği, erişilebilir görünen bir tasarımın gerçekten erişilebilir davranıp davranmadığını belirleyen uygulama düzeyindeki pratiklerin tamamıdır. Anlamsal işaretleme, klavye desteği, odak yönetimi ve doğru ARIA kullanımı buraya girer. Bir tasarım sistemi kusursuz kontrast tanımlayabilir; açılır menü etiketsiz div'lerden kurulduysa bileşen yine de başarısız olur.

Dosyaya eşlenen bulgular — Her sorun yalnızca URL'yi değil, dosyayı ve satırı gösterir.
React, Vue, Angular — Ekibinizin hâlihazırda kullandığı framework içinde çalışırız.
WCAG 2.1 / 2.2 AA — Kod düzeyinde, kriter kriter incelenir.
PR incelemesi ve CI kontrolleri — Regresyonların bir sonraki denetimden önce, pull request'lerde yakalanmasına yardımcı olur.
Neler Dahil?
Kod düzeyinde erişilebilirlik incelemesi
Mevcut bileşenleriniz WCAG 2.2 AA'ya göre incelenir ve her bulgu ona sebep olan kodla eşleştirilir.
Kod tabanınızda doğrudan iyileştirme
İşaretlenen bileşenleri biz düzeltiriz; böylece erişilebilirlik işi ürün yol haritanızla yarışmaz.
Zor bileşenlerde eşli çalışma
Özel açılır menüler, modallar ve veri tabloları birlikte kurulur, desen bir sonraki sefer için belgelenir.
ARIA uygulama desteği
ARIA yalnızca yerel HTML'in yetmediği yerde, WAI-ARIA Authoring Practices izlenerek uygulanır.
Pull request incelemesi
Erişilebilirlik geri bildirimi, kod birleşmeden önce normal inceleme sürecinizin içinde gelir.
Klavye ve odak yönetimi
Sekme sırası, görünür odak ve modallardaki odak tuzakları test edilip düzeltilir.
Her şey mevcut geliştirme akışınızın içinde olur; ekibinizin sonradan yorumlaması gereken ayrı bir denetim hattında değil.
Geliştirici erişilebilirlik desteğine kimlerin ihtiyacı var?
Denetim birikimi olan ekipler
Denetim, ekibin kod değişikliğine nasıl çevireceğini bilmediği kadar çok bulguyla döndü.
Süre baskısı altındaki ekipler
Yasal ya da satın alma kaynaklı bir tarih, iyileştirme birikiminin erimesinden daha hızlı yaklaşıyor.
Erişilebilirlik uzmanı olmayan ekipler
Kadroda daha önce erişilebilir özel bileşen kurmuş kimse yok; her bileşen ayrı bir araştırma projesine dönüşüyor.
Sürekli yayına alan ekipler
Sık sürümler, regresyonların yalnızca denetim öncesinde değil, denetimler arasında da ortaya çıkması demek.
Çoğu iç ekip erişilebilirliğin önemini zaten biliyor. Eksik olan zaman ve bu işi daha önce yapmış bir geliştirici.
Erişilebilirlik geliştirme yaşam döngünüze nasıl yerleşir?

Planlama ve tasarım
Erişilebilirlik gereksinimleri; odak sırası, klavye navigasyonu ve hata davranışını kapsayacak şekilde işlevsel gereksinimlerle birlikte tanımlanır.
Geliştirme
Otomatik kontroller ve kod incelemesi; eksik etiketleri, anlamsal olmayan HTML'i ve hatalı işaretlemeyi sürümden önce yakalar.
Kalite güvence
Klavye, ekran okuyucu ve yardımcı teknolojiyle yapılan manuel test, otomatik araçların ölçemediğini kapsar.
Sürüm öncesi doğrulama
Erişilebilirlik yayına almadan önce doğrulanır; bulgular sayfalara değil belirli bileşenlere bağlanır.
Bakım ve izleme
Yeni özellikler ve güncellemeler kontrol edilir; böylece düzeltilen sorunların sonraki sürümde geri dönme riski azalır.
Kodda tam olarak neler düzeltiliyor?
- Anlamsal HTML
- Başlık Yapısı
- Landmark Bölgeleri
- Alternatif Metin
- Form Etiketleri
- Hata Mesajları
- Klavye Navigasyonu
- Sekme Sırası
- Odak Görünürlüğü
- Odak Yönetimi
- Odak Tuzakları
- Sekme Panelleri
- Canlı Bölgeler
- Özel Açılır Menüler
- Combobox'lar
- Tarih Seçiciler
- ARIA Rolleri ve Durumları
- Modallar
- Veri Tabloları
- Dinamik İçerik Duyuruları
- Üçüncü Taraf Bileşenler
Bunların çoğu hiçbir tasarım mockup'ında görünmez. Ancak bir geliştirici uygulama tercihini yaptıktan sonra ortaya çıkarlar; bu yüzden de yalnızca bir geliştirici çözebilir.
Geliştirici Erişilebilirliğinde Hangi Standartları Kullanıyoruz?

WCAG 2.2 AA
Birçok erişilebilirlik yasasının ve satın alma şartının işaret ettiği teknik temel. Bazı düzenlemeler WCAG 2.1'e atıf yapar.

ADA
ABD'deki dijital erişilebilirlik çalışmalarında ilgili yasal gereklilikleri değerlendirmek için dikkate alınır; teknik uygulamalarda WCAG kriterlerinden yararlanılır.

EAA
Avrupa Birliği'nde kapsam dahilindeki ürün ve hizmetlerin erişilebilirlik gereklilikleri açısından teknik uygulamaların değerlendirilmesine yardımcı olur.

Section 508
ABD federal kurumlarının bilgi ve iletişim teknolojilerinde erişilebilirlik gerekliliklerini tanımlar; ilgili federal tedarik süreçlerinde önem taşır.

EN 301 549
WCAG ile eşleşen, ayrıca yazılım ve dokümantasyonu da kapsayan Avrupa standardı.
İnceleme ve iyileştirme sonuçlarını bileşen ve kod düzeyinde belgeler; geliştiricilerinizin hangi değişiklikleri yapması gerektiğini ve tamamlanan düzeltmeleri açıkça gösteririz.


Geliştirici Erişilebilirlik Hizmetlerinde Neden WeAccess.ai?
| Özellik | Otomatik tarayıcı | Yalnızca denetim raporu | WeAccess.Ai |
|---|---|---|---|
| WCAG kriter kapsamı | Yalnızca yapısal kurallar | Kapsamlı, belirli bir ana ait | EvetKod düzeyinde, kapsamlı |
| Çıktı | Belirtiler listesi | Yorumlanması gereken bir doküman | EvetDosya ve satıra eşlenen bulgular |
| Düzeltmeyi kim yapıyor | Ekibiniz, desteksiz | Ekibiniz, desteksiz | EvetBiz, ekibiniz ya da birlikte |
| Framework farkındalığı | Yok | Sınırlı | EvetReact, Vue, Angular, özel |
| Regresyonların önlenmesi | Yok | Sonraki denetimde yeniden bulunur | EvetHer pull request'te CI kontrolü |
Bir tarayıcı size bir ARIA niteliğinin geçersiz olduğunu söyleyebilir. Yerine hangi bileşen desenini kullanmanız gerektiğini söyleyemez.
Neden WeAccess.ai ile Geliştirici Erişilebilirliği?
Yalnızca raporlamıyor, düzeltiyoruz
İyileştirme, ekibinize teslim edilen bir dokümanda değil; gerçek bileşenlerde ve gerçek pull request'lerde olur.
Yerleşik erişilebilirlik desenleri
Bileşenler yerleşik desenler üzerine kurulur; böylece ürününüz geliştikçe bakımı sürdürülebilir kalır.
Sizin stack'iniz, sizin akışınız
React, Vue, Angular ya da özel bir framework'e ve onun render ile odağı ele alış biçimine uyum sağlarız.
Geride kalan yetkinlik
Eşli çalışma oturumları ve belgelenen desenler sayesinde ekibiniz benzer bileşenleri daha az dış destekle kurabilir.
Türkçe, İngilizce ve Almanca
Arayüz içeriğini üç dilde de inceler, ekibinizin çalıştığı dilde raporlarız.
SSS
Hâlâ sorunuz mu var? Tüm SSS bölümümüzü inceleyin.
İkisi de mümkün. İşaretlenen bileşenleri kod tabanınızda biz düzeltebiliriz ya da geliştiricileriniz değişiklikleri uygularken inceleyip yönlendirebiliriz.
React, Vue, Angular ile özel ve sunucu tarafında render edilen yığınlarda çalışıyoruz. Erişilebilirlik desenleri aynı; onları framework'ünüzün render ve odak davranışına uyarlıyoruz.
Uyumu kriter kriter belgeliyor ve kapsamdaki her şeyi düzeltiyoruz. Tam uyum içeriğe ve üçüncü taraf bileşenlere de bağlı olduğundan tek bir etiket vaat etmek yerine her birinin durumunu dürüstçe raporluyoruz.
Hangisini tercih ederseniz. Birçok ekip iyileştirmeyi bizim yapmamızla başlıyor, kendi yetkinliği arttıkça eşli çalışma ve pull request incelemesine geçiyor.
Bileşen düzeyinde odaklı bir çalışma genellikle birkaç hafta sürer. Mevcut denetim birikimi olan büyük ürünler, en yüksek etkili bulgular önceliklendirilerek aşamalar hâlinde planlanır.
Etkilerini belgeler, erişilebilir alternatifleri test ederiz; tedarikçinin değiştirilemediği durumlarda bileşeni sarmalamanıza, değiştirmenize ya da sorunu kanıtla birlikte yukarı taşımanıza yardımcı oluruz.
Herkesin kullanabileceği dijital deneyimler kurun.
WeAccess'in kurumunuzda web, mobil, doküman ve medya kanallarındaki erişilebilirliği yönetmenize nasıl yardımcı olduğunu görün.


























