Diseño/Arquitectura

WEB-27

27WEB: Todas las agencias deberán exhibir la Bandera de la Commonwealth sin alteraciones y según lo definido por el Sistema de Diseño COV. 

Entendiendo el27web  

El Commonwealth Branding Bar ayuda a los ciudadanos a identificar los sitios web oficiales de las organizaciones gubernamentales en el Estado de Virginia. También ayuda a los visitantes a comprender que el sitio en el que se encuentran es oficial y seguro. La nueva barra de marca también sirve como un portal de navegación para que los visitantes del sitio web naveguen fácilmente a través de las agencias gubernamentales y busquen información en toda la Commonwealth, sin tener que volver a Virginia.gov. 

La barra de marca es fácil de instalar, y las instrucciones y el código se pueden encontrar para que las agencias lo pongan en sus sitios web en Get the Commonwealth Branding Bar. Esta página presenta instrucciones paso a paso para generar un código para colocar en la etiqueta principal del sitio web de una agencia. Las agencias también tienen la opción de elegir entre barras de marca grises y blancas para adaptarse mejor a la temática de color de sus sitios web. 

Cada barra de marca generada contiene: 

  • El logotipo del estado de Virginia 
  • El nombre de la agencia o entidad gubernamental de Virginia, de la cual los generadores deben deletrear el nombre completo 
  • Una firma que dice: "Un sitio web oficial de la Mancomunidad de Virginia" y un menú desplegable que dice "Así es como lo sabes". 
  • El menú desplegable contiene información sobre el logotipo de la Mancomunidad de Virginia y los certificados HTTPS. 
  • Un submenú etiquetado como "Buscar un recurso de la Commonwealth" que, cuando se hace clic, permite a los usuarios buscar en agencias o entidades gubernamentales de Virginia, así como en los servicios y recursos de la Commonwealth de uso común ordenados por área de servicio de la agencia. 

El código generado debe usarse tal cual y no debe modificarse de ninguna manera. Cualquier dificultad con la instalación debe enviarse al equipo de servicios web empresariales de VITA por correo electrónico . El código generado debe usarse tal cual y no debe modificarse de ninguna manera. Cualquier dificultad con la instalación debe enviarse al equipo de servicios web empresariales de VITA enviando un correo electrónico a developer@vita.virginia.gov. 

WEB-28

WEB-28: Los sistemas web COV proporcionarán un cuadro de búsqueda del sitio de la agencia que aparecerá en cada página y se mostrará según las directivas del sistema de diseño COV. 

Entendiendo el28web

Tener un cuadro de búsqueda en todo el sitio web y la página de la agencia permite a los usuarios acceder más rápidamente a la información escribiendo palabras clave y términos de búsqueda relevantes que los dirigen a una lista de enlaces relevantes.  Una agencia no puede depender únicamente de la navegación primaria o secundaria para dirigir a los usuarios a la información relevante.  

Debido a que los cuadros de búsqueda se vuelven cada vez más centrales para los sitios web que albergan grandes cantidades de contenido e información, particularmente relacionados con políticas, procedimientos o servicios al ciudadano, los cuadros de búsqueda deben mostrarse de manera destacada en cada página y deben ser fácilmente perceptibles para los usuarios. 

Además, los cuadros de búsqueda deben cumplir las siguientes prácticas recomendadas: 

  • La búsqueda, siempre que sea posible, debe conservar un campo de consulta de texto abierto con texto de marcador de posición etiquetado como "búsqueda" o con instrucciones más contextuales limitadas a unas pocas palabras en las que el usuario pueda escribir las consultas. 
  • Los cuadros de búsqueda deben ir acompañados de un icono de lupa con la menor cantidad de detallesS posible (lineart simple). Los usuarios reconocen universalmente la lupa como el símbolo de la funcionalidad de búsqueda. 
  • Siempre que sea posible, este icono no debe ocultar la funcionalidad de búsqueda, ya que aumenta el costo de la interacción (más clics) y hace que la funcionalidad de búsqueda sea menos distinta. 
  • En caso de duda, hazlo como Google. 
  • Las consultas de búsqueda deben confirmarse pulsando Intro. Las consultas de búsqueda también se pueden confirmar pulsando un botón de confirmación si se desea, aunque se debe mantener la interacción de pulsar Intro en el cuadro de búsqueda. 
  • Si se agrega un botón de confirmación, debe tener el tamaño y la ubicación adecuados (generalmente la altura del cuadro de búsqueda en sí, colocado a la derecha del campo de consulta de texto abierto). Este botón de búsqueda, como mínimo, debe tener un tamaño de 45 x 45 píxeles para cumplir con las prácticas recomendadas de accesibilidad. 
  • El cuadro de texto de entrada debe tener un tamaño ancho para manejar aproximadamente 27 caracteres de longitud como mínimo (establecido mediante ems). 
  • Siempre que sea posible, el cuadro de búsqueda debe colocarse en la esquina superior derecha del sitio web de la agencia, debajo de la barra de marca de la Commonwealth. 
  • Un campo desplegable de sugerencias automáticas de menos de 10 elementos puede ayudar a los usuarios a encontrar más rápidamente lo que buscan, sin embargo, las agencias que lo utilizan deben asegurarse de que las sugerencias que genera automáticamente el campo sean relevantes para los términos de búsqueda escritos en el campo de entrada. 
  • Una vez que un usuario presiona Entrar, el término de búsqueda original debe permanecer en el campo a menos que el usuario lo autorice y se le debe presentar al usuario una página de resultados que muestre los resultados basados en su consulta de búsqueda. 
  • Si una consulta de búsqueda no devuelve resultados, se debe presentar a los usuarios información que indique claramente que no hay resultados coincidentes. 

WEB-29

WEB-29: Los sistemas web COV incluirán un mapa del sitio para permitir que los motores de búsqueda rastreen un sitio web de manera más eficiente. Se proporcionarán ejemplos en el Sistema de Diseño COV.

Entendiendo el29web

Un mapa del sitio es un archivo que permite a los motores de búsqueda descubrir la mayor parte de su sitio mediante el rastreo de su contenido. 

Los mapas del sitio deben estar en formato XML, lo que permite a los motores de búsqueda indexar no solo archivos HTML, sino también datos sobre imágenes, videos, contenido de noticias y versiones localizadas de las páginas web de las agencias. 

Para obtener más información sobre cómo crear mapas del sitio en formato XML, visite la Documentación en formato XML de mapas del sitio en sitemaps.org. 

VITA recomienda seguir las siguientes prácticas recomendadas para el mapa del sitio, tal y como se establece en developers.google.com: 

  • Un solo mapa del sitio debe limitarse a 50MB sin comprimir. Si el archivo de mapa del sitio de tu agencia es más grande, divida tu mapa del sitio en varios mapas del sitio. 
  • Los archivos de mapa del sitio deben estar codificados en UTF-8 . 
  • Se recomienda que los mapas del sitio estén alojados en la raíz del sitio. 
  • Por ejemplo, usa URL absolutas y completas en tu mapa del sitio, usa https://www.myvaagency.gov/agencypage.html en lugar de /agencypage.html. 

WEB-30

WEB-30: Los sistemas web COV garantizarán que cada página tenga un pie de página que contenga, como mínimo, la siguiente información: 

  • Nombre de la agencia 
  • Información sobre derechos de autor 
  • Texto o un enlace de icono aprobado que indique el cumplimiento de la Iniciativa de Accesibilidad Web (WAI).
  • Enlace a la Declaración de Política de Privacidad en Internet de la agencia.
  • Enlace a la información de la FOIA
  • Aviso de traducción
  • Una página de contacto
  • Otros elementos según lo definido por el sistema de diseño COV 

Entendiendo el30web

Un pie de página de un sitio web es un patrón de interfaz de usuario estático que se muestra en la parte inferior de todas las páginas del sitio de una agencia. WEB-30 establece que en el pie de página de cada página se mostrará lo siguiente: 

  • Nombre de la agencia: Se debe mostrar el nombre completo de la agencia 
  • Información sobre derechos de autor: Se muestra como derechos de autor © Nombre completo de la agencia [año en curso] 
  • Es importante que las agencias trabajen para cumplir con la conformidad con AA como se establece en WCAG 2.0 al usar este enlace. 
  • Enlace a la Declaración de Política de Privacidad en Internet de la agencia: Las políticas de privacidad son específicas de la agencia, pero como mínimo deben explicar cómo una agencia usa y recopila la información de un usuario cuando accede al sitio, qué información se recopila, cómo se relaciona con la ley de Virginia, dónde puede comunicarse un usuario para obtener más información, la política de cookies y otra información relacionada con el uso de los datos del usuario. Un ejemplo se puede encontrar en virginia.gov. 
  • Enlace a la información de la FOIA: La información de la FOIA es específica de la agencia y debe contener información en lenguaje sencillo sobre la Ley de Libertad de Información de Virginia, los derechos de la FOIA de un usuario, cómo un usuario puede solicitar registros, dónde enviar la solicitud y las responsabilidades de una agencia al recibir una solicitud. Puede encontrar más información sobre la FOIA en la Código de Virginia, Capítulo 37. 
  • Descargo de responsabilidad de traducción: un descargo de responsabilidad de traducción indica que un tercero (normalmente el traductor de Google) está disponible para localizar páginas. Este descargo de responsabilidad debe nombrar al tercero, así como la verborrea de que la opción se proporciona para ayudar a los usuarios a proporcionar el sitio web en idiomas distintos del inglés, pero que ninguna traducción automática es perfecta y que el servicio de terceros se proporciona "tal cual". Un ejemplo se puede encontrar en Página de descargo de responsabilidad de traducción de VITA. 
  • Una página de contacto: Se debe incluir una página de contacto en el pie de página. Consulte WEB-31 para obtener información adicional. 

Además, el sistema de diseño COV recomienda que todos los pies de página 

  • Trabajar en dispositivos móviles 
  • Que los enlaces adicionales en el pie de página deben elegirse con un propósito (de uso frecuente, mini mapa del sitio, etc.) 
  • Contener enlaces/iconos de redes sociales, pero no feeds sociales completos 
  • Es claro y legible con imágenes mínimas o nulas 
  • Mantenga las llamadas a la acción breves y con una dirección y un propósito claros si se utilizan. 

WEB-31

WEB-31: Los sistemas web de COV proporcionarán una página de contacto que incluirá, como mínimo, lo siguiente de la agencia: 

  • Dirección postal
  • Número de fax, si está disponible
  • Número de teléfono, incluido un número gratuito y/o un número TTY si está disponible
  • Enlace de correo electrónico o formulario de contacto a un contacto de la agencia. 
  • Se podrá acceder a la página Contáctenos desde el pie de página de la página.  

Entendiendo el31web

Nota Las agencias deben emplear direcciones de correo electrónico genéricas y evitar asociar enlaces de contacto de agencias a personas específicas. 

Una página de contacto permite a los usuarios ponerse en contacto con la agencia con cualquier pregunta o inquietud a través de varios medios para adaptarse a diferentes usuarios. 

  • Las direcciones postales deben ser la dirección física de una agencia y no un apartado de correos, con el siguiente formato: 
     Nombre completo de la agencia 
    123 Calle Dirección Road, Suite Número 456 
    Ciudad, VA Código postal 
     
  • Número de fax, si está disponible, formateado de la siguiente manera: 
    123-555-5555 (Fax)
  • Número de teléfono, incluido un número gratuito y/o un número TTY, si está disponible, con el siguiente formato: 
    1-123-555-5555 (Teléfono) 
    1-800-555-5555 (línea gratuita) 
    1-123-555-5555 (TTY) 
  • Si es necesario, se pueden proporcionar más instrucciones sobre cómo usar TTY o los servicios de retransmisión, si están disponibles. 
  • Se debe utilizar un enlace de correo electrónico genérico para evitar asociar el contacto de la agencia con una persona específica y debe tener el siguiente formato: 
     
    contact@agency.virginia.gov 
     
    Un formulario de contacto para un contacto de agencia es una alternativa a una dirección de correo electrónico. Si utiliza un formulario, los formularios deben tener como mínimo los siguientes campos obligatorios para la respuesta, Con el etiquetado adecuado:
  • Nombre
  • Apellido (? ¿Es realmente necesario el apellido? Siguiendo el principio demínimos)
  • Correo electrónico o número de teléfono
  • Campo para mensaje o comentario 

WEB-36

36WEB: Los sistemas web de la plataforma COV, incluidos los sistemas comerciales listos para usar (COTS), admitirán la marca blanca para un uso sin interrupciones de la marca de la Commonwealth según lo definido por el sistema de diseño COV.

Entendiendo el36web

Los sistemas web de plataforma son definidos por el EA como: 

Cualquier sistema web que proporcione capacidades de nivel empresarial para implementaciones a gran escala o multiusuario, incluidos los sistemas de gestión de recursos humanos (HRMS), las soluciones de gestión financiera (FMS), la gestión de la cadena de suministro (SCM), la gestión de relaciones con los clientes (CRM), la gestión del rendimiento empresarial (EPM) y los sistemas de gestión de contenido (CMS). 

Estos sistemas deben permitir la capacidad de las agencias de COVA de cambiar su apariencia para adaptarse a los estándares del sistema de apariencia y diseño de EA (también conocido como marca blanca) cuando se presentan externamente o están de cara al público. Como mínimo, un sistema web de plataforma al que puedan acceder los usuarios públicos debe mostrar la barra de marca de la Commonwealth en la parte superior de la página. 

Accesibilidad

WEB-39

39web: Los sistemas web COV proporcionarán la información de accesibilidad necesaria que se mostrará según las directivas del sistema de diseño COV, de modo que el usuario tenga un conocimiento inmediato sobre la mejor manera de navegar por el sitio web.

Entendiendo el39web

Los sistemas web COV publicarán claramente el cumplimiento de la accesibilidad de los sitios webtal como se enumeran en30web, en particular para informar a los usuarios de las estrategias necesarias para navegar por el sitio web, independientemente de su capacidad.    Además, las agencias deben incluir una declaración de accesibilidad que incluya los esfuerzos que la agencia está realizando para desarrollar un sitio web accesible, cómo rastrean la accesibilidad y a quién pueden dirigir los usuarios sus inquietudes relacionadas con la accesibilidad.

WEB-40 – WEB-43

Requisitos visuales (WEB-40 – WEB-43)

Entendiendo WEB-40 – WEB-43

La guía de colores de alto contraste se basa en el criterio de éxito de WCAG 1.4.3 Contraste (mínimo), que establece: 

La presentación visual de Mensaje de texto y Imágenes de texto tiene un Relación de contraste de al menos 4.5:1, excepto los siguientes: 

  • A gran escala El texto y las imágenes de texto a gran escala tienen una relación de contraste de al menos 3:1;
  • Texto o imágenes de texto que forman parte de un archivo inactivo Componente de interfaz de usuario, que son Pura decoración, que no son visibles para nadie, o que forman parte de una imagen que contiene otro contenido visual significativo, no tienen ningún requisito de contraste.
  • El texto que forma parte de un logotipo o nombre de marca no tiene ningún requisito de contraste. 

Las relaciones de contraste de color se pueden determinar mediante el uso de una herramienta de auditoría como SiteImprove o verificadores en línea como WebAIM. 

La guía de señales de audio se basa en el Criterio de Éxito 1.2 de WCAG.2 Subtítulos (pregrabados), que dice: 

Se proporcionan subtítulos para todo el contenido de audio pregrabado en medios sincronizados, excepto cuando el medio es una alternativa de medio para el texto y está claramente etiquetado como tal. 

La guía sobre las prácticas recomendadas para representar subtítulos se puede encontrar en El sitio recomendado por WCAG, joeclark.org y el Sitio web del Programa de Medios de Comunicación Descrito y Subtitulado. 

Además, no todos los usuarios pueden entender o percibir el color, las imágenes u otras señales visuales debido a discapacidades que afectan la visión, como la ceguera o el daltonismo en usuarios videntes. WEB-41 se basa en el Criterio de Éxito de WCAG 1.4.1 Uso del color, que establece: 

El color no se utiliza como el único medio visual para transmitir información, indicar una acción, provocar una respuesta o distinguir un elemento visual. 

Por ejemplo, si un formulario de contacto tiene un botón verde para "enviar" y un botón gris para "borrar formulario",, Tanto los botones como las instrucciones de envío deben estar claramente etiquetados. En este caso, el botón verde debe estar etiquetado como "enviar" y el botón rojo debe estar etiquetado como "borrado".. Las instrucciones deben indicar a los usuarios que "hagan clic en el botón Enviar para confirmar el envío del formulario o hagan clic en el botón Borrar formulario para borrar el formulario y comenzar de nuevo". 

El etiquetado debe ser claro y descriptivo para evitar la confusión del usuario, pero lo suficientemente conciso para que los usuarios puedan leer rápidamente y para ayudar a los usuarios con discapacidad auditiva u otras discapacidades cognitivas. 

Las agencias no deben usar solo el color para indicar hipervínculos en sus sitios web. Las agencias deben buscar el uso consistente, patrones de diseño fácilmente reconocibles para denotar hipervínculos internos y externos, como a través de subyacentes, estados de desplazamiento CSS e iconos (especialmente en el caso de un hipervínculo externo). 

Además, los campos que se marcan como obligatorios o los campos que se cumplen con errores de entrada deben presentar esta información de manera que no solo se identifiquen mediante el uso de colores. Por ejemplo, un campo no puede estar resaltado en un borde rojo o tener un asterisco rojo junto a él. Más bien, las agencias deben considerar identificadores como "Nombre obligatorio" o "Nombre*" y un notificador que diga "* = Campo obligatorio". 

Se pueden encontrar ejemplos visuales y de código de las mejores prácticas de campo requerido en La anatomía de los formularios accesibles de Deque: página de campos de formulario obligatorios . 

En el caso de los errores introducidos por el usuario, el error debe ser fácilmente identificable con una descripción clara y concisa del error. Cada mensaje de error también debe cumplir los siguientes criterios: 

  • Identificar cada campo con error
  • proporcionar sugerencias (cuando se conozcan) para corregir los errores,
  • Exponga adecuadamente esta información a la tecnología de asistencia. 

Para obtener información adicional y ejemplos sobre cómo dar formato a los campos de formulario accesibles con errores, visite Página "Cómo proporcionar identificación de errores de formulario accesible ". 

Requisitos de ARIA

WEB-44 – WEB-53

WEB-44 – WEB-53: Requisitos de ARIA

Entendiendo WEB-44 – WEB-53

HTML 5 contiene una mayor variedad y etiquetas HTML más descriptivas para ayudar a los desarrolladores y a la tecnología accesible a comprender más fácilmente la estructura, el contenido y la organización de una página web. Las agencias deben asegurarse de que sus sitios web utilicen correctamente el HTML semántico para ayudar a los desarrolladores, usuarios y tecnologías accesibles a acceder adecuadamente al contenido de su sitio web. Además, el marcado semántico HTML5 ayuda a limitar el uso de ARIA en el código HTML. Para obtener más información sobre el marcado semántico en 5 HTML y su papel en la accesibilidad, visite HTML de Mozilla : Una buena base para la accesibilidad de la página web. 

ARIA, o Accessible Rich Internet Applications, es un conjunto de roles y atributos agregados al código HTML para hacer que un sitio web sea más accesible para los usuarios que utilizan tecnologías web de asistencia. Si tiene la opción de usar un elemento HTML con semántica y comportamiento ya incorporados, use ese elemento HTML en lugar de AIRA. Las agencias deben usar ARIA con un elemento HTML si no hay ningún otro elemento HTML que describa o funcione de manera nativa, semántica o conductual lo que hace. Cuando las agencias eligen usar ARIA, deben ser conscientes de que son responsables de crear una experiencia apropiada y nativa similar para las tecnologías web de asistencia (como el orden de tabulación del teclado). 

WEB-44 - WEB-53 denota específicamente los requisitos para el uso de ARIA en caso de que las agencias encuentren una situación en la que no haya un marcado semántico equivalente. Los desarrolladores pueden hacer referencia a la clase Aplicaciones de Internet enriquecidas accesibles del W3C (WAI-ARIA) 1.3 para obtener detalles más detallados de los estándares ARIA, mientras que los diseñadores pueden consultar el Guía de prácticas de autoría (APG) de ARIA del W3C para obtener información sobre patrones de diseño comunes y cómo diseñar interacciones que funcionen mejor con el uso de ARIA. 

Interacción del usuario con el diseño

WEB-54 – WEB-102

WEB-54 – WEB-102: Interacción del usuario con el diseño

Entendiendo WEB-54 – WEB-102

Cuando las agencias crean sitios web, deben considerar no solo al usuario "más común", sino un diseño para una amplia variedad de tipos de usuarios y experiencias vividas. Estos grupos normalmente se dividen en las siguientes categorías: 

  • Visual
  • Auditivo
  • Motor
  • Cognitivo 

Como tal, las agencias deben asegurarse de que sus sitios web puedan ser accedidos e interactuados con estos cinco grupos de usuarios y que estén disponibles variaciones alternativas de las interacciones de su sitio web. Si se puede acceder a un enlace con un puntero del ratón, por ejemplo, también debe estar disponible a través del teclado a través del orden de tabulación, a través de lectores de pantalla a través del marcado semántico y denotado visualmente no solo a través del color. Además, las agencias deben considerar describir los medios visuales (como imágenes) a través de texto alternativo y texto descriptivo u otro texto equivalente para las señales auditivas.  

Las agencias deben permitir a los usuarios un control total sobre la página web si contiene medios reproducidos (auditivos y/o visuales) y evitar imágenes parpadeantes y desplazadas para los usuarios que puedan tener episodios desencadenantes de epilepsia o migraña. 

Cuando dude, ¡manténgalo simple! 

Los desarrolladores y las agencias pueden hacer referencia a la propiedad Estándares WCAG Web 2.1 para obtener los estándares web más actualizados y aprobados si desean profundizar más. Sin embargo La Universidad de Harvard ha elaborado una guía sencilla y fácil de leer sobre los principales 10 elementos esenciales que los desarrolladores deben tener en cuenta con la accesibilidad que cubre la mayoría de los temas tratados en WEB-54 – WEB-71. 

WEB-72 – WEB-102 se centra específicamente en la creación de sitios web perceptible, operable, robusto. Estos son tres de los cuatro principios documentados en Los cuatro principios de accesibilidad de las WCAG. 

Según las WCAG, estos cuatro principios son: 

  • Perceptible - La información y los componentes de la interfaz de usuario deben ser presentables para los usuarios de manera que puedan percibirlos. Esto significa que los usuarios deben ser capaces de percibir la información que se presenta (no puede ser invisible para todos sus sentidos) 
  • Operable - Los componentes de la interfaz de usuario y la navegación deben estar operativos. Esto significa que los usuarios deben ser capaces de operar la interfaz (la interfaz no puede requerir una interacción que un usuario no pueda realizar) 
  • Comprensible - La información y el funcionamiento de la interfaz de usuario deben ser comprensibles. Esto significa que los usuarios deben ser capaces de comprender la información, así como el funcionamiento de la interfaz de usuario (el contenido o el funcionamiento no pueden estar más allá de su comprensión) 
  • Robusto - El contenido debe ser lo suficientemente robusto como para que pueda ser interpretado de manera confiable por una amplia variedad de agentes de usuario, incluidas las tecnologías de asistencia. Esto significa que los usuarios deben poder acceder al contenido a medida que avanzan las tecnologías (a medida que las tecnologías y los agentes de usuario evolucionan, el contenido debe seguir siendo accesible) 

Estos cuatro principios constituyen la columna vertebral de los estándares modernos de accesibilidad actuales en la web. 

Además, WEB-72 establece que los sitios web de las agencias deben contener al menos Dos de los siguientes artículos: 

  • Lista de páginas relacionadas  
  • Tabla de contenidos 
  • Mapa del sitio 
  • Buscar 
  • Lista de todas las páginas 

Para obtener más información de forma concisa y simplificada, las agencias pueden consultar Principios de la Universidad de Harvard en el sitio web de la Iniciativa de Accesibilidad Digital. 

Navegación del dispositivo del usuario

WEB-103 – WEB-120

WEB-103 – WEB-120: Navegación del dispositivo del usuario

Entendiendo WEB-103 – WEB-120

WEB-103 - WEB-120 se centra específicamente en formas alternativas de navegar por un sitio web. Es importante tener en cuenta que no todos los usuarios utilizan un dispositivo de entrada que haga uso de un puntero del mouse. Los dispositivos de entrada alternativos pueden incluir lectores de pantalla, comandos de voz, palitos bucales, sorbos y bocanadas, y las teclas tab e enter que se encuentran en los teclados de las computadoras, por nombrar algunos. 

Las agencias pueden obtener más información sobre las tecnologías de asistencia en el Página web de Tipos de Tecnologías de Asistencia de la Universidad de Berkeley. 

Además, esta sección de EA también hace referencia a la función de control del motor de los usuarios potenciales en dispositivos móviles, afirmando que: 

Los sistemas web COV no requerirán gestos multipunto o basados en rutas, como pellizcar, deslizar o arrastrar. para la funcionalidad, a menos que el gesto sea esencial para la funcionalidad. 

Esto significa que en los dispositivos con pantalla táctil, los usuarios deben poder hacer zoom, ampliar el texto o realizar interacciones básicas en una página web sin necesidad de control de gestos; y que los sitios web deben desarrollarse para responder de forma nativa a diferentes tamaños de pantalla y dispositivos. 

Las agencias pueden encontrar un desglose de las técnicas de accesibilidad adicionales, incluidas las de la sección, en Página web de Técnicas de Tecnologías de Asistencia de la Universidad de Harvard. 

Contenido audiovisual

WEB-121 – WEB-128

Contenido AV: WEB-121 – WEB-128

Entendiendo WEB-121 – WEB-128

Todos los medios de audio y visuales deben ser accesibles y tener el formato adecuados para los usuarios de la web. Esta sección del EA se refiere específicamente a Guía WCAG 1.2 - Medios basados en el tiempo, que describe cómo se debe acceder al contenido audiovisual de los sitios web. Normas 1.2.1 y 1.2.5 deben ser referenciados, los cuales son los siguientes: 

  • Se proporciona una alternativa para los medios basados en el tiempo que presenta información equivalente para el contenido pregrabado de solo audio o video.  
  • Se proporcionan subtítulos para todo el contenido de audio pregrabado en medios sincronizados. 
  • Se proporciona una alternativa para los medios basados en el tiempo o la descripción de audio del contenido de vídeo pregrabado para los medios sincronizados, 
  • Se proporcionan subtítulos para todo el contenido de audio en vivo en medios sincronizados. 
  • Se proporciona descripción de audio para todo el contenido de video pregrabado en medios sincronizados. 

Además, todo el contenido en directo, como los seminarios web y las webcasts alojados en los sitios web o las aplicaciones de las agencias, también debe proporcionar subtítulos precisos y puntuales (como subtítulos en tiempo real y/o transcripción CART). 

Los usuarios también deben tener la capacidad de pausar, reproducir y detener los medios en cualquier momento; Y los medios no deben reproducirse automáticamente cuando el usuario visita la página.