path: root/files/es/learn/accessibility/css_and_javascript/index.html

---
title: Buenas prácticas de accesibilidad CSS y JavaScript
slug: Learn/Accessibility/CSS_and_JavaScript
translation_of: Learn/Accessibility/CSS_and_JavaScript
---
<div>{{LearnSidebar}}</div>

<div>{{PreviousMenuNext("Learn/Accessibility/HTML","Learn/Accessibility/WAI-ARIA_basics", "Learn/Accessibility")}}</div>

<p class="summary">CSS y JavaScript, cuando se usan correctamente, también tienen el potencial de permitir experiencias web accesibles... o pueden dañar significativamente la accesibilidad si se usan incorrectamente. Este artículo describe algunas de las mejores prácticas de CSS y JavaScript que deben tenerse en cuenta para garantizar que incluso el contenido complejo sea lo más accesible posible.</p>

<table class="learn-box standard-table">
 <tbody>
  <tr>
   <th scope="row">Prerrequisitos:</th>
   <td>Conocimientos básicos de informática, conocimientos básicos de HTML, CSS y JavaScript, y comprensión de <a href="/es/docs/Learn/Accessibility/Qué_es_la_accesibilidad">qué es la accesibilidad</a>.</td>
  </tr>
  <tr>
   <th scope="row">Objetivo:</th>
   <td>
    <p>Familiarizarse con el uso apropiado de CSS y JavaScript en documentos web para maximizar la accesibilidad y no restarle valor.</p>
   </td>
  </tr>
 </tbody>
</table>

<h2 id="¿CSS_y_JavaScript_son_accesibles">¿CSS y JavaScript son accesibles?</h2>

<p>CSS y JavaScript no tienen la misma importancia inmediata para la accesibilidad que HTML, pero aún así pueden ayudar o dañar la accesibilidad, dependiendo de cómo se usen. Para decirlo de otra manera, es importante considerar algunos consejos de buenas prácticas para asegurarse de que el uso de CSS y JavaScript no arruina la accesibilidad de tus documentos.</p>

<h2 id="CSS">CSS</h2>

<p>Comencemos estudiando CSS.</p>

<h3 id="Semántica_correcta_y_expectativas_del_usuario">Semántica correcta y expectativas del usuario</h3>

<p><span class="tlid-translation translation" lang="es">Es posible usar CSS para hacer que cualquier elemento HTML se vea como <em>cualquier cosa</em>, pero esto no significa que deba hacerse. Como mencionamos con frecuencia en nuestro artículo <a href="/es/docs/Learn/Accessibility/HTML">HTML: Una buena base para la accesibilidad</a>, debes usar el elemento semántico apropiado para cada cosa, siempre que sea posible. Si no lo haces, puede causar confusión y problemas de usabilidad para todos, pero especialmente para los usuarios con discapacidades. El uso de la semántica correcta tiene mucho que ver con las expectativas del usuario: los elementos se ven y se comportan de cierta manera, de acuerdo con su funcionalidad, y los usuarios esperan estas convenciones comunes.</span></p>

<p>Por ejemplo, un usuario de lector de pantalla no puede navegar por una página a través de elementos de encabezado si el desarrollador no ha utilizado adecuadamente los elementos de encabezado para marcar el contenido. Del mismo modo, un encabezado pierde su propósito visual si se le aplica un estilo para que no parezca un encabezado.</p>

<p>La regla general es que puede actualizar el estilo de una característica de la página para que se ajuste a tu diseño, pero no cambiarlo tanto como para que ya no se vea ni se comporte como se esperaba. Las siguientes secciones resumen las principales características de HTML a considerar.</p>

<h4 id="Estructura_de_contenido_de_texto_estándar">Estructura de contenido de texto "estándar"</h4>

<p>Encabezados, párrafos, listas: el contenido de texto central de su página:</p>

<pre class="brush: html notranslate">&lt;h1&gt;Cabecera&lt;/h1&gt;

&lt;p&gt;Párrafo&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;Mi lista&lt;/li&gt;
  &lt;li&gt;tiene dos ítems.&lt;/li&gt;
&lt;/ul&gt;</pre>

<p>Un CSS típico podría tener este aspecto:</p>

<pre class="brush: css notranslate">h1 {
  font-size: 5rem;
}

p, li {
  line-height: 1.5;
  font-size: 1.6rem;
}</pre>

<p>Deberías:</p>

<ul>
 <li>Seleccionar tamaños de fuente razonables, alturas de línea, espaciado entre letras, etc. para que el texto sea lógico, legible y cómodo de leer.</li>
 <li>Asegurarte de que los títulos destaquen del texto del cuerpo, generalmente grandes y en negrita como estilo predeterminado. Tus listas deben parecer</li>
 <li>El color del texto debe contrastar bien con el color de fondo.</li>
</ul>

<p>Consulte <a href="/es/docs/Learn/HTML/Introduccion_a_HTML/texto">Fundamentos del texto HTML</a> y <a href="/es/docs/Learn/CSS/Styling_text">Estilo de texto</a> para obtener más información.</p>

<h4 id="Texto_enfatizado">Texto enfatizado</h4>

<p>Marcado en línea que confiere un énfasis específico al texto que rodea:</p>

<pre class="brush: html notranslate">&lt;p&gt;El agua está &lt;em&gt;muy caliente&lt;/em&gt;.&lt;/p&gt;

&lt;p&gt;Las gotas de agua que se acumulan en las superficies se denominan &lt;strong&gt;condensación&lt;/strong&gt;.&lt;/p&gt;</pre>

<p>Es posible que desees agregar algunos colores simples a su texto enfatizado:</p>

<pre class="brush: css notranslate">strong, em {
  color: #a60000;
}</pre>

<p>Sin embargo, rara vez necesitarás dar estilo a elementos de énfasis de manera significativa. Las convenciones estándar de texto en negrita y cursiva son muy reconocibles y cambiar el estilo puede causar confusión. Para obtener más información sobre el énfasis, consulte <a href="/es/docs/Learn/HTML/Introduccion_a_HTML/texto#%C3%89nfasis_e_importancia">Énfasis e importancia</a>.</p>

<h4 id="Abreviaciones">Abreviaciones</h4>

<p>Un elemento que permite asociar una abreviatura, un acrónimo o una inicialización a su expansión:</p>

<pre class="brush: html notranslate">&lt;p&gt;El contenido web se marca usando &lt;abbr title="Hypertext Markup Language"&gt;HTML&lt;/abbr&gt;.&lt;/p&gt;</pre>

<p>Nuevamente, es posible que desees darle estilo de una manera simple:</p>

<pre class="brush: css notranslate">abbr {
  color: #a60000;
}</pre>

<p>La convención de estilo reconocida para las abreviaturas es un subrayado punteado, y no es aconsejable desviarse significativamente de esto. Para obtener más información sobre abreviaturas, consulte <a href="/es/docs/Learn/HTML/Introduccion_a_HTML/Advanced_text_formatting#Abreviaturas">Abreviaturas</a>.</p>

<h4 id="Enlaces">Enlaces</h4>

<p>Hipervínculos: la forma de llegar a nuevos lugares en la web:</p>

<pre class="brush: html notranslate">&lt;p&gt;Visita la &lt;a href="https://www.mozilla.org"&gt;página de inicio de Mozilla&lt;/a&gt;.&lt;/p&gt;</pre>

<p>A continuación se muestra un estilo de enlace muy simple:</p>

<pre class="brush: css notranslate">a {
  color: #ff0000;
}

a:hover, a:visited, a:focus {
  color: #a60000;
  text-decoration: none;
}

a:active {
  color: #000000;
  background-color: #a60000;
}</pre>

<p>Las convenciones de enlace estándar son subrayado y un color diferente (predeterminado: azul) en su estado estándar, otra variación de color cuando el enlace ha sido visitado anteriormente (predeterminado: púrpura) y otro color más cuando el enlace está activado (predeterminado: rojo) . Además, el puntero del ratón cambia a un ícono de puntero cuando se pasa el ratón sobre los enlaces, y el enlace recibe un resaltado cuando se enfoca (por ejemplo, mediante tabulación) o se activa. La siguiente imagen muestra el resaltado tanto en Firefox (contorno punteado) como en Chrome (contorno azul):</p>

<p><img alt="" src="https://mdn.mozillademos.org/files/14371/focus-highlight-firefox.png" style="display: block; height: 173px; margin: 0px auto; width: 319px;"></p>

<p><img alt="" src="https://mdn.mozillademos.org/files/14369/focus-highlight-chrome.png" style="display: block; height: 169px; margin: 0px auto; width: 309px;"></p>

<p>Puedes ser creativo con los estilos de enlaces, siempre y cuando sigas dando información a los usuarios cuando interactúan con los enlaces. Definitivamente, algo debería suceder cuando los estados cambian, y no debes deshacerte del cursor del puntero o del contorno; ambos son ayudas de accesibilidad muy importantes para quienes usan los controles del teclado.</p>

<h4 id="Elementos_de_formulario">Elementos de formulario</h4>

<p>Elementos que permiten a los usuarios introducir datos en sitios web:</p>

<pre class="brush: html notranslate">&lt;div&gt;
  &lt;label for="nombre"&gt;Entra tu nombre&lt;/label&gt;
  &lt;input type="text" id="nombre" name="nombre"&gt;
&lt;/div&gt;</pre>

<p>Puedes ver algunos buenos ejemplos de CSS en nuestro ejemplo de <a href="https://github.com/mdn/learning-area/blob/master/accessibility/css/form-css.html">form-css.html</a> (<a href="https://github.com/mdn/learning-area/blob/master/accessibility/css/form-css.html">pruébalo en vivo</a> también).</p>

<p>La mayor parte del CSS que escribirás para los formularios será para dimensionar los elementos, alinear las etiquetas y las entradas y hacer que se vean limpios y ordenados.</p>

<p>Sin embargo, no debes desviarse demasiado de la retroalimentación visual esperada que reciben los elementos del formulario cuando están enfocados, que es básicamente la mismo que con los enlaces (ver más arriba). Puedes aplicar estilos a los estados de enfoque / desplazamiento del formulario para que este comportamiento sea más coherente en todos los navegadores o se adapte mejor al diseño de tu página, pero no te deshagas de él por completo; de nuevo, las personas confían en estas pistas para ayudarles a saber qué está pasando.</p>

<h4 id="Tablas">Tablas</h4>

<p>Tablas para presentar datos tabulares.</p>

<p>Puedes ver un buen y simple ejemplo de tabla HTML y CSS en nuestro ejemplo <a href="https://github.com/mdn/learning-area/blob/master/accessibility/css/table-css.html">table-css.html</a> (<a href="http://mdn.github.io/learning-area/accessibility/css/table-css.html">pruébalo en vivo</a> también).</p>

<p>El CSS de tablas generalmente sirve para hacer que la tabla se adapte mejor a su diseño y se vea menos fea. Es una buena idea asegurarse de que los encabezados de la tabla se destaquen (normalmente en negrita) y usar rayas de cebra para que las diferentes filas sean más fáciles de analizar.</p>

<h3 id="Color_y_contraste_de_color">Color y contraste de color</h3>

<p>Al elegir un esquema de color para tu sitio web, asegúrate de que el color del texto (primer plano) contrasta bien con el color de fondo. Tu diseño puede verse bien, pero no es bueno si las personas con discapacidades visuales como daltonismo no pueden leer tu contenido.</p>

<p>Existe una manera fácil de verificar si el contraste es lo suficientemente grande como para no causar problemas. Hay una serie de herramientas de verificación de contraste en línea en las que puede introduci los colores de primer plano y de fondo para verificarlos. Por ejemplo, el <a href="http://webaim.org/resources/contrastchecker/">Comprobador de contraste de color</a> de WebAIM es fácil de usar y proporciona una explicación de lo que necesitas para cumplir con los criterios WCAG sobre el contraste de color.</p>

<div class="note">
<p><strong>Nota</strong>: una relación de contraste alta también permitirá que cualquier persona que utilice un teléfono inteligente o una tableta con una pantalla brillante lea mejor las páginas cuando se encuentre en un entorno brillante, como a la luz del sol.</p>
</div>

<p>Otro consejo es no confiar solo en el color para las señales / información, ya que esto no será bueno para aquellos que no pueden ver el color. En lugar de marcar los campos de formulario obligatorios en rojo, por ejemplo, márcalos con un asterisco y en rojo.</p>

<h3 id="Esconder_cosas">Esconder cosas</h3>

<p>Hay muchos casos en los que un diseño visual requerirá que no se muestre todo el contenido a la vez. Por ejemplo, en nuestro ejemplo de <a href="http://mdn.github.io/learning-area/css/css-layout/practical-positioning-examples/info-box.html">cuadro de información con pestañas</a> (ver <a href="https://github.com/mdn/learning-area/blob/master/css/css-layout/practical-positioning-examples/info-box.html">código fuente</a>) tenemos tres paneles de información, pero los colocamos uno encima del otro y proporcionamos pestañas en las que se puede hacer clic para mostrar cada uno (también es accesible desde el teclado - pues usar alternativamente Tab y Enter / Return para seleccionarlos).</p>

<p><img alt="" src="https://mdn.mozillademos.org/files/13368/tabbed-info-box.png" style="display: block; height: 400px; margin: 0px auto; width: 450px;"></p>

<p>A los usuarios de lectores de pantalla no les importa nada de esto: están contentos con el contenido siempre que el orden del código fuente tenga sentido y puedan acceder a todo. El posicionamiento absoluto (como se usa en este ejemplo) generalmente se considera uno de los mejores mecanismos para ocultar contenido para lograr un efecto visual, porque no impide que los lectores de pantalla accedan a él.</p>

<p>Por otro lado, no debes usar {{cssxref ("visibility")}}<code>: hidden</code> o {{cssxref ("display")}}<code>: none</code>, porque ocultan el contenido de los lectores de pantalla. A menos que, por supuesto, exista una buena razón por la que desees ocultar este contenido a los lectores de pantalla.</p>

<div class="note">
<p><strong>Nota</strong>: <span class="subtitle"><a href="http://webaim.org/techniques/css/invisiblecontent/">Invisible Content Just for Screen Reader Users</a> </span>tiene muchos más detalles útiles sobre este tema.</p>
</div>

<h3 id="Acepta_que_los_usuarios_pueden_saltarse_tus_estilos">Acepta que los usuarios pueden saltarse tus estilos</h3>

<p>Es posible que los usuarios anulen tus estilos con sus propios estilos personalizados, por ejemplo:</p>

<ul>
 <li>Consulte <a class="external external-icon" href="https://www.itsupportguides.com/knowledge-base/computer-accessibility/how-to-use-a-custom-style-sheet-css-with-firefox/" rel="noopener">How to use a custom style sheet (CSS) with Firefox</a>, de Sarah Maddox, una útil guía que cubre cómo hacer esto manualmente en Firefox.</li>
 <li>Probablemente sea más fácil hacerlo usando una extensión; por ejemplo, la extensión Stylish está disponible para <a href="https://addons.mozilla.org/en-US/firefox/addon/stylish/">Firefox</a>, <a href="https://safari-extensions.apple.com/details/?id=com.sobolev.stylish-5555L95H45">Safari</a>, <a href="https://addons.opera.com/en/extensions/details/stylish/">Opera</a> y <a href="https://chrome.google.com/webstore/detail/stylish/fjnbnpbmkenffdnngjfgmeleoegfcffe">Chrome</a>.</li>
</ul>

<p><span class="tlid-translation translation" lang="es">Los usuarios pueden hacerlo por diversas razones. Un usuario con discapacidad visual puede querer agrandar el texto en todos los sitios web que visita, o un usuario con una deficiencia de color severa puede querer poner todos los sitios web en colores de alto contraste que sean fáciles de ver. Cualquiera que sea la necesidad, debes sentirse cómodo con esto y hacer que tus diseños sean lo suficientemente flexibles para que dichos cambios funcionen en tu diseño. Como ejemplo, es posible que desees asegurarte de que tu área de contenido principal pueda manejar texto más grande (tal vez comience a desplazarse para permitir que se vea todo), y no solo lo ocultará o romperá por completo.</span></p>

<h2 id="JavaScript">JavaScript</h2>

<p>JavaScript también puede romper la accesibilidad, dependiendo de cómo se use.</p>

<p>El JavaScript moderno es un lenguaje poderoso, y podemos hacer mucho con él actualmente, desde contenido simple y actualizaciones de la interfaz de usuario hasta juegos 2D y 3D completos. No existe una regla que diga que todo el contenido debe ser 100% accesible para todas las personas; solo debe hacer lo que pueda y hacer que sus aplicaciones sean lo más accesibles posible.</p>

<p>Se puede decir que el contenido y la funcionalidad simples son fáciles de hacer accesibles; por ejemplo, texto, imágenes, tablas, formularios y botones que activan funciones. Como vimos en nuestro artículo <a href="https://developer.mozilla.org/es/docs/Learn/Accessibility/HTML">HTML: Una buena base para la accesibilidad</a>, las consideraciones clave son:</p>

<ul>
 <li>Buena semántica: usar el elemento correcto para el trabajo correcto. Por ejemplo, asegúrate de usar encabezados y párrafos, y elementos {{htmlelement ("button")}} y {{htmlelement ("a")}}</li>
 <li>Asegurarse de que el contenido esté disponible como texto, ya sea directamente como contenido de texto, buenas etiquetas de texto para los elementos de formulario o alternativas de texto, p.ej. texto alternativo para imágenes.</li>
</ul>

<p>También vimos un ejemplo de cómo usar JavaScript para incorporar la funcionalidad donde faltaba; consulta <a href="/es/docs/Learn/Accessibility/HTML#Volver_a_añadir_la_accesibilidad_del_teclado">Volver a añadir la accesibilidad del teclado</a>. Esto no es ideal; en realidad, deberías usar el elemento correcto para el trabajo correcto, pero demuestra que es posible en situaciones en las que, por alguna razón, no puedes controlar el marcado que se utiliza. Otra forma de mejorar la accesibilidad de los widgets no semánticos que funcionan con JavaScript es utilizar WAI-ARIA para proporcionar semántica adicional para los usuarios de lectores de pantalla. El próximo artículo también cubrirá esto en detalle.</p>

<p>Las funcionalidades complejas como los juegos en 3D no son tan fáciles de hacer accesibles: un juego en 3D complejo creado con <a href="/es/docs/Web/API/WebGL_API">WebGL</a> se renderizará en un elemento {{htmlelement ("canvas")}}, que en este momento no tiene la capacidad de proporcionar alternativas de texto u otros información que pueden utilizar los usuarios con discapacidad visual grave. Se puede argumentar que un juego de este tipo no tiene realmente a este grupo de personas como parte de su público objetivo principal, y no sería razonable esperar que lo hicieras 100% accesible para las personas ciegas; sin embargo, podrías implementar controles de teclado para que sea utilizable por usuarios que no utilizan el ratóny hacer que el esquema de color sea lo suficientemente contrastante como para que lo puedan usar aquellos con deficiencias de color.</p>

<h3 id="El_problema_de_demasiado_JavaScript">El problema de demasiado JavaScript</h3>

<p>El problema a menudo surge cuando la gente confía demasiado en JavaScript. A veces verás un sitio web donde todo se ha hecho con JavaScript: el HTML ha sido generado por JavaScript, el CSS ha sido generado por JavaScript, etc. Esto tiene todo tipo de problemas de accesibilidad y otros asociados, por lo que no es aconsejado.</p>

<p>Además de utilizar el elemento correcto para el trabajo correcto, ¡también debes asegurarte de utilizar la tecnología adecuada para el trabajo correcto! Piensa detenidamente si necesitas ese brillante cuadro de información en 3D con JavaScript o si bastaría con texto antiguo sin formato. Piensa detenidamente si necesitas un widget de formulario no estándar complejo o si una entrada de texto sería suficiente. Y no generes todo tu contenido HTML usando JavaScript si es posible.</p>

<h3 id="Hacerlo_no_intrusivo">Hacerlo no intrusivo</h3>

<p>Deberías hacer tu <strong>JavaScript no intrusivo</strong> al crear tu contenido. La idea de JavaScript no intrusivo es que debe usarse siempre que sea posible para mejorar la funcionalidad, no para construirlo todo; las funciones básicas deberían funcionar idealmente sin JavaScript, aunque sabemos que esto no siempre es una opción. Pero, de nuevo, una gran parte es usar las funcionalidades integradas del navegador siempre que sea posible.</p>

<p>Entre los buenos ejemplos de usos de JavaScript no intrusivo se incluyen:</p>

<ul>
 <li>Proporcionar validación de formularios del lado del cliente, que alerta a los usuarios sobre problemas con las entradas de sus formularios rápidamente, sin tener que esperar a que el servidor verifique los datos. Si no está disponible, el formulario seguirá funcionando, pero la validación puede ser más lenta.</li>
 <li>Proporcionar controles personalizados para <code>&lt;video&gt;</code> HTML5 a los que pueden acceder los usuarios que solo utilizan el teclado, junto con un enlace directo al video que se puede usar para acceder a él si JavaScript no está disponible (los controles del navegador predeterminados para <code>&lt;video&gt;</code> no son acccesibles por teclado en la mayoría de los navegadores).</li>
</ul>

<p><span class="tlid-translation translation" lang="es">Como ejemplo, hemos escrito un ejemplo rápido y sucio de validación de formulario del lado del cliente: consulta <a href="https://github.com/mdn/learning-area/blob/master/accessibility/css/form-validation.html">form-validation.html</a> (y también la <a href="http://mdn.github.io/learning-area/accessibility/css/form-validation.html">demostración en vivo</a>). Aquí verás un formulario simple; al intentar enviar el formulario con uno o ambos campos vacíos, el envío falla y aparece un cuadro de mensaje de error para indicar cuál es el problema.<br>
 <br>
 Este tipo de validación de formulario es no intrusiva: se puede usar el formulario perfectamente aunque JavaScript no esté disponible, y cualquier implementación de formulario razonable también tendrá activa la validación del lado del servidor, porque es demasiado fácil para los usuarios malintencionados eludir la validación del lado del cliente (por ejemplo, desactivando JavaScript en el navegador). La validación del lado del cliente sigue siendo realmente útil para informar de errores: los usuarios pueden saber los errores que cometen al instante, en lugar de tener que esperar un viaje de ida y vuelta al servidor y la recarga de la página. Esta es una clara ventaja de usabilidad.</span></p>

<div class="note">
<p><strong>Nota</strong>: la validación del lado del servidor no se ha implementado en esta simple demostración.</p>
</div>

<p>También hemos hecho que esta validación de formulario sea bastante accesible. Hemos utilizado elementos {{htmlelement ("label")}} para asegurarnos de que las etiquetas del formulario estén vinculadas de forma inequívoca a sus entradas, de modo que los lectores de pantalla puedan leerlas junto con ellas:</p>

<pre class="brush: html notranslate">&lt;label for="name"&gt;Entra tu nombre:&lt;/label&gt;
&lt;input type="text" name="name" id="name"&gt;</pre>

<p>Solo realizamos la validación cuando se envía el formulario; esto es para no actualizar la IU con demasiada frecuencia y confundir potencialmente a los lectores de pantalla (y posiblemente a otros) usuarios:</p>

<pre class="brush: js notranslate">form.onsubmit = validate;

function validate(e) {
  errorList.innerHTML = '';
  for(let i = 0; i &lt; formItems.length; i++) {
    const testItem = formItems[i];
    if(testItem.input.value === '') {
      errorField.style.left = '360px';
      createLink(testItem);
    }
  }

  if(errorList.innerHTML !== '') {
    e.preventDefault();
  }
}</pre>

<div class="note">
<p><strong>Nota</strong>: En este ejemplo estamos ocultando y mostrando el cuadro de mensaje de error utilizando posicionamiento absoluto en lugar de otro método como la visibilidad o la visualización, porque no interfiere con que el lector de pantalla pueda leer su contenido.</p>
</div>

<p>La validación real del formulario sería mucho más compleja que esto: querría verificar que el nombre entrado realmente parezca un nombre, la edad entrada sea realmente un número y sea realista (por ejemplo, no negativa y menor de 4 dígitos). Aquí acabamos de implementar una verificación simple de que se haya completado un valor en cada campo de entrada (<code>if(testItem.input.value === '')</code>).</p>

<p>Cuando se ha realizado la validación, si las pruebas pasan, se envía el formulario. Si hay errores (<code>if (errorList.innerHTML! == '')</code>), detenemos el envío del formulario (usando <code>preventDefault()</code>) y mostramos los mensajes de error que se hayan creado (ver más abajo). Este mecanismo significa que los errores solo se mostrarán si hay errores, lo que es mejor para la usabilidad.</p>

<p>Para cada entrada sin un valor completado cuando se envía el formulario, creamos un elemento de lista con un enlace y lo insertamos en <code>errorList</code>.</p>

<pre class="brush: js notranslate">function createLink(testItem) {
  const listItem = document.createElement('li');
  const anchor = document.createElement('a');

  anchor.textContent = 'El campo ' + testItem.input.name + ' está vacío. Entra tu ' + testItem.input.name + '.';
  anchor.href = '#' + testItem.input.name;
  anchor.onclick = function() {
    testItem.input.focus();
  };
  listItem.appendChild(anchor);
  errorList.appendChild(listItem);
}</pre>

<p>Cada enlace tiene un doble propósito: te dice cuál es el error, y además puedes hacer clic en él / activarlo para ir directamente al elemento de entrada en cuestión y corregir la entrada.</p>

<div class="note">
<p><strong>Nota</strong>: La parte <code>focus()</code> de este ejemplo es un poco complicada. Chrome y Edge darán foco al elemento al hacer clic en el enlace, sin necesidad del bloque <code>onclick</code> / <code>focus()</code>. Safari solo resaltará el elemento de formulario con el enlace por sí solo, por lo que necesita el bloque <code>onclick</code> / <code>focus()</code> para darle foco. Firefox no da foco a las entradas correctamente en este contexto, por lo que los usuarios de Firefox no pueden aprovechar esto en este momento (aunque todo lo demás funciona bien). El problema de Firefox debería solucionarse pronto; se está trabajando para que el comportamiento de Firefox sea igual al de otros navegadores (consulte {{bug (277178)}}).</p>
</div>

<p>Además, el <code>errorField</code> se coloca en la parte superior del orden de código (aunque se coloca de manera diferente en la interfaz de usuario usando CSS), lo que significa que los usuarios pueden averiguar exactamente qué está mal con los envíos de sus formularios y acceder a los elementos de entrada en cuestión retrocediendo hasta el inicio de la página.</p>

<p>Como nota final, hemos utilizado algunos atributos WAI-ARIA en nuestra demostración para ayudar a resolver los problemas de accesibilidad causados ​​por áreas de contenido que se actualizan constantemente sin recargar la página (los lectores de pantalla no captan esto ni alertan a los usuarios de forma predeterminada):</p>

<pre class="notranslate">&lt;div class="errors" role="alert" aria-relevant="all"&gt;
  &lt;ul&gt;
  &lt;/ul&gt;
&lt;/div&gt;</pre>

<p>Explicaremos estos atributos en nuestro próximo artículo, que cubre <a href="/en-US/docs/Learn/Accessibility/WAI-ARIA_basics">WAI-ARIA</a> con mucho más detalle.</p>

<div class="note">
<p><strong>Nota</strong>: Algunos de vosotros probablemente estaréis pensando en el hecho de que los formularios HTML5 tienen mecanismos de validación integrados como los atributos <code>required</code>, <code>min</code> / <code>minlength</code> y <code>max</code> / <code>maxlength</code> (consultad la referencia del elemento {{htmlelement("input")}} para más información). No los hemos usado en la demostración porque la compatibilidad entre navegadores es irregular (por ejemplo, solo funciona en IE10 y versiones superiores).</p>
</div>

<div class="note">
<p><strong>Nota</strong>: <a href="http://webaim.org/techniques/formvalidation/">Usable and Accessible Form Validation and Error Recovery</a>, de WebAIM, proporciona más información útil sobre la validación de formularios accesibles.</p>
</div>

<h3 id="Otros_potenciales_problemas_de_accesibilidad_de_JavaScript">Otros potenciales problemas de accesibilidad de JavaScript</h3>

<p>Hay otras cosas que debes tener en cuenta al implementar JavaScript y pensar en la accesibilidad. Agregaremos más a medida que los encontremos.</p>

<h4 id="Eventos_específicos_del_ratón">Eventos específicos del ratón</h4>

<p>Como sabrás, la mayoría de las interacciones de los usuarios se implementan en JavaScript del lado del cliente mediante controladores de eventos, que nos permiten ejecutar funciones en respuesta a ciertos eventos que suceden. Algunos eventos pueden tener problemas de accesibilidad. El ejemplo principal con el que se encontrará son los eventos específicos del ratón, como <code>mouseover</code>, <code>mouseout</code>, <code>dblclick</code>, etc. La funcionalidad que se ejecuta en respuesta a estos eventos no será accesible mediante otros mecanismos, como los controles del teclado.</p>

<p>Para mitigar estos problemas, debes duplicar estos eventos con eventos similares que se pueden activar por otros medios (los llamados controladores de eventos independientes de dispositivo); <code>focus</code> y <code>blur</code> proporcionarían accesibilidad para los usuarios del teclado.</p>

<p>Veamos un ejemplo que destaca cuándo esto podría ser útil. Tal vez queramos proporcionar una imagen en miniatura que muestre una versión más grande de la imagen cuando al colocar el ratón sobre ella o darle foco (como pasaría en un catálogo de productos de comercio electrónico).</p>

<p>Hemos creado un ejemplo muy simple, que puedes encontrar en <a href="http://mdn.github.io/learning-area/accessibility/css/mouse-and-keyboard-events.html">mouse-and-keyboard-events.html</a> (consulta también el <a href="https://github.com/mdn/learning-area/blob/master/accessibility/css/mouse-and-keyboard-events.html">código fuente</a>). El código presenta dos funciones que muestran y ocultan la imagen ampliada; estas se ejecutan mediante las siguientes líneas que las configuran como controladores de eventos:</p>

<pre class="brush: js notranslate">imgThumb.onmouseover = showImg;
imgThumb.onmouseout = hideImg;

imgThumb.onfocus = showImg;
imgThumb.onblur = hideImg;</pre>

<p>Las dos primeras líneas ejecutan las funciones cuando el puntero del ratón se desplaza sobre la miniatura y deja de hacerlo, respectivamente. Sin embargo, esto no nos permite acceder a la vista ampliada con el teclado; para hacerlo hemos incluido las dos últimas líneas, que ejecutan las funciones cuando la imagen toma y pierde el foco. Esto se puede hacer presionando el tabulador hasta llegar a la imagen, porque le hemos dado <code>tabindex="0"</code>.</p>

<p>El evento de <code>click</code> es interesante: parce dependiente del ratón, pero la mayoría de los navegadores activan los controladores de eventos <code>onclick</code> al presionar Enter / Return en un enlace o elemento de formulario que tenga foco, o cuando dicho elemento se toca en un dispositivo de pantalla táctil. Sin embargo, esto no funciona por defecto cuando permites que un evento no enfocable por defecto adquiera el foco usando tabindex; en tales casos, debe detectar específicamente cuándo se presiona esa tecla exacta (consulte <a href="/es/docs/Learn/Accessibility/HTML#Volver_a_añadir_la_accesibilidad_del_teclado">Volver a añadir la accesibilidad del teclado</a>).</p>

<h2 id="¡Pon_a_prueba_tus_habilidades">¡Pon a prueba tus habilidades</h2>

<p>Has llegado al final de este artículo. ¿Recuerdas la información más importante? Encontrar pruebas para verificar que has retenido esta información antes de continuar en <a href="/en-US/docs/Learn/Accessibility/CSS_and_JavaScript/Test_your_skills:_CSS_and_JavaScript_accessibility">Test your skills: CSS and JavaScript accessibility</a>.</p>

<h2 id="Resumen">Resumen</h2>

<p>Esperamos que este artículo te haya brindado una buena cantidad de detalles y comprensión sobre los problemas de accesibilidad relacionados con el uso de CSS y JavaScript en las páginas web.</p>

<p>¡Siguiente parada, WAI-ARIA!</p>

<div>{{PreviousMenuNext("Learn/Accessibility/HTML","Learn/Accessibility/WAI-ARIA_basics", "Learn/Accessibility")}}</div>

<div>
<h2 id="In_this_module">In this module</h2>

<ul>
 <li><a href="/en-US/docs/Learn/Accessibility/What_is_accessibility">What is accessibility?</a></li>
 <li><a href="/en-US/docs/Learn/Accessibility/HTML">HTML: A good basis for accessibility</a></li>
 <li><a href="/en-US/docs/Learn/Accessibility/CSS_and_JavaScript">CSS and JavaScript accessibility best practices</a></li>
 <li><a href="/en-US/docs/Learn/Accessibility/WAI-ARIA_basics">WAI-ARIA basics</a></li>
 <li><a href="/en-US/docs/Learn/Accessibility/Multimedia">Accessible multimedia</a></li>
 <li><a href="/en-US/docs/Learn/Accessibility/Mobile">Mobile accessibility</a></li>
 <li><a href="/en-US/docs/Learn/Accessibility/Accessibility_troubleshooting">Accessibility troubleshooting</a></li>
</ul>
</div>