Questão de Arquitetura de Software — Acessibilidade de Software — FGV 2024
Arquitetura de Software›Acessibilidade de Software
Código
fg075813
Banca
FGV
Órgão
AL-TO
Ano
2024
Nível
Superior
Cargo
Analista Legislativo - Análise de Sistema
Um formulário para cadastro de usuários segue o guia de estilo da Web Content Accessibility Guidelines (WCAG).Assinale a implementação que está mais alinhada às diretrizes desse guia e aos princípios de usabilidade.
AUtilizar cores vibrantes nos botões de ação, sem considerar contraste mas incluir indicativos textuais para ação.
BEmpregar apenas ícones sem rótulos textuais nos botões, presumindo que a interpretação visual será universal.
CImplementar mensagens de erro para falhas de validação de campos, sem especificar o erro mas apenas como corrigi-lo.
DOmitir a implementação de atalhos de teclado, deixando apenas para usuários avançados que venham a ler anotações no manual, considerando que todos os usuários preferem navegar utilizando o mouse.
EAssegurar que os campos de formulário tenham rótulos claramente associados e mensagens de erro específicas que guiam o usuário na correção de entradas inválidas.
Revelar gabarito e comentário▾
GabaritoE — Assegurar que os campos de formulário tenham rótulos claramente associados e mensagens de erro específicas que guiam o usuário na correção de entradas inválidas.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Acessibilidade em Formulários – WCAG e Usabilidade
Gabarito: letra E. A alternativa que assegura rótulos claramente associados aos campos e mensagens de erro específicas que orientam a correção está alinhada aos critérios de sucesso da WCAG, como a identificação de erros (3.3.1) e a associação de labels (1.3.1). As demais alternativas violam princípios básicos de contraste, textos alternativos, descrição de erros e navegação por teclado.
A banca testa o conhecimento dos requisitos mínimos de acessibilidade para formulários, previstos em normas como a NBR 17225 (baseada na WCAG 2.2). Segundo a norma, formulários acessíveis exigem "label associado ao campo, indicação de obrigatoriedade sem depender apenas de cor, mensagem de erro próxima e vinculada ao campo, e foco direcionado para o erro quando necessário".
Alternativa
Descrição da implementação
Alinhamento com WCAG e usabilidade
Motivo da correção/incorreção
A
Utilizar cores vibrantes nos botões de ação, sem considerar contraste, mas incluir indicativos textuais para ação.
❌ Incorreta
Viola o critério de contraste mínimo (WCAG 1.4.3). Pessoas com baixa visão ou daltonismo podem não perceber os indicativos textuais se o fundo for insuficientemente contrastado.
B
Empregar apenas ícones sem rótulos textuais nos botões, presumindo que a interpretação visual será universal.
❌ Incorreta
Viola o princípio de texto alternativo (WCAG 1.1.1). Ícones não são universais; usuários de leitores de tela ou com deficiência cognitiva ficarão sem entender a função do botão.
C
Implementar mensagens de erro para falhas de validação de campos, sem especificar o erro, mas apenas como corrigi-lo.
❌ Incorreta
Viola a identificação de erros (WCAG 3.3.1). Sem saber qual entrada é inválida, o usuário não consegue entender o problema, especialmente em formulários com múltiplos campos.
D
Omitir a implementação de atalhos de teclado, deixando apenas para usuários avançados que venham a ler anotações no manual, considerando que todos os usuários preferem navegar utilizando o mouse.
❌ Incorreta
Viola a operabilidade por teclado (WCAG 2.1.1). Muitos usuários dependem exclusivamente do teclado para navegar.
E
Assegurar que os campos de formulário tenham rótulos claramente associados e mensagens de erro específicas que guiam o usuário na correção de entradas inválidas.
✅ Correta
Alinhada aos critérios de sucesso da WCAG: identificação de erros (3.3.1) e associação de labels (1.3.1). Atende aos requisitos mínimos de acessibilidade para formulários.
Formulário acessível (WCAG): Rótulos (Associados ao campo (1.3.1), Indicam obrigatoriedade sem só cor); Mensagens de erro (Específicas (3.3.1), Próximas ao campo, Foco direcionado ao erro); Contraste (Mínimo (1.4.3)); Texto alternativo (Ícones com rótulo (1.1.1)); Navegação por teclado (Operável (2.1.1))
Alternativa A — ❌ Incorreta
Utilizar cores vibrantes sem considerar contraste, mesmo com indicativos textuais, desrespeita o requisito de contraste mínimo (WCAG 1.4.3). Pessoas com baixa visão ou daltonismo podem não perceber os indicativos textuais se o fundo for insuficientemente contrastado. A norma exige contraste para garantir percepção.
Alternativa B — ❌ Incorreta
Empregar apenas ícones sem rótulos textuais fere o princípio de texto alternativo (WCAG 1.1.1). Ícones não são universais — usuários de leitores de tela, pessoas com deficiência cognitiva ou desconhecimento do significado do ícone ficarão sem entender a função do botão. É obrigatório associar um texto (rótulo visível ou oculto) a cada controle.
Alternativa C — ❌ Incorreta
Mensagens de erro que não especificam o erro, mas apenas como corrigi-lo são insuficientes. A WCAG 3.3.1 (Error Identification) exige que o erro seja identificado e descrito. Sem saber qual a entrada inválida (ex.: "campo obrigatório não preenchido" vs. "formato de e-mail inválido"), o usuário não consegue entender o problema, especialmente quando existem múltiplos campos.
Alternativa D — ❌ Incorreta
Omitir atalhos de teclado e deixar a navegação apenas por mouse viola o requisito de operabilidade por teclado (WCAG 2.1.1). Muitos usuários dependem exclusivamente do teclado (deficiência motora, usuários de leitores de tela). A norma classifica a interação por teclado como base da acessibilidade.
Alternativa E — ✅ Correta ⟵ GABARITO
"Assegurar que os campos de formulário tenham rótulos claramente associados e mensagens de erro específicas que guiam o usuário na correção de entradas inválidas" é a implementação correta. Os rótulos garantem a identificação dos campos (WCAG 1.3.1); as mensagens específicas cumprem a identificação e sugestão de erro (WCAG 3.3.1 e 3.3.3). A norma reforça: "formulário acessível é aquele em que campos são identificáveis, instruções são claras e erros são comunicados de modo compreensível e recuperável".
PEGA ESSA DICA!
Na prova, desconfie de alternativas que ignoram contraste, usam apenas ícones, omitem teclado ou dão mensagens de erro vagas. A WCAG prioriza perceptibilidade, operabilidade, compreensibilidade e robustez — a alternativa E atende às três primeiras.