Artigo O que saber sobre as próximas alterações das WCAG
Publicados: 2022-10-07Em setembro de 2022, o W3C anunciou que a próxima versão das WCAG havia alcançado o status de recomendação de candidato. Salvo quaisquer alterações de última hora, a versão 2.2 da norma deve ser ratificada em breve. As mudanças são relativamente pequenas, mas qualquer pessoa responsável pela construção ou manutenção de um site deve saber o que está por vir.
Se você já está familiarizado com as WCAG, pode pular a visão geral e ir direto para os detalhes nerds, caso contrário, continue lendo.
O que são as WCAG e por que elas são importantes?
As Diretrizes de Acessibilidade de Conteúdo da Web (WCAG) compreendem um conjunto de critérios projetados para ajudar desenvolvedores, designers e administradores de conteúdo da Web a garantir que seus sites sejam acessíveis a pessoas com uma ampla gama de deficiências. A equipe da Iniciativa de Acessibilidade da Web do W3C é responsável pelo padrão. O W3C e o WAI compreendem um consórcio de líderes do setor e especialistas no assunto focados em tornar a web mais acessível.
As WCAG estão organizadas sob quatro princípios de acessibilidade. Esses princípios afirmam que um site deve ser perceptível, operável, compreensível e robusto. Dentro de cada um desses princípios estão as diretrizes que descrevem os objetivos básicos. Dentro de cada diretriz estão os critérios de sucesso que descrevem uma meta específica e mensurável que os desenvolvedores de sites devem cumprir para estarem em conformidade com as WCAG.
Cada critério de sucesso tem um indicador de nível de conformidade de A, AA ou AAA. Os critérios de nível A são mais facilmente atendidos, enquanto o AAA é o mais rigoroso.
Serei processado se meu site não for compatível com WCAG 2.2 AA?
A resposta definitiva é "talvez".
Nos EUA, as leis são ambíguas e a ADA não trata explicitamente de sites. Embora existam leis muito específicas sobre as acomodações que devem ser feitas em um espaço físico, a única coisa que a ADA diz que pode ser aplicada diretamente aos sites é que as "instalações devem ser acessíveis". Mesmo assim, nem todos os tribunais concordam se um site conta como uma instalação de uma empresa e em nenhum lugar há uma definição clara de "acessível". Observe que estamos falando de sites de empresas privadas e leis federais. Para sites do governo federal e alguns estaduais, existem leis que se aplicam.
Como não há uma definição clara de "acessível", recorremos às WCAG para nos dizer o que fazer ao construir ou manter um site. Nenhuma lei dos EUA recomenda especificamente qualquer versão das WCAG (ou qualquer outro padrão) para sites públicos. No entanto, esforçar-se para atender a qualquer versão dos critérios de sucesso das WCAG é uma boa meta. Deve levar a um site que seja razoavelmente acessível para todos.
Como os padrões são desenvolvidos?
Ao contrário da crença popular, o desenvolvimento de padrões não é realizado em uma torre de marfim por um seleto grupo de participantes. Embora grande parte do trabalho seja realizado por funcionários de organizações membros, grande parte do trabalho vem de especialistas convidados e outros indivíduos que são apaixonados pelo assunto e estão dispostos a dedicar seu tempo. Além disso, muitas equipes de padrões têm fóruns públicos abertos onde os membros da comunidade em geral são incentivados a participar fazendo perguntas ou levantando novos problemas.
Para as WCAG, o público pode ler e comentar sobre os padrões abrindo um novo problema, um pull request ou apenas participando das discussões existentes no repositório WCAG no Github. Ao chegar ao grupo com uma ideia, é sempre aconselhável pesquisar todos os problemas existentes e obter solicitações para garantir que sua ideia ainda não tenha sido trazida à mesa. Se você está pensando em contribuir para as WCAG com um pull request, sempre reserve um tempo para abrir um problema e discutir sua ideia primeiro. Há uma boa chance de você economizar algum trabalho desnecessário.
Contribuir para os padrões pode ser frustrante e difícil, mas também é muito gratificante. Em sua maioria, os participantes são muito acolhedores e pacientes. Se você dedicar algum tempo para pesquisar suas ideias, fazer a devida diligência e for educado e respeitoso com os outros, suas contribuições serão bem-vindas. O pior resultado possível é que você se tornará mais familiarizado com o assunto do que jamais imaginou ser possível.
O que está mudando?
Um critério de sucesso existente foi alterado nas WCAG 2.2 e nove novos critérios de sucesso foram adicionados. Aqui nos restringiremos apenas aos Níveis A e AA, pois raramente visamos AAA. Para ver todos os novos critérios, confira o artigo completo do W3C,
2.4.7 Foco Visível (A)
Este critério mudou de Nível AA para A, que é a barra mais baixa para conformidade com as WCAG. Parte da razão de sua existência é que, em um passado não tão distante, era uma prática comum para pessoas que construíam sites remover anéis de foco. Afinal, eles não faziam parte do projeto. Isso significava que os usuários que navegavam em uma página da Web com o teclado não podiam ver onde estavam em uma página. Faz sentido que esse critério seja movido para single-A porque um número tão grande de usuários depende da navegação do teclado, mesmo aqueles sem qualquer tipo de deficiência.
Todos os principais navegadores da Web exibirão anéis de foco por padrão. O principal requisito aqui é não quebrar a funcionalidade interna.
W3C – Entendendo o Foco Visível
2.4.11 Aparência do Foco (AA)
Este novo critério define algumas regras esclarecedoras sobre a visibilidade dos anéis de foco. Eles devem ter uma proporção de contraste de 3:1 com os pixels ao redor e os pixels que eles substituem. Eles também devem incluir o elemento ou subcomponente que está em foco ou ser tão grande quanto uma linha de 4 pixels de espessura ao longo da borda mais curta do elemento.
Novamente, os anéis de foco padrão do navegador geralmente atendem a esse critério. Como os usuários estão acostumados com os padrões, você deve substituí-los apenas se necessário. Um exemplo pode ser se houver contraste de cor insuficiente entre o anel de foco padrão e a cor primária da sua marca. Os navegadores normalmente usam anéis de foco azuis, portanto, se você tiver azul na paleta da sua marca, pode haver um conflito.
W3C – Entendendo a Aparência do Foco
2.4.12 Foco não obscurecido (mínimo) (AA)
Este critério afirma que o foco não deve ser completamente obscurecido pelo conteúdo gerado pelo usuário. Isso tem como objetivo evitar que conteúdo em camadas, como navegação fixa (uma barra de menu que fica na parte superior da janela enquanto o usuário rola), encobrir os indicadores de foco.
A solução mais fácil aqui é simplesmente não ter nenhum elemento pegajoso. No entanto, sites modernos fazem uso liberal de navegação fixa e CTAs flutuantes, de modo que provavelmente não é uma opção. Há alguma expectativa de que as propriedades CSS scroll-padding e scroll-margin algum dia nos permitirão definir um deslocamento que acomodará navegação fixa. Por enquanto, essas propriedades são usadas exclusivamente em elementos que aproveitam o snap de rolagem.
Isso nos deixa com JavaScript. Geralmente, nosso objetivo é usar JavaScript no navegador apenas quando necessário. Esta função StickyFix monitorará os elementos focalizáveis dentro do elemento principal e, se estiverem obscurecidos pela navegação fixa quando ganharem foco, eles serão rolados para a visualização.
Para usar esta função, basta incluí-la nos arquivos JavaScript do seu site.
/** * A minimal function that will detect if a focusable element is obscured by sticky navigation * This only works for sticky elements at the top of the page, but could be extended * @author Donovan Buck <dbuck@brandextract.com> * @param {string} selector - A valid CSS selector string for the sticky element * @param {number} offset - An additional offset for the focused element * * @see https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Selectors * @tutorial https://www.brandextract.com/Insights/Articles/Changes-to-the-Web-Content-Accessibility-Guidelines/ * @license MIT */ function stickyFix(selector, offset = 0) { // Find the height of our sticky element const sticky = document.querySelector(selector); let stickyRect = sticky.getBoundingClientRect(); let stickyHeight = stickyRect.bottom - stickyRect.top; // Select all the focusable elements within the main element const focusables = document.querySelectorAll('main button:not([disabled]), main [href], main input:not([disabled]), main select:not([disabled]), main textarea:not([disabled]), main [tabindex]:not([tabindex="-1"]):not([disabled]), main details:not([disabled]), main summary:not(:disabled)'
); // Add a listener to each focusable element focusables.forEach(focusable => { focusable.addEventListener('focus', (event) => { const targetRect = event.target.getBoundingClientRect(); if(targetRect.top < stickyHeight + offset) { window.scrollTo({ top: targetRect.top + window.scrollY - stickyHeight - offset }); } }); }); };Você pode então chamar a função:
// Wait for the document to load document.addEventListener("DOMContentLoaded", function() { stickyFix('.sticky', 24); });Compreensão do foco não obscurecido (mínimo)
2.5.7 Movimentos de Arrasto (AA)
Esse critério afirma que, se os movimentos de arrastar fizerem parte da interface do usuário, deve ser fornecido um método alternativo que permita ações simples de apontar e clicar. Um exemplo disso pode ser um formulário que permite aos usuários arrastar e soltar arquivos de seu computador no navegador para upload. Você deve garantir que um usuário também possa usar a caixa de diálogo de upload de arquivo para escolher quais arquivos devem ser carregados. Movimentos de arrastar geralmente não são necessários na maioria das interfaces de usuário do site, com essa única exceção.
Entendendo os movimentos de arrastar
2.5.8 Tamanho do Alvo (Mínimo) (AA)
Qualquer alvo de ponteiro deve ter no mínimo 24 x 24 pixels, a menos que esse alvo esteja a pelo menos 24 pixels de distância de cada alvo adjacente ou o alvo esteja em uma frase ou bloco de texto. Ao verificar um design para este critério, tenha muito cuidado para verificar os links de compartilhamento social que usam apenas ícones e todas as suas listas de navegação.
Entendendo o tamanho do alvo (mínimo)
3.2.6 Ajuda consistente (A)
Suponha que seu site contenha detalhes de contato, uma opção de autoajuda ou qualquer mecanismo de contato que apareça em várias páginas. Nesse caso, esses elementos devem aparecer na mesma ordem em relação ao conteúdo de outra página em todo o site. Isso é em grande parte uma função de um design bom e consistente, e esse critério não deve ser difícil de atender.
Entendendo a ajuda consistente
3.3.7 Autenticação Acessível (AA)
Forçar um usuário a lembrar um nome de usuário e senha pode criar um fardo indevido para pessoas com deficiências cognitivas. Por isso, os desenvolvedores da web nunca devem criar um processo de login que não permita o uso de gerenciadores de senhas ou copiar e colar. Esse critério permite métodos alternativos de autenticação, desde que não dependam de um teste de função cognitiva, como lembrar uma senha ou resolver um quebra-cabeça.
Entendendo a autenticação acessível
3.3.9 Entrada Redundante (A)
Este critério estabelece que qualquer informação inserida anteriormente pelo usuário durante o mesmo processo será preenchida automaticamente ou disponível para o usuário selecionar, em vez de ter que reinserir as informações manualmente. Obviamente, isso deve ser uma conveniência esperada para qualquer um.
Entendendo a entrada redundante
Referências
- O que há de novo no WCAG 2.2 Draft
- O repositório WCAG do W3C no Github