WCAG 2.5.7: Movimentos de Arrastar

O que Esta Regra Significa

WCAG 2.5.7 — Movimentos de Arrastar (Nível AA, introduzido na WCAG 2.2) estabelece que toda funcionalidade que utiliza um movimento de arrastar para operar deve ser realizável por meio de uma única ação de ponteiro sem arrastar, exceto quando o movimento de arrastar for essencial para a funcionalidade e não existir mecanismo alternativo.

Um movimento de arrastar é definido como uma interação em que o ponteiro é pressionado, mantido pressionado e movido para uma nova posição antes de ser liberado. Exemplos comuns incluem: ordenar itens de lista por arrastar e soltar, redimensionar painéis arrastando uma alça de divisão, usar um controle deslizante segurando e puxando o “thumb”, desenhar em um canvas e reordenar cartões de kanban. Todos esses padrões devem ter uma alternativa equivalente de ponteiro único — um mecanismo que o usuário possa acionar sem precisar manter o botão do ponteiro pressionado enquanto se move.

A restrição de ponteiro único é importante. A alternativa não precisa ser um atalho de teclado; pode ser um clique de mouse, um toque ou qualquer outra ação que envolva apenas um ponto de contato e não exija movimento contínuo enquanto pressionado. Por exemplo, um controle deslizante que permite aos usuários clicar diretamente na trilha para pular para um valor satisfaz o critério porque clicar na trilha é uma ação de ponteiro único sem arrastar.

O que conta como aprovação: Uma lista arrastável que também oferece botões de seta para cima/para baixo ou uma caixa de diálogo de mover para posição; um controle deslizante de faixa que aceita cliques em qualquer lugar da trilha; um painel redimensionável que também possui uma entrada numérica ou um recurso de duplo clique para recolher; um mapa que pode ser deslocado clicando em setas de navegação, bem como arrastando.

O que conta como reprovação: Uma lista ordenável em que a única maneira de reordenar itens é arrastando; um redimensionador de painel dividido sem recurso alternativo; um envio de arquivo que só aceita arrastar e soltar sem botão de fallback; um seletor de cor em que a única forma de selecionar um tom é arrastar sobre uma faixa de gradiente sem alternativa de entrada numérica ou de texto.

Exceção oficial: O critério permite explicitamente interfaces somente de arrastar quando o arrastar é essencial — ou seja, removê-lo mudaria fundamentalmente ou invalidaria a atividade. Um aplicativo de desenho por gestos ou um widget de captura de assinatura é um exemplo canônico. No entanto, essa exceção é intencionalmente estreita; a maioria dos padrões de UI do dia a dia (controles deslizantes, listas ordenáveis, colunas redimensionáveis) não é considerada cenário de arrastar essencial.

Por Que Isso Importa

Deficiências motoras afetam uma parte significativa da população global. De acordo com a Organização Mundial da Saúde, mais de 1,3 bilhão de pessoas no mundo — aproximadamente 16% da população global — vivem com algum tipo de deficiência, e deficiências motoras ou físicas estão entre as categorias mais comuns. Condições como tremor essencial, doença de Parkinson, lesão por esforço repetitivo, hemiplegia, lesões na medula espinhal e diferenças de membros tornam difícil ou impossível manter um botão de ponteiro pressionado enquanto se move o ponteiro com precisão.

Para um usuário com tremores nas mãos, arrastar o “thumb” de um controle deslizante de uma extremidade da trilha à outra não é apenas inconveniente — pode ser totalmente pouco confiável. O ponteiro pode escorregar, o arrasto pode ser cancelado no meio da operação ou a precisão exigida simplesmente excede o que mãos afetadas por tremor conseguem fornecer. Esses usuários frequentemente dependem de alternativas baseadas em clique, navegação por teclado ou dispositivos de acesso por varredura. Se o único caminho para um recurso é um gesto de arrastar, todo o recurso torna-se efetivamente inacessível para eles.

Cenário concreto: Considere uma página de produto de e-commerce com um filtro de faixa de preço implementado como um controle deslizante de faixa com duas alças. Um usuário com controle motor fino limitado tenta estreitar a faixa de preço, mas não consegue arrastar nenhuma das alças de forma confiável até a posição desejada — o ponteiro deriva, a alça salta para valores errados e a frustração o leva a abandonar a tarefa. Se o mesmo filtro expusesse um par de campos de texto numéricos ao lado do controle deslizante, esse usuário poderia simplesmente digitar os preços mínimo e máximo desejados e enviar. Essa única adição transforma um recurso inacessível em totalmente acessível com custo mínimo de desenvolvimento.

Além das deficiências motoras, usuários em telas sensíveis ao toque em ambientes desafiadores — segurando um corrimão no transporte público, usando luvas ou utilizando uma caneta — se beneficiam de alternativas de ponteiro único. A acessibilidade cognitiva também desempenha um papel: interações mais simples, baseadas em clique, reduzem a carga cognitiva em comparação com operações de arrastar e soltar que exigem compreender uma metáfora espacial enquanto se mantém precisão física.

Do ponto de vista de usabilidade e SEO, garantir que controles interativos sejam alcançáveis por ações simples de ponteiro tende a produzir uma arquitetura de componentes mais limpa, com melhor marcação semântica, o que por sua vez melhora a capacidade de descoberta por tecnologias assistivas e rastreadores de mecanismos de busca.

Regras Relacionadas do Axe-core

WCAG 2.5.7 é um critério de teste manual. No momento da redação, o axe-core não inclui uma regra automatizada que possa sinalizar de forma definitiva violações desse critério. A razão é fundamental para o funcionamento do critério: ferramentas automatizadas podem detectar que existe um listener de evento de arrastar em um elemento, mas não conseguem determinar com certeza se uma alternativa sem arrastar está disponível, se essa alternativa cobre a mesma funcionalidade ou se o arrastar é essencial. Esse julgamento exige avaliação humana do design de interação.

• Auditoria manual — recursos de arrastar e soltar: Testadores devem identificar todos os componentes na página que respondem a sequências mousedown/mousemove/mouseup ou equivalentes de toque (touchstart/touchmove/touchend) e verificar se cada um expõe um mecanismo alternativo operável por meio de um único pressionamento de ponteiro sem arrastar. Testadores também devem verificar o atributo HTML5 draggable e os listeners de eventos associados dragstart/drop como sinais de funcionalidade dependente de arrastar.
• Auditoria manual — inspeção de eventos de ponteiro: Usando a inspeção de listeners de eventos nas DevTools do navegador ou ferramentas de auditoria de acessibilidade como o Accessibility Insights for Web (que inclui uma checklist manual para 2.5.7), testadores devem inspecionar componentes em busca de manipuladores de eventos de ponteiro e confirmar que toda a faixa de valores do componente ou sua capacidade de reposicionamento é alcançável sem movimento contínuo do ponteiro.
• Por que a automação não consegue detectar isso: Um scanner automatizado pode sinalizar que uma <div> tem um listener dragstart, mas não pode saber se clicar em um botão próximo rotulado “Move up” fornece uma alternativa em conformidade. Isso exige entender a relação entre elementos de UI e sua equivalência funcional — uma tarefa que atualmente excede a capacidade de ferramentas de análise de DOM estática ou em tempo de execução.

Como Testar

1. Base de varredura automatizada: Execute axe DevTools ou Lighthouse na página para revelar quaisquer problemas relacionados a ponteiro ou modalidade de entrada. Embora nenhuma regra do axe mapeie diretamente para 2.5.7, revisar problemas sinalizados sob as regras 2.5.x fornece contexto útil. Observe quaisquer componentes que o axe sinalize como tendo suporte de teclado insuficiente, pois estes frequentemente se sobrepõem a padrões somente de arrastar.
2. Identifique todos os componentes arrastáveis: Abra o Chrome DevTools, navegue até o painel Elements e use a aba Event Listeners para procurar handlers dragstart, drag, drop, pointermove, mousemove e touchmove. Alternativamente, pesquise no código-fonte da página pelo atributo draggable e por padrões JavaScript como .addEventListener('dragstart'. Liste todos os componentes que exigem arrastar.
3. Teste cada componente arrastável em busca de alternativas: Para cada componente identificado, tente alcançar o mesmo resultado usando apenas cliques ou toques de ponteiro único — sem arrastar. Para um controle deslizante, clique diretamente na trilha na posição desejada. Para uma lista ordenável, procure botões de mover ou opções de menu de contexto. Para um painel redimensionável, procure controles baseados em clique ou duplo clique. Se nenhuma alternativa existir, o critério é reprovado.
4. Verificação de navegação por teclado (sinal secundário): Teste todos os componentes arrastáveis apenas com teclado (Tab para focar, setas, Enter/Espaço). Embora o suporte de teclado seja coberto pela WCAG 2.1.1, a presença de suporte robusto de teclado frequentemente se correlaciona com a existência de alternativas sem arrastar, tornando isso uma etapa confirmatória útil. Use NVDA + Firefox, VoiceOver + Safari (macOS/iOS) ou JAWS + Chrome e verifique se toda a funcionalidade do componente é operável sem um dispositivo apontador.
5. Verificação em dispositivo touch: Em um dispositivo móvel ou usando a emulação de dispositivo em modo touch no Chrome DevTools, tente concluir as mesmas tarefas usando gestos de toque (sem arrastar e segurar). Confirme que toques únicos ou interações de toque no alvo são suficientes para toda a funcionalidade.
6. Documente os resultados: Para cada componente testado, registre se existe uma alternativa em conformidade de ponteiro único, se ela cobre toda a faixa de funcionalidade e se a operação de arrastar pode ser considerada essencial. Use a checklist de teste manual do Accessibility Insights for Web para a WCAG 2.5.7 como guia estruturado.

Como Corrigir

Controle Deslizante de Faixa sem Suporte a Clique na Trilha — Incorreto

<!-- Slider that only responds to drag on the thumb;
     clicking the track does nothing -->
<div class='slider-container'>
  <div class='slider-track'>
    <div class='slider-thumb'
         id='priceSlider'
         onmousedown='startDrag(event)'>
    </div>
  </div>
</div>

Controle Deslizante de Faixa com Clique na Trilha e Entrada Numérica — Correto

<!-- Native <input type='range'> provides drag, click-on-track,
     and keyboard support natively. A numeric input offers an
     additional single-pointer alternative. -->
<label for='priceRange'>Maximum price: <span id='priceValue'>500</span> TL</label>
<input type='range'
       id='priceRange'
       name='priceRange'
       min='0'
       max='1000'
       value='500'
       step='10'
       aria-valuemin='0'
       aria-valuemax='1000'
       aria-valuenow='500'
       oninput='document.getElementById("priceValue").textContent = this.value;
                document.getElementById("priceNumber").value = this.value;'>
<label for='priceNumber'>Or enter a value:</label>
<input type='number'
       id='priceNumber'
       name='priceNumber'
       min='0'
       max='1000'
       value='500'>

Lista Ordenável por Arrastar e Soltar sem Alternativa — Incorreto

<!-- Items can only be reordered by dragging.
     No move buttons or keyboard reordering exist. -->
<ul id='taskList'>
  <li draggable='true' ondragstart='handleDrag(event)' id='item1'>Task One</li>
  <li draggable='true' ondragstart='handleDrag(event)' id='item2'>Task Two</li>
  <li draggable='true' ondragstart='handleDrag(event)' id='item3'>Task Three</li>
</ul>

Lista Ordenável por Arrastar e Soltar com Botões de Mover — Correto

<!-- Drag-and-drop is preserved for users who can use it.
     Move Up / Move Down buttons provide a single-pointer
     (and keyboard-accessible) alternative for every item. -->
<ul id='taskList' aria-label='Sortable task list'>
  <li draggable='true'
      ondragstart='handleDrag(event)'
      id='item1'>
    <span>Task One</span>
    <button type='button'
            onclick='moveItem("item1", -1)'
            aria-label='Move Task One up'>
      &uarr; Move Up
    </button>
    <button type='button'
            onclick='moveItem("item1", 1)'
            aria-label='Move Task One down'>
      &darr; Move Down
    </button>
  </li>
  <li draggable='true'
      ondragstart='handleDrag(event)'
      id='item2'>
    <span>Task Two</span>
    <button type='button'
            onclick='moveItem("item2", -1)'
            aria-label='Move Task Two up'>
      &uarr; Move Up
    </button>
    <button type='button'
            onclick='moveItem("item2", 1)'
            aria-label='Move Task Two down'>
      &darr; Move Down
    </button>
  </li>
</ul>

Painel Dividido Redimensionável sem Alternativa — Incorreto

<!-- The divider can only be repositioned by dragging.
     No percentage input or preset-size buttons exist. -->
<div class='split-pane'>
  <div class='pane pane-left' id='leftPane'>Content A</div>
  <div class='divider'
       onmousedown='startResize(event)'
       aria-hidden='true'></div>
  <div class='pane pane-right' id='rightPane'>Content B</div>
</div>

Painel Dividido Redimensionável com Botões de Tamanho Pré-definido — Correto

<!-- The divider still supports dragging, but preset-layout
     buttons allow single-pointer repositioning. The divider
     is also keyboard-focusable with arrow-key support. -->
<div class='split-pane-wrapper'>
  <div class='split-controls' role='group' aria-label='Panel size presets'>
    <button type='button' onclick='setSplit(25)'>25 / 75</button>
    <button type='button' onclick='setsplit(50)'>50 / 50</button>
    <button type='button' onclick='setSplit(75)'>75 / 25</button>
  </div>
  <div class='split-pane'>
    <div class='pane pane-left' id='leftPane'>Content A</div>
    <div class='divider'
         role='separator'
         tabindex='0'
         aria-label='Resize panels'
         aria-valuenow='50'
         aria-valuemin='10'
         aria-valuemax='90'
         onmousedown='startResize(event)'
         onkeydown='resizeWithKeys(event)'>
    </div>
    <div class='pane pane-right' id='rightPane'>Content B</div>
  </div>
</div>

Erros Comuns

• Implementar controles deslizantes como componentes personalizados baseados em <div> sem suporte a clique na trilha, dependendo inteiramente de arrastar o elemento “thumb” e não tratando eventos de click no próprio elemento de trilha para mover o valor para a posição clicada.
• Assumir que o envio de arquivos por arrastar e soltar é o único mecanismo de upload necessário, sem fornecer um botão de navegação de arquivo visível e clicável (<input type='file'>) como fallback obrigatório ao lado da área de soltar.
• Aplicar a exceção de essencialidade de forma muito ampla — por exemplo, tratar uma lista de tarefas ordenável ou um quadro kanban como “arrastar essencial” quando botões de Mover para cima/para baixo atenderiam plenamente às necessidades dos usuários sem qualquer perda de funcionalidade.
• Fornecer alternativas de teclado, mas não alternativas de ponteiro único, interpretando erroneamente que a WCAG 2.5.7 é satisfeita apenas com suporte de teclado. O critério exige especificamente um caminho de ponteiro único; soluções apenas de teclado atendem à 2.1.1, não à 2.5.7.
• Ocultar botões de mover ou entradas numéricas atrás de estados de hover ou menus secundários que por si só exigem interações de arrastar ou sequências complexas de ponteiro para serem revelados, o que efetivamente anula a acessibilidade da alternativa.
• Negligenciar dispositivos touch ao testar alternativas de arrastar apenas com mouse de desktop e depois implantar para usuários em telas sensíveis ao toque, onde o comportamento do gesto de arrastar e suas alternativas podem diferir significativamente da implementação em desktop.
• Usar pointer-events: none na trilha do controle deslizante em CSS para evitar cliques acidentais durante o arrasto, o que bloqueia inadvertidamente a alternativa de clique na trilha exigida pela 2.5.7.
• Não fornecer alternativa para interações de arrastar/deslocar em mapas em mapas incorporados ou visualizações personalizadas baseadas em canvas, em que clicar em botões de seta direcional ou inserir coordenadas seria uma alternativa de ponteiro único suficiente.
• Implementar a alternativa de ponteiro único como um alvo de arrastar e soltar em si — por exemplo, criar uma área “solte aqui” que ainda exige um arrasto para ser usada — em vez de um modelo de interação genuinamente diferente, como um botão ou um campo de texto.
• Esquecer de testar alternativas em toda a faixa de valores de um componente arrastável. Um controle deslizante que permite aos usuários clicar apenas em algumas posições predefinidas na trilha, mas não em qualquer posição arbitrária, não oferece uma alternativa completa se a versão com arrastar suportar valores contínuos.

Relação com os Regulamentos de Acessibilidade da Turquia

A Circular Presidencial 2025/10 da Turquia, publicada no Diário Oficial nº 32933 em 21 de junho de 2025, estabelece uma estrutura nacional abrangente de acessibilidade para serviços digitais. A circular exige que as entidades abrangidas estejam em conformidade com as Diretrizes de Acessibilidade para Conteúdo Web e faz referência específica à conformidade de Nível AA como padrão para obtenção do Erişilebilirlik Logosu (Logotipo de Acessibilidade), a marca oficial de certificação emitida pelo Ministério da Família e Serviços Sociais (Aile ve Sosyal Hizmetler Bakanlığı).

WCAG 2.5.7, como critério de Nível AA introduzido na WCAG 2.2, está dentro do escopo dos requisitos necessários para obter e manter o Logotipo de Acessibilidade. Para organizações que dependem de interações de arrastar e soltar — como plataformas de e-commerce com controles deslizantes de filtragem de produtos ou listas de desejos ordenáveis, aplicativos bancários com painéis de gestão de portfólio ou ferramentas de reserva de agências de viagem com seletores de faixa de datas — a não conformidade com 2.5.7 constituiria uma barreira direta à certificação.

As entidades abrangidas pela Circular Presidencial 2025/10 incluem uma ampla seção transversal da economia digital turca: instituições públicas e órgãos governamentais em níveis central e local; bancos e prestadores de serviços financeiros regulados pela Agência de Regulação e Supervisão Bancária (BDDK); plataformas de e-commerce que operam na Turquia; hospitais e prestadores de serviços de saúde privados; operadoras de telecomunicações com 200,000 ou mais assinantes; agências de viagem e empresas de transporte privado; e escolas privadas autorizadas pelo Ministério da Educação Nacional (Milli Eğitim Bakanlığı — MoNE).

Para essas organizações, deixar de fornecer alternativas de ponteiro único para interações de arrastar não é apenas uma falha técnica — é uma lacuna de conformidade que pode impedir a certificação, expor a organização a escrutínio regulatório e excluir um segmento significativo de usuários com deficiências motoras. As estatísticas de deficiência da Turquia refletem as tendências globais: milhões de residentes vivem com condições que afetam o controle motor fino, e serviços digitais que dependem exclusivamente de gestos de arrastar erguem barreiras desnecessárias para essa população.

Na prática, organizações que buscam o Erişilebilirlik Logosu devem incluir a WCAG 2.5.7 em suas checklists de auditoria de acessibilidade, garantir que todos os componentes interativos construídos com funcionalidade de arrastar sejam revisados em busca de alternativas em conformidade e documentar suas decisões de conformidade — incluindo quaisquer alegações de exceção de essencialidade — como parte de sua Declaração de Acessibilidade (Erişilebilirlik Beyanı), que a circular exige que as entidades abrangidas publiquem e mantenham atualizada.