Descripción
- -Esta técnica demuestra como usar el rol alertdialog.
El rol alertdialog es utilizado para notificar al usuario información urgente que demanden la atención inmediata del usuario. Como el nombre implica, alertdialog es un tipo de díalogo. Esto significa que la mayoría de las instrucciones proveidas en la técnica de ''usando el rol dialog' son aplicables al rol alertdialog también:
-
-
- El díalogo de alerta debe siempre recibir un nombre accesible (a través de
aria-labelledbyoaria-label), y en la mayoría de los casos el texto de alerta debe ser marcado como la descripción accesible del díalogo de alerta (utilizandoaria-describedby).
- - A diferencia de alertas regulares, un díalogo de alerta debe tener al menos un control enfocable y el foco debe moverse a ese control cuando el díalogo de alerta aparece. Generalmente los díalogos de alerta tienen al menos un botón de Confirmación, Cerrar o Cancelar que pueder ser usado para moverl el foco. Adicionalmente, díalogos de alerta pueder tener otros controles interactivos tales como campos de texto, pestañas o checkboxes. El enfoque de control al que se debe desplazar depende del propósito del diálogo. -
- El orden de la pestaña dentro del díalogo de alerta debe ajustarse. -
La diferencia con díalogos normales es que el rol de alertdialog debe ser utilizado únicamente cuando una alerta, error, o advertencia ocurre. En otras palabras, cuando la información o controles de un díalogo requieren la inmediata atención del usuario debe usarse alertdialog en lugar de dialog. Sin embargo, depende del desarrollador hacer esta distinción.
Debido a su carácter urgente los díalogos de alerta deben ser siempre modales.
- -alertdialog es probablemente el rol incorrecto para ser utilizado.. El rol alert debe ser usado en su lugar en éste caso (como se describe en la técnica de Utilizando el rol alert).Posibles efectos de agentes de usuario y tecnología de asistencia
- -Cuando un rol alertdialog es utilizado, el agente de usuario debería hacer lo siguiente:
-
-
- Exponer el elemento como un díalogo a la API de accesibilidad del sistema operativo. -
- Disparar un evento de alerta accesible usando la API de accesibilidad del sistema operativo si lo soporta. -
Cuando la aleta de díalogo aparece, los lectores de pantalla deberían anunciar la alerta.
- -Cuando el díalogo de alerta es etiquetado correctamente y el foco es movido de un control a el interior del díalogo, los lectores de pantalla deberían anunciar el rol accesible del díalogo así como su nombre y su descriipción antes de anunciar el elemento enfocado.
- -Ejemplos
- -Ejemplos 1: Un díalogo de alerta básico
- -El fragmento de código siguiente muestra como marcar un díalogo de alerta que solo provee un mensaje y un botón de OK.
- -<div role="alertdialog" aria-labelledby="tituloDialogo1" aria-describedby="descrDialogo1"> - <div role="document" tabindex="0"> - <h2 id="tituloDialogo1">Tu sesión esta apunto de expirar</h2> - <p id="descrDialogo1">Para extender tu sesión de clic en el botón OK</p> - <button>OK</button> - </div> -</div>- -
Ejemplos en funcionamiento:
- -Pendiente
- -Notas
- -Atributos ARIA utilizados
- - - -Técnicas ARIA relacionadas
- - - -Compatibilidad
- -Pendiente: Add support information for common UA and AT product combinations
- -Recursos adicionales
diff --git a/files/es/web/accessibility/aria/roles/alertdialog_role/index.md b/files/es/web/accessibility/aria/roles/alertdialog_role/index.md new file mode 100644 index 00000000000000..d0f6c21beee352 --- /dev/null +++ b/files/es/web/accessibility/aria/roles/alertdialog_role/index.md @@ -0,0 +1,82 @@ +--- +title: Usando el rol alertdialog +slug: Web/Accessibility/ARIA/Roles/alertdialog_role +tags: + - ARIA + - Accesibilidad + - Alertas + - Desarrollo web + - HTML + - agente + - alertdialog + - modal +translation_of: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_alertdialog_role +original_slug: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_alertdialog_role +--- +### Descripción + +Esta técnica demuestra como usar el rol [`alertdialog`](http://www.w3.org/TR/2009/WD-wai-aria-20091215/roles#alertdialog). + +El rol `alertdialog` es utilizado para notificar al usuario información urgente que demanden la atención inmediata del usuario. Como el nombre implica, `alertdialog` es un tipo de díalogo. Esto significa que la mayoría de las instrucciones proveidas en la técnica de ''[usando el rol `dialog`](/es/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_dialog_role)' son aplicables al rol `alertdialog` también: + +- El díalogo de alerta debe siempre recibir un nombre accesible (a través de `aria-labelledby` o `aria-label`), y en la mayoría de los casos el texto de alerta debe ser marcado como la descripción accesible del díalogo de alerta (utilizando `aria-describedby`). +- A diferencia de alertas regulares, un díalogo de alerta debe tener al menos un control enfocable y el foco debe moverse a ese control cuando el díalogo de alerta aparece. Generalmente los díalogos de alerta tienen al menos un botón de Confirmación, Cerrar o Cancelar que pueder ser usado para moverl el foco. Adicionalmente, díalogos de alerta pueder tener otros controles interactivos tales como campos de texto, pestañas o checkboxes. El enfoque de control al que se debe desplazar depende del propósito del diálogo. +- El orden de la pestaña dentro del díalogo de alerta debe ajustarse. + +La diferencia con díalogos normales es que el rol de `alertdialog` debe ser utilizado únicamente cuando una alerta, error, o advertencia ocurre. En otras palabras, cuando la información o controles de un díalogo requieren la inmediata atención del usuario debe usarse `alertdialog` en lugar de `dialog.` Sin embargo, depende del desarrollador hacer esta distinción. + +Debido a su carácter urgente los díalogos de alerta deben ser siempre modales. + +> **Nota:** Este rol solo debe ser usado para mensajes de alerta que tienen controles interactivos asociado. Si un díalogo de alerta solo contiene contenido estático y no tiene controles interactivos, `alertdialog` es probablemente el rol incorrecto para ser utilizado.. El rol `alert` debe ser usado en su lugar en éste caso (como se describe en la técnica de [Utilizando el rol `alert`](/en/ARIA/ARIA_Techniques/Using_the_alert_role)). + +### Posibles efectos de agentes de usuario y tecnología de asistencia + +Cuando un rol `alertdialog` es utilizado, el agente de usuario debería hacer lo siguiente: + +- Exponer el elemento como un díalogo a la API de accesibilidad del sistema operativo. +- Disparar un evento de alerta accesible usando la API de accesibilidad del sistema operativo si lo soporta. + +Cuando la aleta de díalogo aparece, los lectores de pantalla deberían anunciar la alerta. + +Cuando el díalogo de alerta es etiquetado correctamente y el foco es movido de un control a el interior del díalogo, los lectores de pantalla deberían anunciar el rol accesible del díalogo así como su nombre y su descriipción antes de anunciar el elemento enfocado. + +> **Nota:** Opiniones pueden diferir en como tecnología de asistencia debe manejar esta técnica. La información proveída arriba es una de éstas opiniones y por lo tanto no es normativa. + +### Ejemplos + +#### Ejemplos 1: Un díalogo de alerta básico + +El fragmento de código siguiente muestra como marcar un díalogo de alerta que solo provee un mensaje y un botón de OK. + +```html +Tu sesión esta apunto de expirar
+Para extender tu sesión de clic en el botón OK
+ +-
Si conoces alguna lista de correo, grupo de noticias, foro, o comunidad relacionada con la - - accesibilidad - que pueda ser de interés. Por favor, pon aquí un enlace.
-Mozilla
--
-
- La - - Accesibilidad - en la comunidad Mozilla... en inglés -
{{ DiscussionList("support-accessibility", "mozilla.support.accessibility") }}
-Listas de correo
--
-
- Accesoweb Lista en castellano sobre problemas y soluciones de diseño accesible para la Red de la Fundación Sidar. -
Foros
--
-
- -
-
Bitácoras
--
-
- Accesibilidad, Usabilidad y Estándares Web Este es un blog dedicado a todos los temas relacionados con la accesibilidad web, usabilidad y estándares web. -
Wikis
--
-
- -
-
Otros Sitios
- -categorías
diff --git a/files/es/web/accessibility/community/index.md b/files/es/web/accessibility/community/index.md new file mode 100644 index 00000000000000..c1d4bf9f441ac3 --- /dev/null +++ b/files/es/web/accessibility/community/index.md @@ -0,0 +1,42 @@ +--- +title: Comunidad +slug: Web/Accessibility/Community +tags: + - Accesibilidad + - Todas_las_Categorías +translation_of: Web/Accessibility/Community +original_slug: Web/Accesibilidad/Comunidad +--- +Si conoces alguna lista de correo, grupo de noticias, foro, o comunidad relacionada con la +_accesibilidad_ +que pueda ser de interés. Por favor, pon aquí un enlace. + +### Mozilla + +- La + _Accesibilidad_ + en la comunidad Mozilla... en inglés + +{{ DiscussionList("support-accessibility", "mozilla.support.accessibility") }} + +### Listas de correo + +- [Accesoweb](http://es.groups.yahoo.com/group/accesoweb) Lista en castellano sobre problemas y soluciones de diseño accesible para la Red de la **Fundación Sidar**. + +### Foros + +- + +### Bitácoras + +- [Accesibilidad, Usabilidad y Estándares Web](http://accesibilidadweb.blogspot.com/) Este es un blog dedicado a todos los temas relacionados con la accesibilidad web, usabilidad y estándares web. + +### Wikis + +- + +### Otros Sitios + +- [El sitio del WAI (en)](http://www.w3.org/WAI/) + +categorías diff --git a/files/es/web/accessibility/understanding_wcag/index.html b/files/es/web/accessibility/understanding_wcag/index.html deleted file mode 100644 index b8172e56351b04..00000000000000 --- a/files/es/web/accessibility/understanding_wcag/index.html +++ /dev/null @@ -1,57 +0,0 @@ ---- -title: Understanding the Web Content Accessibility Guidelines -slug: Web/Accessibility/Understanding_WCAG -translation_of: Web/Accessibility/Understanding_WCAG -original_slug: Web/Accesibilidad/Understanding_WCAG ---- -Esto es parte de un grupo de artículos que explican rápidamente los pasos necesario para cumplir con la normativa de W3C Web Content Accessibility Guides 2.0 o 2.1 (también conocida como WCAG).
- -La norma WCAG 2.0 y 2.1 provee unas guías detalladas para lograr que el contenido de nuestro sitio sea accesible para personas con distintos tipos de discapacidades. Es exhaustivo y muy detallado, por lo que cuesta comprenderlo rápidamente. Por esta razón, hemos resumido los pasos a seguir para que puedas cumplir con las diferentes recomendaciones e incluimos links al pie para más detalles en los lugares necesarios.
- -Los cuatro principios
- -La normativa WCAG tiene cuatro secciones, cuatro categorías en las cuales el contenido debe ser accesible (para más información puedes referirte a Understanding the Four Principles of Accessibility (inglés)).
- -Cada uno de los siguientes enlaces te llevarán a páginas en las que podrás expandir tu conocimiento en cada una de las áreas de WCAG 2.0 y 2.1.
- --
-
- Perceptible: Los usuarios deben poder percibir el contenido de alguna forma, a través de alguno de sus sentidos. -
- Operable: Los usuarios deben poder controlar los elementos de interfaz (por ejemplo, se deben poder cliquear botones de alguna forma, ya sea utilizando el ratón, teclado o comando de voz). -
- Comprensible: El contenido debe ser comprensible para los usuarios. -
- Robusto: El contenido debe ser desarrollado utilizando estándares actuales que funcionarán en todos los navegadores del momento, hoy y en el futuro. -
Debo usar WCAG 2.0 o 2.1?
- -WCAG 2.1 es el estándar más reciente y relevante. Utilízalo para mejorar la calidad de navegación de los usuarios con discapacidades y para reducir las posibles acciones legales a los dueños del sitio web.
- -Al momento de asignar recursos, ten como objetivo WCAG 2.0, luego sube a 2.1.
- -¿Qué es WCAG 2.1?
- -WCAG 2.1 fue publicado el 5 de junio de 2018 como recomendación oficial. La Unión Europea (EU) lo adoptó como estándar en septiembre de ese mismo año. La W3C publicó un anuncio de prensa al respecto.
- -WCAG 2.1 incluye:
- --
-
- Toda la normativa WCAG 2.0 (literal, palabra-por-palabra) -
- 17 nuevos Criterios de Conformidad en los niveles A / AA / AAA que se enfocan principalmente en las siguientes necesidades:
-
-
-
- Accessbilidad móvil -
- Baja visión -
- Cognitivas -
- - Lee más sobre WCAG 2.1 (en inglés): - - -
Legal
- -Esta guía tiene como objetivo proveer información para que puedas construir mejores sitios, más accesibles. Sin embargo, no somos abogados y nada de esto es un asesoramiento legal. Si estás preocupado/a por las implicaciones legales de la accesibilidad web recomendamos que investigues la legislación de tu país o que consultes a un abogado calificado.
- -¿Qué es la accesibilidad? y guías de accesibilidad y sobre la ley proveen más información al respecto (en inglés).
diff --git a/files/es/web/accessibility/understanding_wcag/index.md b/files/es/web/accessibility/understanding_wcag/index.md new file mode 100644 index 00000000000000..c392c5db094721 --- /dev/null +++ b/files/es/web/accessibility/understanding_wcag/index.md @@ -0,0 +1,50 @@ +--- +title: Understanding the Web Content Accessibility Guidelines +slug: Web/Accessibility/Understanding_WCAG +translation_of: Web/Accessibility/Understanding_WCAG +original_slug: Web/Accesibilidad/Understanding_WCAG +--- +Esto es parte de un grupo de artículos que explican rápidamente los pasos necesario para cumplir con la normativa de W3C Web Content Accessibility Guides 2.0 o 2.1 (también conocida como WCAG). + +La norma WCAG 2.0 y 2.1 provee unas guías detalladas para lograr que el contenido de nuestro sitio sea accesible para personas con distintos tipos de discapacidades. Es exhaustivo y muy detallado, por lo que cuesta comprenderlo rápidamente. Por esta razón, hemos resumido los pasos a seguir para que puedas cumplir con las diferentes recomendaciones e incluimos links al pie para más detalles en los lugares necesarios. + +## Los cuatro principios + +La normativa WCAG tiene cuatro secciones, cuatro categorías en las cuales el contenido **debe** ser accesible (para más información puedes referirte a [Understanding the Four Principles of Accessibility (inglés)](https://www.w3.org/TR/UNDERSTANDING-WCAG20/intro.html#introduction-fourprincs-head)). + +Cada uno de los siguientes enlaces te llevarán a páginas en las que podrás expandir tu conocimiento en cada una de las áreas de WCAG 2.0 y 2.1. + +- [Perceptible:](/es/docs/user:chrisdavidmills/Understanding_WCAG/Perceivable) Los usuarios deben poder percibir el contenido de alguna forma, a través de alguno de sus sentidos. +- [Operable](/es/docs/user:chrisdavidmills/Understanding_WCAG/Operable): Los usuarios deben poder controlar los elementos de interfaz (por ejemplo, se deben poder cliquear botones de alguna forma, ya sea utilizando el ratón, teclado o comando de voz). +- [Comprensible](/es/docs/user:chrisdavidmills/Understanding_WCAG/Understandable): El contenido debe ser comprensible para los usuarios. +- [Robusto](/es/docs/user:chrisdavidmills/Understanding_WCAG/Robust): El contenido debe ser desarrollado utilizando estándares actuales que funcionarán en todos los navegadores del momento, hoy y en el futuro. + +## Debo usar WCAG 2.0 o 2.1? + +WCAG 2.1 es el estándar más reciente y relevante. Utilízalo para mejorar la calidad de navegación de los usuarios con discapacidades y para reducir las posibles acciones legales a los dueños del sitio web. + +Al momento de asignar recursos, ten como objetivo WCAG 2.0, luego sube a 2.1. + +### ¿Qué es WCAG 2.1? + +WCAG 2.1 fue publicado el 5 de junio de 2018 como recomendación oficial. La Unión Europea (EU) lo adoptó como estándar en septiembre de ese mismo año. La W3C publicó un [anuncio de prensa al respecto](https://www.w3.org/blog/2018/09/wcag-2-1-adoption-in-europe/). + +WCAG 2.1 incluye: + +- Toda la normativa WCAG 2.0 (literal, palabra-por-palabra) +- 17 nuevos Criterios de Conformidad en los niveles A / AA / AAA que se enfocan principalmente en las siguientes necesidades: + + - Accessbilidad móvil + - Baja visión + - Cognitivas + +- Lee más sobre WCAG 2.1 (en inglés): + + - Deque: [WCAG 2.1: What is Next for Accessibility Guidelines](https://www.deque.com/blog/wcag-2-1-what-is-next-for-accessibility-guidelines/) + - TPG: [Web Content Accessibilituy Guidelines (WCAG) 2.1](https://developer.paciellogroup.com/blog/2018/06/web-content-accessibility-guidelines-wcag-2-1/) + +## Legal + +Esta guía tiene como objetivo proveer información para que puedas construir mejores sitios, más accesibles. Sin embargo, no somos abogados y nada de esto es un asesoramiento legal. Si estás preocupado/a por las implicaciones legales de la accesibilidad web recomendamos que investigues la legislación de tu país o que consultes a un abogado calificado. + +[¿Qué es la accesibilidad?](/es/docs/Learn/Accessibility/What_is_accessibility) y [guías de accesibilidad y sobre la ley](/es/docs/Learn/Accessibility/What_is_accessibility#Accessibility_guidelines_and_the_law) proveen más información al respecto (en inglés). diff --git a/files/es/web/accessibility/understanding_wcag/keyboard/index.html b/files/es/web/accessibility/understanding_wcag/keyboard/index.html deleted file mode 100644 index b3f2792fb401cd..00000000000000 --- a/files/es/web/accessibility/understanding_wcag/keyboard/index.html +++ /dev/null @@ -1,93 +0,0 @@ ---- -title: Teclado (Keyboard) -slug: Web/Accessibility/Understanding_WCAG/Keyboard -tags: - - Accesibilidad - - teclado -translation_of: Web/Accessibility/Understanding_WCAG/Keyboard -original_slug: Web/Accesibilidad/Understanding_WCAG/Teclado ---- -Los elementos enfocables deben tener una semántica interactiva
- -Si un elemento puede ser enfocado utilizando un teclado, entonces debería ser interactivo, es decir, el usuario debería ser capaz de hacer algo y producir un cambio de algún tipo (por ejemplo, activar un enlace o cambiar una opción).
- -Nota: Una excepción importante a esta regla es si el elemento tiene aplicado role="document", dentro un contexto interactivo (como un role="application"). En tal caso, enfocar el documento anidado es la única forma de devolver la tecnología de asistencia a un estado de no interactividad (comúnmente llamado "modo navegador").
La mayoría de los elementos son enfocables por defecto, y se puede hacer que un elemento sea enfocable al añadir el atributo tabindex=0. Sin embargo, sólo se debería añadir tabindex si el elemento también se hace interactivo, por ejemplo, definiendo los eventos de teclado apropiados para los manejadores de eventos.
Ver también
- --
-
- Atributo HTML global tabindex -
- Manejador de evento global: onkeydown -
- Manejador de evento global: onkeyup -
Evitar usar el atributo tabindex con un valor mayor a cero
-
-El atributo tabindex indica que un elemento es enfocable utilizando el teclado. Un valor de cero indica que el elemento es parte del orden de enfoque normal, que está basado en el orden de los elementos en el documento HTML. Un valor positivo pone al elemento adelante de aquellos con el orden normal; elementos con valores positivos son enfocados en el orden del valor de tabindex (1, luego 2, después 3, etc.).
Esto genera una confusión para usuarios que solo usen el teclado cuando el orden del enfoque difiera al orden lógico de la página. Una mejor estrategia es estructurar el documento HTML para que los elementos enfocables estén es un orden lógico, sin la necesidad de reordenarlos con un valor positivo de tabindex.
Ver también
- --
-
- Atributo HTML globlal tabindex -
- Entendiento el orden del enfoque -
- No use un tabindex mayor que 0 -
Los elementos a los que se les puede hacer click deben ser enfocables y deberían tener semánticas interactivas
- -Si a un elemento se le puede hacer click con un dispositivo apuntador, como un ratón, entonces también debería enfocable utilizando el teclado, y el usuario debería ser capaz de hacer algo al interactuar con este.
- -A un elemento se le puede hacer click si tiene in manejador de evento onclick definido. Se puede hacer enfocable al añadir un atributo-valor tabindex=0. Se puede hacer que se opere con un teclado al definir un manejador de evento onkeydown; en la mayoría de los casos, la acción tomada por el manejador de eventos debería ser la misma para los dos tipos de eventos
Ver también
- --
-
- El atributo global HTML tabindex -
- Manejador de evento global: onkeydown -
- Manejador de evento global: onkeyup -
Los elementos interactivos deben ser capaz de ser activos utilizando un teclado
- -Si el usuario puede interactuar con un elemento utilizando el tacto o un dispositivo apuntador, entonces el elemento debería ser también capaz de interactuar con el teclado, Es decir, si hay manejadores de evento definidos para los eventos al tacto y al hacer click, también debería haber manejadores de eventos para el teclado. Los manejadores de eventos para el teclado deberían realizar la misma interacción que sus contrapartes con el tacto y al hacer click.
- -Ver también
- - - -Los elementos interactivos deben ser enfocables
- -Si el usuario puede interactuar con un elemento (por ejemplo, usando el tacto o con un dispositivo apuntador) entonces debería ser enfocable utilizando el teclado. Puede hacerse enfocable al añadirle el atributo-valor tabindex=0. Eso añadirá el elemento a la lista de elementos que pueden ser enfocados al presionar la tecla Tab, en la secuencia en que dichos elementos se encuentran definidos en el documento HTML.
Ver también
- --
-
- Atributo global HTML tabindex -
Elementos enfocables deben tener un estilo al estar enfocados
- -Cualquier elemento que pueda recibir el enfoque desde el teclado, debería tener un estilo visible que indique cuando el elemento esta enfocado. Se puede hacer esto con la pseudo-clase de CSS :focus.
Elementos enfocables estándar como enlaces y los campos de entrada reciben un estilo especial por parte del navegador de forma predeterminada, por lo que podría no ser necesario especificar un estilo de enfoque para éstos, a menos que se quiera que el estilo de enfoque sea más distintivo.
- -Si se crean componentes enfocables, se debe estar seguro de que también se defina el estilo de enfoque para éstos.
- -If you create your own focusable components, be sure that you also define focus styling for them.
- -Ver también
- - diff --git a/files/es/web/accessibility/understanding_wcag/keyboard/index.md b/files/es/web/accessibility/understanding_wcag/keyboard/index.md new file mode 100644 index 00000000000000..a44f66f901f8f6 --- /dev/null +++ b/files/es/web/accessibility/understanding_wcag/keyboard/index.md @@ -0,0 +1,79 @@ +--- +title: Teclado (Keyboard) +slug: Web/Accessibility/Understanding_WCAG/Keyboard +tags: + - Accesibilidad + - teclado +translation_of: Web/Accessibility/Understanding_WCAG/Keyboard +original_slug: Web/Accesibilidad/Understanding_WCAG/Teclado +--- +Para ser completamente accesible, una página web debe ser operable por alguién utilizando únicamente un teclado para acceder y controlarla. Esto incluye usuarios de lectores de pantalla, pero también puede incluir a quienes tienen dificultades utilizando un dispositivo apuntador como un ratón o una bola de rastreo, o aquellos cuyo ratón no esta funcionando temporalmente, o la gente que simplemente prefiere usar un teclado como entrada siempre que les sea posible. + +## Los elementos enfocables deben tener una semántica interactiva + +Si un elemento puede ser enfocado utilizando un teclado, entonces debería ser interactivo, es decir, el usuario debería ser capaz de hacer algo y producir un cambio de algún tipo (por ejemplo, activar un enlace o cambiar una opción). + +> **Nota:** Una excepción importante a esta regla es si el elemento tiene aplicado `role="document"`, **dentro** un contexto interactivo (como un `role="application"`). En tal caso, enfocar el documento anidado es la única forma de devolver la tecnología de asistencia a un estado de no interactividad (comúnmente llamado "modo navegador"). + +La mayoría de los elementos son enfocables por defecto, y se puede hacer que un elemento sea enfocable al añadir el atributo `tabindex=0`. Sin embargo, sólo se debería añadir `tabindex` si el elemento también se hace interactivo, por ejemplo, definiendo los eventos de teclado apropiados para los manejadores de eventos. + +### Ver también + +- Atributo HTML global [tabindex](/es/docs/Web/HTML/Global_attributes/tabindex) +- Manejador de evento global: [onkeydown](/es/docs/Web/API/GlobalEventHandlers/onkeydown) +- Manejador de evento global: [onkeyup](/es/docs/Web/API/GlobalEventHandlers/onkeyup) + +## Evitar usar el atributo `tabindex` con un valor mayor a cero + +El atributo `tabindex` indica que un elemento es enfocable utilizando el teclado. Un valor de cero indica que el elemento es parte del orden de enfoque normal, que está basado en el orden de los elementos en el documento HTML. Un valor positivo pone al elemento adelante de aquellos con el orden normal; elementos con valores positivos son enfocados en el orden del valor de `tabindex` (1, luego 2, después 3, etc.). + +Esto genera una confusión para usuarios que solo usen el teclado cuando el orden del enfoque difiera al orden lógico de la página. Una mejor estrategia es estructurar el documento HTML para que los elementos enfocables estén es un orden lógico, sin la necesidad de reordenarlos con un valor positivo de `tabindex`. + +### Ver también + +- Atributo HTML globlal [tabindex](/es/docs/Web/HTML/Global_attributes/tabindex) +- [Entendiento el orden del enfoque](https://www.w3.org/WAI/WCAG21/Understanding/focus-order.html) +- [No use un tabindex mayor que 0](http://adrianroselli.com/2014/11/dont-use-tabindex-greater-than-0.html) + +## Los elementos a los que se les puede hacer click deben ser enfocables y deberían tener semánticas interactivas + +Si a un elemento se le puede hacer click con un dispositivo apuntador, como un ratón, entonces también debería enfocable utilizando el teclado, y el usuario debería ser capaz de hacer algo al interactuar con este. + +A un elemento se le puede hacer click si tiene in manejador de evento`onclick` definido. Se puede hacer enfocable al añadir un atributo-valor `tabindex=0`. Se puede hacer que se opere con un teclado al definir un manejador de evento `onkeydown`; en la mayoría de los casos, la acción tomada por el manejador de eventos debería ser la misma para los dos tipos de eventos + +### Ver también + +- El atributo global HTML [tabindex](/es/docs/Web/HTML/Global_attributes/tabindex) +- Manejador de evento global: [onkeydown](/es/docs/Web/API/GlobalEventHandlers/onkeydown) +- Manejador de evento global: [onkeyup](/es/docs/Web/API/GlobalEventHandlers/onkeyup) + +## Los elementos interactivos deben ser capaz de ser activos utilizando un teclado + +Si el usuario puede interactuar con un elemento utilizando el tacto o un dispositivo apuntador, entonces el elemento debería ser también capaz de interactuar con el teclado, Es decir, si hay manejadores de evento definidos para los eventos al tacto y al hacer click, también debería haber manejadores de eventos para el teclado. Los manejadores de eventos para el teclado deberían realizar la misma interacción que sus contrapartes con el tacto y al hacer click. + +### Ver también + +- Manejador de evento global: [onkeydown](/es/docs/Web/API/GlobalEventHandlers/onkeydown) +- Manejador de evento global: [onkeyup](/es/docs/Web/API/GlobalEventHandlers/onkeyup) + +## Los elementos interactivos deben ser enfocables + +Si el usuario puede interactuar con un elemento (por ejemplo, usando el tacto o con un dispositivo apuntador) entonces debería ser enfocable utilizando el teclado. Puede hacerse enfocable al añadirle el atributo-valor`tabindex=0`. Eso añadirá el elemento a la lista de elementos que pueden ser enfocados al presionar la tecla Tab, en la secuencia en que dichos elementos se encuentran definidos en el documento HTML. + +### Ver también + +- Atributo global HTML [tabindex](/es/docs/Web/HTML/Global_attributes/tabindex) + +## Elementos enfocables deben tener un estilo al estar enfocados + +Cualquier elemento que pueda recibir el enfoque desde el teclado, debería tener un estilo visible que indique cuando el elemento esta enfocado. Se puede hacer esto con la pseudo-clase de CSS [`:focus`](/en-US/docs/Web/CSS/:focus). + +Elementos enfocables estándar como enlaces y los campos de entrada reciben un estilo especial por parte del navegador de forma predeterminada, por lo que podría no ser necesario especificar un estilo de enfoque para éstos, a menos que se quiera que el estilo de enfoque sea más distintivo. + +Si se crean componentes enfocables, se debe estar seguro de que también se defina el estilo de enfoque para éstos. + +If you create your own focusable components, be sure that you also define focus styling for them. + +### Ver también + +- [Utilizando CSS para cambiar la presentación de un componente UI cuando reciba el enfoque](https://www.w3.org/WAI/WCAG21/Techniques/css/C15.html) diff --git a/files/es/web/accessibility/understanding_wcag/perceivable/color_contrast/index.html b/files/es/web/accessibility/understanding_wcag/perceivable/color_contrast/index.html deleted file mode 100644 index f694c0b3883af1..00000000000000 --- a/files/es/web/accessibility/understanding_wcag/perceivable/color_contrast/index.html +++ /dev/null @@ -1,163 +0,0 @@ ---- -title: Contraste del color -slug: Web/Accessibility/Understanding_WCAG/Perceivable/Color_contrast -tags: - - Accesibilidad - - Perceptible - - contraste -translation_of: Web/Accessibility/Understanding_WCAG/Perceivable/Color_contrast -original_slug: Web/Accesibilidad/Understanding_WCAG/Perceivable/Color_contraste ---- -El contraste del color entre el fondo y el contenido del primer plano (que suele ser texto) debe ser lo suficientemente alto como para garantizar la legibilidad.
- -Al diseñar interfaces legibles para diferentes capacidades de visión, las directrices de la WCAG recomiendan las siguientes relaciones de contraste:
- -| Tipo de contenido | -Relación mínima (nivel AA) | -Relación mejorada (nivel AAA) | -
|---|---|---|
| Cuerpo de texto | -4.5 : 1 | -7 : 1 | -
| Texto a gran escala (120-150% mayor que el cuerpo de texto) | -3 : 1 | -4.5 : 1 | -
| Componentes activos de la interfaz de usuario y objetos gráficos como iconos y gráficos | -3 : 1 | -No definido | -
Estas proporciones no se aplican al texto "incidental", como controles inactivos, logotipos o texto puramente decorativo.
- -Consulta la sección Solución a continuación para obtener más información.
- -Tener un buen contraste de color en tu sitio web beneficia a todos tus usuarios, pero es particularmente beneficioso para los que tienen cierto tipo de ceguera al color y otras afecciones similares, como los que experimentan una baja sensibilidad al contraste y tienen dificultades para diferenciar colores parecidos. Esto se debe a que no distinguen las áreas brillantes y oscuras con tanta facilidad como las personas que no tienen esa discapacidad, y por lo tanto tienen problemas para ver los bordes y otros detalles.
- -Es bueno tener un diseño atractivo en tu sitio web, pero el diseño es inútil si tus usuarios no pueden leer el contenido.
- -Ejemplos
- -Veamos algunos ejemplos simples con código HTML y CSS:
- -<div class="good">Buen contraste</div> -<div class="bad">Mal contraste</div>- -
div {
- /* General div styles here */
-}
-
-.good {
- background-color: #fae6fa;
-}
-
-.bad {
- background-color: #400064;
-}
-
-Ambos fragmentos de texto tienen color negro por defecto. El <div> "good" tiene un color de fondo púrpura claro, lo que hace que el texto sea fácil de leer:
example1
- -<div class="good"> - Good contrast - </div>- -
div {
- font-family: sans-serif;
- text-align: center;
- font-size: 2rem;
- font-weight: bold;
- width: 250px;
- padding: 30px;
- border-radius: 20px;
- box-shadow: 1px 1px 1px black;
-}
-
-.good {
- background-color: #fae6fa;
-}
-{{EmbedLiveSample('example1', '100%', '100')}}
- -El <div> "bad", por otro lado, tiene un color de fondo púrpura muy oscuro, lo que hace que el texto sea mucho más difícil de leer:
example2
- -<div class="bad"> - Bad contrast - </div>- -
div {
- font-family: sans-serif;
- text-align: center;
- font-size: 2rem;
- font-weight: bold;
- width: 250px;
- padding: 30px;
- border-radius: 20px;
- box-shadow: 1px 1px 1px black;
-}
-
-.bad {
- background-color: #400064;
-}
-{{EmbedLiveSample('example2', '100%', '100')}}
- --
-
Solución
- -Al elegir un esquema de color para tu sitio web, selecciona colores de primer plano y de fondo que tengan un buen contraste. Haz que el contraste de color sea lo mejor posible dentro de las limitaciones de tu diseño — preferiblemente elige el nivel AAA (ver 1.4.6 más abajo), pero al menos cumple con el nivel AA (ver 1.4.3 más abajo).
- -Si incluyes contenido no textual, como vídeo o animación, debes seguir 1.4.11 (nuevamente, ver más abajo).
- -Para verificar el contraste a medida que seleccionas los colores puedes utlizar una herramienta como Color Contrast Checker de WebAIM.
- -También puedes comprobar el contraste de color sobre la marcha utilizando las herramientas para desarrolladores de Firefox— ver nuestra guía Accessibility inspector, y en particular la sección Check for accessibility issues. Prueba a usarlo en los ejemplos en vivo en la sección de descripción.
- -Criterios de conformidad relacionados con WCAG
- --
-
- 1.4.3 Contraste mínimo (AA) -
- El contraste de color entre el fondo y el contenido del primer plano debe tener un nivel mínimo para garantizar la legibilidad:
-
-
-
- El texto y el fondo deben tener una relación de contraste de al menos 4.5:1. -
- Los encabezados (o simplemente el texto más grande) deben tener una relación de contraste de al menos 3:1. El texto más grande se define como de al menos 18pt, o 14pt en negrita. -
- - 1.4.6 Contraste mejorado (AAA) -
- Esto sigue y se basa en el criterio 1.4.3.
-
-
-
- El texto y el fondo deben tener una relación de contraste de al menos 7:1. -
- Los encabezados (o simplemente el texto más grande) deben tener una relación de contraste de al menos 4.5:1. -
- - 1.4.11 Contraste no textual (AA) (añadido en 2.1) -
- Debe haber una relación mínima de contraste de color de 3 a 1 para los componentes de la interfaz de usuario y los objetos gráficos. -
Ver también
- - diff --git a/files/es/web/accessibility/understanding_wcag/perceivable/color_contrast/index.md b/files/es/web/accessibility/understanding_wcag/perceivable/color_contrast/index.md new file mode 100644 index 00000000000000..c3ebb2617022e0 --- /dev/null +++ b/files/es/web/accessibility/understanding_wcag/perceivable/color_contrast/index.md @@ -0,0 +1,145 @@ +--- +title: Contraste del color +slug: Web/Accessibility/Understanding_WCAG/Perceivable/Color_contrast +tags: + - Accesibilidad + - Perceptible + - contraste +translation_of: Web/Accessibility/Understanding_WCAG/Perceivable/Color_contrast +original_slug: Web/Accesibilidad/Understanding_WCAG/Perceivable/Color_contraste +--- +El [contraste del color](https://www.w3.org/TR/WCAG21/#dfn-contrast-ratio) entre el fondo y el contenido del primer plano (que suele ser texto) debe ser lo suficientemente alto como para garantizar la legibilidad. + +Al diseñar interfaces legibles para diferentes capacidades de visión, las directrices de la WCAG recomiendan las siguientes relaciones de contraste: + +| Tipo de contenido | Relación mínima (nivel AA) | Relación mejorada (nivel AAA) | +| --------------------------------------------------------------------------------------- | -------------------------- | ----------------------------- | +| Cuerpo de texto | 4.5 : 1 | 7 : 1 | +| Texto a gran escala (120-150% mayor que el cuerpo de texto) | 3 : 1 | 4.5 : 1 | +| Componentes activos de la interfaz de usuario y objetos gráficos como iconos y gráficos | 3 : 1 | No definido | + +Estas proporciones no se aplican al texto "incidental", como controles inactivos, logotipos o texto puramente decorativo. + +Consulta la sección [Solución](#solución) a continuación para obtener más información. + +Tener un buen contraste de color en tu sitio web beneficia a todos tus usuarios, pero es particularmente beneficioso para los que tienen cierto tipo de ceguera al color y otras afecciones similares, como los que experimentan una baja sensibilidad al contraste y tienen dificultades para diferenciar colores parecidos. Esto se debe a que no distinguen las áreas brillantes y oscuras con tanta facilidad como las personas que no tienen esa discapacidad, y por lo tanto tienen problemas para ver los bordes y otros detalles. + +Es bueno tener un diseño atractivo en tu sitio web, pero el diseño es inútil si tus usuarios no pueden leer el contenido. + +## Ejemplos + +Veamos algunos ejemplos simples con código HTML y CSS: + +```html +Este artículo ofrece consejos prácticos sobre cómo hacer que tu sitio web cumpla con los criterios de Percepción de WCAG 2.0 y 2.1. Los estados perceptivos que los usuarios deben poder reconocer utilizando alguno de sus sentidos.
- -Nota: Para leer las definiciones de la W3C sobre Percepción y las guías para cumplir con los criterios dirígete a Principle 1: Perceivable - Information and user interface components must be presentable to users in ways they can perceive.
-Pauta 1.1 — Dar alternativas de texto para contenido no textual.
- -La clave aquí es convertir el texto a otros formatos que puedan ser entendidos por personas con otras capacidades; ya sea si utilizan un screen-reader, zoom o un lector de braille. El contenido no textual se refiere a elementos multimedia como imágenes, audio y vídeo.
- -| Criterio de éxito | -Cómo cumplir | -Recursos prácticos | -
|---|---|---|
| 1.1.1 Alternativas textuales (A) | -Toda imagen que sea útil para el usuario debe tener un texto alternativo. | -Texto alternativo. | -
|
- Las imágenes complejas o gráficos deben tener una alternativa accesible, ya sea en al misma página o en una externa. Utiliza un elemento de link en vez del atributo |
-
- Una alternativa textual o una tabla puede resolverlo (ver HTML table advanced features and accessibility y Other text alternative mechanisms para leer sobre el argumento en contra de |
- |
| El contenido multimedia (por ejemlo, audio o vídeo) debería tener por lo menos una descripción accesible disponible (captions o similar). | -
- Ver alternativas de texto para opciones de captions, y Audio transcripts, Video text tracks o Other multimedia content para otras alternativas. - |
- |
Los elementos de interfaz como botones o elementos de formulario deberán tener labels que describan su propósito. |
- Deberás asegurarte de que los botones describan su función (por ejemplo, <button>Subir imagen</button>). Para más información ver UI controls. |
- |
|
- Implementa elementos decorativos (imágenes o vídeos) de manera que sea invisibles para lectores de pantalla, de esta forma evitarás confundir a estos usuarios. - |
-
- Las imágenes decorativas deben ser implementadas utilizando la propiedad Si incluyes un vídeo o audio en tu sitio que se reproduce automáticamente intenta de que sea lo menos molesto posible. No hagas que se vea ni actúe como contenido y provee una forma de apagarlo. - |
-
Nota: Ver también WCAG description for Guideline 1.1: Text alternatives.
-Pauta 1.2 — Proporcionar alternativas para los medios tempo-dependientes.
- -Los medios tempo-dependientes se refieren a multimedia con una duración (audio y vídeo, por ejemplo). Ten en cuenta que si este contenido multimedia funciona como una alternativa a un contenido textual no necesitas proveer otra alternavtiva.
- -| Criterio de éxito | -Cómo cumplir | -Recursos prácticos | -
|---|---|---|
| 1.2.1 Provee alternativas para multimedia de solo audio o solo vídeo (A) | -A transcript should be provided for prerecorded audio-only media, and a transcript or audio description should be provided for prerecorded video-only media (i.e. silent video). | -See Audio transcripts for transcript information. No audio description tutorial available as yet. | -
| 1.2.2 Provee captions para los vídeos (A) | -You should provide captions for video presented on the web, e.g. HTML5 video. This is for the benefit of people who can't hear the audio part of the video. | -See Video text tracks for HTML5 video captions, and Other multimedia content for other technologies. See also Add your own subtitles & closed captions (YouTube). | -
|
- 1.2.3 Provee texto alternativo o una descripción para el audio del vídeo (A) - |
- You should provide text transcripts or audio descriptions for video presented on the web, e.g. HTML5 video. This is for the benefit of people who can't see the visual part of the video, and don't get the full content from the audio alone. | -See Audio transcripts for transcript information. No audio description tutorial available as yet. | -
| 1.2.4 Provee captions para audio en vivo (AA) | -You should provide synchronized captions for all live multimedia that contains audio (e.g. video conferences, live audio broadcasts.) | -- |
| 1.2.5 Provee descripciones de adio para vídeo pre-grabado (AA) | -Audio descriptions should be provided for prerecorded video, but only where the existing audio does not convey the full meaning expressed by the video. | -- |
| 1.2.6 Provee lenguaje de signos equivalente a el audio pre-grabado (AAA) | -An equivalent sign language video should be provided for any prerecorded content containing audio. | -- |
| 1.2.7 Provee un vídeo extendido con descripciones de audio (AAA) | -Where audio descriptions cannot be provided (see 1.2.5) due to video timing issues (e.g. there are no suitable pauses in the content in which to insert the audio descriptions), an alternative version of the video should be provided that includes inserted pauses (and audio descriptions). | -- |
| 1.2.8 Provee una alternativa para los elementos multimedia pre-grabados (AAA) | -For all content that features video, a descriptive text transcript should be provided, for example a script of the movie you are watching. This is for the benefit of hearing impaired viewers who cannot hear the content. | -See Audio transcripts for transcript information. | -
| 1.2.9 Provee una transcripción para el audio en vivo (AAA) | -For any live audio content being broadcast, a descriptive text should be provided, for example a script of the play or musical you are listening to. This is for the benefit of hearing impaired viewers who cannot hear the content. | -See Audio transcripts for transcript information. | -
Nota: Ver también la descripción de WCAG Guideline 1.2: Time-based Media: Provide alternatives for time-based media.
-Pauta 1.3 — Crear contenido que pueda presentarse de diferentes formas
- -Esta pauta hace referencia a la posibilidad de que todo contenido pueda ser consumido de distintas formas, adaptándose a las necesidades del usuario.
- -| Criterios de éxito | -Cómo cumplir | -Recursos prácticos | -
|---|---|---|
| 1.3.1 Info and relationships (A) | -
- Any content structure — or visual relationship made between content — can also be determined programmatically, or be inferred from text description. The main situations in which this is relevant are: - -
|
- The whole of
- HTML: A good basis for accessibility is packed with information about this, but you should particularly refer to Good semantics, UI controls, and Text alternatives. - |
-
| 1.3.2 Meaningful content sequence (A) | -A sensible, logical reading order should be easy to determine for any content, even if it is visually presented in an unusual way. The order should be made obvious by use of correct semantic elements (e.g. headings, paragraphs), with CSS being used to create any unusual layout styles, irrespective of the markup. | -Again, refer to HTML: A good basis for accessibility. | -
| 1.3.3 Sensory characteristics (A) | -
- Instructions for operating controls or understanding content do not rely on a single sense — this may prove inaccessible to people with a disability related to that sense, or a device that does not support that sense. So for example: - -
-
- Note: Conveying instructions solely by color is related, but covered in a different guideline — 1.4.1. - |
- - |
| 1.3.4 Orientation (AA) added in 2.1 | -Content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential. | -- - | -
| 1.3.5 Identify Input Purpose (AA) added in 2.1 | -
- - - Follow the list of 53 input fields to programmatically identify the purpose of a field. - |
- Understanding Identify Input Purpose | -
| 1.3.6 Identify Purpose (AAA) added in 2.1 | -In content implemented using markup languages, the purpose of User Interface Components, icons, and regions can be programmatically determined. | -Understanding Identify Purpose | -
Nota: Ver también la descripción de WCAG: Guideline 1.3: Adaptable: Create content that can be presented in different ways without losing information or structure.
-Pauta 1.4: Facilitar a los usuarios ver y oír el contenido, incluyendo la separación entre el primer plano y el fondo
- -Esta pauta tiene como objetivo la creación de contenido que sea fácil de diferenciar del fondo y otras decoraciones. El ejemplo clásico es sobre color (tanto en relación al contraste como utilizarlo para transmitir información), pero aplica también en otras situaciones.
- -| Criterios de éxito | -Cómo cumplir | -Recursos prácticos | -
|---|---|---|
| 1.4.1 Use of color (A) | -
- Color should not be solely relied upon to convey information — for example, in forms you should never mark required fields purely with a color (like red). Instead (or as well as), something like an asterisk with a label of "required" would be more appropriate. - |
- See Color and color contrast and Multiple labels. | -
| 1.4.2 Audio controls (A) | -For any audio that plays for longer than three seconds, accessible controls should be provided to play and pause the audio/video, and mute/adjust volume. | -Use native <button>s to provide accessible keyboard controls, as shown in Video player syling basics. |
-
| 1.4.3 Minimum contrast (AA) | -
- The color contrast between background and foreground content should be at a minimum level to ensure legibility: - -
|
- See Color and color contrast. | -
| 1.4.4 Resize text (AA) | -The page should be readable and usable when the text size is doubled. This means that designs should be responsive, so that when the text size is increased, the content is still accessible. | -- |
| 1.4.5 Images of text (AA) | -Images should NOT be used to present content where text would do the job. For example, if an image is mostly textual, it could be represented using text as well as images. | -- |
| 1.4.6 Enhanced contrast (AAA) | -
- This follows, and builds on, criterion 1.4.3. - -
|
- - |
| 1.4.7 Low or no background audio (AAA) | -Prerecorded audio recordings that primarily feature speech should have minimal background noise, so the content can be easily understood. | -- |
| 1.4.8 Visual presentation (AAA) | -
- For text content presentation, the following should be true: - -
|
- - |
| 1.4.9 Images of text (No Exception) (AAA) | -Text should not be presented as part of an image unless it is purely decoration (i.e. it does not convey any content), or cannot be presented in any other way. | -- |
| 1.4.10 Reflow (AA) added in 2.1 | -
-
|
- Understanding Reflow | -
| 1.4.11 Non-Text Contrast(AA) added in 2.1 | -Minimum color contrast ratio of 3 to 1 for user interface components and graphical objects. | -Understanding Non-Text Contrast | -
| 1.4.12 Text Spacing (AA) added in 2.1 | -
- No loss of content or functionality occurs when the following styles are applied: - -
|
- Understanding Text Spacing | -
| 1.4.13 Content on Hover or Focus (AA) added in 2.1 | -
- Additional content appear and disappear in coordination with hover and keyboard focus, this success criterion specifies three conditions that must be met: - -
|
- Understanding Content on Hover or Focus | -
Nota: Ver también la descripción de WCAG: Guideline 1.4: Distinguishable: Make it easier for users to see and hear content including separating foreground from background..
-| Criterio de éxito | +Cómo cumplir | +Recursos prácticos | +
|---|---|---|
| 1.1.1 Alternativas textuales (A) | ++ Toda imagen que sea útil para el usuario debe tener un texto + alternativo. + | ++ Texto alternativo. + | +
|
+
+ Las imágenes complejas o gráficos deben tener una alternativa
+ accesible, ya sea en al misma página o en una externa. Utiliza un
+ elemento de link en vez del atributo |
+
+
+ Una alternativa textual o una tabla puede resolverlo (ver
+ HTML table advanced features and accessibility
+ y
+ Other text alternative mechanisms
+ para leer sobre el argumento en contra de |
+ |
| + El contenido multimedia (por ejemlo, audio o vídeo) debería tener por lo + menos una descripción accesible disponible (captions o similar). + | +
+ + Ver + alternativas de texto + para opciones de captions, y + Audio transcripts, + Video text tracks + o + Other multimedia content + para otras alternativas. + + |
+ |
+ Los elementos de interfaz como botones o elementos de formulario deberán
+ tener labels que describan su propósito.
+ |
+
+ Deberás asegurarte de que los botones describan su función (por ejemplo,
+ <button>Subir imagen</button>). Para más
+ información ver
+ UI controls.
+ |
+ |
|
+ + Implementa elementos decorativos (imágenes o vídeos) de manera que sea + invisibles para lectores de pantalla, de esta forma evitarás confundir + a estos usuarios. + + |
+
+
+ Las imágenes decorativas deben ser implementadas utilizando la
+ propiedad + Si incluyes un vídeo o audio en tu sitio que se reproduce + automáticamente intenta de que sea lo menos molesto posible. No hagas + que se vea ni actúe como contenido y provee una forma de apagarlo. + + |
+
| Criterios de éxito | +Cómo cumplir | +Recursos prácticos | +
|---|---|---|
| 1.3.1 Info and relationships (A) | +
+ Any content structure — or visual relationship made between content — can also be determined + programmatically, or be inferred from text description. The main situations in which this is + relevant are: +
|
+ The whole of
+ HTML: A good basis for accessibility is packed + with information about this, but you should particularly refer to Good semantics, UI controls, and Text alternatives. + |
+
| 1.3.2 Meaningful content sequence (A) | +A sensible, logical reading order should be easy to determine for any content, even if it is visually + presented in an unusual way. The order should be made obvious by use of correct semantic elements (e.g. + headings, paragraphs), with CSS being used to create any unusual layout styles, irrespective of the + markup. | +Again, refer to HTML: A good basis for accessibility. + | +
| 1.3.3 Sensory characteristics (A) | +
+ Instructions for operating controls or understanding content do not rely on a single sense — this may + prove inaccessible to people with a disability related to that sense, or a device that does not + support that sense. So for example: +
+
+ Note: Conveying instructions solely by color is related, but covered in a + different guideline — 1.4.1. + |
+ + |
| 1.3.4 Orientation (AA) added + in 2.1 | +Content does not restrict its view and operation to a single display orientation, such as portrait or + landscape, unless a specific display orientation is essential. | ++ + | +
| 1.3.5 Identify Input Purpose (AA) added in 2.1 | +
+ + Follow the list of 53 input fields to + programmatically identify the purpose of a field. + |
+ Understanding Identify + Input Purpose | +
| 1.3.6 Identify Purpose (AAA) added in 2.1 | +In content implemented using markup languages, the purpose of User Interface Components, icons, and + regions can be programmatically determined. | +Understanding Identify + Purpose | +
| Criterios de éxito | +Cómo cumplir | +Recursos prácticos | +
|---|---|---|
| 1.4.1 Use of color (A) | +
+ Color should not be solely relied upon to convey information — for example, in forms you should never mark + required fields purely with a color (like red). Instead (or as well as), something like an asterisk with a + label of "required" would be more appropriate. + |
+ See Color and color + contrast and Multiple + labels. | +
| 1.4.2 Audio controls (A) | +For any audio that plays for longer than three seconds, accessible controls should be provided to play and + pause the audio/video, and mute/adjust volume. | +Use native <button>s to provide accessible keyboard controls, as shown in Video player
+ syling basics. |
+
| 1.4.3 Minimum contrast (AA) | +
+ The color contrast between background and foreground content should be at a minimum level to ensure + legibility: +
|
+ See Color and color + contrast. | +
| 1.4.4 Resize text (AA) | +The page should be readable and usable when the text size is doubled. This means that designs should be + responsive, so that when the text size is increased, the content is still accessible. | ++ |
| 1.4.5 Images of text (AA) | +Images should NOT be used to present content where text would do the job. For example, if an image is mostly + textual, it could be represented using text as well as images. | ++ |
| 1.4.6 Enhanced contrast (AAA) | +
+ This follows, and builds on, criterion 1.4.3. +
|
+ + |
| 1.4.7 Low or no background audio (AAA) | +Prerecorded audio recordings that primarily feature speech should have minimal background noise, so the + content can be easily understood. | ++ |
| 1.4.8 Visual presentation (AAA) | +
+ For text content presentation, the following should be true: +
|
+ + |
| 1.4.9 Images of text (No Exception) (AAA) | +Text should not be presented as part of an image unless it is purely decoration (i.e. it does not convey any + content), or cannot be presented in any other way. | ++ |
| 1.4.10 Reflow (AA) added in + 2.1 | +
+
|
+ Understanding Reflow | +
| 1.4.11 Non-Text Contrast(AA) added in 2.1 | +Minimum color contrast ratio of 3 to 1 for user interface components and graphical objects. | +Understanding Non-Text + Contrast | +
| 1.4.12 Text Spacing (AA) added in 2.1 | +
+ No loss of content or functionality occurs when the following styles are applied: +
|
+ Understanding Text Spacing | +
| 1.4.13 Content on Hover or Focus (AA) added in 2.1 | +
+ Additional content appear and disappear in coordination with hover and keyboard focus, this success criterion + specifies three conditions that must be met: +
|
+ Understanding Content on + Hover or Focus | +
Hay muchas situaciones en las cuales un control, dialogo o cualquier otra característica de un sitio web deberían recibir un nombre o etiqueta descriptiva para permitir a los usuarios de técnologías asistivas entender cual es su propósito y ser capaz de entenderlo y operarlo correctamente. Hay un número de diferentes tipos de problemas en esta categoría, dependientes del contexto, y cada uno tiene su propia solución. Los diferentes problemas y soluciones son discutidas en las secciones posteriores.
- -Utilizar el atributo alt para etiquetar elementos que ocupen un área que tiene el atributo href
- -En mapas de imágenes, cada elemento {{htmlelement("area")}} con un atributo alt definiendo un nombre que describa el recurso al que enlaza el area. Fallar al hacer eso provoca que un mapa de imagen sea difícil de usar para usuarios que usen tecnología asistiva — ellos necesitan texto alternativo para ser capaces de entender el propósito de una imagen.
Ejemplos
- -El siguiente ejemplo muestra un simple mapa de imagen (tomada de H24: Providing text alternatives for the area elements of image maps):
- -<img src="welcome.gif" usemap="#map1" - alt="Areas in the library. Select an area for -more information on that area." /> -<map id="map1" name="map1"> - <area shape="rect" coords="0,0,30,30" - href="reference.html" alt="Reference" /> - <area shape="rect" coords="34,34,100,100" - href="media.html" alt="Audio visual lab" /> -</map>- -
Ver la página de referencia del elemento <area> para unu ejemplo interactivo.
Ver también
- --
-
- {{htmlelement("area")}} -
- H24: Providing text alternatives for the area elements of image maps -
Los diálogos deberían ser etiquetados
- -Para cualquier contenedor cuyo contenido actue como una caja de diálogo (por ejemplo, un modal preguntando al usuario realizar una elección o responder a una acción siendo tomada), debe tener una etiqueta descriptiva o nombre, para que la tecnología asistiva le permita al usuario descrubir fácilmente cual es su propósito.
- -Una caja de diálogo es generalmente denominada con un ARIA role="dialog" o role="alertdialog"; se puede usar tanto el atributo aria-label o aria-labelledby para proporcionar una etiqueta.
Ejemplos
- -El siguiente ejemplo muestra una caja de dialogo sencilla, definida como role="dialog" y etiquetada con aria-labelledby.
<div role="dialog" aria-labelledby="dialog1Title" aria-describedby="dialog1Desc"> - <h2 id="dialog1Title">Your personal details were successfully updated</h2> - <p id="dialog1Desc">You can change your details at any time in the user account section.</p> - <button>Close</button> -</div>- -
Si la caja de diálogo no tiene un encabezado, se puede usar aria-label para contener la etiqueta de texto:
<div role="dialog" aria-label="Personal details updated confirmation"> - <p>Your personal details were successfully updated. You can - change your details at any time in the user account section.</p> - <button>Close</button> -</div>- -
Ver también
- --
-
role="dialog"
- role="alertdialog"
- aria-label
- aria-labelledby
- - WAI-ARIA: dialog role -
- Dialog authoring practices -
Los documentos deben tener un título
- -Es importante que cada documento HTML, incluya un elemento {{htmlelement("title")}} que describa el propósito de la página. Una técnica común de navegación para usuarios que usan tecnologías asistivas es inferir el contenido de la página leyendo su título. Si no hay título disponible, tienen que navegar por la página para determinar su contenido, lo cual puede ser un proceso largo y confuso.
- -Ejemplos
- -El título para el artículo de refencia sobre el elemento {{htmlelement("title")}} es como sigue:
- -<title><title>: The Document Title element - HTML: Hypertext Markup Language | MDN</title>- -
Otro ejemplo podría ser:
- -<title>Fill in your details to register — myGov services</title>- -
Para ayudar al usuario, se puede actualizar el titulo de la página para reflejar cambios significativos al estado de la página (como problemas en la validación de un formulario):
- -<title>2 errors — Fill in your details to register — myGov services</title>- -
Ver también
- --
-
- {{htmlelement("title")}} -
Contenido incrustado debe ser etiquetado
- -Asegurarse que elementos que incrusten contenido tengan un atributo título que describa el contenido incrustado. Esto incluye al elemento {{htmlelement("embed")}} y al elemento {{htmlelement("object")}}. Estos elementos son usualmente definidos por un contenido gráfico, similar a un elemento {{HTMLelement("img")}}. Un título descriptivo ayuda a los usuarios de tecnologías asistivas entender que muestra el elemento.
- -Figuras con leyendas opcionales deberían ser etiquetadas
- -Para una mejor accesibilidad, incluir un {{HTMLElement("figcaption")}} dentro de un elemento {{HTMLElement("figure")}}, incluso si hacerlo es opcional técnicamente. La leyenda es adicional a cualquier texto alternativo en las imágenes dentro de la figura. La leyenda describe el proósito de una figura en el documento, que puede ser diferente de una descripción sencilla de un elemento visual, tal como lo proporciona el texto alternativo.
- -Ejemplo
- -El siguiente ejemplo muestra código para una figura con un pie de página. El atributo alt del elemento {{htmlelement("img")}} describe la apariencia de la imagen; el elemento {{htmlelement("figcaption")}} lo describe desde una perspectiva funcional (en este caso, el nombre en latín de la flor de la imagen).
<figure> - <img src="milkweed.jpg" - alt="Black and white close-up photo of milkweed flowers"> - <figcaption>Asclepias verticillata</figcaption> -</figure> -- -
Los elementos de un conjuto campos deben ser etiquetados
- -Los elementos de un conjunto de campos (fieldset) deben tener un texto descriptivo, similar a otros elementos del formulario. Utilice el elemento {{htmlelement("legend")}} para describir el propósito de un conjunto de campos (fieldset).
- -Utilizar una leyenda para etiquetar un conjunto de campos
- -Al agrupar un conjunto de elementos de un formulario con un elemento {{htmlelement("fieldset")}}, se debería incluir un elemento {{htmlelement("legend")}} anidado dento de éste, conteninedo una clara descripción del grupo.
- -Usuarios de tecnologías asistivas encuentras esta descripción útil cuando tratan de entender el propósito del grupo. Sin la leyenda, tienen que navegar individualmente por todos los controles del formulario en el grupo para inferir una idea del propósito general, lo que puede resultar confuso.
- -Ejemplo
- -<form> - <fieldset> - <legend>Choose your favorite monster</legend> - - <input type="radio" id="kraken" name="monster"> - <label for="kraken">Kraken</label><br/> - - <input type="radio" id="sasquatch" name="monster"> - <label for="sasquatch">Sasquatch</label><br/> - - <input type="radio" id="mothman" name="monster"> - <label for="mothman">Mothman</label> - </fieldset> -</form>- -
Puede ver un ejemplo interactivo en la página de referencia de <fieldset>.
Ver también
- --
-
- {{htmlelement("fieldset")}} -
- {{htmlelement("legend")}} -
Los elementos de un formulario deben estar etiquetados
- -Todos los elementos dentro de un formulario deben tener un elemento {{htmlelement("label")}} que identifique su propósito. Esto aplica a todos los tipos de elementos {{htmlelement("input")}}, como también para elementos {{htmlelement("button")}}, {{htmlelement("output")}}, {{htmlelement("select")}}, {{htmlelement("textarea")}}, {{htmlelement("progress")}} y {{htmlelement("meter")}}, como para cualquier elemento con el ARIA role switch.
El elemento del formulario puede ser puesto dentro de un elemento {{htmlelement("label")}}, en cuyo caso la asociación entre el elemento del formulario y la etiqueta es obvia por la estructura. O, se puede crear una asociación entre un {{htmlelement("label")}} y el elemento del formulario al especificar el valor id del elemento del formulario y el valor del atributo for de la etiqueta.
Ejemplos
- -<label>I agree to the terms and conditions. - <input type="checkbox" id="terms"> -</label> - -<input type="checkbox" id="emailoptin"> -<label for="emailoptin">Yes, please send me news about this product.</label> -- -
Los elementos de un formulario deberían tener una etiqueta de texto visible
- -En adición a tener un elemento {{htmlelement("label")}} para cada elemento del formulario, estas etiquetas deberían ser visibles, no ocultarse. Las etiquetas visbles ayudan a todos los usuarios entender el propósito de un elemento de formulario. No dependa de un texto temporal porque éste desaparece tan pronto como el usuario empieza a escribir.
- -Los elementos marco ('frame') deben estar etiquetados
- -Los elementos marco ('frame'), tanto {{htmlelement("iframe")}} como el obsoleto y antiguo {{htmlelement("frame")}}, deben tener un título para describir el contenido del marco. Utilice el atributo title para etiquetar un elemento 'frame'. Sin un título, los usuarios que usen una tecnología asistiva tienen que navegar dentro del marco para entender que contiene, lo que puede ser difícil y confuso.
El elemento <frame> ya no forma parte de la especificación HTML en la versión HTML5. El soporte podría ser abandonado por los navegadores en el futuro. Además, es difícil para los lectores de pantalla el navegar páginas con elementos <frame>. Para una mejor accesibilidad y mantenimiento futuro, se debe rediseñar cualquier página que use marcos y reemplazarlos con el uso de CSS para lograr un diseño similar.
Como una mejor práctica, también proporcionar un {{htmlelement("title")}} para el documento que esta encapsulado en el marco, con un contenido identico al atributo title del marco. (Esto asumiendo que el documento encapsulado esta en control de uno, si no, tratar de coincidir el atributo title del marco con el título del documento.) Algunos lectores de pantalla reemplazan el contenido del atributo title con el contenido del {{htmlelement("title")}} del documento encapsulado. Es más seguro y más accesible el proporcionar el mismo título en ambos lugares.
Ejemplos
- -<iframe - title="MDN Web docs" - width="300" - height="200" - src="https://developer.mozilla.org"> -</iframe> - -- -
Usar el atributo alt para etiquetar elementos mglyph
- -Al escribir ecuaciones con MathML, a cada elemento {{mathmlelement("mglyph")}} se le debe asignar el atributo alt conteniendo un nombre que describa el símbolo. Puesto que los elementos mglyph son usados para símbolos no estándar sin definiciones Unicode, los lectores de pantalla no serán capaces de automáticamente nombrarlos. El texto alternativo ayuda a los usuarios de lectores de pantalla entender el símbolo.
Los encabezados deben ser etiquetados
- -Asegurarse que los encabezados tengan un contenido no vacío y no estén ocultos como con el CSS display:none o aria-hidden=true. Los usuarios de lectores de pantalla confían en los encabezados para entender la estructura y el contenido de un documento.
Además, es importante usar los elementos de encabezado sólo para los encabezados de sección reales, y no como una forma rápida de hacer que el texto se destaque. Los lectores de pantalla suelen "hojear" los encabezados de una página, de manera muy parecida a los usuarios con visión, el texto que no sea encabezado que se marca con elementos de encabezamiento puede causar confusión.
- -Los encabezados deberían tener contenido de texto visible
- -Asegurarse que los encabezados tengan un contenido no vacío y no estén ocultos como con el CSS display:none or aria-hidden=true. Los usuarios de lectores de pantalla confían en los encabezados para entender la estructura y el contenido de un documento. No use encabezados para marcar imágenes u otro contenido gráfico.
Utilizar el atributo title para describir el contenido de un <iframe>
- -Asegurarse que los elementos {{htmlelement("iframe")}} tienen un atributo title para describir el contenido de un marco. Sin un título, los usuarios de tecnologías asistivas tienen que navegar dentro del marco para entender que contiene, lo que puede ser difícil y confuso.
Una mejor práctica consiste en proveer un {{htmlelement("title")}} al documento encapsulado por el marco, con un contenido identico al atributo title del marco. (Asumiendo que el documento encapsulado es propio, si no, tratar de hacer coincidir el atributo title del marco con el título del documento.) Algunos lectores de pantalla reemplazan el contenido del atributo title con el contenido del {{htmlelement("title")}} del documento encapsulado. Es más seguro y accesible definir el mismo título en ambos lugares.
Contenido con imágenes deben ser etiquetados
- -Proporcionar un texto descriptivo para todas las imágenes y elementos parecidos a imágenes que tengan contenido (es decir que no sean decorativos. Esto incluye imágenes SVG, elementos {{htmlelement("img")}}, {{htmlelement("canvas")}}, {{htmlelement("map")}}, y {{htmlelement("area")}}, así como elementos {{htmlelement("input")}} donde este definido type=image y elementos {{htmlelement("object")}} donde el type empiece con image/. La forma típica de hacer esto es con el atributo alt. Asegurarse de que la descripción trasmite lo que muestra la imagen
Ejemplo
- -<img src="milkweed.jgp" - alt="Black and white close-up photo of milkweed flowers">- -
Elementos interactivos deben ser etiquetados
- -Si un elemento esta destinado para que los usuarios interactúen con él, debe estar etiquetado. Los elementos interactivos incluyen enlaces ({{htmlelement("a")}}), elementos de un formulario, botones, y cualquier elemento que tenga manejadores de eventos para ratón o teclado. La forma para etiquetar un elemento depende de su tipo: para elementos de un formulario, utilizar un {{htmlelement("label")}}; para enlaces, botones y elementos sobre los que se puede hacere click, el contenido del texto del elemento suele proporcionar la etiqueta. Si no existe otra opción para etiquetar un elemento, utilizar el atributo aria-label.
Usar el atributo label en elementos optgroup
- -En un elemento {{htmlelement("optgroup")}}, utilizar el atributo label para describir el gupo para que tecnologías asistivas puedan acceder a dicha descripción para sus usuarios.
Ejemplo
- -En este ejemplo, el atributo label en los elementos <optgroup> da un nombre de categoría para el grupo de opciones.
<label for="dino-select">Choose a dinosaur:</label> -<select id="dino-select"> - <optgroup label="Theropods"> - <option>Tyrannosaurus</option> - <option>Velociraptor</option> - <option>Deinonychus</option> - </optgroup> - <optgroup label="Sauropods"> - <option>Diplodocus</option> - <option>Saltasaurus</option> - <option>Apatosaurus</option> - </optgroup> -</select>- -
Las barras de herramientas deben ser etiquetadas cuando haya más de una barra
- -Si se define más una barra de herramientas en una aplicación web utilizando el rol ARIA toolbar, se debe usar el atributo aria-label para etiquetar cada una de ellas de manera que pueda ser descrita por la tecnología de asistencia. Es una buena práctica etiquetar una barra de herramientas aún cuando solo haya una en la página
Ver también
- - - -Criterios de aprobación relacionados a WCAG
- --
-
- 1.1.1 Contenido no textual (A) -
- Todo contenido no textual que es presentado al usuario tiene un texto alternativo que sirve un propósito similar, excepto para las situaciones listadas en el enlace anterior. -
- 2.4.4 Propósito del enlace (en contexto) (A) -
- El propósito de cada enlace puede determinarse a partir del texto del enlace o del texto del enlace en conjunto con contexto determinado programáticamente, salvo cuando el propósito del enlace sea ambiguo para los usuarios en general. -
- 2.4.9 Propósito del enlace (sólo el enlace) (AAA) -
- Se dispone de un mecanismo que permite identificar el propósito de cada enlace a partir del texto del enlace solamente, excepto cuando el propósito del enlace es ambiguo para los usuarios en general. -
+
+```
+
+Ver la [página de referencia del elemento](/es/docs/Web/HTML/Element/area) [``](/es/docs/Web/HTML/Element/area) para unu ejemplo interactivo.
+
+### Ver también
+
+- {{htmlelement("area")}}
+- [H24: Providing text alternatives for the area elements of image maps](https://www.w3.org/TR/WCAG20-TECHS/H24.html)
+
+## Los diálogos deberían ser etiquetados
+
+Para cualquier contenedor cuyo contenido actue como una caja de diálogo (por ejemplo, un modal preguntando al usuario realizar una elección o responder a una acción siendo tomada), debe tener una etiqueta descriptiva o nombre, para que la tecnología asistiva le permita al usuario descrubir fácilmente cual es su propósito.
+
+Una caja de diálogo es generalmente denominada con un ARIA [`role="dialog"`](/en-US/docs/Web/Accessibility/ARIA/Roles/dialog_role) o [`role="alertdialog"`](/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_alertdialog_role); se puede usar tanto el atributo [`aria-label`](/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-label_attribute) o [`aria-labelledby`](/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-labelledby_attribute) para proporcionar una etiqueta.
+
+### Ejemplos
+
+El siguiente ejemplo muestra una caja de dialogo sencilla, definida como `role="dialog"` y etiquetada con `aria-labelledby`.
+
+```
+Your personal details were successfully updated
+You can change your details at any time in the user account section.
+ +Your personal details were successfully updated. You can + change your details at any time in the user account section.
+ +
+