Muitas pessoas usam o desenvolvimento orientado por componentes com guias de estilo de padrões, bibliotecas de componentes ou sistemas de design completos no processo de 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 a construção de uma estrutura física, é importante construir uma peça de cada vez. Primeiro, a fundação, a estrutura, as paredes, as janelas, o telhado e tudo mais. As ferramentas de desenvolvimento baseadas em componentes nos permitem fazer isso em sites, apps e outros produtos digitais.
Algumas vantagens do desenvolvimento baseado em componentes incluem dividir os itens 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. Clientes, designers, gerentes de projeto e muito mais gostam porque podem visualizar o processo de build e usar um guia de estilo de vida como referência após o lançamento do site.
No entanto, quando analisamos padrões, componentes e sistemas de design com a acessibilidade em mente, surgem algumas perguntas. Como você sabe quais padrões são os melhores quando se trata de acessibilidade? É melhor usar um padrão/biblioteca estabelecido ou criar novos? Como você sabe se esses padrões realmente ajudarão seus usuários?
Com a infinidade de opções disponíveis, é fácil ficar confuso sobre esse tema. Este módulo visa fornecer informações gerais sobre como avaliar padrões, componentes e sistemas de design para acessibilidade, além de oferecer um ponto de partida para ajudar você a fazer escolhas mais acessíveis.
Pensar criticamente
Escolher um padrão, componente ou sistema de design acessível não é uma ciência de ponta, mas exige tempo e pensamento crítico. Na verdade, não existe "um padrão perfeito", mas pode haver muitas opções que poderiam funcionar. É uma questão de aprender a escolher a melhor opção para cada situação.
Nos próximos módulos de teste, você vai aprender mais sobre as técnicas e métodos para avaliar padrões, componentes e sistemas de design para acessibilidade. Mas, antes dessa etapa, é preciso dar um passo para trás e fazer algumas perguntas fundamentais a si mesmo, como:
- Já existe um padrão, componente ou sistema de design acessível estabelecido?
- Quais navegadores e tecnologia adaptativa (AT) são compatíveis?
- Preciso considerar alguma limitação de código/framework ou outras integrações/fatores/necessidades do usuário?
Dependendo do seu ambiente de desenvolvimento e das necessidades do usuário, você pode ter perguntas adicionais ou diferentes em relação a elas. Considere essas perguntas como seu ponto de partida na avaliação de acessibilidade.
Recursos estabelecidos
Antes de criar algo novo, analise 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 ou várias soluções que atendam às suas necessidades.
Alguns ótimos recursos para padrões, componentes e sistemas de design acessíveis incluem:
- Componentes acessíveis
- Biblioteca ARIA da Universidade Deque
- Sistema de design Gov.UK
- Componentes inclusivos
- MagentaA11y (em inglês)
- U.S. Web Design System (USWDS), criado para o governo federal dos Estados Unidos
- Lista de estampas acessíveis da Smashing Magazine
Para frameworks do JavaScript, os recursos abaixo podem ser acessados de forma imediata ou são fáceis de personalizar quanto à acessibilidade:
- Quando o CSS não é suficiente: requisitos de JavaScript para componentes acessíveis
- Reagir
- Angular: biblioteca do Material Design (em inglês)
- Vue: Vuetensils
No entanto, e isso não é suficientemente enfatizado, você nunca deve apenas copiar/colar o código e presumir que ele vai se encaixar no seu ambiente e atender automaticamente às necessidades do usuário. Isso é verdade para todos os padrões, componentes e sistemas de design, mesmo que sejam rotulados como totalmente acessíveis.
Todos os recursos devem ser vistos como um ponto de partida. Não deixe de testar tudo.
Compatibilidade com navegadores e tecnologia assistiva (TA)
Depois de pesquisar alguns padrões básicos, componentes ou um sistema de design completo que pode funcionar para seu ambiente de desenvolvimento, você pode passar para o suporte à tecnologia adaptativa. Um tipo importante de TA em que você precisa se concentrar ao avaliar padrões, componentes e sistemas de design são os leitores de tela.
Os leitores de tela foram desenvolvidos com navegadores específicos em mente e funcionarão melhor quando pareados com esses navegadores. Entraremos nesse tópico com muito mais detalhes no módulo sobre testes de TA, 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 |
|---|---|---|---|
| Acesso ao trabalho com a fala (JAWS) | Windows | Chrome, Firefox, Edge | Licença obrigatória (há uma versão sem custo financeiro de 40 minutos) |
| Acesso não visual da área de trabalho (NVDA) | Windows | Chrome e Firefox | Sem custo financeiro (exige download) |
| Narrator | Windows | Edge | Sem custo financeiro (integradas às máquinas Windows) |
| VoiceOver | macOS | Safari | Sem custo financeiro (integrada em máquinas macOS) |
| Orca | Linux | Firefox | Sem custo financeiro (integradas às distribuições baseadas em Gnome) |
| TalkBack | Android | Chrome e Firefox | Sem custo financeiro (integrada a algumas versões do SO Android) |
| VoiceOver | iOS | Safari | Sem custo financeiro (integradas aos dispositivos iOS) |
O suporte ao navegador geralmente é complicado, e as coisas ficam ainda mais complicadas quando você adiciona dispositivos AT e especificações ARIA à combinação.
Mas nem todas são más notícias. Felizmente, ótimos recursos como Acessibilidade HTML5, Suporte à acessibilidade e a Lista de verificação de desenvolvimento acessível de controle personalizado da WCAG nos ajudam a entender melhor o suporte atual a navegadores e dispositivos de AT e até mesmo quando usar ARIA.
Esses recursos descrevem os diferentes subelementos de padrão HTML e ARIA disponíveis, incluindo testes da comunidade de código aberto. Você também pode analisar alguns exemplos de padrão para computadores e navegadores móveis/dispositivos AT. Assim, esses recursos podem ajudar você a tomar uma decisão mais acessível sobre padrões, componentes e sistemas de design que você queira usar.
Outras considerações
Depois de escolher alguns padrões ou componentes base acessíveis e considerar o suporte a dispositivos de navegador e AT, você pode avançar para perguntas contextuais mais específicas sobre padrão, componente, sistema de design e ambiente de desenvolvimento.
Por exemplo, se você estiver trabalhando em um sistema de gerenciamento (CMS) ou tiver um código legado, pode haver algumas limitações quanto aos padrões que podem ser usados. Após a revisão, várias opções de padrão podem ser rapidamente cortadas para uma ou duas opções.
Muitos frameworks JavaScript permitem que os desenvolvedores usem quase qualquer padrão que escolherem. Nesses casos, você pode ter menos restrições e escolher a opção de padrão mais acessível.
Há outras considerações a serem feitas ao escolher um padrão, componente ou sistema de design, como:
- Performance
- Segurança
- Otimização de mecanismos de pesquisa
- Suporte à tradução de idiomas
- Integrações de terceiros
Esses fatores certamente influenciam sua escolha de 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 relacionadas a conteúdo gerado pelo editor ou pelo usuário, além de ser criado de uma maneira que os desenvolvedores de todo o conhecimento de acessibilidade possam usar.
Teste seu conhecimento
Teste seu conhecimento sobre padrões
Os componentes acessíveis sempre permanecem acessíveis para os usuários?