Sayfa yükleniyor…

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.

Geliştirici Erişilebilirlik Hizmetleri broşürü ve yanında basılı erişilebilirlik bulguları tablosu

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.

Masaüstü ekranında erişilebilirlik sonuçlarını inceleyen iki çalışan ve yanında erişilebilirlik istatistik paneli
  • 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?

  1. 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.

  2. Geliştirme

    Otomatik kontroller ve kod incelemesi; eksik etiketleri, anlamsal olmayan HTML'i ve hatalı işaretlemeyi sürümden önce yakalar.

  3. Kalite güvence

    Klavye, ekran okuyucu ve yardımcı teknolojiyle yapılan manuel test, otomatik araçların ölçemediğini kapsar.

  4. 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.

  5. 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 uygunluk rozeti

    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 uygunluk rozeti

    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.

  • Avrupa Erişilebilirlik Yasası uygunluk rozeti

    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 uygunluk rozeti

    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 uygunluk rozeti

    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?

Otomatik tarayıcı ve yalnızca denetim raporunun WeAccess.Ai ile karşılaştırması
ÖzellikOtomatik tarayıcıYalnızca denetim raporuWeAccess.Ai
WCAG kriter kapsamı Yalnızca yapısal kurallarKapsamlı, belirli bir ana aitEvetKod düzeyinde, kapsamlı
Çıktı Belirtiler listesiYorumlanması gereken bir dokümanEvetDosya ve satıra eşlenen bulgular
Düzeltmeyi kim yapıyor Ekibiniz, desteksizEkibiniz, desteksizEvetBiz, ekibiniz ya da birlikte
Framework farkındalığı YokSınırlıEvetReact, Vue, Angular, özel
Regresyonların önlenmesi YokSonraki denetimde yeniden bulunurEvetHer 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.

Geliştirici Erişilebilirlik Ekibimizle Görüşün

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.