Sexta-feira é o fim do dia útil. Más notícias sempre chegam no final do expediente de sexta-feira.
Você está prestes a sair do escritório, uma nova carta sobre outra reorganização acaba de chegar pelo correio.
Obrigado xxxx, yyy a partir de hoje você reportará zzzz
...
E a equipe de Hugh garantirá que nossos produtos sejam acessíveis a pessoas com deficiência.
Oh não! Por que eu mereci isso? Eles querem que eu vá embora? Prepare-se para um trabalho árduo e ingrato e para tentar corrigir os erros de outras pessoas. Isso é definitivamente um fracasso...
Essa era a disponibilidade há alguns anos. Algumas pobres almas receberam a tarefa de “limpar” a UI para tentar torná-la acessível a pessoas com deficiência.
O que isso realmente significava era bastante vago - presumivelmente, se você pudesse ver um indicador de foco e percorrer os campos, tivesse algum texto alternativo e algumas descrições de campo, seria considerado que seu aplicativo está acessível ...
Mas de repente os “insetos” começaram a se multiplicar na velocidade de uma avalanche.
Vários leitores de tela (Eng. Leitores de tela) e navegadores se comportaram de maneira completamente diferente.
Os usuários reclamaram que o aplicativo está inutilizável.
Assim que um erro era corrigido em um lugar, outro aparecia em outro.
E simplesmente alterar e corrigir erros na interface do usuário exigiu esforços hercúleos.
Eu estava lá. Eu sobrevivi, mas não tivemos "sucesso" - tecnicamente, limpamos muita coisa, adicionamos muitas descrições de campos, funções e alcançamos algum nível de conformidade, mas ninguém ficou feliz. Os usuários ainda reclamaram que não conseguiam navegar no aplicativo. O dirigente ainda reclamou do fluxo constante de erros. Os engenheiros reclamaram que o problema foi colocado incorretamente, sem nenhuma solução “correta” claramente definida que funcionasse em todos os casos.
Houve alguns momentos decididamente reveladores ao longo de minha jornada para compreender a acessibilidade.
Talvez a primeira tenha sido a constatação de que era difícil adicionar funcionalidade de acessibilidade a um produto acabado. E é ainda mais difícil convencer os gestores de que é incrivelmente difícil! Não, não é apenas "adicionar algumas tags" e a IU funcionará perfeitamente. Não, isto não pode ser concluído em três semanas; mesmo três meses não serão suficientes.
Meu próximo momento de verdade veio quando vi em primeira mão como os usuários cegos realmente usavam nosso aplicativo. Isso é MUITO diferente de olhar mensagens de erro.
Voltarei a isso várias vezes, mas quase todas as nossas “suposições” sobre como as pessoas usavam nosso aplicativo estavam erradas.
Navegando em uma interface de usuário complexa usando teclas Tab/Shift+Tab – isso é uma merda! Precisamos de algo melhor. Atalhos de teclado, cabeçalhos.
Perder o foco ao mudar a UI não é um grande problema, não é? Vamos pensar novamente – isso é incrivelmente confuso.
Continuei, trabalhei em projetos diferentes por um tempo, e então iniciamos um novo projeto, com uma interface de usuário complexa e uma instalação clara, para finalmente acertar a acessibilidade desta vez.
Então, demos um passo para trás e vimos como poderíamos implementar isso de forma diferente e ter sucesso, além de tornar o processo menos chato!
Rapidamente chegamos a algumas conclusões:
- Não queríamos que as pessoas que desenvolviam a interface do usuário mexessem com rótulos/funções de ária e, claro, com a estrutura HTML dos componentes. Precisávamos fornecer a eles os componentes certos que criassem acessibilidade imediatamente.
- Acessibilidade == Facilidade de uso – ou seja, Este não é apenas um desafio técnico. Precisávamos mudar todo o processo de design e garantir que a acessibilidade fosse levada em consideração e discutida antes do início do design da UI. Você precisa pensar desde o início como os usuários descobrirão qualquer funcionalidade, como navegarão e como funcionará o clique com o botão direito do teclado. A acessibilidade deve ser parte integrante do processo de design – para alguns usuários é muito mais do que apenas a aparência do aplicativo.
- Desde o início, queríamos obter feedback de usuários cegos e outras pessoas com deficiência sobre a facilidade de uso do aplicativo.
- Precisávamos de maneiras realmente boas de detectar regressões de acessibilidade.
Bem, do ponto de vista da engenharia, a primeira parte pareceu bastante divertida - desenvolver uma arquitetura e implementar uma biblioteca de componentes. E de fato foi assim.
Dando um passo para trás, olhando e ao pensar nisso como um problema de design em vez de um problema de “adequação”, introduzimos algumas abstrações. Um componente possui uma 'Estrutura' (consiste em elementos HTML) e um 'Comportamento' (como interage com o usuário). Por exemplo, nos trechos abaixo temos uma lista simples e não ordenada. Ao adicionar "comportamentos", as funções correspondentes são adicionadas à lista para fazê-la funcionar como uma lista. Fazemos o mesmo para o menu.
Na verdade, não apenas funções são adicionadas aqui, mas também manipuladores de eventos para navegação pelo teclado.
Isso parece mais legal. Se pudéssemos obter uma separação clara entre eles, não importaria como a estrutura foi criada, poderíamos aplicar Behaviors a ela e acertar a acessibilidade.
Você pode ver isso em ação em – Biblioteca UX , que é projetado e implementado tendo em mente a acessibilidade desde o início.
A segunda parte - mudar a abordagem e os processos em torno do design inicialmente me assustou: engenheiros humildes que tentam impulsionar a mudança organizacional nem sempre terminam bem, mas acabou sendo uma das áreas mais interessantes onde fizemos contribuições significativas para o processo . Resumindo, nosso processo era o seguinte: novas funcionalidades seriam desenvolvidas por uma equipe, então nossa equipe de liderança revisaria/iteraria a proposta e, então, uma vez aprovado, o projeto normalmente seria entregue à equipe de engenharia. Nesse caso, a equipe de engenharia efetivamente “possuía” a funcionalidade de acessibilidade porque era sua responsabilidade corrigir quaisquer problemas associados a ela.
No início foi um trabalho bastante difícil explicar que a acessibilidade e a usabilidade estão indissociavelmente ligadas e que isso tinha que ser feito na fase de design, caso contrário levaria a grandes mudanças e redefinições de algumas funções. No entanto, com o apoio da gestão e dos principais intervenientes, pegamos na ideia e colocámo-la em prática para que os designs fossem testados quanto à acessibilidade e usabilidade antes de serem apresentados à gestão.
E esse feedback foi extremamente valioso para todos - foi fantástico como um exercício de compartilhamento/comunicação de conhecimento sobre como os usuários interagem com aplicativos da web, identificamos inúmeras áreas problemáticas de UI antes de serem construídas, as equipes de desenvolvimento agora têm especificações muito melhores de não apenas aspectos visuais, mas também comportamentais do design. As discussões reais são discussões divertidas, enérgicas e apaixonadas sobre aspectos técnicos e interações.
Poderíamos fazer isso ainda melhor se tivéssemos usuários cegos e deficientes nessas reuniões (ou nas subsequentes). Isso foi difícil de organizar, mas agora trabalhamos com organizações e empresas locais para cegos, que fornecem testes externos para verificar o fluxo de execução no início. desenvolvimento – tanto nos níveis do componente quanto no fluxo de execução.
Os engenheiros agora têm especificações bastante detalhadas, componentes disponíveis que podem usar para implementar e uma forma de validar o fluxo de execução. Parte do que a experiência nos ensinou é o que nos faltou o tempo todo: como podemos parar a regressão. Da mesma forma, as pessoas podem usar testes de integração ou ponta a ponta para testar a funcionalidade, que precisamos para detectar mudanças nas interações e nos fluxos de execução – tanto visuais quanto comportamentais.
Determinar a regressão visual é uma tarefa bastante definida, há muito pouco que pode ser adicionado ao processo além de talvez verificar se o foco está visível ao navegar com o teclado. Mais interessantes são duas tecnologias relativamente novas para trabalhar com acessibilidade.
- é um conjunto de ferramentas que podem ser executadas no navegador e como parte do ciclo de construção/teste para identificar problemas.
- Verificar se os leitores de tela funcionam corretamente tem sido uma tarefa particularmente desafiadora. Com a introdução do acesso a DOM de acessibilidade, finalmente poderemos tirar instantâneos de acessibilidade do aplicativo, assim como fazemos com testes visuais, e testá-los quanto à regressão.
Assim, na segunda parte da história, passamos da edição do código HTML para o trabalho em um nível mais alto de abstração, alteramos o processo de desenvolvimento do design e introduzimos testes completos. Novos processos, novas tecnologias e novos níveis de abstração mudaram completamente o panorama da acessibilidade e o que significa trabalhar neste espaço.
Mas este é apenas o começo.
O próximo “entendimento” é que os utilizadores cegos estão a impulsionar tecnologia de ponta – são eles que mais beneficiam não só das mudanças que descrevemos anteriormente, mas também de que novas abordagens e ideias são possibilitadas pelo BC/IA. Por exemplo, a tecnologia Immersive Reader permite aos usuários apresentar texto de forma mais fácil e clara. Pode ser lido em voz alta, a estrutura da frase é dividida gramaticalmente e até mesmo o significado das palavras é exibido graficamente. Isso não se enquadra na velha mentalidade de “tornar acessível” – é um recurso de usabilidade que ajudará a todos.
O ML/AI está possibilitando formas inteiramente novas de interagir e trabalhar, e estamos entusiasmados por fazer parte das próximas etapas dessa jornada inovadora. A inovação é impulsionada por uma mudança de pensamento - a humanidade existe há milénios, as máquinas há centenas de anos, os websites há várias décadas e os smartphones ainda menos, a tecnologia deve adaptar-se às pessoas, e não vice-versa.
P.S. O artigo foi traduzido com pequenos desvios do original. Como coautor deste artigo, concordei com Hugh nessas digressões.
Apenas usuários registrados podem participar da pesquisa. por favor
Você presta atenção à acessibilidade de seus aplicativos?
-
Sim
-
Não
-
Esta é a primeira vez que ouço sobre acessibilidade de aplicativos.
17 usuários votaram. 5 usuários se abstiveram.
Fonte: habr.com