Acessibilidade motora em apps de ensino clínico

Você abre o app de casos no tablet. A pista seguinte exige um gesto de pinça para ampliar a imagem, depois um arraste longo até o campo de hipótese e um toque preciso num ícone de 24 pixels ao lado de outro quase idêntico. Com tremor leve nas mãos, ou com força limitada em um dos membros, a tentativa falha três vezes antes da hipótese sequer ser enviada. O raciocínio clínico estava pronto. A interface pediu precisão motora fina. Esse é o terreno da acessibilidade motora em apps de ensino clínico e em jogos de diagnóstico.

O NEXO é um jogo diário de diagnóstico médico: um caso clínico por dia, seis pistas progressivas e feedback por proximidade na CID-10 em cinco níveis.

Acessibilidade motora trata de tornar a interação usável para quem tem tremor, limitação de membros, força reduzida, precisão de toque menor, fadiga muscular ou quem opera com switch, teclado, trackball, controle ou entrada por voz. Vale para estudantes e médicos com deficiência física permanente e também para quem está com tala, pós-procedimento, dor aguda ou usa o aparelho com uma só mão no plantão. O foco deste texto é o desenho de apps e plataformas de ensino: alvos de toque, gestos, tempo, arrastar-e-soltar e alternativas de entrada. Não é checklist numerado de normas técnicas de software médicos, nem guia de leitores de tela (tema de outro post da série).

Principais pontos

• Barreiras motoras em apps de ensino clínico incluem alvos pequenos, gestos de caminho obrigatório, arrastar-e-soltar sem alternativa, timeouts curtos e dependência de mouse fino ou de toque preciso.
• Princípios úteis: alvos grandes e espaçados, operação com um único ponteiro, tempo flexível, teclado e switch completos, desfazer fácil e equivalência entre toque, teclado e entrada assistiva.
• Estudantes e médicos com deficiência física existem na formação; padrões técnicos funcionais pedem o resultado clínico, não um único modo de apontar na tela.
• Tamanho de alvo e alternativas a gestos complexos têm base em pesquisa de interação e em orientação internacional de acessibilidade web e móvel.
• No NEXO, casos fictícios com apresentação clínica real e até seis pistas em fluxo de tela pedem interação com pistas e hipóteses; o desenho inclusivo reduz atrito motor sem afirmar eficácia.

O que é acessibilidade motora em apps de ensino

Acessibilidade motora é o conjunto de decisões de interface que permitem operar um app sem depender de movimentos finos, rápidos ou complexos. Em ensino clínico digital, isso cobre tocar pistas, abrir hipóteses, confirmar envio, navegar no diferencial e fechar o caso. Se a única forma de avançar for um gesto de pinça seguido de um arraste preciso sob cronômetro, o app mede destreza digital, não só raciocínio.

Não confundir com acessibilidade cognitiva (linguagem, carga, feedback) nem com acessibilidade visual (leitores, contraste, ampliação). Um caso pode ser cognitivamente claro e ainda assim inacessível a quem não consegue manter o dedo estável sobre um alvo minúsculo. Também não é o mesmo eixo do post sobre acessibilidade digital em softwares médicos, centrado em critérios gerais de software clínico, nem o de tecnologia assistiva para médicos com deficiência visual. Aqui o problema é motor: tremor, força, amplitude, uso de switch e equivalência de entrada.

Na formação médica, estudantes com deficiência física e sensorial existem, embora a divulgação e as acomodações ainda sejam inconsistentes. Em análise nacional de padrões técnicos de escolas médicas, poucos documentos apoiavam de modo explícito acomodações razoáveis; muitos eram ambíguos ou silentes sobre responsabilidade e sobre o uso de auxílios (Zazove et al., 2016). Uma análise ética argumenta que padrões "orgânicos" (exigir o órgão ou o gesto sem auxílio) excluem candidatos capazes sob padrões funcionais, que pedem o resultado da tarefa com acomodação (McKee et al., 2016). O paralelo para apps de ensino é direto: exigir "toque preciso com o polegar dominante" é padrão orgânico de interface; exigir "enviar a hipótese" com teclado, switch ou toque ampliado é padrão funcional.

Prevalência e trajetória também importam para quem desenha produto educacional. Dados de prevalência e de acomodações clínicas em educação médica mostram que deficiência na escola médica não é anedota (Meeks et al., 2020). Estudos de coorte sobre desempenho de estudantes com deficiência reforçam que, com acesso adequado, a trajetória acadêmica pode se alinhar à dos pares; o gargalo costuma ser barreira de ambiente, não "falta de aptidão" genérica (Meeks et al., 2022). Chamadas à ação na literatura pedem remover barreiras estruturais e adotar padrões técnicos inclusivos (Marzolf et al., 2022; Kezar et al., 2019; Stauffer et al., 2022).

Para o estudante, a pergunta prática é: "este app me cobra raciocínio clínico ou me cobra acertar um pixel?". Para quem desenha casos e jogos, a pergunta é: "cada controle crítico tem um caminho operável com teclado, com toque amplo e com tempo humano?". O restante deste texto traduz isso em barreiras e em remédios concretos, com ligação a tipos de jogos para estudantes de Medicina e a aprendizagem baseada em casos.

Barreiras motoras comuns na interface

Em apps de casos e em jogos de diagnóstico, as barreiras motoras se repetem. Alvos pequenos e colados: ícones de ação lado a lado sem margem. Gestos obrigatórios de caminho: pinça, deslize em curva, multi-toque. Arrastar-e-soltar sem alternativa de toque-para-selecionar e toque-para-soltar. Timeouts curtos: a tela expira se o dedo hesitar. Controles só no canto superior, difíceis de alcançar com uma mão. Dependência de hover de mouse em versão web. Confirmações destrutivas sem desfazer. Campos de texto que abrem teclado virtual cobrindo o botão de envio.

Guias de acessibilidade em jogos (por exemplo a lista completa das Game Accessibility Guidelines) pedem remapeamento de controles, evitar gestos complexos obrigatórios, permitir tempo flexível e oferecer modos de entrada alternativos. Em educação móvel, análises de jogos educativos em Android mostram que interfaces baseadas só em canvas frequentemente expõem um único alvo do tamanho da tela ao switch access, o que impede varredura elemento a elemento. O ponto para Medicina é o mesmo: se a barreira for motora, o estudante "erra" o caso sem ter errado o diferencial.

Lista objetiva de barreiras a inspecionar em qualquer caso jogável:

• Botões críticos menores que a área confortável do dedo, sem padding clicável.
• Ações que só existem como gesto de caminho (arraste livre, pinça, círculo).
• Cronômetro ou expiração de sessão que pune hesitar ou corrigir um toque.
• Fluxo impossível só com teclado (Tab, Enter, setas) na versão web.
• Elementos não focáveis para switch access (ordem de foco quebrada ou ausente).
• Alvos destrutivos (apagar, pular pista) colados ao alvo de confirmar.

Essas barreiras afetam de modo desigual. Quem tem tremor pode acionar o vizinho do botão certo. Quem tem força limitada pode não completar um arraste longo. Quem usa uma só mão cansa em gestos bilaterais. Quem opera com switch precisa que cada controle seja um passo discreto na varredura. Quem está em movimento (ambulância, corredor) sofre o mesmo efeito: a mão treme e o alvo pequeno vira loteria. O desenho inclusivo não "favorece" um grupo; amplia quem consegue treinar o que o caso pretende medir.

Um teste rápido de barreira motora: tente completar o fluxo só com teclado; depois só com toque grosseiro (knuckle ou caneta grossa); depois com tempo deliberadamente lento. Se algum caminho quebrar, a interface está medindo destreza, não raciocínio. Corrija alvos, gestos e tempo antes de adicionar conteúdo clínico novo.

Outro sinal: o estudante formula a hipótese em voz alta e falha ao registrar no app. Nesse padrão, investigue alvo, gesto e timeout antes de concluir lacuna de conhecimento. O post sobre lacuna de conhecimento ou de raciocínio trata o diagnóstico educacional; aqui a hipótese é usabilidade motora.

Alvos de toque, espaçamento e precisão

Tamanho de alvo é o primeiro remédio concreto. Orientação internacional de acessibilidade web recomenda, no critério aprimorado de tamanho de alvo, pelo menos 44 por 44 pixels CSS para entradas de ponteiro, com exceções para links em linha e controles equivalentes (W3C, Target Size Enhanced). Há também um mínimo de 24 por 24 pixels CSS no critério de nível AA mais recente (W3C, Target Size Minimum). Em apps nativos, guias de plataforma costumam falar em cerca de 44 pontos (iOS) ou 48 dp (Android). O número exato importa menos do que a regra prática: alvos de ação clínica (enviar hipótese, abrir pista, confirmar) precisam ser grandes o bastante para um dedo trêmulo ou um toque com a lateral da mão.

Pesquisa clássica de interação móvel com polegar em uma mão sugeriu alvos na faixa de cerca de 9 mm para tarefas discretas e seriadas sem degradar erro e preferência (Parhi, Karlson e Bederson, 2006). Notas técnicas da W3C sobre tamanho de toque em dispositivos móveis traduzem recomendações físicas da ordem de 9 mm por 9 mm, alinhadas a essa linha de evidência (W3C Mobile A11y TF, M002). Em usuários com deficiência motora grave, estudos de interfaces táteis mostram que precisão e taxa de acerto variam por região da tela e por tamanho do alvo; tocar (tapping) costuma ser preferido a gestos direcionais quando o tamanho é adequado (Guerreiro et al., 2010).

Espaçamento importa tanto quanto o tamanho. Dois botões de 44 pixels colados sem margem produzem erro de vizinho. Deixe folga inativa entre confirmar e cancelar; separe "enviar hipótese" de "pular pista". Em listas de hipóteses ou de códigos, aumente a altura da linha clicável, não só o texto visível. Padding invisível conta para a área ativa.

Práticas de alvo em caso jogável:

• Botões primários com área mínima generosa (alvo aprimorado de 44 CSS px como referência de desenho).
• Margem clara entre ações irreversíveis e ações rotineiras.
• Evitar ícones só no canto extremo da tela sem versão acessível no fluxo principal.
• Em web, garantir que o foco do teclado desenhe contorno visível no mesmo controle amplo.
• Testar com polegar, com caneta grossa e com tremor simulado (toque deliberadamente impreciso).

Isso não "infantiliza" o app clínico. Alvos grandes são padrão de produto maduro em saúde digital e em jogos sérios. O treino de diagnóstico diferencial com pistas já pede pesar achados com cuidado; do ângulo motor, o mesmo cuidado vale para o botão que registra o peso da hipótese.

Gestos, arrastar-e-soltar e um único ponteiro

Gestos de caminho e multi-toque são barreiras clássicas. O critério de gestos de ponteiro da WCAG pede que funcionalidade baseada em gestos multiponto ou de caminho possa ser operada com um único ponteiro sem gesto de caminho, salvo quando o gesto for essencial (W3C, Pointer Gestures). Tradução para o jogo de diagnóstico: se ampliar a imagem for necessário, ofereça botões de mais e menos zoom; se ordenar hipóteses for necessário, ofereça setas ou menu, não só arrastar cartões.

Arrastar-e-soltar aparece em vários apps educacionais como metáfora "intuitiva". Para quem tem tremor ou usa switch, arrastar é caro: exige manter pressão, seguir trajetória e soltar no alvo certo. A alternativa acessível é selecionar com um toque e confirmar o destino com outro toque (ou com Enter no teclado). O resultado pedagógico é o mesmo; a exigência motora cai.

Mapeamento útil de gestos para alternativas:

• Pinça para zoom: botões + e −, ou slider com teclado.
• Deslize para revelar pista: botão "próxima pista" com rótulo claro.
• Arrastar hipótese para zona de envio: selecionar hipótese e botão "enviar".
• Pressão longa para menu: botão de menu visível ou tecla de atalho.
• Dois dedos para rotação de imagem: botões de giro 90°.

A orientação de acessibilidade móvel da W3C lembra que gestos complexos podem ser impossíveis para parte dos usuários e que o desenho deve oferecer opções equivalentes (W3C, Mobile Accessibility Mapping). Em gamificação na educação médica, pressão de tempo e gestos "divertidos" só ajudam quando não viram barreira de entrada. Diversão que exclui quem treme na mão não é diversão inclusiva.

Há uma distinção útil entre dificuldade desejável e barreira inútil. Recuperar uma hipótese da memória é dificuldade desejável (ver também o post sobre dificuldades desejáveis). Acertar um gesto de pinça sob tremor é barreira inútil. Acessibilidade motora remove a segunda sem apagar a primeira.

Tempo de interação e timeouts

Tempo rígido introduz variância que não é competência clínica: velocidade de mira, tremor sob ansiedade, necessidade de reposicionar o switch. Em apps de ensino, timeouts de sessão, mensagens que somem sozinhas e cronômetros que fecham o caso punem quem precisa de mais tempo motor, não só quem pensa mais devagar.

Princípios alinhados a acessibilidade de tempo: permitir estender, ajustar ou desligar limites de tempo quando o conteúdo não for uma prova formal sincronizada; avisar antes de expirar; preservar o que já foi digitado. Em treino diário de raciocínio, o padrão deve ser ritmo próprio. Se houver modo cronometrado, ofereça-o como opção avançada, anunciada antes de começar.

Boas práticas de tempo em caso jogável:

• Modo padrão sem contagem regressiva agressiva na interação.
• Pausa que congela o caso sem perder a hipótese em rascunho.
• Tempo extra automático ou configurável para quem usa entrada assistiva.
• Evitar toasts rápidos demais como único canal de feedback de erro de toque.
• Permitir corrigir um toque acidental sem reiniciar o caso inteiro.

Ansiedade e pressa motoras se reforçam: o dedo erra mais quando o relógio vermelho pisca. Há eco com discussões de ansiedade de prova: pressão sem necessidade pedagógica mede estresse, não só conhecimento. No estudo formativo, generosidade de tempo é desenho, não "moleza".

Metacognição também entra depois do caso: "errei o toque ou errei a hipótese?". Separar os dois evita culpar o raciocínio por falha de interface. O post sobre metacognição na Medicina aprofunda o hábito; do ângulo motor, a pergunta pós-caso deve incluir a hipótese de erro de alvo.

Teclado, switch e entrada alternativa

Teclado completo é o teste de ouro da operabilidade. Se a versão web do app de ensino não permite Tab entre controles, Enter para ativar, Escape para fechar e setas em listas, quem usa teclado físico, teclado em tela ampliado, emulador de mouse por cabeça ou switch fica fora. O critério de teclado da WCAG pede que toda funcionalidade seja operável por teclado sem exigir tempo específico por tecla, salvo exceções essenciais de caminho (W3C, Keyboard). Evite armadilha de teclado: o foco não pode ficar preso num widget.

Switch access (varredura linear ou por ponto) depende de elementos focáveis em ordem lógica. Interfaces desenhadas só em canvas com um único retângulo clicável quebram a varredura: o switch "vê" a tela inteira como um botão. Em apps de casos, cada pista, cada hipótese e cada ação de envio precisa ser um controle discreto nomeado. Teste com as ferramentas nativas de switch do sistema operacional móvel antes de publicar um modo novo.

Outras entradas alternativas comuns na prática:

• Trackball e mouse adaptado: precisam de clique simples, não de arraste contínuo.
• Controle ou gamepad: útil quando botões físicos são maiores que alvos de toque.
• Entrada por voz para texto da hipótese: complementar, não único caminho se o ambiente for ruidoso.
• Pedal ou botão externo: mapeável a "próxima pista" e "enviar" quando o SO permitir.
• Modo de aceitação de toque com atraso (dwell): o app não deve cancelar o foco se o dedo hesitou meio segundo.

Percepção do ambiente de aprendizagem por estudantes com deficiência melhora quando o programa de acesso é visível e confiável; barreiras estruturais e cultura de divulgação ainda pesam (Moreland et al., 2025). No produto educacional, o equivalente é documentar caminhos de entrada (teclado, switch, toque ampliado) de forma encontrada sem caça ao tesouro. A página de acessibilidade do site é o lugar institucional para orientar; o app em si precisa cumprir o que a página descreve, sem transformar o post em auditoria de declaração.

Princípios práticos em tabela

A tabela abaixo resume o mapeamento barreira e resposta. Use-a ao revisar um app de ensino clínico, um caso jogável ou uma atividade em tablet antes de publicar.

Barreira motora	O que o estudante sente	Resposta de desenho
Alvo pequeno ou colado	Aciona o vizinho; erra o envio	Alvo amplo; margem entre ações
Gesto de caminho obrigatório	Não completa pinça ou curva	Botão ou toque equivalente
Arrastar-e-soltar só	Solta no lugar errado	Selecionar e confirmar em dois toques
Timeout curto	Perde o progresso ao hesitar	Ritmo próprio; aviso antes de expirar
Sem teclado completo	Switch e teclado param no meio	Tab, Enter, Escape; ordem de foco
Canvas sem controles discretos	Varredura vê um único bloco	Controles nomeados e focáveis
Ação destrutiva ao lado da confirmação	Apaga o caso sem querer	Separar; pedir confirmação; desfazer

Esses princípios alinham-se a orientação W3C de alvo, gesto e teclado, e a práticas de jogos acessíveis. Não substituem teste com usuários que usam switch, trackball ou uma só mão, mas evitam os erros mais caros antes do primeiro playtest. Revisões de padrões técnicos em escolas médicas novas mostram que linguagem inclusiva ainda é desigual (Stauffer et al., 2022); o mesmo vale para apps: a intenção inclusiva precisa aparecer no controle concreto, não só no texto institucional.

O feedback útil em casos clínicos também tem ângulo motor: se o único retorno de erro for um flash de 200 ms sobre um ícone minúsculo, quem errou o toque nem vê o critério. Feedback estável em texto, com tempo para ler e com botão amplo de "entendi", fecha o ciclo sem mira olímpica.

Como o NEXO entra

No NEXO, o fluxo do caso do dia apresenta casos fictícios com apresentação clínica real e até seis pistas progressivas. Interagir com pistas e com o campo de hipótese é o coração do ensaio. Do ângulo motor, o desenho inclusivo significa: alvos operáveis, caminhos sem gesto obrigatório de pinça, tempo que não pune hesitar, e equivalência entre toque e teclado na web. Nenhuma frase aqui afirma eficácia; descreve o tipo de interação que um jogo diário de diagnóstico precisa tornar acessível.

Recursos do ecossistema ligados ao estudo: NEXO Researcher para aprofundar temas; NEXO Closer quando o foco é fechar lacunas; limites de uso em economia. A página de acessibilidade reúne orientações gerais da plataforma. O texto o que é o NEXO situa o jogo no mapa de ensino clínico.

Como usar o caso do dia com olhar de acessibilidade motora (sem promessa de resultado):

• Prefira tablet com teclado ou desktop se o toque fino cansar; o fluxo web precisa permanecer operável por teclado.
• Aumente o zoom do sistema operacional se os alvos parecerem pequenos; teste se o layout refluí sem esconder o botão de envio.
• Se um toque acidental pular pista ou fechar diálogo, pause e use desfazer ou reabrir com calma; não transforme o erro motor em "pressa cognitiva".
• Ensaie a hipótese em texto curto antes de mirar o envio, para separar raciocínio de precisão de toque.
• Se dor, fadiga ou exclusão pela interface forem intensas, pause e busque a ajuda necessária.

Comparações honestas: o NEXO concentra pistas e envio de hipótese em um fluxo único; simuladores com muitos gestos de manipulação 3D e bancos com dezenas de microalvos pedem mais precisão motora. A escolha do dia depende do objetivo. Para treinar diferencial com poucas pistas, o formato enxuto cabe. Para treinar habilidade manual em procedimento, o laboratório de simulação é outro espaço. O princípio compartilhado: meça raciocínio, não a tolerância a alvos minúsculos.

Quem cria casos para turmas (preceptores, monitores, grupos de estudo) pode aplicar a tabela acima mesmo fora da plataforma: botões grandes em slides interativos, alternativas a arrastar, tempo flexível na atividade formativa e devolutiva com critério. O NEXO ilustra um caminho; o padrão de acessibilidade motora vale para qualquer caso jogável em tablet.

Para preceptores que usam o caso do dia em grupo: permita que cada estudante registre a hipótese no próprio ritmo e no próprio dispositivo adaptado, e só então discuta em voz alta. Evite uma única estação com mouse fino compartilhado como único meio de participação. O conteúdo clínico permanece; o protocolo de uso fica mais inclusivo.

Antes de publicar ou de jogar um caso com olhar de acessibilidade motora, passe por esta lista:

• Os botões críticos têm alvo amplo e margem do vizinho?
• Toda ação de gesto tem equivalente de toque simples ou teclado?
• O fluxo web completa com Tab e Enter, sem armadilha de foco?
• Há modo sem timeout punitivo?
• Controles são discretos e focáveis para switch?
• Ações destrutivas estão separadas e são reversíveis?
• O feedback de erro permanece na tela tempo suficiente e em área ampla?
• Testei com toque grosseiro e com teclado só?

Se algum item falhar, corrija o desenho antes de atribuir o erro ao estudante. Depois, treine com um caso completo no fluxo real.

Jogue o caso do dia.

Perguntas frequentes

Acessibilidade motora é o mesmo que WCAG?

Não exatamente. WCAG traz critérios técnicos (alvo, gesto, teclado) que este post usa como princípios. O foco aqui é apps e jogos de ensino clínico, não um guia normativo completo de software médico.

Alvos grandes não deixam a interface "infantil"?

Não. Alvos generosos são padrão em produtos de saúde e em jogos acessíveis. Você muda a área ativa e o espaçamento, não o rigor clínico do caso.

Arrastar-e-soltar pode ficar se houver alternativa?

Sim. Mantenha o arraste como atalho opcional se quiser, desde que selecionar e confirmar com toques ou teclado faça a mesma tarefa.

Switch access exige app nativo?

Não necessariamente. Exige controles focáveis e ordem lógica. Canvas único costuma falhar; botões e campos reais costumam funcionar com as ferramentas do sistema.

Isso só importa para quem tem deficiência permanente?

Não. Tala, dor, fadiga, uso com uma mão no plantão e tremor situacional produzem barreiras parecidas. Desenho inclusivo beneficia a maioria.

Como o NEXO se encaixa sem virar promessa de resultado?

Como ambiente de ensaio com pistas e hipótese em tela. Use-o para praticar o hábito de raciocínio em formato operável; não como prova de destreza nem como tratamento.

Referências

1. W3C. Understanding SC 2.5.5 Target Size (Enhanced). https://www.w3.org/WAI/WCAG22/Understanding/target-size-enhanced
2. W3C. Understanding SC 2.5.8 Target Size (Minimum). https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum
3. W3C. Understanding SC 2.5.1 Pointer Gestures. https://www.w3.org/WAI/WCAG22/Understanding/pointer-gestures
4. W3C. Understanding SC 2.1.1 Keyboard. https://www.w3.org/WAI/WCAG22/Understanding/keyboard
5. W3C. Mobile Accessibility: How WCAG 2.0 and Other W3C/WAI Guidelines Apply to Mobile. https://www.w3.org/TR/mobile-accessibility-mapping/
6. W3C Mobile Accessibility Task Force. M002 Providing adequate touch target size. https://w3c.github.io/Mobile-A11y-TF-Note/Techniques/M002
7. Parhi P, Karlson AK, Bederson BB. Target size study for one-handed thumb use on small touchscreen devices. MobileHCI. 2006. DOI 10.1145/1152215.1152260.
8. Guerreiro T, et al. Towards accessible touch interfaces. ASSETS. 2010. DOI 10.1145/1878803.1878809.
9. Zazove P, et al. U.S. Medical Schools' Compliance With the Americans With Disabilities Act: Findings From a National Study. Acad Med. 2016. PMID 26796093.
10. McKee M, et al. Medical Schools' Willingness to Accommodate Medical Students with Sensory and Physical Disabilities. AMA J Ethics. 2016. PMID 27780023.
11. Meeks LM, et al. National Prevalence of Disability and Clinical Accommodations in Medical Education. J Med Educ Curric Dev. 2020. PMID 33178890.
12. Meeks LM, et al. The Performance and Trajectory of Medical Students With Disabilities. Acad Med. 2022. PMID 34817411.
13. Marzolf BA, et al. Call to Action: Eliminate Barriers Faced by Medical Students With Disabilities. Ann Fam Med. 2022. PMID 35879081.
14. Kezar LB, et al. Leading Practices and Future Directions for Technical Standards in Medical Education. Acad Med. 2019. PMID 30398992.
15. Stauffer C, et al. Technical Standards from Newly Established Medical Schools: A Review of Disability Inclusive Practices. J Med Educ Curric Dev. 2022. PMID 35036566.
16. Moreland CJ, et al. Perceptions of the Learning Environment Among Medical Students With Disabilities and the Impact of Program Access. Acad Med. 2025. PMID 40344596.
17. Game Accessibility Guidelines. Full list. https://gameaccessibilityguidelines.com/full-list/