Accessibilità di serie: che cosa significa per PanelWave

Nella maggior parte delle app di lettura l’accessibilità è una pagina delle impostazioni. In PanelWave è una proprietà del formato. La differenza sembra astratta finché non vedi che cosa comporta: testi alternativi tradotti perché tutto il testo è tradotto, un movimento ridotto che funziona perché le transizioni sono dati, e una graphic novel che chi usa la tastiera può leggere dall’inizio alla fine perché la storia è un grafo che una tastiera può percorrere. Questo post spiega come l’accessibilità attraversa i tre livelli, dal manifest al player fino al CMS, che cosa fa per i lettori, che cosa chiede agli autori e dove ci sono ancora lacune.

Tutto parte dal formato

Il manifest porta le informazioni di accessibilità come campi di primo livello, non come un allegato facoltativo. Ogni asset del catalogo può avere un testo alternativo, una didascalia e una trascrizione per audio e video, e tutti e tre sono LocalizedString, quindi l’output per gli screen reader segue la lingua del lettore esattamente come i dialoghi (Assets, Localization). Una vignetta ha una descrizione che viene letta ad alta voce al posto dell’illustrazione e un blocco di accessibilità con una descrizione alternativa dell’intera vignetta (AccessibilityHints). Un hotspot ha la propria etichetta ARIA, così un’area interattiva annuncia che cosa fa e non dove si trova (Hotspots).

Gli avvisi sui contenuti si dichiarano una volta nei metadati dell’opera, con un’etichetta localizzata e un flag defaultBlur, e poi si richiamano tramite id da ogni vignetta a cui si applicano (ContentWarning). Poiché la dichiarazione è nel formato, qualsiasi implementazione di un reader può rispettarla, non solo la nostra. È un principio che ritorna: metti l’informazione dove ogni strumento può vederla, e l’accessibilità smette di dipendere da quale app apre il file.

Che cosa trova il lettore nel player

Il player open source trasforma quei campi in comportamenti. Ogni pulsante della barra degli strumenti ha un aria-label tradotto e gli interruttori espongono aria-pressed. Il viewport è una regione etichettata che chi usa la tastiera attiva con Invio o Spazio; nella vista pagina ogni vignetta posizionata è un pulsante che può ricevere il focus, con un indicatore di focus visibile. I tasti freccia fanno avanzare la storia, T mostra o nasconde la barra degli strumenti, Esc chiude le finestre modali, e le scorciatoie vengono ignorate mentre il lettore scrive in un campo (Accessibility, Input methods).

Gli hotspot, le aree interattive disegnate dall’autore, sono nell’ordine di tabulazione: Tab si sposta dall’uno all’altro, Invio o Spazio li attiva, e ciascuno annuncia la propria etichetta localizzata. Chi legge a vista li nota grazie a un leggero contorno pulsante; con il movimento ridotto la pulsazione è disattivata e il contorno compare invece al passaggio del mouse e al focus (Interactive hotspots).

Il movimento ridotto si attiva da due fonti, l’impostazione prefers-reduced-motion del sistema operativo e l’input reducedMotion dell’host, e cambia più della semplice velocità delle animazioni. Le transizioni tra vignette sono disattivate, l’avvio automatico dei video alla visualizzazione diventa un avvio al clic, e nella vista tela la camera non scivola mai: i cambi di inquadratura sono istantanei con una breve dissolvenza incrociata, e una transizione alternativa definita dall’autore ha la precedenza quando c’è. Tutte le vignette tranne quella corrente hanno aria-hidden e inert, così una tela virtualizzata non intrappola mai il focus, e gli screen reader seguono l’ordine lineare del grafo mentre la tela resta pura presentazione (Canvas View, Configuration).

I lettori hanno anche comandi diretti. La finestra delle impostazioni offre la modalità manga per la lettura da destra a sinistra, il movimento ridotto e l’alto contrasto, accanto a balloon, audio e tempi della riproduzione automatica, con un ripristino dei valori predefiniti (Settings modal). Anche il cambio di lingua è una funzione di accessibilità, ed è immediato: testo, balloon, asset localizzati e audio si aggiornano senza ricaricare (Player localization).

Come la teniamo sotto controllo

Promesse come queste perdono valore se nessuno le verifica. La suite end-to-end Playwright del player esegue axe-core sulla vista vignetta con la barra degli strumenti aperta, sulla vista pagina e sulla finestra della lingua, e fallisce in caso di violazioni gravi; i report sono allegati a ogni esecuzione. La navigazione da tastiera e il comportamento con movimento ridotto hanno test dedicati. La suite gira su browser desktop e mobile nell’integrazione continua (Development: testing). Non sostituisce i test con uno screen reader, che facciamo anche a mano prima delle release, ma impedisce che le regressioni passino inosservate.

Cosa deve fare un autore

Il formato contiene solo ciò che l’autore inserisce, quindi il CMS fa di questi testi una parte del normale flusso di lavoro, non un controllo a parte.

Niente di tutto questo richiede di sapere che cosa significa ARIA. I campi si trovano accanto ai contenuti, il controllo gira prima della pubblicazione e la correzione è a un link di distanza.

• Descrivi le vignette. Titolo e descrizione della vignetta si modificano nell’inspector per ogni lingua; la descrizione è ciò che leggono gli screen reader, quindi una frase su ciò che succede nella vignetta rende l’opera accessibile a chi è cieco o ipovedente (Panel properties).
• Dai un testo alternativo alle illustrazioni. Impostalo una volta sull’asset con Edit Metadata, oppure sul livello nella scheda A11y dell’inspector; la stessa scheda copre le didascalie per audio e video e l’accessibilità degli elementi interattivi (Alt text and accessibility, Right inspector).
• Etichetta gli hotspot. Ogni hotspot ha un campo Label per lingua e un campo ARIA Label nelle Basic Properties (Naming and accessibility).
• Segnala i contenuti sensibili. Gli avvisi sui contenuti si impostano per vignetta dall’albero della struttura o dalla sezione Content Settings, e l’albero mostra un badge W su ogni vignetta segnalata (Pages and Panels).
• Esegui il controllo pre-pubblicazione. La categoria Accessibility segnala i livelli immagine senza testo alternativo e l’audio senza didascalie; un testo alternativo mancante è un avviso, una didascalia mancante è un errore che blocca la pubblicazione. Ogni problema rimanda alla vignetta che usa l’asset e al riferimento del codice (Validation, Missing alt text, Missing caption).

Anche lo strumento di creazione deve essere accessibile

Chi crea fumetti e ha una disabilità visiva o motoria dovrebbe poter realizzare un fumetto accessibile, non solo fruirne. L’editor ha uno standard di focus visibile in tutta l’app, focus trap in ogni finestra di dialogo, semantica ARIA sull’albero della struttura con navigazione completa tramite i tasti freccia, e una panoramica delle scorciatoie da tastiera dietro il tasto del punto interrogativo (Shortcuts). La palette dei comandi su Ctrl+K raggiunge la maggior parte delle azioni dell’editor senza mouse, e un navigatore dei livelli da tastiera annuncia i livelli agli screen reader mentre li scorri. I temi comprendono System, Light, Dark e una palette High Contrast che si applica sia all’app sia agli elementi dell’interfaccia attorno al canvas dell’editor (Account: theme). Il tema ad alto contrasto è uscito questo mese insieme a un set di componenti di interfaccia condivisi, ed è quello che prevediamo di affinare di più man mano che arriveranno i riscontri.

Verifiche dell’età e paywall, con rispetto

Il comfort non riguarda solo movimento e contrasto. Quando un’opera richiede una verifica dell’età, il player fornisce un componente di verifica con età minima e messaggio configurabili, e la decisione è delegata all’adattatore dei diritti di accesso dell’host, che può verificare l’età o ripiegare su una variabile utente di sola lettura inserita all’avvio. Senza nessuna delle due, la verifica nega l’accesso invece di tirare a indovinare (Paywall and Entitlement). Gli overlay del paywall seguono la stessa regola: il lettore sa sempre con chiarezza che cosa è protetto e perché, nella sua lingua, e la storia non salta mai contenuti in silenzio.

Cosa manca ancora

Elenchiamo questi punti perché una promessa di accessibilità che nasconde le proprie lacune vale meno di una che le nomina.

• Il controllo pre-pubblicazione non esegue ancora tutte le verifiche che elenca. La completezza della localizzazione e la copertura audio per balloon compaiono come categorie, ma i loro codici di problema sono ancora in programma; testi alternativi e didascalie sono attivi (Validation codes).
• Tre caselle delle impostazioni vengono salvate, ma non ancora applicate. Gli interruttori Audio e SFX della barra degli strumenti ora funzionano: Audio silenzia l’intero player, compreso l’audio dei video, SFX silenzia il bus degli effetti, Speech silenzia anche la voce fuori campo, e tutti e tre ricordano la tua scelta (Toolbar controls). Le caselle della finestra delle impostazioni per modalità manga, movimento ridotto e alto contrasto vengono salvate, ma la shell non agisce ancora di conseguenza; il movimento ridotto viene invece rispettato tramite l’impostazione del sistema operativo e l’input dell’host.
• La presentazione degli avvisi sui contenuti dipende dall’implementazione. Il formato dichiara l’avviso e se una vignetta deve essere sfocata per impostazione predefinita; come chiedere la conferma esplicita del lettore lo decide il player, e il nostro lo stiamo ancora affinando su opere reali.

Perché fin dal primo giorno

Aggiungere l’accessibilità a posteriori significa toccare tutti i livelli insieme: il formato deve acquisire nuovi campi, il player deve leggerli, lo strumento di creazione deve raccoglierli, e le opere esistenti restano inaccessibili finché qualcuno non ci rimette mano. Costruirla fin dall’inizio ha trasformato gran parte del lavoro in conseguenze di decisioni che avevamo già preso. Il testo alternativo è localizzato perché tutto è una LocalizedString. Il movimento ridotto è affidabile perché una transizione è un campo di dati che un motore può saltare. La navigazione da tastiera è completa perché la storia è un grafo con un «avanti» e un «indietro» definiti. Grafo narrativo, modello di localizzazione e campi di accessibilità sono stati progettati insieme, ed è in questo senso che qui l’accessibilità è di serie, non una funzionalità in più.

Per approfondire

• Reader Interface: ogni comando, metodo di input e comportamento di accessibilità del player.
• Panels e Assets: i campi di accessibilità nel formato.
• Validation and Preflight: i controlli che girano prima della pubblicazione.
• Perché una navigazione a grafo?: il modello che rende completa la navigazione da tastiera.