Sweent obtém a certificação Trusted Tester do Departamento de Segurança Interna dos EUA

Nós passamos no exame. A partir deste mês, a equipe da Sweent possui a certificação Trusted Tester for Web do Departamento de Segurança Interna dos EUA (DHS), obtida no exame de acordo com o processo de teste atual (versão 5.1.3). É uma credencial que queríamos na equipe há algum tempo, e obtê-la muda a forma como podemos conversar sobre o trabalho de acessibilidade com as agências e empresas que atendemos. Mas a certificação em si é amplamente mal compreendida, então vale a pena explicar o que é e o que não é.

Não existe uma “empresa certificada 508"

Comece aqui, porque é a fonte da maior parte da confusão nesse mercado. Muitos fornecedores anunciam que são “certificados pela Seção 508”. Nenhum órgão governamental emite isso. Não há certificação em nível de empresa para conformidade com a Seção 508, e qualquer pessoa que afirme o contrário está ignorando o idioma ou esperando que você não verifique.

O que realmente existe é o programa Trusted Tester administrado pelo Escritório de Sistemas e Tecnologia Acessíveis (OAST) do Departamento de Segurança Interna dos EUA, o escritório federal responsável pela acessibilidade em todo o governo. Ele certifica pessoas individuais, não organizações. Um testador estuda a metodologia, passa em um exame prático e ganha a credencial. Portanto, a afirmação honesta e defensável é a que estamos fazendo: um engenheiro da Sweent é um testador confiável certificado, o que significa que podemos aplicar o processo de teste oficial do governo federal internamente, em vez de terceirizá-lo ou aproximá-lo.

Se você estiver avaliando qualquer fornecedor de acessibilidade, essa distinção é um filtro útil. Pergunte quem em sua equipe possui a certificação e qual versão do processo eles usaram. Uma resposta real é um bom sinal.

O que realmente é o processo do Trusted Tester

O Trusted Tester é uma metodologia manual padronizada para verificar se uma página da Web está em conformidade com os padrões revisados da Seção 508. Esses padrões, por sua vez, incorporam os critérios de sucesso de nível A e AA das WCAG 2.0, portanto, na prática, o processo está testando os mesmos requisitos de acessibilidade que a maioria das pessoas já conhece das WCAG.

A palavra que importa é padronizado. O processo conduz o testador por cada página e componente com uma sequência fixa de verificações: operabilidade do teclado, ordem de foco, funções e estados do ARIA, rotulagem de formulários e tratamento de erros, contraste, ordem de leitura e assim por diante. Como cada testador certificado segue o mesmo script, dois testadores diferentes avaliando a mesma página devem alcançar o mesmo resultado. Essa repetibilidade é o ponto principal. É o que torna uma reivindicação de conformidade defensável quando um escritório de compras, uma equipe jurídica ou um revisor da agência pergunta como você sabe que o software está acessível.

Por que não confiamos apenas em escaneamentos automatizados

Os scanners automatizados de acessibilidade são realmente úteis e nós os executamos. Aponte um para um local de produção e, em alguns minutos, você obterá uma lista de atributos alternativos ausentes, texto de baixo contraste e algum ARIA malformado. Esse é um valor real com quase nenhum esforço.

Mas é uma fatia da imagem. Os testes do setor mostram consistentemente que as ferramentas automatizadas detectam algo na faixa de 30 a 40 por cento dos problemas das WCAG. Eles não enxergam as coisas que mais afetam os usuários reais:

• Se você pode operar toda a interface com um teclado e se o foco fica em algum lugar sensato quando um menu ou modal é aberto

• Se o foco está preso corretamente dentro de uma caixa de diálogo e liberado corretamente quando ela é fechada

• Se um leitor de tela anuncia a qual campo uma mensagem de erro pertence

• Se a ordem de leitura que um leitor de tela segue corresponde à ordem visual que um usuário com visão vê

Nada disso pode ser verificado por um script que analisa o DOM. Eles exigem que uma pessoa opere a página da mesma forma que um usuário de tecnologia assistiva faria. O processo Trusted Tester existe exatamente porque a camada automatizada fica muito aquém de uma resposta real de conformidade.

O que isso significa se você estiver comprando software

Para nossos clientes federais e estaduais, o resultado prático é simples: podemos produzir testes de conformidade que podem ser analisados e documentados em um VPAT, o modelo voluntário de acessibilidade de produtos que a maioria das compras do setor público exige antes de considerarem um produto. Ter um Trusted Tester certificado internamente significa que os testes e a documentação por trás deles vêm da mesma equipe que entende sua base de código, não de um fornecedor separado integrado ao processo.

Para clientes comerciais, o valor tem menos a ver com a sigla e mais com a disciplina que ela representa. Uma equipe que testa o padrão Trusted Tester é uma equipe que pensou muito sobre usuários de teclado, usuários de leitores de tela e os modos de falha que uma ferramenta automatizada nunca vê. Se você recebeu uma carta de demanda da ADA ou só quer que seu produto funcione para todos que tentam usá-lo, essa disciplina é o que você realmente está pagando.

Onde isso se encaixa com o resto do nosso trabalho

Isso não é um pivô para uma nova linha de serviço. A acessibilidade tem sido parte da forma como criamos software desde o início, e fizemos um trabalho de remediação que envolveu testes reais de leitores de tela em aplicativos ativos, em vez da revisão da lista de verificação. A certificação formaliza algo que a equipe já estava fazendo e aumenta o limite do que podemos prometer: não “usamos um scanner e ele parecia limpo”, mas “um testador certificado conduziu a solicitação pelo processo federal de conformidade, e aqui está o resultado documentado”.

Se a acessibilidade está em seu roteiro ou está em sua mesa como um requisito que você precisa satisfazer agora, essa é a conversa que estamos preparados para ter.