Serviços de Acessibilidade no Design
Um estado de foco em falta é uma edição de cinco minutos num ficheiro de design. O mesmo problema depois do desenvolvimento obriga um programador a reescrever código funcional. Revemos os seus designs e o seu design system face às WCAG, para que a sua equipa possa lançar interfaces que funcionam melhor para utilizadores de leitores de ecrã, teclado e controlo por voz desde a primeira versão.
Organizações confiam em nós a construir experiências digitais mais acessíveis.
Porque é que a acessibilidade pertence à fase de design?
Os rácios de contraste, a ordem de foco, o tamanho das áreas de toque e as mensagens de erro são todos decisões de design. Cada uma delas apoia ou bloqueia alguém que utiliza tecnologia de apoio, e cada uma é definida muito antes de existir código front-end. Tratá-las cedo é mais barato e mais simples. Uma correção no design custa a edição de um ficheiro. A mesma correção depois do lançamento custa alterações de código, novos testes e uma nova versão.
Menor custo de correção — Problemas resolvidos antes de chegarem ao código-fonte.
Barreiras evitadas, não remendadas — Padrões que excluem utilizadores de teclado ou de leitores de ecrã são detetados antes de serem lançados.
Coerência do design system — Um componente de origem corrigido, todos os ecrãs melhorados.
Menos surpresas na auditoria — Design já avaliado face aos critérios que a auditoria vai usar.
O que está incluído?
Auditoria de acessibilidade do design
Os mockups atuais ou um produto em produção são revistos critério a critério face às WCAG.
Capacitação da equipa de design
Práticas de design acessível através de sessões e listas de verificação personalizadas para os componentes e o sistema de design que a sua equipa de design utiliza.
Integração no design system
Os componentes partilhados são corrigidos na origem, para que a correção chegue a todos os ecrãs construídos a partir deles.
Documentação de entrega anotada
Os papéis ARIA, a ordem de foco e a intenção do texto alternativo são documentados onde os programadores os vão realmente ler.
Especificação de interação e protótipo
A ordem de tabulação, a gestão do foco em sobreposições e as mudanças de estado dinâmicas são definidas, e não deixadas à interpretação.
Design de componentes de UI acessíveis
Menus pendentes, modais, campos de formulário e tabelas de dados são desenhados com o comportamento de teclado e de leitor de ecrã já resolvido.
Tudo é entregue dentro dos seus ficheiros de design existentes, e não como um documento separado que a sua equipa tenha de traduzir.
Qual é a diferença entre design inclusivo e design acessível?
O design inclusivo é a abordagem mais ampla. Considera toda a diversidade humana, incluindo deficiência, idade, língua, ambiente e limitações temporárias ou situacionais. Molda a forma como uma equipa pensa sobre para quem é um produto.
O design acessível é a parte mensurável. Remove barreiras para pessoas com deficiência face a critérios definidos como as WCAG, o que o torna testável e verificável. Os dois não são alternativas. As legendas são o exemplo clássico: um requisito de design acessível para utilizadores surdos e um benefício inclusivo para qualquer pessoa que veja vídeo sem som.
O design inclusivo fornece a mentalidade, o design acessível fornece a medição, e um produto maduro precisa de ambos.
Como apoiamos o seu fluxo de trabalho de design?
Diagnóstico e auditoria de base
Os designs existentes ou o produto em produção são revistos face às WCAG, com cada problema classificado por gravidade.
Revisões de design e prototipagem
Os wireframes e os mockups de alta fidelidade são verificados à medida que são produzidos, enquanto as correções ainda são edições rápidas.
Trabalho no design system e nos componentes
Os componentes partilhados são auditados e corrigidos uma vez na origem, em vez de repetidamente em cada ecrã.
Entrega anotada
Os designs seguem para desenvolvimento com os padrões de teclado, a gestão do foco e a intenção ARIA documentados.
Verificação pós-construção
Os ecrãs implementados são verificados face à intenção do design para confirmar que as decisões de acessibilidade sobreviveram à construção.
O que é exatamente corrigido no código?
- Contraste de cor suficiente
- Indicadores de foco visíveis
- Nunca depender apenas da cor
- Navegação previsível
- Posicionamento coerente das ações principais
- Tamanho adequado das áreas de toque
- Botões de ícone com rótulo
- Refluxo e redimensionamento do texto
- Contentores flexíveis
- Hierarquia visual clara
- Ordem de foco definida
- Texto de ligação descritivo
- Espaçamento entre alvos
- Mensagens de erro claras
- Rótulos de formulário programáticos
- Gestão do foco em modais
- Tabelas de dados acessíveis
Um rótulo cinzento-claro sobre branco pode parecer limpo e ainda assim falhar para quem não consegue distinguir os dois, razão pela qual cada um destes pontos é medido e não avaliado a olho.
Que normas utilizamos na acessibilidade do design?
WCAG 2.2 AA
Utilizado como estrutura técnica de base para associar as decisões de design aos requisitos de acessibilidade.
ADA
Considerada na avaliação dos requisitos legais aplicáveis ao trabalho de acessibilidade digital nos EUA; os critérios WCAG orientam a implementação técnica.
EAA
Ajuda a avaliar as decisões de design face aos requisitos de acessibilidade dos produtos e serviços abrangidos na União Europeia.
Section 508
Aplica-se às TIC utilizadas pelas agências federais dos EUA. Aos fornecedores que lhes vendem é normalmente pedido que demonstrem conformidade.
EN 301 549
A norma europeia que se alinha com as WCAG e abrange também software e documentação.
Documentamos os resultados da revisão ao nível do componente e do ecrã, indicando claramente aos designers e programadores que alterações fazer.
Porquê a WeAccess.ai na Revisão de Acessibilidade do Design?
| Critério | Ferramenta automática de contraste | Auditoria pós-lançamento | Revisão de design WeAccess.Ai |
|---|---|---|---|
| Quando os problemas surgem | Depois de o ecrã ser construído | Depois do lançamento do produto | YesNo ficheiro de design |
| Coverage | Apenas contraste | Abrangente, num dado momento | YesAbrangente, critério a critério |
| Interação e ordem de foco | Não avaliada | Avaliada no código | YesEspecificada antes da construção |
| Custo de corrigir um problema | Alteração de código | Alteração de código e novo teste | YesUma edição de ficheiro |
| Efeito em ecrãs futuros | None | Repetido no ciclo seguinte | YesCorrigido no design system |
Muitas das falhas de acessibilidade encontradas numa auditoria foram decididas num mockup meses antes.
Porquê escolher a nossa equipa de design acessível?
Competência de design e de código numa só equipa
Um problema de contraste no Figma e um erro de foco num componente são tratados pelas mesmas pessoas, e não divididos entre fornecedores.
Correções feitas uma vez, na origem
As correções chegam aos seus componentes partilhados, pelo que o defeito deixa de reaparecer em cada novo ecrã.
Acessibilidade que funciona para todos
Alvos maiores, hierarquia clara e ligações descritivas tornam a navegação mais fácil para todos.
Turco, inglês e alemão
Revemos os textos da interface nas três línguas e reportamos naquela em que a sua equipa trabalha.
Competência, não dependência
Os seus designers ficam com os padrões, as anotações e as listas de verificação depois de o projeto terminar.
FAQ
Ainda tem dúvidas? Consulte a nossa secção completa de perguntas frequentes.
Ambos. Os produtos existentes começam normalmente por uma auditoria de base, enquanto o trabalho de design em curso é revisto à medida que é produzido.
WCAG 2.2 AA is the default, since it is the level nearly every law and procurement requirement points to. Where a specific AAA criterion matters for your audience, we flag it and you decide.
No início custa muito pouco; na maior parte dos casos é apenas uma forma diferente de tomar a mesma decisão. A versão cara é corrigir o mesmo problema no código depois do lançamento.
Sim. As sessões de capacitação e as listas de verificação de componentes fazem parte do projeto, para que os seus designers possam aplicar os padrões sem nós no ecrã seguinte.
Condiciona algumas escolhas, como o contraste e o tamanho dos alvos, mas não impõe um estilo visual. A maior parte do trabalho está nos estados, na ordem e na rotulagem, e não na estética.
Sim. Trabalhamos no Figma a par da sua equipa, anotando componentes e correções no próprio ficheiro em vez de produzir um documento separado.
Construa experiências digitais que todos podem usar.
Veja como o WeAccess pode ajudar a sua organização a gerir a acessibilidade na web, no mobile, nos documentos e nos conteúdos multimédia.