Como documentar definições de design para acessibilidade
Uma experiência com aplicações para Windows
Minha primeira experiência com acessibilidade foi quando trabalhei em um portal de educação à distância. Assim, pude ter contato com pessoas cegas e com baixa visão, o que me fez saber como é navegar por teclado, como usar ferramentas no celular e a importância do alto contraste. Porém, o conhecimento de um designer não tem um ponto final.
Já no SiDi, tive a oportunidade de trabalhar com produtos que têm a acessibilidade como um padrão de qualidade para ser aceito dentro da plataforma Windows. Apesar de eu ter uma base de acessibilidade, percebi que ainda tinha muita coisa para aprender.
Já dentro da execução dos projetos, comecei a buscar informações com outros colegas. Algumas questões em comum para mim e o time de design eram:
“Como que funciona a navegação com o Narrador?”
“Qual a melhor forma de documentar os padrões de acessibilidade para Windows? Aliás, será que existe um padrão?”
Isso me levou a um caminho confuso, pois a própria documentação da Microsoft não segue uma linha linear, e tampouco mostra exatamente todos os cenários de uso que precisaríamos definir dentro do projeto.
Fui então adentrando nas muitas referências até chegar aquele momento em que a gente percebe a existência de muito conteúdo para o que a gente realmente precisa e, referenciando o que a designer Daniele Zandoná diz: a sensação é de estarmos todos perdidos no país das maravilhas.
Com isso, o poder de síntese é essencial para traçar um caminho a ser seguido. Trago aqui alguns itens que descobri durante todas as pesquisas.
1. Navegação por teclado
O site WebAIM explica que a acessibilidade pelo teclado é muito importante para as pessoas que possuem deficiências motoras, ou visuais, por exemplo. Elas necessitam de um teclado para navegar e utilizam a tecla Tab para interagir com elementos da interface como os botões, campos de texto e links.
Além disso, algumas pessoas podem simplesmente preferir utilizar o teclado no lugar do mouse, o que faz com que a gente reflita que a acessibilidade na realidade é uma forma de inclusão para todas as pessoas.
1.1 Definições da navegação
Quando estamos na fase de definir a navegação por teclado, a primeira coisa a se pensar é:
Como posso tornar a navegação mais rápida e compreensível ao usar o teclado?
Se pensarmos que há muitos elementos em uma tela e que a pessoa tem que percorrer um caminho enorme para chegar a um item específico, isso vai causar frustração. Por isso, há a possibilidade de agrupar itens parecidos da tela e usar a tecla Tab para pular blocos da interface. Cada parada do Tab é chamada de parada de tabulação ou tab stop.
Há ainda, a possibilidade de colocar uma parada de tabulação para cada elemento da interface. Como na imagem abaixo, as setas podem ser o acesso à cada item, ou o Tab pula os itens das listas individualmente.
Porém, a Microsoft alerta:
“Ao definir uma única parada de tabulação para uma coleção de controles relacionados ou complementares, você pode minimizar o número de paradas gerais de tabulação em seu aplicativo.”
É o que acontece na imagem a seguir, o Tab pula o conjunto de cards e deixa as pessoas navegarem por setas direcionais nos elementos que estão agrupados:
Ordem significativa — A ordem de navegação também precisa ser definida e geralmente ela segue a ordem de leitura. Ou seja, dependendo da linguagem utilizada, a navegação se dará da esquerda para a direita e de cima para baixo. É importante que as pessoas que estão utilizando o produto consigam prever a ordem que o foco irá seguir na interface sempre que pressionarem a tecla Tab.
“Evite uma ordem de tabulação personalizada que faz com que o foco fique saltando em seu aplicativo. Por exemplo, uma lista de controles em um formulário deve ter uma ordem de tabulação que flui de cima para baixo e da esquerda para a direita (dependendo da localidade).” — Microsoft Learn
Consistência — O outro item é a consistência entre as definições que precisam ser mantidas em toda a aplicação. Se uma lista é acessada por setas direcionais, é interessante que todas as outras listas também sejam. Assim, um padrão vai sendo formado na cabeça da pessoa que usa o produto fazendo com que a navegação se torne intuitiva.
Foco visual — Também é preciso definir como que será o visual do estado focado dos botões. O foco é importante para que as pessoas que enxergam saibam em que ponto a navegação por teclado está e, com isso, elas se situam facilmente na interface e podem até mesmo auxiliar as pessoas que não enxergam.
O Windows por padrão usa um foco que possui duas bordas, uma externa preta e outra interna branca. Porém, você pode adaptar essas cores para o que achar mais conveniente para o seu projeto. Ao escolher tais cores, é interessante que elas possuam um alto contraste entre si e o fundo onde foco estiver aparecendo.
1.2 Como documentar
Crie uma legenda visual para reproduzir as teclas do teclado. Se quiser, marque com cores diferentes cada tecla para diferenciá-las. Explique o que cada tecla vai fazer em cada elemento focável.
Deixe claro quais serão os elementos a serem focados pelo uso do Tab. Geralmente são botões, links e elementos que se pode interagir na tela.
É importante sinalizar na documentação a ordem que a navegação por Tab vai seguir:
2. Narrador
O Narrador é uma tecnologia assistiva instalada no próprio Windows. Tal ferramenta auxilia as pessoas cegas, com baixa visão, ou que não sabem ler, a lerem o que está na tela e, por consequência, a navegarem em alguma interface.
2.1 Definições da navegação
Ao iniciar as definições do Narrador, é necessário ter em mente:
Como posso deixar a informação que será ouvida de uma maneira que dê para entender o que está acontecendo?
Nem sempre todos os elementos visuais que estão na tela são auto-explicativos e é necessário que o designer pense em qual informação auditiva pode ser inserida para que haja a compreensão da interação.
Ordem significativa — Assim como a navegação por teclado, a leitura da tela deve seguir uma sequência significativa. Esquerda para direita e de cima para baixo a depender da linguagem, continua sendo o mais indicado.
Porém, se houver algum componente na interface que seja menos utilizado, ou menos importante que outros para que a experiência de uso se torne mais agradável, essa sequência direita — esquerda, cima—baixo, pode ser alterada para que os itens mais importantes sejam acessados primeiro.
“A sequência não é importante para alguns conteúdos. Por exemplo, normalmente não afeta o significado se a navegação lateral é lida antes ou depois do conteúdo principal. Portanto, combinar a ordem visual e de leitura é uma maneira de garantir que esse requisito seja atendido, uma diferença na ordem visual e na ordem de leitura não é uma falha quando a sequência não afeta o significado.”— IBM Accessibility
Então é necessário que o designer avalie quais são os itens mais importantes de uma tela e, dependendo do contexto na qual ela está inserida, alterar a ordem. Além disso, a ordem de leitura também deve casar com a ordem de navegação por teclado, o que faz com que as duas coisas aconteçam conjuntamente.
Níveis de verbosidade — O narrator possui cinco níveis de leitura. O padrão é o nível 3, em que são lidos os textos e também os controles da tela quando se interage com eles. Portanto, é necessário saber qual seria o nível mais indicado para a aplicação que está sendo desenvolvida para saber quais detalhes colocar na documentação.
Feedback — Um dos itens mais importantes para saber o que está acontecendo em resposta a uma ação que tomamos em uma interface é o feedback: muitos são visuais como um loading, uma notificação de sucesso ou de erro, por exemplo.
Por isso, é importante considerar que tais feedbacks ocorram de forma sonora também. Dessa forma, as pessoas saberão que alguma atividade que estavam executando foi concluída, falhou, ou deu certo.
2.2 Como documentar
Quando o Narrador para em algum item que dá para interagir, ele lê algumas propriedades do componente. Por isso, é importante que tais características de cada item navegável sejam especificadas.
Para dar um exemplo, imagine que há um botão de menu na interface chamado "Calendário". As definições necessárias são:
- Nome — É o label visível ou o que você precisar dar ao botão. Ex: Calendário;
- Função — É o tipo do componente. Ex: Botão;
- Valor — É o estado que o componente pode estar. Ex: Selecionado/ Não selecionado;
- Posição — É a posição que um item de um agrupamento, ou lista se encontra. Ex: 1 de 4.
Para que a interface visual fique compreensível, é preciso colocar um texto explicativo onde não existe, como os botões que são apenas ícones. Além disso, botões que são para escolher uma cor, podem ter o texto alternativo que indique o nome da cor selecionada.
Não precisa marcar os itens que não dão para interagir, como os títulos e textos, mas é interessante marcar a ordem de leitura em relação aos links, botões e componentes em geral. Lembrando que uma ordem lógica de leitura é essencial para que o conteúdo faça sentido.
Dicas finais
Como cada projeto possui uma especificidade própria, pode ser que seja difícil encontrar como seria a especificação correta para determinado componente. Por isso, uma prática que os designers acabam adotando é avaliar os mesmos componentes, ou alguns que sejam ao menos parecidos, em outras aplicações. Com isso, é possível identificar como a navegação por Tab está acontecendo, ou como o item está sendo lido pelo Narrador.
Links úteis
O Figma tem alguns plugins, um deles desenvolvido pela própria Microsoft para documentar definições de acessibilidade:
Além disso, existem alguns modelos com componentes prontos para ajudar na documentação:
- Fluent Accessibility Notation — Microsoft
- Accessibility Bluelines — Jeremy Elder
TDC Connections 2023
Apresentei esse conteúdo no TDC Connections 2023 na trilha de acessibilidade e os slides da apresentação estão disponíveis aqui.
A ideia de escrever esse artigo veio a partir da colaboração nas atividades de projetos e o compartilhamento de conhecimento sobre acessibilidade entre os designers:
Daniele Zandoná, Daniel Sannomia, Guilherme Lourenço e Túlio Franklin.
Referências
- Accessibility notation — Microsoft
- Accessibility annotation kit
- A designer’s guide to documenting accessibility / Stéphanie Walter
- Annotating designs for accessibility — Claire Webber and Sarah Pulis
- Complete guide to Narrator
- Criando diretrizes de acessibilidade mais úteis
- Feedback visual — Windows apps
- Guide to documenting accessibility user interactions
- How to design for accessibility — BBC UK
- IBM accessibility requirements — IBM Accessibility
- Interações por teclado — Windows apps
- Microsoft design: A11y — Focus Order plugin
