Język strony

Co oznacza to kryterium

Podaj domyślny język każdej strony, dokumentu lub programu w sposób, który oprogramowanie może odczytać. Polski tekst powinien mieć oznaczenie odpowiadające polszczyźnie. Po zmianie języka całego ekranu oznaczenie musi odpowiadać nowej treści. Przycisk „Polski”, kodowanie UTF-8 i polskie litery nie zastępują metadanych języka.

Nie przypisujemy automatycznie motoryki, rozróżniania barw ani słuchu do tego tekstowego scenariusza. Ustawienie języka daje odbiornikowi informację; nie gwarantuje dostępności konkretnego głosu ani identycznej jakości każdego syntezatora.

Przykłady błędów i poprawek

Pracownia pokazuje odbiór syntetycznego zamówienia P-104: ul. Ogrodowa 8, piątek 10:00–18:00. Oba warianty mają te same teksty, układ i działania; różnica dotyczy języka semantyki całego ekranu. Przyciski „Polski” i „English” mają własne języki etykiet w każdym wariancie. Jawny wybór języka niezależnie od systemu pokazuje tę jedną funkcję, a nie pełne zarządzanie lokalizacją produktu.

Problem: bad przekazuje en przy polskiej treści i pl po przejściu na angielski. Oba tagi są poprawne składniowo, ale nie odpowiadają treści. Odbiornik otrzymuje błędną podstawę odczytu. Poprawka: aktualizuj Semantics.localeForSubtree razem z tekstami całego ekranu, także przy powrocie i resecie.

Nieznany wariant wraca do good. Przycisk „Zmień wariant” przechodzi good → bad → control i przywraca PL; reset wraca do wariantu trasy oraz PL. Demonstracja nie zapisuje preferencji ani nie zmienia zamówienia.

Historyczny przykład WWW

We wcześniejszej próbie z 2026-10-03 te same dane pokazano w HTML. Good miał html lang="pl", po English — en. Bad nie miał języka korzenia; języki dwóch przycisków nie obejmowały całej strony. Poprawka dodaje właściwy lang na html i aktualizuje go razem z treścią i tytułem. Wygląd good/bad w PL był identyczny bajtowo, co odpowiada niewidocznej zmianie metadanych.

Kiedy obowiązuje i gdzie są wyjątki

• Wymaganie normatywne: programowo dostępny domyślny język ludzki każdej strony. Nie jest to język programowania, kodowanie znaków ani kraj hostingu. W samym 3.1.1 nie ma listy wyjątków dla nazw własnych, terminów technicznych lub „niezbędności”.
• Wskazówka Understanding: na stronie wielojęzycznej przyjmujemy język używany najwięcej; przy równym udziale — pierwszy użyty. To wskazówka do oceny, nie mechaniczny próg procentowy. Krótkie nazwy, numery i pojedynczy slogan nie muszą zmieniać języka domyślnego.
• Technika H57: poprawny tag języka zgodny z BCP 47 na html, zgodny z językiem treści. pl i pl-PL mogą oznaczać tę samą polską stronę; region nie jest zawsze obowiązkowy. pl_PL nie jest poprawnym zapisem HTML/BCP 47. en jest poprawnym tagiem, lecz błędnym oznaczeniem dominującej polskiej treści.
• Atrybut pusty oznacza nieznany język; samo istnienie lang nie zalicza kryterium. Nazwa języka wpisana zwykłym tekstem, kodowanie UTF-8, dir, nazwa pliku i przycisk wyboru języka nie zastępują programowej informacji. und nie identyfikuje ustalonego polskiego języka tej demonstracji.
• lang dziedziczy się przez potomków, o ile go nie nadpisano. body lang nie obejmuje tekstu w head, np. tytułu. W zwykłym text/html podstawą jest lang; dla XML/XHTML trzeba uwzględnić xml:lang i sposób serwowania. W razie obu atrybutów nie dopuszczaj konfliktu. Demonstracja używa wyłącznie HTML, bez XML.
• HTTP Content-Language może opisywać odbiorców zasobu; SVR5 jest techniką doradczą. Nie traktuj samego nagłówka ani przestarzałego meta http-equiv="Content-Language" jako zamiennika H57. Fixture nie wysyła tego nagłówka, żeby nie opierać wyniku na fallbacku przeglądarki.
• Granica 3.1.2, poziom AA: język obcego fragmentu bada się osobno. Polska strona z krótkim angielskim zdaniem i html lang="pl" może spełniać badany warunek 3.1.1 mimo problemu z oznaczeniem tego zdania. Nie oznaczaj całej strony jako angielskiej, aby naprawić tylko fragment. To konieczny kontekst, bez osobnego researchu 3.1.2.
• SPA może zmieniać całą treść bez zmiany URL. Oznaczenie musi odpowiadać aktualnemu dominującemu językowi; sprawdzaj też pierwszą odpowiedź, powrót i przeładowanie. W osadzonym dokumencie HTML sprawdź jego własny korzeń; język aplikacji gospodarza nie zastępuje oznaczenia dokumentu.
• PDF16 opisuje domyślny język przez /Lang w katalogu dokumentu. PDF19 dotyczy oznaczania zakresu tekstu i wymaga sprawdzenia pokrycia/dziedziczenia; nie należy utożsamiać języka jednego akapitu z językiem całego PDF. Nazwa pliku lub język okna czytnika PDF nie są metadanymi dokumentu. Nie wykonano próby PDF.

Platformy

Domyślna podstawa: WCAG 2.2. Poza WWW użyto informacyjnej Group Note WCAG2ICT z 2025-12-11; zastępuje stronę dokumentem lub oprogramowaniem. Oprogramowanie może korzystać z ustawienia języka platformy, jeżeli rzeczywiście prezentuje UI w tym języku, albo ujawniać język inną metodą wspieraną przez technologie asystujące. Sam odczyt ustawienia bez zgodnej treści nie wystarcza.

Oddzielne mapowanie EN 301 549

To kontekst edukacyjny, nie wybór podstawy prawnej audytu. Każdy wiersz zweryfikowany przez AI 2026-10-03; test odbiornika według EN oraz przegląd człowieka NOT-RUN. Nie przenosimy warunków między wersjami ani z EN do WCAG2ICT.

W obu sprawdzonych wersjach 5.1.3.14 wiąże język mowy z prezentowaną treścią, z odrębnymi wyjątkami dotyczącymi nazw/terminów, treści zewnętrznej w językach bez wsparcia syntezatora, języka niedostępnego do wyboru niewizualnie oraz jawnego wyboru przez użytkownika innego języka mowy. Te wyjątki nie są wyjątkami WCAG 3.1.1. Zamknięte urządzenie i doświadczenie jego mowy nie były badane. „Nie dotyczy badanego scenariusza” oznacza tutaj brak zamkniętej funkcjonalności w obu własnych demonstracjach, a nie brak zastosowania 3.1.1 na platformie. Żaden wiersz nie oznacza braku odpowiednika tego kryterium.

Klasyfikacja jest edukacyjna i nie ustala obowiązków prawnych.

Rozwiązania w technologiach

<!doctype html>
<html lang="pl">
  <head>
    <meta charset="utf-8" />
    <title>Odbiór zamówienia</title>
  </head>
  <body>
    <h1>Odbiór zamówienia</h1>
    <p>Zamówienie P-104 jest gotowe.</p>
  </body>
</html>

import 'package:flutter/cupertino.dart';

Widget collectionInfo() => Semantics(
  localeForSubtree: const Locale('pl', 'PL'),
  child: const Text('Zamówienie P-104 jest gotowe.'),
);

import SwiftUI

struct CollectionInfo: View {
    var body: some View {
        Text("collection_ready")
    }
}

import UIKit

let info = UILabel()
info.text = "Zamówienie P-104 jest gotowe."
info.accessibilityLanguage = "pl-PL"

import androidx.compose.material3.Text
import androidx.compose.runtime.Composable
import androidx.compose.ui.res.stringResource

@Composable
fun CollectionInfo() {
    Text(stringResource(R.string.collection_ready))
}

import { Text } from 'react-native';

export function CollectionInfo() {
  return (
    <Text accessibilityLanguage="pl-PL">Zamówienie P-104 jest gotowe.</Text>
  );
}

Osadzony HTML w każdej z tych technologii korzysta z rozwiązania webowego we własnym dokumencie. Lokalne testy przeglądarki nie potwierdzają WebView tych frameworków. Brak buildów fragmentów edukacyjnych jest jawnym zakresem materiału, bez obowiązku tworzenia czterech aplikacji.

Jak sprawdzić

Dla głównego przykładu mobilnego ustal język treści, odczytaj odpowiadające węzły UIKit, aktywuj English/Polski i reset, przełącz wariant bez zmiany tekstu, ponownie odczytaj. Oczekuj zgodności pól z tabelą mobilną, także po cyklu i bezpośrednim wejściu; niewykonany odsłuch pozostaje osobnym krokiem. Poniższa procedura rozwija wariant webowy.

1. Ustal dominujący język aktualnej strony z treści, wliczając istotne nazwy i komunikaty, bez wnioskowania z kraju lub URL. Przy remisie zastosuj wskazówkę pierwszego języka i zapisz kontekst oceny.
2. Sprawdź informację domyślną: w HTML html[lang], w innym formacie właściwe metadane/API. Rozróżnij brak, pustą wartość, błędny tag i tag poprawny, lecz niezgodny z tekstem. Sprawdź dziedziczenie i nadpisania; język przycisku wyboru nie zalicza całej strony.
3. Zmień język całej treści, wróć, przeładuj i otwórz bezpośrednio. Oczekuj zgodności oznaczenia z każdym stanem; sprawdź pierwszą odpowiedź i DOM po renderowaniu. W demonstracji good/control/parts mają poprawny język domyślny, bad/wrong/empty/invalid odtwarzają celowy błąd.
4. Oddziel język obcych fragmentów od domyślnego języka. parts ma poprawny domyślny PL; brak oznaczenia krótkiego angielskiego zdania nie jest tu FAIL 3.1.1. Nazwy własne i numery nie uzasadniają automatycznego przełączenia języka całej strony.
5. Gdy potwierdzasz doświadczenie AT, użyj rzeczywistego czytnika, zapisz jego język/ustawienia/głosy i wynik odczytu. Oczekuj odczytu zgodnego z językiem; ten krok pozostaje NOT-RUN. Nie zastępuj go screenshotem, :lang, AX ani wygenerowanym audio.

Wyniki źródłowej próby mobilnej

Próba 2026-10-03: Flutter 3.44.9 / Dart 3.12.2, iPhone 17 Simulator / iOS 26.5, Xcode 27.0 / SDK 27.0. Ramka 402 × 874 pt, PNG 1206 × 2622 px, skala 3, pion, jasny wygląd, tekst large. Pasek 09:41 jest ustawieniem prezentacyjnym, a nie czasem przechwycenia.

Wcześniejsza rozbieżność: przy zmianie wariantu bez zmiany tekstu test widgetu widział nowy język, a natywny odbiornik zachowywał poprzedni. Pierwszy XCTest technicznie PASS sprawdzał obecność odczytu i akcje; nie był finalnym potwierdzeniem języka. Dodano ValueKey(locale.toLanguageTag()) na nadrzędnym Semantics, aby odtworzyć poddrzewo również przy zmianie samego języka. Ponowne historyczne analiza, testy, build i XCTest z asercjami natywnych języków dały wynik końcowy. Nie ustalono ogólnej przyczyny w silniku.

Wyniki wcześniejszej próby WWW

Próba 2026-10-03: Codex In-app Browser na macOS 27.0, Chrome/154.0.0.0, 1280 × 720 CSS px, DPR 1; Python 3.9.6 i Node 22.22.3. Materiał pochodzi z desktopowej przeglądarki, bez emulacji telefonu.

Weryfikacja i ograniczenia

Reguła deterministyczna wykryje brak/pustą wartość, część błędów BCP 47 i konflikty metadanych. Nie potwierdzi sama, że poprawny tag odpowiada językowi treści; wrong przechodzi samo sprawdzenie obecności i składni. ACT b5c3f8/bf051a badają określone aspekty HTML; dopasowanie języka treści w regule ucwvc8 ma status proponowany, więc nie przedstawiamy go jako zatwierdzonej automatycznej metody kompletnego audytu.

Heurystyka językowa lub AI może wskazać rozbieżność na podstawie tekstu, lecz ma ograniczenia przy krótkich treściach, podobnych językach, nazwach, transliteracji i równych proporcjach. W tej demonstracji języki ustalono z własnych pełnych tekstów PL/EN; checker odtwarza oczekiwania autora i nie jest ogólnym detektorem języka. Ocena człowieka rozstrzyga niejasny kontekst.

AX bez pola języka ani sam odczyt nazwy/roli z XCTest nie potwierdza języka. Mobilny observer UIKit rzeczywiście odczytuje accessibilityLanguage, ale jako instrument działający wewnątrz aplikacji nie zastępuje niezależnego doświadczenia czytnika. DOM daje właściwe dane autora dla H57, lecz :lang nie mierzy jakości wypowiedzi ani nie dowodzi dostępności głosu. Nie zaliczaj braku danych jako PASS i nie uznawaj dobrego odczytu uzyskanego zgadywaniem za dowód poprawnego oznaczenia. Brak testu na innej platformie nie jest jej wyłączeniem.

Mobilny observer przechodził przez rzeczywiste obiekty UIKit wewnątrz debug Runnera, odczytując accessibilityLanguage i atrybutowane etykiety, wartości oraz podpowiedzi. Nie otrzymywał locale z Dart ani nie ustawiał języka. Limit wynosił 40 poziomów/500 węzłów; finalne odczyty nie były ucięte. ensureSemantics utrzymywało strukturę, nie włączało VoiceOver. Odczyt wskazywał VoiceOver=false i preferencje en-US/pl-US; brak osobnego runu speechLanguage nie oznacza braku języka, gdy element ma właściwe accessibilityLanguage. Odczyty warstw są sekwencyjne.

Dawny checker WWW ściśle wiąże pierwotny draft i wspólny kod; późniejsze korekty źródeł zgłasza jako drift. Checker mobilny zachowuje integralność wcześniejszych mediów i odczytów, bez utożsamienia WWW z mobile i bez powtórzenia UI. Przegląd interpretacji przez człowieka oraz rzeczywista wymowa PL → EN → PL w czytniku pozostają NOT-RUN.

Jak sprawdza Clearship

Clearship na Androidzie porównuje język rozpoznawalnych tekstów ekranu z programowym językiem odczytanym z zakresów LocaleSpan, ustawienia aplikacji i systemu. Metoda language-2 działa deterministycznie, bez AI. Wskazuje niezgodność domyślnego języka, gdy niezgodne akapity obejmują co najmniej połowę liter analizowanej treści. Ta reguła techniczna nie jest procentowym progiem WCAG.

Pomiar kontrolny Androida z 8 października 2026 r. spełnił próg metody: 6/6 usterek i 0 fałszywych alarmów na 739 poprawnych ekranach. Jednostką analizy jest zbadany ekran, nie cały program. Tekst krótszy niż rozpoznawalny akapit, język spoza obsługiwanych 60 języków, brak sygnału, sprzeczne dane i pominięte stany wymagają dalszej oceny.

Metoda nie bada języka dokumentu WWW w WebView, cyklu zmiany języka, tekstu w obrazach, wartości pól ani podpowiedzi. Węzeł bez zakresu obok węzłów z zakresami może mieć niepewny język i trafia do człowieka. Na iOS sonda XCUITest nie dostarcza informacji języka; wynik jest poniżej progu i wymaga człowieka. Wewnętrzny observer UIKit edukacyjnej demonstracji nie jest sondą aplikacji klienta ani testem VoiceOver.

Powiązane kryteria

• 3.1.2
  Język części treści

  Odmienny język fragmentu oznacza się osobno od języka całej strony.

• 2.4.2
  Tytuł strony

  Tytuł opisuje stronę, lecz jego tekst nie zastępuje metadanych języka.