Elementos não textuais devem ter um texto alternativo que descreva o seu significado. Elementos não textuais, como imagens, cujo significado é essencial para a compreensão do que é exibido na tela, devem ter uma alternativa textual a ser interpretada por recursos de tecnologia assistiva. Elementos meramente decorativos devem ser ignorados por recursos de tecnologia assistiva.

Elementos interativos e de interface do usuário devem ter rótulos que descrevem o elemento, sua funcionalidade, estado ou operação. Elementos de interface interativos, como botões e campos de formulário, devem conter um rótulo que descreve a sua função. Os rótulos devem estar relacionados com o elemento por meio de código de programação. Nem todos os elementos possuem todas essas características, mas eles devem ser compreensíveis para a operação do usuário.

Deve haver cabeçalhos e rótulos para organizar a estrutura da aplicação. A aplicação deve estar estruturada por meio de elementos de cabeçalho em títulos de seção e rótulos em campos de entradas de dados, permitindo que usuários de tecnologia assistiva compreendam melhor sua organização. O uso desses recursos possibilita a localização do conteúdo de forma mais rápida.

Deve ser mantida a mesma organização de elementos funcionais e nomes acessíveis ao longo de toda a aplicação. Os elementos funcionais devem manter-se na mesma posição e com a mesma descrição acessível. Isso facilita a compreensão e acelera o aprendizado do usuário

Os nomes acessíveis devem conter os rótulos dos elementos. Para os elementos que possuam rótulos em texto ou imagens de texto, o nome acessível deve conter todo o rótulo. Sempre que possível, o texto do rótulo deve estar no começo do nome acessível.

Elementos de interface interativos devem descrever sua funcionalidade de forma clara, para a compreensão mesmo fora do contexto. Elementos como botões, links e ícones devem ser compreendidos mesmo fora do contexto. Esses elementos devem ter atributos ou alternativas textuais que descrevem sua funcionalidade aos usuários de tecnologia assistiva. Em caso de elementos que se repetem na interface, cada um deles deve fazer referência a qual objeto ou contexto a ação ou funcionalidade está relacionada.

Os rótulos de campos de formulário devem estar posicionados na ordem usual. Os rótulos de formulários devem ser posicionados adjacentemente ao seu respectivo campo. Em campos de formulário gerais, como os de entrada de textos e/ou números, o rótulo deve ser posicionado antes do campo, ou seja, à esquerda ou acima. Em formulários de botão de rádio (radio button) e caixas de marcação (checkboxes), os rótulos devem estar após as respectivas opções, à direita. A ordem destes itens no código deve coincidir com a ordem visual, para manter a experiência independentemente da forma de navegação do usuário. Esse tipo de posicionamento melhora a previsibilidade da leitura do formulário, usando visão e tecnologias assistivas, além de evitar desalinhamentos acidentais.

Os campos de formulários devem ter seu tipo determinado com base na necessidade de entrada. Deve ser especificado o tipo de campo para a entrada de dados de acordo com a finalidade deste campo. Especificar o tipo de campo de formulário por meio de código de programação oferece uma experiência melhor para o usuário.

Deve haver instruções de preenchimento de entrada de dados. Campos de entrada de dados devem ter, além do seu rótulo, instruções de preenchimento relacionadas com o tipo de dados exigidos para entrada, de forma que o usuário possa perceber. Essa técnica é importante para evitar que o usuário cometa erros durante o preenchimento do formulário. Isto pode tomar forma como (mas não se limitando a) de “marcadores de posição” (placeholder), etiqueta, parágrafos ou instruções prévias. Na dúvida, deve-se ser redundante.

Deve haver indicador de foco de navegação. Os aplicativos devem permitir que recursos de tecnologia assistiva que suportam indicador de foco visível em navegação sequencial, como leitores de tela, exibam esse indicador adequadamente.

Os elementos de interface de itens em sequência ou que exigem paginação devem situar o usuário. Deve ficar claro para o usuário a quantidade de etapas, o intervalo mostrado, o seu posicionamento atual e o número de itens totais quando uma ação exige interação em itens sequenciais.

Os textos e elementos gráficos devem ter contraste suficiente com seus respectivos planos de fundo. Deve haver contraste mínimo entre os textos e seus respectivos planos de fundo. Também deve haver contraste mínimo entre os elementos gráficos relevantes e seus respectivos planos de fundo e/ou entornos. As taxas de contraste devem estar em conformidade mínima com os critérios de sucesso nível AA do WCAG 2.1. Elementos interativos no estado desabilitado não precisam cumprir requisitos de contraste. Elementos gráficos meramente decorativos e logotipos também estão isentos.

A cor não pode ser a única forma de transmitir informação. Qualquer elemento de interface do usuário que dependa de cor para a sua compreensão deve ter uma outra forma de compreensão que não dependa apenas da cor.

Não podem existir instruções que dependem somente das características sensoriais do usuário. As instruções fornecidas para compreender e utilizar o conteúdo não podem depender somente das características sensoriais dos elementos de interface, como forma, cor, tamanho, localização visual, orientação ou som.

Todo retorno (feedback) fornecido pela aplicação deve ser percebido por todos os usuários e por recursos de tecnologia assistiva. Ações de interação do usuário, como o acionamento de botões e elementos interativos, devem fornecer um retorno (feedback) perceptível a todos os usuários. Esse retorno (feedback) pode ser visual, mas também deve oferecer alternativas para os usuários de tecnologia assistiva.

A aplicação deve fornecer uma forma de saída ou retorno perceptível a todos os usuários. O usuário deve ter formas de retornar ou voltar para as telas anteriores de forma intuitiva.

Deve haver programaticamente um título que descreva a finalidade das páginas e aplicações. Em páginas web acessadas pelo navegador, isso geralmente é feito pelo elemento HTML <title>. Para o caso de aplicação web, híbrida ou nativa, deve-se seguir a documentação da tecnologia aplicada, sendo o nome dessa aplicação o suficiente para atender a esta orientação. Esta informação deve ser interpretada corretamente por tecnologias assistivas, como um leitor de tela, ao navegar entre diferentes abas de um navegador web ou aplicativos abertos simultaneamente no aparelho.

Os idiomas da aplicação e das partes devem ser declarados. A declaração do idioma deve ser feita dentro do código-fonte da aplicação, conforme a especificação da tecnologia utilizada para o seu desenvolvimento. Caso ocorra mudança de idioma na mesma tela da aplicação, o código de idioma também deve ser declarado, exceto nomes próprios, vocabulário técnico e palavras ou frases estrangeiras que são parte do vocabulário nacional. Essa técnica permite que tanto o sistema operacional quanto o recurso de tecnologia assistiva identifiquem o idioma e apresentem o conteúdo ao usuário de forma compreensível. A forma de declaração do idioma pode mudar, dependendo da tecnologia de desenvolvimento da aplicação.

Deve haver opção de contornar os elementos piscantes. Caso existam elementos em tela que piscam três vezes ou mais por segundo, o usuário deve ser avisado com antecedência para que possa evitar a visualização deste tipo de conteúdo. Caso seja tecnicamente possível, deve haver uma função para desabilitar os elementos piscantes. Elementos piscantes podem deixar os usuários desorientados, confusos ou causar desconforto e convulsões em pessoas com fotossensibilidade.

A aplicação deve respeitar as configurações de acessibilidade do dispositivo do usuário. A aplicação não pode alterar as configurações de acessibilidade do usuário sem que ele seja notificado e concorde com a mudança.

Deve haver controle do usuário sobre as ações por movimento de dispositivos móveis. A aplicação deve permitir que o usuário desative a resposta ao movimento físico do aparelho e forneça alternativa de execução desta ação por meio de componentes de interface.

A aplicação deve permitir que o usuário configure suas formas de notificação. O usuário deve ter autonomia para escolher como e se deseja receber notificações da aplicação.

O usuário deve ser avisado sempre que for necessário forçar uma determinada orientação (retrato ou paisagem) do dispositivo.

Deve haver tempo suficiente para o usuário executar as atividades. Nas aplicações em que a limitação de tempo não é essencial para a execução de uma atividade, deve haver a possibilidade de controle de tempo pelo usuário. Caso haja alguma limitação de tempo, esta limitação pode ser desligada ou prolongada de forma simples e eficiente por ao menos 10 vezes, ou deve ser superior a 20 h.

Deve haver uma forma de controlar os áudios iniciados automaticamente.Caso uma aplicação ou página inicie a reprodução de um áudio automaticamente e esta reprodução persista por mais de três segundos, deve haver um mecanismo para parar, pausar ou controlar o volume do áudio, de tal forma que não atrapalhe a experiência do usuário, independentemente de uso de recursos assistivos.

Deve haver controle do usuário para pausar, parar ou ocultar conteúdo que se movimente na tela. A aplicação deve permitir uma forma de parar, pausar ou ocultar conteúdo em movimento que é iniciado automaticamente, que dure mais de cinco segundos e que esteja próximo a outros conteúdos. Atualizações de tela também devem permitir o controle do usuário.

Não pode haver alteração de contexto inesperada ao interagir com formulários. Interações com formulários devem ter efeitos previsíveis, ou seja, ao entrar ou editar dados em formulários, não pode ocorrer de forma automática uma alteração de contexto sem que o usuário tenha conhecimento prévio. As alterações de contexto inesperadas podem deixar desorientados os usuários que não conseguem ter visibilidade completa da página.

Não pode haver alteração de contexto inesperada ao focar em elementos interativos. Nenhum tipo de alteração de contexto ocorre quando algum elemento de interface recebe foco. Assim, há garantia de previsibilidade de navegação na tela sobre componentes que possuem algum tipo de interação. Um componente pode receber foco tanto com algum recurso de tecnologia assistiva (por exemplo, com a utilização de um leitor de tela) como sem recurso de tecnologia assistiva (tocar em um campo de formulário para ativar a digitação).

Toda interação deve ser suportada por um único toque na tela. Caso existam aplicações que exijam múltiplos toques ou gestos específicos, deve existir uma forma de permitir que o usuário consiga executar a mesma ação com toque único

Não pode haver bloqueio na navegação sequencial com recursos de tecnologia assistiva. A aplicação deve permitir que tecnologias assistivas que utilizam navegação sequencial, normalmente pelo movimento rápido de deslizar o dedo (também conhecido como swipe), como um leitor de tela, percorram todo o conteúdo livremente sem ficar preso em ponto algum.

A aplicação deve informar ao usuário os erros de interação e dar a oportunidade de corrigir o erro sem prejuízo do uso da aplicação. As informações referentes aos erros do usuário devem ser claras, e a aplicação deve permitir a sua correção.

Deve haver suporte para ampliação da tela sem perda de informação ou funcionalidade. Quando o usuário fizer ampliação da tela (zoom) em uma aplicação, ele não pode perder informação ou funcionalidade, como, por exemplo, elementos que ficam escondidos atrás de outros elementos de interface visuais.

As aplicações que façam uso de comandos de voz devem permitir outra modalidade de comandos por meio de interface interativa. Se uma aplicação utilizar comandos de voz para executar uma ação, esta ação está disponível também em uma outra modalidade de interação

Os vídeos devem oferecer legendas para conteúdo em áudio. Em vídeos ao vivo, deve-se oferecer esse recurso utilizando estenotipia, legenda automática ou serviço similar.

Deve haver ao menos um recurso alternativo para todo conteúdo de vídeo pré-gravado, como transcrição ou audiodescrição. Para tornar o conteúdo disponível a mais pessoas, deve ser fornecida uma transcrição que contenha todas as informações da mídia pré-gravada (visual ou sonora) na forma de texto ou audiodescrição da mídia de vídeo. Além das informações contidas nas falas, deve-se informar todo o conteúdo visual relevante para a compreensão do vídeo, como expressões corporais, risadas, informações em texto, mudança de ambiente, entre outros. Transcrição e audiodescrição são recursos importantes para a acessibilidade. Ambos beneficiam pessoas surdas, que não podem compreender o conteúdo em áudio, e pessoas com deficiência visual (cegas ou com baixa visão), que podem não compreender informações visuais. Recomenda-se adicionar os dois recursos à mídia.

Deve existir uma transcrição textual para conteúdo de áudio pré-gravado. Para que as pessoas tenham acesso ao conteúdo por áudio, é ideal que exista uma alternativa em texto, de preferência, de modo sincronizado para acompanhamento.

Os códigos devem ser estruturados de forma correta. Toda a aplicação deve ser codificada conforme as documentações de padrões técnicos, para garantir compatibilidade com o máximo de dispositivos e tecnologias assistivas. Para aplicações e páginas web que rodam em dispositivos móveis, as linguagens de marcação e o conteúdo devem ser bem estruturados e válidos, de acordo com as regras definidas nessas linguagens. Os erros na sintaxe dos elementos e atributos e as falhas de estrutura podem impedir a correta interpretação do conteúdo por agentes de usuário e tecnologias assistivas. Caso sejam utilizados elementos de interface ou controles customizados, é necessário verificar se do componente possui nome, função e valores declarados, e se são acessíveis por recurso de tecnologia assistiva.