Esta semana eu tenho pensado sobre desempenho e acessibilidade na web. Tudo começou quando Ethan Marcotte fez muitas anotações sobre os problemas de acessibilidade comuns às AMP :
Nas gravações acima, estou tentando navegar pela AMP Story. E como eu faço, o VoiceOver descreve uma página que é impossível de entender: as setas para voltar ou avançar são simplesmente anunciadas como “botão”; a maioria das imagens não possui equivalentes de texto, e é por isso que o leitor de tela soletra cada caractere de seus nomes de arquivos; e quando o conteúdo de uma matéria é visível na tela, é quase impossível acessar. Eu gostaria de dizer que esta história AMP foi um outlier, mas cada um dos nove demos listados no site AMP Stories soa tão incompreensível no VoiceOver.
Ethan continua a argumentar que esses problemas são tão comuns nas AMP que a acessibilidade não deve ser uma prioridade:
Desde o início, o Google insistiu que o AMP é a melhor solução para o problema de desempenho da web. E o Google usou seu domínio de mercado para forçar os editores a adotar o framework, chegando a sugerir que o AMP é o único formato que você precisa para publicar páginas na web . Mas chegamos a um ponto em que as AMP podem “resolver” os problemas de desempenho da Web ao sobrecarregar o problema de acessibilidade da Web, excluindo ainda mais pessoas de acessar o conteúdo que merecem.
Eu tenho pensado muito sobre isso ultimamente – sobre como o trabalho de acessibilidade é frequentemente visto como um recurso adicional que pode ser incluído em um projeto mais tarde – em vez de o trabalho de acessibilidade ser um princípio básico ou padrão de trabalho na web.
E eu já vi esse sentimento expresso uma e outra vez, nos frameworks, no Twitter, no processo de design, no processo de desenvolvimento, e tanto que argumentar sobre a importância da acessibilidade pode se tornar bastante desgastante. Porque em algum momento não estamos discutindo sobre a importância da acessibilidade, mas a importância do desenvolvimento de front-end em si como uma série de habilidades dignas de se ter. Habilidades que não podem ser substituídas.
Da mesma forma, este post de Craig Mod, sobre por que o software deveria ser muito rápido , me fez pensar da mesma maneira:
Eu amo software rápido. Ou seja, software rápido tanto na função quanto na interface. Software com um mínimo ou nenhum atraso entre querer ativar ou manipular algo e o que está acontecendo. Leveza.
Mais adiante, Mod descreve o software rápido como a própria definição de bom software e argumenta que toda ação em um computador – seja um site ou um aplicativo – deve parecer como se você estivesse se movendo sem qualquer latência. E eu não poderia concordar mais; Cada tela de carregamento e tempo de espera é, em algum grau, uma marca de falha.
Alex Russell fez um ponto semelhante há não muito tempo atrás, quando analisou o desempenho de telefones celulares e examinou como todos experimentam a web de uma maneira muito diferente :
A conclusão aqui é que você literalmente não pode arcar com os níveis de JS de desktop ou iPhone se estiver tentando fazer boas experiências na Web para qualquer pessoa, exceto para os usuários mais ricos do mundo, o que provavelmente significa reavaliar seu toolchain.
Eu sou uma espécie de idiota quando se trata dessas coisas. Eu não acho que um site pode ser bom até que seja rápido. O tipo de jejum que tira seu fôlego. Tão rápido quanto o pensamento humano, ou até mais rápido. Então, meu ponto aqui é que o desempenho da Web não é algo que devemos aspirar, deve ser o padrão. O status quo. A linha de base pela qual nosso trabalho é julgado. Deve ser não-shippable até que a coisa seja rápida.
A boa notícia é que é mais fácil do que nunca enviar um site com esses requisitos básicos de velocidade e acessibilidade incomparáveis! Temos o Page Speed Insights e o Web Page Test , sem mencionar a capacidade de fazer com que o Lighthouse realize auditorias a cada commit no GitHub automaticamente enquanto trabalhamos. Ire Aderinokun nos mostrou como fazer isso não há muito tempo, estabelecendo um orçamento de desempenho e aprendendo como cumpri-lo.
As ferramentas para tornar nossos sites rápidos e acessíveis estão aqui, mas não as estamos usando. E é isso que me deixa louco.
Enquanto eu estou nesse discurso – e antes de eu sair do meu cavalo particularmente alto – eu acho importante anotar o argumento de Deb Chachra de que “qualquer negligência suficientemente avançada é indistinguível da malícia”. Com isso em mente, não é apenas ruim design e desenvolvimento de software se um site estiver lento. Desempenho e acessibilidade não são recursos que podem permanecer na parte inferior de uma placa Jira para serem considerados mais tarde quando for conveniente.
Em vez disso, devemos começar a ver sites inacessíveis e lentos pelo que são: uma forma de crueldade. E se queremos construir uma web que seja verdadeiramente uma World Wide Web, um lugar para todos e para todos, uma web que seja acessível e rápida para o maior número de pessoas possível e que resista a todos nós, então primeiro devemos fazer nossos sites são completamente diferentes; devemos torná-los gentis.