Botones Accesibles y Falsos Botones

en esta ocasión comparto con vosotras este artículo sobre Botones Accesibles y Falsos Botones, que si bien es sencillo en el plano técnico, resulta muy interesante a nivel conceptual.

Ya sabeis que la máxima en accesibilidad es que las cosas tienen que ser lo que aparentan, y aparentar lo que son. Llevando este concepto al caso concreto de la creación de botones, vamos a ver qué son los Botones Botones Accesibles y Falsos Botones, qué implicaciones tienen en accesibilidad y cómo solucionar las barreras que generan estos últimos.

Falsos Botones

Comenzaré explicando qué es un falso botón o fake button, que no es más que un componente web que tiene apariencia de botón y que ejecuta alguna acción, pero que semánticamente, no es un botón. Es decir, por medio de estilos y propiedades css habremos dotado a un elemento cualquiera con el aspecto de un botón, y por medio de lógica de programación estaremos haciendo que ejecute alguna acción.

Botón Accesible

Crear un botón accesible es muy sencillo, de hecho más sencillo que crear un falso botón puesto que para hacerlo no tendremos más que usar código nativo html y darle aspecto de botón por medio de nuestros estilos css.

Os propongo un juego

Usando solamente el sentido de la vista, ¿sabríais decir cuál de los siguientes botones es un falso botón y cuál un botón accesible? Compañeras y compañeros ciegos, nosotros partimos con ventaja en este juego así que será mejor estar callados para no dar pistas…

¿Qué podemos analizar para saber si tenemos un botón accesible o un falso botón?

Con una sola pregunta podemos saber con una alta probabilidad de acierto si lo que tenemos entre manos es un botón accesible o un falso botón:

¿Puedo hacer foco en el botón usando la tecla tabulador de mi teclado físico?

Si la respuesta es NO, la probabilidad de que estemos ante un falso botón es muy alta, pero no es del 100%.
Lo que sí tiene una probabilidad del 100% en este caso, es que el botón que estamos evaluando es inaccesible puesto que, guiándonos por la normativa española de accesibilidad TIC, el Nivel AA de las WCAG 2.1, con esta comprobación podemos afirmar que se incumplen dos criterios:

  • Criterio 2.1.1: Teclado.
  • Criterio 2.4.7: Foco visible.

Si por el contrario la respuesta es , lo único que puedo asegurar es que ese control apunta maneras para ser accesible, pero sigo sin poder afirmar que se trata de un botón accesible que no es un falso botón.

Confirmando que se trata de un botón accesible o de un falso botón

La prueba anterior está bien, y es la que hay que hacer para saber si el control que estamos evaluando es directamente inaccesible porque incumple los criterios 2.1.1 y 2.4.7, pero en realidad, la única manera de saber si lo que tenemos delante es un falso botón es analizando el código fuente o, como adelantaba, si disponemos de una tecnología de apoyo como un lector de pantalla, que es la tecnología que usamos las personas ciegas para manejar nuestros equipos.

el Criterio de las WCAG 2.1 que incumple un falso botón es el 4.1.2: Nombre, rol, valor puesto que si el control en cuestión no tiene rol o función semántica de botón, por mucho que su aspecto sea el de un botón, las tecnologías de apoyo como los lectores de pantalla no lo reconocerán como tal.

El lector de pantalla JAWS 2021 muestra un botón Aceptar.
El lector de pantalla JAWS 2021 muestra un enlace Aceptar.

en la primera imagen, vemos cómo el lector de pantalla JAWS 2021 reconoce un botón “Aceptar”; éste no es un falso botón y se corresponde con el segundo botón de la lista.

En la seguna imagen, JAWS reconoce un control “Aceptar”, pero con rol o función semántica de enlace, por lo que se trata de un falso botón; es el tercer botón de la lista.

El primer botón, las tecnologías de apoyo ni tan siquiera lo reconocen como un elemento interactivo o ejecutable, por lo que también se trata de un falso botón, y además inaccesible.

Convirtiendo un Falso botón en un Botón Accesible

En primer lugar, nos tenemos que asegurar de que el botón sea focalizable con el teclado y reconocido como un botón por las tecnologías de apoyo.

para que pueda focalizarse, si estamos usando un elemento que ya es focalizable de manera nativa como un enlace, no tenemos que hacer nada. Por el contrario, si estamos usando cualquier otra etiqueta html que no es interactiva, como un <span>, conseguiremos que se convierta en focalizable usando el atributo tabindex="0".

<span tabindex="0">Aceptar</span>

Finalmente, para conseguir que este componente sea lo que aparenta ser, tenemos que indicar a las tecnologías de apoyo que se trata de un botón. Esto lo haremos con el atributo de ARIA role="button".

<span tabindex="0" role="button">Aceptar</span>

Con el código anterior, hemos convertido un falso botón en un botón real, y habremos conseguido cumplir los siguientes criterios WCAG 2.1:

  • 2.1.1: Teclado.
  • 4.1.2: Nombre, rol, valor.

En el caso del último de los tres botones, el que está creado con una etiqueta de enlace, lo único que tendremos que hacer para convertirlo en un botón real es añadir el atributo role="button", ya que al ser un enlace, es focalizable de manera nativa.

<a href="…" role="button">Aceptar</a>

Nuestros tres botones ya accesibles

El código fuente de nuestros tres botones queda de la siguiente manera:

<span class="btn" tabindex="0" role="button">Aceptar</span>
<button class="btn">Aceptar</button>
<a href="Javascript:void(0)" class="btn btn-focus" role="button">Aceptar</a>
Y a continuación la imagen de como son detectados nuestros tres botones por un lector de pantalla.
Ahora el lector de pantalla JAWS 2021 reconoce los trres elementos como tres botones Aceptar.
h2>Botones Reales, pero también Accesibles

Todo lo anterior es lo que necesitamos para que unos falsos botones se conviertan en botones reales, pero necesitamos que sean accesibles, así que para que nuestros botones reales sean botones accesibles, tenemos que prestar atención a más criterios, en total, tendríamos:

  • 1.4.3: Contraste (mínimo).
  • 1.4.10: Reajuste de elementos.
  • 1.4.11: Contraste no textual.
  • 2.1.1: Teclado.
  • 2.4.6: Encabezados y etiquetas.
  • 2.4.7: Foco visible.
  • 4.1.2: Nombre, rol, valor.

Conclusión

Podemos ahcer que unos botones, que por exigencias de diseño o requisitos de nuestros clientes son botones falsos se conviertan en botones reales con, literalmente, un par de atributos; teniendo esto en cuenta junto con los criterios WCAG 2.1 que influyen en un elemento como un botón, podremos contar con botones visualmente atractivos y accesibles.

Deja un comentario