Quando a primeira versão das WCAG (Diretrizes para Conteúdo acessível na Web) foi publicada, em maio de 1999, não era possível criar conteúdos dinâmicos ou manipular elementos multimídia na Web sem um plug-in ou aplicativo proprietário. Nessa época, as diretrizes eram suficientes para tornar conteúdo acessível, afinal a Web era composta apenas formulários, tabelas, imagens e outros elementos estáticos. Nove anos depois surgiram as WCAG 2.0, criadas com base na versão 1.0, que ampliou as possibilidades para tornar o conteúdo acessível. Mas a Web demandava mais…

Conteúdos dinâmicos ainda tinham barreiras sérias de acessibilidade, inclusive porque as tecnologias assistivas não conseguiam acessar modais ou áreas que eram atualizadas sem um “refresh” completo da página. Para tornar esse conteúdo dinâmico acessível na Web o W3C publicou a recomendação WAI-ARIA 1.0, que se tornou uma Recomendação do W3C em março de 2014.

WAI-ARIA (Accessible Rich Internet Applications) define a forma de tornar conteúdo, principalmente aplicações Web, acessíveis para pessoas com deficiências. Essa documentação auxilia especialmente conteúdo dinâmico e interfaces de usuário com controles avançados. WAI-ARIA funciona com as tecnologias já existentes, como HTML e SVG e proporciona uma forma de aplicar os requisitos das WCAG para aplicações ricas na Web.

Aplicações web complexas tornam-se inacessíveis quando as tecnologias assistivas não podem determinar a semântica de partes de um documento ou quando o usuário não é capaz de navegar de forma eficaz em todas as partes do site ou aplicação. WAI-ARIA divide a semântica em roles (papéis), states e properties (estados e propriedades).

Roles servem para identificar o elemento ou a aplicação na interface e estão divididas em quatro tipos:

• Abstract Roles: Usadas para ontologias. Não devem ser utilizadas para conteúdo
• Widget Roles: Utilizadas para definir interfaces de widgets, como alert, dialog, slider, tab, etc.
• Document Structure Roles: descrevem as estruturas que organizam o conteúdo em uma página, por exemplo article, group, img, region, etc. Estruturas de documentos geralmente não são interativos.
• Landmark Roles: são regiões da página destinadas a marcação de navegação, por exemplo banner, main, navigation, etc.

A lista completa de roles está neste link.

Cada uma das “roles” pode ser manipulada e definida por diversos “states and properties”, por exemplo, um link definido como item de um checkbox pode ser definido como “true” ou “false” para que o usuário tenha um retorno acessível do resultado da ação.

<li role=”menuitemcheckbox” aria-checked=”true”>Link ativo</li>

A lista completa de states and properties para cada role está aqui.

Uma das principais diferenças entre as WCAG e ARIA é que a primeira utiliza os elementos semânticos do HTML para tornar o conteúdo acessível. Já WAI-ARIA possibilita a mudança da semântica de um elemento para torna-lo acessível. Eu explico.

Neste exemplo, o desenvolvedor precisa criar um cabeçalho que é um botão. Para esse caso a recomendação é:

• Não faça isso: <h1 role=button>botão</h1>
• Faça isso: <h1><button>botão</button></h1>
• Ou então isso: <h1><span role=button>botão</span></h1>

Porque se role=button for colocado dentro do H1, a estrutura de acessibilidade dos objetos tratará esse elemento como <button>botão</button> e perderá sua característica de cabeçalho.

Por esse motivo, WAI-ARIA deve ser utilizado somente onde não for possível utilizar a semântica do HTML para tornar o conteúdo acessível. Sempre dê prioridade para as WCAG.

A Web está em constante evolução e conforme ela evolui, navegadores e tecnologias assistivas devem acompanhar esse processo. Por esse motivo o W3C tem uma preocupação imensa com a acessibilidade. A Web foi criada com o intuito de ser acessível desde sua concepção e esse princípio deve acompanhar sua evolução. E nós, criadores e mantenedores dos códigos que circulam pela Web, temos uma responsabilidade imensa de manter esse legado de uma Web acessível para as atuais e futuras gerações, afinal, dentro de algumas décadas nós poderemos ser os usuários de tecnologias assistivas que vão acessar esse conteúdo na Web. E ele deve ser acessível. Para o nosso próprio bem.

***

Artigo publicado na Revista iMasters, na seção “Por dentro do W3C”. Você pode assinar a Revista e receber as edições impressas em casa, saiba mais.