4.1.2 Nome, Função, Valor

Intenção

A intenção deste Critério de Sucesso é garantir que as Tecnologias Assistivas (AT) possam coletar informações sobre, ativar (ou definir) e manter-se atualizado sobre o status dos controles da interface do usuário no conteúdo.

Quando controles padrão de tecnologias acessíveis são usados, esse processo é direto. Se os elementos da interface do usuário forem usados ​​de acordo com a especificação, as condições desta disposição serão atendidas. (Ver exemplos do Critério de Sucesso 4.1.2 abaixo)

Sinais auditivos também podem ser usados. Por exemplo, um carrilhão pode indicar o início de uma nova seção; uma mudança no tom de voz ou velocidade da fala pode ser usada para enfatizar informações importantes ou para indicar o texto citado; etc.

No entanto, se controles personalizados forem criados ou elementos de interface forem programados (em código ou script) para ter um papel e/ou função diferente do normal, medidas adicionais precisam ser tomadas para garantir que os controles forneçam informações importantes para tecnologias assistivas e permitem-se ser controlados por tecnologias assistivas.

Um estado particularmente importante de um controle de interface do usuário é se ele tem ou não foco. O estado de foco de um controle pode ser determinado programaticamente e notificações sobre mudança de foco são enviadas para agentes de usuário e tecnologia assistiva. Outros exemplos de estado de controle da interface do usuário são se uma caixa de seleção ou botão de opção foi selecionado ou não, ou se uma árvore recolhível ou nó de lista foi expandido ou recolhido.

Benefícios

Exemplos

1. APIs acessíveis

Um applet Java usa a API de acessibilidade definida pela linguagem. Recursos Relacionados

Técnicas

Cada item numerado nesta seção representa uma técnica ou combinação de técnicas que o Grupo de Trabalho WCAG considera suficiente para atender a este Critério de Sucesso. No entanto, não é necessário usar essas técnicas específicas. Para obter informações sobre o uso de outras técnicas, consulte Compreendendo as técnicas dos critérios de sucesso WCAG, particularmente a seção "Outras técnicas".

Técnicas suficientes

Selecione a situação abaixo que corresponde ao seu conteúdo. Cada situação inclui técnicas ou combinações de técnicas que são conhecidas e documentadas como sendo suficientes para aquela situação.

Situação A: Se estiver usando um componente de interface de usuário padrão em uma linguagem de marcação (por exemplo, HTML):
ARIA14: Usando aria-label para fornecer um rótulo invisível onde um rótulo visível não pode ser usado
ARIA16: Usando aria-labelledby para fornecer um nome para os controles da interface do usuário

G108: Usar recursos de marcação para expor o nome e a função, permitir que as propriedades configuráveis ​​pelo usuário sejam definidas diretamente e fornecer notificação de alterações usando técnicas específicas de tecnologia abaixo:
• H91: Usando controles e links de formulário HTML • H44: Uso de elementos de rótulo para associar rótulos de texto a controles de formulário • H64: Usando o atributo title do elemento iframe • H65: Uso do atributo title para identificar controles de formulário quando o elemento label não pode ser utilizado • H88: Usando HTML de acordo com as especificações

Situação B: Se estiver usando script ou código para redirecionar um componente de interface de usuário padrão em uma linguagem de marcação:
Expondo os nomes e as funções, permitindo que as propriedades configuráveis ​​pelo usuário sejam definidas diretamente e fornecendo notificação de alterações usando uma das seguintes técnicas:
ARIA16: Usando aria-labelledby para fornecer um nome para os controles da interface do usuário

Situação C: Se estiver usando um componente de interface de usuário padrão em uma tecnologia de programação:
G135: Usar os recursos da API de acessibilidade de uma tecnologia para expor nomes e notificar alterações usando as técnicas específicas da tecnologia abaixo:
• PDF10: fornecendo rótulos para controles de formulário interativos em documentos PDF
• PDF12: fornecendo nome, função e informações de valor para campos de formulário em documentos PDF

Situação D: Se estiver criando seu próprio componente de interface de usuário em uma linguagem de programação:
G10: Criar componentes usando uma tecnologia que suporte a notificação de acessibilidade de alterações usando as técnicas específicas da tecnologia abaixo:
• ARIA4: Usando uma função WAI-ARIA para expor a função de um componente de interface do usuário
• ARIA5: Usando o estado WAI-ARIA e os atributos de propriedade para expor o estado de um componente da interface do usuário
• ARIA16: Usando aria-labelledby para fornecer um nome para os controles da interface do usuário

Formas de Implementação

As formas de se atingir os critérios de sucesso são diversas e variam de acordo com o contexto e as características do seu projeto. Para te ajudar durante o desenvolvimento das suas interfaces, selecione qual tipo de situação mais se adequa ao seu projeto.

Você poderá gerar uma documentação contendo todas as informações sobre as técnicas, de todos os critérios que você escolher implementar em suas telas, para te guiar com mais facilidade durante o andamento do projeto.

Falhas

A seguir estão erros comuns que são considerados falhas deste Critério de Sucesso pelo Grupo de Trabalho WCAG:

F59: Falha no Critério de Sucesso 4.1.2 devido ao uso de script para fazer div ou expandir um controle de interface do usuário em HTML sem fornecer uma função para o controle
F15: Falha no Critério de Sucesso 4.1.2 devido à implementação de controles personalizados que não usam uma API de acessibilidade para a tecnologia ou o fazem de forma incompleta
F20: Falha do Critério de Sucesso 1.1.1 e 4.1.2 devido à não atualização de alternativas de texto quando ocorrem alterações em conteúdo não textual
F68: Falha do Critério de Sucesso 4.1.2 devido a um controle de interface do usuário não ter um nome determinado programaticamente
F79: Falha do Critério de Sucesso 4.1.2 devido ao estado de foco de um componente de interface do usuário não ser determinável programaticamente ou nenhuma notificação de mudança de estado de foco disponível
F86: Falha no Critério de Sucesso 4.1.2 devido ao não fornecimento de nomes para cada parte de um campo de formulário com várias partes, como um número de telefone dos EUA
F89: Falha nos Critérios de Sucesso 2.4.4, 2.4.9 e 4.1.2 devido ao não fornecimento de um nome acessível para uma imagem que é o único conteúdo em um link

Outros recursos

Os recursos são apenas para fins informativos, sem endosso implícito:
• Roteiro de Conteúdo da Web Acessível Dinâmico
• Taxonomia de papéis para aplicativos adaptáveis ​​acessíveis
• Módulo de Estados e Propriedades Adaptáveis
• Acessibilidade ativa da Microsoft, versão 2.0

Créditos

O conteúdo desta página foi originalmente desenvolvido pelos participantes do Grupo de Trabalho de Diretrizes de Acessibilidade (AG WG) como parte dos projetos WAI-Core financiados por fundos federais dos EUA.

A interface do usuário e a tradução livre do conteúdo foram feitas pelos alunos: Lucas Almeida, Mayara Viana, Milena Ferreira, Roberta Manfredini e Paulo Serpa, na disciplina de Acessibilidade Digital, ministrada pelo Prof. Dr. Edson Rufino de Souza