Cómo mejorar las ventanas modales para todos

 

 

 

  • Implemente rápidamente. Implementar inteligentemente
  • Smart Interface Design Patterns, 10h video + UX training

  • Índice
    1. Una mejor semántica conduce a una mejor usabilidad y accesibilidad
    2. Hacer que los modales sean más utilizables y accesibles
      1. Incluyendo estados de enfoque
      2. Guardar el último elemento activo
      3. Enfoque cambiante
      4. Pasar a pantalla completa
      5. Despedir
    3. Pasos adicionales de accesibilidad
      1. aria-oculta
      2. rol = "diálogo"
      3. etiqueta-aria
    4. ¿Qué pasa con el elemento de diálogo de HTML5?
    5. ¿A dónde ir desde aquí?
      1. Otras lecturas

    Dependiendo de cómo un usuario navegue por Internet, las ventanas modales pueden resultar francamente confusas. Los modales cambian rápidamente el enfoque visual de una parte de un sitio web o aplicación a otra área de contenido. Este escenario es más común de lo que debería ser. Y es bastante fácil de resolver, siempre y cuando haga que su contenido sea accesible para todos mediante prácticas sólidas de usabilidad. En este artículo, Scott O'Hara ha configurado una demostración de una ventana modal inaccesible que aparece al cargar la página y que no es del todo semántica. Primero, interactúe con él usando el mouse para ver si realmente funciona. Luego, intenta interactuar con él usando solo tu teclado.

     

    Para usted, las ventanas modales pueden ser una bendición de espacio adicional en la pantalla, ya que brindan una manera de entregar información contextual, notificaciones y otras acciones relevantes para la pantalla actual. Por otro lado, los modales pueden parecer un truco que te has visto obligado a realizar para incluir contenido adicional en la pantalla. Estos son los extremos del espectro y los usuarios están atrapados en el medio. Dependiendo de cómo un usuario navegue por Internet, las ventanas modales pueden resultar francamente confusas .

     

    Los modales cambian rápidamente el enfoque visual de una parte de un sitio web o aplicación a otra área de contenido (con suerte relacionado). La acción generalmente no es discordante si la inicia el usuario, pero puede ser molesta y desorientadora si ocurre automáticamente, como sucede con los primos malvados de la ventana modal, la "pantalla molesta" y la "intersticial".

    Sin embargo, los modales son simplemente una ligera molestia al final, ¿verdad? El usuario sólo tiene que hacer clic en el botón "cerrar", hojear rápidamente algún contenido o completar un formulario para descartarlo.

    Bueno, imagina que tuvieras que navegar por la web con un teclado. Supongamos que aparece una ventana modal en la pantalla y tiene muy poco contexto para saber qué es y por qué oscurece el contenido que está intentando explorar. Ahora te estarás preguntando: "¿Cómo interactúo con esto?" o "¿Cómo me deshago de él?" porque el foco de su teclado no se ha movido automáticamente a la ventana modal.

    Este escenario es más común de lo que debería ser. Y es bastante fácil de resolver, siempre y cuando hagamos que nuestro contenido sea accesible para todos mediante prácticas sólidas de usabilidad.

    Por ejemplo, configuré una demostración de una ventana modal inaccesible que aparece al cargar la página y que no es completamente semántica. Primero, interactúe con él usando el mouse para ver si realmente funciona. Luego, intenta interactuar con él usando solo tu teclado.

    Una mejor semántica conduce a una mejor usabilidad y accesibilidad

    Muchas ventanas modales carecen de usabilidad y accesibilidad. Ya sea que se utilicen para proporcionar acciones o entradas adicionales para la interacción con la página, para incluir más información sobre una sección particular de contenido o para proporcionar notificaciones que puedan descartarse fácilmente, los modales deben ser fáciles de usar para todos.

    Para lograr este objetivo, primero debemos centrarnos en la semántica del marcado modal. Esto puede parecer una obviedad, pero no siempre se sigue el paso.

    Supongamos que un sitio web de juegos popular tiene una superposición modal de página completa y ha implementado un botón de "cerrar" con el siguiente código:

    div div X /div …/div

    Este divelemento no tiene ningún significado semántico detrás. Los visitantes videntes sabrán que se trata de un botón de "cerrar" porque parece que lo es. Tiene un estado flotante, por lo que hay alguna indicación visual de que se puede interactuar con él.

     

    Pero este elemento no tiene ningún significado semántico heredado para las personas que utilizan un teclado o un lector de pantalla.

    No existe una forma predeterminada de permitir que los usuarios accedan a a divsin agregarle un tabindexatributo. Sin embargo, también necesitaríamos agregar un :focusestado para indicar visualmente que es el elemento activo. Eso todavía no proporciona a los lectores de pantalla suficiente información para que los usuarios puedan discernir el significado del elemento. Una "X" es la única etiqueta aquí. Si bien podemos suponer que las personas que usan lectores de pantalla sabrían que la letra "X" significa "cerrar", si fuera un signo de multiplicación (usando la entidad HTML times;) o una cruz ( ), entonces algunos lectores de pantalla no leerían en absoluto. Necesitamos una mejor alternativa.

    Podemos evitar todos estos problemas simplemente escribiendo el marcado semántico correcto para un botón y agregando una etiqueta ARIA para los lectores de pantalla:

    div button type="button" aria-label="close" X /button/div

    Al cambiarlo diva un botón, hemos mejorado significativamente la semántica de nuestro botón "cerrar". Hemos abordado la expectativa común de que se puede acceder al botón mediante tabulación con un teclado y aparecer enfocado, y hemos proporcionado contexto agregando la etiqueta ARIA para lectores de pantalla.

    Este es sólo un ejemplo de cómo hacer que el marcado de nuestros modales sea más semántico, pero podemos hacer mucho más para crear una experiencia útil y accesible.

    Hacer que los modales sean más utilizables y accesibles

    El marcado semántico contribuye en gran medida a crear una ventana modal totalmente utilizable y accesible, pero aún más CSS y JavaScript pueden llevar la experiencia al siguiente nivel.

    Incluyendo estados de enfoque

    ¡Proporcione un estado de enfoque! Obviamente, esto no es exclusivo de las ventanas modales; muchos elementos carecen de un estado de enfoque adecuado de una forma u otra más allá del estado predeterminado básico del navegador (que puede o no haber sido eliminado por el restablecimiento de CSS). Como mínimo, empareje el estado de enfoque con el estado de desplazamiento que ya diseñó:

    .btn:hover, .btn:focus { background: #f00;}

    Sin embargo, debido a que enfocar y flotar son diferentes tipos de interacción, tiene sentido darle al estado de enfoque su propio estilo.

    .btn:hover { background: #f00;}:focus { box-shadow: 0 0 3px rgba(0,0,0,.75);}

    Realmente, cualquier elemento que pueda enfocarse debería tener un estado de enfoque. Tenga esto en cuenta si está ampliando el contorno de puntos predeterminado del navegador.

    Guardar el último elemento activo

    Cuando se carga una ventana modal, se debe guardar el elemento con el que el usuario interactuó por última vez. De esa forma, cuando la ventana modal se cierre y el usuario regrese a donde estaba, se habrá mantenido el foco en ese elemento. Piense en ello como un marcador. Sin él, cuando el usuario cierre el modal, sería enviado de regreso al principio del documento y abandonado para encontrar su lugar. Agregue lo siguiente a las funciones de apertura y cierre de su modal para guardar y volver a habilitar el enfoque del usuario.

     

    var lastFocus;function modalShow () { lastFocus = document.activeElement;}function modalClose () { lastFocus.focus(); // place focus on the saved element}

    Enfoque cambiante

    Cuando se carga el modal, el foco debe pasar del último elemento activo a la ventana modal misma o al primer elemento interactivo del modal, como un elemento de entrada. Esto hará que el modal sea más utilizable porque los visitantes videntes no tendrán que alcanzar el mouse para hacer clic en el primer elemento, y los usuarios del teclado no tendrán que desplazarse por un montón de elementos DOM para llegar allí.

    var modal = document.getElementById('your-modal-id-here');function modalShow () { modal.setAttribute('tabindex', '0'); modal.focus();}

    Pasar a pantalla completa

    Si su modal ocupa toda la pantalla, oscurezca el contenido del documento principal tanto para los usuarios videntes como para los usuarios de lectores de pantalla. Sin que esto suceda, un usuario de teclado podría fácilmente salir del modal sin darse cuenta, lo que podría llevarlo a interactuar con el documento principal antes de completar lo que la ventana modal le pide que haga. Todos sobre leds e iluminación

    Utilice el siguiente JavaScript para limitar el foco del usuario a la ventana modal hasta que se cierre:

    function focusRestrict ( event ) { document.addEventListener('focus', function( event ) { if ( modalOpen !modal.contains( event.target ) ) { event.stopPropagation(); modal.focus(); } }, true);}

    Si bien queremos evitar que los usuarios naveguen por el resto del documento mientras un modal está abierto, no queremos evitar que accedan al Chrome del navegador (después de todo, los usuarios videntes no esperarían quedarse atrapados en la pestaña del navegador). mientras una ventana modal está abierta). El JavaScript anterior evita la tabulación del contenido del documento fuera de la ventana modal, en lugar de eso, lleva al usuario a la parte superior del modal.

    Si también colocamos el modal en la parte superior del árbol DOM, como el primer hijo de body, al presionarlo, Shift + Tabel usuario saldría del modal y entraría en Chrome del navegador. Si no puede cambiar la ubicación del modal en el árbol DOM, utilice el siguiente JavaScript:

    var m = document.getElementById('modal_window'), p = document.getElementById('page');// Remember that div surrounds the whole document,// so aria-hidden="true" can be applied to it when the modal opens.function swap () { p.parentNode.insertBefore(m, p);}swap();

    Si no puede mover el modal en el árbol DOM o reposicionarlo con JavaScript, aún tiene otras opciones para limitar el foco al modal. Puede realizar un seguimiento del primer y último elemento enfocable en la ventana modal. Cuando el usuario llega al último y presiona Tab, puede volver a centrar el foco en la parte superior del modal. (Y harías lo contrario por Shift + Tab).

    Una segunda opción sería crear una lista de todos los nodos enfocables en la ventana modal y, tras la activación modal, permitir la tabulación solo a través de esos nodos.

    Una tercera opción sería encontrar todos los nodos enfocables fuera del modal y configurarlos tabindex=“-1”.

     

    El problema con esta primera y segunda opción es que hacen que Chrome del navegador sea inaccesible. Si debe tomar esta ruta, entonces Escapees fundamental agregar un botón de “cerrar” bien marcado al modal y respaldar la clave; sin ellos, atrapará efectivamente a los usuarios de teclados en el sitio web.

    La tercera opción permite tabular dentro del modal y del Chrome del navegador, pero tiene el costo de rendimiento de enumerar todos los elementos enfocables en la página y negar su capacidad de enfocarse. Puede que el costo no sea alto en una página pequeña, pero en una página con muchos enlaces y elementos de formulario, puede convertirse en una tarea ardua. Sin mencionar que cuando se cierre el modal, deberá devolver todos los elementos a su estado anterior.

    Claramente, tenemos mucho que considerar para permitir a los usuarios tabular de manera efectiva dentro de un modal.

    Despedir

    Finalmente, los modales deberían ser fáciles de descartar. Los cuadros de diálogo modales estándar alert()se pueden cerrar presionando la Escapetecla, por lo que se esperaría hacer lo mismo con nuestro modal, y sería conveniente. Si su modal tiene múltiples elementos enfocables, permitir que el usuario simplemente presione Escapees mucho mejor que obligarlo a desplazarse por el contenido para llegar al botón "cerrar".

    function modalClose ( e ) { if ( !e.keyCode || e.keyCode === 27 ) { // code to close modal goes here }}document.addEventListener('keydown', modalClose);

    Además, cerrar un modal de pantalla completa cuando se hace clic en la superposición es convencional. La excepción es si no desea cerrar el modal hasta que el usuario haya realizado una acción.

    Utilice el siguiente JavaScript para cerrar el modal cuando el usuario haga clic en la superposición:

    mOverlay.addEventListener('click', function( e ) if (e.target == modal.parentNode) modalClose( e ); }}, false);

    Pasos adicionales de accesibilidad

    Más allá de los pasos de usabilidad cubiertos anteriormente, los roles, estados y propiedades de ARIA agregarán aún más ganchos para las tecnologías de asistencia. Para algunos de estos, no se requiere nada más que agregar el atributo correspondiente a su marcado; para otros, se requiere JavaScript adicional para controlar el estado de un elemento.

    aria-oculta

    Utilice el aria-hiddenatributo. Al alternar el valor truey false, el elemento y cualquiera de sus hijos estarán ocultos o visibles para los lectores de pantalla. Sin embargo, como ocurre con todos los atributos de ARIA, no tiene un estilo predeterminado y, por lo tanto, no estará oculto a los usuarios videntes. Para ocultarlo, agregue el siguiente CSS:

    .modal-window[aria-hidden="true"] { display: none;}

    Observe que el selector es bastante específico aquí. La razón es que es posible que no queramos que todos los elementos aria-hidden=“true”estén ocultos (como en nuestro ejemplo anterior de la "X" para el botón "cerrar").

    rol = "diálogo"

    Agregar role=“dialog”al elemento que contiene el contenido del modal. Esto le dice a las tecnologías de asistencia que el contenido requiere la respuesta o confirmación del usuario. Nuevamente, combine esto con JavaScript que cambia el foco del último elemento activo en el documento al modal o al primer elemento enfocable en el modal.

     

    Sin embargo, si el modal es más bien un mensaje de error o alerta que requiere que el usuario ingrese algo antes de continuar, entonces utilícelo role=“alertdialog”en su lugar. Nuevamente, establezca el foco automáticamente con JavaScript y limite el foco al modal hasta que se tomen medidas.

    etiqueta-aria

    Utilice el atributo aria-labelo aria-labelledbyjunto con role=“dialog”. Si su ventana modal tiene un encabezado, puede usar el aria-labelledbyatributo para señalarlo haciendo referencia al ID del encabezado. Si su modal no tiene un encabezado por algún motivo, al menos puede usarlo aria-labelpara proporcionar una etiqueta concisa sobre el elemento que los lectores de pantalla pueden analizar.

    ¿Qué pasa con el elemento de diálogo de HTML5?

    Chrome 37 beta y Firefox Nightly 34.0a1 admiten el dialogelemento, que proporciona información semántica y de accesibilidad adicional para ventanas modales. Una vez que se establezca este elemento nativo dialog, no necesitaremos aplicarlo role=“dialog”a elementos que no sean de diálogo. Por ahora, incluso si estás usando un polyfill para el dialogelemento, úsalo también role=“dialog”para que los lectores de pantalla sepan cómo manejar el elemento.

    Lo interesante de este elemento no es solo que cumple la función semántica de un diálogo, sino que viene con sus propios métodos, que reemplazarán el JavaScript y CSS que necesitamos escribir actualmente.

    Por ejemplo, para mostrar o cerrar un cuadro de diálogo, escribiríamos esta base de JavaScript:

    var modal = document.getElementById('myModal'), openModal = document.getElementById('push_button redOpen'), closeModal = document.getElementById('push_button redClose');// to show our modalopenModal.addEventListener( 'click', function( e ) { modal.show(); // or modal.showModal();});// to close our modalcloseModal.addEventListener( 'click', function( e ) { modal.close();});

    El show()método inicia el cuadro de diálogo y al mismo tiempo permite a los usuarios interactuar con otros elementos de la página. El showModal()método inicia el cuadro de diálogo y evita que los usuarios interactúen con cualquier cosa que no sea el modal mientras está abierto.

    El dialogelemento también tiene la openpropiedad, establecida en trueo false, que reemplaza aria-hidden. Y tiene su propio ::backdroppseudoelemento, que nos permite darle estilo al modal cuando se abre con el showModal()método.

    Hay más que aprender sobre el dialogelemento de lo que se menciona aquí. Puede que no esté listo para el horario de máxima audiencia, pero una vez que lo esté, este elemento semántico contribuirá en gran medida a ayudarnos a desarrollar experiencias accesibles y utilizables.

    ¿A dónde ir desde aquí?

    Ya sea que utilice un complemento jQuery o una solución propia, dé un paso atrás y evalúe la usabilidad y accesibilidad general de su modal. Por más menores que sean los modales para la web en general, son lo suficientemente comunes como para que si todos intentáramos hacerlos más amigables y accesibles, haríamos de la web un lugar mejor.

    He preparado una demostración de una ventana modal que implementa todas las funciones de accesibilidad que se tratan en este artículo.

    Otras lecturas

    • Ventanas modales en diseño web moderno
    • Nuevos enfoques para diseñar formularios de inicio de sesión
    • Técnicas innovadoras para simplificar los registros y los inicios de sesión
    • Mejor diseño de interfaz: inicios de sesión, menús y otros módulos sofisticados

    (hp, il, al, ml, mrn)Explora más en

    • Accesibilidad
    • javascript
    • experiencia de usuario
    • Semántica





    Tal vez te puede interesar:

    1. ¿Deberían abrirse los enlaces en ventanas nuevas?
    2. 24 excelentes tutoriales de AJAX
    3. 70 técnicas nuevas y útiles de AJAX y JavaScript
    4. Más de 45 excelentes recursos y repositorios de fragmentos de código

    Cómo mejorar las ventanas modales para todos

    Cómo mejorar las ventanas modales para todos

    Implemente rápidamente. Implementar inteligentemente Smart Interface Design Patterns, 10h video + UX training Índice

    programar

    es

    https://aprendeprogramando.es/static/images/programar-como-mejorar-las-ventanas-modales-para-todos-872-0.jpg

    2024-05-20

     

    Cómo mejorar las ventanas modales para todos
    Cómo mejorar las ventanas modales para todos

    Si crees que alguno de los contenidos (texto, imagenes o multimedia) en esta página infringe tus derechos relativos a propiedad intelectual, marcas registradas o cualquier otro de tus derechos, por favor ponte en contacto con nosotros en el mail [email protected] y retiraremos este contenido inmediatamente

     

     

    Top 20