Ferramenta de Apoio à Prática

Tendo em conta os diversos standards e documentos existentes referentes a acessibilidade digital, bem como a contingência de vários tipos de projeto de software, um bom ponto de partida é relacionar cada standard ao tipo de projeto ao qual melhor se coaduna. Se assim for, o esforço em pesquisa numa fase anterior à programação e na leitura de documentação complicada, será bastante minimizado. Com isto em mente, foi desenvolvida uma tabela que se apresenta como uma proposta para uma ferramenta de apoio na utilização da proposta de método de desenvolvimento anteriormente apresentada, e que almeja ser uma ferramenta pedagógica no ensino de acessibilidade digital a futuros programadores de software. A proposta de ferramenta é apresentada abaixo (Tabela 3) e explicada seguidamente.

106

Tipo de Projeto Documentos a consultar

Web IU Web Content Accessibility Guidelines

(WCAG) ou o cap.9 da EN 301 549 Aplicações nativas com controlos de IU

standard do SO hospedeiro

Human Interface Guidelines do SO hospedeiro; Guia de programação de acessibilidade do SO hospedeiro

Aplicações Nativas com controlos de IU feitos de raiz

APIs de acessibilidade do SO hospedeiro; cap. 11 da EN 301 549

IU para um grande sistema de software, como um SO, e máquinas com funcionalidade fechada, tais como máquinas de venda de bilhetes

ISO 9241-171:2008 – Ergonomics of human- system interaction ou todos os capítulos da EN 301 549

Tabela 3. Relação entre tipo de projeto e a documentação apropriada.

4.2.2.1. Desenvolvimento Web

Para o desenvolvimento de software com interface gráfica Web, o recomendado por várias organizações – incluindo Governos –, é a utilização das linhas orientadoras WCAG da W3C. Para além das linhas orientadoras, as WCAG contêm checkpoints que ajudam a levar a interface gráfica Web a ser utilizável, a um determinado nível, por pessoas com problemas causados por deficiências específicas. A EN 301 549, no seu capítulo 9, é sobreponível com as WCAG. Isto significa que ao seguir o capítulo 9 da EN 301 549, a interface gráfica Web ficará de acordo com as WCAG. Assim, a acessibilidade da interface gráfica Web será tão boa quanto a qualidade da implementação das WCAG, ou do capítulo 9 da EN 301 549. É importante perceber que seguir as WCAG ou o Capítulo 9 da EN 301 549 pode não ser suficiente, uma vez que um projeto Web pode ser enorme, e com diversos tipos de conteúdo. Por exemplo, se o projeto incluir conteúdos em vídeo, o capítulo 7 da EN 301 549 deve ser examinado, uma vez que aborda ICT com conteúdo em vídeo. No caso de o projeto disponibilizar documentação, esta deve estar conforme o capítulo 10, que contém informação sobre documentos não Web. É importante ter presente que os projetos Web podem ser muito complexos e abrangentes, e, evidentemente, nem toda a gente será capaz de saber tudo perfeitamente. Em suma,

107

significa que nem todos os criadores têm que dominar tudo, detalhadamente. Seguir estas linhas orientadoras pode ser encarado como um atalho para atingir a acessibilidade Web, usando o conhecimento de um grupo de especialistas que usou o seu saber e tempo para desenvolver estas linhas orientadoras.

4.2.2.2. Desenvolvimento e Aplicações Nativas com Controlos Gráficos Standard

As HIG do SO hospedeiro são fundamentais no caso de o programador querer fazer uma aplicação com um aspeto gráfico semelhante ao SO hospedeiro. É importante explanar que se um programador fizer a sua aplicação graficamente semelhante ao SO hospedeiro, está, imediatamente, a criar um certo nível de acessibilidade ao seu projeto, uma vez que a interação com a sua aplicação será idêntica à do SO hospedeiro. Desta forma, a curva de aprendizagem será simples, ou praticamente inexistente. Ao usar componentes gráficos standard do SO hospedeiro, o programador terá o seu trabalho bastante facilitado, uma vez que estes – os componentes gráficos standard – já possuem, por omissão, as APIs de acessibilidade implementadas e, portanto, terá apenas que consultar o guia de acessibilidade do SO hospedeiro, de forma a usar esses componentes de forma correta.

4.2.2.3. Desenvolvimento de Aplicações com Componentes Gráficos Feitos de Raiz

Numa situação como esta, o programador deve seguir a abordagem descrita no ponto acima, com os extras de estudar a documentação relativa às APIs de acessibilidade do SO hospedeiro, bem como implementá-las corretamente – as APIs de acessibilidade –, nos seus novos componentes gráficos. Apenas depois destes procedimentos a aplicação será acessível. Num caso como este, é recomendável que o programador consulte o capítulo 11 da EN 301 549, que trata de software nativo, e pode ajudá-lo a entender e apreender uma série de conceitos importantes para compreender e implementar, corretamente, acessibilidade digital no seu projeto. É importante enfatizar que a acessibilidade do software é um tópico muito importante, complexo e enorme. Para desenvolver um software acessível, é necessário muito

108

trabalho, e requer muitos testes. Escolher desenvolver componentes gráficos de raiz representa um grande desperdício de investigação e esforço previamente efetuados por outra pessoa/empresa. Sistemas operativos como algumas versões do Windows, iOS, Mac OS e Android, etc. já possuem muito trabalho desenvolvido relativo à acessibilidade digital. Ao decidir utilizar componentes gráficos não standard, o programador deve estar consciente que estará a desperdiçar muito trabalho que já foi feito durante o desenvolvimento da plataforma que escolheu para o seu software. Numa situação como esta, será relevante, e de grande ajuda, o programador ler os capítulos 4 e 5 da EN 301 549 que tratam de performance funcional e de requerimentos genéricos, respetivamente.

4.2.2.4. Desenvolvimento de Sistemas de Software Complexos

Para o desenvolvimento de uma grande IU – e.g. para um SO –, a recomendação é o uso/leitura do ISO 9241-171:2008 - Ergonomics of human-system interaction, elaborado pelo comité técnico ISO/TC 159, Ergonomics, Subcommittee SC4, Ergonomics of human-system interaction (ISO). Este ISO oferece orientações em ergonomia e especificações de acessibilidade para um software que tenha que ser usado em ambiente laboral, em casa, na educação, ou espaços públicos, como o escrito no seu abstract. Estas devem ser as linhas orientadoras para o desenvolvimento de uma grande IU, feita de raiz.

No capítulo 4 da EN 301 549, tanto um programador como a pessoa responsável pela encomenda do software, podem aceder a informação sobre a performance funcional, que indica que requerimento é necessário para satisfazer uma necessidade especial de um utilizador. Este capítulo explica como é que um utilizador pode localizar, identificar e usar uma função independentemente da sua própria capacidade. É importante ter este conhecimento presente antes de passar à preocupação com os requerimentos técnicos, abordados nos capítulos subsequentes da EN 301 549. O anexo B da EN 301 549 é útil para fazer a ligação entre os requerimentos técnicos com as necessidades do utilizador, portanto, para atingir a performance funcional. Este capítulo é um ótimo ponto de partida. Depois de saber a informação relevante do capítulo 4, os programadores devem seguir para o capítulo 5. O capítulo 5 da EN 301 549 trata dos requisitos genéricos, ou seja, tem informação sobre os

109

requisitos de acessibilidade genéricos, independentemente da tecnologia. Isto significa, que contém requisitos que podem ser utilizados pelos diferentes tipos de projetos e serviços TIC – e.g. máquinas de venda automática; máquinas de venda de bilhetes; IU de eletrodomésticos; IU de SOs. Nem todos os requisitos precisam de ser implementados ao mesmo tempo. Os requisitos relevantes ao projeto devem ser considerados prioritários. Tomando como exemplo uma máquina de venda de comidas e bebidas, os criadores devem prestar atenção ao capítulo 4 e, por exemplo, à primeira parte do capítulo 5 – i.e. 5.1 –, que fala sobre funcionalidade fechada. A funcionalidade fechada é muito comum neste tipo de equipamentos. Portanto, os criadores devem saber como superar os obstáculos tratados nesse capítulo e, assim, tornar a máquina utilizável por todas as pessoas. Seguindo com o mesmo exemplo, os criadores devem seguir as recomendações do capítulo 8 da EN 301 549, que trata de hardware – capítulo 8.4 – e o acesso físico ao hardware – capítulo 8.3. Desta forma, por exemplo, uma pessoa utilizadora de cadeira de rodas consegue chegar perto o suficiente da máquina a fim de a utilizar. Num projeto como este, é muito importante ter em mente que a acessibilidade não pode ser implementada de uma forma não planeada. Provavelmente será necessário recorrer a especialistas de várias áreas da acessibilidade.