VR acessível e WCAG: o que se aplica, o que falha e a checklist que seguimos

VR acessível é a prática de desenhar experiências imersivas que uma pessoa consegue usar independentemente da visão, audição, mobilidade ou tolerância ao desconforto. As Web Content Accessibility Guidelines (WCAG) foram escritas para documentos planos e interfaces 2D, por isso só se aplicam à VR até meio caminho: os princípios sobrevivem, os critérios de sucesso quase todos não. É assim que traduzimos as WCAG para a realidade de um head-mounted display (HMD), é aqui que falham, e esta é a checklist que seguimos em cada projeto imersivo.

VR acessível e WCAG: porque uma adaptação direta falha

As WCAG organizam-se em torno de quatro princípios — Percetível, Operável, Compreensível, Robusto (POUR). São sólidos em qualquer meio. O problema é que os critérios de sucesso por baixo deles pressupõem uma página: uma viewport com eixos x/y, um DOM, um teclado, um leitor de ecrã a percorrer uma árvore linear. A VR não tem nada disso. Não há ordem de tabulação numa sala. Não há tamanho de letra fixo quando o texto flutua a dois metros à frente e a pessoa se pode inclinar para ele. O contraste deixou de ser uma propriedade de dois valores hexadecimais; depende da lente, do painel, da luz ambiente que entra à volta da interface facial, e de onde o utilizador está a olhar.

Por isso mantemos os quatro princípios como bússola e reconstruímos os critérios para três dimensões. Os XR Accessibility User Requirements (XAUR) do W3C são o mais próximo de uma ponte oficial, e é o documento que entregamos a novos colaboradores antes de tocarem numa cena. As WCAG dão-lhe o espírito; os XAUR dão-lhe o vocabulário imersivo; a checklist abaixo é o que verificamos de facto.

Percetível: legendas, contraste e pistas sonoras em 3D

As legendas em VR não são uma faixa que se sobrepõe a um retângulo — são um objeto no espaço, e onde se coloca esse objeto decide se funcionam. Legendas fixas no fundo do campo de visão enjoam, porque o texto nada contra o movimento da cabeça. Nós prendemos as legendas a um billboard que segue suavemente a cabeça com um ligeiro atraso e uma zona morta, de modo a permanecerem legíveis sem ficarem rigidamente presas ao olhar. Para diálogo entre duas personagens ou estações, acrescentamos um indicador direcional — uma pequena seta ou um brilho subtil — para que um utilizador surdo ou com perda auditiva saiba quem fala e para onde se virar. Legendas que não dizem de onde veio o som estão meio feitas.

O contraste é o critério que mais erram porque desenham num monitor. As WCAG pedem um rácio de contraste de 4,5:1 para texto normal. Num HMD, o rácio medido no painel e o rácio percebido pelo olho divergem: layouts de subpíxeis pentile, aberração cromática nas bordas da lente e o brilho Fresnel comem todos contraste. A nossa regra é desenhar com uma margem confortável acima do mínimo das WCAG — apontamos a cerca de 7:1 para texto corrido — e depois verificar dentro do headset, não no Figma, com o brilho onde uma clínica ou sala de estar real o colocaria. Evitamos também branco puro sobre preto puro, que faz bloom nos painéis OLED e arrasta durante o movimento.

O áudio carrega uma carga enorme em VR, e é precisamente por isso que não pode ser o único canal. Cada pista sonora importante precisa de um parceiro visual e, quando o hardware permite, de um háptico. Um temporizador que só apita falha para um utilizador surdo; um temporizador que apita, pulsa um anel de luz e vibra o comando funciona para quase toda a gente. O áudio espacial é maravilhoso para quem vê e ouve, e um verdadeiro obstáculo para outros, por isso oferecemos sempre um interruptor de áudio mono / não-espacial e nunca bloqueamos o progresso atrás de localizar um som.

Operável: uma mão, sentado e sem pressão de tempo

É aqui que a VR mais diverge da web, e onde a maioria das experiências "acessíveis" exclui pessoas em silêncio. Os critérios de operabilidade a que nos obrigamos:

• Modo a uma mão. Nunca exigir dois comandos em simultâneo para uma ação central. Muitos utilizadores têm uma mão utilizável, ou seguram uma bengala, ou estão numa cama de hospital com um soro num braço. Cada interação a duas mãos precisa de um equivalente a uma mão, mesmo que seja mais lento.
• Paridade entre sentado e de pé. A recentragem e a calibração de altura têm de permitir que um utilizador sentado alcance tudo o que um de pé alcança. Nunca colocamos um objeto obrigatório no chão ou acima do alcance natural de quem está de pé. Testem a experiência inteira sentados antes de a darem por concluída.
• Sem exigência de alcance. Os objetos vêm ter com o utilizador, ou existe um gesto de "aproximar". Não obrigamos ninguém a esticar-se ou a aproximar-se de uma parede que não consegue ver.
• Sem pressão de tempo. As WCAG 2.2 têm toda uma diretriz sobre Tempo Suficiente (2.2.1) e transfere-se na perfeição. Tudo o que tenha limite temporal tem de ser extensível ou desativável. Em contextos médicos e de idosos isto é inegociável — um paciente frágil nunca deve perder progresso por ter sido lento.
• Escolha de locomoção. Oferecer teleporte, suave e rotação por incrementos, com o teleporte por defeito. A locomoção suave é um gatilho de cibernáusea para uma minoria significativa; impô-la é uma falha de acessibilidade, não uma opção estilística.
• Alvos de interação ajustáveis. O equivalente em VR ao WCAG 2.5.8 (tamanho do alvo) é o tamanho angular. Os botões têm de ocupar um ângulo suficientemente grande para serem acertados de forma fiável com uma mão trémula ou tracking impreciso. Dimensionamos e espaçamos os elementos interativos para que um tremor não acione o errado.

Compreensível e Robusto: conforto, previsibilidade e a realidade do hardware

Compreensível, em VR, significa sobretudo previsível. Não teleportar a câmara sem input do utilizador. Sem mudanças súbitas de campo de visão. Sem flashes — a regra das WCAG dos três flashes por segundo (2.3.1) importa mais num headset preso à cara de alguém do que alguma vez importou num monitor, porque não se pode desviar o olhar. Cumprimo-la à risca e tratamos qualquer coisa perto do limite como um bug.

As definições de conforto são o capítulo nativo da VR que as WCAG nunca escreveram, e tratamo-las como funcionalidades de acessibilidade, não como opções. Vinhetagem (efeito túnel) durante o movimento, um piso de framerate abaixo do qual nos recusamos a descer, a capacidade de reduzir ou remover o movimento conduzido pela câmara, incrementos de rotação — são a diferença entre uma experiência que alguém consegue terminar e uma em que tira o headset ao fim de noventa segundos. Se uma definição de conforto está escondida três menus abaixo, não existe. Expomo-las num ecrã de conforto inicial, antes de a experiência propriamente começar.

Robusto significa que continua a funcionar na realidade desarrumada dos dispositivos e do contexto assistivo. Na prática: respeitar as definições de acessibilidade da plataforma onde existem, não lutar contra a escala de texto ou os filtros de cor do sistema, etiquetar objetos interativos para que leitores de ecrã ao nível da plataforma e futuras camadas assistivas os possam descrever, e degradar com elegância quando um comando perde tracking. Robustez em VR significa também robustez física — em implementações clínicas o hardware é desinfetado entre pacientes e manuseado por quem não o construiu, o que é uma restrição de acessibilidade própria sobre a qual escrevemos separadamente.

A versão curta: a nossa checklist de VR acessível

Esta é a lista que corremos antes de qualquer build imersiva ser publicada. É deliberadamente concreta, porque "torna-o acessível" não é uma especificação.

1. Existem legendas, seguem a cabeça com uma zona morta e indicam a direção de quem fala.
2. Cada pista sonora tem um parceiro visual e, quando possível, háptico. Nenhum progresso depende só de ouvir.
3. Existe um interruptor de áudio mono / não-espacial.
4. Contraste do texto verificado dentro do headset, apontando a ~7:1 para texto corrido; sem branco puro sobre preto puro.
5. Cada ação central tem um caminho a uma mão.
6. A experiência inteira é completável sentado, com recentragem e calibração de altura completas.
7. Nada exige esticar-se, dar passos ou interagir ao nível do chão.
8. Sem limites de tempo não-canceláveis; passos cronometrados são extensíveis ou desativáveis.
9. Locomoção por teleporte, suave e por incrementos, todas oferecidas; o teleporte é o defeito.
10. Os alvos interativos são angularmente grandes e bem espaçados para input impreciso.
11. As definições de conforto (vinheta, redução de movimento, incrementos de rotação, piso de framerate) ficam num ecrã inicial, não num menu profundo.
12. Sem movimento de câmara sem input do utilizador; cumprimento estrito da regra dos três flashes.
13. Os objetos interativos estão etiquetados para camadas assistivas da plataforma; a build degrada com elegância em caso de perda de tracking.

Onde as WCAG genuinamente não chegam

Vale a pena ser honesto sobre as lacunas, porque fingir que as WCAG cobrem totalmente a VR é como as equipas publicam coisas que passam numa auditoria e continuam a excluir pessoas. Não há uma métrica de contraste acordada para HMDs. Não há forma normalizada de expor um grafo de cena 3D a um leitor de ecrã como o DOM expõe uma página. A cibernáusea não tem qualquer critério WCAG, e é a maior razão para as pessoas abandonarem a VR. E a tolerância ao conforto varia tanto entre indivíduos que a única resposta robusta são definições generosas e descobríveis, e não um limiar único.

Por isso tratamos as WCAG como o piso e os quatro princípios POUR como a lei, e depois acrescentamos por cima os XAUR e regras de campo conquistadas a custo. A disciplina que melhor transita da web é a mentalidade: desenhar para a pessoa que não é você — o utilizador com uma mão funcional, o paciente que nunca segurou um comando, a pessoa que enjoa em noventa segundos. Construa para eles primeiro e a experiência melhora para todos, tal como os rebaixamentos de passeio e as legendas melhoraram a web.

FAQ

As WCAG aplicam-se à VR? Os seus quatro princípios (POUR) aplicam-se na totalidade; a maioria dos critérios de sucesso específicos foi escrita para páginas 2D e precisa de tradução. Use as WCAG como fundação e os XR Accessibility User Requirements (XAUR) do W3C como ponte imersiva.

Qual é a mudança de VR acessível com mais impacto? Oferecer locomoção por teleporte por defeito e um bom conjunto de definições de conforto. Remove a maior barreira — a cibernáusea — que nenhum critério WCAG sequer nomeia.

Como se fazem legendas em VR? Prendê-las a um billboard que segue a cabeça com uma zona morta para se manterem legíveis sem provocar enjoo, e indicar de que direção veio um som ou quem fala.