Case study · progetto demo
Un calendario corsi che non lascia indietro chi non usa il mouse
Interfaccia a schede per il calendario corsi di un centro sportivo, pensata perché consultarla e prenotare non richieda mai un dispositivo di puntamento.
Il problema
I calendari corsi "a schede per giorno" sono comodi da guardare ma, implementati male, diventano una barriera concreta per chi naviga da tastiera (per scelta, per necessità motoria, o perché usa uno screen reader): schede che rispondono solo al click del mouse, focus che scompare dopo un cambio di vista, contenuto che esiste nel DOM ma non è mai raggiungibile senza puntatore. In un centro sportivo, che per definizione serve anche persone con disabilità motorie, è un problema che va oltre l'accessibilità "di principio": è chi non riesce a scoprire quando c'è un corso adatto a sé.
Contesto e vincoli
Progetto demo pensato per dimostrare un vincolo concreto — non "accessibilità" come parola generica, ma un requisito verificabile: l'intero calendario, compresa l'azione di prenotazione, deve essere raggiungibile e operabile esclusivamente da tastiera, con il focus sempre visibile. Vincoli dichiarati:
- consultare gli orari di ogni giorno non deve mai richiedere JavaScript: deve funzionare anche a script disattivato;
- con JavaScript attivo, i giorni devono comportarsi come un vero
pattern ARIA
tablist, navigabile con le frecce, non solo con Tab ripetuto su ogni singolo elemento; - ogni elemento interattivo deve avere un indicatore di focus visibile, non solo il contorno di default (spesso invisibile) del browser.
Processo e decisioni
La decisione strutturale è stata partire dal markup che funziona senza JavaScript e considerare la versione "a schede" un miglioramento applicato sopra, non l'unica versione esistente. Nel markup di base, i giorni sono normali link di ancoraggio verso sezioni sempre visibili e impilate: già così, il calendario è interamente leggibile e navigabile da tastiera con il comportamento nativo del browser, senza una riga di script.
Quando main.js si carica, trasforma quella lista di link
in un vero pattern ARIA tabs: aggiunge role="tablist" al
contenitore, role="tab" a ogni giorno, gestisce il
roving tabindex (un solo elemento della lista è raggiungibile
con Tab alla volta; le frecce spostano il focus internamente) e
nasconde i pannelli non attivi con l'attributo hidden
invece che con solo CSS, così anche gli screen reader li ignorano
correttamente. Le frecce sinistra/destra passano da un giorno
all'altro, Home ed End saltano al primo e all'ultimo.
Per il pulsante "Prenota" ho fatto una scelta di scopo esplicita:
la consultazione del calendario (il compito con più valore
informativo) funziona al 100% senza JavaScript; la conferma di
prenotazione, in questa demo, è una simulazione lato client — non
esiste un backend reale dietro — e degrada dichiarando apertamente il
limite con un messaggio <noscript> che indica un
numero di telefono alternativo, invece di fingere che il pulsante
faccia qualcosa quando in realtà non succede nulla.
Soluzione
Il risultato sono due esperienze coerenti sullo stesso markup: senza JavaScript, una pagina più lunga da scorrere ma completa; con JavaScript, un'interfaccia compatta che segue esattamente il comportamento da tastiera che ci si aspetta da un componente a schede, con focus sempre visibile grazie a un contorno a contrasto elevato applicato in modo coerente su ogni elemento interattivo del sito, non solo sui tab.
Risultati
Comandi da tastiera supportati sull'interfaccia a schede:
- Tab
- ← →
- Home
- End
- Invio / Spazio
Il peso complessivo di HTML, CSS e JavaScript, misurato sui file sorgente, è di circa 17 KB non compressi: l'attenzione all'accessibilità qui non ha richiesto librerie esterne per i componenti — l'intero pattern tabs è scritto a mano in meno di 3 KB di JavaScript.
Nota: progetto dimostrativo a scopo di portfolio. Centro sportivo, corsi e recapiti sono fittizi.