Supporto per Metodologie Personalizzate

Configurazione della Metodologia di Test Manuale Personalizzata in axe Auditor

Scopo

I clienti che utilizzano axe Auditor a volte hanno bisogno di adeguare 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'uso di strumenti specifici durante i test.
• Decisioni politiche che modificano vari attributi delle problematiche (impatto, descrizioni, raccomandazioni).

Questo documento descrive le personalizzazioni che possono essere effettuate sulla metodologia di test manuale in axe Auditor e spiega come tali modifiche vengono riportate a Deque per il confezionamento e la distribuzione nella tua istanza ospitata.

Come funziona: ruoli e flusso di lavoro

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

Il processo completo è:

Nota sull'ambito: Questo documento elenca tutti i tipi di personalizzazione disponibili per completezza. Le modifiche specifiche che il tuo team apporterà dovrebbero essere in linea con l'ambito delle modifiche concordato.

Prima di iniziare

1. Fai il backup dell'originale. Prima di modificare qualsiasi cosa, fai una copia della cartella package decompressa. Se una modifica rompe il pacchetto, questo è il tuo unico modo sicuro per revertire.

cp -r package package_backup_original

2. Modifica solo i file elencati in ciascuna sezione. I file sono interdipendenti. Modificare un file non elencato per una determinata modifica — o mancarne uno che è è elencato — può produrre un pacchetto che non funziona solo dopo che è stato riconsegnato a Deque.

3. Valida ogni file che modifichi. Ogni file è in formato JSON e deve rimanere un JSON valido dopo la modifica (nessuna virgola finale, parentesi/parentesi quadre bilanciate). Valida 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'inglese (en). Se la tua organizzazione richiede una metodologia in lingue aggiuntive, informa Deque — Deque abilita il supporto linguistico durante la configurazione. In tal caso, ogni modifica che apporti in un file .en.json deve essere effettuata anche nel file locale corrispondente (ad esempio, l'equivalente .nl.json) per ciascuna lingua aggiuntiva.

Aggiornamenti consentiti

Aggiorna 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. Individua il checkpoint Deque specifico nel file JSON (ad esempio, 1.1.1.a).
2. Cerca l'attributo testing-methodology sotto quel checkpoint specifico.
3. Fai aggiornamenti appropriati a qualsiasi tipo di asset elencato sotto testing-methodology.
4. Salva il file nella sua posizione attuale.

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

Aggiorna l'impatto di una regola

Puoi cambiare il livello di impatto (bloccante, critico, serio, moderato, minore) per ogni problema all'interno di axe Auditor. Tuttavia, se hai bisogno di cambiare l'impatto predefinito per una regola, segui queste istruzioni.

Gli impatti in axe Auditor sono memorizzati a livello di 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 innescato dalla violazione di questa regola tra tutto Criteri di Successo WCAG connessi alla regola.

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

Passaggi:

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

Mappatura dei valori di impatto

Aggiungi un nuovo standard di accessibilità (ad esempio, uno standard specifico per l'organizzazione)

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

⚠️ Interno Deque — risolvi 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 file compilati distinti o se questi sono errori di percorso, quindi aggiorna l'elenco di conseguenza 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ù semplice è 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 checkpoint applicabili.
8. In issue-descriptions.json, aggiorna l'array standards per tutti gli oggetti delle regole applicabili.
9. In dist/bundle/checkpoints.json, aggiorna l'array standards di ciascun checkpoint applicabile con lo standard corretto.

Aggiorna le descrizioni brevi e lunghe dei problemi per 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 ciascuna regola. Una singola regola può influenzare più criteri di successo WCAG — cambiare questo testo influisce su tutti criteri di successo a cui è collegato.

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

Passaggi:

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

Aggiorna la raccomandazione di rimedio

Se vuoi cambiare la libreria di rimedi e le descrizioni associate per allinearle con la 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 esempio, alt-text-dynamic-image-inconsistent) e checkpoint per cui desideri cambiare la libreria di rimedi.
2. Aggiorna il testo per recommendationType (Tecnica di Raccomandazione), rule, howtofix e background (sezioni della raccomandazione da correggere) come appropriato.
3. Salva il file nella sua posizione attuale.

Rimuovi tipi di asset digitali

Usa questa opzione quando un determinato tipo di asset non si applica alla tua organizzazione (ad esempio, se il test di 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

Passaggio 1: Rimuovi dal file delle metodologie di test

File: dist/bundle/testingMethodologies.json

Trova e rimuovi l'intero oggetto per la metodologia che vuoi 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

Passaggio 2: Rimuovi dal file delle impostazioni locali in 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 — per esempio una metodologia web-app o macos. L'esempio seguente utilizza web-app; sostituisci il tuo id-asset come necessario.

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 — contenuti dei checkpoint in inglese con sezioni di metodologia di test
• dist/bundle/checkpoints.json — dati principali dei checkpoint
• dist/bundle/descriptions.json — descrizioni dei problemi con riferimenti a metodologia di test
• dist/bundle/schemata.json — definizioni di schema con riferimenti a metodologia di test

Passaggio 1: Aggiungi 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"
  ]
}

Passaggio 2: Aggiungi al file delle impostazioni locali in inglese

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

Aggiungi lo stesso oggetto metodologia a questo file.

Passo 3: Aggiungi riferimenti al file 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"
  ]
}

Passo 4: Aggiungi contenuti di metodologia di test al file di lingua del checkpoint

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

Per ogni checkpoint che dovrebbe supportare la nuova metodologia, aggiungi il contenuto sulla 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>"
    }
  }
}

Passo 5: Aggiungi riferimenti al file delle descrizioni

File: dist/bundle/descriptions.json

Per le descrizioni dei problemi che dovrebbero supportare la nuova metodologia, aggiungilo al loro array testingMethodologies.

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

Passo 6: Aggiungi riferimenti al file 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

Aggiungere 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

Passo 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 univoco utilizzando il tuo formato personalizzato (ad esempio, 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 esempio, ["custom"], ["TT508"], ["smoke"], ["brand"] (non ["wcag2a"]).
• testingMethodologies — piattaforme su cui 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 (ad esempio, "custom.1", "1", "s.1").
• categories — categorie di accessibilità rilevanti (può essere vuoto [] per non-WCAG).
• terms — array opzionale di riferimenti a termini del glossario con proprietà id e ordinal.

Passo 2: Aggiungi contenuti localizzati a checkpoints.en.json

Usa il formato id trattino: converti punti in trattini (ad esempio, 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 tag HTML appropriati per le liste.

Aggiungere 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 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 localizzate.
5. package/dist/bundle/recommendations.json — raccomandazioni di recupero collegate alle descrizioni dei problemi.
6. package/dist/bundle/locales/recommendations.en.json — contenuto della raccomandazione localizzato (titolo, descrizione, passaggi, risorse).

Opzionale — inserimento manuale: Se preferisci evitare di aggiungere descrizioni e raccomandazioni predefinite ai file JSON, puoi gestirle quando si registrano i problemi nello strumento: seleziona il tuo checkpoint WCAG, scegli Crea la tua descrizione invece di uno predefinito, quindi inserisci manualmente la descrizione e (se necessario) la raccomandazione adattata al problema riscontrato.

Passo 1: Definisci 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 dei criteri di successo WCAG (ad es., "1.4.3").
• standards — "wcag2a" (Livello A), "wcag2aa" (Livello AA), o "wcag2aaa" (Livello AAA).
• automatedRules — elenco di ID delle regole automatizzate.
• grouping — Numero delle linee guida WCAG (ad es., "1.4", "2.1").

Passo 2: Aggiungi la metodologia di test

File: package/dist/bundle/locales/checkpoints.en.json — utilizza 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: Aggiungi le 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: Aggiungi 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: Aggiungi 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: Aggiungi 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 testi e documenti.

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

Passi:

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 (possono essercene più di uno) mantenendo il JSON valido. Salva il file.
4. In checkpoints.en.json, cerca il checkpoint specifico utilizzando 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 utilizzando il formato con trattino (ad es., 1-2-1-b). Elimina ogni oggetto associato a questo checkpoint (possono essercene più di uno) mantenendo il JSON valido. Salva il file.

Inviare le modifiche a Deque

Quando le modifiche sono complete e convalidate:

1. Conferma che ogni file modificato superi ancora la convalida 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 assegnerà la versione, imballerà il pacchetto, lo mapperà alla versione corretta di axe-core, e lo distribuirà a un'istanza di test per la verifica. Dopo che il tuo team ha verificato le modifiche sull'istanza di test e ha dato conferma, Deque promuoverà la metodologia alla tua istanza produzione.

Supporto

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