Erişilebilirlik ve i18n: Kapsayıcı Çok Dilli Uygulamalar Ge…

Erişilebilirlik ve i18n: Kapsayıcı Çok Dilli Uygulamalar Geliştirmek

Erişilebilirlik ve uluslararasılaştırma (i18n), yazılım geliştirmede çoğunlukla birbirinden bağımsız konular olarak ele alınır; farklı ekipler tarafından proje yaşam döngüsünün farklı aşamalarında üstlenilir. Bu ayrım bir hatadır—her iki disiplin de aynı temel amacı paylaşır: yazılımı yeteneklerinden veya dillerinden bağımsız olarak herkes tarafından kullanılabilir kılmak.

Erişilebilirlik ve i18n'i başından birlikte oluşturduğunuzda, farklı ihtiyaçlara sahip küresel kullanıcılara gerçek anlamda hizmet eden uygulamalar yaratırsınız. Bunları sonradan düşünülen birer ek olarak gördüğünüzde ise birbirini pekiştiren iki ayrı teknik borç yığını oluşturursunuz.

Erişilebilirlik ve i18n Neden Birbirine Bu Kadar Bağlıdır?

Erişilebilirlik ve i18n'in kesişimi, çoğu geliştiricinin fark ettiğinden çok daha derindir:

Ekran okuyucular ve dil: Ekran okuyucular metinden konuşmaya sentezi kullanır. Sayfa diliniz yanlış (ya da hiç) bildirilmişse, ekran okuyucu kelimeleri yanlış telaffuz eder ve İngilizce dışındaki dillerde içeriği görme engelli kullanıcılar için anlaşılmaz hale getirir.

RTL ve uzamsal gezinme: Sağdan sola düzenler yalnızca görsel tasarımı değil, aynı zamanda klavye gezinme sırasını ve odak yönetimini de etkiler. Yanlış odak sırası, ekran okuyucu gezintisini ve yalnızca klavye kullanan gezinmeyi aynı anda bozar.

Farklı yazı sistemlerinde yazı tipi erişilebilirliği: Yüksek kontrastlı temalar ve disleksi dostu yazı tipleri, uygulamanızda kullanılan tüm yazı sistemlerini desteklemelidir; yalnızca Latin karakterleri değil.

Alternatif metin yerelleştirmesi: Görseller, uygulamanızın desteklediği her dilde alt metin gerektirir. İngilizce bir alt metin, Japonca kullanan bir ekran okuyucu kullanıcısına hiçbir işe yaramaz.

Sesli açıklamalar: Erişilebilir video içeriği sesli açıklamalar gerektirir. Çok dilli uygulamalarda bunların çevrilmesi ve yerelleştirilmiş videoya uygun biçimde zamanlanması gerekir.

Bilişsel yük ve çeviri kalitesi: Sade dil ilkeleri—kısa cümleler, açık yapı, basit sözcük dağarcığı—hem erişilebilirliği (bilişsel engelli kullanıcılar için) hem de çevrilebilirliği artırır. Karmaşık, deyimsel İngilizce; anadili İngilizce olmayan kullanıcılar için anlaması daha zor, doğru çevrilmesi de daha güçtür.

i18n Açısından WCAG 2.1 Gereksinimleri

WCAG 2.1 (Web İçeriği Erişilebilirlik Kılavuzları), dört ilke üzerinden gereksinimler tanımlar: Algılanabilir, Çalıştırılabilir, Anlaşılabilir ve Sağlam. Birçok kriter doğrudan i18n çıkarımları taşır.

3.1.1 Sayfanın Dili (Seviye A)

Gereksinim: Her Web sayfasının varsayılan insan dili programatik olarak belirlenebilir olmalıdır.

i18n çıkarımı: <html> öğesindeki lang niteliği, sayfanın geçerli diliyle eşleşmelidir. Çok dilli bir uygulamada, kullanıcı dil değiştirdiğinde bu değer dinamik olarak güncellenmek zorundadır.

<!-- Doğru: lang gerçek içerik diliyle eşleşiyor -->
<html lang="ar" dir="rtl">
  <!-- Arapça içerik -->
</html>

<!-- Yanlış: Japonca içerikte İngilizce lang -->
<html lang="en">
  <p>日本語のコンテンツ</p>
</html>

next-i18next veya benzeriyle React'ta:

// pages/_document.tsx
import { Html } from 'next/document';

export default function Document({ locale }) {
  return (
    <Html lang={locale} dir={locale === 'ar' || locale === 'he' ? 'rtl' : 'ltr'}>
      {/* ... */}
    </Html>
  );
}

3.1.2 Bölümlerin Dili (Seviye AA)

Gereksinim: İçerikteki her pasaj veya cümlenin insan dili programatik olarak belirlenebilir olmalıdır.

i18n çıkarımı: Sayfanızda birden fazla dilde metin bulunduğunda (örneğin Almanca bir sayfa içinde İngilizce bir ifade), dil değişikliği işaretlenmelidir:

<p lang="de">
  Wir bieten auch <span lang="en">premium support</span> an.
</p>

1.3.4 Yönlendirme (Seviye AA)

i18n çıkarımı: Bazı yazı sistemleri (Moğolca gibi) geleneksel olarak dikey yazılır. Yönlendirme kısıtlamaları, yazı sistemine özgü okuma gelenekleriyle çelişebilir.

1.4.5 Metin İçeren Görseller (Seviye AA)

i18n çıkarımı: Görsellere gömülü metin yerelleştirilemez. Bu gereksinim, görsel tabanlı metin yerine gerçek metin (yerelleştirilebilir) kullanımını teşvik eder.

2.4.2 Sayfa Başlığı (Seviye A)

i18n çıkarımı: Sayfa başlıkları her dilde çevrilmiş olmalıdır. Çevrilmemiş sayfa başlıkları hem bir erişilebilirlik (ekran okuyucular sayfa başlıklarını seslendirir) hem de bir yerelleştirme hatasıdır.

ARIA Etiketleri Çevrilmek Zorundadır

ARIA etiketleri, ekran okuyucu kullanıcıları için kritik öneme sahiptir ve yerelleştirilmek zorundadır. Bir ARIA niteliğine iletilen her dize, kodda İngilizce sabit değer olarak değil, çeviri sisteminizden gelmelidir.

// Yanlış: kodda sabit İngilizce ARIA etiketi
<button aria-label="Close dialog">X</button>

// Doğru: çevrilmiş ARIA etiketi
import { useTranslation } from 'react-i18next';

function CloseButton() {
  const { t } = useTranslation();
  return (
    <button aria-label={t('dialog.close')}>
      <CloseIcon />
    </button>
  );
}

Bu durum tüm ARIA nitelikleri için geçerlidir: aria-label, aria-description, aria-placeholder, aria-roledescription ve tüm aria-live bölge içerikleri.

React i18n kalıplarının daha kapsamlı bir incelemesi için React i18n rehberimize bakabilirsiniz.

Dinamik İçerik ve Canlı Bölgeler

ARIA canlı bölgeleri, dinamik içerik değişikliklerini ekran okuyucu kullanıcılarına duyurur. Çok dilli uygulamalarda:

Canlı bölge duyuruları mevcut sayfa dilinde olmalıdır
Çeviri yükleme durumları erişilebilir biçimde iletilmelidir
Dil değiştirme arayüzü, dil değişikliğini ekran okuyuculara duyurmalıdır

function LanguageSwitcher() {
  const { i18n, t } = useTranslation();
  const [announcement, setAnnouncement] = useState('');

  const changeLanguage = async (locale) => {
    await i18n.changeLanguage(locale);
    setAnnouncement(t('language.changed', { language: locale }));
  };

  return (
    <>
      <select onChange={(e) => changeLanguage(e.target.value)}>
        {/* ... seçenekler */}
      </select>
      {/* Ekran okuyucu duyurusu için erişilebilir canlı bölge */}
      <div aria-live="polite" aria-atomic="true" className="sr-only">
        {announcement}
      </div>
    </>
  );
}

RTL ve Klavye Gezintisi

RTL düzenler, sayfanın görsel sırasını tersine çevirir. Klavye gezintisi (Tab, Shift+Tab, ok tuşları) görsel sırayı yansıtmalıdır; bu da RTL düzenler için DOM sırasının veya tabindex değerinin ayarlanması gerekebileceği anlamına gelir.

CSS'te yönlü özellikler yerine mantıksal özellikler kullanın:

/* Yanlış: sol/sağ yönleri sabit olarak kodlanmış */
.card {
  margin-left: 16px;
  padding-right: 24px;
  border-left: 2px solid var(--accent);
}

/* Doğru: mantıksal özellikler kullanılıyor, yazı yönüne uyum sağlıyor */
.card {
  margin-inline-start: 16px;
  padding-inline-end: 24px;
  border-inline-start: 2px solid var(--accent);
}

RTL uygulamasına kapsamlı bir kılavuz için bkz. CSS ve React'ta RTL desteği.

Erişilebilirlik ve Yazı Sistemi Desteği için Yazı Tipi Değerlendirmeleri

Erişilebilir tipografi şunları gerektirir:

Minimum yazı tipi boyutları (gövde metninde 16px yaygın olarak önerilen değerdir)
Yeterli kontrast oranları (WCAG 2.1 AA'ya göre normal metin için 4,5:1, büyük metin için 3:1)
Kullanıcı yazı tipi boyutu tercihlerine destek (göreceli birimler: px değil rem)

Birden fazla yazı sistemini desteklerken seçtiğiniz yazı tipleri şunları sağlamalıdır:

Gerekli tüm Unicode aralıklarını kapsamalı
Yazı sistemleri genelinde okunabilir oranları korumalı (CJK karakterler, Latin metin için tasarlanan boyutlarda küçük görünür)
Erişilebilirlik özellikleri için değişken yazı tipi ağırlığı ve boyut ölçeklendirmesini desteklemeli

Sistem yazı tipi yığınları genellikle erişilebilirlik ve i18n için birlikte iyi çalışır:

font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Noto Sans,
             Helvetica, Arial, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji';

Noto Sans, tüm Unicode yazı sistemlerini kapsayacak şekilde özel olarak tasarlanmıştır; kullanıcıların hangi yazı sistemlerine ihtiyaç duyacağını tahmin edemediğinizde oldukça işlevseldir.

Renk ve Kültürel Anlam

WCAG, rengin bilgi iletmenin tek yolu olarak kullanılmamasını gerektirir (1.4.1). Bu kural, kültürel renk anlamlarıyla kesişir:

Batı bağlamında kırmızı "dur" veya "tehlike" anlamına gelirken Çin bağlamında şans getirir
Finansal kazanç/kayıp göstergelerinde yalnızca renge güvenmek (kırmızı = kayıp, yeşil = kazanç) hem WCAG'ı hem de kültürlerarası kullanılabilirliği ihlal eder

Önemli durum göstergeleri için renk, metin etiketi ve simgeyi birlikte kullanın:

function PriceChange({ value, locale }) {
  const isPositive = value > 0;
  return (
    <span 
      className={isPositive ? 'gain' : 'loss'}
      aria-label={`${isPositive ? t('price.gain') : t('price.loss')}: ${formatCurrency(value, locale)}`}
    >
      {isPositive ? '▲' : '▼'} {formatCurrency(value, locale)}
    </span>
  );
}

Form Doğrulama ve Hata Mesajları

Erişilebilir form doğrulaması şunları gerektirir:

aria-describedby aracılığıyla alanlarıyla ilişkilendirilmiş hata mesajları
Form gönderilemediğinde odağın hatalara taşınması
Açık, eyleme yönelik hata dili

Tüm hata mesajları çevrilmelidir. Zod, yup veya react-hook-form gibi doğrulama kütüphanelerinde, hata mesajı dizelerinizin i18n sisteminizden geldiğinden emin olun:

// Yanlış: kodda sabit İngilizce hata
const schema = z.object({
  email: z.string().email('Please enter a valid email address'),
});

// Doğru: çevrilmiş hata mesajları
function useFormSchema() {
  const { t } = useTranslation();
  return z.object({
    email: z.string().email(t('validation.email.invalid')),
  });
}

Çok Dilli İçerikle Erişilebilirliği Test Etmek

Çok dilli uygulamalarda erişilebilirliği test etmek, desteklenen her dilde ayrı ayrı test yapmayı gerektirir:

Ekran okuyucu testi: Her dili uygun bir TTS sesiyle test edin. VoiceOver (macOS/iOS), NVDA (Windows), TalkBack (Android). Temel terimlerin telaffuzunu ve dil değişikliklerinin duyurulduğunu doğrulayın.

Klavye gezintisi testi: Hem LTR hem de RTL düzenlerde mantıklı sekme sırasını doğrulayın. Odak göstergeleri tüm renk temalarında görünür olmalıdır.

Otomatik test: axe-core, Lighthouse ve Pa11y gibi araçlar birçok WCAG ihlalinı otomatik olarak yakalayabilir. Her yerel ayar için CI'da çalıştırın. Entegrasyon kalıpları için bkz. i18n test araçları, stratejileri ve otomasyonu.

Renk kontrastı doğrulaması: Latin olmayan yazı sistemlerindeki metinler dahil tüm metinler için tüm temalarda (açık, koyu, yüksek kontrastlı) kontrast oranlarını doğrulayın.

Yasal Gereksinimler: Yerel Ayarlar Genelinde Erişilebilirlik

Erişilebilirlik yasaları ülkeye ve sektöre göre farklılık gösterir:

Bölge	Yasa	Gereksinim
ABD	ADA, Section 508	Federal kurumlar ve kamuya açık yerler için WCAG 2.1 AA
AB	Avrupa Erişilebilirlik Yasası (2025)	AB'deki ürün/hizmetler için WCAG 2.1 AA
İngiltere	PSBAR, Eşitlik Yasası	Kamu sektörü için WCAG 2.1 AA
Kanada	AODA (Ontario), ACA	WCAG 2.0 AA, 2.1'e geçiş sürecinde
Avustralya	Engellilik Ayrımcılığı Yasası	WCAG 2.1 AA önerilen

Bu pazarlara hizmet eden çok dilli uygulamalarda, erişilebilirlik uyumu hizmet verilen kullanıcıların dilinde yasal bir gerekliliktir. İspanyolca arayüz erişilebilirlik standartlarını karşılamıyorsa, erişilebilir bir İngilizce arayüz İspanyolca konuşan kullanıcılar için ADA gereksinimini karşılamaz.

Temel:

lang niteliği her dil için doğru ayarlanmış
RTL diller için dir niteliği ayarlanmış
Tüm metinler i18n sisteminden geliyor (hiçbir şey sabit kodlanmış değil)
ARIA etiketleri ve açıklamaları çevrilmiş

Görsel tasarım:

Mantıksal CSS özellikleri kullanılıyor (yönlü değil)
Renk, bilgi iletmenin tek yolu değil
Tüm renk temalarında yeterli kontrast sağlanıyor
Yazı tipi gerekli tüm yazı sistemlerini destekliyor
Kullanıcı tercihlerine göre göreceli yazı tipi boyutlandırması

Etkileşim:

LTR ve RTL'de klavye gezintisi mantıklı
Tüm temalarda odak göstergeleri görünür
Dinamik içerik ARIA canlı bölgeleri aracılığıyla duyuruluyor
Dil değişiklikleri ekran okuyuculara duyuruluyor

Formlar:

Hata mesajları çevrilmiş ve alanlarıyla ilişkilendirilmiş
Form etiketleri çevrilmiş
Yer tutucu metni çevrilmiş
Doğrulama geri bildirimi kullanıcının dilinde

Test:

Her yerel ayar için CI'da axe-core/Lighthouse
Temel dillerde manuel ekran okuyucu testi
RTL klavye gezintisi doğrulandı
Tüm temalar ve yazı sistemlerinde renk kontrastı doğrulandı

Uygulamanızı better-i18n ile küresel hale getirin

better-i18n; yapay zeka destekli çeviriler, git-yerel iş akışları ve küresel CDN dağıtımını tek bir geliştirici odaklı platformda birleştirir. Elektronik tabloları yönetmeyi bırakın ve her dilde yayınlamaya başlayın.

Ücretsiz başlayın → · Özellikleri keşfedin · Belgeleri okuyun

Erişilebilirlik ve i18n: Kapsayıcı Çok Dilli Uygulamalar Geliştirmek