Coautora: Jessie Huff

A empatia quase sempre o levará mais longe em qualquer empreendimento, e a experiência do usuário não é diferente. Entender como nossos usuários interagem com nosso software e quais ferramentas eles estão usando nos dá uma ideia de como melhor ajudá-los. Alguns de nós estão acostumados a olhar para um site, examinar os títulos, rolar até a parte desejada e clicar para interagir com os elementos da página.

Se eu tiver uma deficiência motora, posso usar um teclado para interagir com uma página para chegar a esse elemento em vez de um mouse. Posso percorrer a página ou usar teclas de atalho para obter rapidamente as informações de que preciso. Eu posso até ser o tipo de usuário que vai e volta entre as ferramentas, dependendo das minhas necessidades. Ou, se eu for um usuário cego, posso usar um leitor de tela para me ajudar a navegar em uma página. Posso usar os menus do leitor de tela para obter rapidamente as principais categorias da página, como cabeçalhos, pontos de referência, controles de formulário ou links. (No entanto, é importante observar que existem muitos tipos de usuários que se encaixam nessas categorias, em todas as categorias e em outras categorias que não mencionaremos.) Portanto, quando consideramos essas experiências, precisamos entender como essas ferramentas interagir com um site.

Estruturação de acessibilidade

O todo-poderoso DOM, Document Object Model, é incrivelmente importante quando se trata de tecnologia assistiva. Tanto o teclado quanto o leitor de tela dependem do DOM para navegar e interpretar o que está acontecendo em uma página. Ele traduz o conteúdo de um documento HTML em um objeto padronizado que linguagens de programação funcionais, como JavaScript, podem acessar e modificar facilmente. Todas as páginas da Web dinâmicas dependem do DOM para exibir e funcionar corretamente.

Cada página da web tem uma estrutura que você pode ver usando a ferramenta Inspetor:

O DOM ou estrutura é o que será utilizado pelas tecnologias assistivas para interpretar o que está acontecendo na página. Tecnologias assistivas, como leitores de tela, passarão pelo DOM e tentarão interpretar os elementos que estão sendo usados, a ordem desses elementos e o que se espera que eles façam.

Digamos que temos uma IU onde você pode adicionar conteúdo — talvez até mesmo blogs como este! Nessa página, temos um botão “adicionar” flutuante para que os usuários possam adicionar conteúdo facilmente onde quer que estejam na página. Bem, isso parece um conceito legal, certo?

Agora, digamos que sou um usuário de teclado ou leitor de tela. Cheguei a esta página, estou pronto para adicionar minha voz à conversa e estou procurando o botão Adicionar. Como o desenvolvedor marcou esse código no DOM afetará tudo. Muitos desenvolvedores irão renderizar o botão na parte inferior do DOM e apenas reposicionar visualmente o elemento para parecer que está flutuando e seguindo você conforme você rola a página. No entanto, ainda está na parte inferior do DOM o tempo todo.

Portanto, como usuário de teclado ou leitor de tela, estou navegando pela página e, estranhamente, não consigo encontrar o botão Adicionar. Estou vendo links para postagem de blog após postagem de blog na página principal, mas nenhum lugar onde eu possa adicionar minha própria postagem de blog. Começo a me perguntar se este site não permite que os usuários publiquem seu conteúdo e se o anúncio está errado. Já se passaram alguns minutos navegando na página e já estou me sentindo irritado.

Ah, finalmente encontrei o botão adicionar. Por que diabos eles colocaram o botão adicionar no final da página? Eles realmente queriam me deixar louco e me fazer trabalhar tanto apenas para contribuir? A resposta honesta é que a equipe provavelmente não tinha ideia de como eles dificultaram a interface do usuário para uma boa porcentagem de usuários. Eles provavelmente viram o botão flutuante e pensaram: “uau, isso parece legal” e nunca realmente se sentaram e pensaram nesses diferentes tipos de experiências.

Vemos o mundo através de nossas próprias lentes, às vezes tornando difícil perceber que as lentes de outra pessoa podem ser totalmente diferentes. Não é fácil pensar em todas as experiências, mas certamente devemos tentar aprender sobre diferentes usuários e suas experiências. Caso contrário, podemos deixar de ajudar nossos clientes incríveis, sem mencionar que temos a capacidade de tornar suas vidas muito mais difíceis se não o fizermos. Portanto, quando outro designer vier até você com uma ideia super legal, nova e elegante, pare e pense em como diferentes tipos de usuários interagiriam com ela. Se você vai ter um botão “adicionar” em sua página, onde no fluxo faz mais sentido para os usuários descobri-lo? Se você for um desenvolvedor, faça perguntas ao designer sobre essas diferentes interações do usuário. Todos devem estar na mesma página quando se trata de interações esperadas.

Agora que entendemos um pouco mais sobre os diferentes tipos de experiência do usuário e como a ordem dos seus elementos pode ser importante, vamos discutir mais detalhes técnicos essenciais.

Abordagens do PatternFly para anexar ao DOM

Ao usar um sistema de design como o PatternFly, as possibilidades são quase infinitas em termos de interações que você pode criar. Algumas dessas possibilidades podem ser mais vantajosas do que outras e algumas podem criar problemas inesperados para os usuários. É por isso que é importante considerar as implicações de sua abordagem para essas interações.

Antes de examinar as abordagens do PatternFly, vamos primeiro obter um pouco de conhecimento sobre a propriedade menuAppendTo React usada em vários componentes do PatternFly. Embora o que realmente é anexado possa depender do componente - em uma lista suspensa, apenas um menu suspenso aberto será anexado em vez da alternância, enquanto um modal inteiro seria anexado - a propriedade essencialmente faz a mesma coisa: anexa o componente ao especificado contêiner no DOM.

Com a propriedade menuAppendTo, há espaço para flexibilidade para anexar um componente em qualquer lugar no DOM, mas tudo se resume a dois tipos básicos de anexação: uma ordem DOM “não natural” e uma ordem DOM mais natural.

Uma ordem DOM “não natural”

Uma ordem não natural do DOM refere-se a quando o local de um elemento no DOM não corresponde à sua ordem de tabulação visual ou esperada. O exemplo mais comum disso é anexar algum conteúdo renderizado dinamicamente ao corpo do documento. Alguns componentes do PatternFly que geralmente podem ser anexados ao corpo do documento são componentes do tipo dropdown, como dropdown ou select, dicas de ferramentas e modais, apenas para citar alguns.

Acrescentar coisas em uma ordem DOM não natural certamente pode ter seu lugar. Ao renderizar um modal, anexar ao corpo do documento pode fazer sentido, pois deve ser a única coisa que pode receber foco ou interagir com os usuários, portanto, a desvantagem usual de uma ordem DOM não natural pode não se aplicar necessariamente. Um componente como uma dica de ferramenta pode ser outro caso em que uma ordem DOM não natural faz sentido, pois o conteúdo da dica de ferramenta em si nunca receberá o foco (embora ainda deva ser transmitido a usuários de tecnologias assistivas, como leitores de tela). Da mesma forma, os alertas do sistema que “aparecem” visualmente no canto superior direito da página podem ser anexados “não naturalmente” se não houver conteúdo interativo dentro dos alertas, como links para mais informações ou botões para descartar o alerta.

Quando você começa a ter um aninhamento mais complexo de componentes, como um menu suspenso dentro de um assistente dentro de um modal, anexar o menu suspenso ao corpo do documento ou ao modal pode até ajudar a garantir que o menu suspenso apareça acima de todo o outro conteúdo, em vez de ser encoberto e cortado por qualquer coisa.

Apesar de haver casos de uso para isso, uma desvantagem dessa abordagem é que ela pode tornar as coisas menos acessíveis para usuários que navegam e interagem via teclado ou tecnologias assistivas.

Se uma alternância suspensa for renderizada no meio do DOM, enquanto o menu suspenso estiver anexado ao corpo do documento, a ordem de tabulação esperada e a ordem de tabulação real não corresponderão. Dependendo de quantos outros elementos focalizáveis ​​existem entre a alternância e o menu no DOM, em vez de pressionar a tecla Tab uma vez para entrar no menu suspenso, pode ser necessário pressioná-la um número desconhecido de vezes, navegando por todo o resto do a página antes de finalmente colocar o foco dentro do menu suspenso.

Da mesma forma, se você fechar um menu suspenso por meio da tecla Escape, pode esperar que pressionar Tab coloque o foco no próximo elemento focalizável após a alternância suspensa. O que realmente recebe o foco é o próximo elemento válido de onde o menu suspenso foi anexado no final do corpo do documento. Se não houver outros elementos focalizáveis, você acabará tabulando na parte superior da janela do navegador.

Outra desvantagem dessa abordagem é que ela pode exigir que o consumidor implemente o gerenciamento de foco para evitar esses problemas, supondo que o componente não cuide disso para você (o que não será imediatamente aparente).

Por que um componente pode não lidar com o gerenciamento de foco

Alguns componentes têm casos de uso e interações muito simples. Um botão, por exemplo, normalmente será apenas algo em que você clica e algo acontece em resposta a esse clique.

Outros componentes, no entanto, podem não ser tão diretos e os casos de uso podem diferir muito, dependendo de quem o está usando e do contexto em que está sendo usado. Embora implementar o gerenciamento de foco ou alguma outra funcionalidade no próprio componente possa ser útil para o caso de uso de uma pessoa, isso pode causar problemas ou ser uma experiência indesejada para o caso de uso de outra pessoa.

Uma ordem DOM mais natural

Ao anexar componentes no DOM de uma maneira que corresponda melhor à ordem de tabulação visual ou esperada, você pode evitar completamente alguns dos problemas ao anexar em uma ordem DOM não natural.

Usando nosso cenário suspenso da seção anterior, se um menu suspenso estiver visualmente “depois” de uma alternância suspensa e o menu receber o foco imediatamente após a alternância, o menu deverá ser anexado para que apareça após a alternância no DOM, ou o mais próximo possível dela. A principal conclusão dessa abordagem é evitar elementos não relacionados e perceptíveis entre dois elementos relacionados que devem receber foco antes ou depois do outro.

Uma desvantagem dessa abordagem é que ainda pode haver algum gerenciamento de foco a ser implementado pelo consumidor ou pelo próprio componente, principalmente garantindo que qualquer elemento que acionou o conteúdo para renderização dinâmica receberá o foco depois que o conteúdo não estiver mais visível. No entanto, esse é o gerenciamento de foco que precisaria ser implementado independentemente de onde você anexar um componente.

A vantagem dessa abordagem — além de melhorar a acessibilidade — é que você não precisa se preocupar em implementar muito mais gerenciamento de foco, pois isso deve ser feito pela ordem do DOM. Você também não precisa descobrir se o componente lida com essa funcionalidade para você ou se apenas parcialmente para o seu caso de uso.

Recomendação de PatternFly para menuAppendTo

A recomendação a seguir é baseada na v4 do PatternFly. No entanto, com mais componentes que podem ser compostos sendo introduzidos na próxima v5 em 2023, alguns dos quais ainda mantêm a funcionalidade menuAppendTo, a recomendação ainda se aplica.

Para a maioria das situações, PatternFly recomenda a abordagem de ordem DOM natural. Para vários componentes, isso pode ser obtido passando uma prop React “menuAppendTo” com um valor de “parent”. Para um controle mais preciso sobre onde o conteúdo é anexado, você também pode passar uma função que retorna um seletor de consulta, embora você ainda deva anexar o mais próximo possível de uma ordem DOM natural ao fazer isso.

Para situações em que uma ordem DOM natural não é tão importante - como modais - ou onde tentar lidar com o z-index ou contexto de empilhamento não é facilmente gerenciável - como aninhamento complexo de componentes - a abordagem de ordem DOM não natural certamente pode seja mais útil. Essa abordagem pode ser obtida passando uma função que retorna “document.body” ou um seletor de consulta para a propriedade React “menuAppendTo”. Idealmente, este deve ser o último recurso, especialmente se fizer mais sentido anexar um item em um local mais específico no DOM.

Assim como a própria acessibilidade, pode não haver sempre uma única solução que funcione para todas as situações e resolva todos os problemas para todos. A recomendação do PatternFly pode nem sempre ser a melhor escolha para sua situação específica, mas é importante entender as implicações de qualquer abordagem que você adotar.

Tem uma história própria? Escreva conosco ! Nossa comunidade prospera com diversas vozes — vamos ouvir a sua.