Creación de Aplicaciones Accesibles de Oracle JET

Nota: Esta ruta de aprendizaje tiene un requisito: Desarrollar una aplicación web en Oracle JavaScript Extension Toolkit (Oracle JET), que se debe completar antes de comenzar este curso.

Introducción a la accesibilidad

Ahora que tiene una comprensión básica de cómo utilizar Oracle JET para desarrollar aplicaciones web, es hora de abordar las necesidades especializadas de casi el 10-20 por ciento de su público objetivo, aquellos con discapacidades. Según un artículo publicado por la Organización Mundial de la Salud en 2014, aproximadamente el 15 por ciento de la población mundial tiene algún tipo de discapacidad, y ese número crece con una población que envejece constantemente.

History

El concepto moderno de accesibilidad se originó a finales de 1960s como un movimiento de base en los campus universitarios y en las comunidades locales para abordar los derechos de las personas con discapacidad que buscan acceso físico a los edificios públicos. Este acceso incluyó rampas a lo largo de pasarelas públicas, entradas, puertas automáticas y etiquetas Braille en ascensores a edificios públicos, gubernamentales y universitarios.

Legislación sobre igualdad de acceso

Hoy en día, el "acceso" incorpora tanto el acceso físico a las estructuras como el acceso al panorama tecnológico actual de PC, computadoras portátiles, tabletas, teléfonos inteligentes y dispositivos controlados por voz como Amazon Alexa. La legislación en materia de igualdad de acceso sigue abordando las cuestiones del acceso físico y la tecnología de la que dependemos.

La accesibilidad del software está obligada por las leyes civiles en muchos países de todo el mundo. Por ejemplo:

• La Ley de Estadounidenses con Discapacidades en Estados Unidos
• La Ley de Accesibilidad para los Ontarianos con Discapacidades en Ontario, Canadá
• La Ley de Igualdad de 2010 en el Reino Unido

Desafíos al acceso - Tipos de obstáculos

Como diseñadores y desarrolladores de aplicaciones web, debemos ser conscientes de que los clientes discapacitados se enfrentan a obstáculos al acceder a la tecnología. Tenga en cuenta lo siguiente:

• Un usuario no puede manipular el ratón debido a problemas de movilidad (defecto congénito de nacimiento, enfermedad de Lou Gehrig, enfermedad de Parkinson, artritis reumatoide, lesión o un déficit relacionado con el envejecimiento). ¿Cómo activaría un usuario de este tipo texto que tenga un evento al hacer clic vinculado a él?
• Un usuario tiene una discapacidad visual y no puede ver que las instrucciones para utilizar una página o un formulario sigan el contenido. ¿Cómo sabría el usuario leer toda la página para encontrar las instrucciones?
• Un usuario tiene baja visión y utiliza una lupa de pantalla que se enfoca y agranda solo una pequeña porción de la pantalla a la vez. Dadas las limitaciones de la lupa, ¿cómo sabría el usuario si aparece un mensaje en otra parte de la pantalla?
• Un usuario es daltónico y no puede distinguir entre ciertos colores. ¿Cómo sabría el usuario cuál es el botón rojo, azul o verde al que se hace referencia en el texto de la página?

Estas son solo algunas ilustraciones de las preocupaciones que un desarrollador debe abordar al crear una aplicación web accesible. Esta ruta de aprendizaje proporciona métodos claros para la codificación y las pruebas de accesibilidad con el fin de cumplir con los estándares más actuales establecidos por las directrices de accesibilidad de contenido web (WCAG) versión 2.2.

Es prudente examinar detenidamente las directrices antes mencionadas, ya que constituyen la base de nuestro trabajo en materia de accesibilidad.

Directrices de Accesibilidad al Contenido Web (WCAG)

El World Wide Web Consortium (W3C) ha creado un conjunto de estándares denominados Web Content Accessibility Guidelines (WCAG) que proporcionan reglas muy específicas para hacer que los sitios web y las aplicaciones web sean accesibles. Estas directrices constituyen la base de esta ruta de aprendizaje.

Los estándares WCAG se centran en cuatro áreas de una aplicación web o sitio web:

1. Perceptibilidad: ¿Puede la interfaz ser percibida por una gran mayoría de personas, independientemente de su discapacidad?

   • Coeficientes de contraste de color que funcionan bien para aquellos con baja visión
   • Simplicidad de diseño que funciona bien para aquellos con déficits cognitivos

2. Operabilidad: ¿Pueden las personas interactuar con la interfaz independientemente de las discapacidades?

   • Acceso solo con teclado: navegue y opere la interfaz sin el uso de un mouse
   • Acceso solo por voz: opere la interfaz solo por entrada de voz

3. Comprensión: ¿La interfaz es fácilmente entendida por las personas independientemente de las discapacidades?

   • El contenido está escrito para ser entendido por personas con discapacidades cognitivas.
   • La interfaz es entendida por un individuo usando un lector de pantalla

4. Robustez: ¿La interfaz admite una variedad de agentes de usuario (navegadores, dispositivos y tecnologías de asistencia)?

Si se cumplen los criterios de WCAG, las aplicaciones web y los sitios web también deben cumplir con todos los requisitos legales.

El costo de la accesibilidad

Cabe señalar que la accesibilidad nunca debe ser una idea tardía al escribir código. Aunque el proceso de desarrollo es más largo, es más rentable escribir características de accesibilidad en el código durante la fase de desarrollo que modificar una aplicación existente.

Los desarrolladores a menudo se quejan de la necesidad de satisfacer las necesidades especiales de una población posiblemente pequeña. Cuando se implementa correctamente, el código accesible en realidad hace que una aplicación sea más fácil de usar para todos, no solo para los discapacitados. Por ejemplo, al simplificar la interfaz y elegir colores con mayores ratios de contraste, las aplicaciones en dispositivos móviles o navegadores más antiguos son más fáciles de usar.

1, 2, 3 pasos para el éxito

La accesibilidad comienza en la fase de diseño. Los diseñadores crean un plano de lo que hace el programa. Deben tejer la accesibilidad en todo el diseño para garantizar que el plan incluya una mecánica efectiva para el acceso solo con teclado. Este tipo de acceso permite dispositivos de entrada alternativos para aquellos con uso limitado o sin uso de sus manos.

Los desarrolladores deben tener un sólido conocimiento práctico de cómo codificar la accesibilidad (front-end) y un conocimiento técnico de cómo probar la accesibilidad (back-end).

Los ingenieros de control de calidad (QA) necesitan hablar el idioma de la accesibilidad. Ellos, como los desarrolladores, necesitan comprender y realizar pruebas de accesibilidad junto con las pruebas normales de funcionalidad y seguridad. Los profesionales de control de calidad son el buffer entre el software que se libera y el potencial de litigio si no se cumplen las directrices de accesibilidad.

Notas a la notificación

Oracle JET está abierto al público para su uso en aplicaciones y sitios web que no sean de Oracle. Por lo tanto, se debe cumplir la versión 2.2 de WCAG al escribir aplicaciones de Oracle JET.

Esta ruta de aprendizaje se centra principalmente en los aspectos de accesibilidad que se aplican al acceso al teclado y al uso del lector de pantalla. Esta ruta no se centra en los aspectos cognitivos del diseño o la creación de una aplicación de Oracle JET.