PHP attraverso uno screen reader: piccole scelte di sintassi che contano

Sono uno sviluppatore backend e PHP è il mio linguaggio principale; è anche il mio preferito. Sviluppo in PHP dal 2008 e oggi, quando avvio un progetto web, scelgo PHP con orgoglio, perché so cosa funziona bene per me.

C'è una particolarità nella mia esperienza di sviluppatore: sono completamente cieco dalla nascita. Quindi uso uno screen reader, uno strumento che invia le informazioni alla sintesi vocale e/o a un display Braille.

Naturalmente, i programmatori ciechi non sono un unico organismo con un file di configurazione condiviso. Usiamo strumenti diversi e livelli di tolleranza diversi per la punteggiatura pronunciata a 500 miglia all'ora. Eppure PHP ha molte qualità che lo rendono comodo da leggere e scrivere in modo non visivo.

La sintassi come punto di riferimento

L'accessibilità nella programmazione viene spesso discussa attraverso gli strumenti, e gli strumenti contano molto; ma conta anche il linguaggio stesso, perché la sintassi è qualcosa che ascoltiamo, cerchiamo, ricordiamo e a volte leggiamo su un display Braille.

Come tutti sappiamo, ogni variabile in PHP inizia con $ e, anche se questo viene spesso considerato una di quelle vecchie stranezze di PHP che tutti amano tirare in ballo, per chi usa uno screen reader è piuttosto un punto di riferimento pratico. Non devo dedurre se user è una variabile, una costante, il nome di una classe, una funzione o qualcos'altro, perché $user si annuncia da solo, immediatamente. Senza quel marcatore, qualcosa come User user = new User() diventa, nel parlato, “user user equals new user left parenthesis right parenthesis”, o nel mio uccellese, “user user equal new user left right”; è comprensibile, sì, ma richiede comunque un piccolo sforzo per essere decifrato. Mille piccoli sforzi al giorno, in realtà.

Anche le funzioni hanno un marcatore chiaro: la keyword function, e le arrow function hanno fn. Queste parole sono ancore ricercabili e prevedibili all'interno di un file, soprattutto perché non tutti gli sviluppatori ciechi vivono dentro un grande IDE visuale. Molti di noi usano editor di codice o persino editor di testo, strumenti da riga di comando e la funzione di ricerca dove funzionano bene: quindi, se voglio saltare da una funzione all'altra in un file, la parola function è mia amica.

Anche la moderna sintassi orientata agli oggetti di PHP ha un ritmo piacevole:

public function getDisplayName(): string

Forse perché vengo da una formazione linguistica, per me conta che questa sia una buona frase da ascoltare e da leggere: ha parole intere, ha struttura — visibilità, function, nome, lista di parametri, due punti, tipo di ritorno. Non voglio scatenare una guerra tra linguaggi — beh, non oggi — ma quando il codice viene letto in modo lineare attraverso la voce o il Braille, una sintassi esplicita può risultare più comoda di una sintassi compatta.

Lo stesso vale per le graffe e i punti e virgola: una graffa di chiusura mi dice che un blocco è terminato, un punto e virgola mi dice che un'istruzione è terminata, ed entrambi mi risparmiano di ricostruire la struttura basandomi solo sull'indentazione. L'indentazione è utile, certo, ma le graffe fungono da pietre miliari: blocco finito, punto, vai avanti.

Anche le convenzioni di denominazione contano. In PHP vediamo comunemente camelCase, PascalCase e UPPER_SNAKE_CASE. Per me camelCase è comodo perché gli screen reader spesso separano naturalmente le parole, mentre le costanti in UPPER_SNAKE_CASE sono ben riconoscibili, soprattutto in Braille. Il normale snake case è più difficile: se la punteggiatura è attiva — e lo è quando si scrive codice! — my_very_descriptive_variable_name può diventare “my underscore very underscore descriptive underscore variable underscore name”. Puoi regolare le impostazioni della punteggiatura, e io l'ho fatto, ma resta comunque un lavoro in più.

PHP non è perfetto; nessun linguaggio lo è. Ma l'accessibilità non è solo eleganza: a volte è prevedibilità, esplicitezza, e la possibilità di cercare function, sentire un amichevole $, distinguere una costante su un display Braille e sapere che un blocco è finito perché c'è una }.

E per quanto riguarda l'apprendimento?

La seconda parte della storia è l'apprendimento. Il linguaggio PHP in sé può essere amichevole verso le tecnologie assistive, ma l'educazione alla programmazione è molto più disomogenea. Molti tutorial oggi sono video-first, visivamente densi e pieni di frasi come “clicca qui”, “come puoi vedere” o “ora otteniamo questo risultato”. Va bene se l'informazione importante viene anche detta o scritta, ma diventa una barriera quando il tutorial dipende da un contesto visivo che non viene mai spiegato.

Ecco una semplice regola pratica: chiudi gli occhi e prova a capire cosa sta succedendo in un corso o in un intervento a una conferenza. Se non ci riesci, la parte cieca del tuo pubblico è immediatamente esclusa. Una persona cieca che impara non può usare “questo pulsante qui” se “qui” indica soltanto il puntatore del mouse di chi insegna, non può copiare il codice da uno screenshot e non può seguire facilmente un refactoring se l'insegnante seleziona silenziosamente un blocco e dice: “ora lo sistemiamo così”.

E non si tratta solo di cecità. Un insegnamento chiaro aiuta tutti: i principianti, chi impara in una seconda lingua, chi guarda da un telefono e chi torna su un tutorial sei mesi dopo.

Quindi ecco il mio desiderio concreto per chi insegna PHP: fornisci il codice come testo, idealmente in un repository Git. Di' quale file stai modificando, di' in quale funzione ti trovi e non affidarti solo a “come puoi vedere”. Se qualcosa cambia sullo schermo, descrivi il cambiamento; se mostri un errore, leggi la parte importante dell'errore; se usi un diagramma, spiega brevemente cosa significa. Se pubblichi le slide, assicurati che gli esempi di codice siano testo reale e non solo immagini, e valuta di pubblicare una trascrizione.

Conta anche un buon materiale scritto. PHP ha sempre avuto una forte cultura della documentazione e degli esempi, e questo non è solo comodo: è una funzionalità di accessibilità.

Conclusione

L'accessibilità è essenziale per gli utenti, ma anche chi sviluppa ha bisogno di accessibilità. Per me, parte della facilità di approccio di PHP sta nel fatto che il codice mi offre punti di riferimento: parla in una struttura che riesco a seguire, mi permette di cercare e segnala le parti importanti in modi che non sono solo visivi.

Sono piccole cose, ma la programmazione è fatta di piccole cose ripetute molte volte, e quando quelle piccole cose riducono l'attrito, permettono a più persone di costruire.