Acessibilidade não é uma revisão final

Existe uma forma bastante comum de tratar acessibilidade em produtos digitais.

A interface fica pronta.

O fluxo funciona.

O desenvolvimento termina.

Então alguém faz uma revisão.

Contraste.

Labels.

Alt text.

Tabulação.

ARIA.

Algumas correções entram.

A aplicação melhora.

Mas existe um problema nesse processo.

Nem toda barreira de acessibilidade nasce no código.

Muitas começam muito antes.

Na escolha da interação.

Na hierarquia da informação.

Na forma como uma mensagem é escrita.

Na dependência de cor.

Na maneira como um fluxo exige precisão.

Na decisão de esconder algo até que alguém passe o mouse por cima.

Quando acessibilidade entra apenas no final, parte do trabalho deixa de ser melhoria.

Vira reparo.

Corrigir implementação é diferente de corrigir decisão

Alguns problemas realmente podem ser resolvidos durante a implementação.

Um campo sem label pode receber um.

Uma imagem informativa pode ganhar uma descrição adequada.

Um elemento pode ter o contraste ajustado.

Uma ordem de foco pode ser corrigida.

Tudo isso importa.

Mas imagine uma funcionalidade que depende exclusivamente de arrastar um elemento de um lado para outro.

Talvez consigamos adicionar atributos semânticos ao componente.

Ainda assim, a interação original pode continuar inacessível para quem não consegue realizar aquele gesto.

Ou uma informação importante pode aparecer apenas quando o usuário posiciona o cursor sobre um ícone.

Adicionar aria-label pode melhorar parte da experiência.

Mas talvez a pergunta mais importante seja anterior:

essa informação deveria depender de hover para existir?

É por isso que acessibilidade não pode ser reduzida a uma lista de atributos adicionados depois.

Alguns problemas são técnicos.

Outros são estruturais.

O cenário ideal também engana aqui

No segundo artigo desta série, falamos sobre como é fácil desenhar para o cenário em que tudo acontece como esperado.

Acessibilidade amplia ainda mais essa discussão.

Quando testamos uma interface apenas da forma como nós mesmos a utilizamos, assumimos uma série de condições sem perceber.

Conseguimos enxergar diferenças sutis de cor.

Usamos um mouse ou trackpad com precisão.

Lemos textos pequenos.

Interpretamos ícones rapidamente.

Conseguimos acompanhar animações.

Temos tempo para concluir uma tarefa antes que alguma coisa expire.

Sabemos onde clicar porque participamos da construção do produto.

Nenhuma dessas condições é universal.

A interface pode parecer óbvia para quem a criou e continuar impondo barreiras para outras pessoas.

Esse é um dos motivos pelos quais acessibilidade exige uma mudança de perspectiva.

Não se trata apenas de perguntar se o sistema funciona.

É perguntar:

para quem ele funciona?

Teclado revela muita coisa

Uma das formas mais simples de perceber problemas de interação é tentar usar uma aplicação sem mouse.

A experiência muda rapidamente.

Alguns elementos não recebem foco.

Outros recebem, mas não deixam claro onde ele está.

Menus abrem e não podem ser fechados.

Modais aparecem, mas o foco continua atrás deles.

A ordem de navegação não acompanha a ordem visual.

Componentes que parecem botões foram construídos com elementos que não possuem comportamento de botão.

Esses problemas são interessantes porque frequentemente revelam algo além da acessibilidade.

Eles mostram que a interface depende demais de uma forma específica de interação.

Uma navegação por teclado bem resolvida exige hierarquia.

Ordem.

Estado.

Comportamento previsível.

Ou seja, muitas decisões que também tornam o produto mais consistente para todos.

Semântica é mais do que HTML correto

Existe uma tendência de pensar em HTML semântico como questão de código limpo.

Usar button para botão.

nav para navegação.

main para conteúdo principal.

Headings em uma ordem coerente.

Isso realmente melhora a estrutura do código.

Mas a consequência mais importante aparece fora dele.

Tecnologias assistivas dependem dessa estrutura para entender o que existe na página.

Quando utilizamos uma div com evento de clique para representar um botão, visualmente podemos chegar ao mesmo resultado.

Para o navegador e para quem depende da semântica daquele elemento, não é a mesma coisa.

O problema não é simplesmente quebrar uma boa prática.

É remover informação.

Um elemento semântico carrega comportamento, significado e expectativas.

Recriar tudo manualmente quase sempre significa assumir responsabilidade por detalhes que o navegador já conhecia.

Às vezes precisamos de componentes customizados.

Mas complexidade visual não deveria automaticamente significar perda de semântica.

Cor não pode carregar uma mensagem sozinha

Considere um formulário.

Campos válidos recebem borda verde.

Campos inválidos recebem borda vermelha.

Visualmente, a diferença parece clara.

Mas a cor está carregando uma informação importante:

isso está certo ou errado.

Se essa diferença não puder ser percebida, a mensagem desaparece.

O mesmo acontece em gráficos.

Status.

Indicadores.

Alertas.

Estados de disponibilidade.

A solução não é abandonar cor.

Cor é uma ferramenta útil de comunicação.

O problema é fazê-la carregar todo o significado sozinha.

Podemos combinar cor com texto.

Ícones.

Labels.

Padrões.

Mudanças de forma.

Assim, a cor reforça a informação em vez de ser a única maneira de percebê-la.

Esse é um princípio pequeno, mas representa bem uma ideia maior:

interfaces robustas não dependem de uma única pista para serem compreendidas.

Contraste não é apenas um número

Contraste costuma ser uma das primeiras coisas lembradas quando falamos de acessibilidade.

E é importante.

Mas existe um risco de transformar o assunto em matemática isolada.

O valor passa na regra.

Então está resolvido.

Nem sempre.

Texto pequeno.

Fontes muito finas.

Elementos sobre imagens.

Estados desabilitados quase invisíveis.

Informações secundárias que acabam ficando secundárias demais.

Mesmo quando determinado valor atende ao limite esperado, ainda precisamos olhar para a experiência real.

A pergunta não é apenas se conseguimos atingir um número.

É se a informação continua legível no contexto em que aparece.

Critério técnico ajuda a estabelecer limites.

Não substitui julgamento.

Foco é parte do comportamento

Foco parece um detalhe visual até precisarmos depender dele.

Em interfaces interativas, ele responde a uma pergunta essencial:

onde estou agora?

Quando alguém utiliza teclado, leitor de tela ou outras formas de navegação, perder essa referência pode tornar uma interface inteira difícil de utilizar.

Abrimos um modal.

Para onde o foco vai?

Fechamos.

Para onde ele volta?

Uma validação encontra erro em um campo fora da área visível.

Como o usuário descobre?

Adicionamos conteúdo dinamicamente.

A pessoa precisa ser informada?

Essas perguntas não são resolvidas apenas escolhendo uma borda bonita para :focus.

Elas fazem parte do comportamento do fluxo.

Mais uma vez, acessibilidade toca diretamente em design e desenvolvimento ao mesmo tempo.

Copy também pode criar barreiras

O artigo anterior sobre copy mostrou como palavras ajudam usuários a entender o sistema.

Acessibilidade adiciona outra camada a essa discussão.

Textos podem ser visualmente legíveis e ainda assim difíceis de compreender.

Mensagens excessivamente técnicas.

Labels vagos.

Instruções que dependem de posição, como “clique no botão vermelho à direita”.

Links chamados apenas de “saiba mais”.

Erros que informam o problema, mas não dizem como corrigi-lo.

Tudo isso aumenta o esforço necessário para entender a interface.

E, dependendo de como o conteúdo é consumido, algumas dessas escolhas ficam ainda piores.

A linguagem faz parte da acessibilidade porque compreensão também faz parte do acesso.

Não basta conseguir chegar até a informação.

É preciso conseguir entendê-la.

Movimento também é uma decisão

Animações podem tornar uma interface mais clara.

Mostrar continuidade.

Explicar transições.

Reforçar relações entre elementos.

Criar feedback.

Mas movimento também pode causar desconforto ou dificultar a utilização para algumas pessoas.

Autoplay.

Parallax intenso.

Elementos piscando.

Transições excessivas.

Conteúdo que se move sem controle.

Esse é outro caso em que a solução não precisa ser “remover todas as animações”.

O ponto é considerar controle e preferência.

Se o sistema operacional informa que o usuário prefere movimento reduzido, a interface consegue respeitar isso?

Se um conteúdo começa automaticamente, existe forma de pausar?

A animação ajuda a compreender ou existe apenas porque parece interessante?

Acessibilidade não proíbe expressão visual.

Ela exige critério sobre as consequências dessa expressão.

Tempo também pode ser uma barreira

Nem toda barreira é visual ou motora.

Imagine um fluxo que expira rapidamente.

Uma sessão que termina enquanto alguém preenche um formulário longo.

Uma notificação que desaparece antes de ser lida.

Um código que precisa ser inserido em poucos segundos.

Talvez isso funcione perfeitamente para a maioria das pessoas.

Mas tempo também é uma restrição de interação.

Pessoas leem em ritmos diferentes.

Utilizam tecnologias diferentes.

Podem precisar navegar de maneira mais lenta.

Podem se distrair ou interromper a tarefa.

Isso não significa que nunca podemos ter limites de tempo.

Alguns contextos realmente exigem.

Segurança pode exigir.

Operações em tempo real podem exigir.

Mas o limite deveria existir por uma razão.

Não apenas porque foi mais simples implementar dessa forma.

Componentes acessíveis não garantem um produto acessível

Design systems ajudam muito.

Um botão acessível.

Um modal bem implementado.

Campos com semântica correta.

Componentes com estados bem definidos.

Tudo isso reduz repetição de problemas.

Mas existe uma armadilha.

Podemos ter componentes individualmente acessíveis e ainda construir um fluxo inacessível.

O modal funciona.

O formulário também.

Os botões também.

Mas a sequência exige informação que aparece apenas em outro lugar.

Ou existe excesso de etapas.

Ou as mensagens não fazem sentido.

Ou a hierarquia da página é confusa.

Acessibilidade não é apenas uma propriedade de componentes.

Também é uma propriedade da experiência criada quando eles são combinados.

Um design system pode criar uma base excelente.

Ainda precisamos tomar boas decisões sobre ela.

Automatização ajuda, mas não enxerga tudo

Ferramentas automáticas são úteis.

Linters.

Auditorias.

Testes.

Extensões.

Checks no pipeline.

Elas conseguem detectar muitos problemas que não deveríamos precisar encontrar manualmente todas as vezes.

Isso é ótimo.

Mas também existe um limite.

Uma ferramenta pode identificar que uma imagem não possui alt.

Ela dificilmente consegue decidir se aquela descrição realmente comunica o que importa.

Pode detectar contraste insuficiente.

Não necessariamente entende se a hierarquia visual faz sentido.

Pode identificar alguns problemas de semântica.

Não consegue navegar pelo produto com a intenção de alguém tentando concluir uma tarefa.

A automação encontra padrões.

Experiência exige contexto.

Uma não substitui a outra.

Testar com pessoas muda a discussão

Existe uma diferença enorme entre imaginar uma barreira e observar alguém encontrá-la.

Quando vemos uma pessoa navegar de uma forma diferente da nossa, algumas decisões que pareciam pequenas começam a ganhar peso.

Uma ordem de foco estranha deixa de ser detalhe técnico.

Um label ruim deixa de ser uma escolha de texto.

Uma interação escondida deixa de ser apenas um padrão visual.

Ela se torna uma tarefa que alguém não conseguiu concluir.

Esse contato muda a qualidade da discussão porque tira acessibilidade do campo abstrato.

Deixa de ser “atender uma regra”.

Passa a ser permitir que uma pessoa utilize o produto.

Nem todo time terá acesso contínuo a pesquisas específicas.

Ainda assim, buscar feedback real sempre que possível produz um tipo de informação que uma checklist nunca entrega.

Existe custo em considerar acessibilidade cedo

É importante reconhecer o trade-off.

Pensar em acessibilidade desde o início exige atenção.

Pode exigir pesquisa.

Pode mudar uma interação que parecia pronta.

Pode aumentar o tempo de implementação de determinado componente.

Pode exigir que design e engenharia discutam detalhes que seriam ignorados em outro processo.

Isso existe.

Mas existe um custo do outro lado também.

Corrigir depois pode significar reconstruir componentes.

Refazer fluxos.

Alterar estruturas já utilizadas em dezenas de lugares.

Reescrever conteúdo.

Mudar padrões consolidados no design system.

O problema não desaparece porque adiamos a decisão.

Só muda o momento em que pagamos por ela.

E normalmente corrigir estrutura custa mais do que considerar restrições enquanto ela ainda está sendo definida.

Nem tudo será perfeito na primeira versão

Também precisamos evitar transformar acessibilidade em uma condição impossível de começar.

Produtos reais têm dívida.

Sistemas antigos possuem limitações.

Times trabalham com prazo.

Nem toda barreira poderá ser resolvida imediatamente.

Reconhecer isso não significa abandonar o objetivo.

Significa priorizar.

Fluxos críticos.

Problemas que bloqueiam tarefas.

Componentes amplamente utilizados.

Barreiras com maior impacto.

Uma abordagem incremental pode ser muito melhor do que esperar o momento em que conseguiremos “tornar tudo acessível” de uma vez.

Esse momento provavelmente nunca chega.

A maturidade está em transformar acessibilidade em parte do processo contínuo, não em uma campanha pontual.

Acessibilidade melhora a forma como pensamos

Talvez uma das coisas mais interessantes sobre acessibilidade seja que ela obriga o produto a responder perguntas melhores.

Essa interação depende demais de uma forma específica de uso?

A informação está realmente clara?

Existe outra maneira de concluir essa tarefa?

O sistema comunica estado suficientemente bem?

A hierarquia faz sentido?

Estamos assumindo alguma capacidade que não precisava ser obrigatória?

Essas perguntas ajudam pessoas com diferentes necessidades.

Mas frequentemente produzem interfaces melhores de maneira geral.

Não porque acessibilidade seja uma técnica secreta de UX.

Mas porque ela força o sistema a ser mais explícito, previsível e flexível.

Características que quase sempre melhoram uma interface.

Indo além da criação

É fácil adicionar acessibilidade a uma lista de coisas para revisar antes do lançamento.

Testar contraste.

Revisar teclado.

Executar uma auditoria.

Corrigir alguns atributos.

Esse trabalho tem valor.

Mas ele representa apenas uma parte.

Acessibilidade começa quando decidimos como algo será utilizado.

Quando escolhemos a interação.

Quando estruturamos conteúdo.

Quando definimos estados.

Quando pensamos em feedback.

Quando escolhemos aquilo que será obrigatório para concluir uma tarefa.

Nesse ponto, ela deixa de ser uma camada aplicada sobre uma interface pronta.

Passa a participar da própria construção.

Porque algumas barreiras podem ser corrigidas no final.

Outras já estarão embutidas nas decisões que tomamos no começo.

Acessibilidade não é o que adicionamos depois que a interface funciona.

É uma das coisas que definem para quem ela realmente funciona.