Por que ter um design system acessível?
Saiba qual o papel da acessibilidade na experiência do seu projeto e como construir um
Esta é a parte três da nossa série sobre a construção do Bold, o design system do Laboratório Bridge. Acesse o primeiro e o segundo conteúdos.
Acessibilidade web vem ganhando cada vez mais espaço no desenvolvimento de software. Não é ao acaso — segundo o World Disability Report de 2011, um bilhão de pessoas vivem com alguma forma de deficiência. Isso representa mais de 13% da população mundial.
Aqui no Brasil esse número é ainda mais expressivo: o último censo indica que 45,6 milhões de pessoas têm algum tipo de deficiência — quase 24% dos brasileiros. Ah, e o acesso à informação é um direito de todo cidadão, garantido pela Constituição Federal.
Ou seja, construir um espaço na web com usabilidade para esta parcela da população não é só “legal” — é realmente necessário. Na realidade, a Web foi fundamentalmente projetada para funcionar para todas as pessoas — independentemente de hardware, software, idioma, local ou capacidade.
O problema é que se sites, aplicativos ou ferramentas são mal projetados, são criadas barreiras que dificultam ou até impedem as pessoas de usarem a Web.
Desejamos uma acessibilidade por uma sociedade inclusiva, constituída de indivíduos que enxerguem o que há a frente das deficiências: pessoas. Que percebam o que há por trás das incapacidades: falta de tecnologia, conhecimento e atitude. Toda incapacidade tem uma solução a espera de ser descoberta. A acessibilidade já está aí, olhando para todos e esperando ser aplicada
– Marco Antônio de Queiroz, cego e especialista consultor em acessibilidade web
Por isso, aqui no Bridge temos como objetivo garantir o acesso à informação e proporcionar a mesma experiência a todos os usuários — independentemente de suas capacidades físicas e cognitivas ou da plataforma e das tecnologias utilizadas.
Mas como garantimos isso?
O primeiro passo foi construindo o Bold, nosso design system para aplicações web. Os componentes seguiram as especificações da WCAG — Web Content Accessibility Guidelines, ou Diretrizes de Acessibilidade para o Conteúdo da Web.
B_thinking: o modelo de processo de UX do Bridge, agora para todos!
Existem 3 níveis de conformidade no WCAG: A, AA e AAA. Quanto mais ‘alto’ o nível, maior o impacto no visual das páginas e mais restrito o design. No Bold, optamos por seguir as recomendações no nível de conformidade AA.
Confira agora o checklist das práticas de design que você deve seguir para garantir que seu design system seja acessível a todos.
1. Projetando os componentes
Após ler e reler as recomendações da WCAG, conseguimos elencar os requisitos necessários para a equipe do Design desenvolver a parte gráfica dos componentes. Aqui estão eles:
#1 Projete um foco visível
No Bold, usamos uma borda azul de 2px, como é recomendado pelo e-MAG, o Modelo de Acessibilidade em Governo Eletrônico. O foco ajuda os usuários a navegar pela tela e entender rapidamente onde estão.
Ps.: o outline é uma função nativa do CSS, mas acaba sendo removida por funções estéticas :(
Este é o link para as especificações de foco visível da WCAG.
#2 Garanta um contraste suficiente
Garanta que todos os componentes tenham contraste suficiente entre o componente e o fundo. No geral, texto e imagens devem atingir um contraste mínimo ideal de 4,5:1 (para fontes iguais ou inferiores a 14px).
Esse requisito é necessário para pessoas com alguma deficiência visual, mas também beneficia usuários com monitores de resolução baixa. Além disso, garante que o conteúdo funcionará em diferentes condições de iluminação, como luz solar e brilho.
Este é o link para as especificações de contraste da WCAG.
Listamos algumas ferramentas que podem te ajudar a construir componentes com bom contraste!
- WebAIM Contrast Checker é um site para verificar contraste
- ColorSafe gera uma paleta acessível de acordo com o estilo de texto e cor de fundo
- Stark é um plugin para o Sketch, Figma e XD
- E aqui temos um artigo da WebAIM sobre contraste.
#3 Não use (apenas) a cor como informação
Para transmitir informações, indicar uma ação, pedir resposta ou distinguir um elemento visual, combinações com outros elementos são mais eficientes.
Mas existem exceções: logotipos e elementos desabilitados estão isentos desse padrão.
Este é o link para as especificações do uso de cor da WCAG.
#4 Apresente os links de forma clara e visível
O link deve ser facilmente identificado do restante do texto e deve utilizar descrições claras sobre as ações que irão ocorrer. Não use expressões como “clique aqui” ou apenas “aqui”.
Notou como nossos links estão bem explícitos neste artigo? :)
Este é o link para as especificações de propósito do link da WCAG.
#5 Mantenha uma experiência consistente
Garanta que os componentes que se repetem pela interface serão apresentados na mesma ordem ou sigam o mesmo padrão de funcionamento.
Este é o link para as especificações de navegação consistente da WCAG.
#6 Utilize uma hierarquia de títulos apropriada
Além de proporcionar uma hierarquia visual para seu conteúdo, ordenar os títulos ajuda usuários de leitores de tela, já que eles utilizam esta estrutura para navegar pela página.
Na hora de construir uma tela, também é importante pensar na hierarquia das informações para que a leitura seja linear.
Imagine um leitor de tela na interface que você desenvolveu.
A ordem das informações faz sentido?
Este é o link para as especificações de cabeçalho da seção da WCAG.
#7 Não esqueça dos formulários
- Garanta que as labels não desapareçam quando o input receber foco.
- Este é o link sobre labels ou instruções da WCAG
- Indique quais campos são obrigatórios usando uma legenda.
- Este é o link sobre indicação de campos obrigatórios da WCAG
- Ajude os usuários a corrigir e evitar erros. Forneça instruções descritivas, mensagens de erro claras e sugestões para correção.
- Este é o link sobre sugestão de erros da WCAG
#8 Escreva bons textos alternativos
Por último, mas não menos importante, a construção de textos alternativos (apesar de não ser realizado durante o desenvolvimento dos componentes gráficos) é um requisito que merece atenção.
O objetivo de fornecer estes textos é transmitir a mesma informação e contexto que é recebida por pessoas que podem ver. Tenha cuidado para não usar palavras subjetivas (separamos uma palestra sobre descrição de imagens pra te ajudar).
Este é o link para as especificações de conteúdo não textual da WCAG.
Mas hey, esses são apenas alguns requisitos! É importante que você leia a WCAG e identifique os requisitos para o seu projeto. O Marcelo Sales fez um post bem legal falando sobre quem é responsável por aplicar a acessibilidade em projetos digitais.
Ok, então depois de ler a WCAG, identificar meus requisitos, planejar todos os meus componentes… o projeto acabou?
Nada disso! Agora é a hora de colocá-lo em prática.
2. Implementando os componentes
Para exemplificar essa etapa, vamos descrever como fizemos com o nosso design system. Primeiro, para a construção dos componentes do Bold, uma das principais documentações foi a WAI-ARIA Authoring Practices 1.1, da W3C.
Lá você encontra detalhes de implementação, boas práticas e design patterns para a construção de componentes comuns em páginas web, como botões, checkboxes e caixas de diálogo (modais). A documentação inclui regras gerais e atributos HTML que devem ser utilizados em cada situação.
Já para a prototipação e validação dos componentes codificados, utilizamos o Storybook, uma ferramenta open source de prototipação e documentação de componentes. Ele cria um ambiente isolado, onde o componente pode ser testado e validado de forma individual.
Você pode conferir o storybook do Bold através do link: https://bold.bridge.ufsc.br/storybook/.
Utilizamos também o addon @storybook/addon-a11y, que checa por problemas comuns de acessibilidade que podem ter sido incluídos no HTML do componente.
Por fim, utilizamos React para a implementação dos componentes do design system.
Separamos a seguir alguns links extras que podem te ajudar:
- Este é o Curso Web Accessibility, fornecido pelo Google
- A11yproject.com é uma database com diversos materiais sobre acessibilidade em diferentes formatos
- Por fim, Inclusive components é um blog dedicado exclusivamente ao assunto
#Resultados
O Bold permite o desenvolvimento acessível, fornecendo componentes semanticamente corretos, cada um com sua marcação ARIA apropriada. Assim, eles podem ser corretamente identificados por tecnologias assistivas.
Agora atenção! É importante ter em mente que o design system é apenas a base para o desenvolvimento de aplicativos acessíveis.
Utilizar um design system acessível não garante que seu projeto será acessível.
Recomendamos que você analise e teste seus aplicativos (de preferência com usuários reais — nada sobre “nós sem nós”, ok?) para garantir que eles estejam em conformidade com os padrões WCAG. Nesse link, Nathan Curtis fala sobre outros cuidados no desenvolvimento.
Nosso próximo post será sobre os testes de acessibilidade que realizamos aqui no Laboratório, então siga nossa página e ative as notificações para não perder!
Acesse a versão em inglês deste artigo.
O Laboratório Bridge atua no Centro Tecnológico da Universidade Federal de Santa Catarina (CTC/UFSC), com equipes formadas por bolsistas graduandos, pós-graduandos e profissionais contratados. É orientado por professores do CTC e do Centro de Ciências da Saúde (CCS/UFSC).
Desde 2013, desenvolvemos sistemas e aplicativos para gerenciamento da saúde pública em parceria com o Ministério da Saúde e a Agência Nacional de Vigilância Sanitária (ANVISA).
