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.
Nenhum comentário:
Postar um comentário