Domande Frequenti

Concetti

Qual è la differenza tra un progetto Git e un progetto senza Git?

Developer Hub organizza i tuoi risultati in modo diverso a seconda che i tuoi test utilizzino Git:

• Un progetto Git associa i risultati di accessibilità con branch e commit, permettendoti di tracciare i problemi fino a specifici cambiamenti nel codice.
• Un progetto senza Git organizza i risultati come una serie di esecuzioni di test ordinate per timestamp, senza alcun dato Git.
• I dati Git sono disponibili quando si utilizza Axe Watcher, Axe CLI o Axe DevTools per le API Web (che caricano i risultati tramite CLI). I progetti mobili sono sempre senza Git.

Consulta Comprendere i tuoi Risultati e le voci del glossario per Git e senza Git per ulteriori dettagli.

Qual è la soglia a11y e come posso configurarla?

La soglia a11y riflette la tolleranza della tua organizzazione ai problemi di accessibilità e determina cosa viene considerato un fallimento nel tuo pipeline CI/CD:

• Essa è calcolata su due criteri: se contare tutti i problemi o solo quelli nuovi, e quali livelli di impatto includere (Critico è sempre incluso).
• Solo gli amministratori del progetto possono configurare la soglia.

Consulta Modificare la Soglia A11y per dettagli completi.

Cosa significano i livelli di impatto (Critico, Grave, Moderato, Minore)?

Ogni violazione di accessibilità è assegnata a uno dei quattro livelli di impatto, dal più al meno grave:

• Critico: Gli utenti con disabilità sono completamente bloccati dall'accesso o dall'interazione con una funzionalità.
• Grave: Gli utenti con disabilità incontrano notevoli ostacoli nell'interazione con il sito.
• Moderato: Esistono alcuni ostacoli, ma i contenuti base sono comunque accessibili.
• Minore: Problemi meno gravi che richiedono comunque risoluzione per una piena conformità.

Consulta il Glossario per definizioni dettagliate.

Perché gli stessi problemi continuano a essere segnalati come nuovi?

Per decidere se un problema è nuovo, Developer Hub confronta ogni risultato con l'esecuzione precedente per regola, selettore di elementi e URL, come descritto sotto Duplicato nel glossario. Se lo stesso problema sullo stesso elemento viene segnalato come nuovo ad ogni esecuzione, significa che una di queste variabili sta cambiando tra una esecuzione e l'altra. Ci sono due cause comuni.

L'URL cambia tra le esecuzioni. L'URL viene confrontato per intero, quindi un ID di sessione, un timestamp, un parametro che aggira la cache, o qualsiasi altro valore dinamico nella stringa di query fa sembrare ogni esecuzione come una pagina diversa, e ogni problema su un URL che non è stato visto prima viene segnalato come nuovo. Nessuna impostazione normalizza gli URL prima che vengano confrontati, quindi la soluzione è rendere deterministici gli URL che i tuoi test visitano: rimuovi o fissa i parametri volatili nella tua configurazione di test in modo che la stessa pagina produca lo stesso URL ad ogni esecuzione.

Gli ID o le classi dell'elemento cambiano tra le esecuzioni. I framework che generano identificatori come #component-a1b2c3d4 o .form-field-xyz789 ad ogni rendering modificano il selettore dell'elemento, quindi non corrisponde più all'elemento registrato precedentemente. Impostare l'opzione di esecuzione ancestry su true risolve questo problema, perché il selettore di ascendenza descrive l'elemento in base alla sua posizione nell'albero DOM e non contiene ID o classi:

axe: {
  runOptions: {
    ancestry: true
  }
}

Vedi Utilizzo di selettori dinamici per la spiegazione completa, inclusa la configurazione Java e i compromessi dell'abilitazione di ancestry.

Confronti

Ogni conteggio di "problemi nuovi" o "problemi risolti" in Developer Hub deriva dal confronto della scansione attuale con una scansione baseline. Quale scansione viene considerata come baseline dipende da dove stai guardando:

• Confronti tra branch appaiono nella vista Branches. Confrontano l'ultima scansione del tuo branch con l'ultima esecuzione pipeline sul branch predefinito. Un'esecuzione pipeline è una scansione avviata dal tuo pipeline CI/CD, a differenza di un'esecuzione locale dalla macchina di uno sviluppatore; Developer Hub le segnala separatamente per sapere sempre quale scansione del branch predefinito è autorevole. Questo risponde a "cosa cambierebbe se facessi il merge ora?"
• Confronti all'interno del branch appare sulla vista Commits. Confrontano la scansione di un commit con la scansione del commit precedente che ha risultati sullo stesso branch, che non è necessariamente il letterale commit precedente nella tua storia Git: un commit senza scansione viene saltato. Questo risponde a "cosa ha introdotto o risolto questo specifico commit?"

Il GitHub Action non è un terzo tipo di confronto. I conteggi che pubblica in una richiesta di pull sono il confronto all'interno del branch per il commit corrente, non un confronto con il branch predefinito, il che è una comune fonte di confusione poiché spesso ci si aspetta che un controllo PR confronti con il branch in cui verrà effettuato il merge.

Vedi Comprendere i tuoi Risultati per una visione completa.

Come posso determinare cosa cambia da una release all'altra?

La vista Branches in un progetto Git ti consente di monitorare i cambiamenti di accessibilità tra le release utilizzando un confronto tra branch:

• L'ultimo commit esaminato di ciascun branch è confrontato con l'ultima esecuzione del pipeline sul tuo branch predefinito.
• Il confronto mostra il numero totale di problemi, i nuovi problemi introdotti, i problemi risolti e qualsiasi modifica nel numero di stati delle pagine scansionate.

Per vedere cosa è cambiato nei singoli commit all'interno di un branch, consulta Come posso vedere cosa è cambiato da commit a commit all'interno di un branch?

Come posso determinare quale sarà l'impatto di una pull request?

Esegui la tua suite di test nel branch della pull request in modo che i risultati appaiano in Axe Developer Hub:

• Nella vista Branches, ogni branch non predefinito mostra un confronto tra branch e il branch predefinito, mostrando nuovi problemi introdotti, problemi risolti e la differenza totale.
• Se utilizzi il GitHub Action, può pubblicare automaticamente un commento sul PR con un riepilogo e un link ai risultati completi.

Per approfondire cosa ha cambiato ogni commit sul branch, consulta Come posso vedere cosa è cambiato da commit a commit all'interno di un branch?

Come posso vedere cosa è cambiato da commit a commit all'interno di un branch?

Dalla vista Branch, clicca su Visualizza Commit su qualsiasi branch per vedere i suoi commit scansionati individualmente. A differenza dei confronti tra branch nella vista Branch, la vista Commit utilizza confronti all'interno dello stesso branch:

• Ogni commit viene confrontato con il commit precedente scansionato su quel branch, mostrando nuovi problemi, problemi risolti e cambiamenti negli stati delle pagine.
• A comparire saranno solo i commit sui quali è stata eseguita la suite di test.

Per vedere come il branch nel suo complesso si confronta con il branch predefinito, consulta Come posso confrontare un branch con l'ultima esecuzione CI/CD nel branch predefinito?

Come posso confrontare un branch con l'ultima esecuzione CI/CD nel branch predefinito?

La vista Branches esegue automaticamente un confronto tra branch per ciascun branch non predefinito contro l'ultima esecuzione della pipeline del branch predefinito:

• Questo richiede che un amministratore del progetto abbia configurato Axe Watcher per essere eseguito sul branch predefinito come esecuzione di pipeline.
• Il confronto mostra problemi totali, nuovi problemi, problemi risolti e differenze nello stato delle pagine.

Per vedere cosa è cambiato nei singoli commit all'interno di quel branch, consulta Come posso vedere cosa è cambiato da commit a commit all'interno di un branch?

Come posso ottenere risultati di confronto accurati prima di creare una pull request?

Per un confronto tra branch più accurato prima della fusione, mantieni il tuo branch di funzionalità aggiornato con il branch predefinito:

1. Unisci il branch predefinito nel tuo branch di funzionalità (ad esempio, git merge main) prima di eseguire la tua suite di test.
2. Spingi il commit di merge in modo che Axe Developer Hub possa scansionare il branch aggiornato.
3. La vista Branches confronterà quindi il tuo branch contro l'ultima esecuzione della pipeline sul branch predefinito, mostrando solo le modifiche di accessibilità che il tuo branch effettivamente introduce.

Se il tuo branch di funzionalità è arretrato rispetto al branch predefinito, il confronto potrebbe evidenziare problemi già risolti nel branch predefinito ma non ancora fusi nel tuo branch di funzionalità. Fondere prima il branch predefinito elimina questi falsi positivi e riduce le sorprese quando la pull request viene fusa.

Perché vedo problemi segnalati come nuovi o risolti quando è stato eseguito un diverso set di test?

Un confronto è significativo solo quando è stato eseguito lo stesso set di test su entrambi i lati:

• Se un'esecuzione visita una pagina che la scansione di baseline non ha mai visitato, ogni problema su quella pagina viene segnalato come nuovo, perché non c'è nulla con cui confrontarlo.
• Se un'esecuzione salta una pagina coperta dal baseline, i problemi di quella pagina risultano risolti anche se nessuno ha corretto nulla, poiché semplicemente non sono stati testati.
• Due esecuzioni che coprono suite di test veramente differenti non dovrebbero essere confrontate affatto; il risultato non ti dirà nulla di utile.

Questo non è qualcosa che un'impostazione può correggere. Vedi Best Practice per Confronti Accurati per come impostare la tua suite di test affinché i confronti rimangano significativi.

Best Practice per Confronti Accurati

• Usa un progetto per ogni set di test. Un progetto dovrebbe corrispondere a una suite di test. Puntare più suite su un progetto significa che ogni esecuzione si confronta con un baseline prodotto da un diverso set di test, e i conteggi di nuovi e risolti smettono di avere significato.
• Esegui lo stesso set di test ogni volta. Cambiare ciò che la suite copre cambia ciò che il confronto può dirti. Quando la suite si espande legittimamente, aspetta un aumento una tantum nei nuovi problemi all'esecuzione che aggiunge la copertura.
• Imposta un'esecuzione pipeline sul tuo branch predefinito. I confronti cross-branch misurano un branch rispetto all'ultima esecuzione pipeline sul branch predefinito. Senza una di queste non c'è nessun baseline, e ogni problema viene segnalato come nuovo, che è la versione più confusa di questo sintomo. Configurare questo è un compito per l'amministratore del progetto; vedi Informazioni sulla Pipeline.

CI/CD

Come posso assicurarmi che nessun nuovo problema di accessibilità venga fuso nel mio codice?

Integra Axe Developer Hub nel tuo pipeline CI/CD in modo che i controlli di accessibilità vengano eseguiti automaticamente su ogni commit o pull request:

• Se utilizzi GitHub, il Axe Developer Hub GitHub Action può bloccare i PR che introducono errori di accessibilità.
• Per altre piattaforme come GitLab o Bitbucket, utilizza il REST Service per interrogare i risultati e far fallire la tua pipeline quando vengono rilevati problemi.
• Puoi perfezionare ciò che conta come errore configurando il soglia di a11y.

Come posso integrare Axe Developer Hub nel mio pipeline CI/CD se non uso GitHub?

Puoi utilizzare la REST Service API per integrarti con qualsiasi piattaforma CI/CD:

• Il REST Service ti permette di interrogare Axe Developer Hub per risultati dopo l'esecuzione della tua suite di test.
• L'API restituisce il conteggio dei problemi, le nuove violazioni, le violazioni risolte e un link ai risultati completi in Developer Hub.
• Puoi utilizzare questa risposta per approvare o far fallire la tua pipeline in GitLab, Bitbucket, Jenkins o qualsiasi altra piattaforma.

Gestione del Progetto

Come posso visualizzare le scansioni di accessibilità degli altri membri del team su un progetto?

Tutti i membri del progetto possono vedere tutti i risultati all'interno di un progetto condiviso una volta che sono stati aggiunti:

• Aggiungi membri del team tramite la pagina delle impostazioni Membri.
• Nei progetti Git, la vista Rami mostra i risultati raggruppati per chiave API, in modo da poter vedere chi ha eseguito ogni scansione.

Per dettagli su ruoli e permessi, consulta Configurare i Progetti per l'Uso del Team.

Come posso esportare i miei risultati di accessibilità?

Developer Hub offre diversi modi per esportare i tuoi dati:

• Dalla vista riepilogo problemi, clicca sul pulsante Esporta Issue per scaricare i risultati come CSV o JSON.
• Per accesso programmatico, utilizza il REST Service per interrogare i risultati per un commit e progetto specifico.

Consulta Ottenere Risultati Programmati per ulteriori opzioni.