1. Introdução

O projeto de ferramenta de avaliação de acessibilidade RIA

     O uso de aplicativos Web 2.0 tem aumentado rapidamente por causa de sua interface gráfica , efeitos e comportamento interativos [1] . Estas aplicações web se comportam de forma semelhante às aplicações desktop . Esta nova geração da Web depende de tecnologias que permitam a navegação interativa de conteúdo dinâmico da web[2].

O desenvolvimento Web 2.0 requer o uso de Rich Internet Application ( RIA) . Um subconjunto das seguintes tecnologias é necessário para construir tais aplicações : HTML, XHTML , CSS, Microformats , EcmaScript , Asynchronous JavaScript e XML ( AJAX) , HTML dinâmico ( DHTML) , e FLASH [3] .

Essas tecnologias são usadas para proporcionar apresentação dinâmica e interativa dos conteúdos da web.

Os elementos HTML são transformados pelos scripts em Web 2.0 para se comportarem como elementos interativos de interface de usuário, no caso da marcação resultante não ter nenhuma marcação estrutural que sera difícil para as tecnologias assistivas extrair o conteúdo relevante [4,5]. A interação do usuário com o conteúdo da web geralmente se baseia em navegação visual através cliques do mouse . Os navegadores permitem que os indivíduos usem a navegação por teclado , para apoiar o uso de tecnologias assistivas , quando as pessoas com deficiência navegam pelos conteúdos da Web [ 2,6] .

As tecnologias de apoio precisam ter informações semânticas associadas a componentes que são criados dinamicamente com a interação do usuário. Como mostrado na FIG. 1, estas semânticas são vistas através do navegador e podem ser passadas para tecnologias assistivas pela API do sistema operacional [ 7,2 ] .

Por exemplo, um elemento de uma página da web tem função de menu e que contém três elementos com a função do item de menu, com cada um contendo um conteúdo de texto que representa um sabor diferente.

Assim, a tecnologia assistiva pode ajudar o usuário '' Selecione uma das três opções: chocolate, morango ou baunilha .''

A Web Accessibility Initiative (WAI ) é uma seção do Consórcio World Wide Web que concentra-se sobre as diretrizes de acessibilidade à web [ 8-10 ] . O grupo WAI introduziu um conjunto de diretrizes de acessibilidade web , WCAG 2.0 , que pode ser usado para melhorar a acessibilidade de páginas web. Além disso, para melhorar os conteúdos sintáticos em páginas web de natureza dinâmica , o grupo WAI introduziu um conjunto de especificações que podem ser usados para melhorar a acessibilidade as páginas da WEB. Além disso, para melhorar o conteúdo sintático em páginas da web com caráter dinâmico, o grupo introduz especificações sobre acessibilidade.

WAI- ARIA fornece semântica que a Web 2.0 perde [13] . Ele permite a interoperabilidade entre RIA e tecnologia assistiva , fornecendo sentido claro para os elementos da interface do usuário do RIA . Este conjunto de semântica introduzida pelo WAI-ARIA é suportado pelos navegadores atuais e leitores de tela [14] .

A WAI-ARIA fornece especificações para mapeamento de regiões vivas AJAX, controles e eventos para API de acessibilidade. Ele recomenda a adição de dados importantes codificados em HTML e XHTML [2] , e explica como adicionar informação semântica sobre funções, propriedades e estados para todos os elementos da interface do usuário apresentadas em um RIA .

Isto é feito por meio de atributos que podem ser atribuídos a qualquer elemento HTML. A informação semântica sobre a apresentação e layout são inseridos na página web usando o HTML div, spam elementos e o atributo classe [ 3,15] . Os pedaços de informações semânticas inseridos são funções, propriedades e estados [ 7,13,16-18 ] . A função atributo fornece o propósito de uma instância de widget exemplo( elemento ) .

Enquanto estados e propriedades de widgets definem as características de um elemento , que descrevem e afetam as interações (por exemplo , para pessoas com deficiência , desativado, verificado e oculto) [19].

O uso do web designer WAI- ARIA pode ajudar na definição de funções e incorporar informações semânticas de objetos e um grupo de objetos (região) na interface da aplicação web [12]. A informação semântica é importante não só para a acessibilidade, mas também para a web móvel [2]. O usuário que navega na web usando o telefone móvel pode navegar facilmente uma aplicação web com regiões semanticamente definidos (por exemplo, usando um sintetizador de voz ou acessar diretamente Widget específico em uma página web longa) .

A avaliação de acessibilidade de aplicações web, podem ser realizadas utilizando as diretrizes de acessibilidade , avaliação do usuário e avaliação de especialista [20]. As ferramentas de avaliação automática podem ser implantadas no processo de concepção, desenvolvimento e manutenção de sites [ 20-22 ]. As ferramentas de avaliação de acessibilidade podem verificar vários problemas de acessibilidade automaticamente detectáveis ​​, como imagens sem texto alternativo e formulários sem rótulos(etiquetas). Muitas das ferramentas existentes para testar a acessibilidade web avaliam o HTML para a conformidade das WCAG 1.0 ou 2.0 [2], estas ferramentas são listadas em <http://www.w3.org/WAI/ER/tools/

complete>.

     A crescente complexidade dos sites requer o uso de ferramentas de testes mais sofisticados que têm de verificar a acessibilidade de diferentes elementos na interface de usuário [2]. Novas ferramentas devem ser apresentadas para testar a conformidade das aplicações web com WAI- ARIA [2]. A principal desvantagem das ferramentas existentes, quando utilizado para testar a acessibilidade de Rich Internet Applications é a incapacidade da ferramenta para verificar se os widgets de aplicativos web seguem as recomendações WAI-ARIA (por exemplo, um widget com nenhuma função de atributo é uma violação). Isto pode conduzir a páginas web que passarem nos testes de avaliação de acessibilidade com ferramentas de teste atual, mas não acessíveis a tecnologias assistivas. Outra dificuldade na avaliação automática é que as ferramentas poderiam marcar uma página como não acessíveis mesmo que a página use adequadamente recomendações WAI-ARIA para torná-la acessível.

Este artigo apresenta estruturas de testes automáticos da conformidade de páginas dinâmicas na web com especificações WAI-ARIA. Esta estrutura pode ser utilizada para desenvolver ferramentas de avaliação de acessibilidade para testes em tempo de execução de Rich Internet Applications. A estrutura consiste de diferentes componentes e a avaliação inicia-se com um robô web que dispara diversos eventos sobre o aplicativo da web. Em seguida, os conteúdos resultantes são avaliadas em relação a especificações WAI- ARIA . A ontologia WAI-ARIA, que fornece a semântica sobre widgets, estruturas e comportamentos é usada para validar elementos dinâmicos na página web. Um relatório de avaliação sobre os diferentes problemas de acessibilidade no aplicativo web será gerado, e os problemas de acessibilidade encontrados na página web será destacado para análise manual.

O restante deste documento está organizado da seguinte forma: a Seção 2 apresenta alguns dos desafios para avaliar a acessibilidade de Rich Internet Applications . A Estrutura Conceitual da ferramenta de avaliação de acessibilidade proposto é apresentado na Seção 3. Finalmente, um resumo das principais conclusões e possíveis trabalhos futuros são apresentados na Seção 4.

2. Experiências - estudos

Estudos

     Várias estruturas que abordam a questão da avaliação de acessibilidade em sites, foram introduzidos. Sloan et ai.[24] propôs uma estrutura que visa maximizar o papel da Web para permitir que as pessoas com deficiência, acessem informações, serviços e experiências. Esta é uma abordagem holística que pode resolver as deficiências da abordagem e WAI pode atender a necessidade de abordar resultados para aprendizagem sobre acessibilidade, em vez de nos concentramos em e-learning e em recursos sobre acessibilidade. Em outro estudo, Beirekdar et ai. [25] desenvolveu um sistema para automação de Usabilidade e Acessibilidade (U&A) de avaliação de sites. Foi desenvolvida uma nova abordagem baseada na verificação da representação formal da U&A, orientações estas para avaliação de desenvolvimento de sites.

Em seu sistema, são incorporadas diretrizes completas e interessantes para avaliação de website (chamado lógica de avaliação). A principal característica do seu sistema é que ele pode distinguir entre a lógica de avaliação e mecanismo de avaliação responsável por avaliar as diretrizes. Assim, os elementos HTML são usados ​​para expressar o U&A, orientações estas que ditam os termos e condições a serem cumpridas . Esta estrutura é praticamente apoiada pela linguagem de especificação formal, que permite a transformação da diretriz U&A. Os resultados da avaliação automática são exibidas em um relatório. Bohman e Anderson [22] apresentaram um quadro conceitual para apoiar os usuários com deficiências cognitivas. Vários componentes estão incluídos nesta estrutura:

( i ) As categorias de deficiência cognitiva funcional (ou seja, memória, resolução de problemas, atenção, leitura, linguística e compreensão verbal, a compreensão matemática e compreensão visual) ;

( ii) os princípios de acessibilidade cognitiva deficiência (ou seja, simples e consistente, clara, multi- modal, tolerante ao erro, tolerante a atrasos, e atenção com foco) ;

( iii) as unidades de análise de conteúdo Web (ou seja, web '' página'', o site inteiro, modelo, o conteúdo dentro do modelo, conteúdo '' pedaços '' ou subseções, e cenários e caminhos);

( iv ) os aspectos de análise (ou seja, conteúdo e apresentação);

etapa da análise (v) (ie, processo de planejamento, processo de projeto, fase de testes, e depois que o conteúdo é completado);

( vi) esferas de responsabilidade (ou seja, os desenvolvedores da Web, diretrizes e organismos de normalização, os desenvolvedores de ferramentas de autoria, desenvolvedores de agente de usuário, desenvolvedores de tecnologia assistiva , assistentes pessoais do usuário (quando aplicável) , e usuário).

Wtanable et al. [26 ] desenvolveram uma ferramenta de avaliação que é RIA análogos aos cenários de teste da tecnologia assistiva . O teste simula os eventos de teclado, a fim de atualizar a árvore DOM do site se o desejar. Este trabalho ainda em andamento e seu sistema não leva em consideração todas as possibilidades na interação interface do usuário. Fernandes et ai. [27] desenvolveu uma ferramenta para avaliar a acessibilidade de aplicações Web ricas. O conteúdo do aplicativo web é avaliado por meio de desencadear possíveis eventos que alterar parcialmente a página web. Este avaliador é capaz de avaliar documentos HTML que ficam mudando dinamicamente. Eventualmente, vários projetos de código aberto foram introduzidas recentemente para simular o navegador para processar o conteúdo da web e para testar as interfaces de sites antes da implantação [ 28-30 ] .

3. Desafios ARIA

     Testar acessibilidade Web 2.0 não é uma tarefa fácil [3]. Em ARIA a interface do usuário (UI) da página web é alterada por scripts do cliente para modificar a interface ao reagir às ações do usuário. As ações do usuário dispara eventos de página que alteram o estado de Document Object Model do navegador (DOM) ou um evento na página web que poderiam modificar a estrutura da página [31,32]. As diretrizes de acessibilidade recomendam ter teclado equivalente a eventos do mouse na página web. Os elementos de uma página web que podem receber o foco do teclado são links, controles como botões e objetos externos. Em RIA muitos outros elementos HTML e widgets da Web (por exemplo, menu, item-árvore e controle-deslizante) podem receber um foco do teclado. 

     A exigência event-driven (arquitetura orientada a eventos) da RIA torna a tarefa de teste de difícil acesso. O usuário deve ser notificado pelas tecnologias assistivas (ATS) sobre os elementos adicionados recentemente [2]. A AT precisa informar ao usuário o objetivo do widget. É importante para a AT saber seções diferentes na página da web para ajudar o usuário a acessar a parte necessária da página web (por exemplo, a sessão de navegação que normalmente contém links para as principais categorias no site) [20/19]. 

     A dificuldade de testes de acessibilidade RIA ocorre principalmente porque os acontecimentos são de granulação fina com respeito às alterações à DOM, a vasta gama e variedade de eventos do utilizador e, finalmente, a estrutura de DOM que se torna muito mais importante devido à sua sensibilidade a diferentes eventos do usuário. 

     Baseando-se apenas nas  diretrizes WCAG não é possível verificar-se automaticamente a acessibilidade de RIA IU [19], devido ao carácter dinâmico da RIA, e o requisito de ter informação semântica na widgets de RIA. A ferramenta de testes de acessibilidade para RIA tem de ser capaz de gerar e executar sequências de eventos diferentes para derivar diferentes estados dinâmicos da aplicação RIA.

4. A estrutura conceitual

4.1. requisitos

O resultado da avaliação de acessibilidade de páginas web estáticas são classificados em três categorias [33]:

1. Problemas de acessibilidade que podem ser avaliados e corrigidos usando uma ferramenta automática automaticamente.

2. Uma ferramenta pode apontar para possíveis problemas que podem exigir avaliação manual.

3. Avaliação manual, é necessária para examinar acessibilidade.

Nossa ferramenta hipotética proposta irá assegurar algumas das avaliação de acessibilidade automaticamente, e irá destacar partes da página web que necessitam de avaliação manual. De acordo com Brajnik [20], a ferramenta de testes de acessibilidade precisa:

• Verificar automaticamente os pontos de verificação de acessibilidade. A ferramenta tem de ser flexível para acrescentar facilmente novos pontos de verificação. Ela precisa ser projetada como as diretrizes são atualizadas regularmente e para que novos widgets possam ser adicionados no futuro. Isto pode ser aplicado, separando as regras de acessibilidade a partir do código [34].
• Destacar partes da página web que precisa de inspeção de acordo com um dado ponto de controle .
• Ser capaz de avaliar o código localmente. Isso ajuda o desenvolvedor web em fazer o upload dos arquivos localmente, e testá-las antes de publicar o site.
• Ser capaz de salvar os resultados da avaliação de acessibilidade em um ser humano, e formato legível por máquina.

A fim de testar diferentes estados em RIA, podemos seguir um método utilizado por [35], em que eles testam a robustez de aplicações Web 2.0, automatizando a sequência de interação do usuário.

4.2 Componentes

4.2. componentes
A estrutura proposta ( . Ver Fig. 2 ) consiste nos seguintes componentes:

a. Controlador de eventos RIA : Para superar o desafio de examinar todos os estados da aplicação Web 2.0, a ferramenta passará automaticamente através de diferentes estados da aplicação web dinâmica [32] . O controlador de eventos RIA irá inspecionar os scripts na página web para determinar os elementos que podem responder aos eventos de entrada do sistema (por exemplo, tecla pressionada) e fazer uma lista desses elementos e de seus eventos correspondentes. A ferramenta não assume que as páginas web são marcados como investiga os elementos e os scripts na página web para eventos RIA e widgets na web.
b . Robot Web: Isso irá gerar eventos de entrada do sistema nativo (ou seja , simular eventos do navegador) de acordo com a lista dos eventos especificados pelo controlador de eventos RIA . Atualmente, estamos construindo a ferramenta assumindo que os eventos não são dependentes um do outro . No futuro, vamos usar o controlador de eventos RIA para permitir que uma cadeia de eventos que são dependentes uns dos outros (por exemplo: Depois de ativar cada um dos eventos , todo o DOM será verificada após cada único gatilho de um evento pelo robô).
c . Especificações WAI-ARIA : O conjunto de diretrizes automáticas WAI-ARIA a serem testadas podem ser codificados usando XML. A codificação será na forma de regras, elementos HTML e atributos que estão associados a essas regras. Isto facilita a separação entre as orientações de avaliação e o motor de avaliação.
d . Avaliador: É composto de quatro componentes diferentes: DOM parser, elemento classificador, os testes de especificações ARIA, e ontologia ARIA. Estes componentes serão explicados mais adiante nesta secção.
e. Resultados da execução: Depois da analise da página web, a ferramenta irá produzir um relatório sintético. Este erá um relatório do conteúdo web rica que têm problemas de acessibilidade.

     O manipulador de resultados irá carregar os resultados da avaliação, destacando os elementos que poderiam ter problemas de acessibilidade na página da web para ser inspecionado por um perito . No componente avaliador, o parser DOM irá inspecionar a árvore DOM da página web à procura de um elemento e atributo XHTML específicos.
     Os elementos classificadores irão classificar os elementos extraídos do parser DOM para as quatro principais categorias RIA :

• Os elementos utilizados para a estrutura semântica que fornecem a propósito das áreas de páginas web (por exemplo, barra de navegação principal , etc.). O exemplo a seguir é parte de uma página web que está marcada como uma área de navegação :

-----------------------------------------------------------------------------------------------------------
< papel ul ='' navegação ''
<li> <a href=''#''> Início </ a> </ li>
<li> <a href=''#''> Quem Somos </ a> </ li>
<li> <a href=''#''> Contato < / a> </ li>
</ ul>
-----------------------------------------------------------------------------------------------------------

• Os elementos utilizados para a marcação de peças na página web como um conteúdo dinâmico (ie, região viva) . As atualizações na página web pode ser trivial e não deve ser falada, outras mudanças devem ser faladas imediatamente, e outras ainda devem ser faladas depois de um tempo. Por exemplo, quando o valor assertivo é atribuído ao atributo aria-live, que irá resultar em alertar o usuário sobre a mudança de conteúdo imediatamente . No exemplo abaixo, um temporizador é mudado a cada segundo, e a tecnologia de apoio irá alterar o utilizador sobre essa alteração imediatamente de acordo com o valor de atributo ária-viva.

------------------------------------------------------------------------------------------------------------
<div id=‘‘region1Container’’>
<label id=‘‘live1Label’’
for=‘‘liveregion1’’>Changing value</label>:
<div id=‘‘liveregion1’’
class=‘‘region’’
role=‘‘timer’’
aria-labelledby=‘‘live1Label’’
aria-live=‘‘assertive’’
aria-atomic=‘‘true’’
aria-relevant=‘‘all’’>XXX

</div>

</div>

------------------------------------------------------------------------------------------------------------

• Os elementos que precisam de um foco do teclado na página da web. Por exemplo, um texto em uma página da web pode ser tratado como um botão , adicionando a função ='' botão '' e'' tabindex = 0'' para fazer o teclado Widget focalizável .

------------------------------------------------------------------------------------------------------------
<li id=‘‘larger1’’
role=‘‘button’’
tabindex=‘‘0’’
aria-pressed=‘‘false’’
aria-controls=‘‘text1’’
aria-labelledby=‘‘larger_label’’>+
</li>

------------------------------------------------------------------------------------------------------------

• Os widgets complexos e elementos de navegação que precisam ser acessados ​​pelo teclado e pelo leitor de tela . 

Por exemplo, o código a seguir torna a fonte do menu e um submenu Sans-serif na página web. As funções e os atributos tabindex são utilizados para identificar o widget e torná-la acessível por teclado .

-----------------------------------------------------------------------------------------------------------
<li id=‘‘mb1_menu1’’ role=‘‘menuitem’’
tabindex=‘‘0’’ aria-haspopup=‘‘true’’>
Font
<ul id=‘‘fontMenu’’ class=‘‘menu’’
role=‘‘menu’’>
<li id=‘‘sans-serif’’
role=‘‘menuitemradio’’
tabindex=‘‘-1’’
aria-controls=‘‘st1’’
aria-checked=‘‘true’’>
Sans-serif

</li>

</ul>

</li>

----------------------------------------------------------------------------------------------------------

Os testes de especificações ARIA irão verificar que todos os elementos clicáveis ​​na página web podem receber um foco do teclado [2] . Isto pode ser conseguido através da investigação que elementos do Document Object Model (DOM) precisam receber um foco do teclado. Em seguida, o atributo tabindex pode ser usado para adicionar o foco do teclado para todos estes elementos recuperados .
Os seguintes recipientes RIA precisam ter teclado focalizável : Combobox , grade, caixa de listagem , menu, barra de menu , árvore, TreeGrid , TabList , barra de ferramentas , alerta, AlertDialog , botão, checkbox, combobox , diálogo , gridcell , link, log , marquise , menuitem , menuitemcheckbox , itemradio de menu , opção, progressBar rádio, radiogroup , barra de rolagem , slider, SpinButton , status, guia , TabPanel , caixa de texto, timer, dica , TreeItem .
Esses widgets da Web 2.0 não tem suporte a teclado direto. A fim de tornar esses widgets e elementos de navegação acessíveis por teclado, o atributo tabindex será definido para incluir o elemento na ordem de tabulação da página Web. Em geral, os elementos com o atributo de função, também deve ter o atributo tabindex, a menos que o recipiente correspondente do elemento faça uso de aria-viva descendente.

Componentes (continuação)

     Por outro lado , a estrutura semântica pode ser testada como presente ou não na página Web como especificando as áreas de exatas na página web que perde esses marcos é uma tarefa difícil de ser realizada automaticamente. A seguir estão as funções em que pelo menos um deles precisa estar presente na página web como um indicador de referência para as tecnologias assistivas : documento complementar, Content Info , bandeira, principal , navegação e pesquisa.

A região viva na página da web é a parte da página que é atualizada regularmente , sem que se faça uma atualização (por exemplo, tabelas de pontuação de esporte ou informações de estoque) . A região viva pode ser associada com qualquer elemento . Os testes de especificações ARIA são necessários para verificar se o conteúdo dinâmico na página web são marcados como uma região viva. Isto é indicado pelo uso de estados e propriedades específicas: aria -live , aria -atômicas , e aria - relevante. O código JavaScript usa o ID para uma região específica (por exemplo, div ou span) na página web em que as mudanças

será aplicada (ou seja , adicionar / remover / atualizar ) [36] . A ferramenta irá marcar as regioes vivas que foram encontrados com os valores padrão de acordo com as seguintes : viva = off , atômico = false , relevantes ='' adições de texto'' .

A semântica do núcleo dos widgets são representados como RDF ​​/ OWL ontologia. O RDF / OWL ontologia usa funções , estados e propriedades para definir os elementos da interface do usuário, acessíveis . Esses elementos podem ser usados ​​para melhorar a acessibilidade e interoperabilidade de conteúdo e aplicações web para as pessoas com deficiência.

A ontologia fornece semântica sobre widgets , estruturas e comportamentos. Esta ontologia é usada para testar a conformidade da árvore DOM resultante com as especificações WAI- ARIA .

Por exemplo, o seguinte é a afirmação no RDF ​​/ ontologia :

-----------------------------------------------------------------------------------------------------------
<owl:Class rdf:ID=‘‘combobox’’>
<rdfs:subClassOf rdf:resource=‘‘#select’’/>
<role:requiredState rdf:resource=‘‘http://
www.w3.org/2005/07/aaa#aria-expanded’’/>

</ owl : Class >

-----------------------------------------------------------------------------------------------------------

Isso significa que há uma classe chamada '' combobox '' , que é uma sub-classe de outra classe chamada '' selecionar '' e tem um papel de estado necessário '' papel : requiredState '' representado pelo recurso URL http://www.w3.org/2005/07/aaa # aria - expandido na ontologia ARIA .

Os testes de especificações ARIA será realizada como se segue :

• Aplicando um checkpoints específicas de acessibilidade de RIA para especificações WAI- ARIA de acordo com esta ontologia.
• O robô Web interage com o controlador de Eventos RIA no qual ele vai passar os eventos de entrada necessários para a Web robô , a fim de ser desencadeado o evento sistema nativo através do simulador. Os eventos serão disparados na seqüência de sua ordem na página web. O avaliador irá então verificar todo o DOM alterado após o último evento que está sendo demitido.
• Os resultados serão usados ​​para detectar se há uma função ausente, sustentar, propriedade ou estado para um elemento específico, e para verificar o uso correto deles, como os estados e propriedades precisam ser herdadas da função selecionada.
• Os valores das funções, cuja sintaxe está incorreta com base nas descrições ARIA/RDF gera uma violação. Um container com função (árvore, grade, menu, etc) deve ter pelo menos um ramo com um papel aplicável como definido pela Aria , caso contrário, será gerada violação . Alguns widgets tem uma propriedade necessária de acordo com a ontologia (por exemplo, aria-marcada para a caixa de seleção) e faltando uma dessas propriedades de um elemento é considerado violação .

    A seguir são apresentadas as etapas para verificar a conformidade da RIA com a ontologia WAI-ARIA . Essas etapas são explicadas com um exemplo na seção seguinte . Em primeiro lugar, os widgets serão extraídos a partir da página web em fase de testes (nós da árvore DOM) , e o resultado será representado como uma ontologia RDF/OWL.

Em segundo lugar, estes elementos extraídos serão convertidos em modelo gráfico RDF ​​. Em terceiro lugar, o modelo de gráfico gerado será comparado com o modelo gráfico da ontologia RDF/OWL usando uma consulta SPARQL .

Finalmente , a semântica em falta será relatada ao usuário como problemas de acessibilidade ARIA na página web.

     A Avaliação e Relatório Language (EARL) são usados para apresentar os resultados dos testes de acessibilidade em um formato legível pela máquina [37] . Esta representação vai ajudar a gerar muitos relatórios de avaliação de uma forma flexível [38] . Este formato pode ser usado para agregar os resultados obtidos por diferentes ferramentas de teste. Os resultados da nossa ferramenta pode ser integrada com os obtidos a partir de outras ferramentas de avaliação das WCAG. O estrutura descrita neste trabalho ajuda na concepção e construção de ferramentas de avaliação, não só para Internet rica, mas também para a integração com outras ferramentas de avaliação de acessibilidade.

5. A estrutura da aplicação

     As tecnologias assistivas podem ajustar o formato do conteúdo da web em uma apresentação compreensível pelo usuário. Para alcançar este objetivo, o software de tecnologia assistiva precisa entender a semântica dos conteúdos da web. Vamos apresentar dois exemplos para esclarecer os benefícios do uso de WAI- ARIA. O primeiro exemplo é quando o usuário encontra uma caixa de seleção, espera-se que ele/ela marque ou desmarque a caixa. Se o desenvolvedor não usar o código HTML padrão para a caixa de seleção, então o usuário não saberá que isso é uma caixa de seleção usando as tecnologias de apoio (por exemplo, leitor de tela). Outro exemplo é o widget de árvore que se parece com exibições de árvore. Uma pessoa que usa um leitor de tela não pode determinar o estado dos ramos (ou seja , expandir ou fechar) . Com a introdução de WAI-ARIA as tecnologias assistivas podem indicar o papel do widget (por exemplo, uma árvore ou caixa) e os diferentes estados que pode ser em (por exemplo, marcada ou desmarcada). Esta informação será acessível para tecnologias assistivas .

Para ilustrar a estrutura, vamos passo a passo de um cenário de aplicação da ferramenta para avaliar a acessibilidade de um widget árvore clicável. Suponha que temos o seguinte conteúdo da página web.

Tabela 1
O núcleo correspondente RDF​​/OWL ontologia com Widget árvore.
-------------------------------------------------------------------------------
Nó relacionado com ARIA         Estrutura RDF / XML
-------------------------------------------------------------------------------
id = '' '' tree1                              <owl:Class rdf:ID=''tree''>
                                                  <rdfs:subClassOf rdf:resource=''#select''/>
                                                  <role:mustContain rdf:resource=''#group''/>
                                                  </ owl : Class >
-------------------------------------------------------------------------------

Tabela 2
Comparando o widget árvore na página web e no núcleo RDF ​​/ OWL ontologia.
--------------------------------------------------------------------------------
DOM node da página web         Apresenta os estados e         Todos os estados
(em relação a funções ARIA )    as propriedades da página     e propriedades do
                                                  web                                      núcleo semântico.
--------------------------------------------------------------------------------
id=’’tree1’’
                                                <owl:Class rdf:ID=’’tree’’> <owl:Class rdf:ID=’’tree’’>
                                                <rdfs:subClassOf                 <rdfs:subClassOf
                                                rdf:resource=’’#select’’/>     rdf:resource=’’#select’’/>
                                                <role:mustContain                <role:mustContain
                                                rdf:resource=’’#group’’/>     rdf:resource=’’#group’’/>
                                                </owl:Class>                        <role:mustContain
                                                                                            rdf:resource=’’#treeitem’’/>
                                                                                            </owl:Class>

----------------------------------------------------------------------------------------------

Tabela 3
Ausência da semântica na widget árvore.
-----------------------------------------------------------------------------------------------
Nó relacionada com ARIA                               Faltando semântica
id = '' '' tree1                                                    <role:mustContain rdf:resource=''#treeitem''/>
-----------------------------------------------------------------------------------------------

Este fragmento de página é identificado automaticamente usando o DOM analisador
( ie, class = árvore) e os elementos classificados.
------------------------------------------------------------------------------------------------
< ul id = '' '' tree1 class = '' árvore '' papel ='' árvore '' aria - labelledby ='' label_1 ''>
< li id ='' frutos '' tabindex ='' 0'' aria - expandidas ='' verdadeiros ''> Frutas
<ul role=''group''>
<li id=''oranges'' tabindex=''-1''> laranjas < / li >
<li id=''pinapples'' tabindex=''-1''> Abacaxi </ li>
< li id = '' '' maçãs tabindex ='' -1 '' aria - expandidas ='' falsas ''> Maçãs<ul role=''group''>
< li id = '' macintosh '' tabindex ='' -1 ''> Macintosh </ li>
                   <
                 </ ul>
              </ li>
            </ ul>
         </ li>
</ ul>
-------------------------------------------------------------------------------------------------

O robô web irá gerar uma tecla no menu Frutas (coluna 1 na fig. 3). O resultado final é que tem todos os níveis da árvore widget expandido ( coluna 3 na figura 3.) . Em seguida, o parser DOM irá procurar elementos RIA . Depois disso, o teste de especificação ARIA irá inspecionar os elementos RIA para verificar se todos têm o atributo tabindex . Isso é necessário para garantir que o widget RIA é o teclado focalizável . O RDF/OWL ontologia de WAI-AIAS vai usar elementos RIA extraídos da página web para encontrar correspondentes entre as estruturas da ontologia (ver Tabela 1).

Os papéis extraídos , estados e propriedades do widget árvore são como se segue :

--------------------------------------------------------------------------------------------------
Class = árvore
<role:mustContain rdf:resource=''#group''/>
mustContain = grupo
<owl:Class rdf:ID=''group''>
<rdfs:subClassOf rdf:resource=''#section''/>
< rdfs : seeAlso rdf : recurso ='' http://
www.w3.org/TR/html401/interact/
forms.html # edef - FIELDSET '' / >
< papel : supportedState rdf : recurso ='' http://
www.w3.org/2005/07/aaa # aria -
activedescendant '' / >
--------------------------------------------------------------------------------------------------
A fim de validar o conteúdo RIA na página da Web, para cada função, o RDF/OWL será convertido para uma consulta SPARQL CONSTRUIR da seguinte forma:
CONSTRUIR { ? X ? P ? Y}
DE RDF- ontologia -de- Widgets- semântica
ONDE {? x owl: Árvore de classe.
? x rdfs : subClassOf select.
? x role : grupo mustContain .
? x ? p ? y}
---------------------------------------------------------------------------------------------------------

Esta consulta será usado para combinar com a ontologia núcleo RDF ​​dos widgets e vai construir um gráfico de RDF da árvore de papel (ver Tabela 2).

O resultado da consulta será comparado com os estados e propriedades apresentadas na página da Web para produzir um relatório contendo o nó DOM e indicar a semântica em falta no nó DOM (ver Tabela 3).

O formato EARL será usado para apresentar os resultados do teste, e esta parte na árvore DOM será destacada com uma cor amarela para notificar o usuário sobre o problema.

6. Conclusão e futuros trabalhos

     Neste artigo, apresentamos a estrutura de uma ferramenta que pode ser utilizada para avaliação automática de acessibilidade de conteúdo rico na internet. A ferramenta verifica a acessibilidade do conteúdo exibido em uma página da web e fornece ao usuário um relatório com o conteúdo sobre acessibilidade que falta e que deve aparecer na página web testada com relação às especificações de acessibilidade WAI-ARIA.

Intuitivamente, isso é conseguido através da transformação semântica WAI-ARIA que aparecem na página web a ser testado em uma consulta SPARQL e, em seguida, combinar a consulta SPARQL contra as especificações de acessibilidade WAI-ARIA. Atualmente, estamos trabalhando na implementação deste projeto para validar a eficácia e precisão do quadro proposto.

Glossário

Ajax

AJAX (acrônimo em língua inglesa de Asynchronous Javascript and XML1 , em português "Javascript Assíncrono e XML") é o uso metodológico de tecnologias como Javascript e XML, providas por navegadores, para tornar páginas Web mais interativas com o usuário, utilizando-se de solicitações assíncronas de informações. 

Wigdet

Um widget é um componente de uma interface gráfica do usuário (GUI), o que inclui janelas, botões, menus, ícones, barras de rolagem, etc..

Outro emprego do termo são os widgets da área de trabalho, pequenos aplicativos que flutuam pela área de trabalho e fornecem funcionalidade específicas ao utilizador (previsão do tempo, cotação de moedas, relógio,...)

Alguns widgets tem por objetivo receber dados do usuário e com isso gerar algum tipo de registro, como os controles de formulário. Componentes como entrada de texto, caixa de seleção, menu de seleção, botões de múltipla escolha e outros são capazes de definir a natureza dos dados a serem coletados, e dessa forma enumerar todas as possibilidades de dados a serem apresentados pelo usuário. 

Event-driven

Arquitetura orientada a eventos ( EDA ) é uma arquitetura de software padrão de promover a produção, detecção, consumo, bem como reação a eventos .

Um evento pode ser definido como uma "mudança significativa no estado ". ^[ 1 ] , por exemplo, quando um consumidor adquire um veículo automóvel, as alterações de estado do veículo de "venda" de "vendido". A arquitetura do sistema de negociante de carro pode tratar essa mudança de estado como um evento cuja ocorrência pode ser dado a conhecer a outras aplicações dentro da arquitetura. Do ponto de vista formal, o que é produzido, publicado, propagada, detectado ou consumidos é uma mensagem (normalmente assíncrona) chamou a notificação de eventos, e não o evento em si, que é a mudança de estado que desencadeou a emissão da mensagem. 

Evento

Em computação, um evento é o resultado de uma ação. A ocorrência de um evento pode provocar uma reação, que seria uma ação (ou conjunto de ações) à ser tomada.

Estado

(Ciência da computação)

Em informática, o estado de uma lógica digital do programa de computador é um termo técnico para toda a informação armazenada, num dado instante no tempo, para que o programa tem acesso.

Robot web

Bot, diminutivo de robot, também conhecido como Internet bot ou web robot, é uma aplicação de software concebido para simular ações humanas repetidas vezes de maneira padrão, da mesma forma como faria um robô. No contexto dos programas de computador, pode ser um utilitário que desempenha tarefas rotineiras ou, num jogo de computador, um adversário com recurso a inteligência artificial. Bots também podem ser considerados ilegais dependendo do seu uso, como por exemplo, fazer diversas ações com intuito de disseminar spam ou de aumentar visualizações de um site. O seu uso mais frequente, entretanto, está no Web crawler, em que um script realiza buscas automáticas, analisa informações de arquivos e servidores em uma velocidade extremamente alta, muito superior à capacidade humana. Além desses usos, o bot pode ser implementado em sites em que há comunicação com o usuário, como sites de jogos ou simplesmente onde é necessária comunicação semelhante à humana.1 O uso mais recente de Internet bots foca-se na publicidade, como o Google Adsense, que exibe a propaganda mais adequada a cada pessoa dependendo de seu comportamento na Internet.

RIA

Aplicações de Internet Rica (da sigla em inglês RIA - Rich Internet Application) são Aplicações Web que tem características e funcionalidades de softwares tradicionais do tipo Desktop.

DOM

DOM (Document Object Model - Modelo de Objetos de Documentos) é uma especificação da W3C para uma interface, independente de plataforma e linguagem, onde pode-se dinamicamente alterar e editar a estrutura, conteúdo e estilo de um documento eletrônico, permitindo que o documento seja mais tarde processado e os resultados desse processamento, incorporados de volta no próprio documento. A API DOM oferece uma maneira padrão de se acessar os elementos de um documento, além de se poder trabalhar com cada um desses elementos separadamente, e por esses motivos criar páginas altamente dinâmicas.

Aria-live

No passado, uma alteração da página da web apenas podiam serem faladas em elementos que muitas vezes incomodavam um utilizador, ou falando muito pouco ou nada, tornando parte ou toda a informação inacessível. Recentemente, os leitores de tela não eram capazes de melhorar isso porque não existia marcação padronizada para alertar o leitor de tela para uma mudança. 

Regiões vivas preenchem esta lacuna e oferecem sugestões aos leitores de tela sobre se e como interromper os usuários com uma mudança.

SPARQL

É uma linguagem de consulta RDF , isto é, uma linguagem de consulta para bancos de dados , capaz de recuperar e manipular dados armazenados em Resource Description Framework formato. ^{[ 1 ] [ 2 ]} Foi feito um padrão pelo Grupo de Trabalho de Acesso de Dados RDF (GDP) do Consórcio World Wide Web , e é reconhecida como uma das principais tecnologias da web semântica . 

WEB SEMÂNTICA

A Web semântica é uma extensão da Web atual, que permitirá aos computadores e humanos trabalharem em cooperação.1 A Web semântica interliga significados de palavras e, neste âmbito, tem como finalidade conseguir atribuir um significado (sentido) aos conteúdos publicados na Internet de modo que seja perceptível tanto pelo humano como pelo computador.

FRAMEWORK

Um framework (ou arcabouço), em desenvolvimento de software, é uma abstração que une códigos comuns entre vários projetos de software provendo uma funcionalidade genérica. Um framework pode atingir uma funcionalidade específica, por configuração, durante a programação de uma aplicação.

ONTOLOGIA

     Uma ontologia é um modelo de dados que representa um conjunto de conceitos dentro de um domínio e os relacionamentos entre estes. Uma ontologia é utilizada para realizar inferência sobre os objetos do domínio.