A importância do foco visível para a acessibilidade digital
Há diversas coisas a se pensar em acessibilidade, mas definitivamente o foco visível é um dos erros mais comuns e também um dos mais simples de se resolver.
Faça um teste rápido enquanto navega em seu site preferido, esqueça o mouse por um instante e navegue por teclado. Não sabe como fazer? Dependendo dos elementos em tela, os controles podem ser complexos e este artigo da WebAIM pode te ajudar a entender melhor como navegar com teclado caso nunca tenha feito isso, mas os comandos básicos são a tecla TAB (para mover o foco para o próximo elemento) e SHIFT+TAB (para mover o foco para o elemento anterior).
É importante ressaltar que a navegação padrão se dá por elementos clicáveis, como links, botões ou controles de formulários. Alguns outros elementos também podem receber foco, mas isso será papo para um outro artigo, hoje a ideia é dar ênfase no foco visível que ocorre de maneira natural, ou seja, em itens clicáveis.
Se tudo estiver certo, você perceberá um contorno azulado em volta dos elementos clicáveis, mais ou menos parecido com isso:
Pausa para um disclaimer aqui: É importante ressaltar que há uma diferença por quem navega por teclado e enxerga o conteúdo e quem navega por teclado e não enxerga o conteúdo. Este artigo trata especialmente do primeiro caso, de quem está enxergando o conteúdo. A Léonie Watson tem um artigo bem completo falando sobre as diferentes formas de se navegar por teclado.
Mas isso acontece apenas se tudo estiver certo, por que infelizmente, muitos designers removem essa borda simplesmente por a acharem esteticamente "feia". As vezes a culpa não é do designer, é verdade, e alguém (qualquer) da equipe pede a remoção da tal borda. Fato é que as pessoas a removem por apenas dois motivos: "estética" ou "ignorância total da acessibilidade".
É relativamente fácil enumerar alguns casos de uso em que essa "borda" é importante:
- Pessoas com baixa visão que fazem uso de leitores de tela e navegam por teclado;
- Pessoas com deficiências cognitivas ou dificuldade em aprendizagem que precisam ter atenção e visualizar o foco do elemento ativo;
- Pessoas com algum tipo de deficiência motora com dificuldades em usar um mouse;
- Pessoas que não possuem nenhum controle manual ou mesmo que não possuem as mãos e navegam através de diferentes tipos de tecnologia assistiva;
- Pessoas que fazem uso de teclados especiais para navegação;
- Pessoas que podem não ter um mouse disponível no momento (falta de pilhas, por exemplo);
- Pessoas que preferem usar o teclado para algumas situações (navegar por um formulário com muitos campos de preenchimento).
Caso ainda não tenha percebido, estamos falando de navegação através de um teclado (não necessariamente com um leitor de telas ativado). Trata-se do design de interação através do uso de outros métodos diferentes do que um mouse.
Enfim, não é difícil perceber a importância dessa borda em torno dos elementos ativos em tela. Pra ficar mais claro ainda, imagine que o ponteiro do seu mouse é o seu feedback visual enquanto rola ele pela tela. Quando se passa o mouse em cima de links ou botões, há outro tipo de feedback, que é o que chamamos de estado "hover", mas e quando se navega por teclado? Qual é o feedback visual que a pessoa tem? Exato! A tal da borda, cujo nome correto é "foco visível" e ele ocorre justamente quando o elemento é focado via teclado.
Um site que sempre recomendo sobre essa questão é o outlinenone.com que possui algumas informações técnicas de como remover a borda, do porquê não fazer isso e como customizar o elemento.
Este tuíte do Denis Boudreau vai direto ao ponto dessa questão (ele menciona que ao remover o "outline: none" do arquivo de CSS de seu site, cerca de 40% dos problemas de acessibilidade pra quem usa o teclado, se resolverão "automaticamente").
É sobre a customização do foco visível que quero dar maior atenção neste artigo, justamente por ter contato com muitas pessoas envolvidas com o desenvolvimento de sites, percebo que boa parte delas sequer sabem da possibilidade da customização da "tal da borda" e daí acabam tomando a decisão de remove-la por fatores estéticos.
Esse é um dos motivos que eu sempre digo que designers de sites precisam conhecer HTML e CSS para no mínimo saber o que podem ou não fazer… e não adianta perguntar pro desenvolvedor diretamente, pois a maioria também desconhece as propriedades do CSS pelo simples motivo de ser algo relacionado ao visual. Exemplo: Posso utilizar uma borda tracejada em torno de um botão para representar o foco visível, isso é feito diretamente no CSS, se o designer não souber dessa possibilidade é pouco provável que o desenvolvedor saiba também, pois ele não pesquisa os recursos visuais da linguagem… CSS é linguagem de designer! Envolve características como espaçamentos, formatos, medidas, cores, transições, animações, etc. Os maiores conflitos entre desenvolvedor e designer ocorrem pela falta de comunicação (e também conhecimento). Brad Frost que o diga neste artigo.
Customizando o foco visível
Antes de falar de customização, vamos falar de como é o padrão de cada browser. E ao invés de printar elementos em todos os browsers, vou deixar esse tuíte aqui do Mikael Ainalem em que ele comenta uma recente atualização do Safari onde ocorreram ajustes nos focos padronizados pra que eles se adequassem a forma dos elementos, como no caso do botão demonstrado na mensagem dele:
Pra ser honesto, não vejo vantagens nisso no momento atual, pois hoje podemos customizar essa interação, no entanto é importante reforçar que cada browser tem as suas próprias características e as empresas que os criam também pensam em melhorias de seus produtos no que tange a acessibilidade.
Levando isso em consideração, vale lembrar que nem sempre a opção "padrão", será a melhor em alguns casos e o foco visível é um exemplo claro dessa questão. Em todos os projetos que participei, no momento que o foco visível foi discutido não houve uma única ocasião em que alguém não tenha sugerido uma customização visual, justamente pelo foco se comportar diferente em browsers diferentes ou ele não ter contraste suficiente em alguns casos.
Foco customizado em botões e links
A customização em si fica a critério de cada um, pois ela deve ser feita de acordo com a identidade visual de seu projeto, o abaixo demonstra botões diferentes na cor laranja utilizados no Manual de Acessibilidade construído internamente no Itaú e que oferece suporte sobre o tema para diferentes times.
Neste exemplo, demonstro a utilização da mudança de cor dos botões e a inclusão de uma borda tracejada em um tom altamente contrastante (escuro) e uma espessura de 2px (guarde essa informação, que será explicada depois).
As animações abaixo demonstram o funcionamento dos estados (hover, por mouse, quando o ponteiro está por cima do elemento) e (foco, por teclado):
Como podem perceber, neste caso eu deixei a mesma interação para ambos os estados (hover ou foco), o que não é uma obrigação e como falei anteriormente vai depender da identidade visual de seu projeto e como você quer trabalhar com os diferentes estados de interação.
No caso deste manual, optei por utilizar o mesmo formato para ambos os estados também nos links distribuídos entre as páginas:
Mas é possível deixar cada estado com uma interação diferente. E eu fiz isso no site com os Princípios do Design Inclusivo, exemplificado nessa animação:
Perceba que quando uso um mouse, opto pela mudança de cor de fundo do link ativo no momento e quando uso a navegação por teclado, deixo apenas a borda customizada com uma borda de 2px, um tom de azul contrastante e uma microanimação para dar ênfase e destacar o elemento selecionado.
Outro exemplo que posso dar ainda em links, mas dessa vez levando em consideração um menu superior de navegação é o que utilizo no Guia WCAG, como demonstrado nessa animação:
Neste caso, optei também pela mesma interação para ambos os estados, seja no uso de mouse, seja no uso de teclado. Em ambos os casos há uma borda azul de 2px em alto contraste com a cor de fundo. Neste caso a diferença ocorre devido a natureza dos elementos demonstrados: menu de navegação no topo e link entre textos na página. Perceba que o espaçamento dado para o menu foi muito maior e isso foi proposital para dar ênfase visual.
Foco customizado em formulários
Outra questão relacionada a navegação por teclado é a customização do foco em itens de formulário e aqui também vale a regra da customização de acordo com a identidade visual do seu projeto. Tecnicamente falando é também mais complicada dependendo do nível de interação que se deseja atingir, mas é importante saber que também é possível ser realizada em qualquer situação.
Esses dois exemplos abaixo estão no Guia WCAG e eles demonstram um elemento de checkbox e um campo de input text, respectivamente.
Neste caso, a interação com o foco pode ser realizada apenas através do foco, no entanto você pode criar a interação através do "mouse over" também (isso é opcional). No caso do Guia WCAG, eu optei por fazer isso.
Acredito que um bom exemplo de interação por teclado em formulários são os apresentados na biblioteca de componentes do Angular do Google para o Material Design, listo abaixo alguns desses exemplos:
Campos de input text e textarea
Neste exemplo, perceba a movimentação do mouse e a navegação por teclado (quando o ponteiro não está por cima) e o seu comportamento exatamente igual para ambos os casos de interação. Sacou que a linha de digitação salta de 1px para 2px após o foco no elemento? Guarde essa informação também, que já comento sobre isso… Em tempo, a opção pelo uso de "float labels" neste caso não impacta na acessibilidade, desde é claro, que seja corretamente implementada (consulte a documentação do material design). ;)
Radio Button
Já no caso de Radio Buttons, há uma ligeira diferença de interação entre os elementos, quando se passa o mouse por eles é possível perceber uma pequena mudança na cor de fundo do elemento (cinza claro, gerando um feedback visual). O que não ocorre quando se navega por teclado, uma vez que o elemento é selecionado diretamente neste caso. Não há impacto de níveis de contrastes também, pois o que define se o elemento está ou não ativo, não é essa "pequena interação" com o mouse. Por fim, a navegação entre itens em um mesmo grupo de Radio Buttons se dá por "setas direcionais" e não por TAB (é importante entender o comportamento de interação, para que isso não gere "falsos positivos" em testes de acessibilidade).
Checkbox
No caso de Checkboxes, há também uma ligeira diferença de interação entre os estados de hover e foco. Bem parecida com o caso do Radio Button, mas neste caso a diferença principal está na navegação por teclado que ao dar foco no elemento, ele não é selecionado diretamente (o Radio Button, sim) e neste caso a seleção é efetuada através do uso da barra de espaço. Só a partir daí é que o elemento muda o tom de cor para que seja possível identificar o seu status (habilitado ou não).
Slider (pra citar apenas um caso de elemento de formulário complexo)
Existe alguns elementos com interações de teclado complexas em formulários e um deles sem dúvida é o slider (não vou entrar no escopo do que é preciso ter em um slider acessível nesse momento, vou me ater ao básico de navegação por teclado). Perceba no exemplo acima que a interação também é ligeiramente diferente entre o uso de mouse (quando o ponteiro está por cima do elemento) e teclado. A navegação por teclado, neste caso, também se dá por setas direcionais, mas é importante perceber que quando se navega por teclado, os feedbacks visuais também são tão importantes quanto.
"Aspecto visual" versus "Aspecto aural"
Diante de todos esses exemplos apresentados, vale lembrar que tudo o que estou falando até aqui é com relação a uma interação VISUAL! Não estou entrando no mérito do uso de leitores de tela e os feedbacks essenciais e necessário para cada uma das situações anteriormente apresentadas.
Farei isso em uma segunda parte deste artigo em breve, com foco exclusivamente no aspecto aural das informações, mas isso é válido para perceberem que a acessibilidade completa em produtos digitais é aplicada tanto em aspectos visuais quanto em aspectos aurais.
E pra mobile? Essa customização funciona também em dispositivos móveis (celular, tablet)?
É importante entender que o comportamento do foco visível em mobile é diferente do que ocorre em desktop. Isso por que, por padrão, o foco visível em mobile surge apenas quando um leitor de telas (VoiceOver ou Talkback) está ativado e isso está relacionado a uma série de questões que vão desde ao tamanho da tela disponível ao comportamento de interação por toque.
Apesar de eu não recomendar a customização dos elementos para este caso em especial, saiba que caso você precise, é possível sim customizar esses elementos tanto em iOS quanto em Android. O guia da BBC focado em produtos acessíveis, faz menção a isso.
Do ponto de vista de interação e seu relacionamento com a WCAG, a W3C cita como relacionar as diretrizes em ambientes móveis em um guia e há uma sessão específica sobre o uso de teclado físico em dispositivos móveis (sim, algum usuário pode conectar um teclado bluetooth aos aparelhos por alguma necessidade específica também).
Falando em WCAG, como relaciono todos esses aspectos as diretrizes de acessibilidade?
Agora sim chegamos a parte técnica e mais interessante do artigo, que foi o que me motivou a escrever este texto. A versão atual da WCAG é a versão 2.1 e há uma nova versão estrutural das diretrizes a ser lançada em breve (sem data ainda), no entanto, o grupo de trabalho atua paralelamente para atualizar da melhor forma possível as diretrizes atuais sem que haja um grande espaço de tempo entre novas atualizações.
Com isso, no último rascunho (draft) apresentado pelo grupo de trabalho em 05 de março de 2020, houve a inclusão de um novo critério (ainda em rascunho, o que significa que ainda está sendo discutido, mas bom o suficiente para já ser utilizado por todos) que está relacionado ao foco visível:
Este critério está diretamente relacionado ao já existente 2.4.7 (Foco Visível) Nível A, e ele não cria nada novo, mas apenas reforça algumas questões que já deveriam ser levadas em consideração com o critério anterior, mas que no entanto sempre eram casos de discussões eternas justamente pelas pessoas envolvidas não saberem o que necessariamente era preciso se levar em consideração.
O critério define alguns padrões para que se tenha um foco visível verdadeiramente útil e são esses:
- Área mínima: A área de indicação do foco precisa ser igual ou maior do que 2x a largura do lado mais longo do elemento. Confuso? Peraí que já explico… ;)
- Contraste do foco: As cores utilizadas na alternância do foco (focado ou não focado) deve ter uma relação mínima de contraste de 3:1. Ou seja, segue-se o padrão já estabelecido para níveis de constraste em diretrizes já existentes.
- Contraste da espessura: A cor utilizada para a apresentação do foco visível (a borda) deve ter uma relação mínima de contraste de 3:1 com áreas adjacentes ao elemento ou pele menos 2px de largura (isso explica os 2px dos elementos de exemplo acima apresentados).
Lá vem aula de matemática…
Agora senta pra aula de matemática que a conta é simples, mas fácil de ser mal interpretada… :) Vamos falar sobre a questão da "área mínima" para se definir o tamanho de um foco verdadeiramente útil, porém para entendermos esse relacionamento é importante compreender a lógica por trás disso tudo…
Qualquer critério da WCAG sempre leva em consideração duas medidas relativas. Pontos (ou PT, que muitos confundem com PX) e CSS Pixel. Neste artigo vamos falar apenas do segundo.
Um Pixel CSS ou “pixel de referência” é uma unidade de medida canônica para qualquer comprimento ou medida em CSS. Essa unidade independe da densidade de pixels reais das telas dos devices, ou seja, é o próprio ambiente que faz os cálculos de adaptação necessários para a respectiva tela do device. O pixel de referência equivale ao ângulo de visão da distância do olho para um determinado device, mais precisamente a distância de um braço (28 polegadas ou 71cm), o que corresponde a 0,26mm para o tamanho de 1 pixel (e isso vai aumentando conforme se aumenta a distância).
É um pouco confuso, mas tudo faz sentido quando se compreende as diferentes unidades de medidas e seus relacionamentos. Caso queira se aprofundar ainda mais no tema, comece pela documentação de unidades de medidas do W3C.
Agora que sabemos o que originou esse papo, podemos entender o relacionamento com o que seria válido para se atender ao foco visível relacionado a área mínima dos componentes em tela.
Segundo o critério 2.4.11 da WCAG, para se determinar uma área mínima que determina um foco válido e útil é preciso se basear no tamanho do elemento. A área de foco deve representar o tamanho (em pixels quadrados) de 2x a maior largura do elemento. Ou seja, se um elemento possui 90 x 30px, a marcação do foco visível útil deverá ser 180px quadrados, que equivale 2x o tamanho da maior largura que é de 90px. Fácil, não? :)
Elaborei esse diagrama aqui pra ficar o mais claro possível a forma de se chegar ao resultado… :)
Imaginem um botão rosa de 90 x 30px…
A grande questão é que você não precisa fazer todas essas contas e o exemplo acima extrapola propositalmente a questão. Oque acabei de demonstrar é a teoria, o cálculo e o objetivo em se medir essas informações. O designer que tem um olhar atento aos detalhes, saberá criar alternativas de uma forma muito simples (e visual) que contemplará todas as situações…
Quer exemplos?
Esses aqui foram retirados diretamente da página do novo critério de sucesso (que vale lembrar, ainda está sendo definido):
Perceba que não há uma regra para o foco visível, há sim uma boa prática em se seguir os padrões convencionais visando o correto atendimento da usabilidade (heurísticas, né?), mas o designer não está limitado a isso. Aqui deixo claro que uma das maiores reclamações dos designers, que é o fato da "acessibilidade limitar a criatividade", cai por terra! Ou seja, você pode ser bem criativo, a questão é… você precisa ser criativo aqui? ;)
Mas e se a forma dos elementos forem específicas, como uma bola ou uma estrela?
Tudo foi pensado no critério de sucesso e há variações para esses exemplos também…
Enfim, é importante saber que ACESSIBILIDADE NÃO LIMITA A CRIATIVIDADE! Seja criativo, desde que você siga alguns padrões, consistências e evoluções para pensar verdadeiramente em um design inclusivo.
Entenda que os critérios da WCAG não funcionam sozinhos…
Pra finalizar este artigo e todos esses exemplos, compreenda de uma vez por todas que nenhum critério de sucesso da WCAG funciona sozinho. Ele sempre será relacionado a algum outro existente e mais importante ainda, nenhum deles é tão complicado a ponto de que não possa ser explicado de uma forma didática, mesmo que se use um textão pra isso… ;)
Esses são os critérios de sucesso da WCAG, relacionados a questão do foco visível, que também precisam ser contemplados:
- 1.3.2 (Sequência com significado) [nível A]: A ordem de leitura e a navegação pelos componentes em tela deve fazer sentido para o usuário.
- 1.4.3 (Contraste-mínimo) [nível AA]: Textos devem ter uma relação de contraste* entre primeiro e segundo plano de ao menos 4.5:1.
- 1.4.6 (Contraste-melhorado) [nível AAA]: Textos devem ter uma relação de contraste* entre primeiro e segundo plano de ao menos 7:1.
- 1.4.11 (Contraste não-textual) [nível AA]: Componentes de interface e imagens essenciais para o entendimento do conteúdo devem ter uma relação de contraste entre primeiro e segundo plano de ao menos 3:1.
- 2.1.1 (Teclado) [nível A]: Toda funcionalidade deve estar disponível para utilização com teclado, a menos que a funcionalidade não possibilite o controle apenas por teclado.
- 2.1.2 (Sem bloqueio de teclado) [nível A]: Deve ser possível navegar de e para todos os elementos sem qualquer tipo de bloqueio de teclado.
- 2.1.3 (Teclado-sem exceção) [nível AAA]: Toda funcionalidade deve estar disponível para utilização com teclado.
- 2.4.3 (Ordem do foco) [nível A]: A navegação (através de um teclado) por elementos focáveis em tela deve ser sequencial e lógica de acordo com o conteúdo apresentado.
- 2.4.7 (Foco visível) [nível A]: Ao se navegar por teclado (ou toque) deve ser possível identificar visualmente e facilmente qual elemento da página ou tela tem o foco no momento.
- 2.4.11 (Foco visível-melhorado) [nível AA] — DRAFT (o critério que originou este material): Sempre que o foco visível for exibido, será preciso ter um espaçamento mínimo entre ele e o conteúdo e o relacionamento de contraste com áreas adjacentes precisa ser suficiente.
Lembrando mais uma vez que não estamos entrando ainda no mérito do uso de leitores de tela, ok? Esses critérios e ajustes referem-se ao que se precisa ser feito do ponto de vista visual. Todos os 78 critérios podem ser consultados no Guia WCAG.
E pra finalizar este artigo, alguns sites com bons exemplos de FOCO VISÍVEL para que vocês possam se inspirar a criar os próprios (lembrem-se de testar através de um teclado):
Você tem algum outro bom exemplo? Comente este artigo… :)
Está procurando por algum curso de acessibilidade?
Quer aprender como efetuar o planejamento de acessibilidade na sua empresa? Como aplicar e envolver todos na equipe (do estagiário ao product manager)? Como especificar e gerar documentações? Ou como dar foco no design como escrito neste artigo? Então conheça o curso que ministro na Mergo. Verifique as turmas disponíveis e o programa completo no site e se tiver dúvidas, comente aqui.
Me chamo Marcelo Sales, sou designer focado 100% em acessibilidade. Estudo o tema desde 2012, desenvolvo ferramentas de apoio e além daqui no Medium, você me encontra também no Twitter, no Instagram e no LinkedIn! ;)
