Sticky header e accessibilità: quando la barra fissa nasconde proprio ciò che stai usando, e come si rimedia

Due finestre di browser disegnate una accanto all’altra, con la stessa fascia blu notte in alto e la scritta bianca Sticky Header. Nella finestra di sinistra, sotto la fascia, ci sono solo tre righe grigie di testo segnaposto: il pulsante su cui è appena arrivato il cursore della tastiera non si vede, perché è finito sotto l’intestazione. In quella di destra lo stesso pulsante, View Pricing, è in piena vista, circondato da un bordo blu spesso e staccato dalla fascia di qualche pixel, con una piccola quota tecnica e la scritta Room to scroll. In fondo alla scheda, tre consigli asciutti: provare in entrambe le direzioni, lasciare spazio pari all’altezza della testata, ripetere il test con finestre strette e zoom alto. In basso a destra, il riferimento: W3C WCAG 2.2.

È una grafica didattica, pulita e senza fronzoli, e racconta in un colpo d’occhio un difetto che vedo quasi ogni settimana quando faccio verifiche di accessibilità sui siti: la barra che ti segue mentre scorri la pagina e che, ogni tanto, si mette esattamente davanti a quello che stai facendo.

Il difetto che non vede chi usa il mouse

Lo sperimentate anche senza saperlo. Cliccate su una voce dell’indice in cima a un articolo lungo, la pagina salta al paragrafo giusto, ma il titolo del paragrafo è sparito: è lì, coperto dalla barra fissa. Dovete scorrere un po’ indietro per leggerlo. Per chi usa il mouse è un fastidio. Per chi naviga con la tastiera è un vicolo cieco: si preme Tab, il fuoco passa al pulsante successivo, la pagina scorre per mostrarlo e il pulsante finisce sotto la testata o sotto un banner dei cookie. Il cursore c’è ancora, ma non si sa più dove sia.

Chi naviga da tastiera non è una minoranza esotica: ci sono persone con disabilità motorie che non riescono a usare un mouse con precisione, chi usa uno screen reader insieme a un residuo visivo, chi ingrandisce molto lo schermo, ma anche chi compila moduli lunghi e salta da un campo all’altro con Tab perché fa prima. Quando il fuoco scompare, tutte queste persone perdono l’orientamento.

Breve storia della barra appiccicosa

Per anni la testata che resta in alto è stata un trucco. Si ascoltava lo scorrimento della pagina con JavaScript e, superata una certa soglia, si cambiava la posizione della barra da normale a fissa. Funzionava, ma era fragile: scatti, saltelli del contenuto quando la barra usciva dal flusso della pagina, calcoli ripetuti a ogni movimento della rotella. Ricordo bene i primi progetti in cui bisognava aggiungere uno spazio vuoto finto sotto la barra per evitare che il testo facesse un balzo verso l’alto.

La svolta è arrivata con il valore position: sticky, nato dalle parti di WebKit e poi formalizzato nel modulo CSS del W3C dedicato al posizionamento. L’idea è elegante: l’elemento si comporta come un normale blocco nella pagina finché non raggiunge una soglia, per esempio il bordo superiore della finestra, e da lì in poi resta incollato. Niente script, niente saltelli. Con la diffusione nei principali browser, la barra fissa è diventata facilissima da realizzare, e proprio per questo è comparsa ovunque: testate, barre degli strumenti, intestazioni di tabelle, carrelli, banner promozionali, avvisi sui cookie. Più strati appiccicosi si sommano, meno finestra rimane per il contenuto vero.

Perché il fuoco finisce proprio sotto la testata

La grafica suggerisce un dettaglio che merita una spiegazione, perché è la chiave di tutto: Tab forward. Shift + Tab back. Quando il fuoco si sposta su un elemento fuori dalla vista, il browser fa scorrere la pagina quel tanto che basta per portarlo dentro la finestra. Se andate avanti con Tab, l’elemento entra dal basso e si ferma vicino al bordo inferiore: lì rischia di essere coperto da una barra fissa in fondo, come un banner dei cookie. Se tornate indietro con Shift e Tab, l’elemento entra dall’alto e si ferma contro il bordo superiore della finestra, cioè esattamente dove sta la testata appiccicosa.

Il browser, in altre parole, non sa che quei primi ottanta o cento pixel sono occupati. Considera visibile tutta la finestra. Ecco perché il difetto compare quasi sempre andando all’indietro, ed ecco perché sfugge a chi prova il sito solo in avanti, o solo con il mouse.

Cosa chiedono le WCAG 2.2

Il 5 ottobre 2023 il W3C ha pubblicato come raccomandazione ufficiale le WCAG 2.2, la versione aggiornata delle linee guida internazionali per l’accessibilità dei contenuti web. Tra le novità c’è il criterio 2.4.11, Focus Not Obscured (Minimum), di livello AA: quando un componente riceve il fuoco da tastiera, non deve essere completamente nascosto da contenuti creati dall’autore della pagina. Accanto ci sono il 2.4.12, di livello AAA, più severo, che non ammette nemmeno una copertura parziale, e il 2.4.13, che riguarda l’aspetto dell’indicatore di fuoco, cioè proprio quel bordo blu ben visibile che si vede nella finestra di destra.

Il documento esplicativo del W3C usa esempi molto concreti: le testate e i piè di pagina fissi e i banner dei cookie. Un avviso che copre per intero il pulsante attivo fa fallire il criterio; si può rimediare, per esempio, facendo in modo che il banner non copra il contenuto o che si possa chiudere. Viene anche chiarito che la versione minima tollera la copertura parziale: se si vede una parte del pulsante e del suo bordo, l’utente si orienta comunque. È un compromesso realistico, e lo trovo onesto: chiede di eliminare il caso peggiore senza vietare le barre fisse.

Una nota per chi lavora in Italia. Le Linee guida AgID sull’accessibilità degli strumenti informatici rimandano alla norma europea EN 301 549, che nella versione di riferimento incorpora i criteri delle WCAG 2.1, non ancora quelli della 2.2. Il criterio sul fuoco nascosto, quindi, oggi è una buona pratica riconosciuta a livello internazionale più che un obbligo formale per tutti. Ma è il genere di difetto che un utente reale incontra subito, e correggerlo costa pochissimo.

La correzione da una riga

Tra le tecniche indicate dal W3C come sufficienti per il criterio c’è la C43, che usa la proprietà CSS scroll-padding. Il principio è semplice: si dice al browser che la parte alta della finestra non è utilizzabile, così quando scorre per mostrare un elemento, che sia per un Tab o per un link interno, lo ferma più in basso. In pratica:

html { scroll-padding-top: 6rem; }

Il valore deve essere un po’ più grande dell’altezza della testata, come dice la grafica: Match the current header height. Quel current non è messo lì a caso. La testata cambia altezza quando il menu va a capo su schermi stretti, quando l’utente ingrandisce il testo, quando compare una seconda riga con un avviso. Nei progetti che seguo preferisco esprimere il valore in rem, che cresce con la dimensione del carattere, oppure aggiornare una variabile CSS con l’altezza reale della testata misurata dal browser. Per i link interni si può lavorare anche sul singolo titolo con scroll-margin-top, che ottiene lo stesso effetto dalla parte dell’elemento di destinazione.

Due avvertenze dall’esperienza. Primo: scroll-padding risolve la testata in alto, ma non il banner in basso; per i cookie la soluzione più pulita resta un avviso che non si sovrappone al contenuto, o che si chiude facilmente e non torna. Secondo: con lo zoom molto alto una testata fissa può arrivare a occupare un terzo o metà della finestra. In quei casi la scelta più sensata è smettere di renderla appiccicosa quando l’altezza disponibile è poca, con una media query sull’altezza della finestra. Nessuna riga di padding salva una pagina in cui il contenuto ha a disposizione una feritoia.

Il test dei dieci secondi

Potete farlo su qualsiasi sito, anche se non avete mai scritto una riga di codice. Serve solo una tastiera.

Tab avanti e indietro. Scendete per la pagina premendo Tab finché il fuoco non arriva a metà del contenuto, poi tornate su con Shift e Tab. Se a un certo punto non vedete più dove sia il cursore, avete trovato il difetto.
Zoom. Ingrandite la pagina al 200 per cento e oltre, oppure restringete la finestra, e ripetete. Spesso il problema compare solo qui, quando la testata va su due righe.
Link interni. Cliccate una voce dell’indice o un link che porta a un punto della stessa pagina. Il titolo di destinazione deve comparire per intero sotto la barra, non dietro.

È lo stesso controllo che la grafica riassume nei tre riquadri in basso, e ha un pregio: ribalta il punto di vista. I siti vengono quasi sempre progettati e provati su monitor ampi, con il mouse in mano e lo zoom al cento per cento. In quelle condizioni la barra fissa sembra solo comoda. Basta cambiare modo di usare la pagina per accorgersi che lo spazio sotto di lei appartiene ancora a qualcuno.

Una buona grafica che insegna senza predicare

Chiudo con due parole sul disegno in sé, perché è un piccolo esempio di comunicazione tecnica fatta bene. Il confronto prima e dopo è costruito con elementi identici, così l’occhio nota solo la differenza che conta: il pulsante presente o assente. Il fuoco è rappresentato con un bordo spesso e un fondo azzurrato, ben distinguibile dal resto, cioè esattamente come dovrebbe essere su un sito reale. E la piccola quota con la scritta Room to scroll trasforma un concetto astratto in una misura da rispettare. Se dovessi migliorarla aggiungerei un terzo pannello con un banner in basso che copre il pulsante andando avanti con Tab: è l’altra metà del problema, e ne è la versione più diffusa nei siti europei, pieni di avvisi sui cookie.

La barra appiccicosa non è sbagliata in sé. È utile, orienta, tiene a portata di mano il menu. Diventa un errore quando chi la progetta dimentica che occupa spazio anche per il browser, non solo per gli occhi. Una riga di CSS e dieci secondi di prova con la tastiera bastano a rimetterla al suo posto.

Fonti

Tag:Interfacce digitali