Redactar componentes accesibles

Objetivos de aprendizaje

Después de completar esta unidad, podrá:

• Identificar los conjuntos de componentes incluidos en el Marco de trabajo de componentes Lightning.
• Enumerar los pasos de creación de componentes accesibles.
• Enumerar los pasos de creación de componentes web personalizados.

Introducción

El Marco de trabajo de componentes Lightning proporciona un conjunto de componentes completamente funcionales para que los utilice. Están todos basados en los planos de componentes SLDS recientes, que siguen las directrices de accesibilidad relevantes. Siempre que sea posible, utilice estos componentes existentes. Se analizaron para la accesibilidad y le ahorrarán realizar una tonelada de trabajo adicional. Puede obtener información acerca de estos componentes en la Referencia de componente. 

Utilizar componentes

La Referencia de componente incluye información acerca de dos conjuntos diferentes de componentes, componentes Aura y componentes web Lightning. Los componentes Aura enumerados se dividen en varios espacios de nombres diferentes. Los componentes en los espacios de nombres ui y force se desarrollaron para cumplir con una especificación de ARIA antigua, y ya no son los componentes más accesibles. 

Los componentes web Lightning (LWC) son la mejor manera de crear interfaces de usuario con Salesforce. Diríjase al módulo Migrar desde Aura a Componentes web Lightning para aprender a usar LWC y cumplir con los estándares web actuales. Si necesita más información sobre Aura, visite la Guía del desarrollador de componentes Lightning Aura o la documentación de componentes Aura. 

Los componentes web Lightning con el prefijo lightning-, están redactados según el último estándar ARIA y siguen lo más reciente en planos de componentes SLDS. Siempre que sea posible, use estos componentes en lugar de alternativas más antiguas. 

Cuando está utilizando componentes Lightning, aún tiene que tener en cuenta la accesibilidad. Por ejemplo, cuando está colocando un icono informativo utilizando <lightning-icon>, aún debe especificar un valor alternative-text apropiado de modo que los usuarios conozcan el fin del icono. Cuando utiliza <lightning-input>, aún debe especificar una label para asociar de forma programática la <input> resultante con su <label>. Establecer required="true" convierte la entrada en obligatoria de una forma accesible.

Varios componentes Lightning también tienen atributos para establecer propiedades de ARIA. Aunque esto podría no ser obligatorio para la accesibilidad, los incluimos en caso de que tenga que establecer estos valores. 

Crear componentes

Si no puede encontrar el componente que necesita en nuestra referencia de componente, es posible que tenga que crear su propio componente Lightning. Si lo hace, siga estos pasos para asegurarse de que es accesible.

1. Siempre comience desde huellas de componente SLDS. Explore el marcado y las funciones, los estados y las propiedades de ARIA cuidadosamente. Tome nota de cualquier atributos obligatorio y atributos que cambian cuando un usuario interactúa con su componente.
2. Implemente interacciones de teclado. Recuerde que las funciones de ARIA son una promesa a sus usuarios. Esta promesa incluye proporcionar al teclado la función que los usuarios están esperando dado la función que especificó. Nuestros planos de componentes incluyen instrucciones de navegación de teclado.

Sugerencia: No escuche eventos de tecla Tabulación. Escuche el enfoque en su lugar. Los usuarios de lectores de pantalla raramente utilizan la tecla Tabulación para navegar en una página.

• Gestionar enfoque de usuario. Siga nuestras Directrices de enfoque global para asegurarse de que los elementos interactivos son enfocables.
• Redacte la automatización y pruebe sus componentes manualmente. 
  1. Redacte pruebas de integración para probar interacciones del teclado. La única forma fiable de probar interacciones del teclado es utilizar un navegar real. No se fíe de una inspección de DOM manual para captar regresiones. Redacte pruebas para garantizar la precisión del marcado, incluyendo:
     • Semánticas correctas en el nodo correcto.
     • Atributos correctos establecidos en el nodo correcto.
     • Valores de atributo correctos actualizados durante el ciclo de vida del componente.
  2. Complete manualmente las pruebas de función de extremo a extremo utilizando solo su teclado, siguiendo las especificaciones de SLDS. Asegúrese de que todo pueda hacerse con un teclado.

Componentes web

Los componentes web son una función del navegador que proporciona un modelo de componente estándar para la web, que consta de varias partes mantenidas en diferentes lugares: DOM paralelo, elementos personalizados, plantillas HTML y cambios CSS (origen). En términos prácticos, los componentes web tienen un elemento personalizado como una raíz. Estos elementos personalizados no tiene ningún valor semántico, pero pueden causar problemas de descendencia para tecnologías de asistencia. 

Problemas de descendencia directa

Si crea una lista no ordenada, <ul>, con elementos de lista de componentes web, <lightning-example-list-item>, su marcado tiene el aspecto siguiente:

<ul>
  <lightning-example-list-item>
    <li>content</li>
  </lightning-example-list-item>
  <lightning-example-list-item>
    <li>content</li>
  </lightning-example-list-item>
  <lightning-example-list-item>
    <li>content</li>
  </lightning-example-list-item>
</ul>

Esta, sin embargo,no es accesible, porque cada secundario de <ul> debe ser un elemento <li>. Los lectores de pantalla no pueden reconocer que ésta es una lista de tres elementos. Aquí, es mejor recurrir a funciones de ARIA en vez de elementos semánticos.

En vez de una <ul> podemos utilizar otro componente web con role="list". Nuestros componentes web de elemento de lista entonces necesitarían role="listitem", y no utilizaremos elementos <li>. Utilizado el código mostrado a continuación, los lectores de pantalla pueden identificar esto de forma apropiada como una lista de tres elementos.

<lightning-example-list>
<div role="list">
  <lightning-example-list-item>
    <div role="listitem">content</div>
  </lightning-example-list-item>
  <lightning-example-list-item”>
    <div role="listitem">content</div>
  </lightning-example-list-item>
  <lightning-example-list-item>
    <div role="listitem">content</div>
  </lightning-example-list-item>
</div>
</lightning-example-list>

Atributos HTML globales

No utilice atributos HTML globales para establecer atributos en los elementos internos. Cuando establece un atributo HTML global en el host con Componentes web Lightning, nuestro marco de trabajo supone que desea que esté en el host, incluso si lo transmite también. Por ejemplo, si utiliza el atributo aria-describedby en un componente web de entrada como una API para establecer el atributo en el secundario, lo establecerá dos veces de forma inadvertida.

<lightning-example-input aria-describedby="foo">

Se representa como:

<lightning-example-input aria-describedby="foo">
  <input aria-describedby="foo" />
</lightning-example-input>

En su lugar, haga que el nombre de API de su componente web distinga entre mayúsculas y minúsculas, como en el siguiente ejemplo:

<lightning-example-input ariaDescribedby="foo">

Esto se representa de forma apropiada:

<lightning-example-input>
  <input aria-describedby="foo" />
</lightning-example-input>

Para obtener más información acerca de los nombres de propiedades y atributos, incluido el uso de la distinción entre mayúsculas y minúsculas, consulte la sección Recursos.

DOM paralelo

Los componentes web con DOM paralelo activado presentan problemas de accesibilidad adicionales. Varios aspectos de la accesibilidad web se basan en referencias de Id. de componente vinculando diferentes elementos en la página. Un ejemplo sencillo de esto implica el etiquetado de entradas de formulario.

<label for="foo">First Name</label>
<input type="text" id="foo" />

En el ejemplo de código mostrado anteriormente, el Id. "foo" asocia la etiqueta “Nombre” con la entrada de texto. Si la etiqueta y la entrada fueran colocadas en componentes web separados debido al DOM paralelo, esta relación ya no existiría en el árbol de accesibilidad del navegador.

<lightning-example-label>
     <label for="foo">First Name</label>
</lightning-example-label>
<lightning-example-input>
     <input type="text" id="foo" />
</lightning-example-input>

En este escenario, la etiqueta y la entrada ya no están asociadas y el formulario ya no es accesible. La solución aquí es no separar elementos en diferentes elementos personalizados cuando se requiere una relación de referencia de Id.

<lightning-example-input>
     <label for="foo">First Name</label>
     <input type="text" id="foo">
</lightning-example-input>

Cuando crea sus propios componentes web personalizados, estudie las especificaciones de diseño de ARIA y planos de SLDS. Identifique propiedades de HTML y ARIA que se basan en referencias de Id., y nunca separe esos elementos en raíces paralelas separadas.

Un grupo en W3C está desarrollando el Modelo de objeto de accesibilidad, un enfoque que ofrece formas de asignar funciones y propiedades, actualizar estados y crear relaciones sin basarse en atributos HTML y referencias de Id. Aunque este modelo aún está en estado borrador, ofrecerá mayor control sobre la accesibilidad de componentes web una vez adoptado por navegadores, tecnologías de asistencia y la comunidad de desarrollo.

¡Misión cumplida!

Ahora conoce los fundamentos de la creación de interfaces de usuario accesibles. Cuando esté listo para iniciar el diseño y la prueba para la accesibilidad, eche un vistazo más de cerca en Trailhead para más recursos. Únase también a nuestra amplia comunidad de administradores y desarrolladores a través de la Salesforce Trailblazer Community para compartir ideas, unirse a grupos, leer historias de éxito y mucho más. 

Recursos

• Documentación: Borradores y estándares de W3C
• Referencia de desarrolladores de Salesforce: Componentes web Lightning
• Referencia de desarrolladores de Salesforce: Nombres de propiedades y atributos
• Documentación: Modelo de objetos de accesibilidad
• Ayuda de Salesforce: Planos de componente
• Documentación: Especificaciones de componentes web W3C