Elabore componentes acessíveis

Objetivos de aprendizagem

Após concluir esta unidade, você estará apto a:

• Identificar os conjuntos de componentes incluídos na estrutura de componente do Lightning.
• Listar as etapas de criação de componentes acessíveis.
• Listar as etapas de criação de componentes Web personalizados.

Introdução

A estrutura de componente do Lightning oferece um conjunto de componentes totalmente funcionais para você usar. Eles são todos baseados nos planos de componentes do SLDS mais recentes que seguem as diretrizes de acessibilidade relevantes. Sempre que possível, use esses componentes existentes. Eles foram aprovados para acessibilidade e irão poupá-lo de muito trabalho extra. Saiba mais sobre esses componentes na Referência de componentes. 

Usar componentes

A Referência de componentes inclui informações sobre dois conjuntos diferentes de componentes, componentes do Aura e componentes Web do Lightning. Os componentes do Aura listados se enquadram em vários namespaces diferentes. Os componentes nos namespaces ui e force foram desenvolvidos para atender a uma especificação mais antiga do ARIA e já não são os componentes mais acessíveis disponíveis. 

Os Componentes Web do Lightning (LWC) é a maneira preferida de criar a interface do usuário com o Salesforce. Visite o módulo Migrar do Aura para os Componentes Web do Lightning para aprender a usar o LWC e cumprir os padrões atuais da Web. Ou, se precisar de mais informações sobre o Aura, visite o Guia do desenvolvedor de componentes do Aura do Lightning ou a documentação de componentes do Aura. 

Os componentes Web do Lightning com o prefixo lightning- estão gravados no padrão ARIA mais recente e seguem os planos do componente do SLDS mais recentes. Sempre que possível, use esses componentes em vez de alternativas mais antigas. 

Quando você usa componentes do Lightning, ainda precisa manter a acessibilidade em mente. Por exemplo, quando você coloca um ícone informativo usando <lightning-icon>, ainda precisa especificar um valor alternative-text adequado para que os usuários entendam a finalidade do ícone. Ao usar <lightning-input>, você ainda precisa especificar um label para associar programaticamente a <input> resultante com seu <label>. A configuração required="true" cria a entrada necessária de maneira acessível.

Muitos componentes do Lightning também têm atributos para definir as propriedades do ARIA. Embora elas não sejam obrigatórias para acessibilidade, nós as incluímos caso você precise definir esses valores. 

Criar componentes

Se não conseguir encontrar o componente necessário em nossa referência de componentes, talvez seja necessário criar seu próprio componente do Lightning. Se fizer isso, siga estas etapas para se certificar de que está acessível.

1. Sempre comece com os planos de componentes do SLDS. Explore a marcação e funções, estados e propriedades do ARIA com atenção. Anote os atributos obrigatórios e os atributos que mudam quando um usuário interage com seu componente.
2. Implemente as interações do teclado. Lembre-se de que as funções do ARIA são uma promessa para seus usuários. Essa promessa inclui fornecer a funcionalidade de teclado que os usuários esperam considerando a função que você especificou. Nossos planos de componente incluem instruções de navegação do teclado.

Dica: Não ouça os eventos de pressionamento da tecla Tab. Em vez disso, ouça o foco. Os usuários de leitores de tela raramente usam a tecla Tab para navegar por uma página.

• Gerencie o foco do usuário. Siga nossas Diretrizes globais de foco para garantir que os elementos interativos possam ser focalizados.
• Grave a automação e teste manualmente seus componentes. 
  1. Grave testes de integração para testar interações de teclado. A única maneira confiável de testar interações de teclado é usando um navegador real. Não confie na inspeção manual do DOM para capturar regressões. Grave testes para garantir a precisão da marcação, incluindo:
     • Semântica correta no nó correto.
     • Atributos corretos definidos no nó correto.
     • Valores de atributo corretos atualizados durante o ciclo de vida do componente.
  2. Faça manualmente um teste de recursos de ponta a ponta usando apenas o teclado, obedecendo as especificações do SLDS. Certifique-se de que tudo possa ser feito com um teclado.

Componentes Web

Os componentes Web são um recurso de navegador que oferece um modelo de componente padrão para a Web formado por várias partes que são mantidas em lugares diferentes: shadow DOM, elementos personalizados, modelos HTML e alterações de CSS (fonte). Em termos práticos, os componentes Web têm um elemento personalizado como raiz. Esses elementos personalizados não têm valor semântico, mas podem causar problemas de descendência direta para tecnologias assistenciais. 

Problemas da descendência direta

Se você criar uma lista desordenada, <ul>, com itens da lista de componentes Web, <lightning-example-list-item>, sua marcação ficará assim:

<ul>
  <lightning-example-list-item>
    <li>content</li>
  </lightning-example-list-item>
  <lightning-example-list-item>
    <li>content</li>
  </lightning-example-list-item>
  <lightning-example-list-item>
    <li>content</li>
  </lightning-example-list-item>
</ul>

No entanto, isso não ficará acessível já que cada filho de um <ul> deverá ser um elemento <li>. Os leitores de tela não conseguem reconhecer que esta é uma lista de três itens. Aqui, é melhor contar com funções do ARIA em vez de elementos semânticos.

Em vez de um <ul>, podemos usar outro componente Web com role="list". Nosso item da lista de componentes Web precisaria de role="listitem” e não iríamos usar os elementos <li>. Com o código mostrado abaixo, os leitores de tela podem identificá-lo corretamente como uma lista de três itens.

<lightning-example-list>
<div role="list">
  <lightning-example-list-item>
    <div role="listitem">content</div>
  </lightning-example-list-item>
  <lightning-example-list-item”>
    <div role="listitem">content</div>
  </lightning-example-list-item>
  <lightning-example-list-item>
    <div role="listitem">content</div>
  </lightning-example-list-item>
</div>
</lightning-example-list>

Atributos HTML globais

Não use atributos HTML globais para definir atributos nos elementos internos. Quando você define um atributo HTML global no host com os Componentes Web do Lightning, nossa estrutura pressupõe que você queira que ele esteja no host, mesmo que o transmita também. Por exemplo, se você usar o atributo aria-describedby em um componente Web de entrada como uma API para definir o atributo no filho, acidentalmente, você o definirá duas vezes.

<lightning-example-input aria-describedby="foo">

Renderiza como:

<lightning-example-input aria-describedby="foo">
  <input aria-describedby="foo" />
</lightning-example-input>

Em vez disso, use letras concatenadas no nome da API de seu componente Web como no exemplo a seguir:

<lightning-example-input ariaDescribedby="foo">

Isso renderiza adequadamente:

<lightning-example-input>
  <input aria-describedby="foo" />
</lightning-example-input>

Mais informações sobre nomes de propriedade e atributo, incluindo o uso de letras concatenadas, podem ser encontradas na seção Recursos.

Shadow DOM

Os componentes Web com o shadow DOM ativados apresentam mais problemas relacionados à acessibilidade. Muitos aspectos da acessibilidade na Web dependem das referências de ID do componente que vinculam elementos diferentes na página. Um exemplo simples disso envolve a criação de rótulos de entradas de formulário.

<label for="foo">First Name</label>
<input type="text" id="foo" />

No exemplo de código mostrado acima, a id "foo” associa o rótulo "Nome" à entrada de texto. Se o rótulo e a entrada fossem colocados em componentes Web separados por causa do shadow DOM, esse relacionamento já não existiria na árvore de acessibilidade do navegador.

<lightning-example-label>
     <label for="foo">First Name</label>
</lightning-example-label>
<lightning-example-input>
     <input type="text" id="foo" />
</lightning-example-input>

Nesse caso, o rótulo e a entrada já não estão associados e o formulário já não está acessível. Aqui, a solução é não separar elementos em diferentes elementos personalizados quando um relacionamento de referência de ID é obrigatório.

<lightning-example-input>
     <label for="foo">First Name</label>
     <input type="text" id="foo">
</lightning-example-input>

Ao criar seus próprios componentes Web personalizados, estude os planos do SLDS e as especificações de design do ARIA. Identifique propriedades HTML e do ARIA que dependem de referências de ID e nunca separe esses elementos em raízes de sombra separadas.

Um grupo no W3C está desenvolvendo o Modelo de objeto de acessibilidade, uma abordagem que oferece maneiras de atribuir funções e propriedades, atualizar estados e criar relacionamentos sem depender de atributos HTML e referências de ID. Embora este modelo ainda esteja em estado de rascunho, ele oferecerá maior controle sobre a acessibilidade dos componentes Web quando for adotado por navegadores, tecnologias assistenciais e a comunidade de desenvolvimento.

E isso é tudo, pessoal!

Agora você já conhece as noções básicas da criação de interfaces de usuário acessíveis. Procure mais recursos no Trailhead quando estiver pronto para começar a projetar e testar a acessibilidade. Participe de nossa grande comunidade de administradores e desenvolvedores pela Salesforce Trailblazer Community para compartilhar ideias, participar de grupos, ler histórias de sucesso e muito mais. 

Recursos

• Documentação: Padrões e rascunhos do W3C
• Referência de desenvolvedores da Salesforce: Componentes Web do Lightning
• Referência de desenvolvedores da Salesforce: Nomes de propriedade e atributo
• Documentação: Modelo de objeto de acessibilidade
• Ajuda do Salesforce: Planos de componente
• Documentação: Especificações dos componentes Web do W3C