Supporto per Metodologie Personalizzate

Configurazione di una Metodologia di Test Manuale Personalizzata in Axe Auditor

Obiettivo

I clienti che utilizzano axe Auditor a volte necessitano di adattare la metodologia di test manuale (il DequeWay). Questa necessità può derivare da:

• Politiche interne specifiche che richiedono controlli aggiuntivi o ridotti.
• Linee guida interne per l'utilizzo di strumenti specifici durante l'esecuzione dei test.
• Decisioni politiche che cambiano vari attributi del problema (impatto, descrizioni, raccomandazioni).

Questo documento descrive le personalizzazioni che possono essere apportate alla metodologia di test manuale in axe Auditor e spiega come queste modifiche vengono rese disponibili a Deque per il packaging e il deployment nella vostra istanza ospitata.

Come Funziona: Ruoli e Flusso di Lavoro

L'istanza di axe Auditor della vostra organizzazione è ospitata e gestita da Deque. Ciò significa che Deque gestisce l'installazione, la sequenziazione delle versioni, il packaging e il deployment della metodologia. Il vostro team è responsabile solo della modifica dei file di configurazione della metodologia. Non è necessario aggiornare i numeri di versione, creare pacchetti, né eseguire comandi di installazione o per i database. Deque si occupa di tutto questo per vostro conto.

Il processo end-to-end è:

Nota sull'ambito: Questo documento elenca tutti i tipi di personalizzazioni disponibili per completezza. Le modifiche specifiche che il vostro team apporterà dovrebbero essere allineate con l'ambito di cambiamento concordato.

Prima di Iniziare

1. Eseguire il backup dell'originale. Prima di modificare qualsiasi cosa, fare una copia della cartella package non compressa. Se una modifica compromette il bundle, questo è il vostro unico modo pulito per tornare indietro.

cp -r package package_backup_original

2. Modificare solo i file elencati in ogni sezione. I file sono interdipendenti. Modificare un file non elencato per una data modifica — o omettere uno che è elencato — può produrre un pacchetto che fallisce solo dopo che è ritornato a Deque.

3. Validare ogni file che si modifica. Ogni file è in formato JSON e deve rimanere un JSON valido dopo la modifica (senza virgole finali, parentesi graffe e quadre bilanciate). Validare prima di inviare:

# Validate a single file
python3 -m json.tool package/dist/bundle/descriptions.json > /dev/null && echo "VALID" || echo "INVALID"

# Or validate every JSON file in the bundle at once
find package/dist -name "*.json" -print0 | while IFS= read -r -d '' f; do
  python3 -m json.tool "$f" > /dev/null 2>&1 && echo "VALID:   $f" || echo "INVALID: $f"
done

4. Presupposto linguistico. Queste istruzioni presuppongono l'uso dell'inglese (en). Se la tua organizzazione richiede la metodologia in lingue aggiuntive, informa Deque — Deque abilita il supporto linguistico durante la configurazione. In tal caso, ogni modifica apportata a un file .en.json deve essere effettuata anche nel file di localizzazione corrispondente (ad esempio, l'equivalente .nl.json) per ciascuna lingua aggiuntiva.

Aggiornamenti Consentiti

Aggiornare la metodologia di test per un checkpoint specifico

Utile quando si desidera modificare le istruzioni di test per un checkpoint specifico in axe Auditor.

File aggiornati: package/dist/bundle/locales/checkpoints.en.json

Passaggi:

1. Individuare lo specifico checkpoint Deque nel file JSON (ad esempio, 1.1.1.a).
2. Cercare l'attributo testing-methodology sotto quello specifico checkpoint.
3. Effettuare aggiornamenti appropriati a qualsiasi tipo di asset elencato sotto testing-methodology.
4. Salvare il file nella sua posizione attuale.

Nota: Anche il nome del checkpoint visibile in axe Auditor può essere modificato usando le stesse istruzioni. Invece di aggiornare la sezione testing-methodology, aggiornare l'attributo name sotto il checkpoint pertinente nello stesso file.

Aggiornare l'Impatto di una Regola

È possibile modificare il livello d'impatto (bloccante, critico, grave, moderato, minore) per ogni problema all'interno di axe Auditor. Tuttavia, se è necessario cambiare l'impatto predefinito per una regola, seguire queste istruzioni.

Gli impatti in axe Auditor sono memorizzati a livello regola, non a livello di Criteri di Successo WCAG o checkpoint. Una singola regola può influenzare più checkpoint Deque (ad esempio, id regola alt-text-dynamic-image-inconsistent). Modificare l'impatto per la regola cambia l'impatto predefinito per un problema scatenato dalla violazione di questa regola in tutti tutti Criteri di Successo WCAG collegati alla regola.

File aggiornati: package/dist/bundle/descriptions.json

Passaggi:

1. Individuare la specifica regola Deque nel file JSON (ad esempio, alt-text-dynamic-image-inconsistent).
2. Cercare l'attributo impact sotto quella specifica regola.
3. Aggiornare l'impatto con un valore numerico (vedi la tabella sotto).
4. Salvare il file nella sua posizione attuale.

Mappature dei valori d'impatto

Aggiungere un Nuovo Standard di Accessibilità (ad esempio, uno Standard Specifico dell'Organizzazione)

Se hai standard di test specifici dell'organizzazione che desideri fornire ai tuoi team oltre agli standard esistenti (come WCAG 2.1 AA o ACAA), utilizza i seguenti passi.

⚠️ Interno Deque — risolvere prima della pubblicazione: L'elenco dei file per questa sezione fa riferimento a tre percorsi relativi ai checkpoint che sono incoerenti con il resto del documento (che utilizza dist/bundle/…): package/dist/checkpoints.json, package/dist/issue-descriptions.json e package/dist/bundle/checkpoints.json. Conferma se dist/checkpoints.json e dist/issue-descriptions.json sono effettivamente file compilati distinti, o se si tratta di errori di percorso, quindi aggiorna di conseguenza l'elenco e rimuovi questa nota.

File aggiornati:

• package/dist/bundle/standards.json
• package/dist/bundle/descriptions.json
• package/dist/bundle/testingMethodologies.json
• package/dist/bundle/locales/standards.en.json
• package/dist/checkpoints.json
• package/dist/issue-descriptions.json
• package/dist/bundle/checkpoints.json

Passaggi:

1. Crea un nuovo oggetto array per lo standard in standards.json. L'approccio più facile è copiare l'intero oggetto per wcag21aa e aggiungerlo alla fine del file.
2. Cambia il id dell'oggetto appena copiato con qualcosa di unico che indichi lo standard che rappresenta.
3. Aggiorna l'array rubric per il nuovo oggetto per rappresentare tutti gli standard di test sottostanti che fanno parte di questo nuovo standard.
4. In descriptions.json, per tutte le regole associate al tuo nuovo standard, aggiungi l'id del nuovo standard (da standards.json) all'array standards.
5. In testingMethodologies.json, aggiungi l'id del nuovo standard sotto l'array standards per ogni tipo di asset digitale a cui si applica questo standard.
6. In standards.en.json, aggiungi un nuovo oggetto con l'id e il nome del nuovo standard. Il campo name è ciò che gli utenti vedono nell'interfaccia utente di axe Auditor.
7. In dist/checkpoints.json, aggiorna l'array standards sotto ogni descrizione del problema per i punti di controllo applicabili.
8. In issue-descriptions.json, aggiorna l'array standards per tutti gli oggetti di regole applicabili.
9. In dist/bundle/checkpoints.json, aggiorna l'array standards di ciascun punto di controllo applicabile con lo standard corretto.

Aggiorna le Descrizioni Brevi e Lunghe dei Problemi per le Regole Specifiche

Usa queste istruzioni per aggiornare il testo di selezione della descrizione del problema (breve) e la descrizione lunga del tipo di problema per ogni regola. Una singola regola può influenzare più Criteri di Successo WCAG — modificare questo testo influisce sui Criteri di Successo tutte ai quali è collegato.

File aggiornati: package/dist/bundle/locales/descriptions.en.json

Passaggi:

1. In descriptions.en.json, cerca la regola specifica (ad es., alt-text-dynamic-image-inconsistent).
2. Aggiorna il testo per shortText (Descrizione Breve del Problema) e issueDescText (Descrizione Lunga del Problema) in base alle necessità.
3. Salva il file nella sua posizione attuale.

Aggiorna la Raccomandazione di Correzione

Se desideri modificare la libreria di correzione e le descrizioni associate per allinearle alla tua politica, usa le seguenti istruzioni.

File aggiornati: package/dist/bundle/locales/recommendations.en.json

Passaggi:

1. In recommendations.en.json, cerca la combinazione specifica di regola (ad es., alt-text-dynamic-image-inconsistent) e punto di controllo per la quale si desidera modificare la libreria di correzione.
2. Aggiorna il testo per recommendationType (Tecnica di Raccomandazione), rule, howtofix e background (sezioni della raccomandazione da correggere) in base alle necessità.
3. Salva il file nella sua posizione attuale.

Rimuovi Tipi di Asset Digitali

Usa questo quando un determinato tipo di asset non si applica alla tua organizzazione (ad esempio, se il test su PDF o Android è fuori ambito).

File da aggiornare:

• dist/bundle/testingMethodologies.json — dati principali delle metodologie di test
• dist/bundle/locales/testingMethodologies.en.json — traduzioni in inglese

Passo 1: Rimuovere dal file delle metodologie di test

File: dist/bundle/testingMethodologies.json

Trova e rimuovi l'intero oggetto per la metodologia che desideri eliminare.

// BEFORE — remove this entire object (example: "native-mobile-android"):
{
  "id": "native-mobile-android",
  "techniques": ["general"],
  "standards": [
    "wcag2a", "wcag21a", "wcag22a",
    "wcag2aa", "wcag21aa", "wcag22aa",
    "acaa", "en301549-wad",
    "508-2017-wcag2", "508-2017-wcag21"
  ]
}
// AFTER — object completely removed

Passo 2: Rimuovere dal file della lingua inglese

File: dist/bundle/locales/testingMethodologies.en.json

Rimuovi lo stesso oggetto metodologia da questo file.

Aggiungi un Nuovo Tipo di Asset Digitale

Usa questo per aggiungere un nuovo tipo di asset digitale — ad esempio una metodologia web-app o macos. L'esempio seguente utilizza web-app; sostituisci con il tuo id di tipo di asset secondo necessità.

File da aggiornare:

• dist/bundle/testingMethodologies.json — dati principali delle metodologie di test
• dist/bundle/locales/testingMethodologies.en.json — traduzioni in inglese
• dist/bundle/locales/checkpoints.en.json — contenuto dei checkpoint in inglese con sezioni di metodologie di test
• dist/bundle/checkpoints.json — dati principali dei checkpoint
• dist/bundle/descriptions.json — descrizioni dei problemi con riferimenti alle metodologie di test
• dist/bundle/schemata.json — definizioni di schema con riferimenti alle metodologie di test

Passo 1: Aggiungere al file delle metodologie di test

File: dist/bundle/testingMethodologies.json

Aggiungi il nuovo oggetto metodologia all'array.

{
  "id": "web-app",
  "techniques": ["general", "html", "aria", "css"],
  "standards": [
    "wcag2a", "wcag21a", "wcag22a",
    "wcag2aa", "wcag21aa", "wcag22aa",
    "acaa", "en301549-wad",
    "508-2017-wcag2", "508-2017-wcag21"
  ]
}

Passo 2: Aggiungere al file della lingua inglese

File: dist/bundle/locales/testingMethodologies.en.json

Aggiungi lo stesso oggetto metodologia a questo file.

Passaggio 3: Aggiungi riferimenti al file di checkpoint

File: dist/bundle/checkpoints.json

Per ogni checkpoint che dovrebbe supportare la nuova metodologia, aggiungilo all'array testingMethodologies di quel checkpoint.

{
  "id": "1.4.3.a",
  "testingMethodologies": [
    "desktop", "mobile", "kiosk",
    "native-mobile-ios", "native-mobile-android",
    "pdf",
    "web-app",          // ← Add this line
    "ms-excel", "ms-powerpoint", "ms-word", "windows-desktop"
  ]
}

Passaggio 4: Aggiungi contenuti della metodologia di test al file di localizzazione del checkpoint

File: dist/bundle/locales/checkpoints.en.json

Per ogni checkpoint che dovrebbe supportare la nuova metodologia, aggiungi il contenuto della metodologia di test.

{
  "1.4.3.a": {
    "name": "Color Contrast (Minimum)",
    "testing-methodology": {
      "desktop": "<ol>...</ol>",
      "mobile": "<ol>...</ol>",
      "native-mobile-android": "<ol>...</ol>",
      "web-app": "<ol>\n<li>Open the web application in a modern browser</li>\n<li>Use browser developer tools to inspect text elements</li>\n<li>Check color contrast ratios using accessibility tools</li>\n<li>Verify contrast meets WCAG requirements</li>\n</ol>",  // ← Add this new entry
      "pdf": "<ol>...</ol>"
    }
  }
}

Passaggio 5: Aggiungi riferimenti al file delle descrizioni

File: dist/bundle/descriptions.json

Per le descrizioni dei problemi che dovrebbero supportare la nuova metodologia, aggiungile all'array testingMethodologies.

{
  "id": "some-issue-id",
  "data": [
    {
      "type": "issue",
      "testingMethodologies": [
        "desktop", "mobile",
        "native-mobile-android", "pdf",
        "web-app"        // ← Add this line
      ]
    }
  ]
}

Passaggio 6: Aggiungi riferimenti al file dello schema

File: dist/bundle/schemata.json

Aggiungi la nuova metodologia di test alle definizioni dello schema.

{
  "testingMethodologies": {
    "desktop": null,
    "kiosk": null,
    "mobile": null,
    "native-mobile-ios": null,
    "native-mobile-android": null,
    "pdf": null,
    "web-app": null,   // ← Add this line
    "ms-excel": null,
    "ms-powerpoint": null,
    "ms-word": null,
    "windows-desktop": null
  }
}

Aggiungi un Nuovo Checkpoint

Aggiunta di un Checkpoint Non-WCAG

Importante: I checkpoint Non-WCAG non supportano descrizioni o raccomandazioni predefinite tramite descriptions.json e recommendations.json. Quando registri problemi con questi checkpoint, inserisci manualmente descrizioni e raccomandazioni utilizzando la funzione Crea la tua descrizione nello strumento.

File da aggiornare — solo 2:

• package/dist/bundle/checkpoints.json — definire il checkpoint
• package/dist/bundle/locales/checkpoints.en.json — fornire metodologia di test localizzata

Passaggio 1: Aggiungi il checkpoint a checkpoints.json

{
  "id": "custom.1.1",
  "requiredSenses": {
    "sight": true,
    "hearing": false
  },
  "successCriteria": "",
  "automatedRules": [],
  "testingMethodologies": ["desktop", "mobile"],
  "grouping": "custom.1",
  "categories": [],
  "standards": ["custom"]
}

Campi chiave:

• id — identificatore unico utilizzando il tuo formato personalizzato (es., custom.1.1, brand.2.3, TT.01.A, s.1.1).
• successCriteria — stringa vuota "" per checkpoint non-WCAG (o un formato personalizzato come "tt-01.A").
• standards — il tuo identificatore standard personalizzato, ad es., ["custom"], ["TT508"], ["smoke"], ["brand"] (non ["wcag2a"]).
• testingMethodologies — piattaforme dove si applica questo checkpoint: desktop, mobile, kiosk, native-mobile-ios, native-mobile-android, pdf, windows-desktop, ms-excel, ms-powerpoint, ms-word.
• requiredSenses — quali sensi sono necessari per testare questo checkpoint (sight, hearing: true/false).
• automatedRules — array opzionale di ID regole automatizzate (tipicamente vuoto [] per checkpoint personalizzati).
• grouping — raggruppamento logico per l'organizzazione (es., "custom.1", "1", "s.1").
• categories — categorie di accessibilità rilevanti (può essere vuoto [] per non-WCAG).
• terms — array opzionale di riferimenti a termini di glossario con proprietà id e ordinal.

Passaggio 2: Aggiungi contenuto localizzato a checkpoints.en.json

Usa il formato ID con trattino: converti i punti in trattini (es., custom-1-1, non custom.1.1).

"custom-1-1": {
  "examples": "<ul>\n  <li>Example 1: Describe a scenario where this applies</li>\n  <li>Example 2: Describe another scenario</li>\n</ul>",
  "related-techniques": {
    "general": "<ul>\n  <li>Technique reference 1</li>\n  <li>Technique reference 2</li>\n</ul>",
    "html": "<ul>\n  <li>HTML-specific technique</li>\n</ul>"
  },
  "testing-methodology": {
    "desktop": "<ol>\n  <li>Step 1 for desktop testing</li>\n  <li>Step 2 for desktop testing</li>\n</ol>",
    "mobile": "<ol>\n  <li>Step 1 for mobile testing</li>\n  <li>Step 2 for mobile testing</li>\n</ol>"
  },
  "name": "Your Custom Checkpoint Name",
  "overview": {
    "general": "General description of what this checkpoint tests and why it matters for accessibility.",
    "html": "HTML-specific description if applicable; otherwise can match general."
  }
}

Usa \n per nuove righe e i tag HTML appropriati per le liste.

Aggiunta di un Checkpoint WCAG

File da aggiornare — 6 file per un'implementazione completa del checkpoint WCAG:

1. package/dist/bundle/checkpoints.json — definire il checkpoint con campi specifici di WCAG.
2. package/dist/bundle/locales/checkpoints.en.json — metodologia di test localizzata, esempi, tecniche correlate (usa il formato ID con trattino: 1-4-3-a, non 1.4.3.a).
3. package/dist/bundle/descriptions.json — descrizioni dei problemi con livelli di impatto e riferimenti ai checkpoint.
4. package/dist/bundle/locales/descriptions.en.json — descrizioni dei problemi localizzati.
5. package/dist/bundle/recommendations.json — raccomandazioni di rimedio collegate alle descrizioni dei problemi.
6. package/dist/bundle/locales/recommendations.en.json — contenuto delle raccomandazioni localizzato (titolo, descrizione, passaggi, risorse).

Opzionale — inserimento manuale: Se preferisci evitare di aggiungere descrizioni e raccomandazioni predefinite ai file JSON, puoi gestirle al momento della registrazione dei problemi nello strumento: seleziona il tuo checkpoint WCAG, scegli Crea la tua descrizione invece di uno predefinito, poi inserisci manualmente la descrizione e (se necessario) la raccomandazione su misura per il problema riscontrato.

Passo 1: Definire il checkpoint

File: package/dist/bundle/checkpoints.json

{
  "id": "1.4.3.a",
  "requiredSenses": {
    "sight": true,
    "hearing": false
  },
  "successCriteria": "1.4.3",
  "automatedRules": ["color-contrast"],
  "testingMethodologies": [
    "desktop", "mobile", "kiosk",
    "native-mobile-ios", "native-mobile-android",
    "pdf", "ms-excel", "ms-powerpoint", "ms-word", "windows-desktop"
  ],
  "grouping": "1.4",
  "categories": ["cat.distinguishable"],
  "standards": ["wcag2aa"]
}

Campi chiave:

• id — Modello di numerazione WCAG (ad es., "1.4.3.a", "2.1.1.b").
• successCriteria — Numero del criterio di successo WCAG (ad es., "1.4.3").
• standards — "wcag2a" (Livello A), "wcag2aa" (Livello AA) o "wcag2aaa" (Livello AAA).
• automatedRules — Array di ID delle regole automatizzate.
• grouping — Numero della linea guida WCAG (ad es., "1.4", "2.1").

Passo 2: Aggiungere la metodologia di test

File: package/dist/bundle/locales/checkpoints.en.json — usa il formato con trattino (1-4-3-a).

"1-4-3-a": {
  "name": "Color Contrast (Minimum)",
  "overview": {
    "general": "Text and images of text have a contrast ratio of at least 4.5:1, except for large text which has a contrast ratio of at least 3:1.",
    "html": "Text and images of text have a contrast ratio of at least 4.5:1, except for large text which has a contrast ratio of at least 3:1."
  },
  "examples": "<ul>\n  <li>Gray text on white background with insufficient contrast</li>\n  <li>Blue text on blue background that doesn't meet requirements</li>\n</ul>",
  "testing-methodology": {
    "desktop": "<ol>\n  <li>Identify all text content on the page</li>\n  <li>Use a color contrast analyzer tool</li>\n  <li>Ensure normal text has at least 4.5:1 contrast ratio</li>\n  <li>Ensure large text has at least 3:1 contrast ratio</li>\n</ol>",
    "mobile": "<ol>\n  <li>Test on a mobile device under various lighting conditions</li>\n  <li>Use mobile accessibility testing tools</li>\n  <li>Verify contrast ratios meet WCAG requirements</li>\n</ol>",
    "assistive-technology": "<p><strong>Screen reader testing is optional for this checkpoint.</strong></p>\n<p><strong>Using NVDA:</strong></p>\n<ol>\n  <li>Navigate through text content</li>\n  <li>Verify text readability</li>\n</ol>"
  },
  "related-techniques": {
    "general": "<ul>\n  <li><a href=\"https://www.w3.org/WAI/WCAG22/Techniques/general/G18\">G18: Ensuring contrast ratio of at least 4.5:1</a></li>\n</ul>",
    "html": "<ul>\n  <li><a href=\"https://www.w3.org/WAI/WCAG22/Techniques/css/C21\">C21: Specifying line spacing in CSS</a></li>\n</ul>"
  }
}

Passo 3: Aggiungere descrizioni dei problemi

File: package/dist/bundle/descriptions.json

{
  "id": "insufficient-color-contrast",
  "data": [
    {
      "type": "issue",
      "impact": 4,
      "checkpoint": "1.4.3.a",
      "standards": ["wcag2aa"],
      "references": [
        {
          "standards": ["wcag2aa"],
          "checkpoint": "1.4.3.a"
        }
      ],
      "testingMethodologies": ["desktop", "mobile"]
    }
  ]
}

Passo 4: Aggiungere descrizioni dei problemi localizzati

File: package/dist/bundle/locales/descriptions.en.json

Aggiungi un oggetto per la nuova descrizione:

"insufficient-color-contrast": {
  "shortText": "Insufficient color contrast",
  "issueDescText": "Text does not have sufficient contrast against its background to meet WCAG 2.1 AA requirements."
}

Passo 5: Aggiungere raccomandazioni

File: package/dist/bundle/recommendations.json

Usa il formato con trattino (1-4-3-a) e aggiungilo all'ID della raccomandazione.

{
  "id": "insufficient-color-contrast-fix-1-4-3-a",
  "data": [
    {
      "type": "recommendation",
      "description": "insufficient-color-contrast"
    }
  ]
}

Passo 6: Aggiungere il contenuto delle raccomandazioni

File: package/dist/bundle/locales/recommendations.en.json

"insufficient-color-contrast-fix-1-4-3-a": {
  "title": "Improve Color Contrast",
  "description": "Increase the contrast ratio between text and background colors to meet WCAG 2.1 AA requirements.",
  "steps": [
    "Use a color contrast analyzer to identify insufficient contrast",
    "Adjust text color, background color, or both to achieve a minimum 4.5:1 ratio",
    "For large text (18pt+ or 14pt+ bold), ensure a minimum 3:1 ratio",
    "Test the changes across different devices and lighting conditions"
  ],
  "resources": [
    "WebAIM Color Contrast Checker",
    "W3C Color Contrast Analyzer",
    "Chrome DevTools Accessibility Panel"
  ]
}

Rimuovere un checkpoint specifico

Utilizza queste istruzioni se c'è un checkpoint specifico che non vuoi che il tuo team test e segnali.

File aggiornati:

• package/dist/bundle/checkpoints.json
• package/dist/bundle/descriptions.json
• package/dist/bundle/recommendations.json
• package/dist/bundle/locales/checkpoints.en.json
• package/dist/bundle/locales/recommendations.en.json

Passaggi:

1. In checkpoints.json, cerca il checkpoint specifico (ad es., 1.2.1.b). Elimina l'intero oggetto associato a questo checkpoint mantenendo il JSON valido. Salva il file.
2. In descriptions.json, cerca il checkpoint specifico (ad es., 1.2.1.b). Elimina solo l'oggetto che utilizza il checkpoint sotto la regola mantenendo il JSON valido. Una singola regola può applicarsi a più checkpoint — rimuovi solo l'oggetto per il checkpoint che stai rimuovendo; non rimuovere l'intera regola. Salva il file.
3. In recommendations.json, cerca il checkpoint specifico (ad es., 1.2.1.b). Elimina ogni oggetto associato a questo checkpoint (può essercene più di uno) mantenendo il JSON valido. Salva il file.
4. In checkpoints.en.json, cerca il checkpoint specifico usando il formato con trattino (ad es., 1-2-1-b). Elimina l'intero oggetto mantenendo il JSON valido. Salva il file.
5. In recommendations.en.json, cerca il checkpoint specifico usando il formato con trattino (ad es., 1-2-1-b). Elimina ogni oggetto associato a questo checkpoint (può essercene più di uno) mantenendo il JSON valido. Salva il file.

Invio delle modifiche a Deque

Quando le modifiche sono completate e convalidate:

1. Conferma che ogni file modificato passi ancora la validazione JSON (vedi Prima di iniziare).
2. Conferma che le modifiche corrispondano all'ambito concordato.
3. Invia l'intera cartella package a Deque nella sua struttura originale (non inviare solo file individuali).

Deque assegnarà la versione, confezionerà il pacchetto, lo mapperà alla versione corretta di axe-core e lo distribuirà a una istanza di test per la verifica. Dopo che il tuo team ha verificato le modifiche sull'istanza di test e dato l'approvazione, Deque promuove la metodologia alla tua istanza produzione.

Supporto

Per domande su questo processo, sull'ambito di modifica concordato o per richiedere supporto linguistico aggiuntivo, contatta il tuo referente Deque.