This content originally appeared on DEV Community and was authored by Luiza Gatti
Antes de mais nada, se você não leu minha história anterior, volta lá e dá uma lida porque ela serve de introdução para essa aqui.
A sigla ARIA (Accessible Rich Internet Applications) significa Aplicações para a Internet Ricas em Acessibilidade, que definem as formas de tornar o conteúdo e as aplicações da internet mais acessíveis.
A ARIA permite a marcação de algumas regiões importantes na página que servirão para auxiliar na navegação (para ajudar quem usa um leitor de tela, por exemplo). É um conjunto de atributos especiais para acessibilidade que pode ser adicionado a qualquer linguagem de marcação, mas é especialmente adequado para o HTML, e todos os exemplos que trarei serão nessa linguagem.
Primeira regra de uso de ARIA
Sempre que você puder usar um elemento nativo HTML5 ou atributo com semântica e comportamento que você precisa já incorporados, em vez de redefinir um elemento e adicionar o ARIA para torná-lo acessível, opte pelo HTML5.
Em quais casos isso pode não ser possível?
- Quando o recurso está disponível em HTML5, mas não está implementado; ou está implementado, mas não dá suporte a acessibilidade;
- Se as restrições de design visual excluem o uso de um elemento nativo específico, porque o elemento não pode ser estilizado conforme necessário;
- Se o recurso não estiver disponível em HTML.
Segunda regra de uso de ARIA
Não altere a semântica nativa, a menos que seja realmente necessário.
Não faça:
<h2 role="tab">tab de cabeçalho</h2>
Faça:
<div role="tab">
<h2>tab de cabeçalho</h2>
</div>
Nota: Se um elemento não interativo for usado como base para um elemento interativo, pessoas desenvolvedoras terão que adicionar a semântica usando ARIA e o comportamento apropriado usando scripts. No caso de um botão, por exemplo, é muito melhor e mais fácil usar apenas um botão.
Terceira regra de uso de ARIA
Todos os controles interativos de ARIA devem ser utilizáveis via teclado.
Se você cria uma ferramenta onde a pessoa pode clicar, tocar, arrastar, soltar, deslizar ou rolar, a pessoa também deve ser capaz de navegar até a ferramenta e executar uma ação equivalente usando o teclado.
Todas as ferramentas interativas devem ser programadas para responder aos pressionamentos de tecla padrão ou combinações de pressionamento de tecla quando aplicável.
Por exemplo, se estiver usando role="button", o elemento deve ser capaz de receber o foco e a pessoa usuária deve conseguir ativar a ação associada ao elemento usando Enter (WIN OS) ou Return (MAC OS) e a tecla de espaço.
Quarta regra de uso de ARIA
Não use role="presentation" ou aria-hidden="true" em um elemento visível e focalizável. Usar qualquer uma dessas propriedades em um elemento que pode ser visível e focalizável irá resultar em pessoas usuárias clicando em ‘nada’.
Um elemento que for oculto usando display: none também será removido da árvore de acessibilidade, o que torna desnecessária a adição de aria-hidden="true".
Quinta regra de uso de ARIA
Todos os elementos interativos devem ter um nome acessível.
Um elemento interativo só tem um nome acessível quando sua propriedade de nome (name ou equivalente) está preenchida.
Não faça:
<label>Insira seu nome</label> <input type="text"/>
Faça:
<label for="user-name">Insira seu nome</label>
<input type="text" id="user-name"/>
O correto acima tem um nome acessível porque o elemento de entrada é um elemento rotulável e o elemento de rótulo é usando corretamente para associar o texto à entrada.
O que adicionar "role" faz com a semântica nativa?
Ao adicionar a função ARIA, estamos substituindo a semântica da função nativa na árvore de acessibilidade e, portanto, ARIA afeta diretamente o que é relatado a uma tecnologia assistiva.
Por exemplo, esse código:
<h1 role=button>text</h1>
Fica assim na árvore de acessibilidade:
Adicionar a ARIA não fará com que o elemento pareça ou se comporte de maneira diferente para as pessoas que não estão usando tecnologia assistiva. A função não altera os comportamentos, estados e propriedades do elemento host, apenas a semântica da função nativa. Por exemplo, esse código:
<button role="heading" aria-level=1> Texto </button>
Fica assim na árvore de acessibilidade:
Mas ele ainda pode ser pressionado, ainda está na ordem padrão do tab, ainda se parece com um botão e ainda dispara as ações associadas a ele quando pressionado. É por isso que é um erro de conformidade com o HTML5 transformar um botão em um heading.
Nota: alterar a role de um elemento não adiciona comportamentos, propriedades ou estados àquela função. O ARIA não muda a aparência ou a ação no browser. Por exemplo, quando os links são estilizados para se comportarem como botões, adicionar role="button" não é suficiente. Também é necessário fazer funcionar como um botão, incluindo um manipulador de eventos de chave que escuta a tecla de espaço como os botões nativos fazem.
Uso de "role=presentation" ou "role=none"
role="presentation" ou seu sinônimo role="none" remove a semântica do elemento onde ele está. Por exemplo, esse código:
<h1 role="presentation"> Texto </h1>
Fica assim na árvore de acessibilidade:
Em outras palavras, é apenas relatado na árvore como uma string de texto, sem qualquer significado semântico.
Para elementos sem children obrigatórios, quaisquer outros elementos aninhados dentro de um com role="presentation/none" preservam sua semântica. Por exemplo, esse código:
<h1 role="presentation"><abbr> API </abbr></h1>
Fica assim na árvore de acessibilidade:
Para elementos com children obrigatórios (como <ul> ou <table>) quaisquer filhos obrigatórios aninhados dentro do primeiro elemento com a role="presentation/none" também tem a sua semântica removida. Por exemplo, esse código:
<table role="presentation">
<tr>
<td>
<abbr> API </abbr>
</td>
</tr>
</table>
Fica assim na árvore de acessibilidade:
Nota: quaisquer elementos que não sejam filhos obrigatórios do elemento com uma role="presentation/none" mantém sua semântica. Isso inclui outros como lista ou tabelas aninhadas. Por exemplo, esse código que consiste em uma tabela com outra tabela aninhada:
<table>
<tr>
<td>
<table>
<tr>
<td>
<abbr> API </abbr>
</td>
</tr>
</table>
</td>
</tr>
</table>
Fica assim na árvore de acessibilidade:
Ao adicionar role="presentation/none" na tabela mais externa, é assim que fica a árvore:
Uso de aria-label, aria-labelledby e aria-describedby
Atualmente aria-label, aria-labelledby e aria-describedby tem um suporte melhor em associar conteúdo de texto a um subconjunto interativo de elementos (por exemplo <div role="main"> ou <main>). Essas três opções não funcionam de forma consistente em links, o suporte a conteúdo embedado e conteúdo agrupado é inconsistente em navegadores, tecnologia assistiva e sistemas operacionais, mas podem ser usados com segurança em controles de formulário HTML5, incluindo vários tipos de input e os elementos <aside>, <footer>, <article>, <header>, <nav>, <section> e <main>.
O exemplo a seguir de aria-labelledby com várias referências usa um intervalo com um tabindex=-1.
Uso de role=application
Como role=application afeta um leitor de tela?
Em muitos leitores de tela populares, a maioria dos pressionamentos de tecla são capturados pelo leitor e não pela página da web quando a pessoa usuária está no modo de navegação. Isso é necessário para a navegação eficiente de uma página. Quando o modo de aplicativo está definido, muitos leitores de tela param de interceptar os pressionamentos de tecla e passam todos os pressionamentos de tecla diretamente para o navegador. Assim, a pessoa usuária não conseguirá navegar na página tão facilmente. Por exemplo, não serão capazes de pular a página por títulos ou ler um parágrafo de texto estático linha por linha. No entanto, vários leitores de tela não se comportam de maneira diferente quando há um conjunto de role=application.
Então quando devemos usar?
Ao determinar quando devemos usar essa propriedade precisamos levar em consideração também as vantagens dos atalhos de teclado do leitor de tela em relação à perda desses recursos. Geralmente não deve ser usado e, se for, devem ser realizados testes de usabilidade com pessoas usuárias de leitores de tela.
Não usamos role=application se um conjunto de controles tiver apenas esses widgets que fazem parte do HTML padrão. Isso também se aplica se você marcá-los e criar um modelo de interação usando funções WAI-ARIA em vez de widgets HTML padrão:
-
text box(também se aplica a telefone, pesquisa e senha) textareacheckboxbutton-
radio button(normalmente dentro de um fieldset/legend) select + option-
link,paragraphs,headingse outros elementos que são clássicos/nativos de documentos web
Nota: não é recomendado que sejam desenvolvidos widgets de entrada de texto personalizados. Quase sempre é melhor usar os inputs nativos.
Também não usamos role=application se seu widget for de algum dos seguintes tipos mais dinâmicos e não nativos:
tree viewslider-
tableque tenha elementos focalizáveis e que esteja sendo navegado pelas teclas de seta, por exemplo uma lista de mensagens de e-mail. Outros exemplos interativos são grids, tree grids, etc - Uma lista de guias (
tab,tablist) onde a pessoa usuária seleciona guias pelas teclas de seta para a direita e para a esquerda. Lembre-se que você tem que implementar o modelo de navegação para esse caso -
dialogealertdialog -
toolbaretoolbar buttons,menusemenu itemse similares
Você deve usar role=application se o conteúdo que está fornecendo consistir apenas em controles interativos focalizáveis e, principalmente, widgets avançados que emulam um aplicativo desktop real. Observe que, apesar de muitas coisas agora serem chamadas de aplicativo web, a maior parte do conteúdo com que esses aplicativos trabalham ainda são informações baseadas em documentos, sejam postagens e comentários de blogs, feeds e até mesmo acordeões que mostram e ocultam certos tipos de informação. Ainda lidamos principalmente com documentos na web, embora eles possam ter uma aparência semelhante a um desktop na superfície.
Em resumo: as vezes que você realmente irá usar o role=application serão muito raras!
Onde usar o role=application quando ele for relevante?
Coloque-o no elemento contido mais próximo de seu widget, por exemplo, a <div> superior a seu elemento.
Como regra geral, se sua página consiste em mais de 90 ou 95% de widgets, role=application pode ser apropriado. Mesmo assim, verifique se realmente é o caso. Jamais use role=application em um elemento amplamente contido, como o body, se sua página consistir principalmente em widgets tradicionais ou elementos de página, como links com os quais a pessoa usuária não precisa interagir no modo de foco. Isso causará enormes dores de cabeça para qualquer pessoa usuária de tecnologia assistiva.
Funções e propriedades de ARIA não disponíveis como recursos em HTML
Abaixo estão listadas as funções e propriedades ARIA não consideradas disponíveis nativamente em HTML. Claro que muitas funções e propriedades fornecidas pelo ARIA, que podem ser usadas para transmitir informações à pessoas usuárias, não estão disponíveis em HTML.
ARIA Roles
alertalertdialogapplicationdirectorydocumentfeedgridgridcellgrouplogmarqueemenumenubarmenuitemcheckboxmenuitemradiononenotepresentationscrollbarsearchstatusswitchtabtablisttabpaneltimertoolbartooltiptreetreegridtreeitem
Estados e propriedades ARIA (atributos aria-*)
aria-activedescendantaria-atomicaria-busyaria-controlsaria-describedbyaria-dropeffectaria-expandedaria-flowtoaria-grabbedaria-haspopuparia-hiddenaria-labelaria-labelledbyaria-levelaria-livearia-orientationaria-ownsaria-posinsetaria-pressedaria-relevantaria-setsizearia-sort
Referências
Iniciativa de Acessibilidade Web (WAI) do W3C.
Accessible Rich Internet Applications (WAI-ARIA) 1.1
WAI-ARIA Authoring Practices 1.1
This content originally appeared on DEV Community and was authored by Luiza Gatti
Luiza Gatti | Sciencx (2021-07-03T20:02:19+00:00) Agora vamos falar de ARIA. Retrieved from https://www.scien.cx/2021/07/03/agora-vamos-falar-de-aria/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.