Glossario di Axe Developer Hub

a11y

Abbreviazione basata sui numeri (o numeronimo) per la parola "accessibilità", con "11" (undici) che rappresenta il numero di caratteri tra l'inizio "a" e la fine "y" in accessibilità. Si pronuncia come ally.

Chiave API

Per l'autorizzazione, genererai un chiave API in Impostazioni dell'Account Axe. Puoi utilizzare lo stesso API Key per più progetti, sebbene tu debba usare un API Key di Axe Developer Hub solo per progetti web e un API Key di Axe DevTools Mobile solo per progetti mobili.

Tratta la tua chiave API come una credenziale segreta: non inserirla nel controllo di versione, non condividerla e conservala in una variabile d'ambiente o nel gestore di segreti della tua piattaforma CI/CD.

Axe Developer Hub

Axe Developer Hub ti consente di creare nuovi progetti di test e ti mostra i risultati delle tue sessioni di test di accessibilità. Puoi creare quanti progetti desideri per visualizzare e gestire l'accessibilità dei tuoi siti web e delle tue app mobili.

Baseline

Un baseline è la scansione precedente che Developer Hub tiene costante affinché un confronto possa misurare le modifiche. Quale scansione serve come baseline dipende dal tipo di confronto: un confronto tra rami utilizza l'ultima esecuzione della pipeline sul ramo predefinito, e un confronto all'interno del ramo, insieme a GitHub Action, utilizza la scansione dall'ultimo commit che ha risultati sullo stesso ramo.

Best Practices

I best practices di Deque sono tecniche collaudate che forniscono i risultati desiderati in termini di accessibilità quando mancano o sono insufficienti metodi formali specifici. Anche se non sono ufficialmente inclusi in alcun insieme di regole di accessibilità stabilite, seguire le migliori pratiche di Deque può migliorare l'accessibilità e la qualità generale della pagina web testata. Va notato che la non conformità alle linee guida sulle migliori pratiche di Deque non indica automaticamente un fallimento. Inoltre, è necessaria una valutazione esperta per considerare l'adeguatezza nel contesto degli obiettivi dell'applicazione, del sito o della pagina. A volte, la tecnica di accessibilità delle migliori pratiche non è applicabile o pratica per risolvere un problema specifico. Vedi Best Practices per le regole che compongono il set di regole delle migliori pratiche.

ID Build

Il ID build viene generato automaticamente come UUID se non fornito dall'utente e viene utilizzato per collegare le scansioni come una singola sessione di test. Quando si esegue una suite di test su più macchine o ambienti, fornire un ID build collegherà tutte queste esecuzioni e verrà visualizzato come una singola sessione in Developer Hub.

Confronto tra rami

Un confronto tra rami confronta l'ultima scansione di un ramo con l'ultima esecuzione della pipeline sul ramo predefinito del progetto. Appare nella vista Rami e mostra cosa cambierebbe se il ramo venisse unito ora.

Forma dei Dati

La forma dei dati di un progetto è o repository Git o Gitless: se i suoi risultati contengono informazioni di Git (repository, ramo e commit) o meno. La forma dei dati di un progetto è impostata dal suo blocco del progetto.

Duplicato

Un duplicato è lo stesso problema di accessibilità visto sullo stesso nodo del modello a oggetti del documento (DOM) in più stati della pagina. Se risolvi un problema con duplicati, tutti i suoi duplicati scompariranno poiché sono tutti lo stesso problema.

Due risultati sono trattati come lo stesso problema quando tutti e tre i seguenti coincidono:

• La regola che è stata violata.
• Il elemento. Axe Developer Hub identifica l'elemento tramite il suo selettore CSS e il suo XPath, e anche tramite il selettore di ascendenza quando ancestry è abilitato; una corrispondenza su uno qualsiasi di questi è sufficiente.
• L'URL della pagina, confrontato per intero, inclusa qualsiasi stringa di query.

Nient'altro viene confrontato. In particolare, il titolo della pagina e l'HTML dell'elemento non influenzano se un risultato è considerato un duplicato.

La deduplicazione attualmente si applica solo ai progetti web. I risultati mobili non hanno un selettore CSS, quindi questo confronto non corrisponde mai, e ogni risultato mobile è considerato nuovo in ogni confronto, senza possibilità di modifica.

Lo stesso confronto determina se un risultato web è nuovo: un risultato che non corrisponde a nulla nella baseline applicabile è considerato nuovo. Vedi Perché gli stessi problemi continuano a essere segnalati come nuovi? per sapere come correggere questo.

Test E2E

Il test end-to-end, o e2e, si riferisce al test della funzionalità di un'intera applicazione web attraverso la verifica della sua implementazione nel mondo reale. Con Axe Developer Hub, puoi testare scenari e2e per problemi di accessibilità.

Regole Sperimentali

Le regole sperimentali sono ancora in fase di sviluppo e test per affrontare nuove tecnologie o una maggiore comprensione e consapevolezza delle problematiche di accessibilità. Queste regole non dovrebbero essere utilizzate in ambienti di produzione poiché sono ancora in sviluppo e sono soggette a falsi positivi. Alla fine, le regole in questo insieme di regole potrebbero diventare parte degli standard di accessibilità. Le regole sperimentali sono disabilitate per impostazione predefinita. Vedi Regole Sperimentali per le regole che compongono questo insieme nella versione più recente di axe-core.

repository Git

repository Git è una forma dei dati a cui un progetto di Developer Hub può bloccarsi: la suite di test del progetto utilizza un repository Git. Utilizzare Git consente di associare i difetti di accessibilità al codice su diversi rami e in commit specifici, facilitando la loro risoluzione.

Gitless

Gitless è l'altro forma dei dati a cui un progetto di Developer Hub può bloccarsi: la suite di test del progetto non utilizza un repository Git. Anche se non è necessario, un repository Git permette di associare i difetti di accessibilità a modifiche di codice specifiche, facilitando la loro risoluzione.

Impatto

A ogni violazione di accessibilità viene assegnato un livello impatto, categorizzato in quattro livelli dal meno al più impattante: minori, moderati, serio e critico. Questa metrica aiuta a dare priorità agli sforzi di correzione, e gli esperti di accessibilità di Deque assegnano un livello di impatto a ciascun tipo di violazione per impostazione predefinita.

I difetti con livelli di impatto serio o critico presentano barriere significative o insormontabili per gli utenti con disabilità, con la più alta responsabilità legale. Anche se i problemi minori e moderati non sono così gravi, sono comunque cruciali per la conformità e per rispondere alle esigenze delle persone con disabilità.

I quattro livelli utilizzati per categorizzare l'impatto delle problematiche di accessibilità sono:

1. Minore: Problemi che colpiscono gli utenti con disabilità meno dei problemi moderati ma richiedono ancora una risoluzione per una piena conformità.

2. Moderato: Alcune barriere esistono per gli utenti con disabilità, ma non impedirebbero loro di accedere ai contenuti e 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à.

3. Serio: Gli utenti con disabilità affronteranno barriere significative quando interagiscono con il sito, causando frustrazione e difficoltà nell'accesso ai contenuti correlati. La risoluzione dovrebbe essere una priorità alta per evitare azioni legali.

4. Critico: Gli utenti con disabilità sono completamente bloccati dall'accesso o dall'interazione con una funzione sulla pagina web, rendendo il contenuto inaccessibile e lasciando la tua organizzazione altamente vulnerabile a denunce legali. La risoluzione dei problemi critici dovrebbe essere una massima priorità.

Suite di Test Modificata

Un suite di test modificata è una suite di test che hai modificato seguendo le istruzioni fornite da Axe Developer Hub quando hai creato un nuovo progetto. Modificare la tua suite di test ti consente di aggiungere test di accessibilità alla tua suite di test esistente con modifiche minime alla suite stessa.

Necessita revisione

Un Necessita revisione risultato è uno in cui axe-core non è stato in grado di determinare con certezza se qualcosa costituisce una violazione, quindi è necessaria l'ispezione da parte di una persona. Consulta Necessita revisione nel glossario di Axe DevTools per Web per la definizione completa. Axe Developer Hub non mostra i risultati che necessitano di revisione nella sua interfaccia né li include in nessun totale di problemi o nel punteggio di accessibilità. Appaiono solo nell'Esportazione JSON universale di Axe e nei risultati in formato completo restituiti dall'API delle sessioni e dei risultati.

Amministratore Organizzativo

Un amministratore organizzativo (amministratore dell'organizzazione) è un utente con privilegi amministrativi per l'intera impresa in Axe Account. Gli amministratori dell'organizzazione possono visualizzare tutti i progetti della loro impresa e gestire i membri e le impostazioni dei progetti, indipendentemente dal fatto che siano membri di un determinato progetto. Lo status di amministratore dell'organizzazione ha la precedenza sui ruoli a livello di progetto. Gli amministratori dell'organizzazione devono avere una licenza attiva di Axe Developer Hub o Axe DevTools for Mobile per creare nuovi progetti o inviare risultati ai progetti di cui sono membri in Axe Developer Hub, ma possono gestire i progetti esistenti senza una licenza.

Stato della Pagina

Il stato della pagina si riferisce allo stato del modello a oggetti del documento (DOM) di una pagina web in un momento specifico. Visualizzare diversi stati della pagina è utile per siti 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 selezionato dei pulsanti di opzione e delle caselle di controllo

Quando si utilizza Watcher, il pacchetto esegue nuovamente la scansione delle pagine web ogni volta che rileva cambiamenti al DOM e salva un nuovo stato della pagina ogni volta.

Esecuzione della Pipeline

Un esecuzione della pipeline è una scansione attivata da una pipeline CI/CD, piuttosto che un'esecuzione locale da una macchina di uno sviluppatore. Developer Hub etichetta le esecuzioni della pipeline separatamente in modo che sappia sempre quale scansione di un ramo è autorevole. Un'esecuzione della pipeline configurata sul ramo predefinito del progetto è necessaria affinché i confronti tra rami abbiano una baseline; senza di essa, ogni problema viene segnalato come nuovo. Vedi Informazioni sulla Pipeline e Axe Watcher in Ambienti di Integrazione Continua (CI).

Progetto

Un progetto in Axe Developer Hub contiene risultati di accessibilità, informazioni sui test eseguiti e dati di Git (rami e commit). Si crea e si assegna un nome a un nuovo progetto in Developer Hub, il che crea un ID progetto da utilizzare con i tuoi test per identificare il progetto e associare i dati dei risultati con il progetto. Una volta che un progetto assume la sua prima sessione di successo, la sua forma dei dati e, per i progetti Git, il suo repository, sono fissati dal suo blocco del progetto.

Amministratore del Progetto

Un amministratore del progetto è un membro del progetto con permessi elevati. Gli amministratori del progetto possono fare tutto ciò che può fare un membro, oltre a gestire le impostazioni del progetto, aggiungere o rimuovere membri e cambiare i ruoli dei membri. Quando si utilizza Axe Watcher, è necessario l'API Key di un amministratore del progetto per eseguire test in una pipeline.

ID Progetto

Un ID Progetto è generato automaticamente quando aggiungi un nuovo progetto, per associare i tuoi dati dei risultati a quel progetto. Sia un ID progetto che una chiave API sono necessari per inviare risultati di accessibilità a Developer Hub. Mappa un ID progetto a una suite di test/repository: ciò è imposto dal blocco del progetto, che fissa la forma dei dati e il repository di un progetto dopo la sua prima sessione di successo.

Blocco del Progetto

Una volta che un progetto assume la sua prima sessione di successo, esso blocchi a quella sessione forma dei dati e, per i progetti Git, al repository di quella sessione. Un progetto bloccato rifiuta qualsiasi esecuzione successiva con una forma dei dati diversa o un repository diverso all'ingestione; i risultati non vengono salvati. Le impostazioni del progetto mostrano la forma dei dati bloccata e il repository come sola lettura. Vedi Esecuzione Rifiutata: Forma dei Dati o Repository Non Corrispondono al Progetto.

Membro del Progetto

Un membro del progetto è un utente che è stato aggiunto a un progetto di Axe Developer Hub. I membri del progetto possono eseguire test e visualizzare i risultati all'interno del progetto. I membri devono avere una licenza attiva per accedere al progetto.

Scansione

Una scansione sono i risultati di accessibilità che Developer Hub riceve dal testare il tuo prodotto, e ciò che una scansione copre varia a seconda del tipo di progetto.

Per i progetti web, una scansione è l'insieme completo di risultati che la tua suite di test produce in una sola esecuzione, per quanti pagine possa visitare nel tragitto, inviate a Developer Hub tramite Axe Watcher, Axe DevTools per Web CLI o le API Web, che caricano tramite il CLI. Ogni pagina che controlla può produrre una o più stati della pagina, una per ogni stato DOM distinto rilevato, come una applicazione single-page che cambia stato senza ricaricare la pagina; la scansione è l'intera raccolta di stati della pagina da quell'esecuzione.

Per i progetti mobili, una scansione è il risultato del test di una singola schermata dell'app con Axe DevTools Mobile Analyzer. Testare diverse schermate in una sola seduta produce diverse scansioni, che sono raggruppate insieme sotto una sola sessione.

SHA

Quando crei un commit con Git, viene creato un ID per identificare univocamente il commit. Questo ID unico è chiamato SHA (così chiamato dai Secure Hash Algorithms, un gruppo di funzioni hash crittografiche).

Tag

Un tag raggruppa le regole che appartengono a una specifica linea guida di accessibilità, come WCAG. Per ulteriori informazioni sulle regole e sui tag a cui appartengono, vedi Descrizioni delle Regole di axe-core

WCAG

WCAG, o Linee Guida per l'Accessibilità dei Contenuti Web, sono un insieme di linee guida sviluppate dal World Wide Web Consortium (W3C) per aiutare a rendere i contenuti web più accessibili alle persone con disabilità. Queste linee guida forniscono un quadro per creare siti web e contenuti digitali accessibili che possono essere utilizzati da persone con una vasta gamma di disabilità.

I tre livelli di conformità delle 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, mentre il livello di conformità AAA è il più rigoroso. Il livello di conformità AA richiede il rispetto sia dei criteri di successo del livello A che del livello AA. Il rispetto di tutti e tre i livelli di criteri di successo (A, AA e AAA) è richiesto per la conformità al livello AAA.

Le WCAG 1.0 sono state la prima versione di queste linee guida e sono state pubblicate nel 1999. Le WCAG 2.0 sono state pubblicate nel 2008 e hanno fornito linee guida più complete per rendere i contenuti web accessibili a persone con una gamma più ampia di disabilità.

Le WCAG 2.1 sono state pubblicate nel 2018. Si basano sulle versioni precedenti e includono nuovi criteri di successo per affrontare problemi di accessibilità emersi dal rilascio delle WCAG 2.0. Le WCAG 2.1 offrono anche più indicazioni sull'accessibilità mobile, per persone con problemi di vista e disabilità cognitive e di apprendimento.

Le WCAG 2.2, l'iterazione più recente di queste linee guida, sono state pubblicate nel 2023 e offrono nove nuovi criteri di successo rispetto alle WCAG 2.1. Forniscono una guida migliorata per affrontare le esigenze degli utenti con disabilità cognitive o di apprendimento, utenti con problemi di vista e utenti con disabilità su dispositivi mobili. Sono retrocompatibili con le WCAG 2.1.

Confronto all'interno del ramo

Un confronto all'interno del ramo confronta la scansione di un commit con la scansione dal commit precedente che ha risultati sullo stesso ramo. Appare nella vista Commit e mostra cosa ha introdotto o corretto un commit specifico.