Chrome DevTools sta lanciando un albero di accessibilità completo che consente agli sviluppatori di ottenere più facilmente una panoramica dell'intero albero. In questo post scoprirai come è stato 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 di base di questa API è l'albero dell'accessibilità: una struttura di oggetti di accessibilità su cui le tecnologie per la disabilità possono interrogare attributi e proprietà ed eseguire azioni. 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 vengono esposti alle tecnologie per la disabilità. Concretamente, quando viene selezionato un nodo nel visualizzatore ad 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 è stato creato l'albero?
Prima di vedere come si presenta questa nuova visualizzazione ad albero completa in DevTools, analizziamo brevemente cos'è l'albero dell'accessibilità in termini più tangibili. L'albero dell'accessibilità è un derivato dell'albero DOM. La sua struttura è più o meno la stessa, ma è stata semplificata per rimuovere i nodi senza contenuto semantico, come un elemento <div> utilizzato esclusivamente per lo stile. Ogni nodo nell'albero ha un ruolo, ad esempio Button o Heading, e spesso un nome che può derivare dagli attributi ARIA o dai contenuti del nodo. Se guardiamo 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 di Chromium, chiamato Blink, ricava un albero di accessibilità interna all'incirca 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 ruolo genericContainer, il 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 nell'albero interno e non sarebbe esposta alle tecnologie per la disabilità. Poiché DevTools raccoglie le informazioni sull'accessibilità direttamente dal processo del renderer, questa è la rappresentazione ad albero gestita da DevTools.
Albero dell'accessibilità completo in DevTools
Il nuovo albero di accessibilità completo è sincronizzato con l'albero DOM per consentire agli sviluppatori di passare da una struttura all'altra. Ci auguriamo che il nuovo albero si riveli più esplorabile, utile e più facile da utilizzare.
Ora che sai come funziona l'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 mostrare 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 ti consentiva di esplorare solo un singolo nodo e i relativi predecessori.
Ora, quando attivi/disattivi la nuova struttura ad albero, questa sostituisce la visualizzazione ad albero DOM e consente di vedere l'albero dell'accessibilità completa per la pagina:
Costruzione di alberi lenti
Per migliorare le prestazioni dell'albero anche nei siti più grandi, l'albero viene pigramente costruito sul front-end durante l'esplorazione. Una volta espanso un nodo nell'albero, i nodi secondari vengono recuperati tramite il protocollo CDP (Chrome DevTools) e l'albero viene ricreato.
Live
La nuova visualizzazione ad albero è attiva e si aggiorna in modo dinamico se l'albero dell'accessibilità cambia nel renderer. Si aggancia agli stessi meccanismi che notificherebbero alla tecnologia per la disabilità le modifiche all'albero e lo utilizza per inviare eventi al frontend di DevTools con i nodi aggiornati. In pratica, il backend CDP rimane in ascolto degli aggiornamenti della struttura ad albero, tiene traccia dei nodi richiesti in precedenza e invia eventi al frontend di DevTools se uno di questi nodi cambia.
La storia di molti alberi
Nella descrizione di cos'è l'albero dell'accessibilità hai imparato in che modo Blink crea un albero dell'accessibilità per il DOM di cui sta eseguendo il rendering e DevTools recupera questo albero tramite CDP. Sebbene sia vero, abbiamo tralasciato alcune complicazioni nella 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 in merito a quale parte delle caratteristiche 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 su tutte le piattaforme, l'API per interagire 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 più siti e più frame
Poiché Chromium non solo inserisce i contenuti di ogni scheda in processi del renderer diversi, ma isola anche i documenti di più siti in diversi processi del renderer, dobbiamo connetterci a ogni documento figlio out-of-process separatamente su CDP e recuperare il relativo albero dell'accessibilità. Quindi cuciamo questi sottoalberi sul frontend per dare l'illusione di un albero coerente, anche se si trovano in processi di rendering diversi in Chromium.
Nodi ignorati e non interessanti
Alcuni nodi sono nascosti per impostazione predefinita: quelli ignorati e quelli con il ruolo "generico" senza nome. Questi nodi non hanno alcun significato semantico e, nel caso di nodi ignorati, non sono esposti alle tecnologie per la disabilità. Questi nodi vengono nascosti per evitare di ingombrare la visualizzazione ad albero. In caso contrario, l'albero dell'accessibilità per la maggior parte delle pagine web avrebbe un aspetto simile al seguente:
L'avvertenza è che questo significa essenzialmente che dobbiamo costruire un altro albero rispetto a quello disponibile nel backend. Ad esempio, supponiamo di avere i nodi A, B, C e X, dove A ha i nodi X e B e X ha i nodi figlio C. Se X è un nodo ignorato, eliminiamo X dall'albero e creiamo invece un albero in cui C è un elemento figlio di A.
Sul frontend, costruiamo l'intero albero, inclusi i nodi ignorati, e li eliminiamo solo poco prima di eseguire il rendering dei nodi. Ciò avviene 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 nell'esempio il nodo B viene rimosso, riceveremo un aggiornamento per il nodo X (poiché i suoi elementi figlio sono cambiati), ma se lo eliminassimo avremmo avuto difficoltà a capire cosa aggiornare.
- garantisce che tutti i nodi DOM abbiano un nodo di accessibilità corrispondente. Quando si attiva/disattiva la struttura ad albero, selezioniamo il nodo corrispondente al nodo attualmente selezionato nell'albero DOM. Quindi, nell'esempio precedente, se l'utente attiva/disattiva la struttura ad albero mentre è selezionato il nodo DOM corrispondente a X, iniettiamo X tra i nodi A e B e selezioniamo X nell'albero. Ciò consente all'utente di ispezionare il nodo di accessibilità per tutti i nodi DOM e può aiutare a determinare perché il nodo viene ignorato.
Idee per il futuro
Il lancio del nuovo albero dell'accessibilità è solo l'inizio. Abbiamo alcune idee per progetti futuri che potremmo basare sulla nuova visualizzazione, ma siamo anche impazienti di ascoltare il tuo feedback.
Filtri alternativi
Come spiegato in precedenza, al momento escludiamo i nodi considerati non 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 delle "best practice per l'accessibilità" nell'albero ed evidenziare i problemi di accessibilità direttamente sui nodi che causano problemi.
Azioni di accessibilità della superficie in DevTools
L'albero attualmente visualizzato è a senso unico: ci permette di avere un'idea delle informazioni che verrebbero fornite alle tecnologie per la disabilità durante la navigazione di una pagina web specifica. Le azioni di accessibilità rappresentano la comunicazione nella direzione opposta: consentono alle tecnologie per la disabilità di agire sull'interfaccia utente mostrata. Potremmo mostrare queste azioni in DevTools per consentire azioni come "fare clic", scorrere o modificare i valori nella pagina utilizzando l'API disponibile per le tecnologie per la disabilità.