Share via

Aplicaciones modernas

  • Artículo

Diseño y desarrollo de aplicaciones modernas accesibles

Rachel Appel

Rachel Appel¿Qué valor tiene la tecnología (Internet, las aplicaciones y los distintos formatos multimedia) si no implica un beneficio humano? Desafortunadamente, hay una gran cantidad de software que no beneficia a todas las personas. Los diseñadores, administradores y desarrolladores a menudo prestan más atención a la seguridad y el rendimiento que a la accesibilidad. La accesibilidad suele tener una prioridad baja en el software, si es que siquiera tiene prioridad alguna.

La accesibilidad debería tener una prioridad más alta. WebAIM calcula el 20 por ciento de los usuarios web tienen necesidades de accesibilidad o dependen de tecnologías de asistencia. Eso implica que hay más de 60 millones de personas solo en Estados Unidos que pueden tener problemas para usar su aplicación o sitio web, o consumir contenido. Para la mayoría de aplicaciones y sitios web, los clientes perdidos implican directamente pérdidas de ingresos. En mi PDF, "The Importance of Accessibility", explico muchas otras razones para ofrecer un diseño accesible (puede descargarlo en bit.ly/1CIx4k4).

Los aspectos fundamentales de la accesibilidad

Al diseñar y desarrollar con la accesibilidad en mente, tenga en cuenta las amplias categorías de discapacidades:

  • Visuales: Las personas con discapacidades visuales van desde las que tienen una visión deficiente a las que son ciegas, pasando por un espectro de daltonismo.
  • Auditivas: Las personas con problemas de audición pueden tener una sordera parcial o total.
  • Motoras: Hay muchas personas con discapacidades motoras. Algunos han sufrido la pérdida completa una extremidad o la posibilidad de usarla. Otras pueden padecer una neuropatía por causa de un accidente o enfermedad. Las personas con una discapacidad motora pueden necesitar dispositivos de entrada especializados.
  • Cognitivas: Las personas con discapacidades de aprendizaje, entre las que se incluyen el TDAH y la dislexia, a menudo tienen dificultades para consumir información, dependiendo de su presentación.

Muchas personas requieren algún tipo de tecnología de asistencia. Una tecnología de asistencia es cualquier herramienta o tecnología que se utiliza para ayudar en las actividades diarias para hacerlas más fáciles o posibles. Normalmente la gente no considera que las gafas sean una tecnología de ayuda, pero lo son: si bien es cierto que en el extremo inferior de la escala de tecnologías. Algunos usuarios de tecnología no pueden utilizar nada sin sus gafas. Entre las tecnologías de asistencia comunes se incluyen los lectores de braille, las varillas bucales, los licornios, los teclados adaptables, el software con reconocimiento de voz, etc.

 Diseño y contenido accesibles

Encontrará que el diseño más accesible a menudo se considera un diseño excelente. Hay demasiados sitios web que tienen demasiados anuncios mezclados en el flujo del contenido, lo que interrumpe en gran medida el flujo del lector. Otros tienen menús y aspectos de navegación difíciles de usar. El diseño y la navegación de una aplicación o sitio web son consideraciones importantes que se deben tener en cuenta cuando se consideran las necesidades de accesibilidad.

Al organizar contenido, separarlo en distintas secciones con encabezados claros. Las películas, música y animaciones deben incluir subtítulos o transcripciones como parte del contenido. La mayoría del software de creación de películas disponible hoy día permite introducir transcripciones para subtítulos (CC).

Un buen diseño también implica disponer de un esquema de navegación coherente y transparente. Los menús en cascada de JavaScript suelen ser difíciles para los usuarios que no tienen discapacidades. Son todavía peores para aquellos con un problema motor. Los vínculos en la parte superior o en el lado de una página web funcionan mucho mejor. En las aplicaciones para teléfonos, querrá ir en sintonía con el esquema de navegación del dispositivo de destino. Para obtener más información sobre la navegación en Windows 8.x, consulte mi columna de agosto de 2013, "Principios básicos de navegación en las aplicaciones de la Tienda Windows" (msdn.microsoft.com/magazine/dn342878).

Las fuentes deben ser grandes y nítidas. Las fuentes de tipo script son más difíciles de leer. Hay muchos motivos que pueden provocar que algunos caracteres de una fuente no se vean con claridad. Uno es la dislexia, un trastorno de aprendizaje que provoca la incapacidad de distinguir entre letras que parecen iguales. Se estima que un cinco por ciento de la población tiene dislexia. Las letras que se muestran de una forma para las personas que no tienen dislexia, parecen estar rotadas o al revés para los disléxicos.

Con estos conocimientos sobre la dislexia, los chicos de dyslexiefont.com crearon una fuente que cambia las letras ligeramente para que los disléxicos puedan leerlas con mayor facilidad. Hasta ahora, los evaluadores de fuentes aseguran que les encanta. Puede elegir no usar dyslexiefont y no pasa nada. No significa que esté despreciando a los disléxicos. Sin embargo, asegúrese de elegir una fuente que sea fácil de leer.

Podría querer reconsiderar cambiar si fuente si su aplicación tiene a empresarios como destino. Los colores de la fuente deberían tener también un contraste alto. Un buen ejemplo de contraste alto es un fondo blanco o claro con texto negro u oscuro. De la forma completamente opuesta también se cumple. El uso de texto claro en fondos oscuros también funciona bien. Normalmente, cuál usar es una cuestión de preferencias y de estilo, siempre que haya suficiente contraste.

No se puede equivocar con una estrategia de diseño móvil en primer lugar. Los diseños móviles en primer lugar suelen conducir a hacer el mejor uso posible del espacio. La mayoría de teléfonos y tabletas pequeñas solo tienen unos centímetros de espacio para el contenido. Esto significa que la aplicación normalmente solo presenta la información más importante. En este caso, sencillamente no hay espacio para anuncios verticales.

Existen otras buenas prácticas de diseño que puede seguir y también ayudan a garantizar la accesibilidad. Piense en los sitios sociales y de noticias más populares de la web. Muchos de ellos no son accesibles o solo lo son mínimamente. A menudo contienen elementos emergentes que interfieren y pueden detener por completo los lectores de pantalla y también a las personas. Estos mismos elementos emergentes suelen tener diminutos botones para cerrarlos que son difíciles de encontrar e imposibles de pulsar o hacer clic, incluso con dispositivos estándares.

Otros usan elementos emergentes en serie. Cuando finalmente consigue deshacerse de un elemento emergente, otro ocupa su lugar. Esto es frustrante. Muchas personas con necesidades de accesibilidad se niegan a visitar estos sitios, ya que simplemente no merece la pena tanta molestia.

Es importante también evitar los efectos estroboscópicos, los efectos intermitentes o las imágenes que parpadean sin previo aviso. Suponen un riesgo de padecer un ataque. Además, normalmente son molestos, a menos que su objetivo sea específicamente un efecto o ilusión óptica.

No use solamente colores para transmitir mensajes a los usuarios. Por ejemplo, muchos formularios utilizan una fuente de color rojo para indicar que se trata de un campo obligatorio. Los usuarios daltónicos no pueden ver esa diferencia. No utilice la frase "haga clic aquí" como texto del vínculo. Eso no ayuda nada a los lectores de pantalla. En su lugar, use algo descriptivo.

Código accesible de programa

Existen técnicas de programación que puede utilizar para desarrollar aplicaciones y sitios web accesibles. Como programador, necesitará interactuar con las entradas y salidas. Esto significa que debe tener en cuenta que diferentes personas necesitan formas distintas de interactuar con el software y que no solo se utilizan el mouse y el teclado.

Para quienes usan principal o exclusivamente el teclado, asegúrese de que el orden de tabulación de los campos es lógico y está en orden. También debería etiquetar los campos y elementos como los botones con el elemento de HTML <label>. Esto garantiza una mayor claridad. Las imágenes deberían tener atributos alt establecidos con algo descriptivo y conciso. Los lectores de pantalla no pueden leer por arte de magia las imágenes y por eso usan la etiqueta alt para describirle la imagen al usuario.

HTML5 contiene un conjunto de elementos denominados elementos semánticos. El objetivo de estos elementos es que tanto máquinas como humanos puedan leer y entender fácilmente los elementos HTML. Los elementos semánticos describen su contenido de forma muy parecida a XML. Por ejemplo, cualquier persona que sepa inglés puede entender los siguientes elementos semánticos simplemente leyéndolos: caption, figure, article, footer, header, summary, time, nav, mark y main, por nombrar algunos.

Para los que dependen de un lector de pantalla, los vínculos de omisión son salvavidas. Un vínculo de omisión permite que un lector pase de largo de los elementos de navegación y anuncios en un sitio web y vaya directamente al contenido deseado. Tener que esperar varias insoportables e innecesarias iteraciones de opciones y anuncios no es nada divertido. No obligue a sus usuarios a tener que padecer una experiencia tan desagradable. Inmediatamente después del elemento <body> es donde se sitúa el vínculo de omisión de navegación principal, como se muestra en el código siguiente:

<body>
<a href="#maincontent">Skip to main content</a>
<nav><!-- navigation here --></nav>
<main id="maincontent">
<p>The quick brown fox jumps over the lazy dog.</p>

Cuando un lector de pantalla ve el vínculo de omisión, se centra en el elemento al que hace referencia el vínculo de omisión por su identificador. Esto significa que en el ejemplo anterior, el vínculo de omisión apunta al elemento <main> con el identificador "maincontent". Dado que los vínculos de omisión deben ser el primer elemento y muchos diseñadores prefieren que el vínculo de omisión se ubique en otro sitio, puede ocultarlo y hacerlo visible para la tecnología de asistencia con algo de CSS, tal y como se muestra en este código:

.skiplink-offscreen {
  position:absolute;
  left:-10000px;
  top:auto;
  width:1px;
  height:1px;
  overflow:hidden;
}

Como puede ver, es un selector de clase posicionado de forma absoluta con un atributo de valor establecido en -10000px. El overflow está establecido como hidden. El código coloca el elemento que utiliza este selector donde el usuario nunca lo verá, pero un lector de pantalla sí. Los lectores de pantalla omiten los elementos con los atributos hidden o display establecidos en hidden o none. Por eso debería utilizar este pequeño truco.

Desarrollo con ARIA

ARIA (Accessible Rich Internet Applications) son un conjunto de atributos estándares que puede aplicar al marcado (como HTML) que ayudan a que las tecnologías de asistencia funcionen de forma eficaz. Con ARIA, puede definir un elemento por su estado, propiedad o función. A partir de esa información, los lectores de pantalla pueden determinar lo que el software está haciendo.

Por ejemplo, una casilla de verificación puede tener un estado de ARIA checked. O bien, un elemento puede asumir el rol de un menú. Este mínimo de información adicional sobre el estado o rol ayuda a que los lectores de pantalla construyan una mejor representación del contenido de la página web. Estos atributos no cambian el elemento, sino que hacen que el elemento tenga una naturaleza más semántica. El marcado semántico es más fácil de entender para los seres humanos y las máquinas. Por ejemplo, el código siguiente muestra un artículo con una sección semántica, para que un lector de pantalla pueda identificar mejor el contenido relacionado y lo transmita al usuario:

<article>
<section aria-labelledby="ProgrammingBestPractices">
  <h2 id="ProgrammingBestPractices">Best Practices for Programmers</h2>
  <ol>
  <li>Take a few minutes a day to refactor small portions of code.</li>
  <li>Learn a new programming language every year.</li>
  </ol>
</section>
</article>

Puede extender este marcado semántico y accesible a los formularios HTML. Los lectores de pantalla necesitan conocer los elementos que etiquetan o describen los campos de los formularios, y qué campos están relacionados como un grupo. El estado de los botones y las casillas de verificación son otros aspectos que deben conocer los lectores de pantalla. Un buen diseño de formularios implica conocer de qué forma afectan los scripts a la tecnología de asistencia. Podría querer volver a considerar el código que establece automáticamente el foco en un control o que cambia de forma dinámica el estado de los controles de los formularios.

Utilice el elemento de HTML <label> para etiquetar elementos de formulario individuales con etiquetas únicas. Sin embargo, habrá veces que necesitará etiquetar un elemento con varias etiquetas, como en una tabla. Eso no es un problema. El atributo aria-labelledby funciona en esos casos. Establezca aria-labelledby de cada elemento del grupo para los identificadores de elemento que llevarán a cabo el etiquetado. Puede usar tanto el elemento <label> como el atributo aria-labelledby en el mismo formulario. No es necesario etiquetar los botones de envío o de restablecimiento, a menos que sean botones de imagen. A continuación, asegúrese de establecer el atributo alt.

Todos los formularios tienen elementos obligatorios y elementos con restricciones específicas sobre el tipo de datos que aceptan. La mayoría de formularios ejecutan JavaScript para realizar la comprobación de los campos obligatorios y restringidos. Lo hacen antes de enviar todos los datos al servidor para su procesamiento, ya que es mejor notificar los errores al usuario lo más pronto posible. Los lectores de pantalla tienen dificultades para distinguir qué sucede en la página cuando se ejecuta un script. Para resolver este problema, utilice los atributos aria-required y aria-invalid, como se muestra en la Figura 1.

Figura 1. Formulario HTML accesible con atributos ARIA

<form>     
  <div>
    <label for="name">* Name:</label>
    <input type="text" id="name" aria-required="true" />
  </div>
  <div>
    <label for="checkboxGroupLabel">* Language</span>
    <ul role="radiogroup" aria-labelledby="checkboxGLabel">
      <li role="checkbox"><input type="checkbox" value="C#"
        name="language" aria-checked="false" />C#</li>
      <li role="checkbox"><input type="checkbox" value="JavaScript"
        name="language" aria-checked="false" />JavaScript</li>
      <li role="checkbox"><input type="checkbox" value="Python"
        name="language" aria-checked="false" />Python</li>
    </ul>
  </div>
  <div>
    <span id="yearsLabel">* Years Experience</span>
    <select name="YearsExperience" aria-labelledby="yearsLabel" >
      <option value="1">1-5 Years</option>
      <option value="6">6-10 Years</option>
      <option value="10">10-20 Years</option>
      <option value="20">20+ Years</option>
    </select>
  </div>
  <div>
    <input type="submit" alt="Submit" />
  </div>
</form>

También se muestra en la Figura 1 un ejemplo de aria-required y aria-labelledby, así como el uso de roles. Simplemente se agrega algo de HTML adicional, pero pasa desapercibido. No cuesta mucho esfuerzo y proporciona un gran valor.

La tecnología de asistencia debe ocuparse de más cosas que los elementos estáticos. JavaScript, las llamadas a AJAX y las aplicaciones de estilo SPA cambian con frecuencia el contenido de las aplicaciones y los sitios web. En algunos casos, los scripts dinámicos como estos interfieren con los lectores de pantalla. Debe restablecer el estado de algunos atributos ARIA, como aria-invalid, tras una validación de JavaScript.

Pruebas del código accesible

Pruebe la aplicación descargando software de lectura de pantalla y probando las tecnologías de asistencia por usted mismo. Cierre los ojos y use el lector de pantalla como si no pudiera ver. Los comentarios de sus usuarios que utilicen tecnología de asistencia también es una buena manera de comprobar cómo de accesible es el software que ha creado. Aquí se muestran algunos lectores de pantalla que puede descargar y usar:

Cuando haya probado los lectores, WebAIM tiene una completa lista de comprobación y un analizador de páginas denominado Web Accessibility Evaluation tool (WAVE), que notifica errores, advertencias y otra información sobre el estado de accesibilidad de una página. Es muy sencillo de usar. Vaya a wave.webaim.org e introduzca la dirección URL que desea analizar. WAVE muestra la página de destino en línea y anota los elementos y puntos problemáticos que puede cambiar para mejorar la accesibilidad. En la Figure 2se muestra el escáner en acción, que marca algunos elementos de la página de la edición de enero de 2015 de MSDN Magazine.

MSDN Magazine tras introducirla en WAVE Scanner
Figura 2 MSDN Magazine tras introducirla en WAVE Scanner

Haga clic en cualquiera de los elementos anotados y WAVE mostrará información del error o los metadatos sobre el elemento. El analizador examina todo, desde los atributos label y alt que faltan, a los problemas de contraste. Los marca como errores o advertencias para que pueda cambiar primero los problemas más importantes. Puede ejecutar una versión independiente de WAVE o puede agregar la API a los procesos automáticos de control de calidad.

Resumen

El diseño accesible suele ser un mejor enfoque de diseño para todos los usuarios. Un diseño que no es accesible deja fuera a un porcentaje considerable de la población, por lo que dedicar el esfuerzo en hacer que el software sea accesible es una decisión empresarial inteligente. Las interfaces de usuario deberían presentar opciones claramente etiquetas y fáciles de encontrar, y asegurarse de que los pasos para completar una tarea sean sencillos y simples.  Cuando se diseña para mejorar la accesibilidad, conseguirá automáticamente un sistema claro y fácil de usar que funciona bien para todo el mundo.

Rachel Appel es una consultora, autora, mentora y empleada de Microsoft con más de 20 años de experiencia en la industria de TI. Da conferencias en los principales acontecimientos de la industria, como Visual Studio Live!, DevConnections, Mix y muchos otros. Su experiencia se basa en el desarrollo de soluciones que alinean la empresa y la tecnología en la pila del dispositivo y web abierta de Microsoft. Para obtener más información sobre Appel, visite su sitio web en rachelappel.com.

Gracias al siguiente experto técnico de Microsoft por revisar este artículo: Frank La Vigne