# data[].attributes.body
O critério visa permitir que o usuário tenha controle total sobre mudanças de contextos. Fazendo com seja necessário realizar uma ação do usuário para que a mudança aconteça, evitando que janelas abram automaticamente, formulários sejam enviados sem uma confirmação, etc.

Caso exista uma situação de mudança automática em que o usuário possa ativar e/ou desativar seu funcionamento, o critério pode continuar sendo atendido.

No caso de links, se a abertura da nova página não ocorrer em uma nova aba, o critério não estará sendo atendido.

Quem se beneficia?
- Pessoas com deficiências motoras;
- Pessoas com baixa visão;
- Pessoas cegas;
- Pessoas com certas limitações cognitivas.

Como testar?

----
Ao cumprir esse critério, estará cumprindo com o 3.2.1 (A) e o 3.2.2 (A).

# data[].attributes.attachment_link.readable_text
Items such as slideshows may automatically change context. In this case, ensure functions are available for users to control this automated change.

Before Rectification

The example above shows a webpage having live updates of news items. Persons with vision impairments or specific learning difficulties may not have enough time to read all the news items before the automatic update with the latest news items.

After Rectification

In this example, users who have difficulties in reading the news items within the time limit are provided with the option to request an update or pause the update.
WCAG 2.0 Reference: http://www.w3.org/TR/UNDERSTANDING-WCAG20/consistent-behavior-no-extreme-changes-context.html

# data[].attributes.attachment_link.keywords[]
wcag 2.0 success criterion 3.2.5 − change on request

# data[].attributes.attachment_link.title
OGCIO : WCAG 2.0 Success Criterion 3.2.5 − Change on Request

# data[].attributes.attachment_link.description
Items such as slideshows may automatically change context. In this case, ensure functions are available for users to control this automated change.

# data[].attributes.headline
Requisito 2.5.5 - Tamanho da área clicável - [AAA] - Operável

# data[].attributes.subject
Requisito 2.5.5 - Tamanho da área clicável - [AAA] - Operável

# data[].attributes.body
O que é:
A intenção do critério de sucesso é garantir que os tamanhos de destino sejam grandes o suficiente para que os usuários ativem com facilidade (mínimo 44x44 pixels), mesmo que o usuário esteja acessando o conteúdo em um dispositivo pequeno com tela de toque, tenha destreza limitada ou tenha problemas para ativar pequenos destinos por outros motivos.
O que se torna um problema, pois é um mecanismo de entrada que possui muita precisão. Um dedo pode muito bem obstruir a visão do usuário na localização precisa da tela em que está tocando.

Layouts responsivos em telas pequenas costumar ser alvo de grande problema também, por exemplo os dispositivos móveis, que precisam acomodar diferentes tipos de entradas. Ambos os tipos de entrada devem ser suportados para um site que pode ser acessado em um desktop / notebook tradicional com um mouse, bem como em um tablet ou smartphone.

Se existir mais uma opção na tela que executará a mesma ação, somente uma delas precisa ter sua área maior igual a 44x44 pixels.

O tamanho mínimo também não é necessário em links utilizados no meio de frases e/ou parágrafos, porém, se o link está em toda a frase, será necessário cumprir com a área mínima requisitada.

Quem ira se beneficiar?

Usuários que usam um dispositivo móvel em que a tela sensível ao toque é o principal modo de interação;

Usuários com problemas de mobilidade, como tremores nas mãos;

Usuários que usam um dispositivo móvel em ambientes onde são expostos a tremores, como transporte público;

Usuários que têm dificuldade com movimentos motores finos;

Usuários que acessam um dispositivo com uma mão;

Usuários com dedos grandes ou que operam o dispositivo com apenas uma parte do dedo ou da junta;

Os usuários com baixa visão podem ver melhor o alvo.

# data[].attributes.body
O objetivo do critério é reduzir ainda mais as chances de convulsão. Diferente do critério 2.3.1 que permitia que nenhum conteúdo deveria piscar 3 vezes por segundo, a não ser que os flashes estejam em baixo contraste ou possuam pouco vermelho, no critério 2.3.2 nenhum conteúdo da página deve piscar mais que 3 vezes por segundo, sem exceção. Independente do brilho, do contraste, ou tamanho da área.

Quem se beneficia:

Indivíduos que sofrem convulsões ao visualizar o material em flash serão capazes de visualizar todo o material em um site sem ter uma convulsão e sem ter que perder a experiência completa do conteúdo, limitando-se a alternativas em texto.

Pessoas com epilepsia fotossensível, bem como outros distúrbios convulsivos fotossensíveis.

# data[].attributes.attachment_link.readable_text
Ensure there is nothing on a website that "flashes" for more than three times per second irrespective of its size. Otherwise, this may cause problems for people who suffer from epilepsy.

Before Rectification

In this example, the traffic light image is flashing too fast and is large in size. This can cause seizures.

After Rectification

It is better to replace flashing content with static content that does not change.
WCAG 2.0 Reference: http://www.w3.org/TR/UNDERSTANDING-WCAG20/seizure-three-times.html

# data[].attributes.attachment_link.keywords[]
wcag 2.0 success criterion 2.3.2 − three flashes

# data[].attributes.attachment_link.title
OGCIO : WCAG 2.0 Success Criterion 2.3.2 − Three Flashes

# data[].attributes.attachment_link.description
Ensure there is nothing on a website that "flashes" for more than three times per second irrespective of its size. Otherwise, this may cause problems for people who suffer from epilepsy. In this example, the traffic light image is flashing too fast and is large in size. This can cause seizures.

# data[].attributes.headline
Requisito 1.4.9 - Imagens de texto (sem exceção) - AAA - Perceptível

# data[].attributes.subject
Requisito 1.4.9 - Imagens de texto (sem exceção) - AAA - Perceptível

# data[].attributes.body
Este critério afirma a importância da utilização de texto ao invés de imagens com textos. As exceções englobam: imagem decorativa, logos de marcas, imagem com texto que seja necessário para o conteúdo e que não possa ser modificada (como por exemplo uma imagem demonstrando um tipo de tipografia).

O objetivo do critério é permitir que o usuário possa realizar modificações  na aparência dos textos para sua melhor experiência, como: tamanho da fonte, cor, cor do background, etc.

Quem se beneficia?
Pessoas com baixa visão, pessoas com problema de rastreamento visual (ler o texto com espaçamento, e ou linhas), pessoas com deficiência cognitiva.

Como testar?
Teste funcional
tem imagem de texto no lugar que pode usar texto simples?
tem citações de texto como imagem?

---
Ao cumprir esse critério, automaticamente estará cumprindo com o 1.4.5.

# data[].attributes.headline
Requisito 1.2.8 - Mídia alternativa (pré-gravado) - [AAA] Perceptível

# data[].attributes.subject
Requisito 1.2.8 - Mídia alternativa (pré-gravado) - [AAA] Perceptível

# data[].attributes.body
Esse critério visa oferecer aos indivíduos que não conseguem utilizar legenda e áudio descrição, uma alternativa para usufruírem de mídias baseadas em tempo.
Ele consiste em oferecer em forma de texto a contextualização visual e auditiva, como se fosse um livro: descrevendo cenários, expressão no rosto dos atores, diálogos, risadas, entre outros.

Os critérios 1.2.5 e 1.2.8 são as mesmas que compõem a diretriz 1.2.3 a diferença está na forma de adequar o conteúdo.

Quem se beneficia?
Pessoas com deficiência na visão (parcial ou total) e audição (parcial ou total).

Como testar?
Teste Funcional
O texto condiz com o áudio/vídeo?

# data[].attributes.headline
3.2.7 - Controles ocultos [AA] Compreensível

# data[].attributes.subject
3.2.7 - Controles ocultos [AA] Compreensível

# data[].attributes.body
Este critério ainda é um rascunho, antes da publicação oficial da WCAG 2.2 ele pode ser retirado.

Controles necessários para progredir ou concluir um processo são visíveis no momento em que são necessários, sem exigir a passagem do ponteiro ou foco do teclado para torná-los persistentemente visíveis.

Intenção:

A intenção é garantir que os controles necessários para progredir ou concluir um processo possa ser facilmente encontrado por pessoas com deficiência cognitiva.

Os controles devem ser visíveis sem a interação do usuário.

# data[].attributes.headline
1.4.13 - Conteúdo em foco por mouse ou teclado - AA - Perceptível

# data[].attributes.subject
1.4.13 - Conteúdo em foco por mouse ou teclado - AA - Perceptível

# data[].attributes.body
Ao receber e então remover o ponteiro do mouse ou do foco do teclado aciona o conteúdo adicional o tornando visível e então oculto, o itens seguintes são verdadeiros:

Descartável: Um mecanismo está disponível para descartar conteúdo adicional sem mover o ponteiro do mouse ou o foco do teclado, a menos que o conteúdo adicional comunique um erro de entrada ou não obscureça ou substitua outro conteúdo;

Flutuante (passar o cursor sobre): Se o ponteiro do mouse puder acionar o conteúdo adicional ao passar sobre ele, então o ponteiro poderá ser movido sobre o conteúdo adicional sem que o conteúdo adicional desapareça;

Persistente: O conteúdo adicional permanece visível até que o acionador do mouse ou do foco seja removido, o usuário o descarte ou sua informação não seja mais válida. Exceção: a apresentação visual de conteúdo adicional é controlada pelo agente de usuário e não é modificada pelo autor.

Público

Usuário com baixa visão: A navegação por vezes feita somente por meio do teclado faz com que estes usuários não queiram a pequena área de sua janela de visualização ampliada cheia de texto flutuante. Eles precisam de um método de teclado para descartar algo que está obscurecendo a área focal atual.

Usuários que precisam de tempo para perceber, ler e processar novos conteúdos.

Neste casos, a tecla "ESC" auxilia no descarte fácil o conteúdo adicional ou/e posicionar o conteúdo adicional de forma que não obscureça nenhum outro conteúdo

Exceções

Este critério de sucesso não inclui pop-ups cuja apresentação é controlada pelo navegador da web, como dicas de ferramentas criadas usando o atributo Título HTML.

Isso não inclui links “Pular para o conteúdo principal” que se tornam visíveis quando recebem o foco, porque não há novo conteúdo sendo disponibilizado além do objeto que recebeu o foco.

# data[].attributes.headline
Requisito 1.4.10 - Refluxo - [AA] - Perceptível

# data[].attributes.subject
Requisito 1.4.10 - Refluxo - [AA] - Perceptível

# data[].attributes.body
O que é:
A intenção deste Critério de Sucesso é apoiar pessoas com baixa visão que precisam ampliar o texto e lê-lo em uma única coluna. Quando o zoom do navegador é usado para dimensionar o conteúdo em 400%, ele reflui - ou seja, é apresentado em uma coluna para que a rolagem em mais de uma direção não seja necessária. Para pessoas com baixa visão, o texto ampliado com refluxo permite a leitura.

Quem se beneficia:
Principalmente pessoas com baixa visão, quem podem navegar em um site através de uma única coluna, com o layout refluído.

Como testar:

Exemplos:
https://www.youtube.com/watch?v=fs3ZKymqSEU

# data[].attributes.headline
1.4.3 - Contraste (mínimo) - AA - Perceptível

# data[].attributes.subject
1.4.3 - Contraste (mínimo) - AA - Perceptível

# data[].attributes.body
Para textos e imagens contendo textos deve ter a relação de contraste de 4.5:1. A intenção desse Critério de Sucesso é de que o texto possa ser lido por pessoas com baixa visão moderada (que não utilizem tecnologias assistivas para aumento de contraste) que podem ter doenças congênitas ou adquiridas, idosos e daltônicos. Esse critério considera fontes de espessura média, por isso deve-se ter cuidado com fontes em modo light e thin.

Existe a problemática de imagens com texto pois ao redimensionarem podem pixelar e também impossibilitam o usuário de modificar a cor do fundo ou do texto.

Placeholders, o hover em elementos (e o conteúdo, quando aparece junto) e o foco do teclado também precisam seguir o contraste mínimo.

Exceções

Texto grande (18pt ou 14pt bold) podem ter 3:1 de contraste;

Textos em elementos inativos, textos que são apenas decorativos ou que não são visíveis a ninguém;

Logotipos.

O critério de sucesso encoraja a criação de mecanismos para alterar a cor de texto/fundo, pois algumas pessoas com alguma deficiência cognitiva preferem combinação de cores com contraste mais baixo (que pode ser inclusive abaixo do valor mínimo que o Critério de Sucesso estipula). É interessante também lembrar que o contraste entre preto puro e branco puro podem gerar desconfortos pelo alto brilho.

Plugins para conferir o contraste (Figma, Sketch e Adobe XD):

Contrast e Stark

Sites para conferir o contraste entre cores:

whocanuse.com

accessible-colors.com

color.adobe.com

# data[].attributes.body
O que é:
A intensão deste critério é fornecer às pessoas cegas ou com deficiência visual acesso às informações visuais em uma apresentação de mídia sincronizada.
É um critério que complementa o 1.2.3 que fala de audiodescrição ou mídia alternativa.

Quem se beneficia:
Pessoas que tenham cegueira ou baixa visão, bem como aquelas pessoas que tem dificuldade em interpretar visualmente o que está acontecendo.

Como testar?
Teste Funcional.

Exemplos:
https://www.youtube.com/watch?v=mtLeuAOwRiY

# data[].attributes.attachment_link.title
😎[AUDIODESCRIÇÃO] O corpo fala | Turma da Mônica

# data[].attributes.body
A intenção deste Critério de Sucesso é garantir que os agentes do usuário, incluindo tecnologias assistivas, possam interpretar e analisar o conteúdo com precisão.

Se o conteúdo não puder ser analisado em uma estrutura de dados, diferentes agentes do usuário podem apresentá-lo de maneira diferente ou ser completamente incapazes de analisá-lo. Alguns agentes de usuário usam "técnicas de reparo" para renderizar conteúdo mal codificado. Uma vez que as técnicas de reparo variam entre os agentes do usuário, os autores não podem presumir que o conteúdo será analisado com precisão em uma estrutura de dados ou que será processado corretamente por agentes de usuário especializados, incluindo tecnologias assistivas, a menos que o conteúdo seja criado de acordo com as regras definidas no documento formal gramática para essa tecnologia.

Alguns tipos de problemas comuns que levam a esta condição de falha

Marcas de abertura e fechamento sem os colchetes de abertura <e fechamento>.

Tag de fechamento sem a inicial / para indicar que é uma tag de fechamento.

Valores de atributo que possuem uma cotação de abertura, mas não uma cotação de fechamento. Os valores dos atributos devem estar totalmente entre aspas ou, em algumas linguagens de marcação, podem estar sem aspas.

Falta de espaço em branco entre os atributos.

Valores de atributo sem aspas que possuem espaço em branco no valor.

Falha em fornecer uma tag de fechamento de elemento para elementos que não aceitam sintaxe de elemento vazio.

Exemplo:

A página https://ofertas.vw.com.br/ tem duplicidade de IDs.

# data[].attributes.body
Exemplo de como instruir o usuário a digitar a data da maneira correta.

# data[].attributes.body
Exemplo onde o critério não é saciado: no VSTS os campos de effort não indica o formato válido de inserção dos dados.

# data[].attributes.headline
Requisito 2.4.3 Ordem do foco - [A] Operável

# data[].attributes.subject
Requisito 2.4.3 Ordem do foco - [A] Operável

# data[].attributes.body
O que é?
Quando a pessoa usuária for navegar pelo conteúdo (através de um teclado) ela precisa encontrar uma sequência lógica nos elementos focáveis.

Exemplo: https://developer.mozilla.org/pt-BR/docs/Web/Accessibility

# data[].attributes.attachment_link.readable_text
Acessiblidade no desenvolvimento Web significa permitir que o máximo possível de pessoas possa acessar os sites da web mesmo quando suas habilidades são limitadas de alguma forma. Aqui nós fornecemos informações sobre o desenvolvimento de conteúdo acessível.

"A palavra Acessibilidade é, frequentemente, usada para descrever facilidades ou assistências às pessoas com necessidades especiais, como em acessível para cadeirantes. Isto pode se estender para o Sistema Braille, rampas para cadeirantes, sinais sonoros em passagens de pedestres, modelos de páginas e assim por diante". Acessibilidade na Wikipedia

" A Web é, fundamentalmente, projetada para funcionar para todas as pessoas, independentemente de máquina, programas, língua, cultura, localização ou capacidade física ou mental de seus utilizadores. Quando a web atende a esses requisitos, ela se torna acessível a pessoas com dificuldades auditivas, motoras, visuais e cognitivas". W3C - Acessibilidade

# data[].attributes.attachment_link.description
Acessiblidade no desenvolvimento Web significa permitir que o máximo possível de pessoas possa acessar os sites da web mesmo quando suas habilidades são limitadas de alguma forma. Aqui nós fornecemos informações sobre o desenvolvimento de conteúdo acessível. "A palavra Acessibilidade é, frequentemente, usada para descrever facilidades ou assistências às pessoas com necessidades especiais, como em acessível para cadeirantes.

# data[].attributes.headline
Requisito 3.3.2 Rótulos e instruções [A] Compreensível

# data[].attributes.subject
Requisito 3.3.2 Rótulos e instruções [A] Compreensível

# data[].attributes.body
O que é:
Esse critério tem a intensão de fazer com que os autores de conteúdo apresentem instruções ou rótulos que identifiquem os controles de um formulário, para ajudar que os usuários saibam quais dados são esperados para aquele campo.
A ideia aqui não é  colocar informações desnecessárias na página, mas sim, fornecer dicas e instruçoes importantes para beneficiar os usuários.

Quem se beneficia:
Todos os usuários são beneficiados, mas principalmente aqueles com deficiências cognitivas, de linguagem e também de aprendizagem. Esse critério ajuda a evitar que usuários façam envios equivocados, incompletos ou incorretos, o que auxilia que usuários precisem navegar mais de uma vez na página para corrigir a informação antes do envio.

Como testar?
Verificar se ao clicar no campo ele descreve as informações necessárias conforme a indicação da diretriz ou seja, se cada rótulo esclarece a finalidade do componente.

Exemplos:
1. Um input de telefone que indica que é necessário inserir o DDD, DDI e o número, além de exibir o formato necessário.

2. Um formulário que indica quais são os campos obrigatórios e opcionais.

# data[].attributes.attachment_link.title
OGCIO：8.23 WCAG 2.0 Success Criterion 3.3.2 − Labels or Instructions

# data[].attributes.attachment_link.description
To help persons with disabilities avoid making mistakes, it is good to provide simple instructions and cues for entering information into forms. For example, use labels, instructions and examples. The above screen is a typical "Contact Us" form. However, there is no information on what format to use to enter the phone number.

# data[].attributes.headline
Requisito 2.5.4 - Atuação em movimento - A - Operável

# data[].attributes.subject
Requisito 2.5.4 - Atuação em movimento - A - Operável

# data[].attributes.body
Esse critério afirma que se existir alguma função acionada ao mover o dispositivo é necessário existir uma forma de:
a) Desativar;
b) Realizar a ação por meio de uma interface gráfica.

Exemplos:
1. Agitar o telefone para ligar a lanterna (Motorola);
2. Agitar o telefone para desfazer o ato (iPhone);
3. Girar rapidamente o telefone para ativar a câmera (Motorola);
4. Sorrir para tirar automaticamente uma foto;

Um exemplo que não se aplica ao critério, é o pedômetro. Que depende exclusivamente do movimento do dispositivo, portanto, não é possível desabilità-lo.

Quem irá se beneficiar com isso?
Pessoas com dificuldade ou deficiência motora podem utilizar alguns exemplos para realizarem tal tarefa.

Como esse critério é testado?
O teste é realizado de forma funcional.

# data[].attributes.headline
Requisito 2.4.4: Finalidade do link - [A] Operável

# data[].attributes.subject
Requisito 2.4.4: Finalidade do link - [A] Operável

# data[].attributes.body
O objetivo deste Critério de Sucesso é ajudar os usuários a compreender a finalidade de cada link para que possam decidir se desejam acessá-lo.
Sempre que possível, deve ser fornecido um texto de link que identifique a finalidade do link sem a necessidade de contexto adicional. A tecnologia assistiva tem a capacidade de fornecer aos usuários uma lista de links que estão na página da web. O texto do link que é o mais significativo possível ajudará os usuários que desejam escolher a partir dessa lista de links. Um texto de link significativo também ajuda aqueles que desejam navegar de um link para outro. Links significativos ajudam os usuários a escolher quais links seguir sem exigir estratégias complicadas para entender a página.

Quem se beneficia disso?

Pessoas com deficiência motora, pois permite pular links nos quais não estão interessados, evitando os pressionamentos de tecla necessários para visitar o conteúdo referenciado e, em seguida, retornar ao conteúdo atual.

Pessoas com limitações cognitivas não ficarão desorientadas por vários meios de navegação de e para conteúdos nos quais não estão interessados.

Pessoas com deficiência visual serão capazes de determinar a finalidade de um link explorando o contexto do link.

Como testar?
Localize links onde algum contexto de link adicional seja necessário para entender a finalidade do link. Para cada link:

1. Verifique se o texto do link descreve a finalidade do link

Resultados esperados
Seja verdadeiro!

# data[].attributes.headline
2.2.2 - Colocar em pausa, parar ou ocultar (Operável) [A]

# data[].attributes.subject
2.2.2 - Colocar em pausa, parar ou ocultar (Operável) [A]

# data[].attributes.body
Para informações que ficam em movimento (exemplos: pop-up de anúncios, componente carrossel com anúncios/banners, loading das telas) é necessário implementar "função" que permita pausar/despausar esses movimentos.

Conteúdo que comece automaticamente;

Dure mais que 5 segundos;

É apresentado paralelamente a outro conteúdo.

W3:
“Common time-based content” includes audio, automatically updated weather information, news, stock price updates, and auto-advancing presentations and messages.

WHO
Pessoas com déficit de atenção o conteúdo pode dificultar ou até mesmo impossibilitar a interação com o restante da página;

Exemplos na CWI:

Carrossel Pão de Açúcar que não tem a opção de pause

Carrossel das Casas Bahia são desativados para leitores de tela

# data[].attributes.headline
2.2.1 Ajustável por limite de tempo - A - Operável

# data[].attributes.subject
2.2.1 Ajustável por limite de tempo - A - Operável

# data[].attributes.body
Este critério visa garantir que os usuários com deficiência tenham tempo adequado para interagir com o conteúdo da Web (sempre que possível). Pessoas com deficiências, como cegueira, baixa visão, deficiências de destreza e limitações cognitivas, podem exigir mais tempo para ler o conteúdo ou realizar funções como preencher formulários online.

Exemplos:
Um exemplo muito comum onde vemos esse tempo para realizar determinada tarefa, são nos apps de bancos, onde a sessão tem um tempo limitado para controle de segurança.

Ou então, em jogos, onde os usuários possuem tempo para responder ou realizar determinada tarefa.

Sobre esses exemplos, a diretriz diz que sempre que possível e não interferir na regra de negócio, exista a possibilidade de prolongar a sessão quando ela está se encerrando, ou então que possa ser desativada antes do usuário iniciar.

https://www.ogcio.gov.hk/en/our_work/community/web_mobileapp_accessibility/promulgating_resources/handbook/wcag2a/8_12_timing_adjustable.html

https://compre2.voegol.com.br/Select2.aspx

Como testar esse critério:
O teste desse critério deve ser realizado de forma funcional.

# data[].attributes.attachment_link.readable_text
Ideally ensure processes on a website are not time dependent. If they are, ensure persons with disabilities can either adjust or stop the time limit so they can have enough time to complete their task.

Before Rectification

This example warns a person that time is about to expire.

After Rectification

A better approach is to allow the person to extend the time.
WCAG 2.0 Reference:
http://www.w3.org/TR/UNDERSTANDING-WCAG20/time-limits-required-behaviors.html

# data[].attributes.attachment_link.keywords[]
8.12 wcag 2.0 success criterion 2.2.1 − timing adjustable

# data[].attributes.attachment_link.title
OGCIO : 8.12 WCAG 2.0 Success Criterion 2.2.1 − Timing Adjustable

# data[].attributes.attachment_link.description
Ideally ensure processes on a website are not time dependent. If they are, ensure persons with disabilities can either adjust or stop the time limit so they can have enough time to complete their task. This example warns a person that time is about to expire.

# data[].attributes.headline
2.1.4 Atalhos de teclado por caractere - A - Operável

# data[].attributes.subject
2.1.4 Atalhos de teclado por caractere - A - Operável

# data[].attributes.body
O que é?
Quando atalhos de teclado forem implementados utilizando letras, pontuação, números ou caracteres de símbolos, é necessário que a função de ativar/desativar essa funcionalidade e remapear os caracteres possa ser feita utilizando somente o foco. A ideia é reduzir assim possíveis ativações dos atalhos de forma acidental e facilita a desativação dos atalhos para pessoas que utilizam recursos de voz

ex:
speech-input user named Kim has her cursor focus in the main window of a web mail application that uses common keyboard shortcuts to navigate ("k"), archive ("y") and mute messages ("m").

A coworker named Mike enters her office and says "Hey Kim" and her microphone picks that up. The Y of "hey" archives the current message. K in "Kim" moves down one conversation and M mutes a message or thread. And, if Kim looks up and says "Hey Mike" without remembering to turn off the microphone, the same three things happen in a different sequence.

# data[].attributes.headline
Requisito 1.4.1 - Utilização de cores - A - Perceptível

# data[].attributes.subject
Requisito 1.4.1 - Utilização de cores - A - Perceptível

# data[].attributes.body
Importante não se limitar apenas às cores para sinalizar algo na página ao:

transmitir uma informação

indicar uma ação

pedir uma resposta ao usuário

distinguir um elemento visual

Ou seja, fornecer as informações transmitidas com cores por outro meio visual garante que os usuários que não podem ver as cores ainda possam perceber as informações.

Exemplo:
Comportamento de erro, em um campo de input. O ideal é que a sinalização desse erro seja feita não apenas por cores, como circular o campo em vermelho, mas sim com algum ícone, negritando/ engrossando algum elemento, texto...

Outro exemplo seriam links que precisam ficar sublinhados ou em bold, além de ter um destaque significativo depois de serem clicados. Ainda a cor, quando utilizada, deve ter um contraste mínimo para textos de 4.5:1 e outros componentes de interface de 3:1 (**relacionando com os critérios 1.4.3 - Contraste (mínimo) [AA] e 1.4.11 - Contraste Não-Textual [AA])

Ferramentas de teste:

Validador WAVE que aponta onde existem problemas de contraste entre o fundo e o texto (além de apontar outros pontos relacionados diretrizes de acessibilidade);

Toptal que simula diversos tipos de deficiências cromáticas;

Colors que permite verificar o contraste entre as cores baseado nas diretrizes da W3C.

# data[].attributes.headline
Requisito 1.2.1 - Apenas áudio ou apenas vídeo (pré-gravado) - A - Perceptível

# data[].attributes.subject
Requisito 1.2.1 - Apenas áudio ou apenas vídeo (pré-gravado) - A - Perceptível

# data[].attributes.body
Onde vive? Do que se alimenta?

O objetivo desse critério é trazer uma alternativa aos conteúdos de apenas áudios (exemplo: podcast) ou vídeos (exemplo: vídeo institucional, tutoriais, animações GIFs, etc.) que são pré-gravados.

Não se trata de informar legenda, mas descrever o que está sendo apresentado
- É indicado utilizar texto para transcrição descritiva (ex.: Vídeo com metade de um círculo na cor roxa no rodapé com a chamada [...] No fundo, vai trocando as imagens. No primeiro frame, duas modelos femininas juntas [...]) e, no caso de vídeo, é possível também utilizar audiodescrição (quando, em um vídeo, existe um narrador que conta a cena).

# data[].attributes.headline
Requisito 1.3.3 - Características Sensoriais - A - Perceptível

# data[].attributes.subject
Requisito 1.3.3 - Características Sensoriais - A - Perceptível

# data[].attributes.body
Esse requisito diz que qualquer tipo de instrução ou direcionamento não devem depender apenas de uma característica (como formato, cor ou localização). A intensão dele é garantir que todos os usuários possam acessar as instruções, mesmo se não puderem perceber formas, tamanhos ou cores.

Exemplos:
Não deve-se utilizar instruções como: "Clique no botão abaixo para avançar", ou então "Preencha o campo ao lado". O ideal seria utilizar algo como "Utilize o ícone de seta verde colocado no canto inferior direito para ir para a próxima página".

Como testar esse critério?
Verificar em toda a tela ou página se na referência contém informações adicionais que permitem que o item seja localizado e identificado sem qualquer conhecimento de sua forma, tamanho ou posição relativa.

# data[].attributes.attachment_link.readable_text
Do not rely solely on sound, shape, size or visual location to provide instructions for understanding content. For example, if instructions say "to submit, click the button to the right" , a visually impaired person will not know where that button is.

Before Rectification

In the example above, it is only clear to a person who can see the webpage that he/she needs to click the green arrow. This will not be clear to a visually impaired person.

After Rectification

The correct way to do this is to label the button and ensure clear instructions are in place to tell people which button to use and how to use it.
WCAG 2.0 Reference: http://www.w3.org/TR/UNDERSTANDING-WCAG20/content-structure-separation-understanding.html

# data[].attributes.attachment_link.keywords[]
8.7 wcag 2.0 success criterion 1.3.3 − sensory characteristics

# data[].attributes.attachment_link.title
OGCIO : 8.7 WCAG 2.0 Success Criterion 1.3.3 − Sensory Characteristics

# data[].attributes.attachment_link.description
Do not rely solely on sound, shape, size or visual location to provide instructions for understanding content. For example, if instructions say "to submit, click the button to the right" , a visually impaired person will not know where that button is.

# data[].attributes.headline
Requisito 1.3.1 - Informações e Relações - A - Perceptível 

# data[].attributes.subject
Requisito 1.3.1 - Informações e Relações - A - Perceptível 

# data[].attributes.body
Esse requisito diz que a organização estrutural de uma tela deve ser construída de forma que sua arquitetura de informação faça sentido tanto para quem vê, quanto para quem ouve o conteúdo.

Ou seja, as páginas devem ter uma hierarquia de conteúdo e devem possuir semânticas, pois só assim os leitores de telas conseguem identificar o que é um titulo,  os textos abaixo do titulo, listas  ordenadas e não ordenadas, por exemplo. O código com semântica faz o leitor de tela interpretar e ler isso dando sentido ao conteúdo e fazendo o usuário entenda o que está escrito na tela. Quando a página não possuir semântica, usando apenas "divs", por exemplo, fica difícil para uma pessoa que utiliza leitores de tela saber qual é a hierarquia do conteúdo, pois sem a semântica o texto para o leitor fica linha embaixo da outra, não fazendo sentido para quem utiliza esse recurso.

Uma sugestão auditiva que o requisito traz é usar tonalidades de voz diferentes, velocidade da voz ou até mesmo tom de voz para que as pessoas que utilizam esse recurso possam entender e ter uma interpretação melhor do conteúdo que está sendo dito.

A seguir temos dois exemplo, um do código com semântica e outro sem semântica:

# data[].attributes.headline
Requisito 1.1.1 - Conteúdo não textual - A - Perceptível

# data[].attributes.subject
Requisito 1.1.1 - Conteúdo não textual - A - Perceptível

# data[].attributes.body
Esse requisito diz que qualquer conteúdo não textual (imagem, tabela, vídeo, áudio) dependendo da relevância para a compreensão do conteúdo, necessita de uma descrição alternativa em forma textual (seja ela visível ou não).

Exemplos:
Ícones: Se é um ícone utilizado para logar em um sistema, é necessário que ele tenha descrição, pois tem muita importância na utilização dessa página. Mas se for um ícone em um formulário, que está sendo usado para enfeite, não o descrevemos.

Imagens: Se for uma imagem meramente ilustrativa (mulher segurando um cartão na mão), não é necessário descrever. Porém quando ela tem maior importância, podendo ajudar a contextualizar a cena onde está inserido, a descrição é importante.

Vídeos e Tabelas: Não apenas nesses casos, mas em geral, é interessante fornecer um link com um conteúdo adjacente onde há uma descrição detalhada de todo conteúdo não textual.

Como testar esse critério?
Teste Funcional: testar se o ícone (como no exemplo dado) está apontando para o endereço correto, seguindo os padrões já utilizados hoje de teste.
Teste de Acessibilidade: fazendo uso de leitores de telas para garantir que conteúdos não textuais que tenham relevância no contexto da página, estejam descritos adequadamente.