Glossario dell'hub degli sviluppatori di axe
Termini utili per comprendere axe Developer Hub
a11y
Chiave API ** * ** ** **** Pronunciato allegro.
Chiave API
Una chiave API viene creata da axe Developer Hub ogni volta che crei un nuovo progetto. La chiave collega le esecuzioni dei test e i relativi risultati con un determinato progetto. Deve essere impostato nella suite di test per consentire che i suoi risultati siano associati a un progetto specifico.
axe Developer Hub
axe Developer Hub consente di creare nuovi progetti di test e mostra i risultati dei test di accessibilità eseguiti. È possibile filtrare i risultati per data, ID sessione e gravità. Puoi monitorare i risultati di accessibilità e raggrupparli in base all'ID di sessione. Puoi creare tutti i progetti di cui hai bisogno per monitorare diversi siti web.
Il pacchetto @axe-core/watcher
Puoi integrare ** il pacchetto @axe-core/watcher** nella suite di test del tuo sito web per analizzare le pagine web e segnalare i risultati ad axe Developer Hub, dove potrai visualizzarli. Il pacchetto @axe-core/watcher analizza anche il commit e il branch Git correnti e associa le esecuzioni dei test al commit corrente. Durante il test del tuo sito web, il pacchetto @axe-core/watcher supporta solo Google Chrome. Vedere Requisiti di sistema.
Migliori pratiche
Le migliori pratiche Deque sono tecniche collaudate che forniscono i risultati di accessibilità desiderati quando specifici metodi formali sono carenti o insufficienti. Sebbene non siano ufficialmente incluse in nessuna serie di regole di accessibilità stabilite, seguire le best practice di Deque può migliorare l'accessibilità e la qualità complessiva della pagina web testata. È opportuno sottolineare che la mancata osservanza delle linee guida di Deque sulle buone pratiche non indica automaticamente un fallimento. Inoltre, è necessario il giudizio di un esperto per valutare l'appropriatezza nel contesto degli obiettivi dell'applicazione, del sito o della pagina. A volte le tecniche di accessibilità considerate migliori pratiche non sono applicabili o pratiche per risolvere un problema specifico. Consultare Best Practices per le regole che costituiscono il set di regole delle best practice.
Piattaforma di automazione del browser
Una piattaforma di automazione del browser è un framework che puoi utilizzare per automatizzare i test del tuo sito web. Le piattaforme includono Cypress, Playwright, Puppeteer, WebdriverIO e WebDriverJS. Per ulteriori informazioni, vedere
Test dei componenti
Con Cypress o Playwright è possibile testare i singoli componenti (ad esempio i componenti React). Confrontalo con e2e Testing, che testa l'intera applicazione web nella sua implementazione nel mondo reale. Axe Developer Hub è in grado di rilevare problemi di accessibilità solo in scenari end-to-end e non è progettato per testare i componenti in modo isolato. Vedere Test E2E.
Sostituzione della configurazione
Una sostituzione della configurazione consente di personalizzare le impostazioni per esecuzioni di test specifiche tramite la proprietà configurationOverrides nella configurazione del test. Tali sostituzioni devono essere conformi alle impostazioni di configurazione globali della tua organizzazione e possono includere modifiche agli standard di accessibilità, alle best practice, alle regole sperimentali e alle versioni axe-core.
Duplicato
Un duplicato è lo stesso problema di accessibilità riscontrato sullo stesso nodo del modello di oggetti del documento (DOM) in più stati di pagina. Se risolvi un problema con i duplicati, tutti i duplicati scompariranno perché riguardano tutti lo stesso problema.
Test e2e
Il testing end-to-end, o e2e, si riferisce al collaudo dell'intera funzionalità dell'applicazione web verificandone l'implementazione nel mondo reale. **** Con axe Developer Hub è possibile testare scenari e2e per problemi di accessibilità, ma non è possibile testare singoli componenti in modo isolato, come invece fanno Cypress e Playwright. Vedere anche Test dei componenti.
Regole sperimentali
Le regole sperimentali sono ancora in fase di sviluppo e test per far fronte alle nuove tecnologie o per una maggiore comprensione e consapevolezza delle problematiche di accessibilità. Non ci si dovrebbe basare su queste regole negli ambienti di produzione perché sono ancora in fase di sviluppo e sono soggette a falsi positivi. Col tempo, le regole contenute in questo insieme di regole potrebbero diventare parte degli standard di accessibilità. Per impostazione predefinita, le regole sperimentali sono disabilitate. Consultare Regole sperimentali per le regole che compongono questo set di regole nell'ultima versione di axe-core.
Svuotare
La funzione flush scrive i risultati del test sul server Deque ed è necessaria per garantire che i risultati vengano registrati da axe Developer Hub. Devi chiamare la funzione flush nella tua suite di test.
Gitless
Gitless si riferisce all'utilizzo del pacchetto @axe-core/watcher senza un repository Git. Non è obbligatorio utilizzare un repository Git, ma un repository Git consente di associare i difetti di accessibilità a specifiche modifiche del codice, facilitandone la risoluzione.
Configurazione globale
La configurazione globale è parte della Configurazione axe che consente di impostare varie opzioni in un unico posto da condividere tra diversi prodotti Deque. L'amministratore può consentire agli utenti di modificare determinate impostazioni.
Impatto
A ogni violazione dell'accessibilità viene assegnato un livello di impatto, suddiviso in quattro livelli, dal meno al più impattante: **minore, ** moderato, *grave e *critico. ** ** ** Questa metrica aiuta a stabilire le priorità degli sforzi di correzione e gli esperti di accessibilità di Deque assegnano per impostazione predefinita un livello di impatto a ciascun tipo di violazione.
I difetti con livelli di impatto grave o critico rappresentano barriere significative o insormontabili per gli utenti con disabilità, con la massima responsabilità legale. Sebbene i problemi minorie moderatinon siano così gravi, sono comunque fondamentali per la conformità e per soddisfare le esigenze delle persone con disabilità. **
I quattro livelli utilizzati per categorizzare l'impatto dei problemi di accessibilità sono:
-
Minore: problemi che interessano gli utenti con disabilità meno dei problemi moderati ma che richiedono comunque una risoluzione per garantire la piena conformità.
-
Moderato: Esistono alcune barriere per gli utenti con disabilità, ma non impedirebbero loro di accedere ai contenuti o ai flussi di base. Questi problemi potrebbero rendere la tua organizzazione vulnerabile ad azioni legali e dovrebbero essere risolti prima di raggiungere la piena conformità.
-
Grave: gli utenti con disabilità incontreranno notevoli ostacoli nell'interazione con il sito, il che causerà frustrazione e difficoltà nell'accesso ai contenuti correlati. La correzione dovrebbe essere una priorità assoluta per evitare azioni legali.
-
Critico: agli utenti con disabilità viene completamente impedito di accedere o interagire con una funzionalità della pagina web, rendendo il contenuto inaccessibile e rendendo la tua organizzazione altamente vulnerabile a cause legali. La risoluzione dei problemi critici dovrebbe essere una priorità assoluta.
Modalità manuale
Per impostazione predefinita, axe Developer Hub analizza automaticamente ciascuna delle tue pagine web e le rianalizza ogni volta che rileva un nuovo stato della pagina. È possibile disattivare questo comportamento automatico impostando la proprietà autoAnalyze sull'oggetto di configurazione axe su false. È anche possibile ignorare il comportamento dell'analisi automatica utilizzando il metodo stop . In entrambi i casi, questo mette Watcher in modalità manuale. In modalità manuale, le pagine vengono analizzate solo quando si richiama il metodo analyze .
Suite di test modificata
Una suite di test modificata è una suite di test che hai modificato in base alle istruzioni fornite da axe Developer Hub quando hai creato un nuovo progetto. Modificando la suite di test è possibile aggiungere test di accessibilità alla suite di test esistente apportando modifiche minime alla suite di test stessa.
Stato della pagina
Lo stato della pagina di una pagina web si riferisce allo stato del suo modello di oggetto del documento (DOM) in un momento specifico. Gli stati delle pagine sono utili per i siti web complessi con schermate di accesso o interfacce utente dinamiche, come le applicazioni a pagina singola (SPA). Esempi di stato DOM includono:
- La visibilità degli elementi
- Il contenuto degli elementi
- Lo stato di selezione dei pulsanti di scelta e delle caselle di controllo
Il pacchetto @axe-core/watcher esegue una nuova scansione delle pagine web quando rileva modifiche al DOM e salva ogni volta un nuovo stato della pagina.
Progetto
Un progetto in axe Developer Hub contiene risultati di accessibilità, informazioni sui test eseguiti e dati Git (rami e commit). L'associazione tra queste informazioni e il progetto avviene tramite la chiave API del progetto. Crei e assegni un nome a un nuovo progetto in axe Developer Hub, che crea una chiave API da utilizzare con i tuoi test per identificare il progetto.
ID sessione
L' ID di sessione viene generato automaticamente come UUID e identifica il login di un utente su una particolare macchina. In genere, la maggior parte degli utenti non richiede di modificare l'ID di sessione. Tuttavia, se è necessario distinguere tra diverse esecuzioni di test, è possibile utilizzare ID di sessione diversi. Si dovrebbe utilizzare un ID univoco globale, come un UUID, per evitare possibili conflitti di ID di sessione nella stessa organizzazione.
SHA
Quando si crea un commit con Git, viene creato un ID per identificare in modo univoco il commit. L'ID univoco è denominato SHA (dal nome di Secure Hash Algorithms, un gruppo di funzioni hash crittografiche).
Tag
Un tag raggruppa le regole che appartengono a una specifica linea guida sull'accessibilità, come WCAG. Per maggiori informazioni sulle regole e sui tag a cui appartengono, vedere Descrizioni delle regole di axe-core
WCAG
Le WCAG, o Linee guida per l'accessibilità dei contenuti Web, sono un insieme di linee guida sviluppate dal World Wide Web Consortium (W3C) per contribuire a rendere i contenuti Web più accessibili alle persone con disabilità. Queste linee guida forniscono un quadro per la creazione di siti web accessibili e contenuti digitali che possano essere utilizzati da persone con un'ampia gamma di disabilità.
I tre livelli di conformità WCAG sono definiti da una serie di criteri di successo che descrivono elementi specifici del contenuto web che devono essere soddisfatti per raggiungere quel livello di conformità. Il livello di conformità A è il livello minimo di conformità, mentre il livello di conformità AAA è il più rigoroso. Il livello di conformità AA richiede la conformità sia ai criteri di successo del livello A che a quelli del livello AA. Per essere conformi al livello AAA è richiesta la conformità a tutti e tre i livelli dei criteri di successo (A, AA e AAA).
WCAG 1.0 è stata la prima versione di queste linee guida ed è stata pubblicata nel 1999. WCAG 2.0 è stata pubblicata nel 2008 e ha fornito linee guida più complete per rendere i contenuti web accessibili a persone con una più ampia gamma di disabilità.
WCAG 2.1 è stato pubblicato nel 2018. Si basa sulle versioni precedenti e include nuovi criteri di successo per affrontare i problemi di accessibilità emersi dopo il rilascio di WCAG 2.0. WCAG 2.1 fornisce inoltre ulteriori indicazioni sull'accessibilità mobile, sull'accessibilità per ipovedenti e sulle disabilità cognitive e di apprendimento.
WCAG 2.2, l'iterazione più recente di queste linee guida, è stata pubblicata nel 2023 e offre nove nuovi criteri di successo rispetto a WCAG 2.1. Fornisce una guida migliorata per soddisfare le esigenze degli utenti con disabilità cognitive o di apprendimento, degli utenti con problemi di vista e degli utenti con disabilità sui dispositivi mobili. È retrocompatibile con WCAG 2.1.
Wrapping
Il wrapping si riferisce alla modifica di una piattaforma di automazione del browser (ad esempio Cypress) per richiamare il codice di test di accessibilità (nel pacchetto @axe-core/watcher) ogni volta che viene chiamata una funzione della piattaforma di automazione del browser. Il wrapping consente di integrare i test di accessibilità nelle suite di test esistenti con modifiche minime al codice.