Chrome DevTools sta lanciando un albero di accessibilità completo per consentire agli sviluppatori di ottenere più facilmente una panoramica dell'intero albero. In questo post scoprirai come viene creato questo albero e come utilizzarlo nel tuo lavoro.
Cos'è l'albero dell'accessibilità?
Le tecnologie per la disabilità come gli screen reader utilizzano l'API Accessibility di Chromium per interagire con i contenuti web. Il modello sottostante a questa API è l'albero dell'accessibilità: un albero di oggetti di accessibilità su cui le tecnologie per la disabilità possono interrogare attributi e proprietà ed eseguire azioni su cui. Gli sviluppatori web modellano e manipolano l'albero dell'accessibilità principalmente tramite proprietà DOM come gli attributi ARIA per HTML.
In Chrome DevTools, forniamo il riquadro Accessibilità per aiutare gli sviluppatori a capire in che modo i loro contenuti sono esposti alle tecnologie per la disabilità. In pratica, quando viene selezionato un nodo nel visualizzatore dell'albero DOM, le proprietà del nodo di accessibilità corrispondente vengono visualizzate nel riquadro insieme a una vista dei predecessori del nodo e dei relativi elementi secondari immediati.
Come viene creato l'albero?
Prima di vedere come si presenta questa nuova visualizzazione ad albero completa in DevTools, vediamo brevemente in termini più tangibili l'albero dell'accessibilità. L'albero dell'accessibilità è un derivato dell'albero DOM. La struttura è più o meno la stessa, ma è stata semplificata per rimuovere i nodi senza contenuti semantici, ad esempio un elemento <div> utilizzato esclusivamente per lo stile. Ogni nodo nell'albero ha un ruolo come Button o Heading e spesso un nome che può provenire da attributi ARIA o derivato dai contenuti del nodo. Se esaminiamo un documento HTML:
<html>
<head>
<title>How old are you?</title>
</head>
<body>
<label for="age">Age</label>
<input id="age" type="number" name="age" value="42">
<div>
<button>Back</button>
<button>Next</button>
</div>
</body>
</html>
Il renderer in Chromium, denominato Blink, ricava una struttura di accessibilità interna approssimativamente come segue.
role='rootWebArea' focusable name='How old are you?'
role='genericContainer' ignored
role='genericContainer' ignored
role='labelText'
role='staticText' name='Age'
role='spinButton' editable focusable name='Age' value='42'
role='genericContainer' editable
role='staticText' editable name='42'
role='genericContainer'
role='button' focusable name='Back'
role='staticText' name='Back'
role='button' focusable name='Next'
role='staticText' name='Next'
Tieni presente che questa rappresentazione contiene più nodi superflui con il ruolo genericContainer, che apparentemente contraddice l'affermazione precedente secondo cui l'albero dell'accessibilità è una derivata semplificata dell'albero DOM. Tuttavia, la maggior parte di questi nodi si trova solo nella struttura ad albero interna e non sarebbe esposta alle tecnologie per la disabilità. Poiché DevTools raccoglie le informazioni sull'accessibilità direttamente dal processo di rendering, questa è la rappresentazione ad albero gestita da DevTools.
Albero di accessibilità completa in DevTools
Il nuovo albero con accessibilità completa sincronizzato con l'albero DOM in modo che gli sviluppatori possano spostarsi avanti e indietro tra i due alberi. Ci auguriamo che la nuova struttura ad albero risulti più esplorabile, utile e facile da utilizzare.
Ora che sai come funziona la struttura ad albero dell'accessibilità, puoi utilizzare DevTools per vedere l'aspetto della nuova visualizzazione ad albero. Il seguente documento HTML con un titolo, un'intestazione e due pulsanti viene utilizzato per visualizzare la struttura ad albero.
<!DOCTYPE html>
<title>Test</title>
<h1>Heading for example page</h1>
<div>
<button>Back</button>
<button>Next</button>
</div>
La visualizzazione ad albero precedente consente di esplorare solo un singolo nodo e i relativi predecessori.
Ora, quando attivi il nuovo albero, questo sostituisce la visualizzazione ad albero del DOM e ti consente di vedere l'albero completo dell'accessibilità per la pagina:
Costruzione di alberi lenti
Per garantire prestazioni elevate dell'albero anche per i siti più grandi, viene costruito pigramente sul frontend durante l'esplorazione. Una volta che un nodo è espanso nella struttura, gli elementi secondari dei nodi vengono recuperati tramite il protocollo CDP (Chrome DevTools) e la struttura ad albero viene ricreata.
Live streaming
La nuova visualizzazione ad albero è attiva e si aggiorna dinamicamente se la struttura ad albero dell'accessibilità cambia nel renderer. Si aggancia agli stessi meccanismi che notificherebbero le tecnologie per la disabilità delle modifiche all'albero e li utilizza per emettere eventi al frontend DevTools con i nodi aggiornati. In pratica, il backend CDP rimane in ascolto degli aggiornamenti dell'albero, tiene traccia dei nodi che sono stati richiesti in precedenza e invia eventi al frontend DevTools se uno di questi nodi cambia.
La storia di molti alberi
Nella descrizione che cos'è l'albero dell'accessibilità hai imparato in che modo Blink crea un albero dell'accessibilità per il DOM di cui esegue il rendering e DevTools recupera questo albero tramite CDP. Anche se è vero, abbiamo omesso alcune complicazioni in questa descrizione. In realtà, esistono molti modi diversi per sperimentare l'albero dell'accessibilità in Chromium. Durante la progettazione della nuova visualizzazione ad albero per DevTools, abbiamo fatto alcune scelte lungo il percorso su quale parte delle funzioni interne di accessibilità di Chromium volevamo mostrare.
Piattaforme
Ogni piattaforma ha un'API di accessibilità diversa e, sebbene la forma dell'albero sia la stessa in tutte le piattaforme, l'API per l'interazione con l'albero è diversa e i nomi degli attributi possono variare. DevTools mostra la struttura interna di Chromium in cui i ruoli e gli attributi tendono a corrispondere a quelli definiti nella specifica ARIA.
Isolamento di siti e frame multipli
Poiché Chromium non solo inserisce i contenuti di ogni scheda in diversi processi del renderer, ma isola anche i documenti tra siti in diversi processi del renderer, dobbiamo collegarci separatamente a ogni documento secondario out-of-process tramite CDP e recuperarne l'albero di accessibilità. Quindi, uniamo questi sottoalberi sul frontend per dare l'illusione di un unico albero coerente, anche se si trovano in diversi processi di rendering in Chromium.
Nodi ignorati e non interessanti
Alcuni nodi vengono nascosti per impostazione predefinita: nodi ignorati e nodi con ruolo "generico" senza nome. Questi nodi non hanno alcun significato semantico e, nel caso di nodi ignorati, non sono esposti alla tecnologia per la disabilità. Questi nodi vengono nascosti per evitare di intasare la visualizzazione ad albero. In caso contrario, l'albero dell'accessibilità per la maggior parte delle pagine web avrebbe invece un aspetto simile al seguente:
L'avvertenza qui è che ciò significa essenzialmente che dobbiamo costruire un altro albero rispetto a quello disponibile nel backend. Supponiamo, ad esempio, di avere i nodi A, B, C e X in cui A ha i figli X e B e X ha gli elementi secondari C. Se X è un nodo ignorato, eliminiamo X dall'albero e creiamo invece un albero in cui C è un nodo figlio rispetto ad A.
Sul frontend costruiamo l'albero completo che include i nodi ignorati e li eliminiamo solo appena prima del rendering dei nodi. Per due motivi:
- Rende molto più semplice la gestione degli aggiornamenti dei nodi dal backend, dato che abbiamo la stessa struttura ad albero su entrambi gli endpoint. Ad esempio, se il nodo B viene rimosso nell'esempio, riceveremmo un aggiornamento per il nodo X (dal momento che i suoi figli sono cambiati), ma se avessimo eliminato quel nodo avremmo faticato a capire cosa aggiornare.
- Assicura che tutti i nodi DOM abbiano un nodo di accessibilità corrispondente. Quando la struttura ad albero viene attivata, selezioniamo il nodo corrispondente a quello attualmente selezionato nell'albero DOM. Nell'esempio precedente, quindi, se l'utente attiva/disattiva la struttura ad albero mentre è selezionato il nodo DOM corrispondente a X, inseriamo X tra i nodi A e B e selezioniamo X nella struttura ad albero. Ciò consente all'utente di ispezionare il nodo di accessibilità per tutti i nodi DOM e a determinare il motivo per cui il nodo viene ignorato.
Idee future
Il lancio del nuovo albero dell'accessibilità è solo l'inizio. Abbiamo alcune idee per progetti futuri che potremmo sviluppare sulla base di questa nuova visualizzazione, ma non vediamo l'ora di avere un tuo feedback.
Filtri alternativi
Come spiegato in precedenza, al momento escludiamo i nodi che non sono considerati interessanti. Potremmo fornire un modo per disattivare questo comportamento e mostrare tutti i nodi oppure fornire filtri alternativi come Mostra nodi punto di riferimento o Mostra intestazioni.
Evidenzia i problemi di accessibilità
Potremmo incorporare un'analisi di "best practice per l'accessibilità" con la struttura ad albero ed evidenziare i problemi di accessibilità direttamente nei nodi offensivi.
Mostra le azioni di accessibilità in DevTools
L'albero che mostriamo attualmente è solo unidirezionale: ci consente di avere un'idea delle informazioni che verrebbero fornite alle tecnologie per la disabilità durante la consultazione di una pagina web specifica. Le azioni di accessibilità rappresentano la comunicazione nell'altra direzione: consentono alla tecnologia per la disabilità di agire sull'interfaccia utente presentata. Potremmo mostrare queste azioni in DevTools per consentire azioni come "clic", scorrimento o modifica dei valori sulla pagina utilizzando l'API disponibile per le tecnologie per la disabilità.