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 :
< 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>
-----------------------------------------------------------------------------------------------------------
<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
<li id=‘‘larger1’’
role=‘‘button’’
tabindex=‘‘0’’
aria-pressed=‘‘false’’
aria-controls=‘‘text1’’
aria-labelledby=‘‘larger_label’’>+
</li>
<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
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.
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 .
<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.
Nenhum comentário:
Postar um comentário