Olá comunidade de Produto, me chamo Gustavo Barbosa e atualmente sou Product Designer dos apps ConectaBild e VittaFácil, ambos produtos oriundos do time de Inovação do grupo Bild&Vitta, time o qual é responsável pela digitalização de processos e geração de oportunidades para o mercado de construção civil e incorporação imobiliária.

E aproveitando para fazer uma breve autodescrição, sou um homem branco, de 24 anos com 1,70 de altura, tenho descendência japonesa e portuguesa, uso óculos pretos com a armação bem fininha e neste momento estou com uma camisa verde, do Palmeiras. (ok, ainda sem mundial ☹️)

1.1 Conhecendo a Inovação do grupo Bild&Vitta

Os produtos ConectaBild e VittaFácil tem como objetivo empoderar nossos clientes durante sua jornada na Bild e Vitta, expondo as informações que ele precisa de forma clara, com uma experiência intuitiva e autonomia de ações, entregando autosserviço através de solicitações de assistência técnica para seu empreendimento, agendamento de vistoria, entre outros serviços. Bem como também sendo a principal fonte de informação exibindo uma galeria com a evolução do empreendimento, extratos financeiros, 2ª via de boleto, entre outras informações.

As soluções da Inovação do grupo Bild&Vitta têm como legado a escalabilidade de produtos digitais, ou seja, a capacidade de expandir produtos atendendo demandas sem perder qualidade e que entregam valor, validando as regras de negócio do grupo Bild&Vitta e demais construtoras e incorporadoras, olhando para mercado.

A falta de validação sobre a acessibilidade dos produtos do Portal de Relacionamento era uma preocupação para a entrega de valor às pessoas usuárias não videntes, podendo impactar na experiência de uso de nossos clientes.

1.2 E o seu produto, é acessível?

Segundo o Censo IBGE DE 2010, 24% da população brasileira (~50 milhões) possui algum tipo de deficiência, onde 15,31% tem alguma dificuldade visual , 3,18% tem grande dificuldade e 0,27% não consegue de modo algum realizar tarefas que envolvam a percepção visual.

Além destes dados, atualmente o Código de Defesa do Consumidor e a Lei Federal 13.146/2015 (Lei Brasileira de Inclusão da Pessoa com Deficiência) e Lei Federal 7.853/1989, asseguram às pessoa com deficiência o pleno exercício de seus direitos básicos e isto inclui o consumo de produtos e serviços no ambiente digital.

Quando discutimos sobre a deficiência visual, também abordamos pessoas com daltonismo, baixa visão, miopia, entre outros, que podem ter dificuldade com:

• Baixos contrastes;
• Informações ocultas em links;
• Cores como única identificação de ação;
• Layout complexo e conteúdo desorganizado;
• Separação entre a ação e seu contexto (como botões e campos de formulário);

(Evelyn Matos e Karoline Benatti, 2021)

2. Objetivo e metodologias

Neste caso prático nosso principal objetivo foi realizar experimentos e validações sobre acessibilidade dos produtos do Portal de Relacionamento, considerando diferentes cenários e ferramentas de auxílio à pessoas com deficiência visual, sendo abordados testes automatizados e testes humanos. Os experimentos realizados foram:

2.1 Condução de testes automatizados com ferramentas gratuitas

• Verificação de taxa de contraste com plugin Adee no Figma;
• Avaliação da ferramenta “Verificador de contraste” — Adobe Colors;
• Simulação de diferentes tipos de daltonismo com o plugin Able no Figma;
• Avaliação da ferramenta “Apropriado para daltônicos” — Adobe Colors.

2.2 Condução de testes humanos, com pessoas usuárias reais

• Testes com leitor de Tela — NVDA (Desktop)
• Testes com leitor de Tela para Android— TalkBack (Mobile)
• Testes com leitor de Tela para iOS — VoiceOver (Mobile)
• Realização de testes de usabilidade com pessoas com deficiência visual

2.3 Handoff para o time de desenvolvimento/front-end

• Documentação e apresentação para time de desenvolvimento sobre principais anomalias e possíveis soluções de acessibilidade.

Vamos ver na prática os resultados e discussões destes experimentos?

2.1 Condução de testes automatizados com ferramentas gratuitas

Em nossos processos, quando falamos de testes automatizados, consideramos ferramentas que são capazes de validar requisitos mínimos de taxa de contraste e daltonismo (incluindo suas diversas variações).

A taxa de contraste faz uma relação entre os valores de HEX do background com a cor do título/label utilizado em uma tela, como cita o próprio WCAG cita:

WCAG 2.0 nível AA requer uma taxa de contraste de pelo menos 4,5:1 para texto normal e 3:1 para texto grande. As WCAG 2.1 requerem uma taxa de contraste de pelo menos 3:1 para componentes gráficos e de interface da pessoa usuária (como bordas de entrada de formulário).

WCAG Nível AAA requer uma taxa de contraste de pelo menos 7:1 para texto normal e 4,5:1 para texto grande.

Considerando este requisito de mínimo de contraste , executamos testes de taxa de contraste tanto pelo plugin Able do Figma, bem como pela plataforma Adobe Colors.

E na prática, como fica? Começando pelo Able, fizemos alguns testes com as principais telas da solução estudada, começando pela “Tela Inicial”, onde avaliamos o componente de Cards destacados na imagem abaixo.

Ao aplicar o Able, temos a taxa de contraste em 15.06:1 o que indica excelentes padrões de diferenciação entre background dos cards e seus respectivos títulos.

Olhando para outro cenário, temos a tela de Financeiro, qual possui o título em azul escuro, e seu background amarelo também em uma tonalidade escura.

Como podemos visualizar no resultado abaixo, neste exemplo, temos uma taxa de contraste de apenas 2.07:1, onde podemos identificar uma primeira anomalia de acessibilidade visual. Neste caso, durante o handoff, mapeamos e levantamos a hipótese de criar uma variável no front-end para padronizar os títulos de tela para a cor branco (#FFFFFF) para o aumento de contraste seguindo o guia WGAC.

Além do plugin Able, também utilizamos a ferramenta “Verificador de contraste” da Adobe Colors, a qual trás validações baseadas no guia WCAG 2.1, como na imagem à seguir.

Já quando o assunto é apropriação para daltonismo, utilizamos duas outras ferramentas também gratuitas para a validação e compreensão deste cenário.

Começando pelo plugin Adee, também do Figma (❤) o qual é responsável pela simulação de diferentes visualizações dos 3 principais tipos de daltonismo e suas variações, como:

• Acromatopsia: Falta de diferenciação de cores, predominando apenas preto e branco.
• Protanopia: Onde há dificuldades na diferenciação de vermelho e verde.
• Deuteranopia: Também há dificuldades na diferenciação de vermelho e verde.
• Tritanopia: Falta de diferenciação entre azul e amarelo.

Por meio do Able e da ferramenta “Apropriado para daltônicos” da Adobe Colors conseguimos analisar estas diferentes simulações de daltonismo, e por meio disto, revalidar as taxas de contraste como fizemos nos passos anteriores, como por exemplo:

2.2 Condução de testes humanos, com pessoas usuárias reais

Após as validações com testes automatizados, chegamos na cereja do bolo, os testes humanos com pessoas usuárias reais, etapa em que particularmente, eu pude errar e aprender bastante.

Em uma conversa com uma pessoa usuária não vidente, ouvi a seguinte frase “[…] diga aos seus desenvolvedores que apenas testar com leitores de tela não é o suficiente, isso não é ser acessível.” Confesso que refleti essa frase por alguns dias. Atualmente as ferramentas de leitura de tela desktop e mobile de fato auxiliam bastante no diagnóstico de falta de descrição/etiquetas em componentes e imagens, porém apenas este método de validação pode deixar passar uma série de falhas de usabilidade para pessoas não videntes.

Em outubro de 2019 a Everis Brasil realizou uma pesquisa com 427 respostas válidas no contexto de ferramentas auxiliares no ambiente digital. A pesquisa validou que o leitor de tela NVDA é a principal ferramenta no contexto desktop com 76,6% de pessoas usuárias ativas.

Outro dado extremamente interessante é relacionado aos métodos/atalhos de navegação utilizados pelas pessoas usuárias no contexto desktop, onde temos os seguintes dados.

Já no contexto mobile, foi validado que as ferramentas Talkback para Android (50,1%) e Voiceover para iOS (32,8%) são os principais leitores atualmente utilizados.

Recomendo fortemente esta pesquisa, além de dados de ferramentas são indicados principais componentes que mais geram dificuldade de uso para pessoas não videntes, como validações com Captcha e imagens sem descrição, entre outros excelentes dados.

Com base nestes dados, foram conduzidos testes de usabilidade com:

• 4 designers da Inovação Bild&Vitta.
• 2 desenvolvedores front-end também da Inovação.
• 2 pessoas usuárias não videntes do app ConectaBild.

Em primeiro momento, a decisão foi conduzir testes de usabilidade com colaboradores do grupo, sendo os designers e desenvolvedores, onde tomamos os seguintes cuidados:

• Reservamos uma sala silenciosa para que não houvesse qualquer tipo de interferência durante o teste;
• Vendamos as pessoas usuárias de forma que eles não pudessem utilizar nenhum recurso visual para a condução das tarefas do teste;
• Preparamos um roteiro trazendo um cenário hipotético e tarefas subdivididas afim de entender cada passo da pessoa usuária;
• Gravamos os testes afim de analisar todas as percepções e aprendizados.

Quais foram os principais aprendizados do teste adaptado?

• Conseguimos encontrar falhas de acessibilidade como falta de descrição/ etiqueta em alguns componentes, como ícones, ações de botões e afins. Porém nós precisávamos testar com pessoas não videntes, afim de entender seu real contexto de uso.
• Durante os testes, nossos colaboradores estavam numa curva de aprendizado sobre como utilizar os leitores de tela, então isto só reforçou a hipótese anterior.

Para isto, fomos para o próximo passo, que foi um dos mais delicados durante todo o processo, que foi a fase de recrutamento de pessoas com deficiência visual, como primeiro passo, entrei em contato com o time de Inteligência de Clientes para ter uma relação de clientes com deficiência visual. Durante algumas boas tentativas, consegui o contato de um casal de clientes Bild&Vitta que se apresentaram de forma muito receptiva e dispostos a participar dos testes, porém mais um desafio os testes teriam que ser remotos dado que na época ainda tínhamos baixos índices de vacinação contra a COVID-19, desta forma, preparei o que eu chamei de “pré triagem para teste de usabilidade” onde fiz uma pequena entrevista com as pessoas usuárias levantando questões como:

• Qual é a plataforma de videoconferência mais acessível para você?
• Qual é a marca e o modelo do seu smartphone?
• Qual leitor de tela você utiliza em seu celular?
• Bem como explicações sobre como um teste de usabilidade funciona.

#FicaDica

Geralmente em testes de usabilidade, como bem sabemos, as pessoas usuárias normalmente se subestimam durante a execução de algumas tarefas, citando que não estão conseguindo finalizar determinada tarefa, desta forma, as pessoas usuárias não videntes tendem a partilhar deste sentimento por não visualizarem uma tela. Então durante o teste, mantenha sua postura como pessoa condutora para não sair do figurino e dar qualquer “spoiler” para a pessoa usuária, para que assim, você não comprometa seu teste.

Vamos para os testes finais

Afim de amadurecer a cultura de acessibilidade, convidei um de nossos desenvolvedores front-end para atuar como observador dos testes de usabilidade com o casal não vidente que recrutamos na etapa anterior.

Para a criação do roteiro do teste de usabilidade, levantei 4 diferentes tarefas, explorando as funcionalidades mais requisitadas pelas pessoas usuárias ativas através do Google Analytics, e quebrei em subtarefas, focando em componentes que haviam comportamentos anormais como:

• Feedbacks de campos de inserção de texto;
• Selects/listagens;
• Ícones;
• Ilustrações;
• Cards;
• Entre outros componentes.

Além disso, documentei todos os resultados de cada tarefa no Notion, como na imagem abaixo.

Contextualização da tarefa A: Considere que você está em seu trabalho, e deseja consultar a jornada atual do seu empreendimento, afim de obter maiores informações sobre o mesmo e na sequência solicite um atendimento para o SAC.

Durante a tarefa A, percebemos que as pessoas usuárias tiveram dificuldade em visualizar as opções dentro de um Select à partir dos leitores de tela, bem como para compreender um ícone de “mais informações” que não tinha descrição/ etiqueta.

Já durante a tarefa D, identificamos a falta de descrição/etiqueta nos ícones do menu fixo do App. Uma pontuação extremamente grave para a usabilidade de nossos clientes.

Contextualização da tarefa D: Dado que você está em sua casa, e deseja informar que mudou o número de telefone, atualizando esta informação em seu Perfil.

Como “medir” o sucesso dos testes de usabilidade?

Além das análises de cada tarefa, ao final do teste, solicitamos para que as pessoas usuárias respondessem o questionário do SUS (System Usability Scale), métrica a qual se baseia em um formulário de perguntas quantitativas que se relacionam com as Heurísticas de Nielsen para a validação em números do sucesso ou não de um teste de usabilidade.

Em uma escala de 0 até 100, a pontuação mínima para a validação de um teste bem avaliado perante às heurísticas é 68, a nota média entre as 2 pessoas usuárias para o SUS foi de 90 pontos. Além de comentários qualitativos feitos ao final do teste.

2.3 Handoff para o time de desenvolvimento/front-end

Por fim, foram realizadas documentações e apresentações para o time de desenvolvimento, contando os principais resultados, aprendizados e oportunidades coletados durante todo o processo.

Um ponto extremamente importante foram os diferentes comportamentos dos leitores de tela Talkback (Android) e Voiceover (iOS). Alguns ajustes feitos em uma plataforma não necessariamente atendiam as demandas da outra plataforma, sendo assim, tabulamos as melhorias olhando para todos os cenários possíveis ordenando por criticidade.

Após as apresentações e estimativas de esforço/tempo com os desenvolvedores e Product Owner, finalizamos a lista de melhorias em duas sprints de 15 dias cada. Como próximos passos, estamos nos aproximando de ONGs voltadas para pessoas com deficiência visual na região de Ribeirão Preto-SP para o processo contínuo de validação de acessibilidade em todos os produtos da Inovação do grupo Bild&Vitta.

Concluindo…

Acessibilidade não se trata apenas de testes com leitores de tela, acessibilidade se trata de uma cultura que deve envolver Product Managers, Product Owners, desenvolvedores e todas as partes interessadas do produto. Cada vez mais vemos empresas e instituições trazendo esta cultura através de posições como “Acessibility Product Designer” onde a ideia não é apenas estar dentro de leis federais e sim entregar valor para qualquer pessoa que deseje consumir seu produto.

Na minha opinião, tornar seu produto acessível é executar uma validação contínua de acessibilidade, vai lançar uma nova feature com novos componentes? Separe uma base de pessoas usuárias não videntes para conduzir testes de usabilidade assistidos com eles!

Você esta na etapa de descoberta de algum produto? Levante hipóteses que possam impactar na jornada de uma pessoa não vidente. E muito além disso, inclua qualquer tipo de deficiência, desde visual, até motora, auditiva e assim por diante.

Vamos construir esta cultura de acessibilidade juntos? ❤

Meus agradecimentos especiais para todos que participaram deste processo direta ou indiretamente, às referências em acessibilidade Marcelo Sales e Talita Pagani. Ao meus queridos desenvolvedores Mônica Lança e Luis Felipe Colares Juzo e todo time de Design do grupo Bild&Vitta, como Cauê de Oliveira Buck pelo grande desafio, Lucas Thomazini, Lucas Canôas, Mariana Neri e todos os demais.

Referências

• Como fazer o handoff de designs acessíveis para as pessoas desenvolvedoras…
• Resultados da pesquisa sobre o uso de leitores de tela 2.0
• IBGE - Educa | Jovens
• #TheDevConf 2017 — Trilha Acessibilidade: Incorporando acessibilidade no seu projeto — do zero à…
• Precisamos de profissionais focados em acessibilidade dentro das empresas

O seu produto não é acessível para pessoas não visuais (Case prático) was originally published in Accessibility 4DEVS on Medium, where people are continuing the conversation by highlighting and responding to this story.

Um erro muito comum é confundir o tamanho da fonte com o nível de hierarquia do cabeçalho, os títulos devem ser definidos pensando na lógica e não no tamanho da fonte.

Pessoas que usam leitores de telas, como pessoas cegas ou com baixa visão, usam um atalho para navegar entre títulos. Isso permite que elas façam uma leitura dinâmica da página e encontrem o conteúdo desejado com menos esforço.

Nesse artigo, você vai encontrar as principais informações que vão te ajudar a definir a estrutura de cabeçalhos, com uma boa hierarquia da informação.

Como definir a hierarquia dos títulos

Dificilmente usaremos cabeçalhos de nível h4, h5 e h6, pois eles são mais comuns em sites com conteúdo denso, como documentações técnicas. A maioria dos sites só precisam dos níveis h1, h2 e h3.

Título de nível h1

O título h1 é como se fosse a capa de um livro, ele deve ser único e descrever claramente toda a página. Todas as páginas precisam ter um título h1, em alguns casos, é possível colocar esse título invisível, mas que será lido pelo leitor de telas.

Understanding Success Criterion 2.4.2: Page Titled

Título de nível h2

O título h2 é como se fosse o título de cada capítulo do livro, normalmente usado para marcar seções da página e colunas do footer. Toda seção precisa ter um título que o descreva claramente.

Ele deve estar diretamente ligado ao título h1, por exemplo, não pode existir um h2 dentro de outro h2 ou dentro de títulos com hierarquia inferior, como h3, h4, h5 e h6.

Título de nível h3

O título h3, é como se fosse os tópicos dentro do capítulo do livro, normalmente usado para marcar os títulos de blocos dentro de uma seção.

Ele deve estar diretamente ligado a um título h2, por exemplo, não pode existir um h3 sem um h2 relacionado, como também não pode existir um h3 dentro de outro h3 ou dentro de títulos com hierarquia inferior, como h4, h5 e h6.

Títulos de nível h4, h5 e h6

Raramente será necessário usar essas marcações, mas caso precise, seguir a mesma lógica do h3. Só pode existir um h4 dentro de um h3, o h5 dentro de um h4 e o h6 dentro de um h5. Não pode colocar um título dentro de outro com o mesmo nível de hierarquia. Deve ter cuidado para não inverter a ordem no nível dos títulos.

Não colocar títulos em imagens

Devemos permitir que todos os textos sejam customizáveis, por isso nunca coloque títulos em imagens, para estilizar, use o CSS. Quando colocamos o texto na imagem, impedimos, por exemplo, que:

• Pessoas com baixa visão ou pessoas idosas, aumentem o tamanho da fonte.
• Pessoas com dislexia customizem o estilo da fonte.
• Pessoas neurodiversas mudem a cor do fundo e a cor do texto.

Esses recursos de customização estão integrados ao navegador ou dispositivo, além de existir plugins gratuitos que oferecem várias ferramentas de customização como o WebHelp.

Understanding Success Criterion 1.4.5: Images of Text

Outras recomendações da WCAG

• Understanding Success Criterion 2.4.6: Headings and Labels | WAI | W3C
• Understanding Success Criterion 2.4.10: Section Headings

Preparando o Handoff de Acessibilidade

Essa etapa pode ser feita pela pessoa responsável pelo UX Writing, como muitas vezes os times não possuem pessoas dedicadas a escrita, ou as mesmas ainda estão em processo de aprendizado, caberá ao time trabalhar em conjunto para realizar essa tarefa.

No protótipo da aplicação, coloque uma anotação informando quais são os títulos e qual o nível de hierarquia. Conforme exemplo a seguir:

Agora vamos analisar alguns aspectos importantes desse exemplo:

O primeiro título visível da página descreve apenas o bloco, e não a tela inteira, por isso ele não é o nosso h1. Nesse caso, colocamos o nome da empresa invisível, mas que será lido pelo leitor de telas e pelos rôbos de SEO da Google.

Na segunda seção, o texto “Espalhando a palavra da acessibilidade”, apesar de ter a fonte maior é apenas uma frase de efeito, ela não descreve claramente a seção. Nesse caso, o texto menor “Nossas mentorias”, é o título h2, pois semanticamente é o que faz mais sentido.

Ainda na segunda seção, a frase de efeito parece um título porque a fonte é maior e tem um grande destaque visual. Para evitar confusão durante o desenvolvimento, precisamos marcar esse texto como p de parágrafo.

No rodapé, ou footer, cada coluna tem um título, como o tamanho da fonte desses títulos normalmente é menor, as pessoas que desenvolvem ficam confusas e usam a marcação de h6, isso quando não usam p , div ou span. Por isso, é tão importante marcar que eles são do nível de hierarquia h2.

Como fazer o handoff de designs acessíveis para as pessoas desenvolvedoras…

Como testar

Para testar, você pode usar o próprio leitor de telas. A maioria dos leitores, fornece um atalho para navegar entre os cabeçalhos da página, verifique qual é o comando para o seu programa e sistema operacional.

Além disso, é possível realizar a análise da estrutura de cabeçalhos de forma visual, usando o plugin do Google Chrome, HeadingsMap.

HeadingsMap

Ao ativar o plugin, vai abrir uma caixa de diálogo lateral mostrando todos os cabeçalhos e o nível de hierarquia, conforme imagem a seguir:

Faça uma análise verificando se a hierarquia está correta, se todos os títulos da página aparecem na lista, se existem frases marcadas como título incorretamente e se a leitura apenas dos títulos está compreensível.

Problemas comuns de implementação

• Usar tags p, span ou div para marcar os títulos.
• Colocar o atributo role para alterar a semântica.

Nota para dev: os cabeçalhos devem ser definidos usando as tags do HTML: h1, h2, h3, h4, h5e h6, sem alteração da semântica. Caso, você coloque um atributo role no cabeçalho, ele perderá a função de cabeçalho, nesse caso, o leitor de telas vai excluir esse elemento da navegação entre títulos/cabeçalhos.

Implementação em aplicativos mobile

Diferente do HTML que possui 6 níveis de hierarquia, nos aplicativos mobile que geralmente possuem telas mais otimizadas e com menos informações, as principais tecnologias fornecem apenas 1 opção para a semântica dos títulos.

A pessoa que desenvolve para mobile, ao receber o Handoff com h1, h2 , h3 , h4 , h5 e h6 pode usar o código exemplificado a seguir, conforme a tecnologia utilizada:

• No Kotlin, defina o atributo android:accessibilityHeading do elemento como true.
• No Swift, defina o accessibilityTraits como .header.
• No React Native, adicione o atributo accessibilityRole com a propriedade header.
• No Flutter, envolva o texto com o Widget Semantics e adicione o atributo header com o valor true.

Estudo de caso

Para exemplificar a importância das recomendações abordadas nesse artigo, para fins educativos, vamos analisar um site que não possui uma hierarquia da informação bem definida.

Pense na seguinte tarefa: Você é uma pessoa cega e quer comprar um Cropped no site da Enjoei, o site tem muitas peças, você não tem tempo e nem paciência para escutar cada item da tela. Para encontrar o produto mais rápido, você usa um atalho do teclado que navega entre os títulos.

Agora análise a imagem a seguir, leia todos os títulos listados na caixa de diálogo preta que está do lado esquerdo e responda a seguinte pergunta: Qual é o título da seção onde estão os Croppeds?

Como você pode ter percebido, é impossível identificar as seções apenas lendo ou navegando pelos títulos, pois tem muitas frases de efeito que não fazem nenhum sentido para títulos. Como no caso dos Croppeds que o título é “qual a diferença”.

Para quem prefere assistir vídeos, confira o resumão desse artigo no YouTube:

Ainda estamos produzindo o vídeo, disponibilizaremos em breve.

Obrigada por ler. Espero que esse conteúdo seja útil para você e seu time☺

Acessibilidade na Hierarquia de Informação — Estrutura de cabeçalhos was originally published in Accessibility 4DEVS on Medium, where people are continuing the conversation by highlighting and responding to this story.

Os modais são invasivos, confusos, usados com muita frequência, pouco acessíveis, bloqueiam a interação da pessoa usuária com a janela principal, são usados como gaveta de lixo de interação, difíceis de fechar, proporcionam uma experiência frustrante em telas pequenas e aumentam a carga cognitiva com conteúdo ou interação não essenciais.

Tá! Foram mais de 5, mas deu para entender o quão ruim os modais podem ser para a experiência, usabilidade e acessibilidade, né?

Nesse artigo, eu vou abordar algumas estratégias que eu, enquanto pessoa desenvolvedora de software, uso para remover modais das aplicações que eu já trabalhei.

Em 2019, eu trabalhei com um Designer incrível chamado Pedro Ivo. Ele me apresentou o site modalz modalz modalz e me explicou como um modal pode ser ruim para a experiência da pessoa usuária. Desde então eu travei uma guerra contra os modais.

Sempre que eu encontro um modal, eu faço uma pergunta que eu aprendi nesse site:

“Porque isso precisa ser um modal?”

Logo em seguida, eu dou uma sugestão para a pessoa Designer do meu time de como poderíamos substituir o modal, e adivinhem:

Não precisava ser um modal!

Os modais são facilmente substituídos por outros elementos, como elementos de expansão, conteúdo em linha, uma nova página ou caixa de diálogos laterais que não bloqueiam a interação com a janela principal.

Eu já perdi as contas de quantos modais eu evitei, mostrando o poder dos accordions para o meu time de Designers kkk

O case do Zoom

O Zoom poderia ter usado um modal de confirmação ao sair, mas não usou! Apesar de parecer estranho no início, essa opção é interessante e traz alguns benefícios para a usabilidade e acessibilidade.

Por exemplo, após clicar em sair, caso alguém fale com você, é possível abrir o microfone com apenas 1 clique, sem a necessidade de fechar um modal primeiro para só depois conseguir responder.

Como acertar no uso do modal

Se você testou todas as alternativas e nenhuma deu certo, e você realmente considera importante o uso do modal, certifique-se de que seu modal seja bom!

Torne fácil a ação de fechar, por tecla de escape, clicando fora da janela modal e um botão Fechar claramente rotulado. Limite a interação a uma tarefa simples. Seja breve e conciso em seu conteúdo. Acessível para leitores de telas e fontes maiores, se você não puder torná-lo acessível, não use um modal.

Mesmo que seja permitido pela WCAG e exista formas de torna-los acessíveis para leitores de tela, eu particularmente continuo não gostando de usa-los, pois geram sobrecarga cognitiva e podem prejudicar a experiência de pessoas com DCNA — Deficiências Cognitivas Neuronais ou de Aprendizagem. Eu sou autista, se o modal não é acessível para 1 pessoa do meu clã, não é acessível!

Evite abrir um modal a partir de outro modal. Não use modais de tela cheia, nesse caso pode facilmente ser uma nova página. Nunca crie modais com várias etapas. Nunca abra um modal automaticamente, a menos que seja solicitado pela pessoa usuária. Evite modais de marketing, ninguém gosta.

Como criar um modal acessível para teclado e leitores de tela

➊ Ao abrir o modal, mova o foco para o primeiro item do Modal.
➋ Bloquear a interação com a página que está atrás do Modal.
➌ Colocar um botão de fechar grande, com rótulo e função acessível.

No tutorial da W3C e tutorial do Web Accessibility Guidelines tem alguns exemplos de código e explicações de como tornar um Modal acessível. Mas, sempre lembre:

Modal acessível é aquele que não existe.

E aí? Você vai se unir a mim na luta contra os modais?

Para quem prefere assistir vídeos, confira o resumão desse artigo no YouTube:

Esse conteúdo foi inspirado no site modalz modalz modalz. Obrigada por ler. Espero que esse conteúdo seja útil para você e seu time☺

Modais — 5 motivos para nunca mais usa-los ☠ was originally published in Accessibility 4DEVS on Medium, where people are continuing the conversation by highlighting and responding to this story.

Quando usamos HTML puro, a aparência dos botões é um retângulo com texto dentro, e a aparência dos links é um texto com sublinhado. Porém, o que define um botão ou um link, não é a aparência, mas sim o comportamento.

Ao longo das últimas décadas, ocorreram muitas mudanças na forma de construir um design. Hoje é impossível diferenciar botões e links apenas pela apresentação visual!

Nesse artigo vamos abordar a diferença entre botões e links, e mais alguns aspectos relevantes para a acessibilidade desses elementos.

As aparências enganam

É muito comum confundir links e botões por causa da aparência, atualmente usamos a aparência do botão para elementos que queremos dar mais destaque e a aparência do link para outras funções secundárias que não queremos que chame muita atenção.

Sempre lembre que a semântica de um elemento é definida pelo seu comportamento (UX) e não pelo visual (UI). Para conseguir identificar a diferença entre os botões e links, aprenda o comportamento deles:

Os botões executam uma ação e permanecem na mesma página, enquanto os links são responsáveis pela navegação entre páginas.

Antes de entregar o protótipo de uma funcionalidade, você pode fazer o Handoff de Acessibilidade e informar o que é link e o que é botão.

Depoimento

Entenda a importância de definir corretamente os botões e links, leia esse depoimento de uma pessoa uma cega:

Sempre entro e tem a confusão, eu não sei se é um link, se é botão, se vai me deixar na página, se vai abrir outra janela. Socorro! — Janaína Bernardino

Dicas para desenvolvimento

Sempre que possível use as tags HTML5 sem alterar a semântica.

Infelizmente, com o desafio de desenvolver páginas SPA — Single Page Application, é inviável manter a semântica original HTML. Como por exemplo no react-router do ReactJS, que a navegação é feita pelo JavaScript.

Nesse caso, é necessário utilizar o atributo role para alterar a semântica do botão, garantindo a navegação pelo teclado e a leitura correta da função do elemento, conforme imagem a seguir:

Atribuir função em aplicativos mobile

Os componentes nativos do mobile não possuem nenhuma semântica. Sempre é necessário configurar a função do elemento, você pode colocar uma função padrão no Design System e quando necessário alterar via parâmetro.

Verifique na documentação da linguagem ou framework, como colocar o atributo role ou accessibilityRole. A seguir, alguns exemplos de como definir a função “botão” para Swift, Kotlin, React Native e Flutter:

Tem um artigo bem legal sobre acessibilidade para Android nativo, com vários códigos em Kotlin:

Android Accessibility — Resolving common Talkback issues

Modal

Uma dúvida comum é sobre o botão de fechar do modal “é link ou é botão?”. Nesse caso, é botão! Porque ele vai finalizar uma sessão dentro da página.

Propósito do botão ou link

Existem 2 modos de navegar pelo leitor de telas que permite uma leitura dinâmica da página e localizar assuntos relevantes mais rápido. Uma delas é a navegação por títulos, que vamos falar em um dos próximos artigos e a outra é a navegação pelos elementos interativos, como botões, links e caixas de texto.

Um erro bem comum é colocar o nome do link “saiba mais”, “veja mais”, “clique aqui” e termos genéricos que não identificam claramente o propósito do link. Vamos analisar o exemplo a seguir:

Nesse exemplo da imagem, ao navegar pelo leitor de telas pelo modo de navegação por elementos interativos, usando a tecla tab, ou o atalho K pelo NVDA, a pessoa cega vai escutar “Veja mais, link. Veja mais, link. Veja mais, link”. E surge a pergunta, veja mais o que?

Nesse caso, você pode alterar o próprio nome do link para “Saiba mais sobre a mentoria de desenvolvimento” ou colocar o texto complementar apenas para o leitor de telas, conforme imagem a seguir:

Também é possível usar algumas técnicas para trocar o texto que será lido apenas pelo leitor de telas ou adicionar informações complementares, como aria-label ou aria-describedby. Explicamos algumas dessas técnicas no artigo:

O guia definitivo para descrição de imagens e ícones em sites, aplicativos e redes sociais.

Redimensionar texto e refluxo

Faça protótipos e testes simulando fontes maiores, como por exemplo 200% e 400%, principalmente no Mobile, para evitar problemas no layout.

Por exemplo, se o tamanho da fonte é 16 pixels, simule com 32 pixels e 64 pixels e faça as adaptações necessárias.

Outros aspectos importantes

A cor do texto e o fundo devem possuir o contraste mínimo de 4.5:1.

Acessibilidade das Cores — Conheça os 3 principais erros e como resolver….

A altura e a largura devem possuir o tamanho mínimo de 48dp, para proporcionar uma boa área de toque.

Acessibilidade da área mínima de toque e como ela impacta o seu SEO…

Os botões e links precisam estar funcionando na navegação pelo teclado, com o foco ativo e visível.

Estado de foco — A guerra entre UI e UX

Para quem prefere assistir vídeos, confira o resumão desse artigo no YouTube:

Agradecimento especial à Janaína Bernardino por revisar esse artigo.
Obrigada por ler. Espero que esse conteúdo seja útil para você e seu time☺

Acessibilidade de botões e links — Você realmente sabe a diferença entre eles? was originally published in Accessibility 4DEVS on Medium, where people are continuing the conversation by highlighting and responding to this story.

O texto alternativo é uma palavra ou frase para explicar o conteúdo da imagem, sem ele, cerca de 7 milhões de pessoas cegas no Brasil têm o acesso à informação negado, seja nas redes sociais, sites, aplicativos ou até mesmo em grupos do WhatsApp.

Uma mesma imagem pode ter várias descrições diferentes. Isso acontece porque a descrição não é uma ciência exata, ela depende do contexto e da mensagem que queremos transmitir. Por isso, as inteligências artificiais ainda não são capazes de realizar descrições coerentes.

Nesse artigo vou tentar resumir as principais informações que você precisa saber para mandar bem nas descrições.

Como descrever uma imagem

Os 4 principais elementos da descrição são o Formato, Sujeito, Paisagem e Ação.

Vamos analisar uma foto que está no Instagram da Pequena Lô.

A descrição dessa imagem poderia ser:

Foto de Pequena Lô, ela está no estúdio do programa Encontro, sentada na sua motinha elétrica. Ela está com sorriso largo, usando um macacão em tons de vermelho e sapato branco.

Caso essa mesma foto estivesse no e-commerce que vende a motinha, valeria a pena dar mais detalhes sobre a moto. Como o material, a cor, o formato do assento e a posição da cestinha.

Mas se ela estivesse no e-commerce que vende o sapato, os detalhes da motinha não são relevantes e poderíamos dar uma ênfase maior aos detalhes do sapato, se fecha com cadarço ou velcro, qual é o material, formato da sola, detalhes da costura e assim por diante.

Não descreva emoções

As aparências podem enganar, nunca diga que a pessoa está feliz, triste, com raiva, tédio, medo e demais emoções subjetivas. Apenas descreva as características, como está sorrindo, boca entreaberta, posição da mão, cabeça inclinada para cima, para o lado ou para baixo, e etc. Também evite fazer analogias como olhar matador, olhar sedutor e outras comparações.

Não use adjetivos

Não podemos influenciar na opinião da pessoa usuária, cada pessoa tem seus próprios gostos e conceitos de beleza. Por exemplo, não diga que está linda, deslumbrante, magnifica, esplendida, mas se você quer passar essa impressão você pode descrever a roupa, acessórios, maquiagem, cor do esmalte e outros elementos que construam esse conceito.

Recomendações para sites e aplicativos

Evite usar textos em imagens

Isso prejudica a experiência de pessoas com baixa visão, dislexia e outras deficiências visuais e cognitivas. Pois não é possível customizar a cor, o estilo ou tamanho da fonte.

Caso não seja possível colocar os textos diretamente no HTML, pelo menos garanta que todo o conteúdo textual estará escrito no alt que é a tag do texto alternativo.

Vamos analisar uma imagem de uma campanha de Marketing que está no site da Magazine Luiza.

A descrição dessa imagem poderia ser simplesmente:

Chance única, milhares de produtos eletrônicos como máquina de lavar e televisão de 50 polegadas, estão com 70% de desconto + frete grátis. Verifique a disponibilidade do frete simulando na página de produto.

Algumas pessoas colocariam cada detalhe da imagem, como “Chance única na esquerda em branco e amarelo”, “no centro a foto de 3 eletrodomésticos, sendo eles uma máquina de lavar branca, uma televisão da samsumg de 50 polegadas e uma JBL preta”, “na direita lemos o texto com até 70% off + frete grátis em milhares de produtos, escrito em branco e amarelo”, “em baixo com letra menor lemos: * Verifique a disponibilidade do frete simulando na página de produto”. “o fundo azul com a frase chance única em outline formando marca d’água”

Esse tipo de descrição é cansativa, prolixa e confusa. Não existe necessidade de colocar tantos detalhes! Isso torna a navegação estressante e gera sobrecarga cognitiva.

Nesse exemplo da campanha promocional o objetivo da imagem é informar que existe uma promoção, qual é a categoria dos produtos que estão na promoção, qual é o percentual de desconto e se houver um cupom, qual é o código do cupom para receber o desconto.

Se essa mesma imagem estivesse no site que ensina Designers a criar uma arte, aí sim deveríamos escrever os detalhes com precisão.

Para descrever uma imagem, sempre tenha em mente qual o objetivo dela para aquele contexto.

Escreva o rótulo de botões e links

Os botões que possuem apenas ícones precisam de um rótulo acessível. Como por exemplo esses botões com o ícone de coração e sacola.

Em fase de prototipação, a pessoa responsável pelo Writing da aplicação, seja UX Writing ou Product Designer UI/UX, precisa escrever o rótulo desses botões e se necessário uma dica.

Como implementar um rótulo acessível em sites e aplicativos

Para escrever um texto para botões que será lido apenas pelo leitor de telas e ficará invisível na tela. Faça o seguinte:

Esse código funciona para qualquer framework JavaScript, como ReactJS, VueJS, Angular 8, até no InfernoJS. Pois todos eles são baseados em HTML.

Para aplicativos mobile também é possível colocar o rótulo acessível, verifique a documentação de acessibilidade da linguagem ou do framework que você usa. A seguir, alguns exemplos para Kotlin, Swift, React Native e Flutter:

Como implementar as dicas

Em alguns casos, podemos colocar uma dica para melhorar a compreensão do elemento em algum contexto. Nem sempre é necessário colocar dicas, faça uma analise de cada caso para evitar poluição auditiva.

Por exemplo, em um botão desabilitado podemos informar o que deve ser feito para que ele fique habilitado. Ou no caso do botão de notificações podemos informar se há ou não novas notificações e quantas são.

A dica será lida após a função do elemento, conforme imagem a seguir:

Nas documentações de linguagens e frameworks, procure por hint ou accessibilityHint. A seguir alguns exemplos de como colocar dicas no HTML, Kotlin, Swift, React Native e Flutter:

Não descreva imagens ou ícones meramente ilustrativos

Não repita o texto visível na imagem, porque a leitura ficará duplicada. Nunca oculte uma imagem importante para a compreensão ou navegação. Nunca escreva a URL na imagem no lugar do texto alternativo.

Imagens meramente ilustrativas, podemos ocultar do leitor de telas. Como por exemplo esses ícones de destaques da Magazine Luiza.

Apenas se não houvesse o texto visível, seria necessário colocar o rótulo invisível, como fizemos no tópico anterior.

Nesse caso, podemos usar svg que não possui semântica, colocar a imagem como background através do CSS ou usar a tag img sem descrição e aria-hidden="true" conforme trecho de código a seguir:

Se uma imagem desperta sentimentos emocionais, você pode colocar um texto alternativo para oferecer uma experiência agradável para todas as pessoas, mesmo que seja possível viver sem ela.

Como analisar o texto alternativo das imagens

Após a implementação, você pode usar o leitor de telas para escutar o texto alternativo das imagens e verificar se está tudo funcionando conforme o planejado. Essa é melhor forma de testar!

Outra opção é usar o plugin do Google Chrome, Alt Text Tester. Após instalar, clique no ícone do plugin para ativar e passe o mouse em cima das imagens para ler o texto alternativo. Faça uma analise e verifique se a descrição da imagem está coerente com a mensagem que a imagem está transmitindo.

Alt Text Tester

Emojis

Emojis contém descrição nativa, podem ser usados, porém cada sistema operacional lê de uma forma diferente. Use com moderação.

Para saber como usa-los de forma acessível, recomendo a leitura do artigo Emojis e acessibilidade: como usá-los adequadamente que foi publicado pelo UX Collective.

Redes sociais

Sempre descreva as imagens nas redes sociais, seja no perfil pessoal ou profissional. As principais redes sociais como Instagram, Facebook, LinkedIn, Twitter e até o Medium, oferecem suporte para colocar o texto alternativo nas imagens.

Para colocar o texto alternativo no Instagram, na última tela clique a opção Configurações avançadas, depois em Escrever texto alternativo, escreva o texto alternativo para cada imagem e clique em Concluir. Conforme imagem a seguir:

No Twitter, em cada imagem, clique no botão +ALT e escreva o texto alternativo:

No facebook, clique no botão de Mais, aquele com os 3 pontinhos, depois em Editar texto alternativo e escreva a descrição da imagem:

No LinkedIn Mobile ou Web, ao adicionar a imagem, clique no botão Adicionar texto alternativo.

No Instagram Web na última tela clique em Acessibilidade.

No Facebook Web clique, clique no botão Editar que fica sobre a imagem, em seguida clique em Texto alternativo e selecione a opção Texto alternativo personalizado e escreva o texto.

E o TikTok não é acessível.

Regras da WCAG

Conheça algumas regras da WCAG que estão relacionadas ao conteúdo apresentado nesse artigo:

• Understanding Success Criterion 1.1.1: Non-text Content
• Understanding Success Criterion 2.5.3: Label in Name
• Understanding Success Criterion 4.1.2: Name, Role, Value

Relatos de uma pessoa cega

Para entender o que a falta de texto alternativo nas imagens representa na vida de uma pessoa cega ou com baixa visão, recomendo a leitura do artigo Migração de carreira: o impacto da acessibilidade na minha profissão, escrito por Ana Gouvêa.

Outras fontes

Se quiser buscar outras fontes, recomendo os Artigos do Movimento Web Para Todos sobre Descrição de Imagens.

Para quem prefere assistir vídeos, confira o resumão desse artigo no YouTube:

Obrigada por ler. Esperamos que isso seja útil para você. Agradecimento especial a Ana Gouvêa por revisar esse conteúdo ❤

O guia definitivo para descrição de imagens e ícones em sites, aplicativos e redes sociais. was originally published in Accessibility 4DEVS on Medium, where people are continuing the conversation by highlighting and responding to this story.

Escrito por: Marília Gabriele Suzart

O estado de foco é um recurso nativo do HTML, mas por falta de conhecimento Designers sacrificam a experiência em prol da estética.

Nesse artigo, vou te explicar o que é o estado de foco, para que ele serve e como unir UI e UX.

O que é

O estado de foco é uma comunicação visual para informar qual elemento está selecionado, quando estamos navegando pelo teclado ou controle remoto.

Ele é essencial para pessoas com deficiências motoras e muito útil para alguém que eventualmente quebrou o mouse.

Esse é um atributo do CSS chamado outline, o HTML coloca ele automaticamente para os elementos interativos, como botões e links. Mesmo sendo um recurso automático, ainda sim é uma barreira por causa das más práticas de codificação.

WCAG, critério de sucesso 2.4.7 Foco Visível (Nível AA): Qualquer interface de usuário operável por teclado deve ter um modo de operação em que o indicador de foco do teclado é visível.

Porque existem barreiras com o foco

Designers

O estado de foco automático também é acionado no clique, muitas pessoas que atuam como Designer pedem para as pessoas desenvolvedoras remove-lo, só porque acham que é “feio”.

Pessoas desenvolvedoras

Removem o outline porque a pessoa Designer pediu ou porque aprendeu a fazer assim em um curso. Além disso, fazem piadas com o HTML e não se preocupam em aprender semântica básica.

Cursos de programação

Seja na faculdade ou em bootcamps, as pessoas que ensinam programação negligenciam a acessibilidade nos projetos educacionais. As pessoas em início de carreira aprendem tudo errado e replicam isso na vida profissional.

Eu participei de alguns cursos de programação, no qual ensinaram a remover o outline sempre que começar um novo projeto. Conforme exemplo a seguir:

Uma dessas escolas é muito famosa e influente na comunidade de tecnologia, ensinando milhares de pessoas todos os anos.

Até quando as escolas de programação vão continuar ensinando a implementar barreiras de acesso na web?

Removendo a barreira

Designers

Ao criar o protótipo dos componentes, além dos estados de hover, pressed e disabled, também forneça o estado de focus.

Você pode usar as cores padrão do HTML, mas também é possível customizar a largura e cor da borda. Para isso certifique-se que o foco visível não ficará invisível.

A espessura ideal é 2 pixels, com cor sólida, contraste mínimo de 4.5:1 e área mínima de 1 pixel entre o elemento e a borda para destacar melhor o contraste.

Lembre que estamos falando de experiência (UX) e não estética (UI), o foco não é para ser bonito, ele precisa ser operável e perceptível.

Verifique as regras em rascunho da WCAG versão 2.2:
critério de sucesso 2.4.11 Aparência do foco (mínimo) (Nível AA)
critério de sucesso 2.4.12 Aparência do Foco (Aprimorado) (Nível AAA)

Pessoas desenvolvedoras

Procure no código os lugares onde tem outline: none; ou outline: 0; e substitua pelo trecho de código a seguir:

Caso precise customizar a cor e a espessura da borda, coloque essas configurações no focus-visible, conforme imagem a seguir:

Como testar

Navegue pela aplicação usando a tecla TAB para avançar para o próprio elemento e SHIFT + TAB para voltar.

Tente executar a tarefa, como por exemplo realizar o cadastro, sem o mouse, usando apenas o teclado. Verifique se é possível interagir com todos os campos, botões e links e se eles possuem o estado de foco visível.

Caso sinta dificuldade de localizar o elemento que está com o foco ativo, abra um bug descrevendo o problema encontrado.

Esse artigo é o material de apoio do nosso vídeo sobre o estado de foco:

Obrigada por ler. Espero que esse conteúdo seja útil para você e seu time☺

Estado de foco — A guerra entre UI e UX was originally published in Accessibility 4DEVS on Medium, where people are continuing the conversation by highlighting and responding to this story.

Você sabia que ao negligenciar a área mínima de toque, além de prejudicar a experiência e acessibilidade, você também está perdendo aproximadamente 2 pontos de SEO?

A WCAG e a Google possuem opiniões diferentes sobre a acessibilidade da área de toque, mesmo que você use a WCAG como referência, você ainda perderá pontos em SEO.

Não sabia disso? Vem comigo que vou te explicar as recomendações da WCAG e Google. Além disso, eu vou te ensinar um truque maravilhoso para implementar a área de mínima de toque, mantendo um visual minimalista e elegante.

Agora que chamei a sua atenção para ler esse artigo, antes de começar, gostaria de te convidar a pensar na acessibilidade além de cumprir a legislação e de melhorias do SEO.

Bora implementar a acessibilidade para as PESSOAS?

Quando projetamos botões, links e demais elementos clicáveis com uma boa área de toque, proporcionamos uma melhor experiência para todas as pessoas usuárias, principalmente, para pessoas com deficiências motoras, pessoas idosas e as pessoas com DCNA — Deficiências Cognitivas, Neuronais ou de Aprendizagem.

Você percebeu que eu destaquei “pessoas idosas”? Isso foi de propósito. Tem uma pergunta que me faço todos os dias antes de começar a trabalhar e gostaria que você reflita um pouco comigo.

Daqui a 5 ou 10 anos, eu vou conseguir usar a plataforma que eu estou projetando hoje?

Afinal, deficiências são adquiridas ao longo da vida e um dia inevitavelmente TODOS nós vamos precisar de acessibilidade, seja por algum acidente, uma doença ou apenas pelo processo natural de envelhecimento.

Quando projetamos interfaces para atender APENAS aos requisitos de robôs e da legislação, esquecemos do mais importante: as pessoas! Isso prejudica a acessibilidade, criando barreira para milhões de pessoas, inclusive para o nosso eu do futuro.

Então, agora que já refletimos um pouco, bora começar?

Esse artigo é o material de apoio do nosso vídeo no YouTube sobre a área de toque:

Explicando a WCAG

WCAG, versão 2.1, critério de sucesso 2.5.5 Tamanho da área clicável (Nível AAA): O tamanho da área clicável para entradas de ponteiro é de pelo menos 44 por 44 pixels CSS, com algumas exceções.

Esse é critério 2.5.5 é de nível de conformidade AAA (triple A), ou seja, não é obrigatório por lei, pelo menos não ainda.

Empresas que implementam a acessibilidade com o foco apenas na legislação, acabam descartando esse critério da lista de prioridades.

A equipe da WCAG percebeu que a área de toque é muito importante para a acessibilidade, na versão 2.2 que está em rascunho, teremos um novo critério relacionado a área de toque, que ainda pode sofrer alterações, mas que está assim atualmente:

WCAG, versão 2.2 em rascunho, critério de Sucesso 2.5.8 Espaçamento da área clicável (Nível AA): Para cada elemento clicável, deverá ter uma área com largura e altura de pelo menos 44 pixels CSS que o inclui, e nenhum outro elemento clicável, com algumas exceções.

Esse critério 2.5.8 é de nível de conformidade AA (duplo A), ou seja, obrigatório segundo a Lei Brasileira de Inclusão, Capitulo II, Artigo 63.

A seguir, duas imagens com uma breve explicação dessa nova regra que está em rascunho:

Eu recomendo utilizar a recomendação da Google, no próximo tópico eu vou explicar o motivo.

Explicando a recomendação da Google e SEO

Para incentivar a melhoria da acessibilidade na web, a Google coloca alguns problemas de acessibilidade como critérios para SEO. Assim, ela poderá melhorar a posição nas pesquisas para sites que são mais acessíveis.

Ao validar uma página com um botão ou link pequeno, o sistema de auditoria informa o seguinte:

As áreas de toque não estão dimensionadas corretamente: Os elementos interativos, como botões e links, precisam ser grandes o bastante (48x48 px) e ter espaço suficiente ao redor para poderem ser tocados sem sobreposição com outros elementos. Leia sobre a auditoria do Google.

Tem uma página de suporte de acessibilidade no Android sobre área de toque, com um tópico de Design que diz o seguinte:

Considere fazer alvos de toque com pelo menos 48 x 48dp, separados por 8dp de espaço ou mais, para garantir densidade e usabilidade de informações equilibradas. Um alvo de toque de 48x48dp resulta em um tamanho físico de cerca de 9 mm, independentemente do tamanho da tela. O tamanho de destino recomendado para objetos de tela sensível ao toque é de 7 a 10 mm.

Observe que a unidade de medida é dp e não px, ou seja, durante a implementação precisamos levar em consideração a densidade da tela e implementar o que seria equivalente à 48 pixels para aquele dispositivo.

Recomendação do GAIA — Guia de acessibilidade web focado nos aspectos do autismo

GAIA, G23 — Aparência clicável: Botões, menus, controles de formulários e demais elementos clicáveis devem apresentar uma área de clique ou toque maior para acomodar diferentes habilidades motoras de pessoas com TEA e devem apresentar um design que eles podem ser clicados ou pressionados.

E agora qual regra devo seguir?

Você pode conversar com o seu time e escolher o que fica melhor para o cenário e projeto que vocês estão atuando. Porém, cuidado para não confundir as pessoas e complicar a implementação da acessibilidade!

Como existe muitas regras e exceções, é comum que as pessoas fiquem confusas e apresentem resistência para implementar. Além disso, o trabalho fica mais complexo e aumenta as chances de cometermos erros, principalmente, quando tem vários times trabalhando no mesmo produto.

Simplifique a regra! E o trabalho de toda a equipe ao implementar a acessibilidade será mais simples.

Regra simplificada para WCAG:

Todos os elementos clicáveis, por exemplo botões, links, caixa de texto, etc… Precisam ter altura e largura mínima de 44 pixels.

Regra simplificada para WCAG + SEO da Google:

Todos os elementos clicáveis, por exemplo botões, links, caixa de texto, etc… Precisam ter altura e largura mínima de 48 pixels, separado por uma margem de no mínimo 8 pixels de outros elementos clicáveis.

Nos meus projetos eu sigo a recomendação do Google, pois sei que a experiência para as pessoas usuárias será ainda melhor.

Truques de implementação

Na percepção de algumas pessoas que trabalham como Designers, um botão maior pode ser esteticamente “feio”.

Não deveria ser necessário discutir que acessibilidade e experiência (UX), são mais importantes que esse conceito de “beleza”.

Mas, felizmente, existe uma solução para tornar acessível e manter o design minimalista e visualmente “agradável”. Vou mostrar para vocês um exemplo baseado em um projeto que eu já trabalhei:

Um card de produto com padding de 16 pixels e botões com 32 pixels de altura e 32 pixels de largura.

Na implementação, eu removi o padding do card. Para o primeiro bloco, eu coloquei os 16 pixels. Para o bloco onde estava os botões eu coloquei apenas 8 pixels, os outros 8 pixels ficaram livres para adicionar um padding dentro do botão aumentando a área de toque dele, conforme exemplo a seguir:

Ao fazer o protótipo, precisamos lembrar que 2 corpos não ocupam o mesmo lugar no espaço! Essa área transparente não pode ficar sobreposta na área transparente de outros elementos clicáveis. A seguir, um exemplo que apresentei para equipe de pessoas voluntárias de uma ONG:

Durante a prototipação, posicione os elementos considerando o tamanho e espaçamento, conforme imagem abaixo:

Nota para dev: Quando criar componentes reutilizáveis que recebe clique, como por exemplo o botão, você pode colocar min-width: 3rem e min-height: 3rem. Assim, você terá uma preocupação a menos na sua rotina.

Se você gostou desse conteúdo, não esqueça de bater muitas palmas e compartilhar com aquela pessoa que também precisa aprender isso.

Obrigada por ler. Espero que esse conteúdo seja útil para você ☺

Acessibilidade da área mínima de toque e como ela impacta o seu SEO… was originally published in Accessibility 4DEVS on Medium, where people are continuing the conversation by highlighting and responding to this story.

Escrito por: Marília Gabriele Suzart

Quando o assunto é acessibilidade, todas as pessoas que trabalham como Designers amam falar sobre as cores. Mas, ironicamente, poucas entendem como realmente torná-las acessíveis.

Se engana quem pensa que acessibilidade de cores é apenas para pessoas daltônicas, os critérios da WCAG relacionados as cores também são fundamentais para as pessoas com DCNA — Deficiências Cognitivas Neuronais ou de Aprendizagem.

A utilização incorreta das cores pode prejudicar a compreensão das pessoas com DCNA, como também gerar estresse e desconforto.

Nesse artigo, eu vou te contar um pouco da minha experiência trabalhando em equipes de produto, quais foram os principais erros relacionados as cores, os aprendizados que obtive e como trabalhar bem com as cores.

Esse artigo é o material de apoio do nosso vídeo no YouTube sobre as cores:

Dica: Esse vídeo é curto e didático, ideal para reproduzir em uma reunião. Você pode utiliza-lo para iniciar um papo com os times de Design e Branding.

Os 3 principais erros

Baseados na minha experiência em times de produtos, nos quais atuei como “embaixadora” da acessibilidade.

➀ Definir cor para a paleta baseada no contraste mínimo de 3:1

Em 2020, eu estava trabalhando como desenvolvedora em uma FoodTech, um certo dia eu comecei a estudar sobre as cores e fiz alguns testes de contraste, foi quando descobri que a cor principal do site tinha o contraste de 3.37:1. Conversei com o designer do meu time e informei que a cor não era acessível para textos pequenos. Ele me contou que há cerca de 3 meses atrás, havia feito um estudo de cores e fez os testes de contraste, mas mesmo assim decidiu manter essa cor pensando em usá-la apenas em textos grandes, como títulos e componentes gráficos, porém ele havia esquecido e acabou usando essa cor para tudo. Depois disso, trocamos a cor em todas as telas.

➁ Realizar os testes de contraste apenas com o fundo branco

Em 2021, eu comecei a trabalhar como voluntária na Lacrei, uma das primeiras coisas que fizemos foi realizar o estudo de cores. Para evitar o erro anterior, estabelecemos o contraste mínimo de 4.5:1 e montamos uma paleta maravilhosa, pelo menos era o que achávamos. O tempo passou, ocorreu várias mudanças na equipe, o produto evoluiu… Quando eu recebi os protótipos para revisão, encontrei vários problemas de contraste. Tinha card rosa com texto cinza e o texto tinha opacity que deixava a cor ainda mais clara. Tinha tela com fundo preto e texto roxo, também com baixo contraste. O time de Designers precisou fazer vários ajustes nos protótipos, antes de entregar para o desenvolvimento.

➂ Utilizar a cor como única fonte da verdade

Ao longo desses 2 anos de experiência com acessibilidade, absolutamente ninguém sabia da importância de utilizar outros elementos como um apoio visual, além da cor. Foram muitas solicitações de revisão de protótipos para corrigir isso.

Trabalhando com a Acessibilidade das Cores

Aqui vou resumir algumas premissas básicas que eu sigo para trabalhar com a acessibilidade das cores, com base na minha experiência.

Use o contraste mínimo de 4.5:1 como base

Crie uma paleta de cores, na qual todas combinações estejam com o contraste mínimo de 4.5:1. Assim, aumentamos o nosso público, pois mais pessoas terão acesso ao conteúdo e atendemos o nível de conformidade AA para qualquer fonte.

Existem várias ferramentas para testar o contraste das cores. Como por exemplo: o site Adobe Color. O plugin do Figma Stark. O plugin do Chrome Lighthouse que, além disso, faz várias validações básicas de acessibilidade e SEO. E o Storybook que serve para documentar o Design System e também realiza algumas validações de acessibilidade.

Experimente algumas e escolha qual é melhor para sua rotina de trabalho. A seguir, uma imagem de teste de contraste no Adobe Color:

WCAG, critério de Sucesso 1.4.3 Contraste (Mínimo) (Nível AA): A apresentação visual de texto e imagens de texto tem uma relação de contraste de pelo menos 4,5:1…

GAIA, Recomendação 1 — Vocabulário Visual e Textual: A cor de fundo deve ser diferente o suficiente da cor do objeto do primeiro plano e possui contraste adequado. Dê preferência para planos de fundo de cores claras ou branco para destacar os objetos ou textos do primeiro plano.

Documente todas as combinações testadas e aprovadas

Quando estamos desenvolvendo o Style Guide, precisamos pensar que depois, várias pessoas do time vão utilizar essa documentação como referência e que durante a evolução do produto muitas informações se perdem.

Documente as combinações, para que qualquer pessoa do time, mesmo as que ainda serão contratadas, saibam quais combinações são acessíveis. A imagem abaixo ilustra a documentação de uma cor feita pelo designer do meu time, após as nossas conversas sobre acessibilidade das cores.

Saiba que será impossível uma única cor atender a todas as cores de plano de fundo! Realize o teste de contraste, faça os ajustes necessários e documente todas as combinações que forem necessárias para o produto.

Além da cor, use outros elementos para transmitir informações

As cores são importantes, mas não podem ser a única forma de diferenciar o estado dos componentes na tela. Precisamos pensar nas pessoas que só enxergam escala de cinza e nas pessoas com deficiências cognitivas.

Entenda como é frustrante para uma pessoa usuária com Acromatopsia encontrar essa barreira na navegação de produtos digitais e como a solução é muito simples, como ela diz, “bastava apenas um sublinhado”. Assista ao TikTok de Jess Fontoura, navegando na Amazon Prime Video:

Para testar a escala de cinza, eu uso o plugin do Chrome Colorblindly. Eu ativo o modo Monocromacy / Achromatopsia e faço a análise das telas verificando se é possível diferenciar o estado dos componentes, como selecionado, marcado, desmarcado, ativo, desabilitado, bem como os feedbacks de erro e alertas. Exemplo de teste nas imagens abaixo:

Também é possível testar diretamente no iPhone, na opção filtros de cor, selecione a opção tons de cinza. O caminho é: Acessibilidade > Tela e Tamanho de Texto > Filtros de cor > Tons de cinza.

WCAG, critério de Sucesso 1.4.1 Uso de Cor (Nível A): A cor não deve ser usada como o único meio visual de transmitir informações, indicar uma ação, solicitar uma resposta ou distinguir um elemento visual.

GAIA, Recomendação 1 — Vocabulário Visual e Textual: Cores não devem ser a única forma de transmitir um conteúdo.

Forneça opção para customização das cores

A maioria dos dispositivos, fornecem opções para a pessoa usuária personalizar o aparelho. Antes de criar uma configuração interna para escolha de paleta de cores, faça o básico!

Certifique-se de que as customizações configuradas no dispositivo ou navegador estejam sendo respeitadas e funcionando adequadamente, como por exemplo, modo claro e escuro, reduzir transparência e aumentar contraste. Como também garantir que plugins de customização de páginas funcionem corretamente.

Para testar a customização em páginas web, eu uso o plugin do Google Chrome WebHelp, que além de customizar as cores do texto e do fundo, também customiza estilo de fonte, espaçamento entre linhas, espaçamento entre parágrafos, alinhamento do texto e outras funcionalidades.

Nota para dev: evite usar !important no CSS, pois prejudica a customização realizada pelos plugins de acessibilidade.

Gaia, Recomendação 5 — Customização: Permita às pessoas usuárias alterar o esquema de cores da página, incluindo um modo de alto contraste.

Reduza o esforço cognitivo

Alguns conceitos muito comuns, mas não menos importantes: Procure manter uma consistência das cores, por exemplo, mantenha todos os links com a mesma cor. Use cores intuitivas, por exemplo, vermelho para erro, verde sucesso e assim por diante.

GAIA, Recomendação 1 — Vocabulário Visual e Textual: Você pode utilizar cores para diferenciar seções de um site ou relacionar conteúdos similares.

Obrigada por ler. Espero que esse conteúdo seja útil para você ☺

Acessibilidade das Cores — Conheça os 3 principais erros e como resolver…. was originally published in Accessibility 4DEVS on Medium, where people are continuing the conversation by highlighting and responding to this story.

Assim, as pessoas com deficiência visual poderão ter uma experiência similar a das pessoas usuárias que são videntes.

Ao entregar o protótipo de uma nova funcionalidade para equipe de desenvolvimento, você pensou como será a experiência das pessoas com deficiência visual na aplicação? Se você não pensou sobre isso, você está deixando a responsabilidade para as pessoas que desenvolvem, que muitas vezes, não entendem sobre UX e tem dificuldade de realizar a tradução da jornada visual em uma experiência auditiva.

Se você deseja garantir experiências agradáveis para todas as pessoas usuárias — incluindo pessoas usuárias com deficiência visual, este artigo mostrará o passo a passo para fazer isso.

Um pouco do passado: nos últimos 1 ano e meio, eu trabalhei para um cliente no qual os produtos precisavam atingir o nível AA de conformidade com as diretrizes internacionais de acessibilidade (WCAG). Nesse projeto, um dos desafios que tive foi de como comunicar todos os detalhes de acessibilidade de um projeto para as pessoas que desenvolvem.

Meu colega, que participou de vários projetos de acessibilidade, sugeriu que eu entregasse notas de acessibilidade junto com o design.

Vamos começar a analisar item a item?

Como fazer notas de acessibilidade

Marque os pontos de referência, por exemplo, cabeçalho, conteúdo principal e rodapé.

Os pontos de referência são regiões na página para as quais os leitores de tela e outras tecnologias assistivas podem pular, assim as pessoas que usam essas tecnologias podem acessar as informações desejadas com menos esforço, ou seja, menos cliques. Por exemplo, se a pessoa usuária deseja entrar em contato com suporte para solicitar ajuda, é provável que esteja no rodapé, sem a marcação correta, caso haja uma barreira no meio da tela, a pessoa nunca vai conseguir conversar com o suporte.

Nota para dev: O cabeçalho, conteúdo principal e rodapé, são respectivamente as tags do HTML, <header>, <main> e <footer>.

Coloque uma função de pular para o conteúdo principal quando o cabeçalho tiver muitas opções (CTA — Call-to-Actions)

Normalmente, o cabeçalho permanece o mesmo durante toda a jornada da pessoa usuária. Para quem usa apenas o teclado — como pessoas cegas ou com dificuldades motoras — ao apertar a tecla tab precisar passar por todos os componentes do cabeçalho várias vezes é uma tortura. Fornecer uma função de pular para conteúdo principal economizará muito tempo.

Nota para dev: Um exemplo para referência é a página de pesquisa do Google, que ao navegar pelo teclado, exibe o botão “Ir para o conteúdo principal” que estava invisível. Ao clicar nele o foco é movido para o primeiro item da lista de resultados.

Cabeçalho da lista de acordo com a lógica do conteúdo

Os títulos definem a hierarquia da informação na sua página, o que permite que pessoas usando leitores de tela façam uma leitura dinâmica da página e identifiquem algo de interesse mais rápido. Um erro muito comum é confundir o tamanho da fonte com o nível de hierarquia do cabeçalho, os títulos devem ser definidos pensando na lógica e não no tamanho da fonte. Além disso, toda página deve possuir um título principal H1, em alguns casos, como landing page, esse título pode ser colocado de forma invisível, mas que será lido pelo leitor de telas.

Nota para dev: Uma referência para implementação é o site da Apple, no qual o título principal está invisível e o texto é o nome da própria empresa. Alguns atributos do CSS ocultam o conteúdo do leitor de telas como é o caso do display: none, para colocar conteúdos invisíveis, mas que sejam lidos pelo leitor de telas, use o mesmo CSS da classe visuallyhidden que está na captura de tela acima.

Marque a ordem da tabulação

A ordem da tabulação deverá ser aplicada apenas nos elementos que recebem o foco, ou seja são clicáveis, por exemplo, botões, links, campos de texto, etc. A ordem deve ser lógica. Por exemplo, ao fazer a reserva de um hotel, o componente de seleção de data deve estar antes do botão ‘reservar agora’, mesmo que visualmente o botão de reserva venha primeiro, é possível mudar a ordem através do código.

Adicione texto alternativo a imagens e ícones

O texto alternativo é uma palavra ou frase para explicar o conteúdo da imagem. É essencial para pessoas usuárias cegas e também ajuda qualquer pessoa que navega pelo conteúdo e tenha tido problemas para carregar a imagem.

Se a imagem for meramente ilustrativa, não é necessário colocar um texto alternativo, você pode colocar aria-hidden, assim o leitor de telas vai pular essa imagem. Porém, se essa imagem for importante para a compreensão do conteúdo ou para a navegação, você precisa colocar o texto alternativo. Por exemplo, os botões que possuem apenas ícone não são compreensíveis para pessoas com deficiência visual, como o menu de hambúrguer que precisamos declarar que o texto alternativo é ‘Menu’.

Além disso, se uma imagem desperta sentimentos emocionais, coloque um texto alternativo para oferecer uma experiência agradável para todas as pessoas. A melancia acenando triste mostra a emoção que desejamos que as pessoas usuárias sintam. Assim, podemos colocar um texto alternativo mesmo que seja possível sobreviver sem um.

Nota para dev: Dentro dos botões de ícone, coloque um span com texto alternativo e aplique o mesmo CSS da classe visuallyhidden, assim, mesmo que haja problemas para carregar imagens e CSS, qualquer pessoa, até mesmo o robô da Google, vai entender o que é esse botão. Além disso, use os ícones como svg para garantir que não serão serão lidos em duplicidade pelo leitor de telas e também que não será encontrado na pesquisa do Google Imagens.

Coloque dicas relacionadas a elementos interativos

E esta é a nota que fiz para as pessoas desenvolvedoras:

Sem informações adicionais, a pessoa cega não consegue preencher corretamente o campo de texto. Portanto, precisamos anexar informações de suporte a ele pelo atributo aria-describedby.

Aqui mostra como fazer a nota:

Nesse exemplo, se não fornecermos uma dica, as pessoas usuárias com deficiência visual ouvirão a mesma função duas vezes e podem ficar confusas, ‘Editar o que?’. Após colocar as dicas no botão, as pessoas usuárias podem entender qual é o botão para editar o e-mail e qual é para editar a senha.

Mostrar estado de foco de elementos interativos

O estado de foco é uma comunicação visual para informar qual elemento está selecionado, ele é essencial para pessoas com deficiências motoras. Ao navegar uma aplicação pelo teclado, tecla tab, voz ou até mesmo um controle remoto, se o foco não estiver visível, a pessoa usuária não terá ideia de onde está na página.

Nota para dev: ao iniciar um projeto muitas vezes colocamos outline: none para todas as tags do HTML, por favor remova essa linha de código! Ao invés disso, use o CSS da imagem ao lado, apenas onde for necessário, assim você removerá o outline do clique e o manterá para a navegação via teclado.

Anote as funções e estados para os elementos personalizados.

As funções WAI-ARIA são para comunicar como um componente personalizado se comporta. No exemplo, uma pessoa usuária pode marcar e desmarcar os cards. Esses recursos tornam os cards semelhantes ao radio button. Como não é um componente de radio button nativo, precisamos especificar seu nome ao entregá-lo.

Forneça designs para diferentes breakpoints

Você pode pensar: “Eu sei que os breakpoints são importantes. Mas como isso está relacionado à acessibilidade?” Na verdade, os breakpoints melhoram não apenas a usabilidade, mas também a acessibilidade. Por exemplo, quando você deseja aumentar o zoom em 200% para ler melhor o texto em um site.

Sem breakpoints definidos, o site não será fácil de navegar. Com os breakpoints definidos, o navegador pode personalizar a visualização e facilitar a operação em diferentes cenários.

Juntando tudo

Parece cansativo listar tantas notas. Não se preocupe, podemos combinar muitas anotações em uma visualização. Aqui está um exemplo:

Foi cansativo para mim no começo. Felizmente, percebi mais tarde que não preciso saber tudo, em vez disso, posso trabalhar em conjunto com as pessoas especialistas em acessibilidade e obter feedbacks.

Como revisar suas notas de acessibilidade?

Para começar, você precisa de uma pessoa especialista em acessibilidade para consultar por algumas horas. Quando seu design estiver pronto, revise-o e discuta-o com a pessoa que é especialista em acessibilidade. Ela vai corrigir erros, responder perguntas e fornecer exemplos. Depois de concluir as anotações de acessibilidade, compartilhe e analise-as com as pessoas desenvolvedoras.

Como revisar as implementações?

Quando a implementação estiver pronta, você poderá usar a tecla tab e o leitor de tela para navegar pela aplicação. Plugins como o Accessibility Insights for Web podem te ajudar a verificar se o site está acessível. Então você sabe que tudo é implementado de acordo com o plano — eles podem não cobrir tudo, mas já é um começo.

Assista ao vídeo do nosso canal falando sobre o Handoff de Acessibilidade

Teremos vídeos toda semana, nas versões inglês e português!

A versão original desse artigo foi escrito em inglês por Lisha Dai, com a autorização da mesma, foi traduzido e adaptado por Marília Gabriele Suzart, acesse o artigo original através do link: https://uxdesign.cc/how-to-hand-off-accessible-designs-to-developers-e10a0eeacaa6

Obrigada por ler. Esperamos que isso seja útil para você ☺

Como fazer o handoff de designs acessíveis para as pessoas desenvolvedoras… was originally published in Accessibility 4DEVS on Medium, where people are continuing the conversation by highlighting and responding to this story.