Suporte à Metodologia Personalizada

Configuração de Metodologia de Testes Manuais Personalizada no axe Auditor

Finalidade

Os clientes que usam o axe Auditor às vezes precisam ajustar a metodologia de testes manuais (o DequeWay). Essa necessidade pode surgir de:

• Políticas internas específicas que requerem verificações adicionais ou menos verificações.
• Diretrizes internas para usar ferramentas específicas ao realizar testes.
• Decisões políticas que mudam vários atributos de problemas (impacto, descrições, recomendações).

Este documento descreve as personalizações que podem ser feitas na metodologia de testes manuais no axe Auditor e explica como essas mudanças retornam para a Deque para empacotamento e implantação na sua instância hospedada.

Como isto funciona: funções e fluxo de trabalho

A instância do axe Auditor da sua organização é hospedada e gerida pela Deque. Isso significa que a Deque gerencia a instalação, a sequência de versões, o empacotamento e a implantação da metodologia. Sua equipe é responsável apenas por editar os arquivos de configuração da metodologia. Você não precisa atualizar números de versão, construir pacotes ou executar qualquer comando de instalação ou banco de dados. A Deque cuida de tudo isso em seu nome.

O processo de ponta a ponta é:

Nota de escopo: Este documento lista todos os tipos de personalização disponíveis para completar. As alterações específicas que sua equipe fará devem estar alinhadas com o escopo de mudança acordado.

Antes de começar

1. Faça o backup do original. Antes de editar qualquer coisa, faça uma cópia da pasta package descomprimida. Se uma edição quebrar o pacote, esta é sua única maneira limpa de reverter.

cp -r package package_backup_original

2. Edite apenas os arquivos listados em cada seção. Os arquivos são interdependentes. Editar um arquivo que não está listado para uma determinada alteração — ou deixar de editar um que é listado — pode gerar um pacote que falha apenas após ser retornado à Deque.

3. Valide todos os arquivos que você modificar. Cada arquivo é JSON e deve permanecer um JSON válido após a edição (sem vírgulas finais, chaves/colchetes balanceados). 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. Presunção de idioma. Estas instruções assumem o inglês (en). Se sua organização precisar de metodologia em idiomas adicionais, informe à Deque — a Deque habilita suporte a idiomas durante a configuração. Nesse caso, toda edição que você fizer em um arquivo .en.json também deve ser feita no arquivo do idioma correspondente (por exemplo, o equivalente em .nl.json) para cada idioma adicional.

Atualizações permitidas

Atualizar a metodologia de teste para um ponto de verificação específico

Útil quando você deseja alterar as instruções de teste para um ponto de verificação específico no axe Auditor.

Arquivos atualizados: package/dist/bundle/locales/checkpoints.en.json

Passos:

1. Localize o ponto de verificação específico da Deque no arquivo JSON (por exemplo, 1.1.1.a).
2. Procure o atributo testing-methodology sob esse ponto de verificação específico.
3. Faça as atualizações apropriadas para qualquer tipo de recurso listado sob testing-methodology.
4. Salve o arquivo em sua localização atual.

Observação: O nome do ponto de verificação visível no axe Auditor também pode ser alterado usando as mesmas instruções. Em vez de atualizar a seção testing-methodology, atualize o atributo name sob o ponto de verificação relevante no mesmo arquivo.

Atualizar o impacto de uma regra

Você pode alterar o nível de impacto (bloqueador, crítico, sério, moderado, menor) para cada problema no axe Auditor. No entanto, se precisar alterar o padrão impacto de uma regra, siga estas instruções.

Os impactos no axe Auditor são guardados no nível regra, não no nível de Critérios de Sucesso WCAG ou ponto de verificação. Uma única regra pode afetar múltiplos pontos de verificação da Deque (por exemplo, id de regra alt-text-dynamic-image-inconsistent). Modificar o impacto para a regra muda o impacto padrão de um problema causado pela violação desta regra em todos os todos Critérios de Sucesso WCAG conectados a ela.

Arquivos atualizados: package/dist/bundle/descriptions.json

Passos:

1. Localize a regra específica da Deque no arquivo JSON (por exemplo, alt-text-dynamic-image-inconsistent).
2. Procure o atributo impact sob essa regra específica.
3. Atualize o impacto com um valor numérico (veja a tabela abaixo).
4. Salve o arquivo em sua localização atual.

Mapeamentos de valores de impacto

Adicionar um novo padrão de acessibilidade (por exemplo, um padrão específico da organização)

Se você tiver padrões de teste específicos da organização que gostaria de fornecer às suas equipes além dos padrões existentes (como WCAG 2.1 AA ou ACAA), use os passos a seguir.

⚠️ Interno da Deque — resolver antes de publicar: A lista de arquivos desta seção faz referência a três caminhos relacionados a pontos de verificação que são inconsistentes com o restante do documento (que usa dist/bundle/…): package/dist/checkpoints.json, package/dist/issue-descriptions.json e package/dist/bundle/checkpoints.json. Confirme se dist/checkpoints.json e dist/issue-descriptions.json são de fato arquivos compilados distintos, ou se são erros de caminho, então atualize a lista conforme necessário e remova esta nota.

Arquivos atualizados:

• 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

Passos:

1. Crie um novo objeto de array para o padrão em standards.json. A abordagem mais fácil é copiar o objeto inteiro para wcag21aa e adicioná-lo ao final do arquivo.
2. Altere o id do objeto recém-copiado para algo único que represente o padrão que ele representa.
3. Atualize o array rubric para o novo objeto, de modo a representar todos os padrões de teste subjacentes que fazem parte deste novo padrão.
4. Em descriptions.json, para todas as regras associadas ao seu novo padrão, adicione o id do novo padrão (de standards.json) ao array standards.
5. Em testingMethodologies.json, adicione o id do novo padrão sob o array standards para cada tipo de ativo digital ao qual este padrão se aplica.
6. Em standards.en.json, adicione um novo objeto com o id e nome do novo padrão. O campo name é o que os usuários veem na interface do usuário do axe Auditor.
7. Em dist/checkpoints.json, atualize o array standards sob cada descrição de problema para os checkpoints aplicáveis.
8. Em issue-descriptions.json, atualize o array standards para todos os objetos de regra aplicáveis.
9. Em dist/bundle/checkpoints.json, atualize o array standards de cada checkpoint aplicável com o padrão correto.

Atualizar as descrições curtas e longas dos problemas para regras específicas

Use estas instruções para atualizar o texto de seleção da descrição do problema (curta) e a descrição longa do tipo de problema para cada regra. Uma única regra pode afetar múltiplos Critérios de Êxito WCAG — mudar este texto afeta todos Critérios de Êxito aos quais está conectado.

Arquivos atualizados: package/dist/bundle/locales/descriptions.en.json

Passos:

1. Em descriptions.en.json, procure pela regra específica (por exemplo, alt-text-dynamic-image-inconsistent).
2. Atualize o texto para shortText (Descrição Curta do Problema) e issueDescText (Descrição Longa do Problema) conforme apropriado.
3. Salve o arquivo em seu local atual.

Atualizar a recomendação de remediação

Se você quiser mudar a biblioteca de remediação e as descrições associadas para se alinhar com sua política, use as instruções a seguir.

Arquivos atualizados: package/dist/bundle/locales/recommendations.en.json

Passos:

1. Em recommendations.en.json, procure pela regra específica (por exemplo, alt-text-dynamic-image-inconsistent) e combinação de checkpoint para a qual você quer mudar a biblioteca de remediação.
2. Atualize o texto para recommendationType (Técnica de Recomendação), rule, howtofix e background (seções da recomendação para corrigir) conforme apropriado.
3. Salve o arquivo em seu local atual.

Remover tipos de ativos digitais

Use isto quando um determinado tipo de ativo não se aplica à sua organização (por exemplo, se o teste de PDF ou Android está fora do escopo).

Arquivos para atualizar:

• dist/bundle/testingMethodologies.json — dados principais das metodologias de teste
• dist/bundle/locales/testingMethodologies.en.json — traduções em inglês

Passo 1: Remover do arquivo de metodologias de teste

Arquivo: dist/bundle/testingMethodologies.json

Encontre e remova o objeto inteiro da metodologia que deseja excluir.

// 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: Remover do arquivo de idioma inglês

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

Remova o mesmo objeto de metodologia deste arquivo.

Adicionar um novo tipo de ativo digital

Use isto para adicionar um novo tipo de ativo digital — por exemplo, uma metodologia de web-app ou macos. Abaixo, usa-se web-app como exemplo; substitua pelo seu próprio id de tipo de ativo conforme necessário.

Arquivos para atualizar:

• dist/bundle/testingMethodologies.json — dados principais das metodologias de teste
• dist/bundle/locales/testingMethodologies.en.json — traduções em inglês
• dist/bundle/locales/checkpoints.en.json — conteúdo de checkpoints em inglês com seções de metodologia de teste
• dist/bundle/checkpoints.json — dados principais dos checkpoints
• dist/bundle/descriptions.json — descrições de problemas com referências de metodologia de teste
• dist/bundle/schemata.json — definições de esquema com referências de metodologia de teste

Passo 1: Adicionar ao arquivo de metodologias de teste

Arquivo: dist/bundle/testingMethodologies.json

Adicione o novo objeto de metodologia ao 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: Adicionar ao arquivo de idioma inglês

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

Adicione o mesmo objeto de metodologia a este arquivo.

Passo 3: Adicionar referências ao arquivo de ponto de verificação

Arquivo: dist/bundle/checkpoints.json

Para cada ponto de verificação que deve suportar a nova metodologia, adicione-o ao array testingMethodologies desse ponto de verificação.

{
  "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: Adicionar conteúdo de metodologia de teste ao arquivo local de ponto de verificação

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

Para cada ponto de verificação que deve suportar a nova metodologia, adicione o conteúdo de metodologia de teste.

{
  "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: Adicionar referências ao arquivo de descrições

Arquivo: dist/bundle/descriptions.json

Para descrições de problemas que devem suportar a nova metodologia, adicione-as ao array testingMethodologies.

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

Passo 6: Adicionar referências ao arquivo de esquema

Arquivo: dist/bundle/schemata.json

Adicione a nova metodologia de teste às definições do esquema.

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

Adicionar um novo ponto de verificação

Adicionando um ponto de verificação não WCAG

Importante: Pontos de verificação não WCAG não suportam descrições ou recomendações pré-definidas através de descriptions.json e recommendations.json. Ao registar problemas com esses pontos de verificação, você insere descrições e recomendações manualmente usando o recurso Crie sua própria descrição na ferramenta.

Arquivos para atualizar — apenas 2:

• package/dist/bundle/checkpoints.json — definir o ponto de verificação
• package/dist/bundle/locales/checkpoints.en.json — fornecer metodologia de teste localizada

Passo 1: Adicionar o ponto de verificação a checkpoints.json

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

Campos-chave:

• id — identificador exclusivo usando seu formato personalizado (e.g., custom.1.1, brand.2.3, TT.01.A, s.1.1).
• successCriteria — string vazia "" para pontos de verificação não WCAG (ou um formato personalizado como "tt-01.A").
• standards — seu identificador de padrão personalizado, e.g., ["custom"], ["TT508"], ["smoke"], ["brand"] (não ["wcag2a"]).
• testingMethodologies — plataformas onde este ponto de verificação se aplica: desktop, mobile, kiosk, native-mobile-ios, native-mobile-android, pdf, windows-desktop, ms-excel, ms-powerpoint, ms-word.
• requiredSenses — quais sentidos são necessários para testar este ponto de verificação (sight, hearing: true/false).
• automatedRules — array opcional de IDs de regras automatizadas (tipicamente vazio [] para pontos de verificação personalizados).
• grouping — agrupamento lógico para organização (e.g., "custom.1", "1", "s.1").
• categories — categorias de acessibilidade relevantes (pode estar vazio [] para não WCAG).
• terms — array opcional de referências de termos do glossário com propriedades id e ordinal.

Passo 2: Adicione conteúdo localizado a checkpoints.en.json

Use o formato de id hifenizado: converta pontos em hifens (e.g., custom-1-1, não 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."
  }
}

Use \n para quebras de linha e as tags HTML apropriadas para listas.

Adicionando um ponto de verificação WCAG

Arquivos a serem atualizados — 6 arquivos para uma implementação completa do ponto de verificação WCAG:

1. package/dist/bundle/checkpoints.json — definir o ponto de verificação com campos específicos do WCAG.
2. package/dist/bundle/locales/checkpoints.en.json — metodologia de teste localizada, exemplos, técnicas relacionadas (use o formato de id hifenizado: 1-4-3-a, não 1.4.3.a).
3. package/dist/bundle/descriptions.json — descrições de problemas com níveis de impacto e referências de ponto de verificação.
4. package/dist/bundle/locales/descriptions.en.json — descrições de problemas localizadas.
5. package/dist/bundle/recommendations.json — recomendações de remediação vinculadas a descrições de problemas.
6. package/dist/bundle/locales/recommendations.en.json — conteúdo de recomendação localizado (título, descrição, passos, recursos).

Opcional — entrada manual: Se preferir pular a adição de descrições e recomendações predefinidas nos arquivos JSON, você pode lidar com elas ao registrar problemas na ferramenta: selecione seu ponto de verificação WCAG, escolha Crie sua própria descrição em vez de um predefinido, depois insira manualmente a descrição e (se necessário) a recomendação adaptada ao problema encontrado.

Passo 1: Defina o ponto de verificação

Arquivo: 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 principais:

• id — Padrão de numeração WCAG (e.g., "1.4.3.a", "2.1.1.b").
• successCriteria — Número do critério de sucesso WCAG (e.g., "1.4.3").
• standards — "wcag2a" (Nível A), "wcag2aa" (Nível AA), ou "wcag2aaa" (Nível AAA).
• automatedRules — Matriz de IDs de regras automatizadas.
• grouping — Número da diretriz WCAG (e.g., "1.4", "2.1").

Passo 2: Adicione a metodologia de teste

Arquivo: package/dist/bundle/locales/checkpoints.en.json — use o formato hifenizado (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: Adicione descrições dos problemas

Arquivo: 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: Adicione descrições localizadas dos problemas

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

Adicione um objeto para a nova descrição:

"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: Adicione recomendações

Arquivo: package/dist/bundle/recommendations.json

Use o formato hifenizado (1-4-3-a) e anexe ao ID da recomendação.

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

Passo 6: Adicione o conteúdo da recomendação

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

Remover um ponto de verificação específico

Use estas instruções se houver um ponto de verificação específico que sua equipe não quer testar e relatar.

Arquivos atualizados:

• 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

Passos:

1. Em checkpoints.json, procure pelo ponto de verificação específico (e.g., 1.2.1.b). Apague todo o objeto associado a este ponto de verificação enquanto mantém o JSON válido. Salve o arquivo.
2. Em descriptions.json, procure pelo ponto de verificação específico (e.g., 1.2.1.b). Apague apenas o objeto que usa o ponto de verificação sob a regra enquanto mantém o JSON válido. Uma única regra pode se aplicar a múltiplos pontos de verificação — remova apenas o objeto do ponto de verificação que você está removendo; não remova a regra completa. Salve o arquivo.
3. Em recommendations.json, procure pelo ponto de verificação específico (e.g., 1.2.1.b). Apague todo objeto associado a este ponto de verificação (podem haver mais de um) enquanto mantém o JSON válido. Salve o arquivo.
4. Em checkpoints.en.json, procure pelo ponto de verificação específico usando o formato hifenizado (e.g., 1-2-1-b). Apague todo o objeto enquanto mantém o JSON válido. Salve o arquivo.
5. Em recommendations.en.json, procure pelo ponto de verificação específico usando o formato hifenizado (e.g., 1-2-1-b). Apague todo objeto associado a este ponto de verificação (podem haver mais de um) enquanto mantém o JSON válido. Salve o arquivo.

Enviando alterações de volta para a Deque

Quando as edições estiverem completas e validadas:

1. Confirme que cada arquivo editado ainda passa na validação JSON (consulte Antes de começar).
2. Confirme se as alterações correspondem ao escopo acordado.
3. Envie toda a pasta package de volta para a Deque em sua estrutura original (não envie apenas arquivos individuais).

Deque atribuirá a versão, empacotará o pacote, mapeará para a versão correta do axe-core e implantará em uma instância de teste para verificação. Após sua equipe verificar as alterações na instância de teste e aprová-las, a Deque promove a metodologia para sua instância de produção.

Suporte

Para perguntas sobre este processo, o escopo da mudança acordado, ou para solicitar suporte adicional em outra língua, entre em contato com seu ponto de contato na Deque.