Określenie przeznaczenia pola

Co oznacza to kryterium

Znaczenie pola, np. „pełne imię i nazwisko” albo „adres e-mail”, powinno być dostępne dla oprogramowania bez zgadywania z polskiej etykiety. Dotyczy to określonych informacji o osobie korzystającej z formularza, jeżeli technologia obsługuje ich oznaczanie.

Ustalony cel może umożliwiać znajome symbole i personalizację osobom z trudnościami pamięci lub koncentracji. Może też ograniczyć wpisywanie danych osobom z ograniczeniami ruchowymi. Research nie potwierdza rzeczywistego autofill; dostępna nazwa dla czytnika i purpose są różnymi informacjami.

Przykłady błędów i poprawek

W Pracowni użytkownik wpisuje swoje pełne imię i nazwisko oraz e-mail do zamówienia P-104. Para good/bad ma te same widoczne etykiety, typy klawiatury, puste pola i podgląd. Jedyna istotna różnica pary: good deklaruje właściwe hints/tokeny; bad ich nie deklaruje. Oznaczenie wariantu należy do fixture. Dane wpisywane w testach to Ala Przykladowa i ala@example.invalid; nie korzystano z rzeczywistych profili/kont.

H98 jest wystarczającą techniką dla właściwych pól HTML, nie normatywnym nakazem używania jednego atrybutu w każdej technologii. F107 opisuje błędne wartości przy braku innej metody przekazania purpose. Nie twierdzimy, że te przykłady są najczęstsze.

Rzeczywisty JPEG IAB/macOS: good przed wpisaniem. Obraz daje kontekst; tokeny potwierdza DOM.

Rzeczywisty JPEG: bad przed wpisaniem; podobny wygląd i czytelne etykiety nie ujawniają braku purpose.

Rzeczywisty JPEG: control przed wpisaniem, celowo inny kontekst właściciela danych. Wszystkie trzy obrazy obejrzano przez AI; bez retuszu i bez generacji AI.

Natywny kontekst tych samych danych

Końcowy obraz pochodzi z próby XCTest PASS. Niewidoczny content type potwierdzają osobne, świeże gettery UIKit; podobny wygląd bad nie ujawnia braku celu. Kontrola zbiera dane innej osoby.

Kiedy obowiązuje i gdzie są wyjątki

Trzy przesłanki należy rozpatrywać łącznie: informacje są o użytkowniku treści, cel odpowiada pozycji normatywnej listy, a technologia obsługuje oznaczanie oczekiwanego znaczenia. „Wpisane przez użytkownika” nie oznacza „o użytkowniku”. Wyszukiwanie produktu, komentarz i dane osoby upoważnionej nie stają się takim polem tylko dlatego, że ktoś wpisuje je z klawiatury.

Lista obejmuje m.in. tożsamość i części nazwiska, konto/hasła, organizację i stanowisko, adres z częściami, kontakt, płatność i preferencje. Pełną listę odczytano; demonstracja wykorzystuje tylko name i email. street-address i address-line1 nie są zamienne przy różnych strukturach adresu; bday to data urodzenia, nie dowolna data. Nazwy celów WCAG opisują znaczenia — równoważne API innej technologii nie muszą używać tych samych literalnych tokenów. HTML przy użyciu H98 wymaga własnych prawidłowych tokenów, np. bday, a nie wymyślonego birthday.

Nawet pozycje takie jak transaction-amount wymagają ustalenia, że chodzi o informacje o użytkowniku; obecność nazwy na liście nie rozszerza zakresu na każde pole transakcji. one-time-code i końcowy token webauthn występują w nowszym HTML/API, lecz nie są automatycznie dodatkowymi celami normatywnej listy WCAG 2.2.

Przez pole wejściowe rozumiemy również właściwe select/textarea, nie tylko tag input. Programowe znaczenie pochodzi z danych autora dostępnych dla odbiorników i różnych sposobów prezentacji. Etykieta, accessibility name, type="email", keyboardType, placeholder i ID opisujące implementację same nie zastępują wyspecjalizowanego purpose. Heurystyczne rozpoznanie formularza przez menedżer danych także nie jest jego deklaracją.

Understanding dopuszcza dla pola łączącego dwa cele, np. login lub e-mail, jeden cel albo brak oznaczenia, gdy użyta technologia nie obsługuje wielu znaczeń. To konkretny przypadek wieloznacznego pola; nie uzasadnia pomijania purpose dla osobnego pola e-mail. W Compose można obecnie łączyć ContentType; w iOS jedna właściwość UITextContentType nie przyjmuje zestawu, a Flutter na iOS wykorzystuje pierwszy hint.

Wyłączenie lub brak działania autofill nie dowodzi braku purpose. W WWW form autocomplete="off" może współistnieć z indywidualnymi tokenami pól; w badanym DOM są one odczytywalne. Wartości on, off lub pusty atrybut same nie określają znaczenia. Brak celu poza normatywną listą albo brak obsługi w technologii jest granicą warunku, a nie błędem wymagającym dowolnych wymyślonych metadanych.

Platformy

Każdy wiersz: odczyt i interpretacja AI 2026-10-04, człowiek NOT-RUN. WCAG2ICT to Group Note z 2025-12-11, informacyjna interpretacja poza treścią webową. Nie jest podstawą deklaracji obowiązków prawnych lub zgodności z EN 301 549.

Nie dotyczy badanego scenariusza: control zbiera imię i e-mail osoby trzeciej. Brak purpose w tej kontrolce nie narusza 1.3.5 przy opisanym kontekście; inne wymagania formularza nadal obowiązują.

Rozwiązania w technologiach

<label for="email">E-mail</label>
<input id="email" name="email" type="email" autocomplete="email" />

import 'package:flutter/cupertino.dart';
import 'package:flutter/services.dart';
// W build, wewnątrz AutofillGroup; widoczna i powiązana etykieta osobno.
CupertinoTextField(
  keyboardType: TextInputType.emailAddress,
  autofillHints: const [AutofillHints.email],
);

import SwiftUI
struct ContactField: View {
  @State private var email = ""
  var body: some View {
    TextField("E-mail", text: $email)
      .keyboardType(.emailAddress)
      .textContentType(.emailAddress)
  }
}

import androidx.compose.material3.TextField
import androidx.compose.runtime.Composable
import androidx.compose.ui.Modifier
import androidx.compose.ui.autofill.ContentType
import androidx.compose.ui.semantics.contentType
import androidx.compose.ui.semantics.semantics

@Composable
fun ContactEmail(value: String, onChange: (String) -> Unit) {
    TextField(value = value, onValueChange = onChange,
        modifier = Modifier.semantics { contentType = ContentType.EmailAddress })
}

import React, { useState } from 'react';
import { Text, TextInput, View } from 'react-native';
export function ContactEmail() {
  const [email, setEmail] = useState('');
  return (
    <View>
      <Text>E-mail</Text>
      <TextInput
        accessibilityLabel="E-mail"
        value={email}
        onChangeText={setEmail}
        keyboardType="email-address"
        autoCapitalize="none"
        autoComplete="email"
      />
    </View>
  );
}

Jak sprawdzić

1. Ustal właściciela danych z kontekstu procesu; sama nazwa pola nie wystarcza. Przypisz zamierzone znaczenie do listy i zbadaj możliwości technologii.
2. W WWW odczytaj rzeczywisty atrybut i właściwość DOM po renderze, powiązanie etykiety i typ. Sprawdź gramatykę tokenów i zgodność z celem. Porównaj good/bad/control, wpisz te same dane, pokaż podgląd, przełącz i zresetuj. Form off nie usuwa indywidualnych metadanych.
3. W Flutterze odczytaj deklaracje oraz komunikat TextInput.setClient w hostowym teście. To kontrakt/mocked platforma, nie rzeczywisty iOS content type.
4. Na wskazanym iOS Simulator zainstaluj świeży Runner.app, uruchom każdą trasę, dotknij każdego pola i odczytaj getter aktywnego natywnego firstResponder. Oczekiwane: raw name/email (stałe UIKit .name/.emailAddress) w good, brak celowego purpose w bad/control, ta sama klawiatura w odpowiadających sobie polach. Porównaj świeżość native snapshot, wpisz dane przez XCTest, pokaż podgląd, sprawdź cykl, reset i fallback.
5. Osobno zbadaj odbiornik purpose: personalizację AT lub systemowe podpowiedzi z wyłącznie syntetycznym profilem. Tego sprawdzenia nie wykonano; reakcja OS nie jest tutaj deklarowanym warunkiem zaliczenia DOM, a granica interoperacyjności natywnej pozostaje jawna.

Weryfikacja i ograniczenia

Historyczne wykonanie z 2026-10-04 rozdziela deklaracje autora, mock kanału, odczyt UIKit i rzeczywisty odbiornik purpose.

Finalna obserwacja natywna była osobnym kanałem debug na Simulatorze, bez setterów, żądania fokusu i uruchamiania callbacków przez obserwatora. JSON przeniesiony do value narzędzia nie jest ekspozycją purpose dla VoiceOver. Świeżość gettera, marker purpose-v4-20261004, obliczone oczekiwania SDK, odrębny bundle ID, jawny xctestrun oraz pełne hashe wiążą końcowy wynik z wersją. Nie przenosi się tego sposobu obserwacji do dowolnej aplikacji klienta.

Wcześniejsze próby pozostają nieudane: host mylił klucz hints i konfigurację platformy; driver mylił typ klawiatury nazwiska oraz raw email z nazwą symbolu emailAddress. Trzecia próba wykonywała stare oczekiwanie mimo aktualnego źródła i zgodnych manifestów; przyczyna pozostała nieustalona. Same hashe nie potwierdzają załadowanego kodu. Finalny PASS nie zmienia tej historii; wcześniejsze obrazy good nie potwierdzają purpose ani zaliczenia prób. Startupy przerwane przed testcase i ograniczona rekonstrukcja pierwszej wersji również pozostają ograniczeniami.

ACT 73f2c2 bada składnię istniejącego autocomplete. Brak atrybutu albo on/off może być poza jej celami; PASS lub inapplicable nie potwierdza 1.3.5. Poprawny syntaktycznie token może mieć złe znaczenie. AX label/value i screenshot nie pokazują celu pola. AI nie powinna zgadywać właściciela danych z każdej etykiety name/email. UIKit getter i mock potwierdzają inne etapy mostu, bez pełnej interoperacyjności AT. Checker własnych oczekiwań nie jest zaślepionym walidatorem; niezależny walidator i człowiek pozostają NOT-RUN.

Jak sprawdza Clearship

Clearship rozpoznaje cel i właściciela danych z etykiet oraz tekstu ekranu. Na Androidzie porównuje je z hints odczytanymi przez testową usługę autouzupełniania sondy. Sygnał autofill-1 zbiera deklaracje, a nie wypełnia dane użytkownika. Brak żądania dla pola, niejasny cel lub podmiot trafia do człowieka.

Metoda input-purpose-1 spełniła próg pomiaru kontrolnego Androida w opisanym zakresie. Katalog nadal określa całą ocenę jako wymagającą człowieka. Na iOS sonda produktu nie ma sygnału textContentType; wynik kontrolny jest poniżej progu. Getter debug własnej demonstracji nie jest tą sondą. Nie badamy skuteczności autofill, wartości pól, autocomplete w WebView ani znaczenia całego procesu przez sam słownik. Brak sygnału nie potwierdza poprawnego purpose.

Powiązane kryteria

• 3.3.2
  Etykiety lub instrukcje

  Etykieta i instrukcja dla osoby są odrębne od programowego purpose.

• 4.1.2
  Nazwa, rola, wartość

  Nazwa, rola i wartość kontrolki są odrębnymi informacjami.

• 3.3.7
  Ponowne wprowadzanie danych

  Ponowne użycie danych w procesie nie jest tym samym co cel pola lub autofill.