Sexta-feira – o fim do expediente. Notícias ruins sempre chegam na sexta-feira, no final do dia de trabalho.
Você está prestes a sair do escritório quando um novo e-mail sobre mais uma reestruturação acaba de chegar.
Obrigado xxxx, yyy a partir de hoje você irá se reportar a zzzz.
…
E a equipe da Hugh garantirá a acessibilidade de nossos produtos para pessoas com deficiência.
Oh, não! O que eu fiz para merecer isso? Eles querem que eu saia? Preparar-se para um trabalho ingrato e tentar corrigir os erros de outras pessoas. Isso definitivamente será um fracasso...
Essa era a acessibilidade há alguns anos. Alguns coitados eram encarregados de 'limpar' a interface do usuário para tentar torná-la acessível para pessoas com deficiência.
O que isso realmente significava era bastante vago – provavelmente, se você pudesse ver o indicador de foco e navegar pelos campos usando a tecla Tab, ter algum texto alternativo e algumas descrições para os campos, isso seria considerado como se seu aplicativo fosse acessível...
Mas, de repente, os 'bugs' começaram a proliferar como uma avalanche.
Diferentes leitores de tela (ing. Screen Readers) e navegadores se comportavam de maneiras totalmente diferentes.
Os usuários se queixavam de que o aplicativo não era utilizável.
Assim que um erro era corrigido em um lugar, outro aparecia em outro.
E simplesmente mudar e corrigir os erros da interface do usuário exigia esforços titânicos.
Eu estive lá. Eu sobrevivi, mas não 'prosperamos' – tecnicamente limpamos muito, adicionamos muitas descrições para os campos, funções e atingimos algum nível de conformidade, mas ninguém ficou feliz. Os usuários ainda reclamavam que não conseguiam navegar no aplicativo. O gerente ainda reclamava do fluxo constante de erros. Os engenheiros reclamavam da definição inadequada das tarefas, sem uma 'solução correta' claramente definida que funcionasse em todos os casos.
Na minha jornada para entender a acessibilidade, encontrei alguns momentos claramente reveladores.
Talvez a primeira percepção tenha sido que adicionar funcionalidade de acessibilidade a um produto existente é complicado. E ainda mais difícil é convencer os gerentes de que isso é incrivelmente complicado! Não é simplesmente "adicionar algumas tags" e a interface do usuário funcionará perfeitamente. Não, não é possível concluir isso em três semanas, mesmo três meses serão insuficientes.
Meu próximo momento de verdade aconteceu quando vi de perto como os usuários cegos realmente utilizam nosso aplicativo. É TÃO diferente de apenas observar mensagens de erro.
Voltarei a isso repetidamente, mas quase todas as nossas "suposições" sobre como as pessoas usavam nosso aplicativo estavam erradas.
Navegar por uma interface do usuário complicada usando as teclas Tab/Shift+Tab – é insatisfatório! Precisamos de algo melhor. Atalhos de teclado, cabeçalhos.
A perda de foco ao mudar a interface do usuário não é um grande problema? Vamos reconsiderar – isso é loucamente confuso.
Continuei, trabalhando em vários projetos por um tempo, e então começamos um novo projeto, com uma interface do usuário complicada e um claro propósito de finalmente conseguir acessibilidade adequada desta vez.
Assim, recuamos e pensamos em como poderíamos implementar isso de forma diferente e ter sucesso, e para que o próprio processo de trabalho fosse interessante!
Rapidamente chegamos a algumas conclusões:
- Não queríamos que as pessoas que desenvolvem a interface do usuário se ocupassem com anotações/roles aria e, naturalmente, com a estrutura HTML dos componentes. Precisávamos fornecer os componentes corretos, nos quais a acessibilidade já estivesse implementada desde o início.
- Acessibilidade == Usabilidade – ou seja, não é apenas uma tarefa técnica. Precisávamos mudar todo o processo de design e garantir que a acessibilidade fosse considerada e discutida antes do início do design da interface do usuário. Devemos pensar desde o início sobre como os usuários descobrirão qualquer funcionalidade, como eles se moverão e como funcionará o "clique direito do mouse" com o teclado. A acessibilidade deve ser uma parte integrante do processo de design – para alguns usuários, isso é muito mais do que apenas a aparência do aplicativo.
- Desde o início, queríamos obter feedback de usuários cegos e de outras pessoas com deficiência sobre a facilidade de uso do aplicativo.
- Precisávamos de maneiras realmente eficazes para detectar regressões de acessibilidade.
Bem, do ponto de vista da engenharia, a primeira parte parecia bastante divertida – desenvolver a arquitetura e implementar a biblioteca de componentes. E realmente foi assim.
Dando um passo atrás, ao considerar e pensando nisso como um problema de design, e não apenas uma questão de 'adaptação', introduzimos algumas abstrações. O componente tem uma ‘Estrutura’ (composta por elementos HTML) e ‘Comportamento’ (como ele interage com o usuário). Por exemplo, nos fragmentos abaixo temos uma simples lista não ordenada. Ao adicionar ‘comportamento’ à lista, os papéis apropriados são adicionados para que funcione como uma lista. Fazemos algo semelhante para o menu.
Na verdade, não apenas papéis são adicionados, mas também manipuladores de eventos para navegação pelo teclado.
Isso já parece mais organizado. Se pudéssemos obter uma separação limpa entre eles, não importaria como a estrutura foi criada, poderíamos aplicar comportamentos e garantir a acessibilidade correta.
Na prática, isso pode ser visto em – uma biblioteca UX , que é projetada e implementada com acessibilidade desde o início.
A segunda parte – mudar a abordagem e os processos em torno do design inicialmente me assustava: engenheiros modestos tentando promover mudanças organizacionais, isso nem sempre termina bem, mas acabou sendo uma das áreas mais interessantes onde fizemos contribuições significativas para o processo. Resumindo, tínhamos o seguinte processo: a nova funcionalidade era desenvolvida por uma equipe, em seguida, nosso grupo de líderes analisava/iterava a proposta e, após a aprovação, geralmente o design era entregue à equipe de engenharia. Nesse caso, a equipe de engenharia, na verdade, 'detinha' a funcionalidade de acessibilidade, pois deveria resolver todos os problemas relacionados.
No início, foi um trabalho bastante difícil – explicar que a acessibilidade e a usabilidade estão interligadas e que isso precisa ser feito já na fase de design, caso contrário, levaria a grandes mudanças e redefinições de alguns papéis. No entanto, com o apoio da liderança e dos principais atores, conseguimos transmitir essa ideia e colocá-la em prática, de modo que os designs passassem por uma verificação de acessibilidade e usabilidade antes de serem apresentados à liderança.
E esses feedbacks foram extremamente valiosos para todos – foi fantástico, como um exercício de compartilhamento de conhecimento/informação sobre como os usuários interagem com aplicativos da web, identificamos numerosas áreas problemáticas da interface do usuário antes de serem construídas, as equipes de desenvolvimento agora têm especificações muito melhores, não apenas visuais, mas também dos aspectos comportamentais do design. As discussões reais são conversas animadas, energéticas e apaixonadas sobre aspectos técnicos e interações.
Poderíamos ter feito esse trabalho ainda melhor se tivéssemos tido usuários cegos e usuários com deficiências nessas (ou em reuniões subsequentes) – foi difícil de organizar, mas agora estamos realmente colaborando tanto com organizações locais de deficientes visuais quanto com empresas que fornecem testes externos para verificar o fluxo de execução nas fases iniciais de desenvolvimento – tanto a nível de componente quanto a nível de fluxo de execução.
Agora, os engenheiros têm especificações bastante detalhadas, componentes acessíveis que podem usar para a implementação e um método para verificar o fluxo de execução. Em parte, a experiência nos ensinou sobre o que frequentemente esquecíamos – como podemos evitar a regressão. Da mesma forma, as pessoas podem usar testes de integração ou testes de ponta a ponta para verificar a funcionalidade que precisamos para detectar mudanças nas interações e fluxos de execução – tanto visuais quanto comportamentais.
A definição de regressão visual é uma tarefa bastante específica, com muito pouco a ser acrescentado a esse processo, exceto, talvez, a verificação se o foco é visível ao navegar usando o teclado. Duas tecnologias relativamente novas para trabalhar com acessibilidade são mais interessantes.
- é um conjunto de ferramentas que pode ser executado tanto no navegador quanto dentro do ciclo de build/teste para identificar problemas.
- A verificação da funcionalidade dos leitores de tela foi uma tarefa especialmente desafiadora. Com a introdução do acesso ao Accessibility DOM, finalmente conseguimos fazer capturas do aplicativo do ponto de vista da acessibilidade, muito semelhante ao que fazemos para testes visuais, e verificar se há regressão.
Assim, na segunda parte da história, passamos da edição do código HTML para trabalhar em um nível mais alto de abstração, alteramos o processo de desenvolvimento do design e introduzimos testes rigorosos. Novos processos, novas tecnologias e novos níveis de abstração mudaram completamente a percepção sobre acessibilidade e o que significa trabalhar neste campo.
Mas isso é apenas o começo.
A próxima "compreensão" é que usuários cegos impulsionam tecnologias de ponta – são eles que mais se beneficiam não apenas das mudanças que descrevemos anteriormente, mas também com o fato de que novas abordagens e ideias se tornam possíveis com ajuda de ML/AI. Por exemplo, a tecnologia Immersive Reader permite que os usuários apresentem o texto de forma mais simples e clara. Ele pode ser lido em voz alta, a estrutura da frase é dividida gramaticalmente e até mesmo os significados das palavras são exibidos graficamente. Isso não se encaixa de forma alguma no antigo entendimento de "tornar acessível" – é uma função de usabilidade que ajudará a todos.
Com ML/AI, surgem maneiras completamente novas de interagir e trabalhar, e estamos entusiasmados em fazer parte das próximas etapas desse caminho inovador. A inovação é impulsionada pela mudança de mentalidade – a humanidade já existe há milênios, as máquinas há centenas de anos, os sites há algumas décadas, e os smartphones há ainda menos. A tecnologia deve se adaptar às pessoas, e não o contrário.
P.S. O artigo foi traduzido com pequenas alterações em relação ao original. Sendo coautor deste artigo, eu concordei com essas alterações com Hugh.
Apenas usuários registrados podem participar da pesquisa. , por favor.
Você presta atenção na acessibilidade de seus aplicativos?
Sim
Não
É a primeira vez que ouço sobre acessibilidade de aplicativos
17 usuários votaram. 5 usuários se abstiveram.
Fonte: habr.com
