Supporto per la Metodologia Personalizzata

Configurazione della Metodologia di Test Manuale Personalizzata in Axe Auditor

Scopo

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

• Politiche interne specifiche che richiedono controlli aggiuntivi o minori.
• Linee guida interne per l'uso di strumenti specifici durante i test.
• Decisioni politiche che modificano vari attributi dei problemi (impatto, descrizioni, raccomandazioni).

Questo documento descrive le personalizzazioni che possono essere apportate alla metodologia di test manuale in axe Auditor e spiega come tali modifiche vengono inviate a Deque per il packaging e la distribuzione alla 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 sequenza delle versioni, il packaging e la distribuzione della metodologia. Il vostro team è responsabile solo della modifica dei file di configurazione della metodologia. Non è necessario aggiornare i numeri di versione, creare pacchetti o eseguire comandi di installazione o database. Deque gestisce tutto ciò per voi.

Il processo end-to-end è:

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

Prima di iniziare

1. Esegui il backup dell'originale. Prima di modificare qualsiasi cosa, fai una copia della cartella package non compressa. Se una modifica rompe il pacchetto, questo è l'unico modo pulito per ripristinare.

cp -r package package_backup_original

2. Modifica solo i file elencati in ogni sezione. I file sono interdipendenti. Modificare un file non elencato per una determinata modifica — o perdere uno che è è elencato — può produrre un pacchetto che non funziona solo dopo il round-trip a Deque.

3. Valida ogni file che tocchi. Ogni file è JSON e deve rimanere JSON valido dopo la modifica (niente virgole finali, parentesi graffe e 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. Assunzione della lingua. Queste istruzioni presumono l'inglese (en). Se la vostra organizzazione richiede la metodologia in lingue aggiuntive, informate Deque — Deque attiva il supporto linguistico durante la configurazione. In tal caso, ogni modifica che fate in un file .en.json deve essere fatta anche nel file di localizzazione corrispondente (ad esempio, l'equivalente .nl.json) per ogni lingua aggiuntiva.

Aggiornamenti consentiti

Aggiorna la metodologia di testing per un checkpoint specifico

Utile quando si vogliono cambiare 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 (es., 1.1.1.a).
2. Cerca l'attributo testing-methodology sotto quel checkpoint specifico.
3. Esegui gli aggiornamenti appropriati a qualsiasi tipo di asset elencato sotto testing-methodology.
4. Salva il file nella sua posizione attuale.

Nota: Anche 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 d'impatto (bloccante, critico, serio, moderato, minore) per ogni problema all'interno di axe Auditor. Tuttavia, se devi cambiare l'impatto predefinito per una regola, segui queste istruzioni.

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

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

Passaggi:

1. Individua la regola Deque specifica nel file JSON (es., 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.

Mappature dei valori d'impatto

Aggiungi un Nuovo Standard di Accessibilità (es., uno Standard Specifico dell'Organizzazione)

Se hai degli standard di testing specifici dell'organizzazione che desideri fornire ai tuoi team in aggiunta agli standard esistenti (come WCAG 2.1 AA o ACAA), usa i seguenti passaggi.

⚠️ Interno Deque — risolvere prima di pubblicare: 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 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. Il modo più semplice è copiare l'intero oggetto per wcag21aa e aggiungerlo alla fine del file.
2. Cambia il id del nuovo oggetto copiato in qualcosa di unico che significhi lo standard che rappresenta.
3. Aggiorna l'array rubric per il nuovo oggetto per rappresentare tutti gli standard di testing 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 ciascun 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 ciascuna descrizione del problema per i checkpoint applicabili.
8. In issue-descriptions.json, aggiorna l'array standards per tutti gli oggetti regola 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 sui tutto 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 (es., 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 desideri modificare la libreria di rimedi e le descrizioni associate per allinearti alla tua politica, usa le seguenti istruzioni.

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

Passaggi:

1. In recommendations.en.json, cerca la regola specifica (per esempio, alt-text-dynamic-image-inconsistent) e la combinazione di checkpoint per cui vuoi cambiare la libreria di remediation.
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.

Rimuovere Tipi di Asset Digitali

Usa questo metodo quando un certo tipo di asset non si applica alla tua organizzazione (ad esempio, se il test 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 delle impostazioni locali in inglese

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

Rimuovi lo stesso oggetto metodologico da questo file.

Aggiungere 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 sotto utilizza web-app; sostituisci con il tuo id di tipo-asset a seconda delle 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 metodologia di test
• dist/bundle/checkpoints.json — dati principali dei checkpoint
• dist/bundle/descriptions.json — descrizioni dei problemi con riferimenti alla metodologia di test
• dist/bundle/schemata.json — definizioni di schema con riferimenti alla metodologia di test

Passo 1: Aggiungere al file delle metodologie di test

File: dist/bundle/testingMethodologies.json

Aggiungi il nuovo oggetto metodologico 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 delle impostazioni locali in inglese

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

Aggiungi lo stesso oggetto metodologico a questo file.

Passo 3: Aggiungere riferimenti al file dei checkpoint

File: dist/bundle/checkpoints.json

Per ciascun checkpoint che dovrebbe supportare la nuova metodologia, aggiungila 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: Aggiungere contenuti di metodologia di test al file delle impostazioni locali dei checkpoint

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

Per ciascun checkpoint che dovrebbe supportare la nuova metodologia, aggiungi i contenuti di 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: Aggiungere riferimenti al file delle descrizioni

File: dist/bundle/descriptions.json

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

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

Passo 6: Aggiungere 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
  }
}

Aggiungere un Nuovo Checkpoint

Aggiungere un Checkpoint Non-WCAG

Importante: I checkpoint Non-WCAG non non supportano descrizioni predefinite o raccomandazioni tramite descriptions.json e recommendations.json. Quando registri problemi con questi checkpoint, inserisci manualmente descrizioni e raccomandazioni usando 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: Aggiungere 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 usando il tuo formato personalizzato (per 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 — identificatore standard personalizzato, per esempio, ["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 delle regole automatiche (tipicamente vuoto [] per checkpoint personalizzati).
• grouping — raggruppamento logico per organizzazione (per esempio, "custom.1", "1", "s.1").
• categories — categorie di accessibilità pertinenti (può essere vuoto [] per non-WCAG).
• terms — array opzionale di riferimenti a termini di glossario con proprietà id e ordinal.

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

Usa il formato id trattinati: converti i punti in trattini (ad 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 le 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 — definisci 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 trattinato: 1-4-3-a, non 1.4.3.a).
3. package/dist/bundle/descriptions.json — descrizioni dei problemi con livelli di impatto e riferimenti al 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 — contenuti di raccomandazione localizzati (titolo, descrizione, passi, risorse).

Opzionale — inserimento manuale: Se preferisci evitare di aggiungere descrizioni e raccomandazioni predefinite ai file JSON, puoi gestirle registrando i 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 personalizzata al problema trovato.

Passaggio 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 — array di id delle regole automatizzate.
• grouping — numero delle linee guida WCAG (ad es., "1.4", "2.1").

Passaggio 2: Aggiungi la metodologia di testing

File: package/dist/bundle/locales/checkpoints.en.json — usa il formato trattinato (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>"
  }
}

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

Passaggio 4: Aggiungi descrizioni dei problemi localizzate

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."
}

Passaggio 5: Aggiungi raccomandazioni

File: package/dist/bundle/recommendations.json

Usa il formato trattinato (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"
    }
  ]
}

Passaggio 6: Aggiungi contenuti di 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

Usa queste istruzioni se c'è un checkpoint specifico che non vuoi che il tuo team testi e riporti.

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 (possono essercene più di uno) mantenendo il JSON valido. Salva il file.
4. In checkpoints.en.json, cerca il checkpoint specifico usando il formato trattinato (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 trattinato (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.

Invio delle Modifiche a Deque

Quando le modifiche sono complete e validate:

1. Conferma che ogni file modificato superi 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 assegnerà la versione, confezionerà il pacchetto, lo mapperà alla versione axe-core corretta e lo distribuirà a un istanza di test per la verifica. Dopo che il tuo team verifica le modifiche nella versione di prova e dà l'approvazione, Deque promuove la metodologia alla tua istanza produzione.

Supporto

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