3.3: La evolución de la accesibilidad web
- Page ID
- 154706
\( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)
\( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)
\( \newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\)
( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\)
\( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)
\( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\)
\( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)
\( \newcommand{\Span}{\mathrm{span}}\)
\( \newcommand{\id}{\mathrm{id}}\)
\( \newcommand{\Span}{\mathrm{span}}\)
\( \newcommand{\kernel}{\mathrm{null}\,}\)
\( \newcommand{\range}{\mathrm{range}\,}\)
\( \newcommand{\RealPart}{\mathrm{Re}}\)
\( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)
\( \newcommand{\Argument}{\mathrm{Arg}}\)
\( \newcommand{\norm}[1]{\| #1 \|}\)
\( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)
\( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\AA}{\unicode[.8,0]{x212B}}\)
\( \newcommand{\vectorA}[1]{\vec{#1}} % arrow\)
\( \newcommand{\vectorAt}[1]{\vec{\text{#1}}} % arrow\)
\( \newcommand{\vectorB}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)
\( \newcommand{\vectorC}[1]{\textbf{#1}} \)
\( \newcommand{\vectorD}[1]{\overrightarrow{#1}} \)
\( \newcommand{\vectorDt}[1]{\overrightarrow{\text{#1}}} \)
\( \newcommand{\vectE}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash{\mathbf {#1}}}} \)
\( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)
\( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)
Si estás interesado en conocer la historia detrás de WCAG, echa un vistazo a la línea de tiempo de los hitos que se describen a continuación.
1995: Comienza la Accesibilidad Web
Fue a mediados de la década de 1990 cuando la conciencia de accesibilidad web comenzó a afianzarse, mencionada por primera vez por Tim Berners-Lee en su discurso principal en la Segunda Conferencia Internacional World Wide Web de 1994 en Chicago. Los Lineamientos Unificados de Accesibilidad al Sitio Web fueron compilados poco después en el Centro TRACE de la Universidad de Wisconsin-Madison en 1995. La versión 8 de los Lineamientos Unificados de Accesibilidad al Sitio Web se convirtió en el documento semilla para WCAG 1.0.
1999: Lanzamiento de WCAG 1.0
No fue hasta 1999 que la primera versión de los Lineamientos de Accesibilidad al Contenido Web (WCAG 1.0) fue lanzada por la Iniciativa de Accesibilidad Web (WAI) del W3C. Este fue un avance significativo en la promoción de una web accesible. Con WCAG 1.0 fue posible evaluar la accesibilidad en base a un estándar, sin necesidad de utilizar aplicaciones como JAWS. Ese estándar también fue utilizado por los desarrolladores de tecnología de asistencia (AT) (de lectores de pantalla, por ejemplo) para comprender mejor cómo AT debe interactuar con el contenido en la Web. Entonces se podría juzgar la accesibilidad en función de lo que la especificación WCAG sugirió que se debería hacer. Pero, hubo problemas con WCAG 1.0 que frenaron su adopción. Estos problemas se abordarían con el lanzamiento de WCAG 2.0.
2008: Lanzamiento de WCAG 2.0
En 2008 se lanzó WCAG 2.0 para abordar las deficiencias de su predecesor. Uno de los cambios significativos incluyó la independencia tecnológica. Esto significaba que lo que anteriormente podría haber estado asociado con una barrera en el contenido HTML ahora era una barrera independientemente de la tecnología utilizada.
Por ejemplo, “incluir texto alt con imágenes”, siendo “alt” un atributo HTML, se convirtió en “incluir alternativas de texto para contenido visual”, sin referencia a la tecnología que presenta el contenido. WCAG 2.0 abordó la accesibilidad en toda una gama de tecnologías web, incluyendo cosas como Flash, Java, JavaScript y otras tecnologías similares.
Un segundo cambio importante fue la aceptación de JavaScript en WCAG 2.0 como una tecnología web legítima. Con WCAG 1.0, los desarrolladores tuvieron que crear alternativas a los elementos JavaScript que pudieran haber agregado para crear interactividad en su contenido web. En otras palabras, un sitio web necesitaba operar con la misma funcionalidad si JavaScript estaba desactivado en el navegador de un usuario. Esto limitó severamente lo que los desarrolladores podían hacer al cumplir con WCAG 1.0 y se convirtió en otro factor que contribuyó a la lenta captación de WCAG 1.0.
Con la liberación de WCAG 2.0 se levantó esta restricción. Ya no es un requisito crear alternativas a las funciones con guión, aunque sigue siendo un requisito para que esas funciones sean accesibles, ciertamente factibles para la mayoría de la interactividad JavaScript que vemos en los sitios web actuales.
2015: HTML5 y WAI ARIA
Hoy tenemos una serie de nuevas incorporaciones a la colección de estándares de accesibilidad con la introducción de especificaciones como WAI-ARIA (Accessible Rich Internet Applications). WAI-ARIA es una extensión de HTML5, que permite a los desarrolladores agregar información sobre roles, estados y propiedades a las características personalizadas que podrían crear usando JavaScript, que anteriormente habrían sido inaccesibles para los usuarios de AT.
Por ejemplo, un desarrollador podría querer usar una colección de <div>elementos para crear un formulario. Esto es ciertamente posible con algún guión agregado, pero <div>a nunca se pretendió que se usara como elemento de formulario o para ser interactivo para el caso. No tienen rol ni estados o propiedades que indicarían a un usuario AT que estaban en una forma, a diferencia de un <form>elemento en HTML, que tiene todas esas características semánticas incorporadas por defecto.
ARIA ahora permite a los desarrolladores asignar un role="form” <div>a un para identificarlo como un formulario. Un <div>usado para crear una casilla de verificación ahora podría tener un role="checkbox” agregado, y aria-checked="true” configurado para que su rol y estado (marcados o no marcados) se anuncien a AT de la misma manera que se anuncian los elementos del formulario HTML estándar. Hablaremos un poco más sobre WAI-ARIA en la unidad 8, pero por ahora sepan que es quizás la tecnología de accesibilidad más significativa que ha surgido en los últimos años.
2018: WCAG 2.1 y Proyecto Plata
Cuando se introdujo WCAG 2.0 en 2008, el iPhone acababa de ser lanzado el año anterior, y no sería hasta 2009 que sería utilizable por personas ciegas. WCAG 2.0 proporcionó poca orientación sobre el desarrollo de contenido accesible para ser accedido a través de dispositivos móviles.
WCAG 2.1 tiene como objetivo llenar ese vacío, produciendo pautas para ayudar a los desarrolladores a cumplir con las pautas de accesibilidad al desarrollar web móvil y diseños responsivos para contenido web, entre otras cosas. WCAG 2.1 fue lanzado en junio de 2018, agregando una nueva pauta y 17 nuevos criterios de éxito.
Artículo reciente de Scott Hollier, sobre cambios en WCAG 2.1: WCAG 2.1: Reflexiones sobre los nuevos lineamientos y criterios de éxito.
En paralelo con WCAG 2.1, también se ha lanzado el proyecto Silver. Plata es el nombre en clave para WCAG 3.0. El enfoque de Silver está en integrar los estándares de accesibilidad en el Internet de las Cosas (IoT) emergente. Con todo, desde refrigeradores, hasta sistemas de control de clima doméstico, hasta monitoreo de seguridad que ahora se conecta a Internet, Silver se está desarrollando para garantizar que estas tecnologías emergentes sean accesibles para todos.
¿Por qué Silver? El símbolo del elemento Silver es Ag, que representa los Lineamientos de Accesibilidad.