Usei a Web por um dia com apenas um teclado

Este artigo faz parte de uma série em que tento usar a web sob várias restrições, representando um determinado demográfico de usuário. Espero aumentar o perfil das dificuldades enfrentadas por pessoas reais, que são evitáveis ​​se projetarmos e desenvolvermos de uma forma que seja simpática às suas necessidades. Da última vez, usei a web por um dia sem JavaScript. Hoje, me forcei a navegar na web usando apenas meu teclado.

Quem usa o teclado para navegar?

Em geral, existem três tipos de usuários de teclado:

• Usuários com mobilidade reduzida que lutam para usar um mouse,
• Usuários com deficiência visual que não conseguem ver elementos clicáveis ​​na página,
• Usuários avançados que podem usar um mouse, mas acham mais rápido usar um teclado.

De quantos usuários estamos falando?

Eu vasculhei a web em busca de estatísticas sobre o uso do teclado e não consegui encontrar nada. A sério. Nenhum estudo.

A maioria dos sites de orientação de acessibilidade de teclado simplesmente assume que “muitos usuários” dependem de teclados para se locomover. Qualquer pessoa que tente obter um número aproximado geralmente é dispensada com “as estatísticas não importam – seu site deve ser acessível, ponto final”.

Sim, é verdade que a escala de uso sem mouse é um ponto discutível. Se você puder fazer uma mudança que capacite até mesmo um usuário, é uma mudança que vale a pena fazer. Mas há muitas estatísticas disponíveis sobre coisas como daltonismo, uso do navegador, velocidades de conexão e assim por diante - por que a cautela em torno das estatísticas do teclado? Se os números são tão prevalentes quanto os sites parecem sugerir, certamente tê-los permitiria um caso de negócios mais forte e facilitaria a defesa da acessibilidade do teclado para seus stakeholders.

A coisa mais próxima de um número que posso encontrar é um artigo no PowerMapper, que sugere que 7% dos adultos em idade ativa nos EUA, Reino Unido e Canadá têm “dificuldades severas de destreza”. Isso os tornaria “improváveis ​​de usar um mouse e, em vez disso, confiar no teclado”.

Os usuários com deficiências visuais graves usam um software chamado leitor de tela, que é um software que lê o conteúdo na tela como fala sintetizada. Assim como os usuários com visão, os usuários sem visão querem poder escanear as páginas em busca de informações interessantes, de modo que o leitor de tela tenha atalhos de teclado para navegar por meio de títulos e links e se baseie em elementos focalizáveis ​​do teclado para interação.

“As pessoas cegas precisam de acesso total ao teclado. Período."

— David Macdonald, coeditor de Using WAI ARIA in HTML5

Esses mesmos usuários também têm leitores de tela em seus dispositivos móveis, onde eles usam gestos de furto em vez de pressionar o teclado para 'tabular' o conteúdo. Portanto, embora não estejam literalmente usando um teclado, eles exigem que o site seja acessível por teclado, pois a tecnologia do leitor de tela se conecta à mesma ordenação de guias e ouvintes de eventos como se estivessem usando um teclado. Vale a pena notar que apenas cerca de dois terços a três quartos dos usuários de leitores de tela são cegos, o que significa que o restante pode usar uma combinação de técnicas de leitura de tela e ampliação.

2,3% dos americanos (de todas as idades) têm deficiência visual, nem todos necessariamente justificariam o uso de um leitor de tela. Em 2016, Addy Osmani estimou o uso real do leitor de tela em cerca de 1 a 2%. Se considerarmos esses usuários com nossos usuários com mobilidade reduzida e nossos usuários avançados, o uso do teclado representa uma porcentagem considerável do público global. Portanto, se preocupar com a acessibilidade do teclado não é apenas fazer a coisa certa moralmente (e legalmente – muitos países exigem que os sites sejam acessíveis por lei), mas também faz sentido para os negócios.

Com tudo isso em mente, qual é o estado da web hoje? Hora de descobrir!

O experimento

O que todo mundo faz quando tem um dia inteiro de trabalho intimidador pela frente? Procrastinar! Fui para o youtube.com. Eu tinha um vídeo específico em mente e fiquei grato ao descobrir que não precisaria entrar na caixa de pesquisa principal, pois ela é focada no carregamento da página por padrão.

O atributo autofocus

Eu assumi que isso seria focado com JavaScript no carregamento da janela, mas na verdade é tratado pelo navegador com um atributo autofocus no elemento de entrada.

Como usuário de teclado com visão, achei isso extremamente útil. Como um usuário cego de leitor de tela, não tenho certeza se gostaria ou não. O consenso parece ser que o uso criterioso do autofocus é aceitável, nos casos em que o único propósito da página é interagir com um formulário (por exemplo, página de destino do Google ou formulário de contato do site).

Estilos de foco padrão

Eu procurei por algum Whose Line Is It Anyway? bondade, e não pude deixar de notar que o YouTube não havia definido nenhum estilo :focus personalizado, em vez disso, confiando no estilo nativo do navegador para indicar visualmente quais elementos eu estava navegando.

Sempre tive a impressão de que nem todos os navegadores definem seu próprio estado :focus , então você precisa definir seu próprio estilo personalizado. Resolvi testar isso e ver quais navegadores negligenciam a implementação de um estilo padrão, mas para minha surpresa, não consegui encontrar nenhum. Cada navegador que testei tinha sua própria implementação nativa de :focus , embora cada um variasse em estilo.

Eu até voltei bastante no tempo:

Se você quiser ver mais, há uma coleção abrangente de capturas de tela de diferentes elementos nos estados nativos do navegador.

O que isso me diz é que você pode razoavelmente supor que todo navegador vem com algum estilo básico de :focus . Não há problema em deixar o navegador fazer o trabalho. O que você está arriscando é a inconsistência: todos os navegadores estilizam elementos de maneira sutilmente diferente, e alguns são tão sutis que não são particularmente acessíveis visualmente.

É possível desabilitar os estilos de foco padrão do navegador — definindo outline: none em seu elemento — mas você deve fazer isso apenas se implementar sua própria alternativa de estilo. Heydon Pickering recomenda essa abordagem, citando os padrões pouco claros ou feios usados ​​por alguns navegadores. Se você decidir implementar seus próprios estilos, certifique-se de usar mais do que apenas cor como modificador: Adicione um contorno ou um sublinhado ou algum outro indicador visual para dar suporte aos usuários com daltonismo.

Muitos sites suprimem os estilos de foco padrão, mas não fornecem estilos personalizados, levando a experiências inacessíveis. Se o seu site estiver usando a redefinição de CSS de Eric Meyer, ele pode ficar inacessível; esse arquivo comumente usado redefine os estilos :focus padrão, mas instrui o desenvolvedor a escrever seus próprios, e muitos não conseguem identificar as instruções.

Algumas pessoas argumentam que pode ser confuso para o usuário se você desabilitar os padrões do navegador, pois eles perdem a capacidade visual do estado de foco ao qual estão acostumados e, em vez disso, precisam aprender como é o estado de foco do seu site. Por outro lado, alguns argumentam que os padrões do navegador são feios ou até confusos para o usuário que não usa teclado.

Por que confuso? Bem, confira este formato de carrossel animado na BBC. Existem dois botões de navegação – próximo e anterior – e é útil para o usuário do teclado que o foco permaneça neles durante toda a narrativa. Mas para o usuário do mouse, pode ser bastante confuso que o botão clicado ainda esteja 'focado' depois de mover o cursor para longe.

O seletor CSS :focus-visible

Se você quer o melhor dos dois mundos, você pode explorar a pseudoclasse CSS4 :focus-visible , que permitirá que você forneça diferentes estilos de foco dependendo do contexto. O estilo :focus-visible visa apenas elementos que foram focados com o teclado, não com o clique do mouse. Isso é super legal, embora atualmente seja suportado nativamente apenas no Firefox. Ele pode ser ativado no Chrome ativando o sinalizador 'Recursos experimentais da plataforma da Web'.

Vídeos do YouTube e acessibilidade do teclado

O YouTube faz um ótimo trabalho com seu player de vídeo - todas as partes do player são navegáveis ​​pelo teclado. Eu gosto de como os controles de volume deslizam para fora quando você desvia o foco do ícone de mudo, em contraste com o deslizamento ao passar o mouse sobre o ícone de mudo.

O que eu não gostei foi que rótulos úteis, como o texto 'Silenciar' que aparece ao passar o mouse sobre o ícone mudo, não são mostrados em foco.

Outra área que decepciona o YouTube é que ele suprime alguns estilos de foco. Aqui estava eu ​​tentando guiar para o botão 'Mostrar mais'.

Eu acidentalmente passei direto pelo botão 'Mostrar mais' porque não consegui ver nenhum estilo :focus aplicado, seja personalizado ou nativo. Eu descobri que o estilo nativo estava sendo substituído por outline-width :

Acessibilidade do teclado do GitHub

Certo, horário de trabalho. Onde é melhor trabalhar do que na casa do código, github.com?

Percebi três coisas sobre o GitHub: uma ótima, uma razoável e uma ruim.

Primeiro, o bom.

Link 'Pular para o conteúdo'

O GitHub oferece um link Skip to content , que pula o menu principal.

Se você pressionar ENTER enquanto estiver focado no link 'Skip to content', você pula todos os itens de menu na parte superior da página e pode começar a guiar dentro da área principal do conteúdo, economizando tempo ao navegar. Este é um padrão de acessibilidade comum que é super útil para usuários de teclado e leitor de tela. Cerca de 30% dos usuários de leitores de tela usarão um link para pular se você fornecer um.

Alternativamente, alguns sites optam por colocar o conteúdo principal primeiro na ordem de leitura, acima da navegação. Essa abordagem saiu de moda, pois quebra a diretriz de fazer com que seu conteúdo DOM corresponda à ordem visual (a menos que sua navegação apareça visualmente na parte inferior). E embora essa abordagem signifique que não precisamos de um link 'Pular navegação', provavelmente queremos um link 'Pular para navegação' em seu lugar.

Guia para ver o conteúdo

Um recurso que notei funcionar de maneira diferente da versão 'sem teclado' foi o indicador de quebra de código.

Usando o mouse, você pode clicar na barra colorida abaixo de qualquer repositório para ver uma divisão proporcional das diferentes linguagens de programação usadas no repositório. Usando o teclado, você não pode realmente navegar para a barra colorida, mas os idiomas são exibidos automaticamente quando você passa o final da meta-informação.

Isso não parece realmente necessário - eu ficaria feliz em ir para a barra colorida e pressionar ENTER - mas esse comportamento diferente também não causa nenhum dano.

Links invisíveis

Uma coisa problemática que encontrei foi que havia um link “invisível” depois de passar pela minha foto de perfil no canto superior direito. Minha ordem de guias seria guiada para a imagem, depois para este link invisível e depois para o botão 'Assistir' no repositório (veja o gif abaixo). Eu não tinha ideia do que o link invisível fazia, então quando reconheci que estava nele, apertei ENTER e fui imediatamente desconectado!

Em uma inspeção mais detalhada, parece que naveguei para um formulário “somente leitor de tela” ( sr-only é um nome de classe de leitor de tela comum) que tem o recurso 'Sair'.

Este link de saída é um acréscimo ao link de saída no menu suspenso do seu perfil:

Não tenho certeza de que dois links de saída HTML separados sejam necessários, pois um usuário de leitor de tela deve ser capaz de acionar a lista suspensa e navegar até o link de saída principal. E se quisermos manter o link separado, eu recomendaria aplicar um estilo :focus ao conteúdo do leitor de tela para que os usuários com visão não acionem acidentalmente o logout!

Como fazer um atalho 'Pular para o conteúdo'

Então, como recriamos o atalho 'Pular para o conteúdo'? É bastante simples de implementar, mas pode ser enganosamente complicado para ficar perfeito - então aqui está o que considero ser o Santo Graal das soluções de links de salto.

'Ignorar link' é alternativamente chamado de 'Ignorar navegação', 'Ignorar navegação principal', 'Ignorar links de navegação' ou 'Ignorar conteúdo principal'. 'Pular para o conteúdo principal' é provavelmente o mais claro, pois informa para onde você está navegando, em vez do que você está pulando.

O link de atalho deve aparecer logo após a tag de abertura <body> . Ele pode aparecer mais tarde no DOM, mesmo após o rodapé, desde que você tenha um tabindex="1" para forçá-lo a se tornar o primeiro elemento interativo na ordem de tabulação. No entanto, usar tabindex com um número maior que zero geralmente é uma prática ruim e geralmente resultará em um aviso ao usar ferramentas de validação como o Lighthouse.

Não é infalível confiar em tabindex , pois você pode ter mais de um link com tabindex="1" . Nesses casos, é o primeiro link que obterá o foco da guia primeiro, não os links posteriores. Leia mais sobre como usar o atributo tabindex aqui, mas lembre-se de que é sempre melhor mover fisicamente seu link para o início do DOM por segurança.

 <a class="screen-reader-shortcut" href="#main-content"> Skip to main content </a>

O link 'Pular para o conteúdo principal' tem uso limitado para usuários com visão, que já podem pular a navegação usando os olhos. Assim, enquanto alguns sites mantêm o link de pular visível o tempo todo, a convenção hoje em dia é manter o link oculto até que você tabule nele, momento em que ele fica em foco e ganha o estilo aplicado pelo pseudoseletor :focus .

 .screen-reader-shortcut { position: absolute; top: -1000em; } .screen-reader-shortcut:focus { position: fixed; top: 0; left: 0; z-index: 999; /* ...and now any nice styling you want to apply... */ padding: 1em; background-color: rgb(114, 105, 105); color: white; text-decoration: none; }

Então, o que estamos realmente pulando? O que é #main-content ? Na verdade, pode ser qualquer coisa:

1. Conteúdo embutido
   ou seja, o id da sua tag h1 : <h1 id="main-content"> .
2. Recipiente
   por exemplo, o id do contêiner em torno de seu conteúdo principal, como <main id="main-content"> .
3. Âncora de irmão
   Você pode vincular a uma tag nomeada logo acima de seu conteúdo principal, por exemplo, <a name="main-content"></a> . Essa abordagem geralmente é descrita em tutoriais mais antigos — eu não a recomendaria hoje em dia.

Para compatibilidade máxima em todos os leitores de tela, recomendo vincular à tag h1 . Isso é para garantir que o conteúdo seja lido assim que você usar o link para pular. A vinculação a contêineres pode levar a um comportamento engraçado, por exemplo, o leitor de tela começar a ler todo o conteúdo dentro do contêiner.

Seu #main-content também deve ter um tabindex de -1 , para garantir que seja programável. Caso contrário, alguns leitores de tela podem não obedecer ao link de pular.

 <h1 tabindex="-1">This is the title of the page</h1>

Uma última consideração: suporte a navegadores legados. Se você tiver usuários suficientes no IE9 ou abaixo, talvez seja necessário aplicar uma pequena correção de JavaScript aos links de ignorar para garantir que o foco realmente mude conforme o esperado e que seus usuários ignorem a navegação com êxito.

Por que estamos reinventando a roda?

Parece loucura que, como desenvolvedores da web, tenhamos que implementar esse hack de 'saltar navegação' em todos os nossos sites como regra. Você pensaria que poderíamos deixar os padrões fazerem o trabalho.

Desde HTML5, temos elementos semânticos como <main> , <nav> e <header> . Antes disso, tínhamos referências ARIA como role="main" , role="navigation" e role="banner" respectivamente. No cenário atual da web, as melhores práticas determinam que você precisa de ambos, ou seja, <main role="main"> , que é uma violação horrível do princípio DRY, mas lá vamos nós.

Com toda essa riqueza semântica, você esperaria que os navegadores começassem a oferecer suporte nativo à navegação através dessas áreas de referência, por exemplo, expondo um atalho de teclado para os usuários acessarem diretamente a seção <main> de uma página da web. Sem essa sorte - não há suporte nativo no momento. Sua melhor aposta é usar a Landmark Navigation via extensão de teclado para Chrome, Opera ou Firefox.

Os usuários de leitores de tela, no entanto, podem começar a navegar diretamente para essas regiões de referência. Por exemplo, no VoiceOver no Mac, você pode pressionar CTRL + ALT + U para abrir o Menu de Marcos e ir para o marco 'principal', que é um atalho rápido e consistente para acessar o conteúdo principal. Claro, isso depende de sites marcando seus documentos corretamente.

Aqui está um bom ponto de partida para o seu site se você quiser que ele seja navegável por meio de regiões de referência:

 <body> <header role="banner"> <!-- Logo and things can go here --> <nav role="navigation"> <!-- Site navigation links go here --> </nav> </header> <main role="main"> <!-- Main content lives here - including our h1 --> </main> <footer role="contentinfo"> <!-- Copyright statement, etc --> </footer> </body>

Toda essa marcação é um trabalho sedento. Hora de um café.

Café Pacto

Lembro-me de ver um flyer para o pactcoffee.com… vamos dar uma olhada!

Banner de cookies

O banner 'Política de cookies' é uma das primeiras coisas que você nota aqui, e descartá-lo é quase um reflexo instintivo para o usuário de mouse com visão. Alguns usuários de leitores de tela podem não se importar com isso (se você é cego, não saberia que está lá até chegar), mas como usuário com visão, você o vê, quer matá-lo e, no caso de neste site, você precisa passar por TODOS OS OUTROS LINKS antes de poder dispensá-lo.

Usei a extensão de acessibilidade ChromeLens para rastrear a ordem de tabulação da página:

Isso pode ser corrigido movendo o aviso para a parte superior do documento (ele ainda pode ser ancorado visualmente na parte inferior com CSS) ou adicionando um tabindex="1" ao botão OK. Sugiro aplicar essa correção a qualquer conteúdo em que a expectativa seja de que o usuário queira descartá-lo.

Mais links invisíveis

Como no GitHub, encontrei-me acessando um elemento fora da tela cujo propósito não estava claro. Acabou sendo uma alternância 'Ver menos...' que fica atrás do cartão 'Ver mais...'.

Isso ocorre porque a área 'oculta' não está realmente oculta, é apenas girada 180 graus, usando:

 transform: rotateY(180deg);

…o que significa que o botão 'Ver menos…' ainda faz parte da ordem de tabulação. Isso pode ser corrigido aplicando um display: none até que o aplicativo esteja pronto para acionar a rotação:

Café pedido. Agora é hora de continuar com minha pesquisa.

Mundo de TI

Eu estava fazendo algumas pesquisas para este artigo e me deparei com um experimento semelhante ao meu; Kevin Purdy navegou na web por sete dias usando apenas o teclado. Acho irônico que não consegui ler seu artigo sob as mesmas restrições!

O problema era um banner de cookie de página inteira, exigindo que eu “atualize as configurações de privacidade” ou aceite as configurações de cookie padrão. Não importa quantas vezes eu abasse, não conseguia focar no banner do cookie e descartá-lo.

Eu cavei no código-fonte para descobrir o que estava acontecendo. Por um momento, pensei que poderia ser nosso arqui-inimigo, a propriedade CSS de outline .

Inspecionando o link “Atualizar configuração de privacidade”, posso ver um outline: 0 como eu suspeitava. Então, talvez eu esteja focando nos botões, mas não há feedback visual quando isso acontece?

Tentei definir o estado como :hover para ver se estava perdendo algum estilo como usuário de teclado:

Com certeza, o link ficou com uma cor laranja bonita e óbvia ao passar o mouse - algo que nunca vi em foco:

Viva! Quebrou! Eu nunca vi o estado :focus porque o estilo personalizado estava sendo aplicado apenas em :hover . Devo ter passado pelos botões sem nem perceber, certo?

Errado. Mesmo quando hackeei o CSS localmente, não consegui ver nenhum estilo de foco, o que significa que não estava chegando ao ponto de entrar no modal do cookie. Então percebi… o link estava faltando um atributo href :

Esse foi o verdadeiro culpado. O outline: 0 não era o problema - o navegador nunca iria guiar para o link porque não era um link válido!

Da especificação HTML 5.2:

O destino do(s) link(s) é dado pelo atributo href, que deve estar presente e deve conter um URL válido não vazio potencialmente cercado por espaços. Se o atributo href estiver ausente, o elemento não define um link.

Dar aos links um atributo href — mesmo que seja apenas # — os tornaria links válidos e os adicionaria à ordem de tabulação da página.

Curiosamente, mais tarde naquele dia, me enviaram um artigo no PC World para ler e encontrei exatamente o mesmo problema.

Parece que ambos os sites estavam usando a mesma Plataforma de Gerenciamento de Consentimento (CMP). Pesquisei um pouco e deduzi que isso estava afetando vários sites de propriedade da mesma empresa e, desde então, os contatei diretamente com uma correção sugerida.

Cinético

Minha torneira da cozinha está vazando e eu estava querendo substituí-la. Eu vi um anúncio no jornal local para kinetico.co.uk, então pensei em dar uma olhada.

Não consegui navegar até a seção 'Torneiras da cozinha', pois o link estava escondido atrás de um link pai 'Sal e cartuchos' que mostra apenas seus links filhos ao passar o mouse. É interessante que o site seja inovador o suficiente para fornecer um link 'Skip to Content' (visto brevemente no gif acima), mas não conseguiu criar um menu acessível!

Aqui é onde o menu dá errado - ele só mostra o submenu quando o item do menu pai está sendo passado sobre:

Consertar é mais fácil falar do que fazer. Na maioria dos casos, você pode simplesmente “dobrar” seu seletor para aplicar ao foco também:

 li:hover .nav_sub_menu, li:focus .nav_sub_menu { }

Mas isso não funciona neste caso porque, embora o elemento <li> seja passível de passar o mouse, ele não é focalizável. É o link dentro do <li> que é focalizável. Mas o submenu não está dentro do link, está ao lado dele, então precisamos aplicar o seletor irmão para mostrar o submenu quando o link estiver em foco.

 li:hover .nav_sub_menu, a:focus + .nav_sub_menu { }

Esse ajuste significa que podemos ver nosso submenu quando guiamos para o item de menu pai no teclado. Mas o que acontece quando você tenta entrar no submenu?

Quando guiamos a partir do item de menu pai, o foco muda para o primeiro link no menu filho conforme o esperado. Mas isso afasta o foco do link do menu pai, o que significa que o submenu fica oculto e os itens do menu filho são removidos da ordem de tabulação novamente!

Este é um problema que pode ser resolvido com :focus-within , que permite aplicar estilo a um elemento pai se ele ou qualquer um de seus elementos filho tiver o foco. Então, neste caso, temos que triplicar:

 li:hover .nav_sub_menu, /* hover over parent menu item, show child menu */ a:focus + .nav_sub_menu, /* focus onto parent menu item, show child menu */ .nav_sub_menu:focus-within { /* focus onto child menu item, keep showing child menu */ }

Nosso menu agora é totalmente acessível pelo teclado através de CSS puro. Eu amo soluções CSS criativas, mas um aviso aqui: muitas soluções “somente CSS” caem quando se trata de navegação pelo teclado. Evitar o JavaScript não torna necessariamente um site mais acessível.

Na verdade, um menu baseado em JS pode ser um grito melhor neste caso, pois o suporte do navegador para esta solução ainda é bastante ruim. :focus-within atualmente só pode ser usado no Chrome, Firefox e Safari. Mesmo no Chrome, achei incompatível com o display: none lógica usada para mostrar/ocultar o menu filho; Eu tive que esconder meus itens de menu definindo opacity: 0 em vez disso.

OK, terminei o dia. Agora é hora de relaxar com um pouco de mídia social.

o Facebook

O Facebook faz um trabalho incrível aqui, oferecendo uma masterclass em acessibilidade de teclado.

No primeiro toque de TAB , um menu oculto é aberto, fornecendo atalhos para as seções mais populares da página atual e links para outras páginas populares.

Quando você percorre as seções da página usando as teclas de seta, essas seções são destacadas visualmente para que você possa ver para onde você estaria tabulando.

O recurso mais útil é que o Facebook fornece um atalho OPT + / (ou ALT + / ) para voltar ao menu a qualquer momento, fazendo uso do atributo aria-keyshortcuts.

 <div class="a11y-help"> Press opt + / to open this menu </div> <div aria-label="Navigation Assistant" aria-keyshortcuts="Alt+/" role="menubar"> <a class="screen-reader-shortcut" tabindex="1" href="#main-content"> Skip to main content </a> </div>

Ao contrário do link 'pular para o conteúdo principal', que é construído em cima da tecnologia de ancoragem nativa e “simplesmente funciona”, o atributo aria-keyshortcuts requer que o autor implemente todo o comportamento do teclado, então você terá que escrever alguns JavaScript personalizado se você quiser usar isso.

Aqui estão alguns JS que ocultam e mostram a área da menubar de menus, que é um ponto de partida útil:

 const a11yArea = document.querySelector('*[role="menubar"]'); document.addEventListener('keydown', (e) => { if (e.altKey && e.code === 'Slash') { a11yArea.style.display = a11yArea.style.display === 'block' ? 'none' : 'block'; } });

Resumo

Este experimento tem sido uma mistura de ótimas experiências de teclado e ruins. Eu tenho três tópicos principais.

Mantenha-o elegante

De longe , o problema de acessibilidade de teclado mais comum que enfrentei hoje é a falta de estilo de foco para elementos tabbable. Suprimir estilos de foco nativos sem definir nenhum estilo de foco personalizado torna extremamente difícil, até mesmo impossível, descobrir onde você está na página. Remover o contorno é uma gafe tão comum que existe até um site dedicado a isso.

Garantir que o estilo de foco nativo ou personalizado seja visível é a coisa mais impactante que você pode fazer na área de acessibilidade do teclado, e geralmente é uma das mais fáceis; um caso simples de dobrar seletores em seu estilo :hover existente. Se você fizer apenas uma coisa depois de ler este artigo, deve procurar por outline: 0 e outline: none em seu CSS.

Semântica é a chave

Quantas vezes você tentou abrir um link em uma nova guia, apenas para que sua janela atual fosse redirecionada? Isso acontece comigo de vez em quando, e por mais irritante que seja, tenho sorte de ser um dos únicos problemas de usabilidade que costumo enfrentar quando uso a web. Esses problemas surgem do uso indevido da plataforma.

Vamos ver esse código aqui:

 <span>Click here</span>

Um usuário capaz e com visão poderia clicar no <span> e ser redirecionado para o Google. No entanto, como este é um <span> e não um link ou um botão, ele não possui automaticamente nenhuma capacidade de foco, portanto, um teclado ou leitor de tela não teria como interagir com ele.

Os usuários de teclado são usuários dependentes de padrões, enquanto o grupo demográfico capaz e com visão é privilegiado o suficiente para poder interagir com o elemento apesar de sua não conformidade.

Use os recursos nativos da plataforma. Escreva um HTML bom e limpo e use validadores como https://validator.w3.org para capturar coisas como atributos href ausentes em suas âncoras.

O conteúdo é fundamental

Você pode ser solicitado a exibir avisos de cookies, formulários de assinatura, anúncios ou avisos de adblock.

Faça o que puder para tornar essas experiências discretas. Se você não pode torná-los discretos, pelo menos torne-os descartáveis.

Os usuários estão lá para ver seu conteúdo, não seus banners, então coloque esses elementos descartáveis ​​primeiro em seu DOM para que eles possam ser dispensados ​​rapidamente, ou volte a usar tabindex="1" se você não puder movê-los.

Por fim, ajude seus usuários a acessar seu conteúdo o mais rápido possível, implementando o Santo Graal dos links 'pular para o conteúdo principal'.

Fique atento ao próximo artigo da série, onde vou desenvolver algumas dessas técnicas ao usar um leitor de tela por um dia.