Curso Gratuito de Automação de Testes Para Iniciantes

Disponível no
Youtube

 

Habilidades básicas que podem ajudar seu time a construir um projeto acessível (Parte 1)

acessibilidade

Habilidades básicas que podem ajudar seu time a construir um projeto acessível (Parte 1)

Afinal, o que é Acessibilidade na Web?

A Cartilha de Acessibilidade na Web da W3C diz:

“Acessibilidade na web significa que pessoas com deficiência podem usar a web. Mais especificamente, a acessibilidade na web significa que pessoas com deficiência podem perceber, entender, navegar, interagir e contribuir para a web. E mais, ela também beneficia outras pessoas, incluindo pessoas idosas com capacidades em mudança devido ao envelhecimento”

O World Wide Web Consortium (W3C) é uma comunidade internacional em que as organizações e seus membros trabalham juntos para desenvolver padrões da Web. A principal atividade do W3C é desenvolver protocolos e diretrizes que garantam crescimento a longo prazo para a Web.

Nessas recomendações foram elaborados diversos níveis de abordagem, que incluem princípios globais, diretrizes gerais, critérios de sucesso testáveis e um conjunto abundante de técnicas. Web Content Accessibility Guidelines (WCAG) 2.0:

  • Princípios: São quatro princípios que constituem a fundação da acessibilidade da Web: Percetível, Operável, Compreensível e Robusto;
  • Diretrizes: Abaixo dos princípios estão as 12 diretrizes que fornecem os objetivos básicos para produzir conteúdo mais acessível a usuários com diferentes incapacidades. Que podem ser encontradas no índice da WCAG 2.0;
  • Critérios de sucesso: Para cada diretriz, são fornecidos critérios de sucesso testáveis onde são definidos três níveis de conformidade: A (nível baixo), AA e AAA (o mais elevado);
  • Técnicas de tipo Suficiente e de tipo Aconselhada: Para cada uma das diretrizes e critérios de sucesso existem as técnicas do tipo suficiente para satisfazer os critérios de sucesso e as que são do tipo aconselhada.

Por que preciso tornar meu site acessível?

Um estudo norte americano de pesquisa de legenda e transcrições descobriu que 71% das pessoas com deficiência deixam um site imediatamente se não estiver acessível.

Além de alguns benefícios para as organizações como:

  • Maior tráfego e uso do site por pessoas com e sem deficiência;
  • O usuário vai ter uma melhor experiência;
  • Melhor indexação pelos mecanismos de pesquisa;
  • Otimização para motores de busca (SEO).

Tradicionalmente, vemos que a acessibilidade da web para pessoas com deficiência tem sido uma reflexão vagarosa. Em muitos casos, os desenvolvedores da web fornecem uma adaptação ou uma correção (um “complemento”) para a interface de um site depois que ele já está operando. Essa estratégia é geralmente baseada na percepção de que uma pequena população de pessoas com deficiência que utilizam a Web. No entanto, segundo a OMS, com dados de 2011, 1 bilhão de pessoas vivem com alguma deficiência que pode afetar sua navegação no site. Além disso, a prevalência de incapacidade está crescendo devido ao envelhecimento da população e ao aumento global de doenças crônicas.

Por outro lado projetos da web não levam em consideração a acessibilidade. É muito comum que alguns projetos da Web iniciem com o compromisso de atingir algum nível de acessibilidade na Web. No entanto, seguindo o esquema dos métodos tradicionais de desenvolvimento de software, como o modelo em cascata, a acessibilidade, no contexto de teste de acessibilidade, é adiada para a criação do site. Mas, no final do projeto, o tempo começa a diminuir rapidamente e os recursos começam a ser atribuídos a outras prioridades. Infelizmente, no final do projeto, a acessibilidade é descartada ou adiada para uma versão futura do site, dessa forma voltar para uma fase anterior com o site já em produção fica muito mais caro.

Uso de métodos ágeis para melhorar a acessibilidade dos projetos da Web

Os métodos de desenvolvimento ágil de software dividem as tarefas em pequenas interações que geralmente duram de uma a quatro semanas. No final de cada uma delas, uma parte completa do software é concluída e testada e está pronta para ser mostrada a qualquer parte interessada do projeto. Antes de iniciar uma construção do produto, todos os requisitos são adicionados a um Backlog do Produto. Ao planejar uma sprint, um subconjunto desses requisitos é movido para o Sprint Backlog. Uma abordagem ágil eficaz para o desenvolvimento de software acessível para o conteúdo da Web começa com o entendimento fundamental de que um aplicativo ou site deve ser funcional e utilizável por todos os usuários, independentemente de sua capacidade. A acessibilidade é uma expectativa habitual que todos os membros da equipe de desenvolvimento aceitam como parte normal de seu trabalho.

Os principais pontos de integração de acessibilidade dentro do processo Scrum incluem:

  • A equipe de desenvolvimento tem conhecimento dos padrões de acessibilidade e dos processos de teste, além de ter acesso a conhecimentos de acessibilidade para consulta e validação nos principais pontos;
  • O desenvolvimento e teste interativos incluem o desenvolvimento de funcionalidades que funcionam para todos os usuários, incluindo aqueles com deficiências, e testes para validar a conformidade com os padrões de acessibilidade;
  • A “definição de concluído” para todos os incrementos do produto deve incluir conformidade com os padrões de acessibilidade.

Abaixo vamos apresentar o relacionamento da acessibilidade da Web com os valores do Manifesto Ágil: indivíduos e interações; funcionamento do software; colaboração com o cliente; e respondendo à mudança

  • Indivíduos e interações:
    Nos métodos ágeis, a auto-organização e a motivação são importantes, assim como as interações entre diferentes partes interessadas. O Manifesto Ágil afirma que o método mais eficiente e eficaz de transmitir informações para uma equipe de desenvolvimento é a conversa presencial. Portanto, a cooperação entre as pessoas que participam do projeto e implementação deve ser incentivada. Todos em uma equipe de desenvolvimento devem estar envolvidos com a acessibilidade da web, começando na primeira fase do projeto.
    Além disso, a interação com os usuários finais também deve ser incentivada. O design centrado no usuário, que concentra a atenção em suas necessidades também é uma boa abordagem. Para que esse produto tenha uma boa qualidade é recomendável também que os usuários finais devem participar como revisores externos desde o início do projeto. Ademais, a aplicação de testes do usuário é a melhor maneira de obter um design centrado no usuário final. O teste de acessibilidade é uma técnica insubstituível, pois fornece informações diretas sobre como usuários reais usam sites e quais problemas de fato enfrentam.
  • Funcionamento do software:
    Nos métodos ágeis, o funcionamento do software é a principal medida de progresso e é entregue com frequência (semanas em vez de meses). Desde o início de um projeto, os protótipos dos sites devem ser entregues com a acessibilidade em mente. Portanto, o teste de acessibilidade deve ser realizado desde os estágios iniciais de um projeto e não deve ser adiado para o final do projeto.
    Os problemas de acessibilidade geralmente são causados ​​por problemas de marcação ou incompatibilidade já desde a primeira fase do projeto. Os testes de acessibilidade devem ser executados continuamente e automatizados para detectar esses problemas de acessibilidade desde o início de um projeto. Isso garante que os problemas de acessibilidade sejam capturados e eliminados durante o desenvolvimento. Isso não é possível para o método em cascata, pois o produto final é testado apenas ao concluir o projeto, o que significa que qualquer problema de acessibilidade encontrado resultará na reescrita do produto inteiro ou no problema não sendo resolvido.
  • Colaboração com o cliente:
    A satisfação do cliente é a maior prioridade por trás do Ágile Manifesto. Em um site o cliente é a pessoa que solicita e possui o site, já em relação à acessibilidade na Web consideramos o usuário final como o cliente.
    Existe um mito de que apenas as pessoas cegas enfrentam dificuldades com a acessibilidade. Embora “os problemas mais sérios de acessibilidade, dado o estado atual da Web, provavelmente estejam relacionados a usuários cegos e usuários com outras deficiências visuais, uma vez que a maioria das páginas da Web é altamente visual”, outras pessoas com deficiências diferentes também enfrentam problemas de acessibilidade. O WCAG 1.0 afirma que muitos usuários podem estar acessando um site em contextos muito diferentes do contexto dos designers:
    – Eles podem não ser capazes de ver, ouvir, mover ou de processar alguns tipos de informações facilmente ou de maneira alguma;
    – Podem ter dificuldade em ler ou compreender texto, assim como não ter ou conseguir usar um teclado ou mouse;
    – Eles podem ter uma tela somente texto, uma tela pequena ou uma conexão lenta à Internet;
    – Como também não falar ou entender fluentemente o idioma em que o documento está escrito;
    – Eles podem estar em uma situação em que seus olhos, ouvidos ou mãos estão ocupados ou interferem (por exemplo, dirigir para o trabalho, trabalhar em um ambiente barulhento etc.);
    – Ou ainda ter uma versão anterior de um navegador, um navegador completamente diferente, um navegador de voz ou um sistema operacional diferente.
    O teste do usuário de acessibilidade destaca problemas importantes de acessibilidade e avalia sua gravidade corretamente. Portanto, esse teste ajuda na priorização do impacto dos problemas de acessibilidade e ajuda a detectar erros cuja solução faz diferença na acessibilidade. No entanto, segundo o Giorgio Brajnik, teste de acessibilidade do usuário apresenta algumas desvantagens, dentre elas: implica um custo mais alto do que os especialistas em acessibilidade.
  • Respondendo à mudança:
    Tradicionalmente, as interfaces com o usuário são criadas assumindo que os usuários tenham em mente tarefas ou objetivos concretos. No entanto, quando os usuários navegam na Web, seus objetivos mudam e mudam à medida que encontram seu caminho na Web. Portanto, o método de teste de usuário convencional, em que um usuário é colocado em um computador para ver como ele navega em um site, deve ser repensado. Além disso, um estudo de caso argumentou que os usuários não operam no mundo real da mesma maneira que são solicitados a atuar em pesquisas e testes de usabilidade.
    Atualmente, a maioria dos sites é criado usando sistemas de gerenciamento de conteúdo (CMS). Dessa forma o trabalho que costumava ocupar grande parte de um projeto de desenvolvimento web é automatizado pelo CMS. Portanto, há uma clara mudança no esforço de um projeto da Web: enquanto no passado, a parte principal do esforço de trabalho era investida em programação, hoje em dia o principal esforço é dedicado à manutenção e a adaptação aos novos requisitos e funcionalidades. Isso não é possível quando o método em cascata é empregado, pois qualquer alteração a ser feita significa que o projeto deve ser iniciado novamente.

Acessibilidade Contínua

primeira imagem 3 pessoas na mesma posição, a segunda a 3 pessoa conseguiu ajuda da primeira assistir, 3 todas assistindo
http://blog.core-ed.org/blog/2016/07/unpacking-udl-differentiation-and-adaptation.html

Um site acessível é aquele que pode ser usado por todos os visitantes pretendidos, levando em consideração suas diferentes capacidades. Sites inacessíveis podem representar barreiras significativas para as pessoas com deficiência, as excluindo, o que não podemos deixar acontecer. Não podemos priorizar fazer acomodações, modificações ou ajustes para uma pessoa com deficiência, sob demanda, no momento que o site já está operando. E sim devemos incluir tarefas de acessibilidade como parte regular dos seus processos de desenvolvimento para evitar no futuro trabalho adicional para o projeto. Além disso, oferece um suporte a acomodações de maneira mais rápida, barata e eficaz.

Independentemente da metodologia específica de desenvolvimento de software de uma organização, é necessário incorporar padrões de acessibilidade em artefatos principais, no mínimo, em todos os artefatos principais.

  • Requisitos: sejam descritos como elementos de um Backlog do Produto, Especificações de Todo o Sistema ou outra designação de requisitos, a equipe de desenvolvimento deve estabelecer padrões de acessibilidade;
  • Design e arquitetura: conformidade com os padrões de acessibilidade influencia as decisões de design e arquitetura, seja relacionada a escolhas sobre tipos específicos de tecnologias seja por considerações sobre design de interface do usuário (UI). Os designers de experiência do usuário (UX) devem atender a todos os requisitos (incluindo os de acessibilidade) ao desenvolver wireframes e recursos visuais;
  • A equipe de Desenvolvimento deve incluir a conformidade com os padrões de acessibilidade nos estágios iniciais no desenvolvimento do projeto;
  • Planos de teste: Um processo padronizado de teste de acessibilidade informa a garantia que todos os processos específicos necessários estão funcional para todos os usuários.

LBI (Lei Brasileira de Inclusão)

A Lei Brasileira de Inclusão (LBI) possui um artigo específico onde fala que todos os sites brasileiros sejam acessíveis. Essa determinação está válida desde janeiro de 2016, mas o estudo mostra que ainda há muito a ser feito.

Por exemplo uma pesquisa feita recentemente aponta que menos de 1% dos sites brasileiros são acessíveis para pessoa com deficiência. Esse número é muito triste, por isso a necessidade de incluirmos padrões de acessibilidade no desenvolvimento do site ou aplicativo da sua organização. Dessa forma todos os usuários terão acesso ao conteúdo de um determinado site.

Abaixo listo 5 ferramentas para avaliar a acessibilidade de forma automática:

Segue abaixo um check-list básico com os primeiros passos para testar a acessibilidade da sua aplicação:

  • Valide se os gráficos e as imagens estão com texto alternativo;
  • Verificar se as imagens decorativas NÃO estão visíveis para os leitores de tela;
  • Navegue pelo conteúdo do site usando apenas o teclado;
  • Valide os itens com uma função img sem rótulos de ária;
  • O atributo “src” da imagem precisa ser valido;
  • Os Links estão descritivos;
  • Existem elementos TITLE vazios;
  • Cabeçalhos implícitos;
  • Existe atributo lang ausente no elemento HTML;
  • Existem células do cabeçalho da tabela vazia;
  • Redimensionamento de texto, mesmo aumentando o tamanho o texto continua legível;
  • Nível de contrastes da cor do plano de fundo com a cor do texto.

Na parte 2 desse artigo vou dar alguns exemplos práticos, e também vou criar um mind map desse check-list para facilitar o conceito.

Se você gostou do assunto, me siga nas Redes Sociais que estarei postando muito mais sobre Acessibilidade 😉

Fontes: