Formularis, teclats i autenticació accessible a les aplicacions

Donar-se d'alta, iniciar la sessió, demanar una cita, signar una operació, pagar: gairebé totes les tasques crítiques d'una aplicació passen per un formulari. Al mòbil, a més, s'escriu amb un teclat en pantalla que tapa mitja interfície, es copien codis que arriben per SMS i es combinen contrasenyes, biometria i gestors de credencials. Al curs de formularis web del nivell 3 vas veure els fonaments (etiquetes, errors, autocomplete, 3.3.7 i 3.3.8). Aquesta lliçó els trasllada a les API natives d'iOS, Android i els frameworks multiplataforma, amb els errors que més es repeteixen a les aplicacions de banca, administració i comerç electrònic.

Etiquetes visibles i persistents

El patró més estès al mòbil és el camp amb placeholder (text d'exemple dins del camp) com a única etiqueta. En escriure, el text desapareix i la persona amb problemes de memòria o d'atenció ja no sap quin camp està emplenant; a més, el placeholder sol tenir poc contrast. Pot incomplir el 3.3.2 Etiquetes o instruccions tan bon punt el camp té contingut, i sovint l'1.4.3 Contrast (mínim).

• Android: TextInputLayout amb android:hint (Views) o el paràmetre label d'OutlinedTextField a Compose Material 3; tots dos converteixen el text en una etiqueta flotant que continua visible i s'exposa com a nom accessible. El paràmetre placeholder és només un exemple addicional.
• iOS: col·loca una etiqueta visible a sobre del camp i assigna-la com a accessibilityLabel de l'UITextField; a SwiftUI, combina un Text visible amb TextField i aplica .accessibilityLabel si el títol del camp no coincideix amb l'etiqueta visible.
• Coherència amb l'etiqueta visible: el 2.5.3 Etiqueta en el nom exigeix que el nom accessible contingui el text visible. Si es veu «Codi postal», el nom no pot ser «CP» ni «camp 4»; Voice Control i Accés per veu en depenen.

Tipus de teclat i propòsit de l'entrada

Triar el teclat adequat no és un criteri WCAG per si mateix, però redueix els errors i l'esforç per a tothom: teclat numèric per al codi postal, de correu per a l'adreça electrònica, de telèfon per al mòbil. Més important és el criteri 1.3.5 Identificació del propòsit de l'entrada (AA): els camps que demanen dades de la mateixa persona n'han d'exposar el propòsit de manera que el sistema els pugui emplenar automàticament. A les aplicacions, WCAG2ICT l'interpreta per mitjà dels mecanismes d'emplenament automàtic de la plataforma.

// iOS (UIKit)
correoField.keyboardType = .emailAddress
correoField.textContentType = .emailAddress
cpField.keyboardType = .numberPad
cpField.textContentType = .postalCode

// SwiftUI
TextField("Correu electrònic", text: $correo)
    .keyboardType(.emailAddress)
    .textContentType(.emailAddress)
    .textInputAutocapitalization(.never)

// Android (Views, XML)
<EditText
    android:id="@+id/correo"
    android:inputType="textEmailAddress"
    android:autofillHints="emailAddress" />

// Compose (les versions recents exposen el tipus de contingut com a semàntica)
OutlinedTextField(
    value = correo, onValueChange = { correo = it },
    label = { Text("Correu electrònic") },
    keyboardOptions = KeyboardOptions(keyboardType = KeyboardType.Email, imeAction = ImeAction.Next),
    modifier = Modifier.semantics { contentType = ContentType.EmailAddress }
)

// React Native
<TextInput autoComplete="email" textContentType="emailAddress" keyboardType="email-address" />

// Flutter
TextField(autofillHints: const [AutofillHints.email], keyboardType: TextInputType.emailAddress)

Fes servir també imeAction o returnKeyType («Següent», «Fet») perquè la tecla de retorn avanci al camp següent en l'ordre lògic, i desactiva la correcció automàtica als camps on fa nosa (noms, NIF, IBAN).

Errors: identificar-los, descriure'ls i portar-hi

Els criteris són els mateixos que al web: 3.3.1 Identificació d'errors, 3.3.3 Suggeriments davant d'errors i, per als missatges que apareixen sense moure el focus, 4.1.3 Missatges d'estat. El que canvia és l'API:

• Compose: OutlinedTextField(isError = true, supportingText = { Text("Introdueix un NIF amb 8 números i una lletra") }) i Modifier.semantics { error("NIF no vàlid") } perquè TalkBack anunciï l'error en arribar al camp.
• Views: textInputLayout.error = "Introdueix un NIF amb 8 números i una lletra"; el component mostra el text i l'exposa al servei d'accessibilitat.
• iOS: el missatge d'error és un text visible al costat del camp; inclou-lo a l'accessibilityValue o l'accessibilityHint del camp i, en enviar, anuncia el nombre d'errors i porta el focus al primer (ho vas veure a l'exemple de la lliçó d'iOS).

Valida en enviar o en sortir del camp, no a cada pulsació: un missatge d'error que salta mentre algú escriu amb el lector de pantalla interromp constantment la lectura. I no indiquis mai l'error només amb una vora vermella (1.4.1 Ús del color) ni només amb una vibració: la vibració és un bon senyal addicional, mai l'únic (1.3.3 Característiques sensorials).

Entrada redundant i processos de diversos passos

El 3.3.7 Entrada redundant (A) demana que, dins d'un mateix procés, no s'exigeixi tornar a escriure informació ja aportada: s'emplena automàticament o s'ofereix per seleccionar-la. En una aplicació d'enviaments, l'adreça de facturació ofereix «Fes servir l'adreça de lliurament»; en un tràmit de diversos passos, el NIF del pas 1 no es torna a demanar al pas 4. Les excepcions (tornar a escriure una contrasenya per seguretat, per exemple) són limitades.

En els processos de diversos passos, anuncia el pas actual amb el títol de la pantalla («Pas 2 de 4: dades de contacte»), conserva les dades en retrocedir i permet revisar abans de confirmar operacions amb efectes econòmics o legals (en aquesta línia va el criteri 3.3.4 Prevenció d'errors (legals, financers, dades)).

Autenticació accessible

El criteri 3.3.8 Autenticació accessible (mínim) (AA) prohibeix que un pas d'inici de sessió depengui d'una prova de funció cognitiva (recordar una contrasenya, transcriure un codi, resoldre un trencaclosques) llevat que hi hagi una alternativa o un mecanisme d'ajuda. En una aplicació, això es tradueix en:

1. Permetre els gestors de contrasenyes i enganxar: marca els camps amb .username i .password (o .newPassword a l'alta) a iOS, i amb autofillHints username i password a Android. No bloquegis l'enganxament en cap camp de credencials.
2. Oferir biometria o claus d'accés: Face ID, Touch ID o l'empremta (BiometricPrompt) i les passkeys (claus d'accés, que iOS i Android integren al sistema i Android gestiona amb Credential Manager) eviten memoritzar. Però la biometria no pot ser l'única via: hi ha persones que no la poden fer servir.
3. Codis d'un sol ús que s'emplenen automàticament: textContentType = .oneTimeCode a iOS suggereix el codi rebut per SMS sobre el teclat; a Android, la pista smsOTPCode d'emplenament automàtic o les API d'SMS Retriever i SMS User Consent permeten emplenar-lo sense transcriure'l.
4. Temps suficient: si el codi caduca, avisa'n i permet demanar-ne un altre sense perdre el que s'ha fet (2.2.1 Temps ajustable).
5. Sense CAPTCHA cognitiu: si cal protecció contra abusos, fes servir mecanismes que no exigeixin reconèixer imatges ni desxifrar caràcters (el 3.3.8 admet com a excepció el reconeixement d'objectes, però el 3.3.9, de nivell AAA, no).

Selectors, dates i camps especials

• Prefereix els selectors natius (UIDatePicker, DatePicker de Material 3): són accessibles i, a més, permeten escriure la data. Un calendari a mida exigeix la feina de la lliçó d'Android: cada dia amb el nom complet, l'estat i el rol.
• Els camps de contrasenya amb un botó «Mostra» necessiten nom i estat en aquest botó («Mostra la contrasenya», desactivat).
• Les caselles de condicions i privadesa han de ser controls reals (Toggle, Checkbox o Modifier.toggleable), amb el text associat com a etiqueta i un objectiu tàctil de 48 dp o 44 pt que inclogui aquest text.
• Comprova que el teclat en pantalla no tapa el camp actiu ni el botó d'enviar (2.4.11 Focus no ocult (mínim)); a Android, ajusta el comportament amb windowSoftInputMode o els insets del teclat a Compose.

Resum

• Etiquetes visibles i persistents, mai només un placeholder; el nom accessible conté el text visible (2.5.3).
• Teclat adequat i propòsit de l'entrada exposat amb textContentType (iOS), autofillHints (Android i Flutter), contentType (Compose) o autoComplete (React Native) (1.3.5).
• Errors en text, associats al camp, anunciats i amb un suggeriment de correcció (3.3.1, 3.3.3, 4.1.3); mai només color o vibració.
• No demanis dues vegades el mateix en un procés (3.3.7) i conserva les dades en retrocedir.
• Autenticació sense proves de memòria (3.3.8): gestors de contrasenyes, enganxament, biometria amb alternativa, claus d'accés i codis que s'emplenen automàticament en un únic camp.