Utilizzare ARIA solo quando l'HTML nativo non è sufficiente

Quando è necessario ARIA e quando un elemento HTML nativo rappresenta la soluzione migliore?

ARIA viene utilizzato solo dopo aver esaminato gli elementi nativi, poiché solo questi forniscono semantica e funzionamento standard combinati. Se un ruolo necessario o uno stato dinamico non sono chiari, il supplemento, inclusa la logica relativa a tastiera, focus e stato, deve essere implementato completamente.

Elemento di output nativo

• Output robusto per tecnologie assistive Il componente è testato con browser e tecnologie assistive anziché derivare la sua accessibilità da un markup valido.

Caso d'uso: "Mockup del ruolo"

Un fisarmonica inizialmente può essere aperto solo cliccando su un'intestazione. La correzione sostituisce il contenitore cliccabile con un pulsante reale, lo collega all'area dei contenuti e mantiene ARIA espanso sincronizzato; la logica dei tasti freccia non è implementata perché il modello scelto non la richiede.

Modello di interazione completo

1. Innanzitutto, modellare l'attività utente specifica utilizzando `button`, `a`, `input`, `details` o un altro elemento nativo appropriato.

2. Aggiungere solo il significato che non può essere espresso nativamente e implementare completamente la logica relativa a tastiera, focus e stato.

3. Testare il componente finale in ogni stato utilizzando la tastiera e combinazioni rappresentative di screen reader/browser.

Ruolo fittizio

• Ruolo fittizio A un `div` viene assegnato un ruolo ARIA, ma mancano sia il controllo da tastiera previsto sia le modifiche di stato affidabili.

• Semantica sovrascritta Attributi aggiuntivi modificano il significato nativo già corretto e producono annunci contraddittori.

• Transizione di stato non verificata aria-expanded o aria-selected rimangono errati dopo un'interazione e segnalano uno stato obsoleto alle tecnologie assistive.

Output robusto per tecnologie assistive

• Percentuale di componenti interattivi personalizzati per i quali sono documentati l'alternativa nativa mancante e il modello ARIA scelto.

• Numero di stati verificati in cui ruolo, nome accessibile, comportamento della tastiera e stato di output rimangono coerenti.

Quali domande attivano ulteriori verifiche dopo aver "utilizzato ARIA solo come supplemento mirato"?

È disponibile una risorsa approfondita adeguata. Scrivere un testo alternativo che descriva la funzione dell'immagine anziché il suo contenuto."In che modo il testo alternativo descrive la funzione di un'immagine anziché solo i dettagli visibili? "

Inoltre: Evitare la navigazione JavaScript senza link reali..

Se si desidera implementare concretamente l'utilizzo di ARIA solo come supplemento mirato, è possibile fare riferimento a: Sistemi web robusti Questo documento si concentra su "Semantica nativa e struttura della pagina" e "Elemento sorgente nativo".

Conclusione: Utilizzare ARIA solo come supplemento mirato.

ARIA può integrare la semantica mancante, ma non può correggere comportamenti di interazione incompleti. L'elemento nativo rimane il punto di partenza più robusto.

Fonti e ulteriori informazioni

Queste fonti primarie rendono comprensibili i presupposti, i limiti del sistema e i metodi di test per l'utilizzo di ARIA solo come supplemento mirato.

• Intestazioni - Iniziativa W3C per l'accessibilità webGuida ufficiale all'implementazione per i ranghi delle intestazioni, l'organizzazione dei contenuti e le relazioni con le regioni della pagina.

• ARIA in HTML — Raccomandazione W3CL'attuale raccomandazione W3C definisce quali ruoli e attributi ARIA sono aggiunte consentite alla semantica HTML e quali usi ridondanti o contraddittori dovrebbero essere evitati.

• Standard HTML: Semantica – WHATWGSpecifica primaria per i ruoli e le strutture semantiche degli elementi HTML nativi.