--- title: Accessibility Basics localeTitle: Conceptos básicos de accesibilidad --- > "Las Artes Oscuras son muchas, variadas, siempre cambiantes y eternas. Luchar contra ellas es como luchar contra un monstruo con muchas cabezas, que, cada vez que se corta un cuello, brota una cabeza aún más feroz e inteligente que antes. Estás luchando contra algo que es fijo, mutante, indestructible ". > > \--Profesor Severus Snape, Serie de libros de Harry Potter El rol de la accesibilidad en el desarrollo es esencialmente entender la perspectiva y las necesidades del usuario, y saber que la web y las aplicaciones son una solución para las personas con discapacidades. En esta época, se inventan cada vez más tecnologías para facilitar la vida de los desarrolladores, así como de los usuarios. Hasta qué punto esto es bueno, es un debate para otro momento, por ahora basta con decir que la caja de herramientas de un desarrollador, especialmente un desarrollador web, es tan cambiante como las llamadas "artes oscuras" de las que habla nuestro amigo Snape. Una de las herramientas de esa caja debe ser la accesibilidad. Es una herramienta que, idealmente, debería usarse en uno de los primeros pasos para escribir cualquier forma de contenido web. Sin embargo, esta herramienta a menudo no está tan bien presentada en la caja de herramientas de la mayoría de los desarrolladores. Esto podría deberse a un simple caso de no saber que existe incluso en casos extremos, como no preocuparse por ello. En mi vida como usuario, y más tarde como desarrollador, que se beneficia de la accesibilidad en cualquier forma de contenido, he visto ambos extremos de ese espectro. Si estás leyendo este artículo, supongo que estás en una de las siguientes categorías: * Eres un desarrollador web novato y te gustaría saber más sobre accesibilidad. * Eres es un desarrollador web experimentado y has perdido tu camino (más sobre esto más adelante) * Sientes que tienes una obligación legal del trabajo y necesitas aprender más sobre ello. Si caes fuera de estas categorías bastante amplias, por favor házmelo saber. Siempre me gusta escuchar de las personas que leen sobre lo que escribo. Implementar la accesibilidad afecta a todo el equipo, desde los colores elegidos por el diseñador, la copia escrita por el redactor publicitario, y hasta tú, el desarrollador. ## Entonces, ¿qué es la accesibilidad de todos modos? La accesibilidad en sí misma es un término un tanto engañoso a veces, especialmente si el inglés es tu segundo idioma. A veces se le conoce como diseño inclusivo. Si tu sitio está en Internet, accesible a cualquier persona con un navegador web, en un sentido, ese sitio web es accesible para todos con un navegador web. Pero, ¿es todo el contenido de tu sitio web realmente legible, utilizable y comprensible para todos? ¿No hay umbrales que impidan a ciertas personas 'acceder' a toda la información que estás exponiendo? Podrías hacerte preguntas como las siguientes: * Si agregas información que solo está contenida en un archivo de audio, ¿puede una persona sorda obtener esa información? * Si resaltas una parte importante de su sitio web con un color determinado, ¿lo sabrá una persona que no puede distinguir los colores? * Si agregas imágenes a tu sitio web que transmiten información importante, ¿cómo lo sabrá una persona ciega o con poca visión? * Si deseas navegar por la aplicación con el teclado o la boquilla, ¿será posible y predecible? * ¿Tu aplicación asume la orientación del dispositivo y qué sucede si el usuario no puede cambiarlo físicamente? * ¿Hay aspectos de excepción en tu solicitud para alguien que podría necesitar más tiempo para completar un formulario? * ¿Tu aplicación aún funciona (mejora progresiva) suponiendo que JavaScript no se cargue a tiempo? * Incluso puedes ir tan lejos como para decir que si tu sitio web tiene muchos recursos, ¿podrá alguien con una conexión lenta o irregular leer el contenido? Aquí es donde la accesibilidad entra en juego. La accesibilidad básicamente implica hacer que tu contenido sea tan amigable, tan fácil de 'acceder' como sea posible para la mayor cantidad de personas. Esto incluye a las personas sordas, con poca visión, ciegas, disléxicas, silenciadas, con una conexión lenta, daltónicas, con epilepsia, fatiga mental, edad, limitaciones físicas, etc. ## ¿Por qué implementar la accesibilidad? Puedes pensar que la accesibilidad no aplica a ti ni a tus usuarios, ¿por qué implementarla? ¿Qué haría una persona ciega con una herramienta de edición de fotos? La verdad es que tienes razón, hasta cierto punto. Si has investigado meticulosamente a tus usuarios y has excluido cualquier posibilidad de que cierto grupo de personas visite tu sitio web, la prioridad para atender a ese grupo de personas disminuye bastante. Sin embargo, hacer esta investigación es clave para defender realmente dicha declaración. ¿Sabías que había [jugadores ciegos?](http://audiogames.net) e incluso [fotógrafos ciegos?](http://peteeckert.com/) . ¿Quizás sabías que los [músicos pueden ser sordos](http://mentalfloss.com/article/25750/roll-over-beethoven-6-modern-deaf-musicians) ? Si lo hiciste, bien por ti. Si no, supongo que esto refuerza mi punto de partida. La situación se complica aún más cuando observamos la legislación que obliga a hacer que ciertos sitios web y aplicaciones web sean accesibles. Un buen ejemplo es la [sección 508](http://jimthatcher.com/webcourse1.htm) con sede en los Estados Unidos. En este momento, esta ley se refiere principalmente a organizaciones gubernamentales, sitios web del sector público, etc. Sin embargo, las leyes cambian. El año pasado, los sitios web de las aerolíneas se incluyeron en esta lista, lo que significa que incluso en Europa, los desarrolladores de sitios web de las aerolíneas se apresuraron a hacer que su contenido fuera accesible. No hacerlo puede causarle a tu compañía una multa de literalmente decenas de miles de dólares por cada día que el problema no se resuelva. Hay variaciones en esta legislación en todo el mundo, algunas más severas y abarcadoras que otras. El no saber sobre este hecho no hace que la demanda desaparezca, tristemente. ## Ok, entonces la accesibilidad es un gran problema. Ahora, ¿cómo lo implementamos? Esa pregunta, lamentablemente, es más difícil de responder de lo que parece. La cita de Harry Potter en la parte superior está ahí por una razón, y ésa no es que yo sea un ávido lector de libros de fantasía. Como dije anteriormente, la accesibilidad es importante para un grupo grande de personas diferentes, cada una con sus propias necesidades. Hacer que su sitio web funcione para todos, literalmente, es una tarea grande y continua. Para aportar un poco de método a la locura, se redactaron las Pautas de Accesibilidad al Contenido Web o [WCAG](https://www.wuhcag.com/web-content-accessibility-guidelines/) . Este documento contiene una serie de criterios que puedes utilizar para verificar tu sitio web. Por ahora, cubriré algunos de los conceptos básicos más importantes aquí. Te señalaré las frutas bajas, por así decirlo. En artículos posteriores, discutiré técnicas más avanzadas como \[WAI-ARIA\], que es importante para aplicaciones basadas en JavaScript. ### Hablar como los nativos La especificación HTML es un documento que describe cómo se debe usar el lenguaje para crear sitios web. Las tecnologías de asistencia, como los lectores de pantalla, los programas de reconocimiento de voz, etc. conocen este documento. Sin embargo, los desarrolladores web a menudo no lo conocen, o al menos no lo suficiente, y piensan que algo como esto está bien: ```html
Enorme cabecera a la cual pondre css más tarde Ingles ``` ¿Adivina qué? Estos tres elementos rompen varios criterios de WCAG y, por lo tanto, no son accesibles en absoluto. El primer elemento rompe el llamado 'nombre, rol, valor-criterio', que establece que todos los elementos en una página web deben exponer su nombre, su rol (botón similar) y su valor (como el contenido de un campo de edición) a las tecnologías asistivas. Este div realmente no proporciona ninguno de los tres, haciéndolo invisible para los lectores de pantalla. El segundo elemento parece un encabezado visual después de estilizarlo con CSS, pero semánticamente es un lapso. Por lo tanto, las tecnologías de asistencia no sabrán que es un título. Un lector de pantalla leerá esto como texto regular, en lugar de un encabezado. Los lectores de pantalla a menudo tienen una tecla de acceso rápido para saltar rápidamente al encabezado más cercano, este encabezado no se incluirá en ese alcance. El tercer elemento podría ser, por ejemplo, un elemento en el que un usuario puede hacer clic para cambiar el idioma del sitio web. Tal vez un menú animado de idiomas se expandirá cuando se haga clic. Sin embargo, esto también es un lapso y no expone su función (enlace o botón), lo que hace que las tecnologías de asistencia piensen que esta es solo la palabra inglés con algo de estilo. Spans y divs no son elementos. Están destinados a contener otros elementos, no a ser elementos en sí mismos. Se puede arreglar esto de dos maneras: * Puedes agregar manualmente atributos ARIA a los elementos anteriores. Este es un tema avanzado y fuera del alcance de este artículo. * O, simplemente puedes hacer esto: ```html

Aquí hay una cabecera de nivel 2

Ingles ``` Éxito! De repente todos estos elementos ahora son perfectamente accesibles, solo mediante el uso de HTML nativo. HTML de la forma en que está hecho a ser utilizado, en otras palabras. ### La estructura no puede soportarse sin fundación. Existen teclas de acceso rápido de un lector de pantalla para saltar de un encabezado a otro. De hecho, hay muchas teclas de acceso rápido como ésta para saltar rápidamente a la tabla más cercana, campo de formulario, enlace, etc. Asegurarse de que estos encabezados estén realmente en lugares lógicos es una buena práctica y realmente disminuye los niveles de estrés de los usuarios de la tecnología de asistencia, lo cual es bueno que tenga en cuenta si quiere que estos visitantes sigan regresando a tu sitio web. También recuerda que los encabezados son jerárquicos. Si usas un h2, asegúrate de que los h3 que lo siguen tengan algo que ver con ese h2. No coloques un h3 para detalles de contacto debajo de un h2 para publicaciones de blog recientes. Una buena analogía aquí es un libro con capítulos y subsecciones. No pondría una sección sobre cómo hornear galletas en medio de un capítulo sobre la preparación de verduras ... o ... no lo haría ... ¿verdad? ### ¿Cuál es la alternativa? Las imágenes en un sitio web son excelentes. Añaden una nueva capa a tu contenido, realmente pueden hacer que la experiencia de los visitantes de tu sitio sea mucho más inmersiva y, en general, se vea bien entre todo ese texto. Una imagen puede decir más que mil palabras, ¿verdad? Ciertamente. Es decir, si puedes verla. En la especificación HTML5, un atributo img siempre debe tener un atributo alt. Este atributo está pensado como una alternativa a la imagen en caso de que no se pueda ver. Esto aplica tanto para los visitantes ciegos de tu sitio web como en el caso en que la imagen no se pueda cargar por algún motivo. Por lo tanto, no agregar una etiqueta alt a un atributo img no solo rompe la accesibilidad, sino que va en contra de la especificación HTML5. Imploro a cualquier desarrollador web que se sorprenda haciendo esto que se coma el sombrero de su programador y lo haga trabajar en Windows 95 exclusivamente durante una semana. Después de que se acabe el tiempo, deberás escribir un ensayo sobre lo que has aprendido de esta prueba para que pueda reírme durante mi café de la tarde. Ahora, hay una advertencia aquí. Los atributos Alt son obligatorios según la especificación HTML5, pero no es obligatorio rellenarlos. `` es un código HTML5 legal. ¿Debería por lo tanto llenar las etiquetas alt para todas las imágenes? Depende de la imagen, de verdad. Para las imágenes de fondo, la respuesta suele ser no, pero de todos modos deberías usar CSS. Para imágenes puramente decorativas que no tienen información en absoluto, básicamente tienes la libertad de elegir. O bien poner algo útil y descriptivo o nada en absoluto. Para las imágenes que contienen información, como un folleto, un mapa, un gráfico, etc., no agregue saltos de texto alternativos WCAG a menos que proporciones una alternativa textual. Este suele ser un atributo alternativo, pero también puede ser un bloque de texto justo debajo o al lado de la imagen. Para imágenes de texto, el texto se puede incluir en el atributo alt o se puede ofrecer de alguna manera alternativa. El problema es que agregar la alternativa textual en la misma página básicamente haría que el mismo contenido se muestre dos veces para las personas que pueden ver la imagen, por lo que el atributo alt es mejor en este caso. El texto debe proporcionar el contexto y la información que funciona como una alternativa para ver la imagen. Simplemente no es suficiente escribir "imagen de globos aerostáticos": ¿por qué hay imágenes de globos allí? Si la imagen está estilizada o transmite un significado emocional, esto puede incluirse. ### No puedo leer tu garabato, hijo Incluso las personas que no usan gafas y no tienen ningún problema con la vista se benefician de una fuente fácil de leer y un contraste adecuado. Estoy seguro de que te estremecerías si tuviera que rellenar un formulario en el que las letras de color amarillo claro se colocan sobre un fondo blanco. Para las personas cuya vista no es tan buena, como tu abuela, por ejemplo, esto se vuelve irremediablemente peor. La WCAG tiene relaciones de contraste para letras más pequeñas y más grandes y hay muchas herramientas para verificar si las relaciones de contraste son lo suficientemente fuertes. La información y las herramientas están ahí, ve y úsalas. Un buen lugar para comenzar a verificar el contraste de color es mediante el uso del [verificador de](https://webaim.org/resources/contrastchecker/) contraste de color [WebAIM](https://webaim.org/resources/contrastchecker/) . ### ¿Qué hace este botón? Mientras estamos en el tema de los formularios, echemos un vistazo rápido a la etiqueta de `input` . Esta pequeña es muy importante. Cuando colocas algunos campos de entrada en una página web, puedes usar etiquetas para ... bueno ... etiquetarlos. Sin embargo, ponerlos uno al lado del otro no es suficiente. El atributo que estás buscando es el atributo for, que toma el ID de un campo de entrada posterior. De esta manera, las tecnologías de asistencia saben qué etiqueta asociar con qué campo de formulario. Supongo que la mejor manera de ilustrar esto es dando un ejemplo: ```html