# Accessibilità delle pagine ospitate

Le pagine di accesso ospitate, il portale account e le pagine email di KeenAuth sono progettate per rispettare WCAG 2.2 livello AA. Questo è un obiettivo di progettazione, non una certificazione: lo verifichiamo in modo automatico, e questa pagina descrive cosa è coperto e cosa non lo è ancora.

## Cosa offrono le pagine

- **Etichette ed errori.** Ogni campo di input ha un `<label>` visibile associato. I messaggi di errore vengono comunicati agli screen reader come avvisi.
- **Tastiera.** I controlli sono elementi di form nativi, e il focus è mostrato con un contorno visibile nel colore `color.focus_ring` del tuo progetto.
- **Lingua e direzione.** Le pagine riportano gli attributi `lang` e `dir` della lingua scelta. Arabo, persiano ed ebraico sono impaginati da destra a sinistra. Vedi [Lingue e da destra a sinistra](/docs/guides/localization).
- **Schermi piccoli.** Le pagine si riadattano fino a un viewport largo 320 px senza scorrimento orizzontale.
- **Chiaro e scuro.** Entrambi i temi sono testati separatamente.
- **Password.** Le pagine ospitate non bloccano l'incolla, e i campi hanno valori `autocomplete` così che i gestori di password funzionino.

## Come testiamo

Una suite automatica apre le pagine ospitate e verifica, per ogni pagina, nel tema chiaro e in quello scuro, in ogni lingua supportata (30), a larghezze di 320 px e 1280 px:

- le regole axe-core per WCAG 2.0, 2.1 e 2.2 livelli A e AA, senza violazioni accettate;
- nessuno scorrimento orizzontale;
- direzione da destra a sinistra dove una lingua la richiede, e un confronto di screenshot per l'arabo;
- un percorso solo da tastiera nella pagina di accesso: Tab raggiunge il campo identificativo e poi il pulsante Continua, e Invio invia il form.

Ogni eccezione accettata viene documentata con un motivo e scade entro 90 giorni.

### Cosa non è ancora coperto

- Il portale account, le pagine di errore e di disconnessione e i componenti React incorporabili non fanno ancora parte della suite automatica.
- Il test manuale con gli screen reader (NVDA, VoiceOver) non è ancora stato eseguito.
- I template email non sono ancora stati sottoposti a verifica di accessibilità.
- I controlli automatici trovano solo una parte dei possibili problemi. Alcuni rilievi sono ancora in fase di correzione.

## Protezione del contrasto del brand

I colori del tuo brand non possono rendere illeggibile una pagina ospitata. Quando salvi il branding, KeenAuth verifica queste coppie, separatamente per il tema chiaro e per quello scuro:

| Coppia | Rapporto minimo |
|---|---|
| Testo su sfondo | 4.5:1 |
| `color.link` su sfondo | 4.5:1 |
| `color.primary_contrast` su `color.primary` | 4.5:1 |
| Bordo del controllo su sfondo | 3:1 |
| Anello di focus su sfondo | 3:1 |

Una coppia sotto il minimo viene rifiutata con `422 brand_contrast_insufficient`. L'errore indica il campo e suggerisce il colore più vicino che passa; il suggerimento mantiene tonalità e croma e modifica solo la luminosità. Un branding che non passa non può essere pubblicato. Dettagli e formato dell'errore sono in [Personalizza le tue pagine di accesso](/docs/guides/branding).

Il CSS personalizzato (piano Startup) può ridurre il contrasto, e KeenAuth non lo corregge. Una scansione di anteprima segnala i problemi come avvisi, e l'accessibilità delle modifiche fatte con CSS personalizzato è di tua responsabilità.

## Correlati

- [Personalizza le tue pagine di accesso](/docs/guides/branding)
- [Lingue e da destra a sinistra](/docs/guides/localization)
- [SDK React](/docs/sdk/react)