Cómo ocultar y actualizar el contenido

Cómo ocultar contenido de la tecnología asistencial

Alice Boxhall
Alice Boxhall
Dave Gash
Dave Gash
Meggin Kearney
Meggin Kearney

aria-hidden

Otra técnica importante para afinar la experiencia de los usuarios de tecnología de asistencia implica garantizar que solo las partes relevantes de la página queden expuestas a la tecnología de asistencia. Existen varias formas de garantizar que una sección del DOM no quede expuesta a las APIs de accesibilidad.

En primer lugar, lo que sea que quede explícitamente oculto del DOM tampoco se incluirá en el árbol de accesibilidad. Por lo tanto, todo el contenido que tenga un estilo CSS de visibility: hidden o display: none, o que use el atributo hidden de HTML5, también se ocultará a los usuarios de tecnología de accesibilidad.

Sin embargo, un elemento que no está representado visualmente ni explícitamente oculto sigue estando incluido en el árbol de accesibilidad. Una técnica común es incluir "texto solo para lector de pantalla" en un elemento que se encuentre en una posición absoluta fuera de la pantalla.

.sr-only {
    position: absolute;
    left: -10000px;
    width: 1px;
    height: 1px;
    overflow: hidden;
}

Además, como hemos visto, se le puede brindar texto solo para lector de pantalla a través de un atributo aria-label, aria-labelledby o aria-describedby que haga referencia a un elemento que esté de otra manera oculto.

Consulta este artículo de WebAIM sobre Técnicas para ocultar texto para obtener más información sobre la creación de texto “solo para lectores de pantalla”.

Por último, ARIA proporciona un mecanismo para excluir el contenido de la tecnología de accesibilidad que no está oculto visualmente, con el atributo aria-hidden. La aplicación de este atributo a un elemento lo quita de forma efectiva y también quita a todos sus descendientes del árbol de accesibilidad. Las únicas excepciones son elementos a los que se refiere un atributo aria-labelledby o aria-describedby.

<div class="deck">
    <div class="slide" aria-hidden="true">
    Sales Targets
    </div>
    <div class="slide">
    Quarterly Sales
    </div>
    <div class="slide" aria-hidden="true">
    Action Items
    </div>
</div>

Por ejemplo, puedes usar aria-hidden si creas una IU modal que bloquee el acceso a la página principal. En este caso, un usuario vidente puede ver una especie de capa superior semitransparente que indique que la mayor parte de la página no se puede usar por el momento, pero un usuario lector de pantalla puede seguir explorando las otras partes de la página. En este caso, además de crear la captura de teclado explicada anteriormente, debes asegurarte de que las partes de la página que actualmente están fuera de alcance también sean aria-hidden.

Ahora que comprendes los conceptos básicos de ARIA, cómo funciona con la semántica del HTML nativo y cómo se puede usar para realizar cirugías bastante importantes en el árbol de accesibilidad y cambiar la semántica de un solo elemento, veamos cómo podemos usarlo para transmitir información urgente.

aria-live

aria-live les permite a los desarrolladores marcar una parte de la página como "en vivo" en el sentido de que las actualizaciones deben comunicarse a los usuarios de inmediato, independientemente de la posición de la página, en lugar de que se enteren solo si exploran esa parte de la página. Cuando un elemento tiene un atributo aria-live, la parte de la página que lo contiene y sus descendientes se denomina región live.

ARIA live establece una región live.

Por ejemplo, una región activa puede ser un mensaje de estado que aparece como resultado de una acción del usuario. Si el mensaje es lo suficientemente importante como para captar la atención de un usuario vidente, lo es para dirigir la atención de un usuario de tecnología de accesibilidad mediante la configuración de su atributo aria-live. Compara este div sin formato

<div class="status">Your message has been sent.</div>

con su contraparte "en vivo".

<div class="status" aria-live="polite">Your message has been sent.</div>

aria-live tiene tres valores permitidos: polite, assertive y off.

  • aria-live="polite" le indica a la tecnología de accesibilidad que alerte al usuario sobre este cambio cuando termina lo que está haciendo actualmente. Es muy bueno usarlo si hay algo importante, pero no urgente, y sirve para casi todos los usos de aria-live.
  • aria-live="assertive" le dice a la tecnología asistencial que interrumpa lo que esté haciendo y alerte al usuario sobre este cambio de inmediato. Esto es solo para actualizaciones importantes y urgentes, como un mensaje de estado como "Se produjo un error del servidor y tus cambios no se guardaron; actualiza la página", o actualizaciones de un campo de entrada como resultado directo de la acción de un usuario, como botones en un widget escalonado.
  • aria-live="off" le indica a la tecnología de accesibilidad que suspenda temporalmente las interrupciones de aria-live.

Existen algunos trucos para garantizar que tus regiones live funcionen correctamente.

En primer lugar, tu región aria-live debería estar configurada en la carga de página inicial. Esta no es una regla rígida, pero si tienes dificultades con una región aria-live, este podría ser el problema.

En segundo lugar, distintos lectores de pantalla reaccionan de distintas formas a distintos tipos de cambios. Por ejemplo, se puede activar una alerta en algunos lectores de pantalla si se cambia el estilo hidden de un elemento descendiente de verdadero a falso.

Otros atributos que funcionan con aria-live te ayudan a afinar lo que se le comunica al usuario cuando cambia la región en vivo.

aria-atomic indica si toda la región se debería considerar una totalidad cuando se comunican actualizaciones. Por ejemplo, si un widget de fecha que consiste en un día, mes y año tiene aria-live=true y aria-atomic=true, y el usuario usa un control escalonado para cambiar el valor solo del mes, todo el contenido del widget de fecha se volverá a leer. El valor de aria-atomic puede ser true o false (el valor predeterminado).

aria-relevant indica qué tipos de cambios se le deben presentar al usuario. Existen algunas opciones que se pueden usar por separado o como una lista de tokens.

  • additions, lo que significa que cualquier elemento que se le agrega a la región live es importante. Por ejemplo, agregar un intervalo a un registro de mensajes de estado existente significa que el intervalo se anunciaría al usuario (suponiendo que aria-atomic fuera false).
  • text, lo que significa que el contenido de texto que se agrega a cualquier nodo descendiente es relevante. Por ejemplo, la modificación de la propiedad textContent de un campo de texto personalizado le leería el texto modificado al usuario.
  • removals, lo que significa que la eliminación de texto o nodos descendientes se debería transmitir al usuario.
  • all, lo que significa que todos los cambios son relevantes. Sin embargo, el valor predeterminado de aria-relevant es additions text, lo que significa que, si no especificas aria-relevant, se actualizará el usuario de cualquier adición al elemento, que es lo que probablemente quieras.

Por último, aria-busy te permite notificar a la tecnología de accesibilidad que debe ignorar temporalmente los cambios en un elemento, como cuando se están cargando los elementos. Una vez que todo esté en su lugar, aria-busy debe establecerse como false para normalizar la operación del lector.