Tutorial: cómo hacer formularios accesibles

En webaim.org (un clásico dentro de la accesibilidad web) podemos encontrar el tutorial Creating Accessible Forms podemos encontrar un buen tutorial para crear formularios accesibles. Incluye las recomendaciones clásicas (asociar label/code>), y otras más recientes como las técnicas de wai-aria.

En How to Build HTML Forms Right: Accessibility también podemos encontrar algunas sugerencias, quizás más avanzadas.

Sitios web estáticos para situaciones críticas

If you are in charge of a web site that provides even slightly important information, or important services, it’s time to get static.

Get Satic — Eric Meyer

Ya hace un mes desde que Eric Meyer escribiera el artículo, y algunos días más desde que en España estamos confinados. Muchos otros países, antes o después han tomado medidas similares. Qué se puede contar que no sepamos todos.

En cualquier caso, la reflexión que hace Eric es para tenerla en cuenta, como el extremo pragmático ante la hipertrofia web que estamos viviendo. En situaciones de emergencia, uno se pregunta si realmente es necesario tanto javascript, estilos, imágenes, fuentes,… y un gestor de contenidos con las características de un barco petrolero, cuando lo que nos hace falta es un barco de papel.

Casualidades de la vida, poco después de la pandemia y el artículo, en el cliente en el que presto mis servicios tuvimos que hacer una página estática: nada de scripts, estilos en la cabecera (al menos una llamada menos al servidor) y una única imagen, el logo institucional. Se tardó en decidir los textos, las subidas a producción no son tan ágiles siempre como uno quisiera… pero personalmente voy a recordar este pequeño trabajo de forma especial, porque aparte de miniminzar el código, no se podía optimizar más. Y la página funcionaba en cualquier cacharro que se conectara a internet y ofrecía la información de forma clara a potenciales usuarios en cualquier parte del mundo en circunstancias que a priori no eran nada favorables. Y no es poco.

font icons accesibles

Tardé en conocer los font-icons, y más en utilizarlos. Ahora, en una especie de framework que utilizo para trabajar, también he incluido font-icons: una vieja versión de Font Awesome que sigue siendo útil.

¿Qué es un font-icon? Es una forma de mostrar imágenes usando ficheros de fuentes, lo que ocurre es que en lugar de tener por ejemplo la letra «a» tiene el icono «lupa».

¿Qué ventajas tiene?

  • Poder cambiar el tamaño y color mediante CSS
  • Tener un conjunto homogéneo de iconos
  • Uso relativamente sencillo

¿Qué desventajas tiene? Aquí van algunas:

  • En ocasiones es necesario configurar el servidor para que sirva los ficheros de fuentes de la forma adecuada (mimetype)
  • No siempre hay un equilibrio entre los iconos disponibles y los que realmente se utilizan (y eso penaliza los tiempos de carga)
  • Para que sea compatible con un amplio espectro de navegadores, suelen ser necesarios varios ficheros con diferentes formatos de fuentes (y también penaliza los tiempos de carga).
  • No siempre se tienen en cuenta un aspecto clave, la accesibilidad.

¿Cómo hace un font-icon accesible?

Hay dos posibles casos de uso: iconos decorativos, e iconos importantes.
Y tenemos dos tipos de técnicas para hacerlos accesibles: usando HTML y usando WAI-ARIA.

Veamos, usando como ejemplo la versión actual de Font Awesome (5.10.2).

Una vez tenemos disponible las fuentes de iconos, mediante un código similar a:
<i class="fas fa-star"></i>

En el caso de que sea una imagen decorativa, usando el clásico HTML no haría falta nada más, pero con WAI-ARIA podemos añadir la propiedad aria-hidden para que lo oculte.
<i class="fas fa-star" aria-hidden></i>

En el caso de que se utilice un icono de fuente como si fuera una imagen y como tal necesite una alternativa textual, usando el viejo HTML nos bastaría con añadir un título descriptivo title.
Pero si aprovechamos las cracterísticas de WAI-ARIA podríamos usar role="img" para indicar que es una imagen, y aria-label para añadir esa alternativa textual necesaria.

El resultado final sería:

<i class="fas fa-star" role="img" aria-label="Favorito" title="Favorito"></i>

Optimizar los font-icons y usar sólo los iconos que necesito

Una recomendación final: como en cualquier utilidad, toca valorar si lo que nos ofrece es lo que necesitamos y cuánto nos cuesta para ver si merece o no la pena.

En el caso de los font-icons, tenemos por ejemplo, la posibilidad de usar centenares de iconos. ¿Necesitamos tantos?¿Qué coste tiene en velocidad de carga?

Si no necesitamos 400 iconos, solamente queremos 4, ¿para qué queremos tanto? Al final vamos a conseguir que la página se cargue más tarde y nos penaliza demasiado.

Para esos casos, nada como usar fontello que nos permite seleccionar para nuestro proyecto sólo los iconos que vamos a utilizar realmente. Y aunque no nos ofrezca la versatilidad de otras alternativas, puede ser justo lo que necesitamos.

WCAG 2.2: publicado el primer borrador de trabajo

The Accessibility Guidelines Working Group (AG WG) has published a First Public Working Draft of Web Content Accessibility Guidelines (WCAG) 2.2. WCAG provides recommendations for making web content more accessible to people with disabilities. It addresses accessibility of web content on desktops, laptops, tablets, and mobile devices. Following these guidelines also makes your web content more usable to all users in a variety of situations.

FIRST PUBLIC WORKING DRAFT: WCAG 2.2

¿Qué ha ocurrido? La Iniciativa de Accesibilidad Web, del W3C ya está trabajando en una nueva versión de las Pautas de Accesibilidad Web, la 2.2. Puedes encontrar el actual borrador de trabajo en Web Content Accessibility Guidelines (WCAG) 2.2. First draft y la actualización más reciente de la versión en Web Content Accessibility Guidelines (WCAG) 2.2. Last version.

WCAG 2.2 was initiated with the goal to continue the work of WCAG 2.1: Improving accessibility guidance for three major groups: users with cognitive or learning disabilities, users with low vision, and users with disabilities on mobile devices. Many ways to meet these needs were proposed and evaluated, and a set of these were refined by the Working Group. Structural requirements inherited from WCAG 2.0, clarity and impact of proposals, and timeline led to the final set of success criteria included in this version. The Working Group considers that WCAG 2.2 incrementally advances web content accessibility guidance for all these areas, but underscores that not all user needs are met by these guidelines.

WCAG 2.2: Comparison with WCAG2.1

Novedades de las WCAG 2.2

¿Qué nuevas características trae las WCAG 2.2? Un nuevo Success Criteria o criterio de conformidad:

Success Criterion 2.4.11 Focus Visible (Enhanced)

When a User Interface Component displays a visible keyboard focus, all of the following are true:

  • Minimum area: The focus indication area is greater than or equal to the longest side of the bounding rectangle of the focused control, times 2 CSS pixels.
  • Focus contrast: Color changes used to indicate focus have at least a 3:1 contrast ratio with the colors changed from the unfocused control.
  • Contrast or thickness: The focus indication area has a 3:1 contrast ratio against all adjacent colors for the minimum area or greater, or has a thickness of at least 2 CSS pixels.
Note

A focus indicator that is larger than the minimum area may have parts that do not meet the 3:1 contrast ratio, as long as an area equal to the minimum does meet the contrast ratio.

WCAG 2.2: Success Criterion 2.4.11 Focus Visible (Enhanced)