Criando Aplicativos Acessíveis do Oracle JET

Observação: Esta programação de estudo (Learning Path) tem um pré-requisito, Desenvolver um Aplicativo Web no Oracle JavaScript Extension Toolkit (Oracle JET), que deve ser concluído antes do início deste curso.

Introdução à acessibilidade

Agora que você tem uma compreensão básica de como usar o Oracle JET para desenvolver aplicativos web, é hora de atender às necessidades especializadas de quase 10% a 20% do seu público-alvo - aqueles com deficiências. De acordo com um artigo publicado pela Organização Mundial da Saúde em 2014, aproximadamente 15% da população mundial tem alguma forma de deficiência, e esse número cresce com uma população em constante envelhecimento.

Histórico

O conceito moderno de acessibilidade originou-se no final do 1960s como um movimento de base nos campi universitários e nas comunidades locais para abordar os direitos dos indivíduos com deficiência que buscam acesso físico a edifícios públicos. Este acesso incluía rampas ao longo de passarelas públicas, entradas, portas automáticas e rótulos Braille em elevadores para edifícios públicos, governamentais e universitários.

Legislação de Acesso Igual

Hoje, o "acesso" incorpora tanto o acesso físico às estruturas quanto o acesso ao atual cenário tecnológico de PCs, laptops, tablets, smartphones e dispositivos controlados por voz, como o Amazon Alexa. A legislação em matéria de igualdade de acesso continua a abordar as questões do acesso físico e da tecnologia de que dependemos.

A acessibilidade de software é obrigatória por leis civis em muitos países ao redor do mundo. Por exemplo:

• The Americans with Disabilities Act nos Estados Unidos
• A Lei de Acessibilidade para Ontários com Deficiência em Ontário, Canadá
• A Lei de Igualdade de 2010 no Reino Unido

Desafios para acessar - Tipos de obstáculos

Como web designers e desenvolvedores de aplicativos, precisamos estar cientes de que os clientes com deficiência enfrentam obstáculos ao acessar a tecnologia. Considere o seguinte:

• Um usuário não pode manipular o camundongo devido à mobilidade prejudicada (defeito congênito, doença de Lou Gehrig, doença de Parkinson, artrite reumatoide, lesão ou um déficit relacionado ao envelhecimento). Como um usuário desse tipo ativaria o texto que tem um evento de clique vinculado a ele?
• Um usuário tem deficiência visual e não pode ver que as instruções para usar uma página ou formulário seguem o conteúdo. Como o usuário saberia ler a página inteira para encontrar as instruções?
• Um usuário tem baixa visão e usa uma lupa de tela que se concentra e amplia apenas uma pequena parte da tela de uma só vez. Dadas as limitações da lupa, como o usuário saberia se uma mensagem aparece em outro lugar na tela?
• Um usuário é daltônico e não pode distinguir entre determinadas cores. Como o usuário saberia qual é o botão vermelho, azul ou verde referenciado no texto da página?

Estas são apenas algumas ilustrações das preocupações que um desenvolvedor precisa abordar ao criar um aplicativo web acessível. Essa programação de estudo fornece métodos claros para codificação e teste de acessibilidade a fim de cumprir os padrões mais atuais definidos pelo WCAG (Web Content Accessibility Guidelines) versão 2.2.

É prudente olhar atentamente para as orientações acima mencionadas, uma vez que elas formam a base do nosso trabalho em acessibilidade.

WCAG (Web Content Accessibility Guidelines)

O World Wide Web Consortium (W3C) criou um conjunto de padrões denominado WCAG (Diretrizes de Acessibilidade de Conteúdo da Web) que fornece regras muito específicas de como tornar sites e aplicativos Web acessíveis. Essas diretrizes formam a base dessa programação de estudo.

As normas WCAG se concentram em quatro áreas de um aplicativo web ou site:

1. Percebibilidade: A interface pode ser percebida pela grande maioria dos indivíduos, independentemente das deficiências?

   • Razões de contraste de cores que funcionam bem para pessoas com baixa visão
   • Simplicidade de layout que funciona bem para aqueles com déficits cognitivos

2. Operabilidade: Os indivíduos podem interagir com a interface independentemente das deficiências?

   • Acesso somente ao teclado: navegue e opere a interface sem o uso de um mouse
   • Acesso somente por voz: Opere a interface apenas por entrada de voz

3. Compreensibilidade: A interface é facilmente compreendida pelos indivíduos, independentemente das deficiências?

   • O conteúdo é escrito para ser compreendido por indivíduos com deficiências cognitivas.
   • A interface é entendida por um indivíduo usando um leitor de tela

4. Robustez: A interface suporta uma variedade de agentes de usuário (navegadores, dispositivos e tecnologias assistivas)?

Se os critérios WCAG forem atendidos, os aplicativos da Web e os sites também deverão passar por todos os requisitos legais.

O custo da acessibilidade

Deve-se notar que a acessibilidade nunca deve ser uma reflexão tardia ao escrever código. Embora o processo de desenvolvimento seja mais longo, é mais econômico gravar recursos de acessibilidade no código durante a fase de desenvolvimento do que modificar um aplicativo existente.

Os desenvolvedores muitas vezes reclamam da necessidade de acomodar os requisitos especiais de uma população indiscutivelmente pequena. Quando implementado corretamente, o código acessível, na verdade, facilita o uso de um aplicativo para todos, não apenas para os desabilitados. Por exemplo, ao simplificar a interface e escolher cores com maiores taxas de contraste, os aplicativos em dispositivos móveis ou navegadores mais antigos são mais simples de usar.

1, 2, 3 passos para o sucesso

A acessibilidade começa na fase de design. Os designers criam um plano gráfico do que o programa faz. Eles devem tecer a acessibilidade ao longo do projeto para garantir que o plano inclua mecanismos eficazes para acesso somente por teclado. Este tipo de acesso permite dispositivos de entrada alternativos para aqueles com limitações ou sem uso de suas mãos.

Os desenvolvedores precisam ter um forte conhecimento de como codificar para acessibilidade (front-end) e uma consciência técnica de como testar a acessibilidade (back-end).

Os engenheiros de garantia de qualidade (QA) precisam falar a linguagem da acessibilidade. Eles, como os desenvolvedores, precisam entender e executar testes de acessibilidade juntamente com os testes normais de funcionalidade e segurança. Os profissionais de garantia de qualidade são o buffer entre o software que é lançado e o potencial de litígio se as diretrizes de acessibilidade não forem atendidas.

Observações para Aviso

O Oracle JET está aberto ao público para uso em aplicativos e sites não Oracle. Portanto, o WCAG versão 2.2 deve ser respeitado ao gravar aplicativos Oracle JET.

Essa programação de estudo se concentra principalmente nos aspectos de acessibilidade que se aplicam ao acesso ao teclado e ao uso do leitor de tela. Essa programação não se concentra nos aspectos cognitivos de criação ou criação de um aplicativo Oracle JET.