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.

Disney Plus chegou… e junto com ele um bom exemplo de acessibilidade! was originally published in Mergo on Medium, where people are continuing the conversation by highlighting and responding to this story.

Você começou a ler este artigo por um determinado motivo. Ou alguém te indicou, ou você o encontrou por achar o tema interessante ou simplesmente caiu de paraquedas.

A questão é que independentemente do motivo, antes de começar a ler este conteúdo, você gerou uma expectativa para ele e a partir deste momento eu faço parte do seu julgamento.

Como projetistas e criadores de produtos ou serviços, estamos o tempo todo em busca de uma melhor experiência na jornada da pessoa que irá consumir o seu conteúdo — o que consequentemente fará com que a empresa gere mais negócios e talvez mais promotores do seu produto ou serviço.

Este processo é fundamental para a manutenção do ciclo de vida de qualquer produto e do ponto de contato entre consumidor e empresa.

Quantas vezes você já não presenciou projetos que poderiam ser sensacionais em todos os aspectos, mas que por conta de prazos apertados (ou talvez, ego exacerbado), fatalmente sofrem as consequências da ausência de um aprofundamento maior no entendimento das pessoas que o utilizarão?

Além de aprofundamento na pesquisa antes do lançamento, é fundamental manter os ciclos de manutenção e evolução ativos, pois você até pode usar como desculpa a velha:

“Não houve tempo para uma pesquisa pré-lançamento.”

Mas não há desculpas para se manter desatualizado um produto ou serviço, cujos dados de acesso deixam claro que há problemas de uso.

Aliás, você costuma acompanhar o comportamento das pessoas que usam os produtos que desenvolve, ou deixa isso apenas na mão da “equipe de métricas”?

Gerenciando expectativas, muito além da interface e da experiência

É importante deixar claro que “oferecer uma experiência adequada para todos” (verdadeiramente para todos), é algo que dificilmente acontecerá independentemente de sua preocupação ou não com as expectativas, uma vez que a experiência, além de ser única, tem a ver com toda a jornada que o cliente enfrentará ao consumir o seu produto e cada uma dessas etapas é responsável por determinar uma expectativa diferente em quem está consumindo esse conteúdo.

Também é importante perceber que uma coisa é:

• o não atendimento satisfatório no processo de uso de um produto ou serviço — e isso invariavelmente tem a ver com percepções subjetivas da própria pessoa, do tipo “gostei” ou “não gostei”;
• outra coisa é o não atendimento básico e essencial de funcionalidades importantes para a aquisição ou consumo deste mesmo produto ou serviço — o que fatalmente acarretará em uma frustração tanto para o negócio quanto para o cliente e é justamente esse tipo de expectativa que precisamos aprender a gerenciar.

Você deve ouvir o tempo todo termos como UI (User Interface) ou UX (User eXperience), pois esses termos estão de acordo com qualquer framework padrão de desenvolvimento de produtos e serviços, mas quando falamos de expectativas, há uma questão muito comum a quem lida com IHC (Interação Humano-Computador), mas que não é levado tanto em consideração em outras disciplinas (sendo de certa forma, até esquecido).

São as User Expectations, ou seguindo o padrão de siglas, UE; cujo campo de estudo é justamente responsável por lidar com as expectativas das pessoas.

Não, eu não estou criando uma nova sigla.

Estou apenas evidenciando a sua importância no processo que deveria fazer parte de todo o ciclo de desenvolvimento de qualquer produto ou serviço.

E por que isso costuma não ser levado em consideração?

Simplesmente porque as pessoas envolvidas nos projetos estão acostumadas (ou acomodadas ou mesmo são cobradas) em criar seus produtos em cima de personas (quando não em proto-personas) que muitas vezes traduzem de uma forma não completa a real necessidade dos clientes daquele produto ou serviço a ser criado.

Ou então, nos casos em que evoluímos para pesquisas com usuários reais (mas devido aos custos do processo) envolvemos poucos usuários e muitas vezes essas pesquisas acabam sendo utilizadas mais como “viés de confirmação” do que de fato como insumo para direcionamentos inconclusivos e que deveríamos ter “certezas” somente após um longo período de análise pós-publicação, o que normalmente também não é feito, pois envolve se manter focado em um mesmo projeto a médio ou longo prazo.

"Cada vez que pensamos que o problema não é nosso, essa atitude é o problema."

— Stephen Covey

Não confundam essa afirmação como se o problema fosse o uso de personas ou pesquisas — pelo contrário, elas continuam sendo essenciais em todas as etapas.

O problema está na forma como lidamos com esses métodos sem nos aprofundarmos em entender de fato a pessoa em si.

Ao trabalharmos de forma mecânica e direcionada a uma confirmação “da nossa verdade” estamos sabotando o nosso próprio trabalho e longe de pensar verdadeiramente na pessoa que irá utilizar de fato nosso produto.

Envolver pessoas no processo, significa “conhecer de verdade” as pessoas

Enquanto não se abre a mente para lidar com esse entendimento, somos naturalmente direcionados a nos comportar seguindo o modelo de percepção social de Susan Fiske, que nada mais é que criarmos estereótipos ao lidar com pessoas.

Em todas as fases da sua vida, você cria ou criou estereótipos para as pessoas, e, você só as removeu (ou não) dessa “caixinha”, após se relacionar com elas.

Foi, é e sempre será assim com todos os seus relacionamentos pessoais.

Enquanto existir uma certa distância ou barreira, não haverá compreensão.

"As pessoas ignoram o design que ignora as pessoas"

— Frank Chimero

Conhecer verdadeiramente as pessoas está diretamente ligado a fatores humanos gerais que vão desde:

• Fatores emocionais e racionais
• Vieses cognitivos
• Falácias lógicas
• Análise comportamental e arquétipos
• Economia comportamental; e até mesmo
• Análise de tomada de decisões.

Na verdade, conhecer todos esses fatores (e outros) te ajudará um bocado com a questão da previsibilidade necessária para facilitar no entendimento das expectativas citadas neste texto, mas ainda assim, as pessoas reais sempre te surpreenderão.

Qualquer que seja o seu produto ou serviço, ele depende do contato com pessoas. Qualquer que seja o seu negócio, ele também depende do contato com pessoas.

Tenha contato com pessoas, mas tenha um contato real com pessoas. Isso fará toda a diferença no que se propõe a fazer. Vale desde a pesquisa envolvendo pessoas até mesmo a convivência com a diferença diariamente, seja em um âmbito pessoal ou no profissional. É preciso contemplar a diferença em todas as suas sutilezas.

Deveríamos ter menos empatia e muito mais alteridade, diria Carol Zatorre.

Quando você estiver conversando com pessoas, colhendo dados e agrupando-os, será natural ter duas percepções diretamente ligadas:

1. Pessoas são muito mais complexas do que dados e frameworks

Por mais que você colha informações e os agrupe, ainda assim é importante ter a capacidade de absorver os ensinamentos, o que nos leva a outra percepção;

2. Não adianta nada ter dados, sem saber o que fazer com eles

E neste ponto é importante frisar que, não são todas as pessoas que tem facilidade em sintetizar tudo o que foi colhido nas pesquisas, e obter algo realmente relevante que possa contribuir com o desenvolvimento do produto.

Conversar, observar e anotar é relativamente simples, mas sintetizar em algo útil o que foi colhido é literalmente um trabalho relacionado a psicologia — e aqui cabe reforçar a questão de termos as pessoas certas nos lugares certos, o que invariavelmente não acontece, pois não é qualquer um que possui naturalmente essa característica de compreender com facilidade perfis comportamentais e gerar insumos úteis da pesquisa realizada.

Lidar com expectativas é literalmente lidar com o futuro (e também com o passado)

Já percebeu que algumas pessoas nunca deixam um copo encostado em uma ponta da mesa, justamente por que ela sabe que ela mesma ou alguém diferente dela pode esbarrar nesse copo e fazer com que ele caia no chão?

Se você nunca percebeu, definitivamente você não é uma pessoa preditiva e acredite, pessoas preditivas se darão muito melhor em uma posição de análise comportamental e gerenciamento de expectativas.

É justamente a falta dessa capacidade, literalmente uma soft skill, que faz com que as pessoas envolvidas nos projetos “se esqueçam” de lidar com as expectativas dos usuários.

Qualquer um que estude heurísticas, percebe que algo em comum entre elas é o cuidado que seus autores tem com a tolerância ao erro.

Isso é extremamente importante quando se pensa em atender as expectativas das pessoas, pois você não sabe como o usuário consumirá de fato o seu produto ou serviço.

Você criou e projetou pensando em uma “jornada linda e feliz”, mas fatalmente seus usuários não seguirão essa jornada ou então utilizarão os métodos mais diferentes que você possa imaginar (ou não possa imaginar) para acessar seu conteúdo.

Lidar com expectativas é pensar em design inclusivo, é pensar no que pode dar errado no caminho, é pensar que seu usuário pode (ou precisa) utilizar voz para chegar ao seu conteúdo ou talvez um teclado, é imaginar que ele pode descobrir uma rota alternativa e também estar preparado para o caso dele receber algum tipo de mensagem não esperada.

Sobre Tolerância ao Erro

Já que estamos falando em heurísticas, que tal relembrar os momentos em que os autores das principais e mais conhecidas no campo do design, mencionam sobre tolerância ao erro:

• Em 94, Nielsen nos lembrou disso no item 5 (prevenção de erros) de suas Heurísticas de Usabilidade;
• Já em 97, representantes do Centro de Design Universal da Universidade do Estado da Carolina do Norte nos EUA comentou sobre isso também no item 5 (tolerância ao erro), em seus Princípios do Design Universal;
• Em 98, Tim Berners-Lee falou sobre tolerância no item 4 (tolerância) de seus Princípios de Design para a Web;
• Daí em 2002, Norman em seu livro, O Design do dia a dia, onde ele nos trouxe os 6 Princípios de Design, não menciona a tolerância diretamente, mas ela está presente em Affordance, Feedback e Visibilidade (na verdade, nos demais também);
• E no ano seguinte, 2003, o sempre esquecido Bruce Tognazzini (ou apenas, Tog) também cita a tolerância em vários de seus Princípios de Design de Interação, como no item 15 (proteger o trabalho dos usuários) ou no 12 (redução da latência) ou no 6 (predefinições) ou no 2 (antecipação)… enfim, creio que todos aqui tenham algo relacionado com tolerância ao erro;
• Seguindo a sequência cronológica, a versão moderna da WCAG (ou Diretrizes de Acessibilidade para Conteúdo Web) que é baseada em 4 Princípios e também são heurísticas, lidam com a tolerância em muitos de seus 78 critérios de sucesso.

Enfim, lidar com as expectativas das pessoas é fundamental para o sucesso de qualquer produto ou serviço, e a forma mais simples de lidar com isso é compreendendo de fato o que as pessoas que usarão o seu produto querem.

Parece óbvio dizendo assim, mas acredite, não é.

No entanto, acompanhar como está o progresso do seu produto, associar isso a novas possibilidades de melhorias e consequentemente aplicar em técnicas que podem fazer com que você compreenda melhor o que o seu usuário espera é uma outra forma de lidar com as expectativas.

"Um cliente insatisfeito significa uma nova oportunidade para aprender."

— Bill Gates

Qualquer que seja o momento ou situação do seu produto, o que definirá o seu sucesso ou fracasso será a capacidade que você tem de lidar com as expectativas — não as suas, pois essas se traduzirão em frustração caso você não aprenda a lidar com a dos outros.

Previsibilidade, clareza e humanidade: sempre serão as melhores opções para todos

Qualquer semelhança com relacionamentos entre pessoas, “não” é mera coincidência.

Lidar com expectativas é literalmente lidar também com frustrações e para que elas sejam evitadas, precisamos ter previsibilidade e clareza nas informações.

Cheryl Platz traduz muito bem essa questão em sua palestra “Opti-pessimism — Design for the best case, build for the worst”. Ela deixa muito claro que:

Lidar com perguntas difíceis é algo mais complexo do que se imagina, e isso contribui para que não sejamos previsíveis ao se desenvolver produtos.

Explorar o contexto humano e sempre desenvolver pensando no “pior” caso, são fundamentais no processo.

A designer Jo Szczepanska montou uma timeline sensacional demonstrando quando fatores como antropologia e psicologia cognitiva ou negócios e tecnologia passaram a ter uma ligação direta com o design nos últimos 60 anos.

Nele é possível perceber claramente a maior atenção que o design passou a dar (ou deveria dar) para as pessoas em todos os seus processos. Fazer um paralelo a isso com o desenvolvimento de produtos e serviços, faz todo sentido e abre margem ao desenvolvimento mais humanizado e consequentemente traz uma responsabilidade maior no gerenciamento das expectativas dessas pessoas.

"Se quisermos que os usuários gostem do nosso software, devemos projetá-lo para se comportar como uma pessoa agradável: respeitosa, generosa e útil ."

— Alan Cooper

E se mesmo após compreender a importância de se envolver as pessoas em todo o processo de desenvolvimento de um produto, você ainda não conseguir gerenciar as expectativas de quem o utilizará, talvez a leitura de cartas de tarot, funcione (não é ironia, é sério).

Ou se quiser algo mais prático, quem sabe, saber estatisticamente que 73% dos consumidores esperam que as empresas entendam suas expectativas e necessidades faça você dar mais atenção a isso tudo.

Aprenda a atender expectativas e nunca mais (ou quase nunca) lide novamente com frustrações.

Este texto foi originalmente escrito em 2019 para o projeto “Design 2020”.

Como você lida com as expectativas do usuário de seu produto ou serviço? was originally published in UX Collective 🇧🇷 on Medium, where people are continuing the conversation by highlighting and responding to this story.

Faça um teste rápido enquanto navega em seu site preferido, esqueça o mouse por um instante e navegue por teclado. Não sabe como fazer? Dependendo dos elementos em tela, os controles podem ser complexos e este artigo da WebAIM pode te ajudar a entender melhor como navegar com teclado caso nunca tenha feito isso, mas os comandos básicos são a tecla TAB (para mover o foco para o próximo elemento) e SHIFT+TAB (para mover o foco para o elemento anterior).

É importante ressaltar que a navegação padrão se dá por elementos clicáveis, como links, botões ou controles de formulários. Alguns outros elementos também podem receber foco, mas isso será papo para um outro artigo, hoje a ideia é dar ênfase no foco visível que ocorre de maneira natural, ou seja, em itens clicáveis.

Se tudo estiver certo, você perceberá um contorno azulado em volta dos elementos clicáveis, mais ou menos parecido com isso:

Pausa para um disclaimer aqui: É importante ressaltar que há uma diferença por quem navega por teclado e enxerga o conteúdo e quem navega por teclado e não enxerga o conteúdo. Este artigo trata especialmente do primeiro caso, de quem está enxergando o conteúdo. A Léonie Watson tem um artigo bem completo falando sobre as diferentes formas de se navegar por teclado.

Mas isso acontece apenas se tudo estiver certo, por que infelizmente, muitos designers removem essa borda simplesmente por a acharem esteticamente "feia". As vezes a culpa não é do designer, é verdade, e alguém (qualquer) da equipe pede a remoção da tal borda. Fato é que as pessoas a removem por apenas dois motivos: "estética" ou "ignorância total da acessibilidade".

É relativamente fácil enumerar alguns casos de uso em que essa "borda" é importante:

• Pessoas com baixa visão que fazem uso de leitores de tela e navegam por teclado;
• Pessoas com deficiências cognitivas ou dificuldade em aprendizagem que precisam ter atenção e visualizar o foco do elemento ativo;
• Pessoas com algum tipo de deficiência motora com dificuldades em usar um mouse;
• Pessoas que não possuem nenhum controle manual ou mesmo que não possuem as mãos e navegam através de diferentes tipos de tecnologia assistiva;
• Pessoas que fazem uso de teclados especiais para navegação;
• Pessoas que podem não ter um mouse disponível no momento (falta de pilhas, por exemplo);
• Pessoas que preferem usar o teclado para algumas situações (navegar por um formulário com muitos campos de preenchimento).

Caso ainda não tenha percebido, estamos falando de navegação através de um teclado (não necessariamente com um leitor de telas ativado). Trata-se do design de interação através do uso de outros métodos diferentes do que um mouse.

Enfim, não é difícil perceber a importância dessa borda em torno dos elementos ativos em tela. Pra ficar mais claro ainda, imagine que o ponteiro do seu mouse é o seu feedback visual enquanto rola ele pela tela. Quando se passa o mouse em cima de links ou botões, há outro tipo de feedback, que é o que chamamos de estado "hover", mas e quando se navega por teclado? Qual é o feedback visual que a pessoa tem? Exato! A tal da borda, cujo nome correto é "foco visível" e ele ocorre justamente quando o elemento é focado via teclado.

Um site que sempre recomendo sobre essa questão é o outlinenone.com que possui algumas informações técnicas de como remover a borda, do porquê não fazer isso e como customizar o elemento.

Este tuíte do Denis Boudreau vai direto ao ponto dessa questão (ele menciona que ao remover o "outline: none" do arquivo de CSS de seu site, cerca de 40% dos problemas de acessibilidade pra quem usa o teclado, se resolverão "automaticamente").

dboudreau on Twitter

Wanna fix about 35 to 40% of navigation #accessibility issues for sighted keyboard users at once? Go to your CSS and get rid of every occurrence of: {outline: none;} or {outline: 0;} STOP taking the visible focus indicator away from end users. Yeah. It's really that simple.

É sobre a customização do foco visível que quero dar maior atenção neste artigo, justamente por ter contato com muitas pessoas envolvidas com o desenvolvimento de sites, percebo que boa parte delas sequer sabem da possibilidade da customização da "tal da borda" e daí acabam tomando a decisão de remove-la por fatores estéticos.

Esse é um dos motivos que eu sempre digo que designers de sites precisam conhecer HTML e CSS para no mínimo saber o que podem ou não fazer… e não adianta perguntar pro desenvolvedor diretamente, pois a maioria também desconhece as propriedades do CSS pelo simples motivo de ser algo relacionado ao visual. Exemplo: Posso utilizar uma borda tracejada em torno de um botão para representar o foco visível, isso é feito diretamente no CSS, se o designer não souber dessa possibilidade é pouco provável que o desenvolvedor saiba também, pois ele não pesquisa os recursos visuais da linguagem… CSS é linguagem de designer! Envolve características como espaçamentos, formatos, medidas, cores, transições, animações, etc. Os maiores conflitos entre desenvolvedor e designer ocorrem pela falta de comunicação (e também conhecimento). Brad Frost que o diga neste artigo.

Customizando o foco visível

Antes de falar de customização, vamos falar de como é o padrão de cada browser. E ao invés de printar elementos em todos os browsers, vou deixar esse tuíte aqui do Mikael Ainalem em que ele comenta uma recente atualização do Safari onde ocorreram ajustes nos focos padronizados pra que eles se adequassem a forma dos elementos, como no caso do botão demonstrado na mensagem dele:

Mikael Ainalem on Twitter

Safari fixed their outline on focus 👏. It looks far better than other browsers. Another way to fix a11y, other than raise awareness, is to make it more beautiful.

Pra ser honesto, não vejo vantagens nisso no momento atual, pois hoje podemos customizar essa interação, no entanto é importante reforçar que cada browser tem as suas próprias características e as empresas que os criam também pensam em melhorias de seus produtos no que tange a acessibilidade.

Levando isso em consideração, vale lembrar que nem sempre a opção "padrão", será a melhor em alguns casos e o foco visível é um exemplo claro dessa questão. Em todos os projetos que participei, no momento que o foco visível foi discutido não houve uma única ocasião em que alguém não tenha sugerido uma customização visual, justamente pelo foco se comportar diferente em browsers diferentes ou ele não ter contraste suficiente em alguns casos.

Foco customizado em botões e links

A customização em si fica a critério de cada um, pois ela deve ser feita de acordo com a identidade visual de seu projeto, o abaixo demonstra botões diferentes na cor laranja utilizados no Manual de Acessibilidade construído internamente no Itaú e que oferece suporte sobre o tema para diferentes times.

Neste exemplo, demonstro a utilização da mudança de cor dos botões e a inclusão de uma borda tracejada em um tom altamente contrastante (escuro) e uma espessura de 2px (guarde essa informação, que será explicada depois).

As animações abaixo demonstram o funcionamento dos estados (hover, por mouse, quando o ponteiro está por cima do elemento) e (foco, por teclado):

Como podem perceber, neste caso eu deixei a mesma interação para ambos os estados (hover ou foco), o que não é uma obrigação e como falei anteriormente vai depender da identidade visual de seu projeto e como você quer trabalhar com os diferentes estados de interação.

No caso deste manual, optei por utilizar o mesmo formato para ambos os estados também nos links distribuídos entre as páginas:

Mas é possível deixar cada estado com uma interação diferente. E eu fiz isso no site com os Princípios do Design Inclusivo, exemplificado nessa animação:

Perceba que quando uso um mouse, opto pela mudança de cor de fundo do link ativo no momento e quando uso a navegação por teclado, deixo apenas a borda customizada com uma borda de 2px, um tom de azul contrastante e uma microanimação para dar ênfase e destacar o elemento selecionado.

Outro exemplo que posso dar ainda em links, mas dessa vez levando em consideração um menu superior de navegação é o que utilizo no Guia WCAG, como demonstrado nessa animação:

Neste caso, optei também pela mesma interação para ambos os estados, seja no uso de mouse, seja no uso de teclado. Em ambos os casos há uma borda azul de 2px em alto contraste com a cor de fundo. Neste caso a diferença ocorre devido a natureza dos elementos demonstrados: menu de navegação no topo e link entre textos na página. Perceba que o espaçamento dado para o menu foi muito maior e isso foi proposital para dar ênfase visual.

Foco customizado em formulários

Outra questão relacionada a navegação por teclado é a customização do foco em itens de formulário e aqui também vale a regra da customização de acordo com a identidade visual do seu projeto. Tecnicamente falando é também mais complicada dependendo do nível de interação que se deseja atingir, mas é importante saber que também é possível ser realizada em qualquer situação.

Esses dois exemplos abaixo estão no Guia WCAG e eles demonstram um elemento de checkbox e um campo de input text, respectivamente.

Neste caso, a interação com o foco pode ser realizada apenas através do foco, no entanto você pode criar a interação através do "mouse over" também (isso é opcional). No caso do Guia WCAG, eu optei por fazer isso.

Acredito que um bom exemplo de interação por teclado em formulários são os apresentados na biblioteca de componentes do Angular do Google para o Material Design, listo abaixo alguns desses exemplos:

Campos de input text e textarea

Neste exemplo, perceba a movimentação do mouse e a navegação por teclado (quando o ponteiro não está por cima) e o seu comportamento exatamente igual para ambos os casos de interação. Sacou que a linha de digitação salta de 1px para 2px após o foco no elemento? Guarde essa informação também, que já comento sobre isso… Em tempo, a opção pelo uso de "float labels" neste caso não impacta na acessibilidade, desde é claro, que seja corretamente implementada (consulte a documentação do material design). ;)

Radio Button

Já no caso de Radio Buttons, há uma ligeira diferença de interação entre os elementos, quando se passa o mouse por eles é possível perceber uma pequena mudança na cor de fundo do elemento (cinza claro, gerando um feedback visual). O que não ocorre quando se navega por teclado, uma vez que o elemento é selecionado diretamente neste caso. Não há impacto de níveis de contrastes também, pois o que define se o elemento está ou não ativo, não é essa "pequena interação" com o mouse. Por fim, a navegação entre itens em um mesmo grupo de Radio Buttons se dá por "setas direcionais" e não por TAB (é importante entender o comportamento de interação, para que isso não gere "falsos positivos" em testes de acessibilidade).

Checkbox

No caso de Checkboxes, há também uma ligeira diferença de interação entre os estados de hover e foco. Bem parecida com o caso do Radio Button, mas neste caso a diferença principal está na navegação por teclado que ao dar foco no elemento, ele não é selecionado diretamente (o Radio Button, sim) e neste caso a seleção é efetuada através do uso da barra de espaço. Só a partir daí é que o elemento muda o tom de cor para que seja possível identificar o seu status (habilitado ou não).

Slider (pra citar apenas um caso de elemento de formulário complexo)

Existe alguns elementos com interações de teclado complexas em formulários e um deles sem dúvida é o slider (não vou entrar no escopo do que é preciso ter em um slider acessível nesse momento, vou me ater ao básico de navegação por teclado). Perceba no exemplo acima que a interação também é ligeiramente diferente entre o uso de mouse (quando o ponteiro está por cima do elemento) e teclado. A navegação por teclado, neste caso, também se dá por setas direcionais, mas é importante perceber que quando se navega por teclado, os feedbacks visuais também são tão importantes quanto.

"Aspecto visual" versus "Aspecto aural"

Diante de todos esses exemplos apresentados, vale lembrar que tudo o que estou falando até aqui é com relação a uma interação VISUAL! Não estou entrando no mérito do uso de leitores de tela e os feedbacks essenciais e necessário para cada uma das situações anteriormente apresentadas.

Farei isso em uma segunda parte deste artigo em breve, com foco exclusivamente no aspecto aural das informações, mas isso é válido para perceberem que a acessibilidade completa em produtos digitais é aplicada tanto em aspectos visuais quanto em aspectos aurais.

E pra mobile? Essa customização funciona também em dispositivos móveis (celular, tablet)?

É importante entender que o comportamento do foco visível em mobile é diferente do que ocorre em desktop. Isso por que, por padrão, o foco visível em mobile surge apenas quando um leitor de telas (VoiceOver ou Talkback) está ativado e isso está relacionado a uma série de questões que vão desde ao tamanho da tela disponível ao comportamento de interação por toque.

Apesar de eu não recomendar a customização dos elementos para este caso em especial, saiba que caso você precise, é possível sim customizar esses elementos tanto em iOS quanto em Android. O guia da BBC focado em produtos acessíveis, faz menção a isso.

Do ponto de vista de interação e seu relacionamento com a WCAG, a W3C cita como relacionar as diretrizes em ambientes móveis em um guia e há uma sessão específica sobre o uso de teclado físico em dispositivos móveis (sim, algum usuário pode conectar um teclado bluetooth aos aparelhos por alguma necessidade específica também).

Falando em WCAG, como relaciono todos esses aspectos as diretrizes de acessibilidade?

Agora sim chegamos a parte técnica e mais interessante do artigo, que foi o que me motivou a escrever este texto. A versão atual da WCAG é a versão 2.1 e há uma nova versão estrutural das diretrizes a ser lançada em breve (sem data ainda), no entanto, o grupo de trabalho atua paralelamente para atualizar da melhor forma possível as diretrizes atuais sem que haja um grande espaço de tempo entre novas atualizações.

Com isso, no último rascunho (draft) apresentado pelo grupo de trabalho em 05 de março de 2020, houve a inclusão de um novo critério (ainda em rascunho, o que significa que ainda está sendo discutido, mas bom o suficiente para já ser utilizado por todos) que está relacionado ao foco visível:

• 2.4.11 — Foco Visível (melhorado) — Nível AA

Este critério está diretamente relacionado ao já existente 2.4.7 (Foco Visível) Nível A, e ele não cria nada novo, mas apenas reforça algumas questões que já deveriam ser levadas em consideração com o critério anterior, mas que no entanto sempre eram casos de discussões eternas justamente pelas pessoas envolvidas não saberem o que necessariamente era preciso se levar em consideração.

O critério define alguns padrões para que se tenha um foco visível verdadeiramente útil e são esses:

• Área mínima: A área de indicação do foco precisa ser igual ou maior do que 2x a largura do lado mais longo do elemento. Confuso? Peraí que já explico… ;)
• Contraste do foco: As cores utilizadas na alternância do foco (focado ou não focado) deve ter uma relação mínima de contraste de 3:1. Ou seja, segue-se o padrão já estabelecido para níveis de constraste em diretrizes já existentes.
• Contraste da espessura: A cor utilizada para a apresentação do foco visível (a borda) deve ter uma relação mínima de contraste de 3:1 com áreas adjacentes ao elemento ou pele menos 2px de largura (isso explica os 2px dos elementos de exemplo acima apresentados).

Lá vem aula de matemática…
Agora senta pra aula de matemática que a conta é simples, mas fácil de ser mal interpretada… :) Vamos falar sobre a questão da "área mínima" para se definir o tamanho de um foco verdadeiramente útil, porém para entendermos esse relacionamento é importante compreender a lógica por trás disso tudo…

Qualquer critério da WCAG sempre leva em consideração duas medidas relativas. Pontos (ou PT, que muitos confundem com PX) e CSS Pixel. Neste artigo vamos falar apenas do segundo.

Um Pixel CSS ou “pixel de referência” é uma unidade de medida canônica para qualquer comprimento ou medida em CSS. Essa unidade independe da densidade de pixels reais das telas dos devices, ou seja, é o próprio ambiente que faz os cálculos de adaptação necessários para a respectiva tela do device. O pixel de referência equivale ao ângulo de visão da distância do olho para um determinado device, mais precisamente a distância de um braço (28 polegadas ou 71cm), o que corresponde a 0,26mm para o tamanho de 1 pixel (e isso vai aumentando conforme se aumenta a distância).

É um pouco confuso, mas tudo faz sentido quando se compreende as diferentes unidades de medidas e seus relacionamentos. Caso queira se aprofundar ainda mais no tema, comece pela documentação de unidades de medidas do W3C.

Agora que sabemos o que originou esse papo, podemos entender o relacionamento com o que seria válido para se atender ao foco visível relacionado a área mínima dos componentes em tela.

Segundo o critério 2.4.11 da WCAG, para se determinar uma área mínima que determina um foco válido e útil é preciso se basear no tamanho do elemento. A área de foco deve representar o tamanho (em pixels quadrados) de 2x a maior largura do elemento. Ou seja, se um elemento possui 90 x 30px, a marcação do foco visível útil deverá ser 180px quadrados, que equivale 2x o tamanho da maior largura que é de 90px. Fácil, não? :)

Elaborei esse diagrama aqui pra ficar o mais claro possível a forma de se chegar ao resultado… :)

Imaginem um botão rosa de 90 x 30px…

A grande questão é que você não precisa fazer todas essas contas e o exemplo acima extrapola propositalmente a questão. Oque acabei de demonstrar é a teoria, o cálculo e o objetivo em se medir essas informações. O designer que tem um olhar atento aos detalhes, saberá criar alternativas de uma forma muito simples (e visual) que contemplará todas as situações…

Quer exemplos?
Esses aqui foram retirados diretamente da página do novo critério de sucesso (que vale lembrar, ainda está sendo definido):

Perceba que não há uma regra para o foco visível, há sim uma boa prática em se seguir os padrões convencionais visando o correto atendimento da usabilidade (heurísticas, né?), mas o designer não está limitado a isso. Aqui deixo claro que uma das maiores reclamações dos designers, que é o fato da "acessibilidade limitar a criatividade", cai por terra! Ou seja, você pode ser bem criativo, a questão é… você precisa ser criativo aqui? ;)

Mas e se a forma dos elementos forem específicas, como uma bola ou uma estrela?
Tudo foi pensado no critério de sucesso e há variações para esses exemplos também…

Enfim, é importante saber que ACESSIBILIDADE NÃO LIMITA A CRIATIVIDADE! Seja criativo, desde que você siga alguns padrões, consistências e evoluções para pensar verdadeiramente em um design inclusivo.

Entenda que os critérios da WCAG não funcionam sozinhos…

Pra finalizar este artigo e todos esses exemplos, compreenda de uma vez por todas que nenhum critério de sucesso da WCAG funciona sozinho. Ele sempre será relacionado a algum outro existente e mais importante ainda, nenhum deles é tão complicado a ponto de que não possa ser explicado de uma forma didática, mesmo que se use um textão pra isso… ;)

Esses são os critérios de sucesso da WCAG, relacionados a questão do foco visível, que também precisam ser contemplados:

• 1.3.2 (Sequência com significado) [nível A]: A ordem de leitura e a navegação pelos componentes em tela deve fazer sentido para o usuário.
• 1.4.3 (Contraste-mínimo) [nível AA]: Textos devem ter uma relação de contraste* entre primeiro e segundo plano de ao menos 4.5:1.
• 1.4.6 (Contraste-melhorado) [nível AAA]: Textos devem ter uma relação de contraste* entre primeiro e segundo plano de ao menos 7:1.
• 1.4.11 (Contraste não-textual) [nível AA]: Componentes de interface e imagens essenciais para o entendimento do conteúdo devem ter uma relação de contraste entre primeiro e segundo plano de ao menos 3:1.
• 2.1.1 (Teclado) [nível A]: Toda funcionalidade deve estar disponível para utilização com teclado, a menos que a funcionalidade não possibilite o controle apenas por teclado.
• 2.1.2 (Sem bloqueio de teclado) [nível A]: Deve ser possível navegar de e para todos os elementos sem qualquer tipo de bloqueio de teclado.
• 2.1.3 (Teclado-sem exceção) [nível AAA]: Toda funcionalidade deve estar disponível para utilização com teclado.
• 2.4.3 (Ordem do foco) [nível A]: A navegação (através de um teclado) por elementos focáveis em tela deve ser sequencial e lógica de acordo com o conteúdo apresentado.
• 2.4.7 (Foco visível) [nível A]: Ao se navegar por teclado (ou toque) deve ser possível identificar visualmente e facilmente qual elemento da página ou tela tem o foco no momento.
• 2.4.11 (Foco visível-melhorado) [nível AA] — DRAFT (o critério que originou este material): Sempre que o foco visível for exibido, será preciso ter um espaçamento mínimo entre ele e o conteúdo e o relacionamento de contraste com áreas adjacentes precisa ser suficiente.

Lembrando mais uma vez que não estamos entrando ainda no mérito do uso de leitores de tela, ok? Esses critérios e ajustes referem-se ao que se precisa ser feito do ponto de vista visual. Todos os 78 critérios podem ser consultados no Guia WCAG.

E pra finalizar este artigo, alguns sites com bons exemplos de FOCO VISÍVEL para que vocês possam se inspirar a criar os próprios (lembrem-se de testar através de um teclado):

• American Airlines
• Apple
• Microsoft
• Gov.UK
• A11Y Portal
• W3C-WAI (Web Accessibility Initiative)

Você tem algum outro bom exemplo? Comente este artigo… :)

Está procurando por algum curso de acessibilidade?

Quer aprender como efetuar o planejamento de acessibilidade na sua empresa? Como aplicar e envolver todos na equipe (do estagiário ao product manager)? Como especificar e gerar documentações? Ou como dar foco no design como escrito neste artigo? Então conheça o curso que ministro na Mergo. Verifique as turmas disponíveis e o programa completo no site e se tiver dúvidas, comente aqui.

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 Twitter, no Instagram e no LinkedIn! ;)

A importância do foco visível para a acessibilidade digital was originally published in Mergo on Medium, where people are continuing the conversation by highlighting and responding to this story.

Primeiro, vamos deixar claro que todos são responsáveis por implementar acessibilidade em produtos e serviços digitais. Não dá pra colocar na conta de apenas uma pessoa ou área, quando um projeto não sai como esperado. Neste artigo que escrevi em 2017, "Quem são os responsáveis por aplicar a acessibilidade em projetos digitais?", menciono as responsabilidades de cada área envolvida na aplicação da acessibilidade:

• Negócios
• Marketing
• Design/UX
• Tecnologia
• Qualidade/Testes

Neste mesmo artigo, há também a menção de 4 principais membros que toda empresa deveria ter e que foram mencionados em uma apresentação do John Foliot (uma das principais referências no mundo), mas aqui vamos focar em apenas um desses membros que é o Accessibility Champion.

Importante: Esse tema está diretamente relacionado com o desenvolvimento de uma cultura de acessibilidade dentro da empresa. Porém, este texto não falará diretamente sobre a cultura, isso será papo para outro artigo. Hoje focaremos exclusivamente nos cargos e formas de contratação.

Campeão de Acessibilidade? É sério isso?

Sim, é sério. E apesar de no Brasil não termos o costume de chamar pessoas que ocupam cargos chave de uma empresa de "campeões", essa terminologia é bem comum em outros países.

Segundo uma das definições no Cambridge Dictionary, "champion" significa "a person who enthusiastically supports, defends, or fights for a belief or principle", ou seja, trata-se de "uma pessoa que apóia, defende ou luta com entusiasmo por uma crença ou princípio", o que vendo dessa forma, faz todo sentido ter essa terminologia para alguns cargos e funções.

Mas afinal, o que faz um "Accessibility Champion"?

Segundo o livro "Digital Accessibility as a Business Practice", as características do "Accessibility Champion" são:

• Tem a capacidade de liderar;
• Pode influenciar pessoas em todos os níveis hierárquicos e em todas as funções;
• Possui fortes habilidades de comunicação (verbal e escrita) e capacidade de motivar as pessoas;
• É criativo quando se depara com situações desafiadoras;
• Pode falar sobre questões de deficiência de maneira bem informada;
• Está familiarizado com uma variedade de tecnologias assistivas;
• Compreende os efeitos sociais da inclusão;
• É apaixonado por design inclusivo;
• Possui uma sólida formação técnica.

Além de algumas características "desejáveis":

• É capaz de ensinar;
• É capaz de se apresentar de forma convincente para qualquer tipo de público;
• Tem uma deficiência ou está intimamente relacionado a alguém com deficiência;
• É um engenheiro de software, programador ou desenvolvedor web;
• É um designer de interface ou designer de interação.

Na prática, se você imaginar times ágeis e a sua estrutura padrão, fica fácil imaginar o “Accessibility Champion” como um “Chapter Leader de Acessibilidade” desempenhando as funções de capacitação dos diferentes times enquanto produz materiais, relatórios e faz a ponte de comunicação entre todos os membros, para que se mantenha a consistência no tema. Essa não é necessariamente uma verdade, mas talvez analisando dessa forma fique mais fácil identificar o papel real dessa função.

Quais os níveis de conhecimento para se tornar um especialista em acessibilidade?

Você já possui algumas das competências acima descritas, certo? Agora você quer se especializar cada vez mais e já decidiu que irá se tornar um especialista em acessibilidade digital. A primeira coisa a se fazer a partir desse momento é descobrir o que de fato você precisa saber e conhecer para se especializar no tema.

Normalmente esse conhecimento acontece de forma natural conforme a execução da função. Por mais que você leia ou estude, a prática será fundamental para que você identifique necessidades, e é a partir das necessidades que surgem os desafios (isso serve para qualquer campo de atuação, e com acessibilidade não é diferente).

Uma vez identificado os desafios, será natural você buscar formas de resolve-los, e é a partir deste momento que você perceberá o seu nível de conhecimento referente ao tema.

Glenda Sims (líder da equipe de acessibilidade da DEQUE) em seu artigo sobre "ter ou não uma certificação de acessibilidade" mostra a seguinte escala de proficiência:

Dando continuidade ao artigo da Glenda, a escala acima representa uma visão macro do seu estágio de conhecimento sobre o tema Acessibilidade. Uma vez que você decide se tornar um especialista no tema, percebe naturalmente que o seu campo de atuação começa a se ampliar gradativamente.

Provavelmente hoje você atua em um determinado campo de atuação, como designer, desenvolvedor, testador, etc, mas se chegou até esse texto é porque também está ampliando seu conhecimento para a acessibilidade. A grande questão é que você precisa decidir se irá continuar tocando o seu campo de atuação específico e também acessibilidade ou se irá se especializar profundamente em todos os pontos da acessibilidade para se tornar um especialista neste tema.

O "Especialista em Acessibilidade" (por área de atuação) normalmente está em todas as equipes e áreas, cada um sendo focado em seu respectivo campo de atuação, está mais preocupado em disseminar o que é necessário fazer sobre acessibilidade dentro do seu escopo de envolvimento. Já o "Accessibility Champion" atuará em praticamente todos os campos (em alguns casos também em uma respectiva área, mas no geral atendendo a todos e em todos os momentos), dando direcionamentos e coordenando estratégias, além de capacitar mais pessoas para que disseminem conteúdos e desenvolvam uma cultura de acessibilidade dentro das empresas.

Neste texto falando de acessibilidade em produtos, a BBC explica como é a atuação dos times de Acessibilidade por lá:

"A acessibilidade não é um recurso adicionado em um determinado ponto durante a produção. São muitas as conversas e decisões intencionais que ocorrem ao longo do processo de design e desenvolvimento. (…)

A BBC tem uma rede de mais de 150 [hoje 200, na verdade] campeões entusiastas da acessibilidade, que trabalham em diferentes cargos em todos os produtos digitais oferecidos ao nosso público. (…)

A equipe de acessibilidade da BBC apóia nossos campeões, mas é o compromisso de nossos campeões que impulsiona a implementação da acessibilidade em todo o nosso portfólio digital."

Seja qual for o seu campo de atuação, o conhecimento básico de acessibilidade é imprescindível a todos que queiram se especializar no tema. Mas o que engloba esse conhecimento?

Uma das certificações mais reconhecidas nesse campo é a CPACC (Certified Accessibility Professional Core Competencies) e neste caso ela divide o conhecimento principalmente em 3 campos de atuação:

Para consultar a lista detalhada com o conhecimento necessário, acesse a página da certificação CPACC, mas não se assuste com a lista, esse conhecimento acontece de forma natural conforme você vai aplicando, lendo, estudando, pesquisando…

Esse conhecimento (que reitero, é básico para profissionais que atuam com o tema), deve se complementar ao do seu respectivo campo atuação, por exemplo:

• Desenvolvimento: Padrões Web, Accessibility Tree, ARIA, etc;
• Design: IHC, Arquitetura de Informação, Heurísticas, Tecnologias Assistivas e suas diferentes formas de interação, Comportamento de uso em escopos específicos, Responsividade e Adaptação, Design Inclusivo, etc;
• Conteúdo: Técnicas de texto inclusivo, Documentos acessíveis, Descrição de conteúdos não textuais, Práticas de compreensão textual, etc;
• Testes: Compreender a fundo a WCAG, Conhecer ferramentas de testes, etc.

São apenas alguns exemplos… Cada campo de atuação terá os seus respectivos conhecimentos para implementar adequadamente a acessibilidade em seus produtos ou serviços, mas lembre-se sempre que o conhecimento não é apenas específico aos seus respectivos campos (no fim, todo conhecimento se junta).

Não há uma ordem específica para que o conhecimento seja adquirido, mas é preciso conhecer bem sobre aquilo em que irá atuar. Enfim, cada campo de atuação precisará compreender o "COMO deve ser feito", enquanto o conhecimento básico representa o "POR QUÊ está sendo feito".

E como anda o mercado com relação a esses cargos e funções?

De cara posso dizer que no Brasil o mercado está infinitamente longe de chegar ao patamar de como as empresas lá fora estão atuando. Estamos vivendo por aqui um momento de transição, onde as empresas no geral ainda estão se conscientizando sobre o tema, mas tanto os gestores, como os profissionais envolvidos, ainda possuem muitas dúvidas sobre como trabalhar bem com esse tema.

Raramente vemos profissionais alocados 100% do tempo com atividades relacionadas a acessibilidade e quando vemos é comum ele não ter tanta autonomia ou mesmo uma equipe de suporte. Ele acaba sendo responsável por pesquisar necessidades e requisitos, organizar testes com usuários (quando consegue fazer), disseminar conhecimento e não é raro ter dificuldade para atingir gestores em posições estratégicas, o que fatalmente compromete a aplicação e desenvolvimento do tema dentro da empresa. Minar um profissional que ainda está aprendendo sobre um determinado tema pode ser um tiro no pé, pois o profissional não se sentirá a vontade para trabalhar devido as cobranças exageradas e os gestores não saberão gerenciar adequadamente as expectativas dos projetos, o que só fará com que todos "patinem" sem necessariamente sair do lugar com um planejamento verdadeiramente efetivo.

Caso você tenha uma experiência bacana atuando como profissional focado em acessibilidade, comente este artigo e vamos trocar ideias. Precisamos apoiar e movimentar o mercado para que os gestores percebam a importância de se tratar a acessibilidade como fator competitivo e essencial para o desenvolvimento de produtos melhores.

Ainda vemos muitas empresas tratando o tema com a visão de compliance, o que é altamente equivocado, pois a empresa está perdendo oportunidades de realmente trazer uma qualidade muito maior para seus produtos e serviços. Essa abordagem de compliance ocorre há muitos anos por aqui e uma das pessoas que mais elucida essa questão é o Clécio Bachini em sua palestra no TDC de 2017 na Trilha de Acessibilidade.

Fora do Brasil a história é outra. A maioria das empresas enxerga a acessibilidade como um processo fundamental em todo o ciclo de desenvolvimento e vida de produtos e em alguns casos, há centenas de profissionais envolvidos no processo.

Os exemplos abaixo são referentes a grandes empresas reconhecidas no mundo em seus respectivos campos de atuação. Abrindo as imagens você tem acesso a toda a descrição da vaga, mas sempre há um resumo ao seu lado.

Perceba o quanto habilidades de comunicação e facilidade de promover a capacitação (soft skills) são importantes em quase todas as vagas, justamente por que isso envolve uma mudança de cultura dentro da empresa (e fora dela). Todas as vagas exigem um excelente conhecimento de acessibilidade em todos os seus aspectos e o foco sempre é em pessoas (todas as pessoas). Algumas descrições chegam a emocionar ❤ . Gostaria muito de começar a ver esse tipo de descrição nas vagas por aqui no Brasil… ainda veremos e algo indica que não deve demorar muito… ;)

• Lead Accessibility
  Spotify
  New York, USA
  US$125.000 a 140.000/ano

OBS: a única com salário divulgado, mas vendo a média salarial para cargos semelhantes no GlassDoor, os demais abaixo ficam na mesma média.

Principais atividades: saber definir boas práticas, priorizar e disseminar conteúdo entre todos os profissionais. Estabelecer e governar padrões técnicos e de design em todas as plataformas de serviços e para pessoas de todos os níveis da empresa (do C-level aos Estagiários). A experiência necessária gira em torno de soluções de tecnologia e design com foco em acessibilidade digital, políticas, legislação.

• Accessibility Director
  Google
  California, USA

Principais atividades: Visão ampla dos produtos e serviços do Google para garantir que todos estejam em seu máximo impacto positivo sobre os usuários e funcionários com algum tipo de deficiência. Seu escopo vai além do Google, ajudando a melhorar as práticas de desenvolvimento em todo o setor. Experiência e ótimo domínio sobre acessibilidade e vínculos com comunidades de pessoas com deficiências e capacidade de entender o complexo relacionamento entre organização e seu ambiente.

• Manager Accessibility Experience
  Google
  California, USA

Principais atividades: Criar experiências eficientes, agradáveis e produtivas para todos. Testes manuais com software e hardware de tecnologia assistiva e aconselhar as equipes de produto sobre design e usabilidade acessíveis. Exige certificação IAAP, conhecimento profundo de WCAG, ARIA, Section 508 e experiência em identificar problemas e aplicar soluções de acessibilidade.

• Chief Accessibility
  Atlassian
  California, USA

Principais atividades: Desenvolvimento da estratégia de acessibilidade corporativa da Atlassian. Capacitar os “atlassianos” sobre como garantir que produtos que eles estejam construindo sejam acessíveis. Agir como “o cara da acessibilidade”, impulsionando relacionamentos e comunicação sobre o tema globalmente. Exige profundo conhecimento e experiência na aplicação de normas e regulamentos internacionais. Forte visão e experiência de design, engenharia, pesquisa, atendimento ao cliente, compliance e gerenciamento de produtos.

• Chief Accessibility
  Facebook
  California, USA

Principais atividades: Responsável pela visão, estratégia, execução da abordagem na criação de produtos inclusivos e acessíveis. Estabelecer visão compartilhada de acessibilidade em toda a empresa. Definir métricas que informem o sucesso da acessibilidade na empresa. Exige 5 anos atuando com acessibilidade digital.

• Product Manager Accessibility
  Alteryx
  Colorado, USA

Principais atividades: Conduzir a execução estratégica da iniciativa "cultura de acessibilidade". Responsável por criar roteiro estratégico e direcionar as partes interessadas que implementarão os elementos táticos. Criar e manter o VPAT. Criar conteúdo de suporte (blogs, vídeos, papers, sobre acessibilidade).Ponto focal para todos na empresa. Exige experiência com todos os processos relacionados a acessibilidade e a gerenciamento de produtos.

• Accessibility Programs Director
  Salesforce
  California, USA

Principais atividades: Gerenciar o recém inaugurado "Escritório de acessibilidade". Alguém estratégico e apaixonado por lançar programas globais de acessibilidade. Desenvolver e manter fortes relações com as partes interessadas e o comitê executivo de acessibilidade. Exige alguém que tenha desenvolvido programas de alto impacto do zero.

• Change Coordinator Accessibility
  BBC
  Manchester, UK

Principais atividades: Coordenar uma rede com mais de 200 (DUZENTOS!!!!!) Accessibility Champions focados no ciclo de vida do produto, cada um especializado e treinado em seu respectivo campo de atuação. Organizar e executar eventos de acessibilidade internos e externos, incluindo o GAAD. Experiência com projetos que envolvam mudanças nos negócios e profundo conhecimento nas terminologias, ferramentas e técnicas de acessibilidade.

• UX Research Accessibility
  Bluejeans
  California, USA

Principais atividades: Criar e manter um VPAT. Desenvolver testes com usuários, analisar descobertas e fornecer feedback. Necessário sólida experiência em pesquisas. Conhecimento em ferramentas de acessibilidade e tecnologia assistiva. Excelente comunicação com equipes de design e de produto.

• Digital Accessibility Manager
  Barclays
  Manchester, UK

Percebam como eles começam a descrição dessa vaga: "Nossa ambição é nos tornarmos a empresa FTSE mais acessível e inclusiva. Sua ambição deve ser mais do que apenas palavras, deve ser sobre como procuramos oferecer produtos e serviços de maneira inclusiva para todos os nossos clientes."

Principais atividades: Atuar como especialista do tema acessibilidade para as equipes que fazem parte da iniciativa de acessibilidade desde 2012. Governança, parceria, treinamento e fornecimento de ferramentas. Alinhamento entre equipes de design, negócios e tecnologia. Irá atuar como PM através de todo o ciclo de desenvolvimento dos produtos. Exige compreensão completa da acessibilidade e usabilidade para pessoas com uma ampla gama de interações. Compreender profundamente como as pessoas utilizam as mais diferentes tecnologias assistivas.

• Process Manager Digital Accessibility
  Capital One
  Virginia, USA

Claramente eles querem concorrer sobre quem descreve melhor uma vaga:
"A medida que o cenário digital continua evoluindo e se reinventando, nunca foi tão importante garantir que qualquer pessoa interessada em fazer negócios conosco possa ter sucesso." ❤

Principais atividades: Colaborar com as equipes ágeis de produtos sobre requisitos específicos de acessibilidade e o uso de ferramentas para obter acessibilidade no início do ciclo de vida dos produtos. Exige alguém que vai além da simples conformidade com as diretrizes de acessibilidade. Conhecimento profundo e paixão por garantir a acessibilidade, além de conhecimento em design inclusivo para proporcionar capacitação, inclusive de fornecedores.

Enfim, deu pra sacar o quanto precisamos evoluir na contratação de pessoas com foco em acessibilidade para que possamos garantir a excelência cada vez maior em produtos e serviços lançados aqui no Brasil, certo? A diferença de visão sobre o tema é gritante e perceptível.

Estou indo em diversas empresas para palestrar sobre o tema e consigo perceber uma evolução no cenário, mas ainda é algo muito restrito aos analistas. Gestores de negócios e produtos ainda passam longe de priorizar as atividades em suas sprints. C-levels ainda precisam de um apoio muito grande para que o assunto chegue da forma correta até eles. É tudo um processo. Literalmente, um trabalho de formiguinha. Quem enxergar essa necessidade primeiro, sai na frente dos demais…

Aqui vale uma observação… Gestores, PM's e PO's queridos, deem mais atenção para a acessibilidade e garantam a excelência do seu produto ou serviço para todos. Acreditem, isso não será em vão. Vocês serão muito bem recompensados por isso. Essa é a oportunidade que você esperava pra se diferenciar do "amiguinho", mostre pra ele que você não é apenas "mais um"… Chame o designer ou o dev que está mais focado com o tema acessibilidade na sua equipe pra entender melhor o que fazer (e se não tiver, incentive isso na equipe)… não conhecer nada sobre o tema não é nenhum demérito, saber que o assunto é importante, mas mesmo assim não tomar nenhuma ação a respeito, sim.

Onde buscar vagas com foco em acessibilidade?

Hoje (na data de publicação deste artigo), não adianta buscar vagas específicas nos principais sites de vagas no Brasil, ainda não há vagas com esse foco (e nem filtros para isso). Você terá que garimpar atividades relacionadas a acessibilidade entre as demais existentes nas descrições.

As pessoas que atuam nas empresas aqui no Brasil foram contratadas inicialmente com outra função e a partir daí algumas empresas alocaram a pessoa em uma função voltada para a acessibilidade (quando isso acontece). Espero que este artigo ajude a mudar esse panorama no Brasil. :)

Lá fora, você consegue encontrar facilmente as vagas que listei aqui no artigo nesses sites aqui:

• a11yjobs.com digital accessibility jobs.
• Accessibility Jobs, Employment | Indeed.com

Acredito que diante disso tudo, diversas dúvidas ou alguns esclarecimentos aconteceram na cabeça de quem chegou até aqui. Fique a vontade para comentar e também me falar como é a realidade da sua empresa. Você atua exclusivamente com acessibilidade? Como foi o processo? Migrou de área e hoje você foca nisso ou foi contratado já pra desempenhar alguma função focada nisso? Conte-me mais…

Tudo isso tem a ver com o desenvolvimento de uma Cultura de Acessibilidade, mas isso será papo para um próximo texto. :)

Está procurando por algum curso de acessibilidade?

Quer aprender como efetuar o planejamento de acessibilidade na sua empresa? Como aplicar e envolver todos na equipe? Como especificar e gerar documentações? Então vem pro curso que realizo em conjunto com a Talita Pagani na Mergo. Verifique as turmas disponíveis e o programa completo no site e se tiver dúvidas, comente aqui.

Me chamo Marcelo Sales, sou designer focado 100% em acessibilidade. Estudo o tema desde 2012, desenvolvo ferramentas de apoio e além aqui do Medium, você me encontra também no Twitter, no Instagram e no LinkedIn! ;)

Precisamos de profissionais focados em acessibilidade dentro das empresas was originally published in Mergo on Medium, where people are continuing the conversation by highlighting and responding to this story.

Mas montanha-russa não é tudo igual? Tem looping, carrinho, subida, descida…

…a resposta simples é SIM! Todas possuem essas mesmas características, porém se você já foi em algumas já percebeu que umas são mais suaves, outras mais intensas, algumas possuem diversos loopings e cada vez mais elas vão ficando mais complexas. Ou seja, é um mercado como qualquer outro. No Brasil, por uma série de questões que tratarei em outros artigos nunca houve uma cultura de parques de diversões como acontece em outros países, mas lá fora há uma briga intensa entre parques por quebras de recordes (a mais alta, a mais rápida a que tem maior número de "loopings", etc) e isso gera uma indústria própria, onde cada fabricante possui suas respectivas patentes.

Quem é fã de montanhas-russas assim como eu sou, provavelmente já ouviu a seguinte frase:

A B&M é a Ferrari das Montanhas-Russas!

Qualquer fã que se preze tem o sonho de andar em uma B&M, que nunca teve seus trilhos montados no Brasil… O site ParkPlanet tem um artigo muito bacana (em holandês) falando como os fãs literalmente piraram quando a primeira B&M foi construída na Holanda em 2014.

B&M é o "nome fofo" para Bolliger & Mabillard, uma empresa suíça aberta por dois engenheiros que trabalhavam para outras fabricantes e decidiram criar o seu próprio negócio em 1988. É uma das que mais possuem patentes registradas para alguns elementos muito conhecidos e exclusivos de seus trajetos. Por exemplo, eles foram os criadores do modelo de montanha-russa invertida (aquela em que você vai com os pés soltos e os trilhos estão acima de você parecendo um teleférico) e possuem a sua patente datada de 1992.

Devido a isso, antes de falar das inversões existentes, acho válido comentar o nome básico de todos os elementos de uma montanha-russa. Pra quem costuma jogar RollerCoaster Tycoon já deve estar familiarizado com esses termos e elementos, mas pra que não joga (mas deveria) fica aqui um mini-glossário… :)

Elementos básicos que formam uma montanha-russa

Station (Estação): É o ponto de partida onde as pessoas entram e descem dos trens. São construídos de diversos materiais e formas e costumam ser tematizados de acordo com o tema da MR (a partir de agora, qualquer menção a Montanha-Russa, será tratada por MR);

Train (Trem ou Carrinho, que eu acho muito mais bacana): É o carrinho propriamente dito. Ele pode ter diversas formas. Individual, coletivo, enfileirado, lado-a-lado, etc.;

Lift (Subida): O único elemento "motorizado" no percurso de uma MR. Serve basicamente para fazer com que o carrinho suba ao ponto mais alto para a partir daí ser levado pela gravidade. Pode ser de diversas formas: Motorizado com correntes, Indução linear (parecido com "trens-bala", onde a subida se dá por indução magnética), Lançamento com pneus, entre outros;

Drop (Descida): Montanha-russa sem descida não é montanha-russa, certo? Esse é o elemento que é o que faz a fama de uma MR;

Brake Run (Freios): Como é basicamente a gravidade que leva o carrinho é natural dizer que a velocidade pode ser demais em alguns pontos, daí a existência de "desaceleradores" no decorrer da pista e claro, no ponto final para frear totalmente;

Airtime: Não há uma tradução direta para este elemento que é conhecido por "airtime" em qualquer lugar. São aqueles pontos elevados no trajeto que fazem com que você sinta o famoso frio na barriga causando a sensação de ausência de peso.

Os elementos citados acima são os mais básicos em uma montanha-russa, existem muitos outros, mas aí começamos a entrar em detalhes que não faz sentido pra esse momento.

Mas agora vamos falar do tema principal deste artigo que são os tipos diferentes de inversões em uma MR.

Tipos de inversões em Montanhas-Russas

Existem muitos tipos de inversões diferentes e é possível que nem todos eu consiga listar aqui (se quiser complementar, fique a vontade para incluir nos comentários), mas tentarei deixar os principais aqui (obs: as fotos abaixo possuem os devidos créditos em cada imagem, porém a edição das mesmas foi efetuada por mim, caso queira utilizar, fique a vontade, mas cite a origem).

Vertical Loop (Looping): É o velho "looping" que estamos acostumados. O primeiro modelo de inversão e mais básico de todos. Há dois tipos, os circulares e os elípticos, sendo que a intensidade dos circulares costuma ser maior e atualmente são pouco utilizados.

Inclined Loop (Looping inclinado): É uma variação do looping básico, porém com uma inclinação de cerca de 45º (que pode variar).

Non-inverting Loop: É um looping que não te deixa de cabeça pra baixo. Você inicia o movimento, mas daí rola uma inversão na pista fazendo com que você não fique de cabeça pra baixo na pista e descendo logo em seguida.

Diving Loop: Você tem a impressão de que está subindo, mas de repente há uma virada de cabeça para baixo e você retorna na mesma direção de onde veio, completando assim uma looping em formato de mergulho.

Immelman: É exatamente o oposto do Diving Loop onde você começa a subida como se fosse fazer um looping, mas de repente ocorre uma inversão na pista em 180º fazendo com que volte para o mesmo ponto de onde vinha no sentido oposto. O nome tem origem em uma manobra na aviação criada na 1ª Guerra Mundial.

Cobra Roll: Esse é bem conhecido dos brasileiros, mais precisamente dos paulistas, pois era o elemento principal da Boomerang no Playcenter. É composto por uma série de elementos (dois meios-vertical loops e 2 meios corkscrews) gerando uma intensidade enorme. Tem esse nome, pois se olhar diretamente para a dupla inversão perceberá uma cabeça de cobra em sua formação.

Corkscrew: É literalmente um saca-rolhas. Pode ser constituído por uma, duas ou mais inversões seguidas, ocasionando leve desnorteamento.

HeartLine Roll: É uma espiral em 360º que ocorre no mesmo eito da pista. Pode ser apenas uma rotação ou uma sequencia.

Batwing: É quase um Cobra Roll invertido em um formato de coração, similar a um bumerangue o que dá origem ao seu nome.

Norwegian Loop: Esse tipo de inversão é tão complexo de descrever que achei melhor ilustrar com um vídeo ao invés de ser com uma imagem. Basicamente ele é composto basicamente pela junção de um Immelman com um Diving Loop. Veja o vídeo a seguir para (talvez) entender melhor… :)

Pretzel Loop: É tão complicado como o Norwegian Loop e o seu formato lembra exatamente um pretzel (daqueles que comemos em shoppings). Uma foto também não explicaria e por isso achei melhor incluir o vídeo a seguir. Esse tipo de inversão é utilizado apenas em montanhas-russas do tipo voadoras (flying coaster), aquelas em que vamos deitado como se estivéssemos voando.

Além desses apresentados, há uma série de outros tipos de inversões e a lista vai aumentando cada vez mais, pois como dito no início do texto, há uma "guerra" entre as fabricantes para que sejam criados cada vez mais elementos complexos e dessa forma cative mais e mais pessoas a frequentarem determinados parques de diversões.

Em um próximo artigo, falarei sobre os tipos diferentes de montanhas-russas… :)

Até a próxima!

Me chamo Marcelo Sales, sou designer apaixonado por Acessibilidade, Psicologia e UX (User Experience). Tenho um projeto chamado Todos por Acessibilidade (http://acessibilida.de) e nas horas vagas gosto de falar sobre montanhas-russas… ;)

Montanhas-russas e suas inversões! was originally published in Aventura Landia on Medium, where people are continuing the conversation by highlighting and responding to this story.

Um guia prático sobre as apresentações que trarão a acessibilidade como tema no Interaction Latin America 2018.

Ano passado após o #ISAFLORIPA17, escrevi um artigo com as percepções que tive sobre o evento e é claro, foquei nas apresentações que rolaram sobre acessibilidade. E neste ano? O que podemos esperar sobre as apresentações que tratam de acessibilidade no #ILARIO18? Vem comigo neste guia prático pra se organizar e não perder nada sobre o tema!

Community Day (Quinta, 15 de Novembro)

Teremos 4 palcos com apresentações simultâneas. Este formato agrada uns e desagrada outros, mas é bem democrático e possibilita a apresentação de mais pessoas e temas durante o evento. Escolha seu palco, confira o horário e corra pra não perder…

• OBS: Não há descrições adicionais, pois elas ainda não foram disponibilizadas no site do ILA.
• OBS 2: Nem todos os palestrantes estão marcados abaixo (ou por eu desconhecer o medium deles ou por realmente não estarem na plataforma — se conhecerem alguém não marcado, me informem nos comentários para que eu atualize).

Palco 1

• 10:40 — Un acercamiento teórico sobre la problemática del diseño de aplicaciones móviles para una población urbana por Griselda Alejandra Molina
• 14:45 — Sistema de busca em Libras por Ricardo Couto e Elias Fernandes
• 15:30 — Falaê: um aplicativo AAC desenvolvido em “40 Days of Doing Good” por Daniela Szabluk, Ana von Frankenberg Berger e Manuela Ferreira De Oliveira
• 15:50 — Design para ser visto: De um projeto no laboratório para um produto na prateleira. Como a fusão entre marketing, design e tecnologia levou o Conta-Gotas Sonoro da ciência ao mercado por Diogo Carvalho
• 16:35 — Acessibilidade no iFood: da pesquisa à criação de cultura por Izabela de Fátima e Juliana Salgado
• 16:55 — Acessibilidade digital: elaboração de artefato para representação interativa de conhecimento inclusivo por Renan Binda, Cecília Machado Henriques e Vânia Ulbricht

Palco 2

• 19:05 — Métodos e técnicas de estudos em wayfinding de pessoas com deficiência em uma etapa pré-design por Raphael Freitas Souza, Solange Coutinho e Laura Bezerra Martins

Palco 3

• 11:45 — Interação em dispositivos touchscreen para pessoas com paralisia cerebral: possibilidades de inclusão digital por Carolina Tavares e Murilo Scoz
• 14:20 — Uber Lite: a Uber para todo o mundo, em qualquer lugar por Srikanth Jalasutram e Laura Garcia Barrio
• 19:05 — O smartphone e o idoso conectado: relações entre heurísticas de usabilidade e recomendações de design da informação por Marcos Souza Filho, Solange Coutinho e Fábio Campos
• 19:30 — Smartphones acessíveis para pessoas com deficiência visual, idosos ou com baixo letramento por Claudinei Martins, Suelen Silva, Fabiani Souza, Alfredo Colito e Ricardo Hiramatsu

PS: Não haverá programação de acessibilidade para o palco 4.

Quer saber quais serão as outras apresentações? Veja aqui a programação completa para o Community Day.

Palestras principais (Sexta e Sábado, 16 e 17/11)

A única apresentação tida como principal, cujo tema tem a ver com acessibilidade, é a palestra de encerramento do evento no sábado, do Rama Gheerawo que é diretor da The Helen Hamlyn Centre for Design e o tema da palestra é Design to Make a Difference: inclusive design and interactions, que promete mostrar como o design pode realmente mudar o mundo para melhor ao se utilizar suas ferramentas e possibilidades criativas e interativas para a composição de projetos sociais, inclusivos e verdadeiramente centrados nos usuários.

Pode ser que sejamos surpreendidos com pequenas pinceladas sobre o tema nas outras apresentações, mas essa, sem dúvida alguma, já é a minha preferida antes mesmo do evento começar.

Quer saber a programação completa das palestras principais?
Vai lá no site do ILA: sexta-feira e sábado.

Dicas para quem vai ao RJ e não conhece o lugar

Quem acompanha o medium do Interaction Latin America - 2018 | Rio de Janeiro já viu alguns posts com dicas, se ainda não viu, pegue aqui coisas como "Fique carioca sem ter que falar chiado" ou então sobre pontos turísticos como o Palácio do Catete ou a Praça Mauá.

Particularmente falando, estou louco pra conhecer o chopp do Pavão Azul (boteco clássico carioca) que o Horacio Soares vive fazendo propaganda, então tô curioso! :)

E se você leu até aqui…

Pra você que realmente estava interessado e leu até aqui, fica a dica adicional. Estarei em alguns momentos no stand do Itaú (pra quem não sabe, o local onde eu trabalho) batendo um papo de acessibilidade. Se me encontrar por lá ou no evento em qualquer lugar, pode me abordar sobre o tema, fique (realmente) a vontade… quem me conhece sabe que curto falar sobre isso.

E a dica final é… se chegar em mim perguntando "Oi Sales… cadê o meu Toolkit de Acessibilidade?" eu vou anotar seu nome e te dar um número. Na hora do happy hour de encerramento do ILA, irei sortear 2 toolkits impressos via random.org e divulgar via story no meu Instagram. É só chegar e me chamar… :)

Ainda não conhece o Toolkit de Acessibilidade? Dê uma olhada neste artigo.

Curtam o evento, pois será uma experiência épica e única! Até lá! ;)

O que esperar sobre acessibilidade no #ILARIO18? was originally published in Mergo on Medium, where people are continuing the conversation by highlighting and responding to this story.

Tenho certeza de que você já ouviu falar dessa tal Acessibilidade. Se você trabalha com projetos digitais, muito provavelmente já foi solicitado a projetar sites ou apps acessíveis, mas daí vem a dúvida: “O que preciso fazer? Como devo fazer?”. E em seguida vem aquele processo padrão de pesquisa… após alguns links você se depara com uma tal de WCAG.

“Dablioque?”

Você encontra o WCAG — ou Web Content Accessibility Guidelines — e pensa “WOW!!! Tem tudo aqui! Tudo detalhadinho, comentado… WOOWWW! Tem exemplos também… sensacional!”. 10 minutos depois e “Nossa… o que isso quer dizer meu deus?”, “Quanto texto! Precisa mesmo?”, “Nossa… isso é coisa de acessibilidade?”, “Mas isso é coisa da TI!”, “[espaço reservado para a sua frase de espanto]”.

Independentemente do processo que o tenha levado a conhecer a WCAG, é fato que a quantidade de textos, ou pior, a quantidade de textos em formato acadêmico (duh!) é realmente espantosa. Por outro lado, não há como negar que o assunto Acessibilidade é muito bem documentado com diversos exemplos, casos de sucesso, erros e boas explicações. E a quantidade de pessoas falando cada vez mais sobre o assunto só aumenta.

Assumindo que você já tenha tido acesso aos textos da WCAG, volto a perguntar: dos 61 critérios de sucesso existentes, você saberia dizer facilmente quais deles se encaixam em um escopo de UX? (update em 06/2020: quando o artigo foi escrito eram 61, atualmente são 78)

Poderíamos formatar a pergunta mudando o tipo de profissional: “Você que é responsável por produzir conteúdo pro seu site, sabe me dizer quais diretrizes se enquadram em seu escopo de trabalho?”, “E você designer? Sabe dizer quais critérios precisa atender em um escopo de design?”.

Ok, você até conseguiu identificar alguns dos critérios que seriam de sua responsabilidade, mas e o seu real significado? Conseguiu entender? Está claro o suficiente? Essas questões nos levam a outra pergunta.

Por que criar um Toolkit?

Eu estudo Acessibilidade há cerca de 5 anos, e por todos os projetos que passei e pessoas com quem falei, a grande questão sempre foi entender a fundo os critérios de sucesso, e como poderíamos atendê-los corretamente sem que houvessem interpretações incorretas.

Qualquer pessoa que inicia os estudos das diretrizes de Acessibilidade concorda que o conteúdo é denso, possui tom acadêmico, e mesmo tendo uma estrutura bem definida se torna maçante e complexo pra qualquer um que queira se aprofundar mais em seu conhecimento.

Isso contribui especialmente para duas coisas:

• o não entendimento das diretrizes;
• (e consequentemente) a não adoção completa das diretrizes.

A ideia de se criar um toolkit começou a nascer a partir do momento que eu utilizei um modelo primário deste material em alguns workshops que realizei para disseminação do conhecimento da Acessibilidade.

Em um exercício simples de card sorting, percebi (de uma forma que não havia percebido ainda em nenhum outro momento) a dificuldade clara de UXers, Designers, Desenvolvedores, PO’s e Editores de conteúdo em entender alguns dos critérios. E ficou mais claro ainda que o grande problema era justamente a forma como alguns dos critérios são escritos (acadêmicos do meu coração, amo todos vocês, mas vamos facilitar esse linguajar rebuscado aí, pô!).

Levando em consideração que existem toolkits em modelos de cartas para as mais diversas atividades, mas até hoje nenhum modelo voltado para acessibilidade havia sido criado ainda, não foi difícil ligar os pontos e imaginar um toolkit de acessibilidade como ferramenta facilitadora do entendimento da WCAG.

Em tempo: Aqui vale a observação a respeito de um artigo recente da Talita Pagani no site Movimento Web Para Todos onde ela cita alguns desafios propostos para a área de Interação Humano-Computador (IHC) e a pouca exploração pela comunidade acadêmica de IHC e UX sobre o tema Acessibilidade e Inclusão Digital. Em um dos desafios há o seguinte questionamento:

Existe, de fato, uma dificuldade no entendimento das recomendações de Acessibilidade, mesmo com a adaptação ao contexto brasileiro?

Confesso que não me aprofundei em pesquisas sobre o tema ainda, mas como citei anteriormente e em experiências próprias, eu diria que a resposta a essa pergunta é um categórico SIM.

Bacana, mas na prática o que eu posso fazer com este toolkit?

Este material pode ser usado de diferentes formas. A aplicação inicial foi pensada para a utilização em exercícios de card sorting, onde as pessoas envolvidas em projetos digitais poderiam facilmente identificar gaps e atividades que precisariam contemplar durante o desenvolvimento dos projetos.

Mas na prática um toolkit neste formato (cards) pode ser utilizado como fonte rápida de consulta de diretrizes, disseminação de conhecimento, facilitador de discussões, identificador de funcionalidades ou até mesmo como um checklist. Manusear algo físico ao invés de apenas consultar digitalmente estimula a criatividade em qualquer processo de desenvolvimento de produto ou serviço.

O melhor feedback que pude receber até agora foi ter feito as pessoas que manusearam o toolkit perceberem que os critérios de sucesso e diretrizes não estavam relacionados diretamente a algo específico para deficientes, mas sim heurísticas básicas de desenvolvimento de qualquer projeto digital.

Nunca é demais lembrar que ACESSIBILIDADE É PARA TODOS! ;)

Processo de criação e desenvolvimento

Com o MVP sendo utilizado nos workshops e a sua aplicação sendo bem aceita, o próximo passo foi definir o modelo final e mais completo do toolkit. Essa etapa foi relativamente simples, uma vez que os elementos essenciais para apresentação das informações já existiam (princípios, recomendações, critérios de sucesso, níveis de conformidade, etc).

A etapa seguinte foi a mais complicada. Uma vez definido o formato, era necessário facilitar o entendimento da informação, afinal algumas diretrizes possuem diversas linhas explicativas e em muitos casos, uma linguagem não tão simples de compreender.

Neste momento o objetivo foi tornar as explicações das diretrizes o mais simples possível enquanto a essência do conteúdo original era mantida. A ideia aqui é que qualquer pessoa "bata o olho" no cartão e já consiga identificar o que precisa ser feito.

Os exemplos demonstrados na imagem acima foram replicados para todos os 61 critérios de sucesso (e você pode conferir todos eles neste Guia Rápido). Alguns textos passaram por mais de 6 versões até serem considerados simples o suficiente para que qualquer pessoa pudesse entender. Em outros, não foi preciso fazer uma grande simplificação e o texto ficou bem parecido com o original mesmo. Mas isso não significa que os textos existente nos cartões não possam ser modificados (aguenta aí, que já te explico como você pode contribuir com esse material).

Por fim, faltava produzir um boneco do toolkit para testar a aplicabilidade do modelo final na prática. E as fotos abaixo mostram como foi esse processo…

Todo o material apresentado até agora foi produzido de forma manual. Impresso em impressora jato de tinta, utilizando estilete e régua para recortar, cola em bastão, muita paciência, reimpressões, ajustes, dedos grudando, mesa cortada e algumas horas de dedicação (chuto por volta de 90 horas desde a conceituação até a finalização do boneco versão final).

Algumas considerações sobre design inclusivo

Desde os primeiros esboços, minha intenção era ter um material de fato fácil de usar e também simples de compreender pelo máximo possível de usuários independentemente de suas habilidades. Como em qualquer projeto é utopia achar que todas as situações serão atendidas, mas com o uso de boas práticas é possível lidar com boa parte delas.

Onde foi possível aplicar princípios de design inclusivo eu apliquei, mas ainda há espaço para melhorar e como eu disse você poderá participar deste processo. ☺

A começar pela tipografia utilizada. A fonte escolhida dentre alguns testes que efetuei foi a Tiresias Infofont, que originalmente é destinada para a impressão de grandes formatos e placas informativas, mas em testes se mostrou com boa legibilidade em pequenos formatos também. Trata-se de uma fonte produzida por John Gill e foi criada especialmente a pedido do RNIB (Royal National Institute of Blind People). Ela possui traços bem definidos entre os caracteres, um bom espaçamento entre eles (kerning), diferenças claras entre as letras e acentos (como optei pela distribuição original em português, esse item é fundamental).

Além disso, optei por dividir os cartões e seus princípios em cores diferentes. E levando em consideração um dos próprios critérios de sucesso, o 1.4.1 que trata de utilização de cores, “não devemos ter a cor como única maneira de distinção de elementos”. Sendo assim, apliquei padrões específicos além das cores como demonstrado na imagem abaixo.

Uma outra questão foi o fato de se utilizar um link direcionando para a diretriz completa, caso o usuário continuasse não entendendo a diretriz após ler a descrição nos cartões. Recebendo o feedback do pessoal que viu os cards antes de eu lançar, vários indicaram a aplicação de um QRCode em cada uma das cartas. Deu um trabalhão, mas está aí… :)

Concluindo

Essa ferramenta está longe de substituir a leitura e o entendimento de todas as diretrizes WCAG de forma aprofundada, mas levando em consideração que a maioria das pessoas dificilmente irão ler todo o seu conteúdo denso e um dos principais desafios que a comunidade IHC e UX enfrenta é facilitar o entendimento dessas informações, talvez este toolkit seja uma forma muito mais simples para se promover esse conhecimento.

Este é um trabalho feito com carinho por alguém que sofreu tanto quanto vocês para entender as diretrizes e começar a fazer real uso delas. ;)

Mas não quero guardar o osso só pra mim e por isso mesmo a distribuição e manipulação é livre.

Contribua com o projeto e com a comunidade open source!

Você me convenceu! Quero um, como faz?

A caixinha pronta e impressa deve demorar uns dias pra sair, pois ainda estou conversando com possíveis parceiros para impressão e distribuição. ;)

No entanto, este material está disponível para download gratuitamente!

Sim, o material digital é livre para uso. Minha intenção com isso é contribuir com qualquer um que queira utilizar os cartões para disseminar o entendimento das diretrizes WCAG ou reforçar os seus estudos de uma forma mais acessível (de verdade) e simplificada.

Você está livre para imprimir, utilizar, traduzir, editar, customizar, redistribuir e fazer o que quiser com o material, desde que cite a fonte e o redistribua utilizando a mesma licença de uso (Creative Commons — Atribuição-CompartilhaIgual 4.0 Internacional).

Os arquivos estão em formato PDF editável e podem ser modificados através do Adobe Illustrator. Você pode fazer o download apenas do PDF com os cartões e/ou também da caixinha com a faca de corte já definida.

Se você nunca contribuiu com projetos Open Source via GitHub e não tem a mínima ideia de como fazer isso, leia esses artigos (Contribuindo com projetos Open Source [Parte 1] e [Parte 2]) do Ivan Santos.

Originalmente o material está disponibilizado em português brasileiro, pois é a língua nativa deste autor que vos fala facilitando bastante o trabalho de resumo das diretrizes. No entanto, a tradução do material para qualquer idioma é livre. Por favor, contribua (no GitHub há algumas instruções)!

Espero que você possa fazer ótimo uso deste toolkit e que ele facilite o seu entendimento sobre acessibilidade. Se possível, comente aqui no artigo sobre a sua experiência ao utilizar o material.

Acesse também o hotsite do projeto e assista ao vídeo explicativo:

Acessibilidade Toolkit

Me chamo Marcelo Sales, sou designer, apaixonado por Acessibilidade, Psicologia, UX e Guioza (não necessariamente nessa ordem). Criador do projeto http://acessibilida.de

Acessibilidade Toolkit: Entendendo de uma vez por todas a WCAG was originally published in Mergo on Medium, where people are continuing the conversation by highlighting and responding to this story.

Calma, ninguém morreu durante o ISA Floripa 2017 (não que eu saiba), mas o título deste artigo faz alusão a duas das palestras que achei mais ”fodas” no evento. Porém antes de falar das palestras, deixa eu comentar um pouco do clima e da experiência em estar no ISA…

Meu primeiro ISA

Esse foi o meu primeiro ISA, e sabe quando vamos em um lugar pela primeira vez e ficamos com aquele pensamento de “como é que eu nunca vim aqui antes?”. Pois é, eu tive esse sentimento desde que cheguei lá no primeiro dia.

O clima, as pessoas, o lugar, a organização, os voluntários, tudo era convidativo a uma experiência inesquecível. “Pô, mas não teve nada de ruim?”… Sim, teve, mas sinceramente? O porte do evento era tão grande e o clima estava tão bacana que os poucos problemas que passei (tradução simultânea em alguns momentos, por exemplo) passaram batido na média final. “Cara, mas e as filas dos food trucks?”. Ouvi diversos comentários assim e vamos combinar… qualquer lugar no mundo que envolva food trucks e mais de 1000 pessoas juntas, é passível de filas, certo? :)

Ouvi comentários do pessoal “velho de ISA” que a estrutura desse ano foi surreal. Muito maior que a de anos anteriores. Como não estive nos anteriores, não duvidei nem por um instante. Realmente a estrutura impressionou.

Vamos ao que interessa… palestras!

Foram 3 dias de evento, sendo que no primeiro dia ocorreram palestras da comunidade divididas em ilhas específicas (humanas, tecnologia, comunicação e negócios) que duravam 10, 20 ou 30 minutos de acordo com o tema. Havia também os workshops adicionais ao evento, mas vou dar foco a tudo que ocorreu no pavilhão principal.

Nesse dia, as palestras eram “silenciosas”, todas as ilhas rolavam ao mesmo tempo e daí a galera ficava o tempo todo com fones de ouvido. Bastava você focar o canal na ilha que estava assistindo e pronto… foco total.

Teve gente que não curtiu a dinâmica, mas mais uma vez devo dizer que achei “foda” também.

E dou duas razões pra esse sentimento:

• Primeiro, facilidade em saber o que rolava nas outras ilhas. Era muita informação ao mesmo tempo, sendo assim, se a palestra que estava assistindo não era bacana, bastava trocar de canal e se o que estava ouvindo agradasse, andar até o local da outra;
• Segundo, foco total na apresentação. O fato de você estar com fones de ouvido, fazia com que você prestasse atenção total ao palestrante, sem ouvir conversas paralelas e mimimi ao seu lado.

Se eu fosse falar de todas as apresentações deste primeiro dia, teria de digitar um livro por aqui, por isso vou me concentrar apenas nas apresentações sobre o tema que mais me cativa e me motiva atualmente que é a acessibilidade. Vi muita coisa interessante, incluindo as 3 únicas apresentações que tiveram com o tema acessibilidade, mas achei muito pouco se levarmos em consideração que foram mais de 160 apresentações neste dia.

Primeiro o Gabriel Morais e a Marina Domingues mandaram muito bem com a provocação pra galera de negócios questionando “Por que deixarmos de ser amadores para um público que espera mais de nós”?

Um pouco mais tarde a Raquel Cordeiro apresentou a palestra que já havia apresentado no último #uxconfbr, “Acessibilidade na Internet das Coisas”.

E na sequencia o Tiago Barros e Anaís Almeida apresentaram um “Sistema de jogo inclusivo com foco em deficiência visual”.

Surpresa boa e inesperada

Entre o intervalo de uma apresentação e outra, estava passeando pelo corredor e encontrei alguns stands, sendo um deles o do iFood, parei pra assistir a apresentação e de repente alguém do stand me entrega um adesivo dizendo que rolaria uma apresentação sobre a acessibilidade no aplicativo do iFood na sequencia. Na hora, olhei pro adesivo, pro cara, abri aquele sorriso e pensei… “ok, vamos aguardar!” :)

A Juliana Salgado, que é responsável pela acessibilidade no iFood, apresentou o antes e depois de começarem a desenvolver o aplicativo de forma inclusiva. Apresentação rápida e direta demonstrando como facilitar a vida dos usuários (inclusive não deficientes) ao se aplicar corretamente recursos de acessibilidade. Que tenhamos mais iniciativas como essa nas próximas edições do ISA.

Tudo lindo, mas e as palestras principais?

Foram mais 2 dias intensos com palestras começando as 10h e terminando quase as 20h. Foi intenso e cativante na mesma proporção. Exaustivo a ponto de eu achar que a cerveja poderia ser por “conta da casa” nas próximas edições, mas definitivamente enriquecedor e instrutivo. É aquele cansaço que dá gosto, sabe?

E assim como as apresentações da comunidade, os temas das palestras principais também foram baseados nas ilhas de conhecimento.

Em HUMANAS, tivemos as palestras:

• “Tragic Design” da Cynthia Savard (Shopify) que na minha opinião foi simplesmente a melhor de todas apresentadas no evento, ela é co-autora do livro que dá nome a palestra e falou do quanto um design ruim pode impactar negativamente o seu produto e em alguns casos até mesmo matar (daí o título do artigo);
• e também a “Design Leadership” do Anderson Gomes (Youse) demonstrando o quanto o UX Designer se tornou importante dentro das empresas.

Em NEGÓCIOS, vimos:

• a aula de cultura empresarial “Work Culture Feijoada: 9 elements of innovation” do Andrew Kaufteil (Cooper Design), pra se fazer uma boa feijoada são necessários alguns ingredientes, a analogia é transformar esses ingredientes em especialidades diferentes e no fim tudo fica bem “azeitado” em sua empresa;
• na minha opinião, a segunda melhor apresentação do evento inteiro e que chutou bundas ao demonstrar o quanto a China pode ser um mercado muito melhor explorado e ir muito além do Vale do Silício foi “How is designing for China market differente from the Western Tech ecosystem and what you can learn from it?” da Elaine Ann (Kaizor Innovation), sem contar que não devemos mesmo seguir uma única cultura, há muito mais no mundo do que o “sonho de vida americano”;
• também rolou “The designer as Behavior Architect. How to maximize the use of behavioral economics in the design process” do Luis Arnal (Insitum) falando sobre economia comportamental e o quanto somos influenciáveis socialmente e emocionalmente;
• na “User Experience Vs Customer Experience” do Rob Nero (Spotify) descobrimos que o SAC é a linha de frente com seus usuários, converse com os atendentes, procure receber relatórios dos colaboradores do SAC de sua empresa, é lá que as boas ideias podem estar.

Em COMUNICAÇÃO:

• a melhor palestra que eu já assisti após o almoço… enérgica, com exemplos cirurgicamente pincelados, dados relevantes e com uma puta presença de palco “Innovation: a sneak peak into the future” do Marcos Piangers (RBS);
• “Designer personal and ethical decisions for career development” da Mariana Salgado (Finnish Immigration Dept.) mostrou o quanto podemos enriquecer nosso trabalho ao trabalhar também com imigrantes, pense culturas diferentes utilizando um serviço ou produto que não foi originalmente pensado para eles, inclusão social nua e crua.

E por fim, em TECNOLOGIA:

• uma das apresentações que eu mais esperava não decepcionou “Accessibility and universal design: developing software that is really for everyone” do Lucas Radaelli (Google), nada de slides aqui, o que acredito eu, só fez aumentar o foco da plateia no apresentador. Ele comentou coisas que deveríamos saber como “jamais resolver aplicar acessibilidade no fim do projeto”, “desenvolver produtos exclusivos não é bom, as coisas precisam funcionar para todos”, “ordem de leitura de sites e aplicativos precisa ser linear, mas normalmente há uma preocupação apenas com o visual” e “testar sites e aplicativos com leitores de tela é fundamental”. Adquirir uma cultura de acessibilidade dentro da empresa é simples, primeiro temos de saber que não é razoável achar que TODOS saberão falar sobre acessibilidade dentro da empresa, logo precisamos que algum superior/diretor o faça e também que haja ao menos 1 interessado no assunto que normalmente irá disseminar para os demais, mas os demais também precisam demonstrar interesse em aprender, perguntar “como faço esse botão acessível?” não deveria ser a pergunta a se fazer;
• “Nudges: Influencing User Behavior” de Russel Parrish (IBM) mostrou que grandes poderes trazem grandes responsabilidades, ou o quanto somos capazes de influenciar comportamentos;
• “Empathy machines: an introduction to Adaptive UX” do Belmer Negrillo (Facebook) trouxe demonstrações que podemos ter com a adaptação das máquinas e a evolução de seu aprendizado;
• “Everything is about to change: Software as Material” do Greg Petroff (Google Cloud) falando sobre como as empresas estão percebendo o valor do profissional de UX e como se preparar paras as mudanças que isso trará para o mundo e para as próprias empresas;
• “Emotional IoT: How to create connections with people” do Ricardo O’Nascimento (PopKalab) falando o quanto é importante manter a criar conexões com e entre pessoas;
• “Bring Interaction Design to Physical Spaces” do Steve Baty (Meld + IxDA) foi a apresentação de encerramento do segundo dia;
• e a apresentação que encerrou o ISA foi “Riding the wave of digital disruption by Design” de Janaki Kumar (SAP Labs), eu já gostei por que ela colocou todos de pé em uma dinâmica que no mínimo fez a galera pensar e “esticar as pernas” em seguida falou sobre o quão veloz algumas mudanças ocorrem no mundo e que nenhuma indústria/empresa está imune a essas mudanças. O quanto antes uma cultura de inovação for criada, mais simples será controlar essas mudanças.

Conclusão

Se você é designer e perdeu o ISA deste ano, vá aos próximos. Se programe. Junte dinheiro. Faça horas extras na empresa. Divida apartamento com amigos. Vá de caravana… só não deixe de ir.

A experiência vivida nesses 3 dias será inesquecível para o resto de sua vida e carreira. Faça conexões, faça networking, puxe os palestrantes pra um papo, puxe aquela galera que você só conhece virtualmente pra um papo. Ali tá todo mundo feliz. Tá todo mundo solícito. Todos estão alegres e com um propósito.

Apenas vá… :)

E o que vem por aí?

Bom, foi o meu primeiro e último ISA… aparentemente a conferência aumentará de tamanho e larga de mão o “south” pra ser tornar “latin” com o futuro ILA — Interaction Latin America 2018 que acontecerá no Rio (se preferir, penas #ilaRio18).

Me chamo Marcelo Sales, sou designer, apaixonado por Acessibilidade, Psicologia e UX. Recentemente criei o projeto http://acessibilida.de.

Emoções, tragédias, UX, CX, Acessibilidade e o que mais rolou no #ISAFloripa17 was originally published in Mergo on Medium, where people are continuing the conversation by highlighting and responding to this story.

É fato, cedo ou tarde você irá receber (ou já recebeu) um link para participar de uma pesquisa. Pode ser um pedido pra avaliar um site ou uma nova funcionalidade de um aplicativo, quem sabe até uma opinião sobre um evento que tenha participado ou até mesmo um pedido de um amigo "sumido" que só te procurou pra pedir “aquela ajuda com uma pesquisa”.

Ou simplesmente, você pode ser a pessoa que está desenvolvendo a pesquisa e logo mais irá enviar aos seus "amigos distantes"... E aí, eu te faço a pergunta: Quando você prepara uma pesquisa você se preocupa em deixá-la simples, assertiva e acessível?

Não estou falando aqui apenas da acessibilidade natural através da navegação por teclado ou voz, felizmente as principais ferramentas online para pesquisa já adaptaram seus recursos para uma correta acessibilidade natural, mas este artigo diz respeito também a organização do conteúdo e clareza na informação.

Em uma pesquisa realizada em 2016, a ferramenta Testr idealizada pela Elisa Volpato, perguntou quais técnicas eram mais utilizadas em testes de usabilidade e a opção "questionários online" foi a terceira mais votada.

Vamos falar de boas práticas!

Técnicas de melhor codificação são essenciais, porém acessibilidade se trata de conteúdo, portanto, além da parte técnica (que neste caso normalmente é resolvida pela própria ferramenta utilizada), há que se focar em boas práticas na construção de sua pesquisa.

"Embora nossas pesquisas sejam tecnicamente acessíveis, você pode ajudar ainda mais tornando-as mais fáceis de usar com um leitor de telas e outras tecnologias assistivas" — Survey Monkey

Iniciando a sua pesquisa

É bem comum recebermos pesquisas que só tem título (quando tem) e nenhuma ou bem pouca explicação sobre o que o usuário irá encontrar nas próximas perguntas. Portanto, ao iniciar a sua pesquisa:

• Informe claramente sobre do que se trata a pesquisa. Além do título, um sub-título explicativo de 2 linhas é suficiente na maioria dos casos;
• Informe quantas perguntas há na pesquisa, dessa forma você diminui a ansiedade do usuário. Caso a ferramenta forneça um indicador de progresso, não deixe de usar;
• Caso a pesquisa seja direcionada a diferentes públicos, vale indicar o idioma da pesquisa;
• Caso a pesquisa seja longa, forneça uma alternativa para que o usuário salve e retorne depois. Diversas ferramentas possuem esse recurso.

Língua, linguagem e tom de voz

• Use linguagem clara e simples em suas perguntas e respostas (dica: feche os olhos e peça para alguém ler em voz alta pra você e veja se você mesmo compreende o que está sendo informado);
• Evite jargões e caso precise utilizar, explique-os na primeira vez que utilizá-los. O mesmo vale para abreviações e acrônimos;

Organização de conteúdo

• Faça agrupamentos e seções para organizar melhor o conteúdo;
• Faça uso adequado da estrutura de cabeçalhos que a ferramenta que escolher fornece. Título de nível 1 deve ser único e o principal em sua pesquisa. Demais títulos podem ser de níveis 2 ou 3, tente apenas manter uma estrutura hierárquica em sua pesquisa (usuários que utilizam leitores de tela costumam navegar principalmente através de títulos);
• Caso seja necessário uma explicação maior em uma pergunta (vulgo textão), considere separar esse conteúdo através de marcadores (bullets ou numerais);
• Utilize negrito e itálico para dar ênfase a determinadas partes do conteúdo, mas evite construir frases inteiras em negrito e itálico;
• JAMAIS E EM HIPÓTESE ALGUMA COMETA O ERRO DESTA LINHA, ou seja, nunca escreva apenas em maiúsculas;

Diagramação da pesquisa

• Deixe espaços adequados para as respostas. Quantas vezes você mesmo não xingou um formulário onde você precisava inserir uma resposta maior, mas não havia espaço suficiente? (por exemplo: nem todos possuem um nome pequeno como o seu);
• Seja lógico em sua organização. Essa é fundamental para pesquisas longas, deixe claro a quem se destina a pesquisa logo no início, não vá dizer que a pesquisa é destinada ao público XYZ após o usuário já ter iniciado e preenchido algumas questões;
• Seja consistente na diagramação. Tente manter uma ordem como se estivesse utilizando um GRID. Por exemplo, os primeiros dois terços (2/3) do formulário poderia ser destinado a um formato com questões de múltipla escolha e o um terço (1/3) final poderia ser destinado a questões que exigem respostas dissertativas;
• Continue sendo consistente. Tenha certeza de deixar mais espaço acima da pergunta do que abaixo dela, fazendo com que haja um agrupamento visual adequado entre a pergunta e a resposta. Ao iniciar uma nova seção, mantenha sempre os mesmos espaçamentos, tamanhos de fonte e ordenação (título, sub-título, questões, respostas, etc);
• Seja simples, não complique. Jamais direcione o usuário dessa forma: "Se respondeu a letra A, vá para a seção 4, sub-item 2 e continue";
• Não use algarismos romanos para numerar seções. Sério! Se for numerar as seções, seja claro informando os numerais que todos já conhecem e não dependerão de pesquisa para relembrar o que aprendeu na escola (você já parou pra pensar em como um leitor de telas lê algarismos romanos?);
• Prefira utilizar elementos básicos em sua pesquisa. Não reinvente a roda se não for realmente necessário. Campos de texto, checkboxes, radio buttons, combos de seleção, tabelas comparativas (desde que tenha títulos claros), costumam ser acessíveis. Elementos complexos como sliders, elementos de ordenação (drag & drop), NPS, Likert, questões ocultas (que aparecem após selecionar alguma opção) costumam ser difíceis de compreender através de leitores de tela. Use esses elementos quando realmente necessário, explique-os muito bem e tenha certeza de testar esses elementos com leitor de telas;
• Sempre informe a quantidade de itens que pode ser selecionados. Parece óbvio, mas para um usuário que está utilizando um leitor de telas, quanto mais informações ele tiver melhor e neste caso é fundamental. Por exemplo: "Selecione apenas 3 opções" ou "Selecione até 3 opções" ou "Selecione todas as opções que se aplicam a você";
• Valide erros e campos obrigatórios. Você cria sua pesquisa com campos obrigatórios, mas você costuma testar a sua pesquisa clicando em "Enviar" sem preencher nada? Pois é… crie esse hábito e aproveite para verificar como o leitor de telas está informando o usuário que o campo é obrigatório;
• Questões de múltipla escolha precisam de diferentes formatos. Você pode escolher exibir as opções de forma horizontal ou vertical, depende apenas do contexto e também da comodidade para os usuários. Para perguntas, cuja resposta seja algo do tipo "sim ou não", utilize uma apresentação horizontal (uma ao lado da outra). Para respostas com três ou mais opções, escolha uma apresentação vertical (uma abaixo da outra), veja o exemplo abaixo:

• Utilize elementos corretos para as questões. Em um grupo de opções onde o usuário pode selecionar apenas uma delas, deve-se utilizar o Radio Button. Para um grupo de opções onde o usuário poderá selecionar mais de uma opção, utilize checkboxes. Parece óbvio? Mas cansamos de ver o uso de checkboxes quando se deve selecionar apenas uma opção…;
• Evite escalas numéricas que exigem a memorização dos valores. Escalas numéricas podem prejudicar o entendimento de usuários com dificuldade em memorização. O ideal é que não haja uma escala e que as opções sejam apresentada diretamente nas questões. Veja os exemplos abaixo:

Imagem, áudio e vídeo

Não é comum acrescentar conteúdo audiovisual em uma pesquisa, mas pode ser necessário. Para esses casos…

• Em imagens, sempre inclua o texto alternativo de forma que fique claro o conteúdo da imagem (aqui também vale a dica para fechar os olhos e pedir para alguém ler o texto alternativo pra você em voz alta);
• Para áudio e vídeo sempre será necessário uma transcrição do conteúdo que poderá ser fornecido através de um link adicional junto ao vídeo.

Contraste e Cores

Cores e contraste sempre será um tema complicado, enquanto alguns grupos se beneficiam com determinadas combinações outros saem prejudicados. Por exemplo, daltônicos podem se beneficiar com um alto contraste, já disléxicos podem ser prejudicados com o mesmo contraste.

Pensando nisso, as principais ferramentas já adaptaram os seus templates padrões com contrastes adequados para a maioria das situações. Caso você construa o próprio método de pesquisa ou modifique as cores pré-determinadas dos temas, é importante fazer uso de ferramentas de análise de contraste para garantir uma taxa mínima aceitável para o nível AA que é 4.5:1, a tabela abaixo trás maiores explicações sobre o tema:

Finalizando seu formulário de pesquisa

• Certifique-se de que há uma tela de confirmação ao se finalizar o formulário e de que a mensagem seja clara e direta indicando que a pesquisa chegou ao fim;
• Teste a navegação de seu formulário de pesquisa utilizando apenas um teclado (sem o uso de mouse);
• Teste a navegação de seu formulário utilizando um leitor de telas;
• Aumente o zoom do próprio browser em no mínimo 200% e veja se as perguntas e as respostas continuam legíveis e visíveis;
• Leia suas perguntas e respostas em voz alta. Se você compreender as perguntas quando forem verbalizadas, qualquer um que utilizar um leitor de telas compreenderá também;
• Se for possível testar seu formulário antes de enviar, faça testes com pessoas que realmente dependam de tecnologias assistivas, é a única forma de garantir que seu formulário de pesquisa estará acessível a maioria das pessoas;
• Teste sua pesquisa, teste novamente e por que não, testar mais uma vez? Seus usuários agradecem! :)

Para saber mais…

Estes foram alguns dos links que utilizei como referência para escrever este artigo e resumir as boas práticas citadas:

• "O que fazer" e "O que não fazer" ao projetar para Acessibilidade
• An accessible survey method: Increasing the participation of people with a disability in large sample social research
• Creating Accessible Surveys
• A Step-by-Step Guide to Creating More Accessible Surveys (PDF)
• Conceito de visão subnormal (Conselho Brasileiro de Oftalmologia)

Principais ferramentas de pesquisa online…

As ferramentas abaixo já adaptaram seus recursos para atender os principais requisitos de acessibilidade. Tem mais sugestões? Deixe nos comentários.

• BOS (possui dicas de acessibilidade)
• Google Forms
• Qualtrics (possui dicas de acessibilidade e uma lista de itens acessíveis)
• Survey Monkey (possui dicas de acessibilidade)
• Typeform

Me chamo Marcelo Sales, sou designer e apaixonado por Acessibilidade, Psicologia e UX. Criei recentemente um canal no Youtube chamado Todos por Acessibilidade e também o projeto http://acessibilida.de.

O seu formulário de pesquisa está acessível para todas as pessoas? was originally published in UX Collective 🇧🇷 on Medium, where people are continuing the conversation by highlighting and responding to this story.

Todos sabem (ou deveriam saber) que a acessibilidade não deve ser tratada apenas como um checklist no fim do processo de desenvolvimento de aplicações web. Muito menos deve ser uma responsabilidade apenas da equipe de desenvolvimento, como em muitos casos acontece. Mas qual é afinal o papel de cada profissional envolvido neste processo? Todas as áreas precisam realmente estar envolvidas?

John Foliot, principal especialista em acessibilidade da consultoria norte-americana Deque tuitou o seguinte:

(((John Foliot))) on Twitter

I just want to note that it's Web CONTENT Accessibility Guidelines, not Web PAGES Accessibility Guidelines.

Ou seja, é essencial lembrar que o WCAG tem a ver com CONTEÚDO e não necessariamente padrões para uma página em si ou aplicação específica. Seus princípios, recomendações e diretrizes focam em um padrão para que seu conteúdo alcance todas as pessoas e neste caso, todos são responsáveis para que isso ocorra da melhor forma.

Principais membros do time

Em uma apresentação realizada pelo mesmo John Foliot, “The Road to Sustainable Corporate Accessibility”, em que ele compartilha a sua visão do que seria uma boa equipe de acessibilidade, ele nos apresenta 4 principais funções macros.

“As equipes mais bem sucedidas possuem esses quatro membros chaves.”

Gestor executivo

Essa é a pessoa que defenderá e sustentará a necessidade de aplicação de acessibilidade por todas as equipes e também a visão que a empresa terá diante do mercado. Principalmente em grandes empresas, algumas decisões precisam ser tomadas "de cima para baixo" pra fazer com que a equipe engrene, principalmente quando o assunto ainda é novo. Essa será a pessoa responsável por deixar claro a importância da acessibilidade para todos.

Claro que isso não deve ser feito visando apenas o cumprimento da legislação. Essa função tem também a influência de fomentar o espírito de equipe, a positividade na aplicação de acessibilidade e consequentemente disseminar a cultura de acessibilidade entre os envolvidos, direcionando assim um futuro ideal para o tratamento do assunto em futuros projetos da empresa.

Coordenador de Acessibilidade Web

Empresas, cuja cultura de acessibilidade já está enraizada em seu DNA possuem áreas específicas que são responsáveis pela disseminação do conceito e aplicação do assunto por todos os setores e colaboradores. Algumas responsabilidades dessa função de coordenador são:

• Comunicar políticas de acessibilidade dentro da empresa;
• Promover a sensibilização para a acessibilidade, em todas as esferas de atividades, colaboradores e equipes;
• Identificar necessidades e promover treinamentos para diversas áreas;
• Garantir que a acessibilidade web permaneça presente na mente de quem toma as decisões e de todos os envolvidos em projetos.

Enfim, é um dos que podem ser chamados de evangelista de acessibilidade na empresa.

“Campeão” de Acessibilidade Web

Apesar do termo "campeão" não ser muito usual por aqui, essa é a pessoa responsável por "fazer as coisas acontecerem" na empresa. Normalmente é o principal apoio do coordenador de acessibilidade web.

Precisa ter uma visão clara sobre acessibilidade, compreender profundamente todos os tipos de deficiências, entender precisamente os benefícios e reais ganhos quando se atende a essas questões e também precisa compreender a legislação a ponto de tomar decisões legais e que podem comprometer o andamento da aplicação das diretrizes por parte das equipes e possíveis falhas de conformidade.

Spoiler: Esse profissional será citado mais adiante, mas ele tem um pé na cozinha de User eXperience. ;)

Especialista em Acessibilidade Web (por funções)

Este profissional, segundo John, é a pessoa que precisa ter uma forte compreensão de como a acessibilidade afeta a sua área de especialização. Daí a separação por funções.

Analista de negócios e gerentes de projetos precisam compreender que algumas decisões impactam diretamente a experiência e podem prejudicar o acesso a informação/conteúdo. Designers devem focar em design inclusivo e entenderem que além da visão, audição e tato também devem fazer parte de suas criações. Desenvolvedores devem entender de semântica, padrões web e dominar boas práticas para fazer com que o acesso a informação seja o mais simples possível.

Enfim, em todos os departamentos, deveria haver algum tipo de especialista integrado a equipe para que se forneça o apoio necessário ao entendimento e correta aplicação dos critérios básicos e essenciais de acessibilidade.

Ok, mas se a empresa em que trabalho não tem especialistas, como faz?

A visão do John é essencial, porém parte do princípio de um mundo corporativo ideal, mas o fato é que a maioria das empresas não possuem a menor possibilidade de ter especialistas em todos os níveis hierárquicos.

Em muitos casos costuma ser importante termos decisões tomadas de cima pra baixo, principalmente em grandes empresas onde é complicado priorizar tarefas essenciais que muitos teimam em considerar como “features”, mas para complementar a visão de John, o artigo “Accessibility is everyone’s job: a role-based model for teams” de Mark Palmer, especialista em acessibilidade da consultoria Simply Accessible, detalha um pouco mais alguns cargos e funções.

Tomei a liberdade e mesclei áreas e funções que o Mark cita em seu artigo com alguns que fazem mais sentido a boa parte da realidade de empresas nacionais. Não necessariamente você terá todas as áreas na empresa em que trabalha, mas daí basta replicar para a sua realidade. Vamos a elas…

Negócios

Demandas não devem ser vistas como uma simples necessidade de compliance

Normalmente as demandas surgem da área de negócios e é claro que o objetivo principal é um ROI de dar sorrisos amplos aos principais investidores. Não vou entrar em detalhes de negócios neste artigo, mas vale lembrar a todos que não necessariamente o ROI se dá em torno de dinheiro propriamente dito.

Tim Cook, foi questionado (diversas vezes, na verdade) sobre os gastos da Apple em torno de programas relacionados a acessibilidade e sustentabilidade e a sua explicação normalmente é simples:

"A empresa faz muitas coisas por diversas razões além do lucro."

Neste artigo da Forbes, "Why Tim Cook Doesn’t Care About ‘The Bloody ROI’", há um detalhamento maior sobre este ponto.

A verdade é que podemos repensar a forma como tratamos alguns assuntos e como eles geram retorno para a empresa. Por exemplo, retorno positivo perante a sociedade e uma melhor experiência para TODOS os usuários.

Senhores analistas de negócios, leiam o artigo "Accessibility for Business and Pleasure" da Sarah Horton, estrategista de UX do Paciello Group e entendam o quanto investir em acessibilidade pode ser prazeroso para o lazer e também para os negócios! :)

Marketing

Conteúdo claro, simples e sem ambiguidade

Em muitos casos há um equipe especializada em conteúdo, caso a empresa não tenha quem cuide do conteúdo é a equipe de marketing que normalmente assume esse papel. Faz sentido, pois normalmente são eles que definem campanhas que entram no ar, o tom de voz e a forma que a empresa se comunica com seus clientes.

Segundo o WCAG, o terceiro princípio de acessibilidade é o "compreensível", ou seja, a informação precisa ser clara o suficiente para que o usuário entenda-a corretamente. Desde títulos de páginas, passando por explicações de produtos e até mesmo mensagens de erro que possam surgir ao preencher um formulário. Esses profissionais tem uma parcela muito grande no que diz respeito a responsabilidade com acessibilidade. Basta pensar que usuários com baixa visão ou cegos, dependem de um leitor de telas e neste caso a mensagem precisa ser clara, inclusive para os ouvidos.

Design

Emoção e sentimento para todos os sentidos, não apenas a visão

Essa é a equipe que define cores, tamanhos de textos, espaços clicáveis, alinha corretamente elementos, enfim, define a camada de apresentação visual de sites e aplicativos. Normalmente baseados em uma identidade visual pré-definida e regras rígidas de aplicação e uso da marca.

Mas muito além de regras, o objetivo principal é cativar o cliente e criar uma relação de identidade com os usuários. O foco é a emoção e neste caso, vale ressaltar que essa emoção deve ser conquistada não apenas através da visão. O tato e principalmente a audição também precisam ser bem pensados e transmitir emoção enquanto facilita o acesso a informação.

Vale lembrar que o quarto princípio de acessibilidade, "robusto", é basicamente tudo sobre design responsivo e conteúdo adaptável a diversos meios e tecnologias assistivas, portanto essa equipe também tem uma boa parcela de responsabilidade na aplicação de acessibilidade.

UX

Experiências impecáveis independentemente de habilidades e/ou deficiências

Se há uma equipe que pode ser considerada a principal responsável pela correta aplicação de acessibilidade, essa é a equipe de User eXperience.

Essa equipe precisa ter na ponta da língua as melhores práticas em fornecer um conteúdo acessível para todos os usuários, independentemente de suas habilidades e/ou deficiências. Todos precisam ter a mesma experiência (de acordo com o seu ponto de vista e uso) ou melhor dizendo, experiências equivalentes.

Devemos fornecer métodos de uso que atendam a todas as pessoas:
- equivalentes, pois a experiência de uso é individual

Esses profissionais precisam entender conceitos de acessibilidade para conseguir promover testes adequados com usuários e seus diferentes graus de dificuldade de acesso a informação. Precisam entender como leitores de tela e outros tipos de tecnologias assistivas (por exemplo, impressoras em braile) funcionam. Precisam entender corretamente quais são os recursos disponíveis de assistência em sistemas operacionais (mobile e desktop) e browsers (como usuários que dependem de zoom, utilizam um navegador?). Precisam entender como hierarquizar adequadamente o conteúdo na tela e como este conteúdo irá se comportar em um ambiente responsivo (a ordem de leitura dos elementos será alterada, será que a experiência também?).

Enfim, são muitas variáveis e se a intenção é fornecer a melhor experiência possível para TODOS os usuários, então este será o profissional que definirá especificações e poderá ajudar outras equipes envolvidas a aplicar corretamente a experiência projetada.

No artigo "O que fazer e o que não fazer ao projetar para Acessibilidade", há boas dicas de como projetar adequadamente para cada tipo de deficiência.

A equipe de UX deve abraçar o papel de evangelistas de acessibilidade.

John Foliot citou que entre os cargos que ele considera essenciais, há a presença de um "campeão de acessibilidade web", não seria incomum dizer que este campeão seria da área de UX.

Tecnologia

Implementação de código semântico e dentro de padrões universais

Se a equipe de UX é considerada como a maior responsável pelo sucesso da aplicação de acessibilidade a equipe de TI é a segunda maior responsável.

Grande parte dos problemas de implementação de acessibilidade em sites se deve pelo desconhecimento de padrões web na construção de código.

Websites aren’t broken by default, they are functional, high-performing, and accessible. You break them.

HTML é uma linguagem naturalmente acessível, todas as suas tags possuem significado semântico e todos os leitores sabem interpretar corretamente esse significado, o problema ocorre quando essas tags não são aplicadas adequadamente.

É bem provável que isso se deve ao fato de que por ser uma linguagem simples, o HTML é subestimado por boa parte dos desenvolvedores. É bem comum pessoas gritarem aos quatro ventos coisas como, "eu manjo de html" ou "html é fácil". Basta ler duas ou três linhas de código desses desenvolvedores para entendermos o "quão fácil" é a linguagem… ;)

Esse profissional precisa ter a semântica na veia e respirar front-end. Precisa saber de cor coisas como DOM, CSSOM, Render Tree, Reflow e Paint. Precisa entender que a Accessibility Tree vai influenciar diretamente na tecnologia assistiva utilizada. Precisa saber que propriedades que ocultam elementos em tela via CSS também o fazem para o leitor de telas (mas não deveria). Precisa conhecer ARIA e saber como aplicar de forma efetiva.

E principalmente, precisa entender que o site tem que ser operável não apenas por mouse! Seu conteúdo precisa ser acessado utilizando apenas um teclado, com tecnologia de voz, com telas touch, com JS e CSS desabilitados e o que mais você puder. Não basta funcionar apenas com mouse.

Felizmente, a documentação do W3C para acessibilidade é uma das mais completas já produzidas. É fácil encontrar conceitos detalhados, exemplos de aplicação, casos de sucesso e insucesso.

Amigo desenvolvedor, caso esses conceitos passam longe do seu conhecimento, talvez valha uma reciclagem. Comece os estudos por este artigo "A Practical Starter Guide on Developing Accessible Websites" e siga para o material do W3C em seguida! :)

Qualidade e testes

Porque alguém tem que ajudar a garantir a excelência

Essa é a equipe que irá ajudar com a qualidade final do "entregável". Perceba que eu citei que é a equipe que "irá ajudar" e não a equipe responsável. Isso por que é muito comum acharem que essa equipe é a que fará todo o processo de homologação e consequentemente também é bem comum eles ficarem com "toda a culpa", caso algo publicado esteja incorreto, afinal "alguém tem que levar a culpa, né?". Todos os envolvidos são responsáveis pela entrega final, o sucesso não vem sozinho, as falhas também não.

O ideal é que os testadores sejam especialistas e conheçam critérios de sucesso, diretrizes e os princípios de acessibilidade. Porém, além disso é necessário que eles tenham noção de UX e em alguns casos de desenvolvimento, para além dos testes (com visão de usuário) auxiliar as outras equipes com dicas e sugestões (com visão técnica) na correção de problemas.

Usuário

Também somos usuários!

Não podemos esquecer de nós mesmos. Quando desenvolvemos produtos e serviços, normalmente nos esquecemos que nós também somos usuários de muitos desses produtos e serviços. Se você não consegue se colocar no lugar de outras pessoas e compreender situações que essas pessoas passariam ao tentar usar determinados recursos, o artigo “Um Alfabeto de Problemas de Acessibilidade” pode ajudar.

Nossa necessidade de web acessível pode durar um minuto, uma hora ou o resto de nossas vidas. Nunca saberemos.

Lembre-se que você poderá necessitar de tecnologias assistivas (um mero recurso de zoom, por exemplo) em algum momento de sua vida e pergunte a si mesmo:

"Será que eu consigo utilizar o que eu mesmo estou projetando?"

TL;DR

É absolutamente mais comum do que a gente imagina pensar que a acessibilidade é algo que apenas desenvolvedores devem pensar. A maioria das pessoas ainda pensam assim. Elas acreditam que é algo técnico e isso é natural se pensarmos que as diretrizes WCAG 1.0 (que foram criadas em 1999, é sempre bom lembrar) tratava-se exclusivamente de critérios técnicos, porém a WCAG 2.0 (de 2008) refuta esse pensamento trazendo uma visão mais humana as questões, mas aparentemente as pessoas ainda se baseiam em opiniões e causos que ouvem “por aí”.

Vale reforçar mais uma vez que a acessibilidade não deve ser tratada como um checklist ou uma feature de projeto. Trata-se uma jornada e não um fim. Não há um deadline para a sua aplicação, pois é algo que mesmo após a implantação deve ser seguidamente validada, pois nada impede de que se não houver um correto ciclo de produção, algum conteúdo deixe de ser acessível em um determinado momento, seja por conta de atualizações frequentes, seja por conta de falha em um das etapas de implementação.

A acessibilidade precisa ser pensada desde o início de qualquer projeto e DEVE ter o envolvimento de todos os profissionais para que se garanta a sua correta aplicação e manutenção.

"Para que o processo de acessibilidade seja incorporado dentro de uma empresa, todos devem entender a sua importância. E se algumas pessoas ou equipes desconhecem essa importância, cabe aqueles que conhecem ajudar seus pares para que a compreendam adequadamente."

A frase acima está diretamente ligada a uma cultura de acessibilidade dentro das instituições, mas isso será papo para um outro post. :)

Me chamo Marcelo Sales, sou designer e apaixonado por Acessibilidade, Psicologia e UX. Criei recentemente um canal no Youtube chamado Todos por Acessibilidade e também o projeto http://acessibilida.de.

Quem são os responsáveis por aplicar a acessibilidade em projetos digitais? was originally published in Tableless on Medium, where people are continuing the conversation by highlighting and responding to this story.