Zmiana rozmiaru tekstu

Co oznacza to kryterium

Użytkownik powinien móc powiększyć tekst dwukrotnie, przeczytać potrzebną informację i wykonać te same czynności. Dotyczy to również etykiet, przycisków, placeholderów i wpisanych danych. Układ może rosnąć i wymagać przewijania; istotna treść nie powinna znikać za krawędzią.

Pomaga to osobom słabowidzącym czytać bez specjalnego powiększalnika. Wyjątki obejmują captions i obrazy tekstu. Rozmiar wizualnego tekstu jest osobnym zagadnieniem niż jego dostępna nazwa.

Przykłady błędów i poprawek

Pełna instrukcja przy 200%

Pracownia używa P-104 i tych samych zdań: „Punkt otwarty do 18:00. Odbiór przy wejściu od ogrodu.” Good pozwala akapitowi rosnąć. Bad ogranicza go do dwóch wierszy z wielokropkiem, bez drogi do reszty instrukcji.

Control ma ten sam limit, lecz widoczny przycisk „Pokaż pełną informację” usuwa go. To kontrola granicy: skrócenie może być dopuszczalne, gdy pełna informacja jest rzeczywiście osiągalna i interfejs wskazuje tę możliwość.

Surowe PNG iOS pochodzą z końcowej próby. Pełna treść poniżej kadru wymaga zwykłego przewinięcia. Nie ustalaj wielkości fontu z etykiety „200%” ani dostępności podglądu z samej ramki przycisku.

Karta o stałej wysokości na WWW

Good ma naturalną wysokość. Bad/control ograniczają obszar informacji do 48 px i overflow:hidden; control pozwala rozwinąć kartę. Pole notatki, Ogrod, podgląd adresu i reset działają we wszystkich wariantach.

To rzeczywiste wykonanie własnego CSS html.fontSize, bez zoomu przeglądarki. Bad wykazuje błąd badanego mechanizmu. Ponieważ nie sprawdzono innych wspieranych sposobów powiększenia, nie stanowi końcowej oceny całej strony według 1.4.4.

Pozostałe błędy i poprawki

Kiedy obowiązuje i gdzie są wyjątki

• Żywy tekst pozostaje w zakresie, również przyciski, pola i treść pomocnicza. Nie przenoś tu wyjątku 1.4.3 dla nieaktywnej kontrolki. Wyjątki tego kryterium to captions i obrazy tekstu.
• 200% oznacza podwojenie rozmiaru tekstu, bez technologii asystującej. Poszerzenie okna lub sam resize viewportu nie dowodzą powiększenia fontu.
• Dla WWW wystarczy co najmniej jeden prawidłowy, wspierany mechanizm bez utraty treści i funkcji. Jeśli ma kroki pośrednie, sprawdź również je. Błąd text-only nie przesądza błędu całego kryterium, gdy pełny zoom działa poprawnie.
• UI kontrolowany przez samą platformę lub odbiornik, np. jego tooltip czy wybór pliku, nie jest autorską treścią tego wymagania. To granica odpowiedzialności za dany element.
• Breakpoint i zmniejszanie fontu nie mogą uniemożliwiać osiągnięcia dwukrotnego rozmiaru względem prezentacji bazowej.
• Przewijanie samo w sobie nie oznacza utraty funkcji. 1.4.4 nie wymaga 320 CSS px, 400% ani zakazu przewijania w dwóch wymiarach; te warunki należą do innych kryteriów.
• Przy skróceniu pełna treść musi być dostępna po fokusie lub aktywacji i mieć wyraźną drogę ujawnienia. Wielokropek, pełny aria-label/AX i tooltip nieosiągalny danym wejściem nie wystarczają.

Techniki G142/G178/G179, C28 oraz pomocnicze C12/C13/C14, SCR34/G146 i C17 opisują możliwe rozwiązania. F69/F80/F94 opisują określone błędy. Nie narzucają jednej jednostki, biblioteki czy mechanizmu.

Platformy

Interpretacja AI z 2026-10-04 dla software dopuszcza 200% albo możliwości skalowania platformy, jeśli platforma je ma, lecz nie wszystkie typy tekstu osiągają 200%. Aplikacja musi z nimi współpracować, zachować informację, funkcje i semantyczne znaczenie różnic wielkości. To nie pozwolenie na własny dowolny limit, np. 130%. Gdy platforma nie zapewnia potrzebnego mechanizmu, rozważ własne skalowanie.

Demonstracja bada odrębny mechanizm aplikacji do 200%, bez potwierdzenia całego Dynamic Type. WebView oceniaj jak WWW, natywną otoczkę osobno. WCAG2ICT jest informacyjną interpretacją; brak testu nie wyłącza platformy. Nie ustalano EN 301 549 ani obowiązku prawnego.

Rozwiązania w technologiach

Dokumentację API sprawdzono 2026-10-04. Fragmenty poniżej są edukacyjne: nie budowano osobnych aplikacji ani zależności. Nie tłumaczą automatycznie dowodu Fluttera na wynik SwiftUI, Compose lub React Native.

import 'package:flutter/cupertino.dart';

Widget pickupInformation() => SingleChildScrollView(
  child: Column(crossAxisAlignment: CrossAxisAlignment.stretch, children: [
    const Text('Punkt otwarty do 18:00. Odbiór przy wejściu od ogrodu.'),
    const Text('Notatka do odbioru'),
    const CupertinoTextField(minLines: 2, maxLines: null),
  ]),
);

import SwiftUI

struct PickupInformation: View {
    @State private var note = ""
    var body: some View {
        ScrollView {
            VStack(alignment: .leading, spacing: 16) {
                Text("Punkt otwarty do 18:00. Odbiór przy wejściu od ogrodu.")
                    .font(.body)
                    .fixedSize(horizontal: false, vertical: true)
                TextField("Notatka do odbioru", text: $note)
                    .font(.body)
                Button("Pokaż adres") { /* normalna akcja aplikacji */ }
            }.padding()
        }
    }
}

import androidx.compose.foundation.layout.Column
import androidx.compose.foundation.rememberScrollState
import androidx.compose.foundation.verticalScroll
import androidx.compose.material3.Text
import androidx.compose.runtime.Composable
import androidx.compose.ui.Modifier
import androidx.compose.ui.unit.sp

@Composable
fun PickupInformation() {
    Column(Modifier.verticalScroll(rememberScrollState())) {
        Text(
            "Punkt otwarty do 18:00. Odbiór przy wejściu od ogrodu.",
            fontSize = 17.sp
        )
    }
}

import React, { useState } from 'react';
import { ScrollView, Text, TextInput } from 'react-native';

export function PickupInformation() {
  const [note, setNote] = useState('');
  return (
    <ScrollView>
      <Text allowFontScaling maxFontSizeMultiplier={0}>
        Punkt otwarty do 18:00. Odbiór przy wejściu od ogrodu.
      </Text>
      <Text>Notatka do odbioru</Text>
      <TextInput
        value={note}
        onChangeText={setNote}
        multiline
        allowFontScaling
      />
    </ScrollView>
  );
}

<label for="note">Notatka do odbioru</label>
<textarea id="note"></textarea>
<style>
  html {
    font-size: 100%;
  }
  p,
  label,
  button,
  textarea {
    font-size: 1rem;
    line-height: 1.5;
  }
  textarea {
    width: 100%;
    box-sizing: border-box;
    min-height: 3em;
  }
  .information {
    height: auto;
    overflow-wrap: anywhere;
  }
</style>

Jak sprawdzić

1. Ustal tekst poza wyjątkami, platformę i dostępne mechanizmy. Zapisz bazowe fonty, dane i stan formularza.
2. W wybranym mechanizmie przejdź wszystkie dostępne kroki do 200%. Jeśli oceniasz współpracę z OS, zmień rzeczywiste ustawienie platformy, a nie tylko parametr demonstracji.
3. Odczytaj osiągnięty rozmiar, sprawdź obcięcie, nachodzenie i zasłonięcie. Przewiń i użyj dostępnego ujawnienia pełnej informacji. Obecność w drzewie oceniaj osobno od widoczności.
4. Wpisz notatkę, pokaż adres, zmniejsz tekst i zresetuj. Oczekuj pełnych danych i tego samego działania w powiększeniu.
5. Jeżeli jedna metoda zawodzi, sprawdź inne wspierane metody przed oceną całego kryterium. Zapisz wynik konkretnego mechanizmu.

Historyczne wyniki z 2026-10-04

Cztery wcześniejsze iOS FAIL i dwa hostowe FAIL zachowano w researchu. Początkowa geometria hostowego fontu różniła się od oczekiwań; pierwsza próba iOS ujawniła też placeholder poza polem. Kolejne próby nie potwierdziły aktywacji przycisku mimo widocznej ramki. Dopiero v5 z oczekiwaniem na ustanie ruchu po normalnych wejściach ukończył scenariusz.

Pierwsza szerokość WWW 42rem rosła razem z fontem i nie wykazała bariery. Po wspólnej zmianie na max 672 px bad ją ujawnił. Pierwszy końcowy zapis miał pustą tablicę odczytów; końcowe dane pochodzą z powtórzonego rzeczywistego przebiegu, nie z dopisanego wyniku. Nieustalone silnik/DPR WWW i rozmiary JPEG nie są dowodem zoomu.

Weryfikacja i ograniczenia

ACT b4f0c3 sprawdza ograniczenia meta viewport, a nie pełną zdolność użycia strony. Alternatywny mechanizm i zachowanie przeglądarki mogą zmienić ocenę założeń. Sprawdzone w researchu ACT 59br37 miało status PROPOSED i badało określone obcięcia przy kontrolowanym viewporcie; resize nie mierzy rzeczywistego zoomu. Nie wykonano silnika ACT.

Pełny tekst w AX dowodzi obecności semantycznej. didExceedMaxLines rozpoznaje limit, ale nie wszystkie klipy rodzica lub nachodzenie placeholdera. RenderParagraph/Editable pokazują geometrię Fluttera, bez pomiaru UIKit i odczytu AT. scrollHeight>clientHeight z overflow hidden daje kandydata dla prostej karty, bez ogólnego algorytmu transformacji i nakładek. Dane renderera i obraz są sekwencyjne; stara ramka po przewinięciu nie jest aktualną pozycją na PNG.

Jak sprawdza Clearship

Clearship porównuje drzewo i zrzuty tego samego ekranu przed zmianą systemowej wielkości tekstu i po niej. Metoda text-resize-3 szuka braku powiększenia, obcięcia, ukrycia, nakładania i utraty kontrolki; skalę szacuje z wysokości wierszy atramentu zamiast przyjmować ją z nazwy ustawienia. Dostępną drogę ujawnienia rozpoznaje tylko w zapisanych przejściach.

Android spełnił próg pomiaru, ale wynik wymaga ostrożności: kierunek zmian między próbami wybrano również po liczbach zestawu kontrolnego, więc pozostaje otwarta decyzja o niezależnym ponownym pomiarze. iOS jest poniżej progu i wymaga człowieka. Porównanie obejmuje jeden poziom OS, bez kroków pośrednich, własnych mechanizmów, pełnej oceny hierarchii i działania wszystkich kontrolek. P2 nie przewija, więc treść poza widocznym obszarem nie jest zbadana. Ustawienie Androida 2.0 nie oznacza dwukrotnego rozmiaru każdego fontu. Brak kandydata nie potwierdza wszystkich mechanizmów.

Powiązane kryteria

• 1.4.10
  Dopasowanie treści

  Reflow bada wąski obszar i przewijanie w dwóch wymiarach, bez zastępowania warunku 200% tekstu.

• 1.4.5
  Obrazy tekstu

  Wyłączenie obrazów tekstu z powiększania nie zwalnia z ich zastąpienia tekstem.

• 1.4.12
  Odstępy w tekście

  Zmiany odstępów mają osobny zakres i sposób sprawdzenia.