Guías de Accesibilidad de la Ley 229 para Páginas Web de Agencias del Gobierno de Puerto Rico

Guía introductoria para identificar los recursos y elementos esenciales que permiten mejorar la accesibilidad de las páginas web.

Introducción

La Ley 229 del 2 de septiembre de 2003, según enmendada, garantiza el acceso a la información a las personas con impedimentos. Mediante esta ley, se busca lograr que las páginas electrónicas de las agencias gubernamentales sean accesibles a esta población. Para ello, se han desarrollado varias iniciativas, que incluyen la creación de estas Guías de Accesibilidad. Este documento está dirigido a Web Masters y personal técnico a cargo de crear, modificar y mantener las páginas web de las agencias y los municipios del Gobierno de Puerto Rico.

Estas guías también son pertinentes a cualquier entidad que esté obligada o desee voluntariamente cumplir con los parámetros necesarios para lograr que sus páginas web sean accesibles a la población de personas con impedimento.

Definiciones

Para efectos de este documento, se utilizarán los siguientes términos, definiciones y formatos:

TIENE – Denota un parámetro obligatorio que debe ser cumplido a cabalidad.

DEBERÍA – Indica un parámetro de accesibilidad altamente recomendado.

PODRÍA – Denota un parámetro de accesibilidad sugerido u opcional.

Contenido

Idioma
1. El idioma primario de la página TIENE que ser definido en concordancia al idioma del contenido, utilizando el atributo “lang” dentro de la etiqueta “html”. Esto permite que los lectores de pantalla cambien automáticamente al idioma configurado en la página. Ejemplo: <html lang=”es-PR”>.
2. Cambios en el idioma en partes del contenido TIENEN que ser definidos utilizando el atributo “lang” dentro del elemento correspondiente. Ejemplo: <span lang=”en-US”>This is an inline language change inside an HTML element.</span>.
Título de la página
1. TIENE que ser definido dentro de la etiqueta <title>. Ejemplo: <title>Accesibilidad de las páginas web</title>
2. TIENE que ser actualizado cuando cambie la dirección de la página web.
3. TIENE que ser descriptivo e informativo.
Puntos de referencia (Landmarks)
1. DEBERÍAN ser utilizados, combinando HTML 5 y ARIA, para designar las regiones predefinidas del diseño de la página. Esto facilitará que los usuarios de lectores de pantalla puedan moverse rápidamente entre regiones predefinidas, como el contenido principal, área de navegación, área de búsqueda, etc. Ejemplo: <header role=”banner”>, <form role=”search”>, <nav role=”navigation”>, <main role=”main”>, <footer role=”contentinfo”>.
Encabezados (Headings)
1. Texto que visualmente aparenta ser un encabezado TIENE que ser definido como un encabezado real, utilizando las etiquetas <h1>, <h2>, etc. Los lectores de pantalla no infieren el significado del texto con formato que luce como un encabezado, ejemplo: negrita (bold) o tamaño de letra más grande.
2. TIENEN que ser descriptivos e informativos. Ejemplo: <h1>Accesibilidad de las páginas web</h1>.
3. No DEBERÍA haber un salto en el uso de los niveles de jerarquía de encabezados. No recomendado: <h1>Accesibilidad de las páginas web</h1>, <h4>Campos de formulario</h4>, <h3>Campos de texto</h3>. Recomendado: <h1>Accesibilidad de las páginas web</h1>, <h2>Campos de formulario</h2>, <h3>Campos de texto</h3>.
4. El contenido principal DEBERÍA iniciar con un encabezado de nivel 1. Ejemplo: <h1>Accesibilidad de las páginas web</h1>.
Enlaces (Links)
1. Texto que visualmente aparenta ser un enlace TIENE que ser definido como un enlace real, utilizando la etiqueta <a>. Un enlace llevará al usuario a otro lugar en la página, a otra página del sitio web, a un sitio web externo o abrirá un documento alterno como un archivo PDF.
2. TIENEN que tener un nombre distintivo, basado en texto. El texto distintivo será anunciado por el lector de pantalla. Ejemplo: <a href=”http://www.pratp.upr.edu”>Programa de Asistencia Tecnológica de Puerto Rico</a>.
3. Características como etiquetas, nombres o texto alternativo para el contenido con la misma funcionalidad, DEBERÍAN ser identificadas de manera consistente en todas las páginas del sitio web.
4. Un enlace que abre en una ventana o pestaña nueva, que abre una página externa o que abre un documento alterno, DEBERÍA indicar claramente su propósito.
Navegación
1. Un enlace de saltar navegación DEBERÍA incluirse como el primer elemento con foco en la página, de modo que los usuarios de teclado puedan ir directamente al contenido principal.
2. Este enlace TIENE que estar visible en todo momento o cuando adquiera el foco por navegación de teclado.
3. Una tabla de contenido, que refleje la estructura de los encabezados en la página, PODRÍA ser incluida al inicio del contenido principal o en el área de navegación.
4. Una lista de navegación o vista de páginas DEBERÍA incluir un método visible y con texto, que le informe a los usuarios cual es la página activa.
Tablas
1. Contenido que visualmente aparenta ser una tabla TIENE que ser incluido dentro de una tabla real, utilizando la etiqueta <table>. Una tabla se utiliza para organizar datos, no para dar diseño a la página.
2. Las tablas de datos DEBERÍAN tener un título asociado de forma programática, mediante el uso de la etiqueta <caption>. Este título también puede ser definido utilizando “aria-label” o “aria-labelledby”.
3. Las celdas que contengan los títulos de las filas o columnas TIENEN que ser definidas utilizando la etiqueta <th>.
4. Tablas complejas DEBERÍAN usar los atributos “scope” o “headers + id” para establecer una asociación programática entre las celdas y las columnas o filas de título. Ejemplo de asociación simple mediante “scope”: <th scope=”col”>, <th scope=”row”>, <th colspan=”2” scope=”colgroup”>, o <th rowspan=”2” scope=”rowgroup”>. Ejemplo de asociación compleja mediante “headers + id”: <th rowspan=”2” id=”fecha”, <th colspan=”2” id=”lunes”; <td headers=”fecha lunes”>.
5. Un resumen del contenido de la tabla no es requerido, pero si es necesario incluir alguno, este TIENE que ser creado utilizando “id + aria-describedby”. Ejemplo: <p id=”resumen”>La tabla a continuación...</p>, <table aria-describedby=”resumen”>.
Listas
1. Contenido que visualmente aparenta ser una lista TIENE que ser incluido dentro de una lista real, utilizando las etiquetas correspondientes.
2. Las listas no ordenadas TIENEN que ser creadas utilizando la etiqueta <ul>, en combinación con la etiqueta <li> para los elementos de lista. Ejemplo: <ul>, <li>Café expreso</li>, <li>Chocolate caliente</li>, <li>Té verde</li>, </ul>.
3. Las listas ordenadas TIENEN que ser creadas utilizando la etiqueta <ol>, en combinación con la etiqueta <li> para los elementos de lista. Ejemplo: <ol>, <li>2 cucharadas de harina de café</li>, <li>1 taza de agua</li>, <li>2 cucharaditas de azúcar</li>, </ol>.
4. Las listas de definición o descripción TIENEN que ser creadas utilizando la etiqueta <dl>, en combinación con la etiqueta <dt> para los términos y la etiqueta <dd> para las definiciones. Ejemplo: <dl>, <dt>HTML</dt>, <dd>Formato de las páginas web</dd>; <dt>docx</dt>, <dd>Formato nativo de los documentos de Microsoft Word</dd>, </dl>.
Marcos en línea (iframes)
1. La página fuente de un marco en línea TIENE que tener un elemento de título (<title>), que cumpla con los requerimientos establecidos en la guía #2 de este documento.
2. Los marcos en línea TIENEN que tener un título definido mediante el atributo “title”. Para proveer mayor accesibilidad, se recomienda que el texto definido en el atributo “title” sea idéntico al título de la página fuente del marco en línea. Ejemplo: título de la página fuente del marco en línea: <title>Blog de Asistencia Tecnológica — Programa de Asistencia Tecnológica de Puerto Rico</title>. Declaración del marco en línea: <iframe title=”Blog de Asistencia Tecnológica — Programa de Asistencia Tecnológica de Puerto Rico” width=”500” height=”300” src=”http://www.pratp.upr.edu/blog”> </iframe>.
Imágenes
1. Imágenes que comuniquen contenido TIENEN que tener un texto alternativo, que será definido utilizando el atributo “alt” en la etiqueta <img>.
2. El texto alternativo TIENE que ser descriptivo e informativo, que comunique el propósito de la imagen, de manera que sea útil para una persona que no pueda ver la misma. Ejemplo: <img src="./images/baston.jpg" alt="Persona ciega caminando con un bastón blanco">.
3. El texto alternativo DEBERÍA ser conciso, no mayor de 250 caracteres.
4. Imágenes decorativas, que no comuniquen propósito o que son redundantes a un contenido que haya sido definido en el contexto de la página web, TIENEN que ser definidas utilizando un texto alternativo nulo (alt=””), con role=”presentation”, o implementar las mismas como un fondo CSS. Ejemplo: Imagen con un texto alternativo nulo dentro de un enlace para evitar duplicidad de elementos: <a href="http://www.pratp.upr.edu"> <img src="logo_pratp.png" width="100" height="100" alt=””>Sitio web del PRATP</a>
5. Imágenes complejas TIENEN que ser descritas en un texto alternativo corto y TIENEN que incluir una descripción más detallada, utilizando una de las siguientes opciones:
  1. Proveer una descripción detallada en el contexto de la página web.
  2. Proveer un botón que expanda una región que contenga la descripción detallada.
  3. Proveer un botón que abra un diálogo que contenga la descripción detallada.
  4. Proveer un enlace que contenga la descripción detallada en otra página del sitio web.
6. El texto alternativo de la etiqueta <img>, así como las etiquetas <area> dentro de un mapa de imagen (image map), TIENE que cumplir con los requerimientos establecidos en los parámetros “B” y “C”, descritos anteriormente en esta guía.
7. Las imágenes XVG TIENEN que incluir las siguientes características:
  1. El atributo ARIA (role=”img”) para que los lectores de pantalla las identifiquen como imágenes.
  2. Texto alternativo definido dentro de la etiqueta <title>.
  3. Los atributos “aria-labelledby” y “id” para que todo el texto incluido dentro de las etiquetas <title>, <desc> y <text> pueda ser anunciado por un lector de pantalla.
8. Los iconos de fuente (icon fonts) TIENEN que incluir las siguientes características:
  1. El atributo ARIA (role=”img”) cuando sea necesario que los lectores de pantalla los identifiquen como imágenes.
  2. Texto alternativo que será definido utilizando el atributo aria-label dentro del elemento correspondiente.
9. El atributo aria-hidden=”true”`en el caso de que el icono sea redundante o que haya sido definido dentro del contexto de la página web.
10. Las gráficas o imágenes definidas utilizando la etiqueta HTML 5 <canvas> TIENEN que tener las siguientes características:
  1. El atributo ARIA (role=”img”) cuando sea necesario que los lectores de pantalla las identifiquen como imágenes.
  2. Texto alternativo que será definido utilizando el atributo aria-label o aria-labelledby.
Diseño visual y colores
1. Información que sea comunicada mediante el uso del color TIENE que ir acompañada de una alternativa basada en texto. No recomendado: Un sitio web de venta de boletos le informa a sus usuarios que las funciones marcadas en rojo están agotadas. Una persona ciega o con ceguera al color (daltonismo) no podrá identificar dichas funciones, porque el único método que fue empleado para comunicar esa información fue mediante el uso del color. Recomendado: El sitio web, en adición a indicar la información mediante el uso del color, tiene que incluir una alternativa de texto que le comunique al usuario cada una de las funciones agotadas.
2. El color no DEBERÍA ser el único método para distinguir enlaces, botones y otros elementos del resto del contenido, a menos que el contraste entre estos sea igual o mayor de 3 a 1.
3. Texto pequeño, cuyo tamaño de fuente sea menor de 18 puntos letra regular o 14 puntos letra en negrita, TIENE que tener un contraste de, al menos,5 a 1 con el fondo. El sitio web de Juicy Studio contiene una alternativa gratuita que puede ser utilizada para validar el rango de contraste entre texto y el fondo. Más información en: http://juicystudio.com/services/luminositycontrastratio.php.
4. Texto grande, cuyo tamaño de fuente sea mayor de 18 puntos letra regular o 14 puntos letra en negrita, TIENE que tener un contraste de, al menos, 3 a 1 con el fondo.
5. Requerimientos para la tipografía de una página web, que facilitarán la lectura a usuarios con baja visión y con retos en la lectura:
  1. Utilizar fuentes serif como Times New Roman y Georgia, o sans-serif como Arial, Tahoma o Verdana.
  2. El espacio del contenido dentro de un párrafo DEBERÍA ser de, al menos, 1.5 líneas.
  3. El espacio entre párrafos DEBERÍA ser mayor o igual a 1.5 veces más que el espacio entre líneas.
  4. Una línea dentro de una columna o párrafo no DEBERÍA exceder los 80 caracteres.
  5. El texto únicamente DEBERÍA ser justificado a la izquierda. No utilizar justificación completa.
Multimedios, movimiento y animaciones
1. Requerimientos para multimedios pregrabados, video y audio:
  1. TIENEN que incluir una representación simultánea de texto, de preferencia cerrada (closed captions), que les proveerá a las personas sordas acceso a la narración, los diálogos y los sonidos ambientales más significativos presentados en el video.
  2. DEBERÍAN incluir una descripción de audio, que le proveerá a las personas ciegas una mejor comprensión de los aspectos visuales más significativos presentados en el video. La descripción de audio DEBERÍA ser incluida preferiblemente en un archivo de audio alterno, que pueda ser activado o desactivado en cualquier momento, similar a los archivos de audio disponibles en las películas o series de TV.
  3. DEBERÍAN incluir una transcripción de texto, que le proveerá a las personas sordo-ciegas acceso a la narración, los diálogos, los aspectos visuales esenciales y los sonidos ambientales más significativos presentados en el video. Las personas sordo-ciegas podrán leer este archivo utilizando una línea braille.
  4. PODRÍAN incluir una interpretación en lenguaje de señas, que le proveerá a las personas sordas acceso a la narración, los diálogos y los sonidos ambientales más significativos presentados en el video. Esta interpretación podría ser incluida integrando al intérprete de lenguaje de señas al video, en una ventana secundaria (picture in picture), o en un archivo de video sincronizado.
2. Requerimientos para multimedios pregrabados, solo video:
  1. DEBERÍAN incluir una descripción de audio.
  2. DEBERÍAN incluir una transcripción de texto.
3. Requerimientos para multimedios pregrabados, solo audio.
  1. DEBERÍAN incluir una transcripción de texto.
  2. PODRÍAN incluir una interpretación en lenguaje de señas.
4. El reproductor de multimedios TIENE que ser accesible, preferiblemente basado en HTML5. Un lector accesible TIENE que contar con las siguientes opciones:
  1. Métodos para incluir representación simultánea de texto, descripción de audio y, en la medida que sea posible, transcripción de texto e interpretación en lenguaje de señas.
  2. Controles accesibles para usuarios de teclado, con baja visión, y de lectores de pantalla. Algunos ejemplos de reproductores de multimedios accesibles son:
    1. Able Player: https://ableplayer.github.io/ableplayer/
    2. OzPlayer: https://www.accessibilityoz.com/ozplayer/
    3. Nomensa Media Player: https://github.com/nomensa/Accessible-Media-Player
    4. PayPal Media Player: https://github.com/paypal/accessible-html5-video-player
5. Los sonidos ambientales en multimedios pregrabados DEBERÍAN ser configurados a un volumen más bajo, excepto los sonidos ocasionales (no más de 2 segundos de duración). Las personas que utilizan dispositivos de escucha amplificada, como audífonos, podrían tener serias dificultades para comprender la narración o los diálogos, si los sonidos ambientales están configurados al mismo volumen del sonido primario.
6. Para el contenido en audio que se reproduzca de forma automática por más de 3 segundos en una página web, TIENE que incluirse un método para pausar, detener o disminuir volumen. Es altamente recomendado evitar la inclusión de contenido en audio que se reproduzca de forma automática. Las personas ciegas podrían tener serias dificultades para escuchar al lector de pantalla si otra fuente de audio está en reproducción.
7. Una página web TIENE que utilizar contenido que no parpadee más de 3 veces por segundo, a menos que este sea lo suficientemente pequeño, o de bajo contraste. El contenido que parpadee más de 3 veces por segundo podría causar convulsiones a personas con epilepsia foto-sensitiva. El sitio web Trace Research & Development Center ha desarrollado una herramienta gratuita para detectar contenido que podría causar epilepsia foto-sensitiva. Más información en: http://trace.umd.edu/peat.
8. Para el contenido que se reproduzca de forma automática por más de 5 segundos en una página web, TIENE que incluirse un método para pausar, detener u ocultar las animaciones o los videos de fondo. Este contenido podría provocar mareos en personas con problemas para mantener el balance y causar serias distracciones a personas con retos de atención.
Métodos de entrada independiente: mouse, teclado y pantallas táctiles
1. El área predeterminada para realizar clic DEBERÍA ser lo suficientemente amplia como para facilitarle el uso del ratón a las personas con retos de movilidad. Cuando el área para realizar el clic es reducida, las personas con temblores en sus manos, y otros retos en la movilidad, pueden tener dificultades al utilizar el mouse, activando por error enlaces o botones cercanos al elemento que desean acceder.
2. Todos los enlaces, botones y otros controles interactivos TIENEN que obtener el foco mediante navegación de teclado. Las personas ciegas, con retos de movilidad y otros usuarios de teclado, navegan una página web presionando TAB o MAYÚSCULA+TAB. Es importante que todos los elementos interactivos, incluyendo los no nativos en HTML, usualmente creados utilizando CSS o mediante un script, puedan obtener el foco mediante navegación de teclado. Para hacer un elemento no nativo de HTML accesible al teclado, utilice el atributo tabindex=”0”.
3. Todos los elementos que puedan obtener el foco mediante navegación de teclado, TIENEN que tener el indicador visual de foco cuando estén activos.
4. El orden de lectura y navegación de todos los elementos, incluyendo los que puedan obtener el foco mediante navegación de teclado, TIENE que ser lógico e intuitivo.
5. El foco del teclado o de navegación táctil no puede ser atrapado en ningún elemento. el usuario TIENE que ser capaz de entrar a y salir de cualquier elemento que pueda obtener el foco, solamente con el método de entrada en uso, ya sea el teclado o los gestos de navegación.
6. El área predeterminada para tocar/activar un elemento DEBERÍA ser lo suficientemente amplia como para facilitarle el uso de las pantallas táctiles a las personas con retos de movilidad. El ancho del área para tocar/activar el elemento DEBERÍA ser de, al menos, 48px en dispositivos de resolución standard y 96px en dispositivos que doblan la densidad en pixeles, como los dispositivos con pantalla Retina de Apple.
Formularios: instrucciones y validación
1. Todo campo de entrada y control en un formulario TIENE que tener una etiqueta o nombre accesible asociado de forma programática. En la mayoría de las circunstancias, esta asociación se define utilizando la etiqueta <label> y el atributo id. Ejemplo: <label for=”pnombre_a”>Nombre:</label> <input type=”text” name=”pnombre_a” id=”pnombre_a”>.
2. El texto de las etiquetas TIENE que ser descriptivo e informativo.
3. El texto de las etiquetas TIENE que estar visible en todo momento. Evite utilizar atributos como “placeholder”, ya que el contenido de estos desaparece cuando el usuario entra información en el campo de formulario.
4. Los grupos de campos de formulario relacionados, como las casillas de verificación y los botones circulares (botones de radio), TIENEN que ser asociados de forma programática, utilizando las etiquetas <fieldset> y <legend> o mediate role=”group” y aria-labelledby.
5. Las instrucciones para las secciones, los grupos de campos relacionados y los campos de formulario individuales, TIENEN que ser asociadas de forma programática utilizando aria-describedby.
6. Las insturcciones TIENEN que ser descriptivas, informativas y estar visible en todo momento.
7. Los campos de formulario requeridos TIENEN que ser identificados utilizando aria-required=”true” y mediante indicadores visuales como el signo de asterisco (*) o la palabra “requerido”.
8. Los formularios TIENEN que incluir un método accesible que le indique al usuario el estado del proceso de validación. Ejemplo de estrategias que facilitan este proceso:
  1. Agregar el atributo aria-invalid=”true” a los campos con errores.
  2. Agregar un resumen con la cantidad de errores y un listado de los mismos, o un mensaje de confimación indicando que el formulario fue completado exitosamente.
  3. Agregar el atributo tabindex=”-1” al contenedor del resumen de errores/mensaje de confirmación para que este pueda obtener el foco durante la navegación de teclado o por un script.
  4. Mover el foco al resumen de errores/mensaje de confirmación.
  5. Asociar los mensajes de errores de forma programática a los campos correspondientes con aria-describedby.
  6. Asegurarse de que los mensajes de errores estén adyacentes a los campos correspondientes para facilitar el proceso de identificación.
  7. En la medida que sea posible, incluir un texto de error o de confirmación dentro del elemento <title>.
Contenido dinámico, sitios web de una sola página y AJAX
1. Cambios en el contenido:
  1. TIENEN que ser notificados utilizando resaltado u otro método de identificación visual. Es importante comunicarle al usuario los cambios en el contenido que ocurren de manera automática o los procedentes de una acción, como la activación de un botón.
  2. TIENEN que ser notificados utilizando una de las siguientes estrategias de retroalimentación auditiva para los usuarios de lectores de pantalla:
    1. Volver a cargar la página.
    2. Agregar el atributo tabindex=”-1” al contenedor de los cambios, configurar un retrazo de, al menos, 1 segundo en el script y mover el foco al contenido.
    3. Anunciar los cambios mediante el uso de aria-live=”assertive” o aria-live=”polite”.
2. Las sesiones con tiempo límite DEBERÍAN cumplir con los siguientes requerimientos:
  1. Proveer una cuenta regresiva a tiempo real, especialmente si el tiempo límite está por expirar. Este requerimiento es muy importante en páginas web en donde se muestra información sensitiva y la sesión no puede ser extendida.
  2. Anunciar estratégicamente el tiempo restante de la sesión utilizando aria-live.
  3. Proveer un método para prolongar la sesión, en el caso de las páginas web en donde las sesiones puedan ser extendidas.
  4. Notificarle al usuario que la sesión ha expirado utilizando aria-live o moviendo el foco al mensaje de expiración. Si la sesión ha expirado, en la medida que sea posible, proveer un método para retener la mayor cantidad de la información entrada.
3. El contenido de toda la página no DEBERÍA ser recargado de forma automática. Cuando las páginas se autorecargan, los lectores de pantalla desplazan el cursor virtual al inicio y reinician la lectura desde el primer elemento de la misma. Utilice un mensaje de ARIA alert para anunciar el contenido nuevo. De esta manera, el usuario decidirá si desea recargar la página.
4. Un área de desplazamiento infinito (infinite scrolling) DEBERÍA ser el último elemento de la página. Un área con estas características usualmente se configura para mostrar el contenido de redes sociales como Facebook y Twitter. Si una página web posee un área de desplazamiento infinito, es necesario incluir un encabezado antes del elemento, que informe al usuario sobre dicha característica. Este texto TIENE que ser configurado utilizando tabindex=”0” para que pueda obtener el foco mediante navegación de teclado.
5. Los usuarios de lectores de pantalla TIENEN que ser notificados cuando una acción provoca la carga de una página intermedia, un indicador de progreso o la página entra en estado de pausa u ocupado.
6. Los usuarios de lectores de pantalla TIENEN que ser notificados cuando se carga una página nueva o contenido nuevo, en aplicaciones o sitios web de una sola página. Existen dos maneras de notificarle a los usuarios de lectores de pantalla cuando se carga contenido nuevo mediante AJAX:
  1. Mover el foco al contenido. Opción recomendada para la mayoría de los sitios web de una sola página.
  2. Anunciar el contenido nuevo utilizando aria-live.
Documentos alternos
1. Los documentos alternos, como los documentos de Microsoft Word y los documentos en formato PDF, TIENEN que cumplir con las siguientes características:
  1. Encabezados (headings) para estructurar el contenido, imágenes con texto alternativo (alt text), tablas con filas o columnas de títulos, listas para enumerar elementos y otros.
  2. No deben ser imágenes escaneadas. Los usuarios de lectores de pantalla no pueden leer el contenido de un documento alterno, como un archivo PDF, si su contenido es basado en imágenes escaneadas. Sólo pueden leer documentos basados en texto, como documentos de Microsoft Word (.docx), o documentos convertidos a formato PDF desde las aplicaciones de Microsoft Office.
2. Cuando una página web contiene archivos con formatos propietarios (documentos PDF, por ejemplo), DEBERÍA proporcionar un enlace para descargar un plug-in que cumpla con las estipulaciones de accesibilidad.
3. Una página alternativa sólo en texto DEBERÍA proporcionarse solamente como último recurso, obedeciendo las normas de accesibilidad. Siempre debe intentar hacer accesible la página principal y no crear una segunda versión sólo en texto.
Funcionalidad (Usability)
1. Las páginas web TIENEN que ser evaluadas utilizando un validador de accesibilidad que cumpla con las pautas de WCAG, versión 2.1 o la versión más actualizada al momento de la evaluación. Algunos de estos son:
  1. WAVE – WebAIM.
  2. Cynthia Says – Cryptzone.
2. Las páginas web TIENEN que ser revisadas manualmente utilizando equipos y programas de asistencia tecnológica. La gran mayoría de estos están incluidos en el sistema operativo, son aplicaciones gratuitas o se pueden descargar en versiones de demostración.
  1. Lector de pantalla NVDA en Windows.
  2. Lector de pantalla VoiceOver en MacOS y iOS.
  3. Lector de pantalla TalkBack en Android.
  4. Magnificador de pantalla ZoomText en Windows.
  5. Magnificador de pantalla Zoom en MacOS y iOS.
  6. Programa de reconocimiento de voz Dragon Naturally Speaking en Windows.
3. Las páginas web TIENEN que ser revisadas cada vez que ocurran cambios significativos en estructura o contenido.

Vigencia y Alcance

Esta nueva versión de las Guías de Accesibilidad comenzará a partir de junio de 2018 y tendrá la vigencia que los representantes del PRATP, DPI y OGP estimen meritoria.