Cartilha ACESSIBILIDADE NA WEB

1. Introdução

No Fascículo V "Mantendo o conteúdo acessível", aprendemos como integrar a acessibilidade na cultura da instituição, para ser possível manter a acessibilidade das páginas, aplicativos e redes sociais. Também estudamos alguns procedimentos para a criação de conteúdos acessíveis, a fim de evitar a perda da acessibilidade à medida que novas informações são criadas e inseridas. Entretanto, para alcançar essa meta de conservação da acessibilidade conquistada, é preciso mais do que uma atenção especial à capacitação e à atualização do time técnico.

Neste fascículo, serão apresentadas mais detalhadamente as rotinas de validação, bem como sua inserção nos projetos e na cultura da instituição. Este é o último fascículo desta série. Foi uma jornada longa! Esperamos contribuir para que a acessibilidade se torne mais simples de ser implementada por empresas, instituições e até mesmo em projetos pessoais. Durante o processo, trouxemos não só um pouco do que tem sido feito por brasileiros, muito conteúdo maravilhoso produzido por pessoas de diversas partes do país, mas também alguns conteúdos para nossa língua, os quais, até o momento, ainda estavam apenas em inglês, como foi o caso da Iniciativa de Acessibilidade na Web (Web Accessibility Initiative – WAI), e a base para o Capítulo 3: “Integrando a acessibilidade na cultura da instituição” (Planning and Managing Web Accessibility).

Todos os conteúdos dos fascículos anteriores podem ser consultados no Acervo do Centro de Estudos sobre Tecnologias Web (Ceweb), no endereço: https://acervo.ceweb.br/cartilha-acessibilidade-web.

2. Planejando a Avaliação

O planejamento das Rotinas de Avaliação faz parte da etapa Planejar (Capítulo 3.2 do Fascículo V), executadas nas etapas Implementar (Capítulo 3.3) e Sustentar (Capítulo 3.4). Para criar uma rotina de avaliação, é importante saber, em cada etapa do desenvolvimento, o que se deve testar e o porquê.

• quais métodos de teste de acessibilidade serão usados e em que pontos do processo de desenvolvimento serão aplicados;
• como os métodos de validação apoiarão a equipe de produção para garantir o progresso em direção ao grau desejado de experiência de pessoas usuárias;
• como os resultados serão documentados;
• como os resultados serão integrados ao processo de produção para melhorar o produto.

No Capítulo 5 do Fascículo IV, abordamos brevemente sobre avaliação humana, validação automatizada e ferramentas disponíveis. É importante lembrar que muitas ferramentas indicadas podem ser descontinuadas, assim como alguns checklists podem se tornar defasados de acordo com as modificações no uso e nas tecnologias.

A W3C Web Accessibility Initiative (WAI) propõe dois métodos de avaliação de acessibilidade: um simples, para uma primeira revisão, e outro mais robusto, a Metodologia de Avaliação de Conformidade de Acessibilidade de Sítios (Website Accessibility Conformance Evaluation Methodology – WCAG-EM).

2.1. Avaliação Simples

A avaliação simples [1] serve para se ter uma ideia preliminar da acessibilidade e contempla apenas alguns problemas mais comuns. A WAI fornece um passo-a-passo dessa avaliação, que inclui verificar:

• o título da página;
• o texto alternativo das imagens;
• texto: cabeçalhos, relações de contraste e redimensionamento por texto;
• interações: operação por teclado e foco visível, formulários, rótulos e mensagens de erro;
• geral: alternativas para conteúdo multimídia, conteúdo em movimento, intermitente ou piscante, estrutura da página.

Por ser uma avaliação simplificada, uma página da Web pode passar pelas verificações, mas, ainda assim, ter barreiras de acessibilidade significativas. Logo, uma avaliação mais robusta é necessária para avaliar a acessibilidade de forma abrangente.

2.2. WCAG-EM

A WCAG-EM [2, 3] é uma metodologia proposta pelo próprio W3C (World Wide Web Consortium) em 2014, visando promover um conjunto de boas práticas para avaliação. Apesar de ser um documento robusto e bem estruturado, seu status é de W3C Working Group Note: ele é uma referência estável de um documento que não deve ser um padrão formal [4].

Para aplicar a metodologia, a WCAG-EM recomenda que os especialistas tenham uma sólida compreensão de como avaliar o conteúdo da Web, design acessível, tecnologias assistivas e de como pessoas com diferentes deficiências a usam. Isso inclui uma compreensão das tecnologias da Web; barreiras de acessibilidade enfrentadas pelas pessoas com deficiência; tecnologias assistivas e abordagens adaptativas usadas por pessoas com deficiência; e técnicas de avaliação, ferramentas e métodos para identificar barreiras para pessoas com deficiência.

A metodologia WCAG-EM consiste em 5 etapas, com algumas podendo se sobrepor ou correr em paralelo:

1. Definir o escopo;
2. Explorar o sítio;
3. Selecionar uma amostra representativa de páginas;
4. Avaliar a amostra selecionada;
5. Registrar os resultados da avaliação.

2.2.1. Definir o escopo

A metodologia sempre é aplicada a um sítio/aplicativo completo, ou seja, não podem ser excluídas páginas que sirvam à finalidade principal. Você precisará mapear e priorizar cada um de seus canais digitais em sua política de acessibilidade (Fascículo V). Há todo um ecossistema digital construído no entorno do sítio/aplicativo, como contas de redes sociais e canais de atendimento, que também deve ser considerado.

Estabeleça um ponto de partida. Não é recomendável sair testando todo o sítio/aplicativo. Em vez disso, adote algumas estratégias que facilitem o relato e a correção dos problemas encontrados: seções mais utilizadas, conteúdos mais populares, caminhos críticos para quem navega.

Para evitar divergências posteriores entre avaliadores, gestores, usuários e leitores do relatório de avaliação resultante, é importante definir o escopo do que será avaliado e documentar quaisquer aspectos particulares do sítio para apoiar sua identificação. Isso inclui:

• uso de conteúdo e serviços terceirizados;
• versões para dispositivos móveis e de outros idiomas do sítio;
• partes do sítio, especialmente aquelas que podem não ser facilmente identificáveis como tal, por exemplo uma loja online com um endereço web diferente, mas ainda considerada parte do sítio de destino.

Nessa fase, define-se também:

• o nível de adequação aos critérios (A, AA, AAA) que será avaliado;
• a lista de navegadores da Web, TA, leitores de tela utilizados nos testes;
• requisitos de avaliação adicionais acordados entre o avaliador e o cliente, por exemplo: o nível de detalhe do relatório final, casos de uso especial, participação de pessoas com deficiência.

2.2.2. Explorar o sítio e selecionar uma amostra representativa de páginas

O segundo passo é explorar o sítio para selecionar a amostra. Embora o ideal seja uma avaliação completa, em muitos casos o volume de páginas impossibilita a avaliação manual de todas. Além disso, muitas guardam semelhança entre si, como as de notícias em um jornal, não necessitando que se avalie cada uma das notícias publicadas.

Após a exploração, define-se uma amostra de páginas que represente a acessibilidade de todo o sítio com confiabilidade. O tamanho da amostra dependerá de diferentes fatores, como a arquitetura do sítio, o número de modelos (templates) utilizados, a quantidade de serviços, os formulários disponibilizados etc. Uma amostra deve conter:

• a página inicial e as páginas relevantes para quem navega. É importante que se tenha atenção a páginas cujos erros de acessibilidade sejam mais críticos, como os formulários de contato;
• modelos/templates: avaliar, e futuramente corrigir, as falhas nos templates do Content Management System (CMS) e do Design System podem eliminar muitos erros que ocorrem em cascata;
• elementos interativos: formulários de contato, carrinhos de compra e tocadores de vídeos e som devem estar nas prioridades de validação;
• funcionalidade de terceiros: no caso de softwares livres, é importante a participação na comunidade para demandar mais acessibilidade e até ficar em dia com as atualizações. Sempre dê preferência a parcerias que forneçam software e serviços acessíveis;
• conteúdo multimídia e documentos: o fluxo de acesso a conteúdos, como vídeos e documentos, difere do fluxo de desenvolvimento de sítios, pois envolve especialidades diferentes, como audiodescrição e linguagem acessível.

2.2.3. Registrar os resultados da avaliação

A documentação dos resultados de cada uma das etapas anteriores é essencial para garantir a transparência do processo de avaliação, a replicabilidade dos resultados da avaliação e a justificativa para qualquer declaração feita com base nessa avaliação. Essa documentação não precisa ser pública e inclui, pelo menos, alguns itens:

1. Sobre a Avaliação
   • Nome(s) de quem avalia
   • Empresa/departamento/responsável
   • Data da avaliação (data de conclusão e/ou período de duração);
2. Escopo da avaliação;
3. Tecnologias utilizadas;
4. Amostra utilizada;
5. Resultado da avaliação.

Embora as avaliações façam parte do desenvolvimento e sejam atividades internas, recomenda-se salvar todos os detalhes da avaliação, pois pode ser muito útil em caso de conflito entre os resultados encontrados: ferramentas utilizadas, capturas de tela, dados introduzidos nas páginas para replicar os resultados.

Os resultados das rotinas de validação devem estar em um fluxo de resolução de problemas e monitoramento. Muitas vezes, apenas corrigir o erro não é o suficiente. Se, por exemplo, uma etapa da validação mostrar diversas vezes que um dos erros recorrentes é a falta de texto alternativo das imagens no conteúdo, é recomendável verificar com a equipe responsável o motivo desse erro recorrente. Se acontece porque o CMS não permite a inserção do texto alternativo, o problema deve ser resolvido pela equipe de desenvolvimento; caso ocorra por falta de conscientização da equipe de conteúdo, talvez seja necessário um treinamento reforçando a importância da acessibilidade.

Como mencionado no Fascículo V, é importante ter sempre registros em relatórios. Existem diversos modelos de Relatórios de Conformidade de Acessibilidade [5, 6, 7, 8], documentos que resumem formalmente até que ponto um produto ou serviço de tecnologia da informação e comunicação (TIC) está em conformidade com um conjunto acordado de diretrizes e padrões internacionais de acessibilidade. Por fim, a validação deve constar na Declaração de Acessibilidade do sítio/aplicativo, detalhada no Fascículo V, Capítulo 5.

Exemplo de Declaração de Conformidade do sítio completo:

Exemplo de declaração de conformidade com uma auditoria baseada na seleção de amostra de páginas:

2.3. Orçamento e pessoal

Além da WCAG-EM é importante lembrar de outros fatores, como prever um orçamento para revisões manuais de código, testes automatizados e testes de usabilidade. Certifique-se de que há pessoas aptas em sua equipe ou se precisará contratar externamente testadores que representem diferentes habilidades, incluindo pessoas com deficiência. Testar com pessoas com deficiência humaniza o problema para sua equipe e fornece documentação convincente para defender-se de reclamações.

É importante lembrar que, antes de contratar/adotar uma ferramenta de autoria (editor de texto [9], CMS, entre outros) ou framework, devem ser observados os seguintes pontos:

1. Se existe comprometimento com a acessibilidade por parte da proprietária ou da comunidade que mantém a ferramenta ou framework;
2. Se a ferramenta fornece as funções necessárias para criar ou editar conteúdo acessível no formato final;
3. Se qualquer informação de acessibilidade suportada é transportada para o formato final quando o conteúdo é convertido para outro formato;
4. Se o conteúdo de um arquivo continua acessível ao ser exportado, em qualquer formato;
5. Se a ferramenta fornece avisos para itens inacessíveis no conteúdo antes de sua publicação, permitindo sua correção e garantindo sua acessibilidade;
6. Se os modelos disponibilizados pelas ferramentas atendem aos critérios de acessibilidade;
7. Se o framework escolhido tem problemas de acessibilidade, a fim de verificar a possibilidade de resolução desses problemas.

No caso de ferramentas ou frameworks adotados, é importante participar das comunidades que os mantêm e acompanhar as atualizações. Quando possível, pressione pela contínua melhoria da acessibilidade.

2.3.1. Quanto custa a acessibilidade

Há poucos dados públicos de quanto custa a implementação da acessibilidade. Em 2013, a IBM apresentou um Modelo de Custo Conformidade para Acessibilidade baseado nas diretrizes internacionais de acessibilidade, as WCAG 2.0 [10], para estimar os custos de correção de problemas com a acessibilidade em sítios. Para testar o modelo, foi selecionada uma amostra de 10 (dez) sítios canadenses. O projeto teve duração de 7 semanas e seguiu as seguintes etapas:

1. Identificar sítios candidatos e páginas de amostra;
2. Avaliar (testar) páginas de amostra quanto à acessibilidade;
3. Estimar o custo para testar, reparar e manter;
4. Aplicar experiências de projeto a sítios e políticas.

Os sítios foram divididos conforme o tamanho da empresa/organização: pequena, média e grande, e sua complexidade: estáticos, dinâmico e comércio eletrônico. Os valores estimados pela IBM para os custos de correção dos principais problemas encontrados em cada sítio estão na Tabela 1. Os intervalos refletem a variabilidade no design, as opções de tecnologia e a acessibilidade aplicável.

Segundo o modelo, alguns custos de correção excedem rapidamente os custos de redesenho do sítio. A partir do modelo da IBM, a Usablenet criou uma “Calculadora de correção de acessibilidade” [11]. Nesse sentido, o estudo concluiu que:

• a implementação da acessibilidade é mais barata quando o sítio é construído acessível desde o início;
• a acessibilidade custa menos do que não desenvolvê-la. [12]

Segundo o estudo, os itens com mais impactos no custo de manutenção são:

• a estrutura da página;
• a navegação;
• os problemas no design de páginas e modelos;
• a dependência de componentes não acessíveis;
• os repositórios de documentos;
• o uso independente de dispositivo (teclado);
• as imagens com necessidade de descrições longas.

2.4. Desafios e mitos em validar a acessibilidade digital

Embora qualquer empresa possa criar um programa de teste de acessibilidade bem-sucedido, existem desafios [13] – sem mencionar mitos e equívocos – que podem surgir em torno do teste. Seguem algumas questões bastante comuns:

1. Não temos controle total sobre a funcionalidade de nosso sítio porque contamos com ferramentas terceirizadas.
   Muitas organizações alcançam a funcionalidade usando uma variedade de soluções pré-prontas, como sistemas de compras, CMS, formulários, tocadores de vídeo, sistema de assinatura de documentos. É importante que a acessibilidade seja um requisito na escolha dessas soluções. Devido à pressão do ativismo e da existência de leis, com punições em diversos países, é cada vez mais raro não encontrar pelo menos uma solução acessível. Também é importante o domínio e o conhecimento dessas soluções: ainda que um CMS possa estar adequado, a implementação descuidada de templates e a arquitetura da informação sem usabilidade podem prejudicar a acessibilidade.
2. Nossa empresa tem lacunas de conhecimento significativas.
   No Fascículo V, vimos que a acessibilidade só se mantém com pessoas treinadas e conscientizadas acerca do tema. Logo, é necessário que essas lacunas sejam resolvidas, pois é um processo demorado e dependente de recursos. No entanto, é possível trabalhar com especialistas externos, o qual, idealmente, deve ser realizado em conjunto a fim de construir as bases para o desenvolvimento da acessibilidade em sua empresa.
3. Não há testadores suficientes.
   Como apontado em usabilidade, “testar com uma pessoa usuária é melhor que testar com nenhuma” [14]. É preferível realizar os testes com poucas pessoas, com uma contratação externa, do que não realizar, pois um teste bem planejado pode fornecer resultados valiosos, deixando claro seus possíveis vieses.
4. O teste automatizado é bom o suficiente.
   Nenhuma ferramenta sozinha pode determinar se um sítio atende aos padrões de acessibilidade. A avaliação humana experiente é necessária para determinar e ter a dimensão dos problemas de acessibilidade de um sítio ou aplicativo. As ferramentas automatizadas não possuem discernimento, por exemplo, se um texto alternativo foi preenchido adequadamente, se os têm textos relevantes ou se a árvore de cabeçalhos reflete a estrutura da página. Além disso, testes automatizados também podem fornecer falsos alertas. Por fim, todo relatório gerado por esse tipo de teste deve passar por interpretação humana, assim como a verificação dos avisos, itens em que o programa não sabe informar se é um erro ou não.
5. Nem todo mundo concorda com os testes de acessibilidade.
   A consciência da necessidade de acessibilidade tende a aumentar à medida que sua implementação gera resultados tangíveis. Por isso, é importante mapear a situação atual e usar métricas consistentes.
6. É muito caro.
   A acessibilidade exige recursos, mas também oferece retorno [15]. Os benefícios de deixar acessíveis aplicativos e sítios podem ser mais amplos do que a defesa contra riscos de ações judiciais. Sempre é bom lembrar que a acessibilidade:
   • amplia o público de seu negócio;
   • aprimora a usabilidade e aumenta o ranking nos motores de busca (Search Engine Optimization – SEO);
   • melhora a imagem da empresa como uma organização consciente e socialmente progressista na vanguarda de um modelo de negócios mais inclusivo.

3. Tipos de validação

A validação da acessibilidade deve ser incorporada em todas as etapas do desenvolvimento. Além da validação automática e da avaliação humana, abordadas no Fascículo IV, a revisão manual do código e a revisão da experiência da pessoa usuária também permitem detectar problemas na acessibilidade [13, 16].

Um plano de avaliação de acessibilidade deve incluir, em cada etapa do desenvolvimento, pelo menos um desses tipos de validação:

1. Validação automatizada
2. Revisão manual do código
3. Testes de experiência de navegação (UX)
4. Avaliação Humana - equipe técnica
5. Avaliação Humana - pessoas usuárias

O ideal é aplicar as validações nessa ordem, que coincide com o custo médio de cada tipo, porque permite descobrir problemas com antecedência e com o menor custo possível.

A validação automatizada identifica erros com intervenção mínima; existem ferramentas gratuitas que permitem avaliações rápidas e fáceis, podendo ser realizadas a qualquer momento. Com o feedback inicial dos erros mais evidentes, você achará mais fácil obter a adesão da alta administração, ao trazer os imperativos sociais, legais e comerciais para a mesa.

Embora essa primeira etapa esclareça seu nível atual de conformidade, você não pode confiar apenas em ferramentas automatizadas, pois elas apenas detectarão problemas simples e omitirão os mais complexos, que exigem análise humana. A revisão manual do código pode ser feita em conjunto com a resolução dos problemas apontados pelas ferramentas automatizadas, detectando falsos negativos, problemas de semântica e de estrutura no código.

É recomendável que a avaliação humana por pessoas com deficiência seja realizada pelo menos após as validações automatizadas e as realizadas pela equipe técnica, para reduzir a frustração de quem navega, com problemas óbvios e de fácil diagnóstico e solução. Pense bem: você normalmente apresenta a seu cliente um protótipo de produto ainda cheio de erros que você deixou para resolver depois ou quando ele já está minimamente viável para a etapa de desenvolvimento?

Outro ponto é que o escopo das validações vai mudar conforme o tipo de validação. Testes automatizados podem ser aplicados em todo o sítio, dependendo da ferramenta. Aconselha-se testar os modelos de página do CMS primeiro, para evitar avisos de erros que se repetem em diversas páginas após alimentar o conteúdo.

Já no caso de testes com pessoas usuárias, o ideal é seguir um roteiro de uso do sítio/aplicativo que passe por uma amostra de páginas, como:

• página principal;
• mapa do sítio;
• sistema de busca;
• formulário de contato;
• páginas com diagramas, gráficos ou mapas de imagens;
• páginas com dados tabulares;
• páginas com dados gerados dinamicamente;
• conteúdo multimídia;
• caminho para obtenção de um serviço.

Em 2019, o W3C lançou como recomendação o documento “Formato de Regras de Teste de Conformidade de Acessibilidade (ACT) 1.0”, que define regras para teste de acessibilidade, as quais podem ser usadas para desenvolver ferramentas de teste automatizadas e metodologias de teste manual. O documento fornece um formato comum que permite a qualquer parte envolvida em testes de acessibilidade registrar e compartilhar seus procedimentos de teste de maneira uniformizada [17].

O W3C também tem outro documento de trabalho, de 2020, chamado: “Desafios com a conformidade e teste das diretrizes de acessibilidade e abordagens para mitigá-los” [18], que explora alguns cenários complexos de validação de acessibilidade, elencando alguns desafios, como lidar com conteúdos de terceiros que podem não estar em conformidade com as orientações de acessibilidade.

3.1. Validação automatizada

A validação automatizada é o ponto de partida de toda análise de acessibilidade e identifica problemas que podem ser parametrizáveis, revelando uma grande quantidade de barreiras [19]. No entanto, pode deixar passar erros graves de acessibilidade e apresentar falsos problemas, dependendo da interpretação da ferramenta [20]. Hoje, existem desde ferramentas gratuitas que avaliam uma página por vez, até ferramentas robustas, geralmente pagas, que avaliam sítios inteiros e áreas sensíveis à segurança, como carrinhos de compras e pagamentos .

A validação automatizada deve seguir a seguinte ordem:

1. 1. Validação automática do HTML e do CSS;
2. Validação da acessibilidade.

Se você testar em duas ferramentas diferentes, é bem possível que obtenha dois resultados distintos. Embora muitos erros possam ser os mesmos, os pesos dados e a forma de análise variam de ferramenta para ferramenta. O ideal é testar com pelo menos duas ferramentas automatizadas, tendo ciência de que elas conseguem verificar apenas cerca de 30% dos erros de acessibilidade, podendo chegar a 57% [22, 23, 24, 25].

3.2. Revisão manual do código

Esse tipo de teste envolve profissionais com conhecimento e experiência na revisão técnica das diretrizes do Modelo de Acessibilidade em Governo Eletrônico (eMAG) e da WCAG, que podem inspecionar HTML, CSS e Javascript para garantir que estejam em conformidade com as recomendações.

A leitura manual do código permite compreender erros apontados na validação automática, detectar falsos negativos e verificar a concordância da semântica e da estrutura do código. Essa revisão manual deve seguir um roteiro mínimo (checklist) que permita o acompanhamento da solução dos erros encontrados e a aferição dos resultados de forma tangível. Alguns itens a serem verificados são:

• código semântico: os elementos são utilizados de acordo com sua finalidade;
• equivalentes textuais: descrições para todas as informações visuais que transmitem conteúdo e se essas descrições são adequadas;
• alternativas para conteúdo multimídia: para o acesso da pessoa com deficiência ao conteúdo disponível em áudio e vídeo, como transcrições textuais, legendas, audiodescrição e tradução em Língua Brasileira de Sinais (Libras);
• emprego das cores: se a cor é utilizada de forma inadequada, como único recurso para transmitir informação, se a relação de contraste é adequada, se existe a opção de alto contraste, dentre outros;
• tabelas: uso adequado, se a marcação é semântica e se os cabeçalhos estão associados às células de dados, dentre outros;
• documentos para download: se estão em formatos acessíveis;
• formulários: se os campos estão associados às etiquetas, se há a identificação correta de campos de preenchimento obrigatório, se a navegação pelo teclado ocorre de maneira lógica, dentre outros. [26]

3.3. Testes de experiência da pessoa usuária (UX)

Durante muito tempo, a acessibilidade, a usabilidade e, por consequência, a experiência de quem navega (UX) foram tratadas como campos distintos, admitindo a existências de pontos em comum, mas nunca endereçando os problemas de uma área para a outra, possivelmente porque, no início, os problemas encontrados nos códigos eram mais impactantes para a acessibilidade, enquanto, para a usabilidade, compreender o modelo mental da pessoa usuária era o mais importante. À medida que as duas áreas amadureciam, seus pontos em comum se tornaram visíveis, assim como a necessidade de discutir sobre eles [27].

Podendo ser realizados antes da escrita do código, os testes UX são úteis também na avaliação da acessibilidade, permitindo a tomada de medidas preventivas. Consiste em revisar a experiência de navegação, verificando, por exemplo, se as informações são claras, se o tamanho de elementos (texto, área de clique, carga de informação) é suficiente, se a estrutura de cabeçalhos reflete a estrutura de informação da página, dentre outros.

Assim como a revisão manual do código, essa etapa deve também seguir um roteiro.

Se os métodos de pesquisa UX não considerarem as necessidades de diversos participantes, perde-se consistentemente o alvo quando se trata de criar produtos inclusivos [28]. Por exemplo, o método de pensamento em voz alta (think-aloud), no qual os participantes verbalizam seus pensamentos enquanto usam um produto, pode ser confuso para participantes com deficiência visual que dependam de leitores de telas. Enquanto ouve o leitor de tela, eles também são convidados a falar; logo, ou eles falam junto com os leitores de telas, o que pode ser particularmente desafiador para quem faz pesquisa, ou navegam de maneira incomum, por meio de pausas para explicar o que estão fazendo. Para outras pessoas que usam uma forma de navegação alternativa, navegação por voz, por exemplo, a tecnologia assistiva pode ouvir comandos e fala sobreposta, tanto da pessoa usuária quanto de quem pesquisa.

É importante adaptar os métodos de engajamento para maior inclusão da ampla gama de testadores. Outra questão é o uso de laboratórios de usabilidade. Embora o ambiente controlado seja conveniente para quem faz pesquisa, para pessoas com deficiência é muitas vezes um desafio. Dado que a tecnologia assistiva é quase sempre personalizada, observar participantes com deficiência em um laboratório de usabilidade com equipamentos desconhecidos, sem considerar o tempo e as condições da pessoa para deslocamento, pode resultar na observação de comportamentos não naturais.

3.4. Avaliação Humana

Como descrito no Capítulo 5.3 no Fascículo IV, a avaliação deve ser realizada em duas fases: primeiro pela equipe técnica e, depois, por pessoas usuárias. A avaliação eficaz da acessibilidade na Web requer mais do que simplesmente executar uma ferramenta de avaliação automática em um sítio da Web. Nesse sentido, a avaliação humana pode ser auxiliada por roteiros e ferramentas automatizadas:

• Diretrizes: diferentes organizações e governos podem exigir conformidade com diferentes padrões de acessibilidade; portanto, diferentes ferramentas oferecem suporte a esses padrões;
• Avaliações passo a passo: as ferramentas de avaliação baseadas em assistente guiam as pessoas usuárias por meio de sequências de verificações. Elas realizam verificações automatizadas e solicitam que a pessoa usuária avalie manualmente o restante. Por exemplo, uma ferramenta baseada em assistente pode verificar as imagens em busca de texto alternativo. A pessoa usuária, então, avalia a adequação do texto alternativo.
• Feedback na página: esse recurso insere ícones e marcações temporárias para exibir os resultados das verificações de acessibilidade. Eles são úteis para visualizar problemas no contexto e entender a importância relativa de cada questão.
• Simuladores: as ferramentas de simulação alteram a aparência de um sítio para ajudar a identificar problemas de design. Por exemplo, a ferramenta pode mostrar o sítio apenas em texto ou sem cor. Essas ferramentas são úteis para compensar as limitações dos testes automatizados.
• Checklists: listas com diversos itens de verificação. Há diversos roteiros, como o “Checklist de acessibilidade manual para pessoas com deficiências visuais [29]” disponível no sítio do Governo Digital.[30]
• Avaliações abrangentes e eficazes requerem avaliadores com compreensão das tecnologias da Web, ferramentas de avaliação, barreiras que as pessoas com deficiência enfrentam, tecnologias assistivas e abordagens usadas pelas pessoas com deficiência, bem como diretrizes e técnicas de acessibilidade.

3.4.1. Avaliação com equipe técnica

No Fascículo IV, é explicada brevemente a avaliação de acessibilidade pela equipe técnica, a qual é importante ressaltar, também pode ser formada por pessoas com deficiência. Quando indicamos testes com pessoas usuárias com deficiência, lembramos que, como todas as pessoas, elas têm níveis diferentes de experiência diferentes: uma pessoa da equipe, com deficiência ou não, tem vieses ao participar do projeto. Para que a equipe tenha capacidade de avaliar a acessibilidade, é necessário que ela tenha um certo nível de conhecimento na área, como:

• tecnologias da Web;
• ferramentas de validação para tecnologias da Web;
• diretrizes e técnicas de acessibilidade de conteúdo da Web;
• abordagens para avaliar a acessibilidade na Web;
• uso de uma variedade de ferramentas de avaliação para acessibilidade do sítio;
• barreiras de deficiência, tecnologias assistivas e estratégias adaptativas;
• envolvimento com pessoas com deficiência na avaliação.

Embora seja possível que os indivíduos avaliem a acessibilidade da Web de forma eficaz, se tiverem treinamento e experiência em uma ampla gama de disciplinas, é menos provável que uma pessoa tenha todo o conhecimento que uma abordagem colaborativa pode trazer [31].

Quando a equipe não tem esse conhecimento ou sente necessidade de informações para além do saber, muitas vezes são contratadas consultorias externas, com especialistas em acessibilidade. Além do uso de checklists em acessibilidade, a equipe e os especialistas também podem utilizar avaliações heurísticas, que muitas vezes revelam problemas não necessariamente apontados nas diretrizes WCAG. Existem heurísticas criadas especificamente para avaliação de acessibilidade e inclusão [32, 33].

3.4.2. Avaliação com pessoas usuárias

Pessoas com deficiência são tão diversas quanto qualquer pessoa; além disso, a maioria dos projetos não tem tempo e/ou orçamento para inclusão de muitos participantes diferentes em seus testes. Selecionar o número ideal de pessoas usuárias com as características mais adequadas pode ser difícil. Na maioria dos casos, incluir participantes na avaliação envolve [34, 35]:

• selecionar pessoas com deficiência e, dependendo de seu público-alvo, pessoas mais velhas;
• realizar tarefas durante o desenvolvimento para verificar como os diferentes aspectos de design e codificação podem ser melhorados;
• discutir questões de acessibilidade com quem navega.

Pessoas com deficiência e pessoas mais velhas podem ser incluídas em uma ampla gama de atividades de avaliação, desde consultas breves até estudos de usabilidade em larga escala. Existem muitas opções entre esses extremos:

• Avaliações informais de questões específicas de acessibilidade podem ser muito simples. Por exemplo, peça a alguém que usa um leitor de tela ou com outras deficiências para encontrar dados em um rascunho inicial de uma tabela. Observe sua interação e discuta os problemas.
• O teste formal de usabilidade de um sítio segue protocolos estabelecidos para coletar dados quantitativos e qualitativos de pessoas usuárias representativas que executam tarefas específicas. Testes formais podem ser otimizados para focar em questões de acessibilidade.

A realização de avaliações informais ao longo do desenvolvimento, especialmente se realizada por pessoas técnicas e especialistas em acessibilidade, é mais eficaz do que apenas testes formais de usabilidade no final de um projeto. No entanto, lembre-se de não assumir que a opinião de uma específica pessoa com deficiência se aplica a todas as pessoas com deficiência. Tenha cuidado ao tirar conclusões de avaliações ou estudos limitados. Os resultados de apenas algumas pessoas com deficiência não podem ser generalizados para se aplicar a todas as pessoas com deficiências semelhantes ou com outras limitações. Há recomendações para trabalhar com pessoas, informal ou formalmente:

• Desenvolva relacionamentos apropriados com essas pessoas. Por exemplo, passar um tempo conversando informalmente durante o almoço pode ajudá-las a trabalhar com mais conforto.
• Garanta o consentimento informado e outras éticas de pesquisa. Por exemplo, diga a elas que podem parar a qualquer momento.
• Trate participantes com deficiência e as pessoas mais velhas com o mesmo respeito que trataria qualquer outro indivíduo. Por exemplo, respeite seu tempo e forneça uma compensação adequada. Não seja capacitista!

Algumas pesquisas mostram que cinco participantes são suficientes para encontrar 85% dos problemas de usabilidade [13] quando há pessoas usuárias comparáveis que usarão o produto de maneiras bastante semelhantes. Quando você tem vários grupos altamente distintos, é necessário incrementar o número de testantes.

O teste de usabilidade completo para acessibilidade requer mais de cinco testantes, pois as pessoas com deficiência usam os produtos de maneira diferente. Quando você tiver diferentes categorias de pessoas, o ideal é incluir três usuários de cada uma. No entanto, as pessoas com deficiência não se enquadram facilmente nas categorias em termos de interação com o produto; assim, a recomendação é fazer a classificação delas a partir do tipo de tecnologia assistiva utilizada.

Ao decidir o número de participantes com deficiências, considere também questões gerais de usabilidade que afetam todas as pessoas usuárias. Portanto, o teste de usabilidade com participantes com deficiência identificará problemas de acessibilidade e problemas gerais de usabilidade. Em muitos casos, os problemas gerais de usabilidade são amplificados ao testar com participantes com deficiências, evidenciando dificuldades que afetam todos os usuários.

Inclua nos relatórios o escopo do estudo e os parâmetros de avaliação, como métodos de teste e características da pessoa usuária. Por exemplo, se um estudo incluiu apenas participantes com deficiências visuais, o relatório deve esclarecer que não avaliou a conformidade com os padrões de acessibilidade, por isso não se aplica a todas as pessoas com deficiência. Embora pequenos estudos geralmente forneçam informações úteis, eles não são robustos o suficiente para fornecer significância estatística.

Assim, como em qualquer avaliação de pessoas usuárias, a necessidade de incluir equipes novatas, médias ou avançadas depende de seu público-alvo. Por exemplo, se você estiver desenvolvendo um aplicativo da Web para contadores em uma empresa, provavelmente desejará equipes avançadas de tecnologia assistiva. Por outro lado, para um sítio público em que é possível solicitar benefícios, você deseja equipes novatas de tecnologia assistiva.

3.4.3. Recrutando pessoas com deficiência

Como qualquer outro teste com usuários, é necessário planejar o recrutamento das pessoas com deficiência. Como qualquer recrutamento, quanto mais específicos forem os requisitos do participante, mais tempo levará para recrutar. Adicionar requisitos específicos do participante, como tipo de deficiência e uso de tecnologia assistiva, provavelmente aumentará o tempo e o esforço de recrutamento.

Em contrapartida, seu recrutamento pode levar menos tempo do que o normal devido ao "marketing viral" nas comunidades de pessoas com deficiência.

• Busque os contatos importantes: lugares para procurar participantes com deficiência incluem grupos de mídia social, organizações para deficiências ou condições específicas, listas de discussão, programas de faculdades e universidades para estudantes com deficiência, entre outros.
• Considere os testes-piloto como uma ferramenta de recrutamento. Algumas pessoas com deficiência fazem parte de redes que compartilham ativamente informações sobre acessibilidade. A notícia de uma experiência positiva de teste de usabilidade pode se espalhar rapidamente e resultar em participantes em potencial entrando em contato com você.
• Adicione informações relevantes ao recrutamento: ao selecionar participantes com deficiências para um teste de usabilidade, use os mesmos parâmetros que usaria para participantes sem deficiências. As informações adicionais a serem cobertas na tela de recrutamento incluem uso de tecnologia, formatos alternativos para materiais impressos etc.
• Providencie intérpretes conforme necessário. Se você estiver conduzindo estudos de usabilidade com participantes com deficiência auditiva, é comum que você encontre, agende e pague por intérpretes de língua de sinais. Isso geralmente não ocorre quando uma pessoa com deficiência física fornece assistência pessoal, pois ela própria pode fazer os arranjos;
• Planeje reembolsar quem participar dos estudos pelas despesas necessárias. Embora a compensação básica para pessoas com deficiência seja a mesma de qualquer participante de seu teste, pode haver algumas considerações de custo adicionais, como o transporte, que pode ser mais complicado e caro para participantes com deficiência. Normalmente, você deve reembolsar despesas adicionais de transporte, como um táxi acessível.

Como qualquer teste de usabilidade, há vantagens e desvantagens de conduzir as sessões em um laboratório de usabilidade ou "no campo". Algumas pessoas usam avaliação remota com facilitadores e participantes em locais diferentes. Ao realizar testes de usabilidade com pessoas com deficiência, há fatores adicionais a serem considerados ao tomar a decisão de localização. Geralmente, pessoas com deficiência personalizam a tecnologia assistiva que utilizam, sendo difícil reproduzir com fidelidade em um laboratório. Assim, em muitos casos, o ideal é testar em campo, podendo ser a casa ou o local de trabalho da pessoa, com a devida autorização.

3.4.4. Uso de Tecnologia Assistiva para validação

No Capítulo 3 do Fascículo III, tratamos da acessibilidade à Web por pessoas com deficiência, utilizando Tecnologia Assistiva para acessar sítios e aplicativos. Uma dessas tecnologias é o leitor de tela [36, 37].

Para quem enxerga, ouvir o conteúdo de uma página web, em vez de olhar para ele, pode ser uma experiência "reveladora" que tira a pessoa de sua zona de conforto. Erros de digitação e pontuação tornam-se muito óbvios quando você ouve palavras e frases pronunciadas incorretamente. Além disso, os leitores de tela são muito bons para verificar a precisão e a qualidade do texto alternativo das imagens, identificar problemas com a ordem de leitura, marcação de tabela, elementos de formulário e muitos outros aspectos de acessibilidade.

O ideal é que essa validação seja realizada por pessoas que dominam o uso do leitor de tela, utilizando um roteiro pré-determinado. Essa habilidade tem uma curva de aprendizado que não é facilmente transposta por alguém acostumado a usar a visão para aprender, visto que a forma de navegação é diferente. O leitor de tela segue o fluxo linear do código HTML, ao passo que usuários com visão, por sua vez, costumam explorar visualmente as regiões de uma página.

Tudo isso ressalta a importância de haver pessoas com deficiência compondo a equipe técnica. Há uma diversidade de tecnologias assistivas e uma curva de aprendizado para cada uma delas. Por exemplo, geralmente pessoas usuárias de leitores de tela usam o teclado para navegação, ainda que haja um grupo de pessoas, de baixa visão, que usa, além do leitor de tela, também o mouse [38].

Assim, o mínimo é que o teste com os leitores de tela seja realizado por pessoas cegas, que também tenham conhecimento em testes de acessibilidade, a fim de detectar erros que afetem pessoas com um menor domínio do leitor de tela.

Computadores de mesa e celulares têm tipos de leitores de tela diferentes [39]. Apesar de haver diferenças de como cada leitor interpreta o código HTML, não é necessário testar com todos os leitores disponíveis. Usar o leitor de tela mais utilizado, tanto em desktop quanto em dispositivos móveis, pode ser mais que suficiente, se o roteiro criado para o teste e o checklist dos problemas forem bem desenhados.

4. Definindo as métricas de acessibilidade

Definir as métricas de acessibilidade estabelece a base para uma cultura eficiente: elas fornecem as informações necessárias para administrar os problemas, priorizando de acordo com a conformidade e melhorando as habilidades de acessibilidade de suas equipes de desenvolvimento. Escolher a análise de acessibilidade digital é fundamental para o sucesso de seus esforços de teste de acessibilidade a longo prazo. Para tanto, as métricas precisam ser acionáveis e relevantes [40, 41, 42].

• Métricas acionáveis: dividem a acessibilidade em marcos alcançáveis e mensuráveis.
• Uma boa métrica: certifique-se de que seu código esteja limpo de todos os problemas detectados automaticamente pela ferramenta de teste definida pela empresa.
• Uma métrica ruim: procure 100% de conformidade de acessibilidade, cobrindo todos os critérios de sucesso das WCAG 2.1 desde o início.
• Métricas relevantes: relacionadas à responsabilidade da equipe: desenvolvimento, conteúdo, entre outras.
• Uma boa métrica: o tempo médio necessário para corrigir um defeito de acessibilidade a partir do momento em que foi reportado.
• Uma métrica ruim: medir a cobertura dos critérios de sucesso das WCAG.

Vamos detalhar uma coleção de métricas de acessibilidade apropriadas para gerenciamento de TI, função/equipes de acessibilidade central (se você tiver uma), gerenciamento sênior e pessoas em cargos executivos.

4.1. Função/Equipe de Acessibilidade Central

• Problemas de acessibilidade por gravidade: com esses dados, sua equipe central de acessibilidade pode avaliar o estado atual de seu risco e fornecer as próximas etapas estratégicas.
• Problemas de acessibilidade por categoria: ex. ARIA, contraste de cores, formas. Isso pode ajudar sua equipe a identificar oportunidades para melhorar as práticas de codificação e/ou design.
• Tendências de acessibilidade ao longo do tempo: as áreas problemáticas ou de alto risco estão melhorando? Piorando? Você está reduzindo o número de problemas em geral?
• Critérios de sucesso do WCAG aprovados durante os testes iniciais em todas as fases: ajudará a indicar quando sua equipe de desenvolvimento cria interfaces acessíveis por padrão e a entender como eles aplicam as práticas de acessibilidade.
• Taxas de conclusão de treinamento de acessibilidade: quem conclui seu treinamento? Quem luta para ter tempo para o treinamento? Onde estão as lacunas no treinamento ou nas aulas que precisam de atenção extra? Quando é necessário um novo treinamento devido a mudanças na tecnologia?

4.2. Propriedade do Produto/Gerenciamento de TI

• Problemas de acessibilidade distribuídos pelas equipes de desenvolvimento: veja quais equipes estão bem e quais podem precisar de ajuda extra.
• Trabalho de Acessibilidade Restante: Por exemplo, o número de problemas que esperam para serem corrigidos. Se você estiver abordando determinados grupos de problemas de acessibilidade por sprint, o trabalho restante deve medir os grupos-alvo de problemas de acessibilidade.
• Número diário líquido de defeitos de acessibilidade: quantos novos problemas são introduzidos a cada dia? O ideal é que esse número diminua.
• Defeitos de acessibilidade por prioridade: ajude sua equipe a se concentrar nos problemas de prioridade máxima.
• Tempo de resposta de correção. Esses números podem ajudar a chamar a atenção para a quantidade de atenção recebida pelos problemas de acessibilidade e a seriedade desenvolvida.
• Tempo médio entre falhas (TMEF): com que frequência defeitos graves chegam à produção.
• Tempo médio de reparo (TMR): quanto tempo leva para corrigir defeitos graves na produção.

4.3. Resultados que sua organização deve observar à medida que a acessibilidade melhora

À medida que suas equipes de desenvolvimento começam a melhorar e corrigir defeitos de acessibilidade e sua equipe central de acessibilidade mede o risco e melhora o treinamento, a acessibilidade em sua organização deve começar a produzir os seguintes resultados:

• custos de integração de acessibilidade digital reduzidos e contidos;
• investimento ano a ano para acessibilidade tender a cair;
• diminuição do tempo para a remediação da acessibilidade;
• diminuição da dependência de consultoria externa e terceirização;
• economia de tempo e recursos no desenvolvimento de front-end.

Todos esses resultados, medidos com as métricas, ilustram como as práticas de acessibilidade de sua organização se tornam cada vez mais eficientes e sustentáveis. Quanto mais você investir em acessibilidade como um programa e uma mudança de cultura, mais sua organização economizará em acessibilidade no futuro.

5. Rotinas de validação

Embora haja diversas metodologias para o desenvolvimento de sítios/aplicativos, todas têm pontos em comum que podem ser resumidos em: especificação, projeto, desenvolvimento, validação e evolução. Para que a validação da acessibilidade alcance os resultados desejados, é necessário que cada uma das áreas participantes do projeto seja formalmente responsabilizada pelos testes que lhe competem, em cada etapa.

A Tabela 2 mostra as técnicas de validação indicadas para cada área e etapa do desenvolvimento (uma indicação simplificada). Em projetos complexos, com diversas etapas e entregas, o ideal é que o conjunto de testes apresentado esteja presente em cada sprint de um método ágil de produção.

• UX : Experiência da Pessoa Usuária
• EqT: Equipe Técnica
• PCD: Pessoa com Deficiência

5.1. Rotina de validação Design

Nesta cartilha, o termo design abrange diversas áreas, cujas fronteiras nem sempre são claras, como o design gráfico, o design de interface, o design de interação, usabilidade e experiência da pessoa usuária. A rotina de validação em design deve ocorrer desde o início do desenvolvimento.

A acessibilidade começa pelo design. Apesar de boa parte da acessibilidade ser realizada a partir da escrita de um código HTML semântico e de um CSS responsivo, ela começa antes mesmo da primeira linha de código ser escrita, quando são realizados os protótipos em papel, wireframes e a identidade visual [16]. Certifique-se de que pessoas com deficiência e pessoas usuárias mais velhas sejam incluídas em casos de uso, análise, personas, cenários, fluxos de trabalho e orientações de design.

O cuidado com a acessibilidade deve começar desde a concepção de leiautes que usam a identidade visual desenvolvida, incluindo cores, ícones, famílias tipográficas etc. Alguns aplicativos e sítios têm um Design System, que já inclui a identidade visual e artefatos pré-programados, o que deve começar a ser testado ainda na fase de projeto.

Embora muitos programas de criação de protótipos e wireframes não estejam preparados para leitores de tela, é possível aplicar as seguintes validações:

• validação automatizada: realizar testes automáticos para verificação do contraste;
• testes de experiência da pessoa usuária (UX): utilizar pessoas com deficiência e cenários com contextos desfavoráveis para testes de UX;
• avaliação humana pela equipe técnica: utilizar checklists para verificar pontos da interface ainda na fase de wireframe e protótipo (há um modelo no Anexo 9.1);
• avaliação humana por usuários: testar os protótipos com pessoas com deficiência.

5.2. Rotina de validação Front-end

Muito da acessibilidade digital depende de um código semântico. Para isso, é necessário que os desenvolvedores Front-end conheçam em profundidade os padrões web, em toda sua potencialidade, o que inclui frameworks e componentes [43].

Antes de começar a codificação:

• avalie, com antecedência, a melhor forma de escrever o código a partir dos wireframes e protótipos fornecidos pela equipe de design;
• defina, ao longo do desenvolvimento, marcos para a validação humana.

Durante o desenvolvimento, realize as seguintes validações:

• Validação automatizada geral: verifique o código HTML e CSS automaticamente, pelo menos uma vez em cada dia de desenvolvimento. Isso evitará o acúmulo de problemas futuros, e boa parte dos problemas de acessibilidade poderão ser resolvidos rapidamente.
• Validação automatizada de acessibilidade: após o teste com validadores automáticos de HTML e CSS, faça o mesmo com validadores automáticos de acessibilidade.
• Revisão manual do código: mantenha um registro dos problemas de código que não foram resolvidos para debater com o grupo e buscar uma solução. No caso de metodologias ágeis, isso pode ser reportado na reunião diária.

Na etapa de avaliação:

• Avaliação humana pela equipe técnica: na etapa de testes de cada sprint, realize testes de acessibilidade usando checklists (há um modelo no Anexo 9.2).
• Avaliação humana por pessoas usuárias: durante cada etapa, realize pelo menos uma avaliação humana com usuários.

5.2.1. Revisão manual do código

A revisão manual do código, além de averiguar os erros apontados nas verificações automáticas, deve verificar:

• se os atributos de linguagem estão devidamente assinalados;
• se os elementos que estruturam o conteúdo (MAIN, NAV, ARTICLE, ASIDE) estão corretamente utilizados;
• se a ordem dos cabeçalhos (H1, H2, H3…) reflete a estrutura da página;
• se os menus são marcados como listas não numeradas;
• se existem elementos utilizados de forma semanticamente equivocada.

Outra forma de avaliação manual do código é retirar o CSS para verificar se o conteúdo da página continua íntegro e com sentido. Ao se retirar o CSS, os seguintes comportamentos devem ser observados:

• o conteúdo da página aparece alinhado à esquerda e apresenta-se de forma linear;
• a informação aparece numa ordem lógica;
• deve ser possível reconhecer a semântica dos diversos elementos;
• a informação relevante permanece visível.

5.3. Rotina de validação para formulários

Apesar de formulários serem estruturas importantes na interação com quem navega, costumam acumular um número muito grande de erros em acessibilidade. Eles são utilizados como meio de contato e para a realização de transações. Portanto, sua acessibilidade é imprescindível.

A validação dos formulários deve acontecer em conjunto com a rotina de validação do Front-end. No entanto, deve-se destacar a necessidade de um passo anterior, a validação do projeto do formulário, antes da codificação.

Ainda na etapa de design, deve-se testar o conteúdo semântico do formulário, podendo ser realizada uma avaliação heurística e testes (UX). Uma orientação geral é que, na concepção do formulário, você solicite apenas as informações necessárias para a conclusão do objetivo.

As demais etapas da verificação de formulários – validação automatizada, revisão manual do código e as avaliações humanas pela equipe técnica e com usuários – devem estar integradas às validações dos demais elementos do Front-End (há um modelo de checklist específico para formulários no Anexo 9.3). Para as avaliações humanas, devem ser preparados roteiros detalhados, abrangendo as diferentes dinâmicas de interação, inclusive com as mensagens de erro.

5.4. Rotina de validação para conteúdo

A escrita acessível do conteúdo depende das boas práticas da escrita UX (UX writing), SEO e da utilização de linguagem simples. Há checklists de acessibilidade que incluem aspectos do conteúdo, como o uso de links semânticos, com textos que dizem de forma clara e concisa o destino do hiperlink.

O conteúdo dos arquivos em formato .pdf e em quaisquer outros formatos, se houver, deve ser escrito e formatado seguindo as boas práticas de acessibilidade.

A validação de conteúdo deve ser realizada em conjunto com a validação em design, pois a estrutura visual e o conteúdo têm pontos em comum, por exemplo o desenvolvimento de infográficos e a formatação do texto.

Existem algumas formas de verificação de acessibilidade do conteúdo:

• Validação automatizada: ainda que não existam ferramentas em língua portuguesa que verifiquem se um texto está compreensível, alguns testes podem ser realizados de forma automatizada:
  • Ferramentas automatizadas de SEO podem auxiliar na verificação de acessibilidade do conteúdo;
  • Ferramentas automatizadas podem ser utilizadas para verificar a estrutura dos cabeçalhos e a existência de descrição de imagens;
  • Existem ferramentas indicadas para a validação de acessibilidade de arquivos de texto e apresentações.
• Avaliação Humana – equipe técnica: checklists de usabilidade podem ser utilizados ao longo de todo o desenvolvimento, desde a fase de wireframe e protótipo (Anexo 9.4);
• Testes de experiência da pessoa usuária (UX ) e a avaliação humana devem ser realizados em conjunto com as avaliações em design.

5.4.1. SEO e Acessibilidade

Técnicas de SEO referem-se a técnicas para aperfeiçoar o posicionamento orgânico dos sítios e páginas nos resultados dos buscadores. O SEO afeta apenas os resultados orgânicos da pesquisa, que geralmente vêm após os links pagos ou patrocinados [44] .

Em geral, as técnicas de SEO auxiliam a acessibilidade e vice-versa [45]. Quando um link tem um significado semântico, como “Promoções de material escolar”, ele tem um peso maior para os motores de busca do que um link “Clique aqui” (para as promoções de material escolar).

No entanto, existem técnicas de SEO do tipo black hat que podem prejudicar a acessibilidade. Por exemplo, uma das técnicas de black hat consiste em usar palavras-chave no texto alternativo das imagens, mesmo quando elas não tenham nenhuma ligação com o conteúdo da imagem, o que compromete a acessibilidade.

5.5. Rotina de validação para redes sociais

As redes sociais possuem por características o uso de hashtags (#) e emojis. Há boas práticas que devem ser seguidas, como evitar o uso de emojis repetidos ou no nome da conta, pois essas práticas tornam o conteúdo exaustivo para quem usa programas leitores de telas. Se a cor da pele não for relevante para postagens, aconselha-se o uso padrão do emoji amarelo.

O uso excessivo de hashtags também deve ser evitado. As hashtags devem ser relevantes ao conteúdo. No caso de sequência de hashtags, o aconselhável é usar, no máximo, cinco, as quais devem estar no final da postagem. No caso de uma hashtag formada por mais de uma palavra, é aconselhado o uso de CamelCase, em que as letras iniciais de cada palavra são maiúsculas.

Antes de qualquer validação é importante conhecer as ferramentas de acessibilidade da Rede Social e habilitá-las, se não estiverem disponíveis por padrão. A validação para redes sociais pode ser realizada seguindo o roteiro disponível no Capítulo 9, Anexo 9.5.

5.6. Rotina de validação para canais de atendimento

Os canais de atendimento são a forma de contato mais procurada quando as pessoas encontram problemas no sítio, sendo um dos caminhos críticos e, obrigatoriamente, uma das seções em que a acessibilidade precisa ser validada em sua totalidade. Nesse caso, algumas ações são necessárias:

• Validação automatizada e Revisão manual do código fazer de acordo com a rotina de Front-end para garantir que os formulários de atendimento estejam acessíveis;
• Testes de experiência da pessoa usuária (UX): realizar antes da codificação para verificar a clareza nos campos dos formulários, nos roteiros de chatbots e outros canais de atendimento. Podem ser utilizadas técnicas, como a “Mágico de Oz”, ainda na fase de protótipo;
• Avaliação Humana – Testes de usabilidade seguindo a jornada da pessoa com deficiência: veja o checklist no Anexo 9.6.
• Avaliação Humana – pessoas usuárias: semelhante ao teste de experiência do usuário, devem ser testados em toda sua completude para detectar erros críticos.

5.7. Rotina de validação para aplicação web (WebApp)

Um aplicativo web (WebApp) é um sítio com funcionalidade semelhante a um aplicativo de software de desktop ou a um aplicativo móvel [46, 47, 48].

Como qualquer página web, um WebApp deve passar pelas mesmas rotinas de validação de acessibilidade: deve respeitar o uso semântico da escrita de HTML, o contraste das combinações de cores do guia de estilo, dentre outros cuidados (há um checklist específico para WebApps no Anexo 9.7).

Além dos testes com ferramentas automatizadas que analisam o código HTML, o CSS e a acessibilidade, há ferramentas automatizadas próprias para avaliação de acessibilidade em scripts. A avaliação do código depende do framework utilizado. A página a11ycases WebApps [49] possui uma coleção de testes de acessibilidade para WebApps.

5.8. Rotina de validação de aplicativos móveis

O W3C não possui recomendações específicas para dispositivos móveis; entretanto, a acessibilidade móvel é contemplada na WCAG e em outras recomendações da WAI [48, 50, 51].

É preciso testar a acessibilidade dos aplicativos em vários dispositivos reais, além dos simuladores. Busque dados daqueles mais utilizados pela população ou por seu público-alvo.

A maior parte dos testes de acessibilidade em dispositivos móveis usará o software de leitor de tela embutido – TalkBack no Android e VoiceOver no iOS. É importante que, nesse caso, a equipe técnica também domine o uso desses leitores para teste, pois há boas práticas do uso de toques acessíveis que só podem ser verificadas dessa forma.

É muito importante testar a validação de entrada e os erros de formulário no aplicativo, bem como os caminhos esperados nas jornadas da pessoa usuária. Além disso, tente girar o telefone e alterar as configurações do sistema operacional no meio do caminho. Teste uma ampla variedade de configurações de recursos de acessibilidade para garantir que todo mundo que navega tenha a mesma experiência.

Antes da codificação:

• conheça e utilize as melhores práticas para desenvolvimento acessível indicadas pelas plataformas;
• identifique os dispositivos nos quais deseja realizar os testes;
• estude e selecione ferramentas para testes de acessibilidade durante o desenvolvimento [52, 53].

Na validação:

• Validação automatizada:
  • realize testes para problemas gerais de acessibilidade;
  • realize testes para problemas de acessibilidade específicos em dispositivos móveis;
  • revisão manual do código: mantenha um registro dos problemas de código não resolvidos para debater com seu grupo e buscar uma solução.
• Avaliação Humana – equipe técnica:
  • teste e aplique checklists (Anexo 9.8) em dispositivos móveis reais de diferentes tamanhos;
  • teste usando tecnologia assistiva móvel;
  • teste em janelas responsivas em um dispositivo desktop.
• Avaliação Humana – pessoas usuárias:
  • durante cada etapa, realize ao menos uma avaliação humana;
  • realize testes usando tecnologia assistiva móvel.

5.8.1. Especificidades da rotina de validação para aplicativos em iOS

O leitor de tela nativo do iOS é o VoiceOver. O XCode, a IDE da Apple para o desenvolvimento de aplicativos, tem um inspetor de acessibilidade nativo, o Inspetor de Acessibilidade, que ajuda a verificar o comportamento do aplicativo nas tecnologias assistivas do iOS [54, 55].

Durante o desenvolvimento, é importante seguir as boas práticas e as indicações de ferramentas de verificação de acessibilidade disponíveis no sítio de desenvolvedores da Apple e fazer combinações de uso, como no exemplo a seguir:

• Ative o inspetor de acessibilidade no XCode:
  • teste usando o leitor de tela VoiceOver;
  • teste com ferramentas de análise indicadas pela Comunidade IOS.

5.8.2. Especificidades da rotina de validação para aplicativos em Android

O Google possui um framework próprio de validação de acessibilidade. O leitor de tela nativo do Android é o Talkback; quando ativado pela primeira vez, começa por um tutorial, que fica depois acessível no menu de Configurações [56, 57].

Durante o desenvolvimento é importante seguir as boas práticas e as indicações de ferramentas disponíveis no sítios de desenvolvedores do Android [58, 59].

• Ative o teste de acessibilidade no Espresso e no Robolectric:
  • teste usando o leitor de tela TalkBack;
  • teste com ferramentas de análise indicadas pela Comunidade Android.

6. Incluindo a acessibilidade nos requisitos para homologação de produtos

A fase de homologação é uma das fases finais do desenvolvimento, quando se verifica se o produto atende os requisitos do negócio. Ou seja, é o momento em que a empresa e/ou a equipe entrega uma versão preliminar funcional do produto.

No caso da acessibilidade, nunca é demais dizer que ela não deve ficar apenas para o momento de homologação: ela deve ser um requisito inicial de qualquer produto, mesmo antes que qualquer linha de código seja escrita. Por outro lado, pouco adiantará incluir a acessibilidade na metodologia de desenvolvimento se ela estiver ausente ou for considerada secundária na fase de homologação. Se isso acontecer,, a acessibilidade não se sustentará ao longo das manutenções e, em pouco tempo, estará perdida, mesmo que tenha sido considerada durante o desenvolvimento.

A acessibilidade não é uma funcionalidade, algo opcional ou supérfluo a ser pensado ao final do desenvolvimento: ela é uma característica fundamental para o sucesso e a qualidade de qualquer produto. Quando não a consideramos, limitamos o alcance e impedimos que todas as pessoas usem nossos sítios, serviços e aplicativos.

A fase de homologação só deve começar depois que todos os outros testes forem executados e os erros encontrados forem corrigidos ou aceitos. O processo de homologação varia de acordo com a metodologia e a empresa; em geral, tem as seguintes características, organizadas nos tópicos:

• ambiente de homologação: um servidor separado do servidor principal, para ser acessado pelas pessoas usuárias que verificam e testam o produto;
• banco de dados: deve permitir a simulação do funcionamento do produto, inclusive em situações de estresse;
• plano de testes: documento que lista o que deve ser testado e quando; certifique-se de que a acessibilidade está incluída e todas as funcionalidades previstas serão garantidas;
• pessoas usuárias: pessoas que desempenharão os papéis dos diversos públicos do produto; certifique-se de que os grupos que necessitam de acessibilidade estarão bem representados nesta etapa final.

7. Questões finais relacionadas a acessibilidade na Web

A acessibilidade não é uma moda que vai desaparecer com o tempo. Ignorar a acessibilidade é um erro num mundo em que cada vez mais países criam leis e normativos que protegem os direitos das pessoas com deficiência, garantindo seu direito à equidade de acesso. Hoje, o custo de ter produtos inacessíveis não se limita aos custos técnicos associados à correção do software. Em muitos casos, o custo da batalha legal e os danos à marca excedem em muito o custo de se tornar acessível.

Uma demonstração significativa do risco de ignorar os requisitos de acessibilidade foi o acordo de 2008, nos Estados Unidos, da National Federation of the Blind com os varejistas da Target, uma rede de supermercados [60]. A Target teve de arcar com:

• danos à categoria das pessoas cegas de US$ 6 milhões;
• honorários advocatícios do autor acima de US$ 3 milhões;
• honorários advocatícios de defesa não divulgados;
• supervisão judicial de seu sítio por vários anos.

No Brasil, ainda não há uma cultura estabelecida das pessoas com deficiência de se organizarem e processarem empresas e entidades cujos sítio e serviços digitais estejam inacessíveis. No entanto, existem casos de processos a diversas empresas que não ganharam a visibilidade devida. No Capítulo 3 do Fascículo II, há um passo-a-passo de como proceder no caso de encontrar um sítio inacessível e como acionar o Ministério Público, se necessário.

Outro ponto importante a ser mencionado: depois do lançamento do Fascículo II, foi promulgada a Lei n. 13.146 de 06 de julho de 2015, denominada “Lei Brasileira de Inclusão” (LBI) [61]. Seu artigo 63 diz que:

Ademais, o artigo 64 da LBI preconiza que “a acessibilidade nos sítios da internet de que trata o art. 63 desta Lei deve ser observada para obtenção do financiamento de que trata o inciso III do art. 54 desta Lei”, inciso que se refere a “financiamento de projeto com utilização de recursos públicos, por meio de renúncia ou de incentivo fiscal, contrato, convênio ou instrumento congênere”.

Em resumo, a LBI veta o uso de recursos públicos, inclusive por meio de renúncia ou incentivo fiscal, para o desenvolvimento de qualquer aplicativo ou sítio que não seja acessível.

Uma cultura organizacional ancorada no atraso torna tudo relacionado à deficiência mais difícil, desde a implementação de projetos de acessibilidade até a obtenção de suporte crítico para avançar com esse tema dentro da instituição [62]. Melhorar o suporte executivo é o primeiro passo para mudar as coisas. Como apontamos desde o início dessa cartilha, a acessibilidade pode ser cara quando realizada retroativamente. Usar opções de cores inacessíveis exigirá a reabertura de arquivos de leiaute, testar uma nova palheta e transpor as novas cores para o design system e as folhas de estilo, o que não costuma ser divertido ou barato. Também há custos de oportunidade, pois as pessoas que precisam fazer esse retrabalho podem não estar mais disponíveis. Diversas estruturas da organização devem estar envolvidas no processo de garantia de acessibilidade, sendo as principais:

• Gestão: gerentes de negócios devem estar cientes do processo, pois são responsáveis pelo orçamento e por quais canais devem priorizar.
• Gerenciamento de projetos: gerentes de projeto precisam estar envolvidos na priorização dos canais para mapear o cronograma do projeto. Devem diagnosticar problemas, determinar quanto tempo cada problema levará para ser corrigido e quantos recursos vão demandar. Outra responsabilidade comum é selecionar e gerenciar testadores dentre as pessoas usuárias representativas das comunidades de deficiência, integrando seus feedbacks no processo de avaliação.
• Desenvolvimento: desenvolvedores precisam ser capazes de, a partir dos relatórios, corrigir os problemas identificados. Para agilizar esse processo, é recomendável que o relatório de auditoria forneça detalhes suficientes a fim de que cada problema seja facilmente encontrado.
• Conteúdo: assim como desenvolvedores, as equipes responsáveis pelo conteúdo e pelas redes sociais devem ser capazes de corrigir os problemas apontados. É recomendável que os relatórios enviados aos desenvolvedores e conteudistas sejam formatados respeitando as especialidades técnicas de cada área.
• Engajamento e feedback da comunidade: a importância de envolver pessoas das comunidades com deficiência na revisão da usabilidade a partir de suas experiências digitais jamais será excessiva. O feedback dessas pessoas complementará os problemas identificados internamente ou pela empresa contratada, sendo uma fonte contínua de respostas a melhorias e correções implementadas.

8. Referências

• [1] HENRY, S. R. (ed.). Easy Checks – A First Review of Web Accessibility. Wakefield: W3C; WAI, 9 ago. 2023. Disponível em: https://www.w3.org/WAI/test-evaluate/preliminary/. Acesso em 20 nov. 2023.
• [2] VELLEMAN, E. Website Accessibility Conformance Evaluation Methodology (WCAG-EM) 1.0. W3C Working Group Note. Wakefield: W3C; WAI, 10 jul. 2014. Disponível em: https://www.w3.org/TR/WCAG-EM. Acesso em 20 nov. 2023.
• [3] MUÑOZ, O. R.; MONTOTO, O. C. Evaluar la accesibilidad con WCAG-EM. In: MUÑOZ, O. R.; MONTOTO, O. C. Accesibilidad Web. WCAG 2.1 de forma sencilla. Madri: Itákora Press, 2018. p. 45-52. Disponível em: https://www.usableyaccesible.com/archivos/Accesibilidad_Web_WCAG_21%20ARIA_21_12_2020.pdf. Acesso em 21.nov.2023.
• [4] WORLD WIDE WEB CONSORTIUM (W3C). Types of documents W3C publishes. Wakefield: W3C. Disponível em: https://www.w3.org/standards/types#NOTE. Acesso em 21 nov. 2023.
• [5] HENRY, S. R. Conformance Evaluation and Reports. Wakefield: W3C; WAI, 1 ago. 2023. Disponível em: https://www.w3.org/WAI/test-evaluate/conformance/. Acesso em 21 nov. 2023.
• [6] ACCESSIBILITY Conformance Reports. Microsoft, s.d. Disponível em: https://www.microsoft.com/en-us/accessibility/conformance-reports#coreui-banner-1tft0mh. Acesso em 21 nov. 2023.
• [7] GOOGLE Accessibility Conformance Reports. Google, s.d. Disponível em: https://about.google/belonging/accessibility-conformance-reports/. Acesso em 21 nov. 2023.
• [8] UNITED STATES. OpenACR Editor. Overview. Washington: USA GSA, dez. 2021. Disponível em: https://gsa.github.io/openacr-editor. Acesso em 21 nov. 2023.
• [9] CRIAÇÃO de PDFs acessíveis. Adobe, 24 maio 2023. Disponível em: https://helpx.adobe.com/br/acrobat/using/creating-accessible-pdfs.html. Acesso em 21 nov. 2023.
• [10] JENKINS, P.; SHIRE, D. WCAG 2.0 Compliance Costing Model. In: ANNUAL ACCESSING HIGHER GROUND ACCESSIBLE MEDIA, WEB AND TECHNOLOGY CONFERENCE, 16. Proceedings [...]. Westminster: IBM, 4-8 nov. 2013. Disponível em: https://accessinghigherground.org/handouts2013/jenkins/AHG2013-IBM_WCAG2%200Compliance_Costing_Model%20v6.pdf. Acesso em 21 nov. 2023.
• [11] USABLENET. ADA Accessibility Remediation Calculator. Atlanta: IAAP, s.d. Disponível em: https://info.usablenet.com/accessibility-remediation-calculator. Acesso em 21 nov. 2023.
• [12] GONZALEZ, M. Record Number of Lawsuits Filed Over Accessibility for People with Disabilities. SHRM, 23 mar. 2022. Disponível em: https://www.shrm.org/resourcesandtools/hr-topics/behavioral-competencies/global-and-cultural-effectiveness/pages/record-number-of-lawsuits-filed-over-accessibility-for-people-with-disabilities.aspx. Acesso em 21 nov. 2023.
• [13] USABLENET. The Ultimate Guide to Accessibility Testing. Atlanta: IAAP, s.d. Disponível em: https://info.usablenet.com/accessibility-testing. Acesso em 21 nov. 2023.
• [14] NIELSEN, J. Why You Only Need to Test with 5 Users. NN/g, 18 mar. 2000. Disponível em: https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/. Acesso em 21 nov. 2023.
• [15] WEB accessibility isn't always expensive or time consuming. BOIA, 12 ago. 2021. Disponível em: https://www.boia.org/blog/web-accessibility-isnt-always-expensive-or-time-consuming. Acesso em 21 nov. 2023.
• [16] URUGUAY. Metodología de evaluación de accesibilidad. Guía técnica. GUB.UY: Montevideo, 1 set. 2022. Disponível em: https://www.gub.uy/agencia-gobierno-electronico-sociedad-informacion-conocimiento/comunicacion/publicaciones/metodologia-evaluacion-accesibilidad. Acesso em 21 nov. 2023.
• [17] FIERS, W. et al. (ed.). Accessibility Conformance Testing (ACT) Rules Format 1.0. Wakefield: W3C, 31 out. 2019. Disponível em: https://www.w3.org/TR/act-rules-format/. Acesso em 21 nov. 2023.
• [18] SAJKA, J.; COOPER, M. (ed.). Challenges with Accessibility Guidelines Conformance and Testing, and Approaches for Mitigating Them. Wakefield: W3C, 19 jun. 2020. Disponível em: https://www.w3.org/TR/accessibility-conformance-challenges/. Acesso em 21 nov. 2023.
• [19] RIETVELD, R. Automated accessibility testing, a few scenarios. A11Y Collective, 17 jul. 2021. Disponível em: https://www.a11y-collective.com/automated-accessibility-testing-a-few-scenarios/. Acesso em 21 nov. 2023.
• [20] ABOU-ZAHRA, S.; STEENHOUT, N.; KEEN, L. (ed.). Selecting Web Accessibility Evaluation Tools. Wakefield: W3C; WAI, 23 dez. 2017. Disponível em: https://www.w3.org/WAI/test-evaluate/tools/selecting/. Acesso em 21 nov. 2023.
• [21] EGGERT. E.; ABOU-ZAHRA, S. (ed.). Web Accessibility Evaluation Tools List. Wakefield: W3C; WAI, mar. 2006. Disponível em: https://www.w3.org/WAI/ER/tools/. Acesso em 21 nov. 2023.
• [22] FERRAZ, R. Conformidade com validadores automáticos em uma página com barreiras de acesso. Reinaldo Ferraz, 22 jun. 2021. Disponível em: https://reinaldoferraz.com.br/conformidade-com-validadores-automaticos-em-uma-pagina-com-barreiras-de-acesso. Acesso em 21 nov. 2023.
• [23] DURAN, M. What we found when we tested tools on the world’s least-accessible webpage. GOV.UK, 24 fev. 2017. Disponível em: https://accessibility.blog.gov.uk/2017/02/24/what-we-found-when-we-tested-tools-on-the-worlds-least-accessible-webpage. Acesso em 21 nov. 2023.
• [24] AUTOMATED Accessibility Testing Tools: How much do scans catch? Level Acess, 1 dez. 2020. Disponível em: https://www.levelaccess.com/blog/automated-accessibility-testing-tools-how-much-do-scans-catch. Acesso em 21 nov. 2023.
• [25] THE AUTOMATED Accessibility Coverage Report. Why we need to change how we view accessibility testing coverage. Deque, 2021. Disponível em: https://accessibility.deque.com/hubfs/Accessibility-Coverage-Report.pdf. Acesso em 21 nov. 2023.
• [26] CENTRO TECNOLÓGICO DE ACESSIBILIDADE (CTA). Avaliação de acessibilidade em sites. Porto Alegre: IFRS, 14 fev. 2019. Disponível em: https://cta.ifrs.edu.br/avaliacao-de-acessibilidade-em-sites. Acesso em 21 nov. 2023.
• [27] ANDRADE, K. O que aprendi sobre acessibilidade quando migrei pra UX. Medium, 10 fev. 2021. Disponível em: https://medium.com/flux-design/o-que-aprendi-sobre-acessibilidade-quando-migrei-pra-ux-caa83001a56e. Acesso em 21 nov. 2023.
• [28] HOW the Accessible Usability Scale Makes User Research More Inclusive. Equal Entry, 13 set. 2021. Disponível em: https://equalentry.com/accessible-usability-scale-user-research. Acesso em 21 nov. 2023.
• [29] BRASIL. Checklist de acessibilidade manual para Deficientes Visuais. Brasília: MPOG; MEC, jun. 2010. Disponível em: https://www.gov.br/governodigital/pt-br/acessibilidade-digital/emag-checklist-acessibilidade-dv.pdf/@@download/file/eMAG-Checklist-acessibilidade-DV.pdf. Acesso em 21 nov. 2023.
• [30] BRASIL. Serviços para você. Brasília: MGI, s.d. Disponível em: https://www.gov.br/pt-br. Acesso em 22 nov. 2023.
• [31] BREWER, J. (ed.). Using Combined Expertise to Evaluate Web Accessibility. Wakefield: W3C; WAI, 9 jan. 2019. Disponível em: https://www.w3.org/WAI/test-evaluate/combined-expertise/. Acesso em 21 nov. 2023.
• [32] SWAN, H. et al. Inclusive Design Principles. s.d. Disponível em: https://inclusivedesignprinciples.org/. Acesso em 21 nov. 2023.
• [33] ACOSTA-VARGAS, P.; SALVADOR-ULLAURI, L. A.; LUJÁN-MORA, S. A Heuristic Method to Evaluate Web Accessibility for Users With Low Vision. IEEE ACESS, 17 set. 2019. Disponível em: https://ieeexplore.ieee.org/abstract/document/8822682. Acesso em 21 nov. 2023.
• [34] HENRY, S. L. (ed.). Involving Users in Evaluating Web Accessibility. Wakefield: W3C; WAI, 1 jun. 2021. Disponível em: https://www.w3.org/WAI/test-evaluate/involving-users/. Acesso em 21 nov. 2023.
• [35] HENRY, S. L. Planning Usability Testing. In: HENRY, S. L. Just Ask: Integrating Accessibility Throughout Design. S.d. Disponível em: http://www.uiaccess.com/accessucd/ut_plan.html. Acesso em 21 nov. 2023.
• [36] TESTING with Screen Readers. WebAIM, 20 maio 2019. Disponível em: https://webaim.org/articles/screenreader_testing. Acesso em 21 nov. 2023.
• [37] DESIGNING for Screen Reader Compatibility. WebAIM, 21 abr. 2017 Disponível em: https://webaim.org/techniques/screenreader. Acesso em 21 nov. 2023.
• [38] SWAN, H. Desinig for people who use a mouse. WebAIM, 9 nov. 2022. Disponível em: https://www.youtube.com/watch?app=desktop&v=1OBoXqM3B4A. Acesso em 21 nov. 2023.
• [39] RESULTADO da pesquisa do Uso de Leitores de Tela 3.0. NTT Data, 18 abr. 2022. Disponível em: https://estudoinclusivo.com.br/pesquisa-ldt/resultados3. Acesso em 21 nov. 2023.
• [40] VIGO, M.; BRANJNIK, G.; O´CONNOR, J. (ed.). Research Report on Web Accessibility Metrics. Wakefield: W3C, 26 maio 2014. Disponível em: https://www.w3.org/WAI/RD/2011/metrics/note/ED-metrics. Acesso em 21 nov. 2023.
• [41] BRASIL. Métricas para avaliação de acessibilidade virtual. Documento base para ASES, eSelo e Checklist Automatizado. Brasília: MPOG; UFRS, mar. 2015. Disponível em: https://ticwebacessibilidade.ceweb.br/ases/metricas_ases_eselo_junho_2016.pdf. Acesso em 21 nov. 2023.
• [42] WILLIAMS, G. Accessibility Program Fundamentals: Choosing the right accessibility metrics. Deque, 7 ago. 2019 Disponível em: https://www.deque.com/blog/accessibility-program-fundamentals-choosing-the-right-accessibility-metrics. Acesso em 21 nov. 2023.
• [43] MONTOTO, O. C. BS 8878:2010. Proceso para integrar la accesibilidad en todo el ciclo de vida de un producto web. Usable Acessible, 25 jun. 2015. Disponível em: https://olgacarreras.blogspot.com/2015/06/bs-88782010-proceso-para-integrar-la.html. Acesso em 21 nov. 2023.
• [44] MONTOTO, O. C. Accesibilidad web y SEO. Usable Acessible, dez, 2012. Disponível em: https://www.usableyaccesible.com/archivos/Accesibilidad_web_y_SEO_capitulo_ampliado_olga_carreras.pdf. Acesso em 21 nov. 2023.
• [45] CASHIN, C. SEO and Accessibility: Real Talk. Deque, 27 ago. 2019. Disponível em: https://www.deque.com/blog/seo-and-accessibility-real-talk/. Acesso em 21 nov. 2023.
• [46] HERRMANN, H. Accessibility for webapps. Herr Herrmann, 21 dez. 2021. Disponível em: https://herrherrmann.net/accessibility-for-webapps/. Acesso em 21 nov. 2023.
• [47] ACCESSIBILITY. React, s.d. Disponível em: https://legacy.reactjs.org/docs/accessibility.html. Acesso em 21 nov. 2023.
• [48] PATCH, K.; SPELLMANN, J.; WAHLBIN, K. (ed.). Mobile Accessibility: How WCAG 2.0 and Other W3C/WAI Guidelines Apply to Mobile. Wakefield: W3C, 26 fev. 2015. https://www.w3.org/TR/mobile-accessibility-mapping/. 2015. Acesso em 21 nov. 2023.
• [49] STANZAP. a11ycas. webapp. GitHub, s.d. Disponível em: https://github.com/StanZap/a11ycases-webapp. Acesso em 21 nov. 2023.
• [50] TRICHTER, D.; ILYAS, H.; SOHAL, A. Mobile Apps Accessibility Guidelines (2023). Accessibility Checker, abr. 2023. Disponível em: https://www.accessibilitychecker.org/guides/mobile-apps-accessibility/. Acesso em 21 nov. 2023.
• [51] MAKING great accessible mobile apps. GOV.UK, 23 jun. 2021. Disponível em: https://accessibility.blog.gov.uk/2021/05/04/making-great-accessible-mobile-apps/. 2021. Acesso em 21 nov. 2023.
• [52] SILVA, C. F. P. Um estudo sobre a automação de testes de acessibilidade em dispositivos móveis: uma análise de recomendações para deficiência visual da BBC. 2020. Dissertação (Mestrado em Ciências) – Escola de Artes, Ciências e Humanidades. Universidade de São Paulo, São Paulo, 2020. Disponível em: https://www.teses.usp.br/teses/disponiveis/100/100131/tde-16052020-111716/publico/Dissertacao_Camila_Ferreira_Pereira_SIlva.pdf. Acesso em 21 nov. 2023.
• [53] PERI, R. Free mobile accessibility testing tools for IOS and Android. DigitalA11Y, 20 out. 2023. Disponível em: https://www.digitala11y.com/free-mobile-accessibility-testing-tools/. Acesso em 21 nov. 2023.
• [54] BUILDING accessible apps. Apple, s.d. Disponível em: https://developer.apple.com/accessibility/. Acesso em 21 nov. 2023.
• [55] SHORT Guide on Mobile Accessibility Testing For IOS Apps. HOLITICA11Y, 20 mar. 2022. Disponível em: https://holistica11y.com/ios-accessibility-testing-checklist/. Acesso em 21 nov. 2023.
• [56] PRINCÍPIOS para melhorar a acessibilidade do app. Android Developers, s.d. Disponível em: https://developer.android.com/guide/topics/ui/accessibility/testing?hl=pt-br. Acesso em 21 nov. 2023.
• [57] TESTAR a acessibilidade do seu app. Android Developers, s.d. Disponível em: https://developer.android.com/guide/topics/ui/accessibility/principles?hl=pt-br. Acesso em 21 nov. 2023.
• [58] SHORT Guide on Mobile Accessibility Testing For Android Apps. HOLITICA11Y, 20 mar. 2022. Disponível em: https://holistica11y.com/android-accessibility-testing-checklist/. Acesso em 21 nov. 2023.
• [59] COOPERCORONA. Accessibility Test Framework for Android. GitHub, s.d. Disponível em: https://github.com/google/Accessibility-Test-Framework-for-Android. Acesso em 21 nov. 2023.
• [60] RUSH, S. (ed.). The Business Case for Digital Accessibility. Wakefield: W3C, WAI, 9 nov. 2018. Disponível em: https://www.w3.org/WAI/business-case. Acesso em 21 nov. 2023.
• [61] BRASIL. Lei n. 13.146, de 6 de julho de 2015. Institui a Lei Brasileira de Inclusão da Pessoa com Deficiência (Estatuto da Pessoa com Deficiência). Brasília: Presidência da república, 6 jul. 2015. Disponível em: https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2015/lei/l13146.htm. Acesso em 21 nov. 2023.
• [62] BYRNE-HABER, S. How to identify a Toxic Accessibility Culture, and what you can do about it. Medium, 1 jul. 2019. Disponível em: https://sheribyrnehaber.medium.com/how-to-identify-a-toxic-accessibility-culture-and-what-you-can-do-about-it-29c8ec9dc500. Acesso em 21 nov. 2023.

9. Modelos de Checklist

9.1. Checklist de Design

Data da aplicação: ______ /_____/_______

Pessoa Avaliadora: ______________________________________________

9.2. Checklist de Frontend

Data da aplicação: ______ /_____/_______

Pessoa Avaliadora: ______________________________________________

9.3. Checklist de Formulário

Data da aplicação: ______ /_____/_______

Pessoa Avaliadora: ______________________________________________

9.4. Checklist de Conteúdo

Data da aplicação: ______ /_____/_______

Pessoa Avaliadora: ______________________________________________

9.5. Checklist de Redes Sociais

Data da aplicação: ______ /_____/_______

Pessoa Avaliadora: ______________________________________________

9.6. Checklist de Canais de Atendimento

Data da aplicação: ______ /_____/_______

Pessoa Avaliadora: ______________________________________________

9.7. Checklist de WebApps

Data da aplicação: ______ /_____/_______

Pessoa Avaliadora: ______________________________________________

9.8. Checklist de Aplicativos Móveis

Data da aplicação: ______ /_____/_______

Pessoa Avaliadora: ______________________________________________

Checklists consultados

• Guidelines for Accessible Interfaces for people with Autism (GAIA)
  Guia de Acessibilidade de Interfaces Web com foco em aspectos do Autismo. Talita Pagani.
  Disponível em: https://gaia.wiki.br/
• eMAG. Checklist de Acessibilidade Manual para o Desenvolvedor. Disponível em: https://www.gov.br/governodigital/pt-br/acessibilidade-digital/emag-checklist-acessibilidade-desenvolvedores.pdf
• eMAG. Checklist de Acessibilidade Manual para Deficientes Visuais. Disponível em: https://www.gov.br/governodigital/pt-br/acessibilidade-digital/emag-checklist-acessibilidade-dv.pdf
• Lista de verificação "10 aspetos críticos de acessibilidade funcional". Selo de Usabilidade e Acessibilidade. Agência para a modernização administrativa, GOV.PT. Disponível em: https://amagovpt.github.io/kit-selo/checklists/checklist-10aspetos.html
• Lista de verificação "Conteúdo". Selo de Usabilidade e Acessibilidade. Agência para a modernização administrativa, GOV.PT. Disponível em: https://amagovpt.github.io/kit-selo/checklists/checklist-conteudo.html
• Lista de verificação "Transação". Selo de Usabilidade e Acessibilidade. Agência para a modernização administrativa, GOV.PT. Disponível em: https://amagovpt.github.io/kit-selo/checklists/checklist-transacao.html
• Accessibility Checklist for Visual Designers. HolisticA11Y. Disponível em: https://holistica11y.com/accessibility-checklist-for-visual-designers/
• Short Guide on Mobile Accessibility Testing For Android Apps. HolisticA11Y. Disponível em: https://holistica11y.com/android-accessibility-testing-checklist/
• Accessible PowerPoint Presentations Checklist. Queen’s University Disponível em: https://www.queensu.ca/accessibility/tutorials/accessible-documents/accessible-powerpoint-presentations-checklist
• Make your PowerPoint presentations accessible to people with disabilities. Microsoft. https://support.microsoft.com/en-us/office/make-your-powerpoint-presentations-accessible-to-people-with-disabilities-6f7772b2-2f33-4bd2-8ca7-dae3b2b3ef25