Indicações e links de afiliados
Semana passada compartilhei uma lista de
5 livros para aprender acessibilidade no Instagram.
Dos cinco livros, eu escolheria para começar:
Acessibilidade na Web e
Gaia: Um Guia de Recomendações Sobre Design Digital Inclusivo para Pessoas com Autismo
Ontem, gravei um episódio para o podcast
Foco Acessível, foi uma conversa muita interessante, em breve estará disponível.
Também estou refazendo meu site com o Eleventy, a ideia de criar um site estático voltou com tudo.
Mas vamos ao que interessa.
Navegando essa semana, encontrei
um repositório no Github que usa critérios de aceites escritos em Gherkin.
Pessoalmente detesto Gherkin, mas isso é um assunto para outra carta.
O interessante dessa abordagem é:
- A clareza dos requisitos;
- Informações objetivas;
- Facilidade para descrever o comportamento;
- Previsibilidade do funcionamento do componente;
A W3C possui um site chamado
Authoring Pratices Guide (APG), ele é uma coletânea de componentes com todas as especificações de acessibilidade.
Por que isso importa? Esse guia ajuda muito, quando você estiver implementando e não tem muito domínio ou não sabe por onde começar.
Trouxe o componente
<button> para pensarmos em alguns cenários juntos.
Os cenários para esse componente são:
Funcionalidade: Interação e acessibilidade de botões
Como usuário de um site com componentes de botões
quero poder ativar os botões usando o teclado e entender seu estado
Para que eu possa interagir com o site de forma eficaz
Cenário: Ativar um botão
Dado que um botão está presente na página
Quando eu me concentro no botão
E pressiono “Enter” ou “Espaço”
Então o botão deve ser ativado
Cenário: Uso de um botão de alternância para um player de vídeo
Dado que um botão de alternância está presente no player de vídeo
Quando pressiono o botão de alternância
Então o estado aria-pressed do botão deve refletir seu estado atual
E o rótulo do botão de alternância não é alterado
Exemplos:
- Label do botão: ativar, estado: true;
- Label do botão: desativado, estado: false;
Dessa forma, fica muito mais claro testarmos os componentes, fazendo um pequeno exercício temos vários cenários que podemos testar.
No caso do Toggle Button, podemos validar:
- Verificar se o atributo aria-pressed existe no elemento;
- Verificar o estado inicial do aria-pressed tem o valor false;
- Verificar se o rótulo tem o valor de “Desativado” por padrão;
- Verificar quando pressionado, o aria-pressed mudar para true;
- Verificar quando pressionado, o rótulo muda para “Ativado”;
- Verificar quando desativar o botão, o estado deve retornar ao estado inicial.
Percebeu, como conseguimos extrair seis cenários de testes bem interessantes?
O mais legal é que você pode explorar e usar na sua stack preferida.
Garimpo da semana ⛏
Notícias interessantes
Projetos que vale a pena olhar 🧪
Curadoria de links 🔗