Disney Plus chegou… e junto com ele um bom exemplo de acessibilidade!
Sim, ele chegou e daí você pergunta… será que é acessível? Bom, aqui está uma análise que pode te ajudar a entender isso.
Disclaimer muito importante
Antes de iniciar essa análise é importante você saber alguns pontos sobre este conteúdo:
- Este material tem fins educacionais e de aprendizado. Em todos os meus cursos, aulas ou apresentações eu demonstro na prática com alguns exemplos e casos de uso e com o lançamento do Disney Plus® no Brasil nada mais justo do que efetuar essa análise (do que seria um bom caso de sucesso) por aqui;
- Todos os conteúdos utilizados para a análise possuem direitos autorais reservados para a Disney®, sua utilização neste artigo, repito, tem somente propósitos educacionais;
- Essa não é uma análise aprofundada de acessibilidade, para isso, seria necessário muito mais tempo e uso de ferramentas com um detalhamento maior de informações. Os itens citados neste artigo representam problemas ou soluções comuns encontrados em diferentes sites e aplicativos;
- Os testes citados aqui foram realizados em 17 de novembro de 2020. Caso você esteja lendo este artigo em algum momento no futuro, é possível que os exemplos estejam desatualizados.
Dito isto, vamos ao artigo…
Convivendo diariamente com o tema acessibilidade, seja pesquisando, aplicando ou ensinando, é muito comum eu ouvir perguntas como "será que é acessível?" sempre que um novo produto ou serviço é lançado no mercado.
Com a Disney Plus não foi diferente e eu já estava de olho no serviço antes mesmo dele ser lançado por aqui. Efetuando pesquisas para uma apresentação que eu montaria, antes mesmo do serviço chegar aqui no Brasil, me deparei com a lista de funcionalidades disponível para o serviço em inglês, nos EUA:
A lista deixava claro todos os recursos que eles ofereciam no serviço americano, como legendas ocultas (obrigatório em serviços de vídeo), audiodescrições (tão importante quanto legendas), conversão de texto para fala (sim, eles oferecem uma opção para quem não possui leitor de telas), contrastes adequados (alguns designers ainda acreditam que aplicar acessibilidade se trata apenas disso), responsividade do site (em 2020 isso não deveria mais um destaque, mas é justificável em um serviço com a premissa de funcionar em qualquer local) e navegação por teclado (confesso que isso me surpreendeu sendo declarado na lista).
E vamos começar essa análise justamente pelo último item dessa lista, pois a navegação por teclado é um dos itens mais negligenciado por designers e desenvolvedores de qualquer site (e aplicativos também, mas isso é papo pra outro momento).
Navegação por teclado
Diferentemente do que a maior parte das pessoas pensam, não é apenas pessoas que utilizam leitores de tela que navegam por teclado. Todos nós navegamos em diferentes momentos (por exemplo, ao se preencher um formulário), mas a questão é que nem todos possuem o hábito de se navegar por teclado, mas isso também se deve ao fato de que os sites em geral não disponibilizam essa navegação de forma consistente e eficiente, como deveriam. Ou seja, um motivo interfere diretamente no outro.
Há diferentes critérios da WCAG que compreendem a navegação por teclado, mas os mais importantes são:
A navegação por teclado sem o uso de leitores de tela se dá basicamente através de itens clicáveis (que seriam acionados por um mouse), como menus, botões, links, formulários, etc. E não deve ocorrer bloqueios ou interrupções ao se navegar, sem contar que a sequencia de navegação deve ser lógica e intuitiva para o padrão do idioma local, por exemplo, da esquerda para a direita e de cima para baixo em um idioma cuja leitura seja nessa direção (em um idioma cuja leitura das informações se dá da direita para a esquerda a sequencia de tabulação deve seguir essa lógica).
Já que falamos em tabulação, apenas itens bem específicos e em momentos bem especiais deveriam receber uma "tabulação forçada", isso significa que se o elemento não for naturalmente um elemento clicável, ele não deveria receber tabulação caso não haja um bom motivo pra que isso ocorra. Este material da WebAIM sobre navegação por teclado, explica esse ponto de forma mais detalhada.
Outro ponto muito, mas muito mesmo, negligenciado por designers é o foco visível dos elementos clicáveis. E este é um dos erros mais comuns (e também um dos mais simples de se resolver) que encontramos em diferentes sites. Basicamente quando usamos um mouse, este é o nosso feedback visual de onde estamos navegando em uma interface, mas e quando usamos um teclado, como vamos saber onde estamos se não há um foco visível nos elementos em tela?
Eu escrevi um artigo bem completo sobre a importância do foco visível e você pode ler mais detalhes nele. Mas como o nosso foco aqui é no Disney Plus, este foi o item que havia me chamado a atenção e claro, foi o primeiro que eu fui testar no novo site.
E que linda surpresa quando eu vi isso aqui acontecer:
Há pequenos ajustes a serem efetuados, mas nada que seja um impeditivo tão comum encontrado em diversos outros sites de streaming (pra ficar na mesma categoria apenas). Lembrando que até este momento a navegação é apenas por teclado sem uso de leitores de tela.
Pontos de destaque:
- Navegação sequencial acontece de forma correta;
- Foco visível nos elementos é algo digno de aplausos (faça o teste por conta própria e navegue pelos serviços concorrentes, como Netflix, GloboPlay ou Amazon PrimeVideo — apenas esse último tem uma navegação boa também por teclado);
- A navegação por carrosséis teve uma solução simples e eficiente não utilizada pelos serviços concorrentes. Perceba que as setas de "próximo" e "anterior" surgem quando se focaliza no último ou primeiro item visível da tela, cujo efeito é o mesmo ao se utilizar um mouse (com a diferença de se ter o foco visível bem definido em volta do elemento):
Para fins comparativos com o vídeo demonstrado anteriormente, vejam esses GIF's com a navegação por teclado nos "concorrentes" do Disney Plus:
GloboPlay
Impossível saber onde se está navegando por teclado quando estamos na sessão de vídeos…
Netflix
A percepção de foco por teclado é muito sutil se comparado com a navegação por mouse e a navegação se perde ao se chegar no último item do carrossel…
Prime Video
Aqui temos um serviço de primeira qualidade e muito bem feito… :)
Feito essa análise de navegação por teclado, vamos aos testes com o uso de um leitor de telas.
Navegação por teclado + Leitor de telas
Este é o ponto crucial quando fazemos testes de acessibilidade, pois é justamente o ponto onde os designers mais pecam por não necessariamente pensarem layouts de forma aural (auditiva), mas apenas visual.
Isso se deve ao não conhecimento do funcionamento de tecnologias assistivas e não há como se projetar pensando em acessibilidade para todas as pessoas sem conhecer o funcionamento de um leitor de telas, para citar apenas um dos recursos mais utilizados para assistência.
O vídeo a seguir demonstra o uso de um leitor de telas (no caso, o VoiceOver, da Apple). Caso você não consiga acompanhar a velocidade do leitor utilizada, tente acompanhar a transcrição no quadro cinza na parte inferior:
Se possível, assista ao vídeo duas vezes. Uma delas com os olhos fechados.
No vídeo podemos ver a navegação por teclado e também o uso de um leitor de telas e consequentemente é possível identificar alguns pontos muito bons que foram construídos na interface e algumas pequenas falhas (que não chegam a ser impeditivos, mas atrapalham a experiência de quem ouve a informação e não vê a tela).
Novamente, são diversos critérios da WCAG que são atendidos quando se faz uso de tecnologias assistivas, mas os principais que podemos destacar no vídeo são:
Informações e Relações
A primeira grande percepção que tive e a ausência notada é com relação ao critério 1.3.1 — Informações e Relações que é justamente um dos critérios mais importantes da WCAG para se entender os relacionamentos entre os elementos em tela e também as responsabilidades das pessoas envolvidas ao aplicar acessibilidade de forma adequada.
Com relação aos elementos, o exemplo mais evidente é no menu principal do site (isso ocorre a partir de 0:07 no vídeo):
Visualmente não há nada de errado com ele, além de que seu funcionamento com teclado está correto. Porém quando usamos um leitor de telas não percebemos que a sua construção está em formato de lista, pois o leitor de telas não o identifica como tal, lendo individualmente cada um dos itens como está no vídeo.
Qual a importância disso? Um usuário que está vendo a tela, bate o olho no menu e percebe a quantidade de itens existentes. Já um usuário que não vê a tela, mas apenas a ouve, não percebe a quantidade de itens neste mesmo menu.
A correção é simples. Basta aplicar a semântica adequada nos componentes. Ao analisar o código dessa parte da página identifiquei logo de cara a ausência das tags <li> (list item) no HTML e isso faz com que o leitor de telas não identifique adequadamente como sendo uma lista de itens. O agrupamento <ul> (unordered list) existe no código e o aspecto visual, neste caso, não sofreria mudanças. Percebi também a existência da tag <nav> (navigation) englobando todos os elementos (não visível no print), o que indica que a ausência das tags <li> foi provavelmente um "esquecimento". Isso só se torna perceptível com uma análise aprofundada no código ou ao se utilizar um leitor de telas.
Como deveria estar? Exatamente como na imagem abaixo:
O que aconteceria caso estivesse correto? O leitor de telas indicaria a quantidade de itens na lista ao chegar no primeiro item dela, neste caso, seria algo parecido com "menu de navegação, lista 8 itens, item 1 de 8" (o formato exato pode variar devido a combinação de leitores de tela e as particularidades de cada um).
Pular para o conteúdo principal
A segunda questão está atendendo corretamente que o link para "Ir direto para o conteúdo" que surge logo no início do vídeo e que só aparece ao se navegar por teclado. Ele representa o critério 2.4.1 — Ignorar Blocos da WCAG e sua importância é para fazer com que usuários que não veem a tela tenham uma opção para pular blocos repetitivos (como o menu no topo) que surgem em todas as telas, agilizando assim a navegação por conta do usuário.
Há um pequeno erro de semântica na posição em que o elemento está no código, mas isso não afeta a experiência geral.
Nome acessível para rótulos e etiquetas
A última grande observação aqui é com relação ao critério 2.5.3 — Rótulo no Nome Acessível, que também é causador de diversos problemas comuns de acessibilidade principalmente por não ser detectável de forma automatizada.
Este critério basicamente diz respeito ao que você ouve e interpreta sobre os elementos. Ele precisa ser baseado na função da aplicação. Por exemplo, você tem um ícone de "lupa" na sua interface que serve para buscar algo nela. Quando o usuário que não enxerga a interface passa por esse controle utilizando o leitor de telas ele não deveria ouvir "ícone de lupa", mas sim algo parecido com "buscar" ou "o que deseja encontrar?". Isso tem impacto direto na experiência que o usuário tem ao se navegar na interface. O critério possui muito mais detalhe e é recomendado a sua leitura completa.
No caso do vídeo você pode começar a perceber esse tipo de elemento a partir de 0:37 ao se navegar pelo ícone de perfil de usuário:
Aqui, além do rótulo há uma instrução adicional "Selecione esta opção para expandir uma lista suspensa para alterar perfis e acessar configurações" (isso é aplicado pelo desenvolvedor, mas quem define o texto é o designer e/ou conteúdista que projeta a interface). Na sequencia há uma informação "reduzido" que é padrão do sistema (recursos WAI-ARIA, papo para outro momento), mas que precisa ser programada pelo desenvolvedor e isso indica que há um menu e que ele está fechado (reduzido).
A partir daí, ao saltar para o minuto 1:54 no vídeo é possível identificar outros botões que exigem "nome no rótulo acessível" que estão localizados na interface de navegação do filme ou série escolhido. Trata-se dos botões "assistir", "trailer", "adicionar itens na lista" e "groupwatch". Esses últimos dois merecedores de uma atenção maior, principalmente o último que não teve um termo traduzido para o português.
Enfim… há muitos outros elementos para se analisar na interface como um todo, mas os que foram apresentados até aqui já dá um bom norte para todos que querem transformar as suas interfaces em algo mais acessível e inclusivo e é notável que o pessoal da Disney Plus fez um bom trabalho em boa parte do processo.
Ainda pensando na análise do rótulo no nome acessível, há um item que notei que pode ser melhorado também. Ele está na tela de assinatura do serviço, onde você escolhe qual plano deseja:
Note a existência de 2 botões com o mesmo rótulo na tela. Neste caso, para quem está vendo os botões está ok e condizente com o layout e estrutura da página. Fica óbvio identificar a qual grupo cada botão pertence, mas quando você não está vendo a tela, perceba como o leitor de tela lê as informações:
Neste caso o problema poderia ser resolvido simplesmente adicionando um rótulo audível em cada um dos botões, sendo que o da esquerda poderia ser lido com algo parecido com "teste grátis, antes de assinar o plano mensal" e o botão da direita referente ao plano anual poderia ser lido como "teste grátis, antes de assinar o plano anual". Dessa forma, facilitaria a vida do usuário que apenas ouve o conteúdo sem que ele precisasse clicar em um ou outro antes de identificar qual ele escolheu de fato.
Perceba que isso não é um impeditivo, mas fatalmente afeta a experiência do usuário com relação a qualidade do seu conteúdo.
E por fim, neste mesmo vídeo é demonstrado algo que está bem estruturado, mas que infelizmente não é a realidade de boa parte dos sites e sistema.
Uma boa arquitetura de informação.
Mais precisamente a partir do minuto 1:12 é possível identificar a navegação apenas por "heading titles" que é disparada a forma de navegação mais utilizada por usuários de leitores de tela.
Os critérios da WCAG diretamente atendidos nessa questão são:
Como sempre há outros critérios relacionados a estes também, mas esses em geral indicam o que é necessário pontuar com relação a isso em sua interface.
Nota: o mais incrível é saber que boa parte dos designers não sabem construir uma arquitetura de informação adequada para suas interfaces (que pouco tem a ver com tamanhos de títulos da sessão de cada parte da interface).
Aplicativo para celular (Android)
Bem… aqui eu encontrei a maior parte dos erros nessa avaliação não aprofundada.
Há problemas que podem ser impeditivos para algumas pessoas e para outras pode ser apenas algo que atrapalhe a primeira navegação, o que não significa que não deveria ser melhor trabalhado.
Neste primeiro vídeo, navego pela área principal do aplicativo:
Pontos de destaque
- A navegação pelos carrosséis é impraticável em alguns casos sem que se faça o uso de "tentativa e erro";
- Para o carrossel principal (a partir de 0:23) não é possível navegar de forma simples pelos itens e é preciso forçar a leitura em alguns casos. Entrando no contexto de um usuário que não estaria enxergando a tela, isso seria bem complicado;
- Para os carrosséis com temas agrupados (a partir de 0:47) não é possível navegar de forma natural por itens não visíveis em tela. Nota-se no vídeo que a navegação sempre vai para o carrossel seguinte sem continuar na linha original;
- Há também um problema estrutural aqui. Os títulos dos agrupamentos não são lidos e consequentemente eu não sei necessariamente onde estou navegando;
- Ainda relacionado a Arquitetura de Informação, ao se entrar em um vídeo específico, a estrutura de navegação não condiz com o que é visualizado em tela (minuto a partir de 1:57) comprometendo a compreensão através das "Informações e Relações";
- E o último item é com relação ao "nome no rótulo acessível", cujo marcador do botão de "compartilhamento" não possui rótulo (no vídeo é informado "sem marcador, botão").
Já no segundo vídeo, navego por um dos filmes apresentados:
Pontos de destaque
- Aqui as marcações estão corretas em boa parte da navegação, porém não é possível acessar de forma simples os conteúdos das abas na parte inferior (Sugestões, Extras e Detalhes). O próprio comportamento das abas, não está com a interação em formato de abas, prejudicando também a interação entre os itens (a partir de 1:25).
No caso do aplicativo para Android (não efetuei testes na versão para iPhone ainda) é possível sim utilizar, mas a experiência ideal ainda está comprometida e neste caso os ajustes não são tão complexos. Tenho certeza que esses pontos serão resolvidos em próximas atualizações.
Vamos considerar que o aplicativo precisava ser lançado no dia junto com os demais produtos e que ele será melhorado com o tempo. 😊
Aplicativo para TV (Android TV)
Pra finalizar essa análise, efetuei também alguns testes utilizando o aplicativo disponível para a Android TV:
E aqui mais uma vez eu fui surpreendido… de longe de todos os aplicativos que testei até hoje rodando na televisão com o leitor de telas habilitado esse é definitivamente o melhor em todos os pontos possíveis. 😍
A navegação através do controle remoto funciona perfeitamente bem e a leitura dos elementos, inclusive de elementos complexos como os carrosséis, está muito boa, sem bloqueios de navegação e com todos os itens sendo acessados sem maiores problemas.
Note no minuto 1:04, no retorno para a tela principal, a indicação de quantidade de itens existentes no carrossel "item 1 de 21, na lista, 21 itens".
Todos os elogios possíveis por aqui…
Demais formas de apresentação
Analisando os últimos detalhes nos canais de distribuição dos aplicativos do Disney Plus, é possível identificar alguns pontos daqueles pontuados na lista logo no começo deste artigo, principalmente no que diz respeito as legendas e audiodescrições dos vídeos:
A disponibilidade de legendas e audiodescrições não é igual para todos os conteúdos e varia para cada situação (o que é normal, diga-se, mas pode melhorar).
E em um papo com o Edu Agni ele comentou comigo que o filho dele quis assistir a um determinado filme e apareceu uma mensagem a respeito de luzes piscando intermitentemente na tela (o que é comum em games, mas não em sites de streaming). Fui conferir e olha lá que bacana a mensagem:
E vale lembrar que esses itens aqui também são lembrados pela WCAG em diversos critérios, mas aqui estão listados alguns que são afetados diretamente…
Ufa… Concluindo…
Há diversos outros pontos necessários para se analisar e testar um site em sua total acessibilidade. A maioria absoluta dos testes (mais de 60%) se dá através de testes humanizados (com pessoas de verdade, pra ficar bem claro) como os testes que eu fiz acima. Estes são testes dificilmente detectáveis (pra não dizer impraticáveis) através de ferramentas automatizadas.
Em papos futuros falarei mais sobre os testes.
Neste artigo, a ideia era analisar de forma prática alguns dos problemas mais comuns que vemos em diferentes sites e aplicativos e demonstrar na prática o quanto o pessoal da Disney Plus se preocupou em fornecer uma experiência equivalente para todas as pessoas.
E lembrem-se sempre, aplicar acessibilidade não é algo simples que você pode fazer usando "ferramentas mágicas" que prometem que tudo seja feito com "apenas uma linha de código".
Acessibilidade é algo sério e precisa ser levado a sério por todos os profissionais envolvidos nos projetos. Designers, Desenvolvedores, Negócios, Marketing, Gestores… Absolutamente todos!
Fica aqui meu PATOE (Parabéns A Todos Os Envolvidos) ao projeto do Disney Plus! 😍
Agora chega de falar, que eu tenho um "The Mandalorian" pra assistir… 😂
Me chamo Marcelo Sales, sou designer focado 100% em acessibilidade. Estudo o tema desde 2012, desenvolvo ferramentas de apoio e além daqui no Medium, você me encontra também no Instagram e no LinkedIn! ;)
E se interessar, dê uma olhada no meu curso de Acessibilidade Digital na Mergo, com conteúdos, exercícios e metodologias exclusivas.
