Soporte para Metodología Personalizada

Configuración de la Metodología de Pruebas Manuales Personalizadas en Axe Auditor

Propósito

Los clientes que utilizan axe Auditor a veces necesitan ajustar la metodología de pruebas manuales (el DequeWay). Esta necesidad puede surgir de:

• Políticas internas específicas que requieren verificaciones adicionales o reducidas.
• Directrices internas para usar herramientas específicas al realizar pruebas.
• Decisiones de políticas que cambian varios atributos de los problemas (impacto, descripciones, recomendaciones).

Este documento describe las personalizaciones que se pueden hacer a la metodología de pruebas manuales en axe Auditor y explica cómo esos cambios se trasladan a Deque para su empaquetado y despliegue en su instancia alojada.

Cómo Funciona: Roles y Flujo de Trabajo

La instancia de axe Auditor de su organización está alojada y gestionada por Deque. Eso significa que Deque gestiona la instalación, la secuenciación de versiones, el empaquetado y el despliegue de la metodología. Su equipo es responsable solo de editar los archivos de configuración de la metodología. No necesitan actualizar números de versión, construir paquetes o ejecutar comandos de instalación o de base de datos. Deque se encarga de todo eso en su nombre.

El proceso de principio a fin es:

Nota de alcance: Este documento enumera todos los tipos de personalización disponibles para su totalidad. Los cambios específicos que realizará su equipo deben estar alineados con el alcance del cambio acordado.

Antes de Comenzar

1. Hacer una copia de seguridad del original. Antes de editar cualquier cosa, haga una copia de la carpeta package descomprimida. Si una edición rompe el paquete, esta es su única forma limpia de revertir.

cp -r package package_backup_original

2. Editar solo los archivos enumerados en cada sección. Los archivos son interdependientes. Editar un archivo que no esté listado para un cambio dado —o faltar uno que es listó— puede producir un paquete que falle solo después de su ida y vuelta a Deque.

3. Validar cada archivo que toque. Cada archivo es JSON y debe seguir siendo JSON válido después de editarlo (sin comas finales, llaves/corchetes equilibrados). Valide antes de enviar:

# 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. Suposición de idioma. Estas instrucciones asumen inglés (en). Si su organización requiere la metodología en idiomas adicionales, informe a Deque —Deque habilita el soporte de idiomas durante la configuración. En ese caso, cada edición que realice en un archivo .en.json también debe hacerse en el archivo de idioma correspondiente (por ejemplo, el equivalente en .nl.json) para cada idioma adicional.

Actualizaciones Permitidas

Actualizar la metodología de prueba para un punto de control específico

Útil cuando se desea cambiar las instrucciones de prueba para un punto de control específico en axe Auditor.

Archivos actualizados: package/dist/bundle/locales/checkpoints.en.json

Pasos:

1. Localice el punto de control específico de Deque en el archivo JSON (por ejemplo, 1.1.1.a).
2. Busque el atributo testing-methodology bajo ese punto de control específico.
3. Realice las actualizaciones apropiadas para cualquier tipo de activo listado bajo testing-methodology.
4. Guarde el archivo en su ubicación actual.

Nota: El nombre del punto de control visible en axe Auditor también se puede cambiar utilizando las mismas instrucciones. En lugar de actualizar la sección testing-methodology, actualice el atributo name bajo el punto de control relevante en el mismo archivo.

Actualizar el Impacto de una Regla

Puede cambiar el nivel de impacto (bloqueante, crítico, serio, moderado, menor) para cada problema dentro de axe Auditor. Sin embargo, si necesita cambiar el impacto predeterminado para una regla, siga estas instrucciones.

Los impactos en axe Auditor se almacenan a nivel de regla, no a nivel de Criterios de Éxito de WCAG o de punto de control. Una sola regla puede afectar múltiples puntos de control de Deque (por ejemplo, id de regla alt-text-dynamic-image-inconsistent). Modificar el impacto para la regla cambia el impacto predeterminado para un problema desencadenado por la violación de esta regla a través de los todos Criterios de Éxito de WCAG conectados a la regla.

Archivos actualizados: package/dist/bundle/descriptions.json

Pasos:

1. Localice la regla específica de Deque en el archivo JSON (por ejemplo, alt-text-dynamic-image-inconsistent).
2. Busque el atributo impact bajo esa regla específica.
3. Actualice el impacto con un valor numérico (vea la tabla a continuación).
4. Guarde el archivo en su ubicación actual.

Mapeo de valores de impacto

Añadir un Nuevo Estándar de Accesibilidad (por ejemplo, un Estándar Específico de la Organización)

Si tiene estándares de prueba específicos de la organización que desea proporcionar a sus equipos además de los estándares existentes (como WCAG 2.1 AA o ACAA), use los siguientes pasos.

⚠️ Deque interno — resolver antes de publicar: La lista de archivos para esta sección hace referencia a tres rutas relacionadas con los puntos de control que son inconsistentes con el resto del documento (que usa dist/bundle/…): package/dist/checkpoints.json, package/dist/issue-descriptions.json y package/dist/bundle/checkpoints.json. Confirme si dist/checkpoints.json y dist/issue-descriptions.json son realmente archivos compilados distintos, o si estos son errores de ruta, luego actualice la lista en consecuencia y elimine esta nota.

Archivos actualizados:

• 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

Pasos:

1. Cree un nuevo objeto de arreglo para el estándar en standards.json. El enfoque más fácil es copiar todo el objeto para wcag21aa y añadirlo al final del archivo.
2. Cambie el id del objeto recién copiado a algo único que signifique el estándar que representa.
3. Actualice el arreglo rubric para el nuevo objeto para representar todos los estándares de prueba subyacentes que son parte de este nuevo estándar.
4. En descriptions.json, para todas las reglas asociadas con su nuevo estándar, agregue el id del nuevo estándar (de standards.json) al arreglo standards.
5. En testingMethodologies.json, agregue el id del nuevo estándar bajo el arreglo standards para cada tipo de activo digital al que se aplica este estándar.
6. En standards.en.json, agregue un nuevo objeto con el id y nombre del nuevo estándar. El campo name es lo que los usuarios ven en la interfaz de usuario de axe Auditor.
7. En dist/checkpoints.json, actualice el arreglo standards bajo cada descripción del problema para los puntos de control aplicables.
8. En issue-descriptions.json, actualice el arreglo standards para todos los objetos de regla aplicables.
9. En dist/bundle/checkpoints.json, actualice el arreglo standards de cada punto de control aplicable con el estándar correcto.

Actualice las Descripciones Cortas y Largas de Problemas para Reglas Específicas

Use estas instrucciones para actualizar el texto de selección de descripción del problema (corto) y la descripción larga del tipo de problema para cada regla. Una sola regla puede afectar múltiples Criterios de Éxito de WCAG — cambiar este texto afecta todos Criterios de Éxito a los que está conectado.

Archivos actualizados: package/dist/bundle/locales/descriptions.en.json

Pasos:

1. En descriptions.en.json, busque la regla específica (por ejemplo, alt-text-dynamic-image-inconsistent).
2. Actualice el texto para shortText (Descripción Corta del Problema) y issueDescText (Descripción Larga del Problema) según corresponda.
3. Guarde el archivo en su ubicación actual.

Actualice la Recomendación de Remediación

Si desea cambiar la biblioteca de remediación y las descripciones asociadas para alinearse con su política, use las siguientes instrucciones.

Archivos actualizados: package/dist/bundle/locales/recommendations.en.json

Pasos:

1. En recommendations.en.json, busca la regla específica (por ejemplo, alt-text-dynamic-image-inconsistent) y la combinación de puntos de verificación para la cual deseas cambiar la biblioteca de remediación.
2. Actualiza el texto para recommendationType (Técnica de Recomendación), rule, howtofix y background (secciones de la recomendación para corregir) según corresponda.
3. Guarde el archivo en su ubicación actual.

Eliminar Tipos de Activos Digitales

Usa esto cuando un tipo de activo dado no aplique a tu organización (por ejemplo, si las pruebas de PDF o Android están fuera del alcance).

Archivos a actualizar:

• dist/bundle/testingMethodologies.json — datos principales de metodologías de prueba
• dist/bundle/locales/testingMethodologies.en.json — traducciones al inglés

Paso 1: Eliminar del archivo de metodologías de prueba

Archivo: dist/bundle/testingMethodologies.json

Encuentra y elimina todo el objeto de la metodología que deseas borrar.

// 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

Paso 2: Eliminar del archivo del idioma inglés

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

Elimina el mismo objeto de metodología de este archivo.

Agregar un Nuevo Tipo de Activo Digital

Usa esto para agregar un nuevo tipo de activo digital, por ejemplo, una metodología web-app o macos. El ejemplo a continuación usa web-app; sustituye tu propio id. de tipo de activo según sea necesario.

Archivos a actualizar:

• dist/bundle/testingMethodologies.json — datos principales de metodologías de prueba
• dist/bundle/locales/testingMethodologies.en.json — traducciones al inglés
• dist/bundle/locales/checkpoints.en.json — contenido de puntos de verificación en inglés con secciones de metodologías de prueba
• dist/bundle/checkpoints.json — datos principales de puntos de verificación
• dist/bundle/descriptions.json — descripciones de problemas con referencias a metodologías de prueba
• dist/bundle/schemata.json — definiciones de esquemas con referencias a metodologías de prueba

Paso 1: Añadir al archivo de metodologías de prueba

Archivo: dist/bundle/testingMethodologies.json

Añade el nuevo objeto de metodología al 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"
  ]
}

Paso 2: Añadir al archivo del idioma inglés

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

Añade el mismo objeto de metodología a este archivo.

Paso 3: Añadir referencias al archivo de puntos de verificación

Archivo: dist/bundle/checkpoints.json

Para cada punto de verificación que deba soportar la nueva metodología, añádelo al array testingMethodologies de ese punto de verificación.

{
  "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"
  ]
}

Paso 4: Añadir contenido de metodologías de prueba al archivo de idioma de los puntos de verificación

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

Para cada punto de verificación que deba soportar la nueva metodología, añade el contenido de la metodología de prueba.

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

Paso 5: Añadir referencias al archivo de descripciones

Archivo: dist/bundle/descriptions.json

Para las descripciones de problemas que deban soportar la nueva metodología, añádela a su array testingMethodologies.

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

Paso 6: Añadir referencias al archivo de esquemas

Archivo: dist/bundle/schemata.json

Añade la nueva metodología de prueba a las definiciones de esquemas.

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

Agregar un Nuevo Punto de Verificación

Agregar un Punto de Verificación No WCAG

Importante: Los puntos de verificación no WCAG no soportan descripciones o recomendaciones predefinidas a través de descriptions.json y recommendations.json. Al registrar problemas con estos puntos de verificación, ingresas descripciones y recomendaciones manualmente utilizando la función Crea tu propia descripción en la herramienta.

Archivos para actualizar — solo 2:

• package/dist/bundle/checkpoints.json — define el punto de verificación
• package/dist/bundle/locales/checkpoints.en.json — proporciona metodología de prueba localizada

Paso 1: Añadir el punto de verificación a checkpoints.json

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

Campos clave:

• id — identificador único usando tu formato personalizado (por ejemplo, custom.1.1, brand.2.3, TT.01.A, s.1.1).
• successCriteria — cadena vacía "" para puntos de verificación no WCAG (o un formato personalizado como "tt-01.A").
• standards — tu identificador de estándar personalizado, por ejemplo, ["custom"], ["TT508"], ["smoke"], ["brand"] (no ["wcag2a"]).
• testingMethodologies — plataformas donde se aplica este punto de verificación: desktop, mobile, kiosk, native-mobile-ios, native-mobile-android, pdf, windows-desktop, ms-excel, ms-powerpoint, ms-word.
• requiredSenses — qué sentidos se necesitan para probar este punto de verificación (sight, hearing: true/false).
• automatedRules — array opcional de ids de reglas automatizadas (típicamente vacío [] para puntos de verificación personalizados).
• grouping — agrupación lógica para organización (por ejemplo, "custom.1", "1", "s.1").
• categories — categorías de accesibilidad relevantes (puede estar vacío [] para no WCAG).
• terms — array opcional de referencias de términos de glosario con propiedades id y ordinal.

Paso 2: Agregar contenido localizado a checkpoints.en.json

Utilice el formato de id de con guiones: convierta puntos en guiones (por ejemplo, custom-1-1, no 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."
  }
}

Utilice \n para nuevas líneas y etiquetas HTML adecuadas para listas.

Añadiendo un Punto de Referencia WCAG

Archivos a actualizar — 6 archivos para una implementación completa de un punto de referencia WCAG:

1. package/dist/bundle/checkpoints.json — definir el punto de referencia con campos específicos para WCAG.
2. package/dist/bundle/locales/checkpoints.en.json — metodología de prueba localizada, ejemplos, técnicas relacionadas (utilice el formato de id con guiones: 1-4-3-a, no 1.4.3.a).
3. package/dist/bundle/descriptions.json — descripciones de problemas con niveles de impacto y referencias de puntos de referencia.
4. package/dist/bundle/locales/descriptions.en.json — descripciones de problemas localizadas.
5. package/dist/bundle/recommendations.json — recomendaciones de remediación vinculadas a descripciones de problemas.
6. package/dist/bundle/locales/recommendations.en.json — contenido de recomendación localizado (título, descripción, pasos, recursos).

Opcional — entrada manual: Si prefiere omitir agregar descripciones y recomendaciones predefinidas a los archivos JSON, puede manejarlas al registrar problemas en la herramienta: seleccione su punto de referencia WCAG, elija Crea tu propia descripción en lugar de uno predefinido, luego ingrese manualmente la descripción y, si es necesario, la recomendación adaptada al problema encontrado.

Paso 1: Definir el punto de referencia

Archivo: 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"]
}

Campos clave:

• id — patrón de numeración WCAG (por ejemplo, "1.4.3.a", "2.1.1.b").
• successCriteria — número de criterio de éxito WCAG (por ejemplo, "1.4.3").
• standards — "wcag2a" (Nivel A), "wcag2aa" (Nivel AA), o "wcag2aaa" (Nivel AAA).
• automatedRules — array de ids de reglas automatizadas.
• grouping — número de directriz WCAG (por ejemplo, "1.4", "2.1").

Paso 2: Agregar la metodología de prueba

Archivo: package/dist/bundle/locales/checkpoints.en.json — use el formato con guiones (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>"
  }
}

Paso 3: Agregar descripciones de problemas

Archivo: 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"]
    }
  ]
}

Paso 4: Agregar descripciones de problemas localizadas

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

Agregar un objeto para la nueva descripción:

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

Paso 5: Agregar recomendaciones

Archivo: package/dist/bundle/recommendations.json

Utilice el formato con guiones (1-4-3-a) y agréguelo al id de la recomendación.

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

Paso 6: Agregar contenido de recomendaciones

Archivo: 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"
  ]
}

Eliminar un Punto de Referencia Específico

Use estas instrucciones si hay un punto de referencia específico que no desea que su equipo pruebe e informe.

Archivos actualizados:

• 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

Pasos:

1. En checkpoints.json, busque el punto de referencia específico (por ejemplo, 1.2.1.b). Elimine todo el objeto asociado con este punto de referencia mientras mantiene un JSON válido. Guarde el archivo.
2. En descriptions.json, busque el punto de referencia específico (por ejemplo, 1.2.1.b). Elimine solo el objeto que utiliza el punto de referencia bajo la regla mientras mantiene un JSON válido. Una sola regla puede aplicarse a múltiples puntos de referencia — elimine solo el objeto del punto de referencia que está eliminando; no elimine la regla completa. Guarde el archivo.
3. En recommendations.json, busque el punto de referencia específico (por ejemplo, 1.2.1.b). Elimine cada objeto asociado con este punto de referencia (puede haber más de uno) mientras mantiene un JSON válido. Guarde el archivo.
4. En checkpoints.en.json, busque el punto de referencia específico utilizando el formato con guiones (por ejemplo, 1-2-1-b). Elimine todo el objeto mientras mantiene un JSON válido. Guarde el archivo.
5. En recommendations.en.json, busque el punto de referencia específico utilizando el formato con guiones (por ejemplo, 1-2-1-b). Elimine cada objeto asociado con este punto de referencia (puede haber más de uno) mientras mantiene un JSON válido. Guarde el archivo.

Enviando Cambios de Vuelta a Deque

Cuando las ediciones estén completas y validadas:

1. Confirme que cada archivo editado aún pase la validación de JSON (vea Antes de comenzar).
2. Confirme que los cambios coincidan con el alcance acordado.
3. Envíe toda la carpeta package de vuelta a Deque en su estructura original (no envíe solo archivos individuales).

Deque asignará la versión, empaquetará el paquete, lo mapeará a la versión correcta de axe-core, y lo desplegará en un instancia de prueba para verificación. Después de que su equipo verifique los cambios en la instancia de prueba y dé su aprobación, Deque promueve la metodología a su instancia producción.

Soporte

Para preguntas sobre este proceso, el alcance del cambio acordado, o para solicitar soporte adicional de idioma, contacte a su punto de contacto en Deque.