Muitas pessoas usam o desenvolvimento orientado a componentes com guias de estilo de padrões, bibliotecas de componentes ou sistemas de design completos no fluxo de trabalho de desenvolvimento. Mesmo que você não tenha usado essas ferramentas formalmente, é provável que use um processo semelhante para dividir um design grande de um site, app ou outro produto digital em partes gerenciáveis.
Assim como construir uma estrutura física, é importante construir uma parte de cada vez. Primeiro, a fundação, a estrutura, as paredes, as janelas, o telhado e tudo mais. As ferramentas de desenvolvimento orientadas a componentes permitem que façamos isso em sites, apps e outros produtos digitais.
Algumas vantagens do desenvolvimento orientado a componentes incluem a divisão de coisas em partes gerenciáveis, para que haja menos tempo de desenvolvimento com esses componentes reutilizáveis. Ele permite que designers, desenvolvedores de front-end e back-end e QA trabalhem simultaneamente. E clientes, designers, gerentes de projeto e outros profissionais gostam disso porque podem ter uma prévia do processo de criação e usar um guia de estilo dinâmico como referência após o lançamento do site.
No entanto, quando olhamos para padrões, componentes e sistemas de design com acessibilidade em mente, algumas questões surgem. Como saber quais padrões são melhores quando se trata de acessibilidade? Você deve usar um padrão ou biblioteca já estabelecidos ou criar novos? Como você sabe se esses padrões realmente vão ajudar seus usuários?
Com a infinidade de opções disponíveis, é fácil se confundir sobre padrões, componentes e sistemas de design. O objetivo deste módulo é fornecer informações gerais sobre como avaliar padrões, componentes e sistemas de design para acessibilidade e dar um ponto de partida para ajudar você a fazer escolhas mais acessíveis.
Pense criticamente
Escolher um padrão, componente ou sistema de design acessível não é ciência nuclear, mas exige tempo e pensamento crítico. Na verdade, não existe algo como "um padrão perfeito", mas pode haver muitas opções que poderiam funcionar. É preciso aprender a escolher a melhor opção para sua situação específica.
Nos módulos de teste seguintes, você vai ler mais sobre as técnicas e os métodos para avaliar padrões, componentes e sistemas de design para acessibilidade. Antes de chegar lá, você precisa fazer algumas perguntas fundamentais, como:
- Um padrão, componente ou sistema de design acessível já existe?
- Quais navegadores e tecnologias adaptativas (AT) eu estou apoiando?
- Há alguma limitação de código ou framework? Há outras integrações, fatores ou necessidades do usuário que preciso considerar?
Dependendo do ambiente de desenvolvimento e das necessidades do usuário, você pode ter outras perguntas ou diferentes das mostradas aqui. Considere estas perguntas como ponto de partida na avaliação de acessibilidade.
Recursos estabelecidos
Antes de criar algo novo, faça a devida diligência e revise o que já existe em termos de padrões, componentes e sistemas de design acessíveis. Com um pouco de pesquisa, você pode se surpreender ao encontrar uma solução (ou várias) que atenda às suas necessidades.
Alguns ótimos recursos para padrões, componentes e sistemas de design acessíveis incluem:
- Componentes acessíveis
- Biblioteca ARIA da Deque University
- Gov.UK Design System (link em inglês)
- Componentes inclusivos
- MagentaA11y
- U.S. Web Design System (USWDS), criado para o governo federal dos Estados Unidos
- Lista de padrões acessíveis da Smashing Magazine
Para frameworks JavaScript, os seguintes recursos são bastante acessíveis por padrão ou personalizáveis para acessibilidade:
- Quando o CSS não é suficiente: requisitos de JavaScript para componentes acessíveis
- React
- Angular: Biblioteca Material
- Vue: Vuetensils (link em inglês)
No entanto, e isso não pode ser enfatizado o suficiente, nunca copie e cole código e suponha que ele se encaixa no seu ambiente e atende automaticamente às necessidades do usuário. Isso é verdade para todos os padrões, componentes e sistemas de design, mesmo se rotulados como totalmente acessíveis.
Todos os recursos devem ser vistos como um ponto de partida. Não se esqueça de testar tudo.
Suporte a navegadores e tecnologias adaptativas (TA)
Depois de pesquisar alguns padrões, componentes ou um sistema de design completo que podem funcionar no seu ambiente de desenvolvimento, você pode passar para o suporte a tecnologia auxiliar. Um dos principais tipos de AT em que você vai querer se concentrar ao avaliar padrões, componentes e sistemas de design são os leitores de tela.
Os leitores de tela foram criados pensando em navegadores específicos e funcionam melhor quando usados com esses navegadores. Vamos abordar esse tópico com mais detalhes no módulo sobre testes de AT, mas, para fins de avaliação de padrões, é útil entender que essas combinações existem para que você saiba o que precisa em termos de suporte.
| Leitor de tela | SO | Compatibilidade com navegadores | Custo |
|---|---|---|---|
| Job Access with Speech (JAWS) | Windows | Chrome, Firefox e Edge | Licença necessária (existe uma versão sem custo financeiro de 40 minutos) |
| Non-Visual Desktop Access (NVDA) | Windows | Chrome e Firefox | Sem custo financeiro (requer download) |
| Narrator | Windows | Edge | Sem custo financeiro (incorporado a máquinas Windows) |
| VoiceOver | macOS | Safari | Sem custo financeiro (integrado a máquinas macOS) |
| Orca | Linux | Firefox | Sem custo financeiro (incorporado a distribuições baseadas no Gnome) |
| TalkBack | Android | Chrome e Firefox | Sem custo financeiro (incorporado a determinadas versões do SO Android) |
| VoiceOver | iOS | Safari | Sem custo financeiro (integrado a dispositivos iOS) |
O suporte do navegador geralmente é complicado, e as coisas ficam ainda mais complicadas quando você adiciona dispositivos de AT e especificações ARIA.
Mas nem tudo são más notícias. Felizmente, ótimos recursos, como acessibilidade HTML5, suporte à acessibilidade e lista de verificação de desenvolvimento acessível de controle personalizado do WCAG nos ajudam a entender melhor o suporte atual do navegador e do dispositivo de AT e até quando usar a ARIA.
Esses recursos descrevem os diferentes elementos HTML e ARIA disponíveis, incluindo testes da comunidade de código aberto. Você também pode conferir alguns exemplos de padrões para computadores, navegadores para dispositivos móveis e dispositivos de AT. Assim, esses recursos podem ajudar você a tomar uma decisão mais acessível em relação a padrões, componentes e sistemas de design que você pode querer usar.
Outras considerações
Depois de escolher alguns padrões ou componentes básicos acessíveis e considerar o suporte ao navegador e ao dispositivo AT, você pode passar para perguntas contextuais mais específicas sobre o padrão, o componente, o sistema de design e o ambiente de desenvolvimento.
Por exemplo, se você estiver trabalhando em um sistema de gerenciamento (CMS) ou tiver um código legado, talvez haja algumas limitações quanto aos padrões que podem ser usados. Após a análise, várias escolhas de padrões podem ser rapidamente reduzidas a uma ou duas opções.
Muitos frameworks JavaScript permitem que os desenvolvedores usem quase qualquer padrão escolhido. Em casos como esses, você pode ter menos restrições e escolher a opção de padrão mais acessível.
Há outras considerações a serem ponderadas ao escolher um padrão, componente ou sistema de design, como:
- Desempenho
- Segurança
- Otimização de mecanismos de pesquisa
- Suporte a tradução de idiomas
- Integrações de terceiros
Esses fatores certamente influenciam na escolha do padrão, mas você também precisa considerar as pessoas que criam o conteúdo e o código. O padrão escolhido precisa ser robusto o suficiente para lidar com possíveis limitações em relação a conteúdo gerado pelo editor ou pelo usuário, além de ser criado de uma forma que todos os desenvolvedores de acessibilidade possam usar.
Teste seu conhecimento
Teste seus conhecimentos sobre padrões
Os componentes acessíveis sempre permanecem acessíveis para os usuários?