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 risalire ai problemi specifici del codice.
• Un progetto senza Git organizza i risultati come una serie di test eseguiti ordinati 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.

Vedi 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.

Vedi Modificare la Soglia A11y per tutti i dettagli.

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à affrontano significativi ostacoli durante l'interazione con il sito.
• Moderato: Esistono alcuni ostacoli, ma il contenuto di base è comunque accessibile.
• Minore: Problemi meno gravi che richiedono ancora una soluzione per la piena conformità.

Vedi il Glossario per definizioni dettagliate.

Confronti

Developer Hub fornisce due tipi di confronti per i progetti Git. Confronti tra branch appaiono nella vista Branches, dove ogni branch è confrontato con l'ultima esecuzione del pipeline sul branch predefinito (questo mostra cosa cambierebbe se si fondesse adesso). Confronti all'interno del branch appaiono nella vista Commits, dove ogni commit è confrontato con il commit esaminato precedente nello stesso branch (questo ti dice cosa ha introdotto o risolto un commit specifico). Vedi Comprendere i tuoi Risultati per il quadro completo.

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 la GitHub Action, può inviare automaticamente un commento sulla 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 Branches, clicca su Visualizza Commit su qualsiasi branch per vedere i suoi singoli commit scansionati. A differenza dei confronti tra branch nella vista Branches, la vista Commits utilizza confronti all'interno del 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 si confronta l'intero branch 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.

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, la Axe Developer Hub GitHub Action può bloccare le PR che introducono errori di accessibilità.
• Per altre piattaforme come GitLab o Bitbucket, utilizza la REST Service API per interrogare i risultati e bloccare la tua pipeline quando vengono rilevati problemi.
• Puoi perfezionare cosa conta come un fallimento configurando la 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:

• La REST Service API ti consente di interrogare Axe Developer Hub per i risultati dopo che la tua suite di test è stata eseguita.
• 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 sui ruoli e permessi, vedi 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 di riepilogo delle issue, fai clic sul pulsante Esporta Issue per scaricare i risultati in formato CSV o JSON.
• Per l'accesso programmato, usa l'API REST Service per interrogare i risultati per un commit e un progetto specifici.

Consulta Ottenere Risultati Programmati per ulteriori opzioni.