stringtranslate.com

Discusión de Wikipedia:Manual de estilo/Accesibilidad

Accesibilidad de las tablas desplazables. Plantilla diferente

Graham87 . En esta discusión, Talk:COVID-19 epidemic deaths/Archive 1#Scrolling versus expanding tables , señalaste que las tablas desplazables del artículo relacionado ( COVID-19 epidemic deaths ) no eran un problema. Dijiste: "no afecta a los usuarios de lectores de pantalla totalmente ciegos". Se trataba de un conjunto particular de tablas desplazables que se analizan aquí:

Quiero saber si esto también es cierto para las tablas de desplazamiento (de una plantilla diferente) en esta versión de un artículo de lista con 3 tablas de desplazamiento:

Este método para desplazarse por las tablas se analiza aquí:

-- Timeshifter ( discusión ) 14:22 6 jul 2024 (UTC) [ responder ]

@ Timeshifter : En general, funcionan bien aquí. La única excepción es JAWS en Chrome, pero creo que es un problema de JAWS y no de las tablas en sí... la combinación de JAWS y Chrome está teniendo problemas con todo tipo de tablas en este momento. Graham87 ( discusión ) 14:32, 6 de julio de 2024 (UTC) [ responder ]
Todos los encabezados fijos usan CSS puro. Para los usuarios de lectores de pantalla debería funcionar bien por eso. En todo caso, es más probable que sea un problema para personas con ceguera parcial o para usuarios mayores, etc., ya que la posición del elemento cambia, lo que puede resultar confuso para algunos. También puedo imaginar que el desplazador vertical de altura máxima puede ser un pequeño problema para los usuarios de lectores de pantalla en teléfonos móviles, ya que tener un desplazador vertical dentro de un desplazador vertical puede resultar confuso para el descubrimiento, pero mientras no haya controles dentro del desplazador vertical, eso también parece poco probable que cause un problema. — The DJ ( discusión • contribuciones ) 08:15, 8 de julio de 2024 (UTC) [ responder ]

Colapso en el móvil

Tenga en cuenta que las versiones móviles del sitio web no admiten el colapso, por lo que cualquier contenido colapsable se desplegará automáticamente.

Parece que esto está desactualizado; funciona bien en mi teléfono o cuando pruebo la vista previa móvil en mi computadora. Lo eliminaré por ahora, pero avísenme si alguien se opone. Cerrado Limelike Curves ( discusión ) 19:13, 27 de julio de 2024 (UTC) [ responder ]

Texto alternativo para imágenes

Estimados lectores de Wikipedia con discapacidad visual: A veces añado texto alternativo a las imágenes para facilitar la accesibilidad. Intento ser lo más conciso posible y, al mismo tiempo, lo más correcto posible. Este último objetivo tiende a hacer que las descripciones sean más largas, pero trato de mantenerlas por debajo de las 250 palabras. Menciono el color porque creo que es importante, incluso si algunos de nuestros lectores con discapacidad visual han sido ciegos desde su nacimiento. No tengo discapacidad visual y no uso lectores de pantalla. La razón por la que escribo es para pedir sugerencias sobre cosas que se deben evitar al escribir texto alternativo. Cosas que te molestan en el texto alternativo y que desearías que los escritores no hicieran. De esa manera, podría entender mejor las cosas desde la perspectiva de una persona que usa texto alternativo. Por cierto, también comencé a usar generadores de imágenes de IA para ver qué tan bien mis descripciones pueden duplicar la imagen. Es un experimento interesante y los resultados sugieren que una imagen requiere mucho más que mil palabras para describirla, como se dice comúnmente. Sin embargo, la mayoría de las veces las descripciones son aproximaciones razonables. Jason Quinn ( discusión ) 10:21 13 ago 2024 (UTC) [ responder ]

@ Jason Quinn : Muchas gracias por esto. Como soy una persona totalmente ciega de nacimiento, no se me ocurre nada que añadir, pero me resulta difícil evaluar el texto alternativo porque no sé qué me estoy perdiendo; consulta mis comentarios en esta discusión . Graham87 ( discusión ) 15:30, 13 de agosto de 2024 (UTC) [ responder ]

Texto alternativo para iconos en plantillas

¿Cómo debería una plantilla manejar el texto alternativo de un ícono, si el ícono se puede cambiar? Algunas plantillas necesitan |alt=parámetros para imágenes seleccionables, pero ¿qué sucede con una plantilla en la que la imagen debe ser puramente decorativa? ¿Debería tener un |alt=parámetro o debería usar el mismo texto alternativo de manera constante?

Estoy preguntando sobre las mejores prácticas generales, pero vincularé ejemplos que trajeron esto a colación. {{ Archive }} tiene un pequeño ícono de archivador, pero esto se puede cambiar por cualquier cosa. Se agregaron un parámetro alt y un parámetro de enlace después de esta solicitud de edición: Plantilla discusión:Archivos/Archivo 1#Mejora de accesibilidad para image . Sin embargo, estoy pensando que probablemente sería más sencillo tener siempre el texto alternativo algo como "ícono de archivador". He buscado en páginas que hacen uso del parámetro "alt". Rara vez se usa y cuando se usa, generalmente es "Ícono de un archivador". He enumerado varios ejemplos de su uso a continuación.

¿Parámetro útil o texto alternativo estandarizado más sencillo de usar independientemente de la imagen del ícono? Rjj iii ( discusión ) 20:51, 23 de agosto de 2024 (UTC) [ responder ]

Sí, me parece sensato poner el texto alternativo "Icono de archivado". Graham87 ( discusión ) 04:04 24 ago 2024 (UTC) [ responder ]
Según los expertos en accesibilidad, las imágenes puramente decorativas no deberían tener enlaces ni texto alternativo desde siempre. ¿Cuál es el problema con esa opción? Izno ( discusión ) 04:10 7 sep 2024 (UTC) [ responder ]
Si la plantilla permite elegir la imagen en la página donde se utiliza, un editor puede elegir una imagen que no sea de dominio público o que no esté disponible bajo una licencia equivalente. Todas las imágenes de Creative Commons deben vincularse a la página con su información de atribución. Rjj iii ( discusión ) 04:33 7 sep 2024 (UTC) [ responder ]
Los parámetros |alt=y |link=no están relacionados; el valor de uno no afecta el significado del otro. Establecer |link=una cadena vacía puede ser un problema. Si el uso de la imagen requiere atribución (esto incluye, pero no se limita a, las licencias CC BY y CC BY-SA ), debemos poder llegar a la página de descripción del archivo para que se pueda ver la atribución. De hecho, WP:EIS#Link dice: A excepción de las imágenes de dominio público, siempre debe ser posible para el lector llegar a la página de descripción de la imagen, por lo que |link=debe usarse solo con |thumbimágenes. Establecer |alt=una cadena vacía no viola, por sí mismo, ninguna política, por lo que es un problema mucho menor. Pero si Graham87 sugiere |alt=Archiving icon, lo aceptaría al 100%. -- Red rose64 🌹 ( discusión ) 09:16, 7 de septiembre de 2024 (UTC) [ responder ]
Por lo general, ya habría un encabezado o una descripción de texto que transmitiera la misma información. En ese caso, tener un texto alternativo en la imagen decorativa que replique el texto es superfluo. isaacl ( discusión ) 15:43 7 sep 2024 (UTC) [ responder ]
Si la imagen de una plantilla como esta necesita un enlace para su atribución, sería mejor que hubiera un texto alternativo en la imagen (a pesar de su ligera redundancia). Graham87 ( discusión ) 09:10 8 sep 2024 (UTC) [ responder ]

Discusión enWP:HD § Pregunta de accesibilidad

 Estás invitado a unirte a la discusión en WP:HD § Pregunta de accesibilidad . -- Marchjuly ( discusión ) 07:40, 28 de agosto de 2024 (UTC) [ responder ]

Skin móvil y citas en bloque

A los observadores de la página les puede interesar la discusión de Wikipedia:Manual de estilo § Diseño de móviles y citas en bloque . No dudes en participar allí. Izno ( discusión ) 04:07 7 sep 2024 (UTC) [ responder ]

WP:NOBRnotas

¿Existen usos aceptables para el salto de línea HTML <br/>? En una edición reciente mía , sustituí una plantilla {{ ubl }} en el salto de línea HTML, ya que no se estaba utilizando para una lista sino como un salto visual para el tamaño predeterminado, separando el título de la serie del año en una tabla, para lograr armonía visual.

He visto este tipo de interrupción visual en muchos artículos que he editado, especialmente en los menos cuidados, pero ¿cómo se debe manejar? ¿Se desaconseja por completo, incluso para casos de uso en los que no hay ningún factor legítimo que no sea la estética o qué hacer en su lugar? Juwan ( discusión ) 12:21 19 sep 2024 (UTC) [ responder ]

No quiero hacerme eco de mi propio eslogan, pero, en esencia, tal y como yo lo entiendo, break significa pausa . Es decir, los saltos de línea son aceptables cuando realmente representan saltos semánticos en el contenido, quizás aproximadamente equivalentes a un salto de párrafo. No deberían utilizarse para crear la apariencia de listas ni para ajustar manualmente un único bloque de texto, pero más allá de eso, en realidad hay muchas aplicaciones plausibles. Las propias plantillas de Infobox los utilizan mucho en secreto. Remsense  ‥ 论12:24, 19 de septiembre de 2024 (UTC) [ responder ]
¡Ah, ese es un ensayo realmente genial! Si crees que es apropiado, por favor, incluye el enlace en la sección. Es exactamente lo que estaba buscando. Juwan ( discusión ) 12:49 19 sep 2024 (UTC) [ responder ]
Por el momento, está incompleto y me gusta la idea de que otros vinculen esas cosas en lugar de mí si les resulta útil, de modo que solo se vinculen cosas útiles, así que si crees que ayudaría a otros, ¡hazlo! Remsense  ‥ 论12:56, 19 de septiembre de 2024 (UTC) [ responder ]
Los saltos de línea son solo para mejorar la apariencia visual y, por lo tanto, semánticamente son equivalentes a los espacios en blanco. Se debe utilizar el marcado semántico apropiado según corresponda. Los saltos de línea se deben utilizar con moderación. A medida que cambia el ancho del navegador o se agregan otros elementos a la página, los navegadores automáticamente diseñarán la página de manera diferente y las modificaciones manuales pueden funcionar en contra de este proceso y producir un resultado agradable. isaacl ( discusión ) 18:40, 19 de septiembre de 2024 (UTC) [ responder ]

Dónde colocar las plantillas de accesibilidad en las plantillas de problemas

La sección sobre el color sugiere colocar la plantilla {{ Overcolored }} en la parte superior de los artículos con problemas de contraste. ¿Qué pasa con las plantillas? Por ejemplo, la plantilla {{ Transporte en la Ciudad de México }} tiene problemas importantes con el contraste. Pero si coloco la plantilla en la parte superior de la propia plantilla, aparecerá en docenas de páginas, lo que sería disruptivo. Terminé colocándola en la página de discusión de la plantilla Transporte en la Ciudad de México en la parte superior de mi tema.

Sería bueno aclarar esto en el texto sobre dónde se colocaría mejor en las plantillas.

Thisisnotatest ( discusión ) 06:14 26 sep 2024 (UTC) [ responder ]

También lo pondría en la página de documentación. Si no hay una categoría de mantenimiento para plantillas con problemas de accesibilidad, ¡quizás se debería crear y completar! Personalmente, lo agradecería. Remsense  ‥ 论07:04, 26 de septiembre de 2024 (UTC) [ responder ]
Colóquelo en la plantilla, ya sea en la documentación o, si no lo tiene, en la parte inferior entre las etiquetas noinclude. Gonnym ( discusión ) 08:31 26 sep 2024 (UTC) [ responder ]
¡Gracias! Lo he movido a la documentación de la plantilla y lo he añadido a una plantilla relacionada. Eso es lo que haré en el futuro. Thisisnotatest ( discusión ) 07:21, 27 de septiembre de 2024 (UTC) [ responder ]

GIF en bucle y accesibilidad

Mi edición Animaciones: Se aclararon los 5 segundos como tiempo total de reproducción y Remsense los revirtió con el comentario "Esto me resulta confuso: ¿los GIF en bucle simplemente no están permitidos?"

En lugar de correr el riesgo de entrar en una guerra de ediciones, voy a trasladar el asunto aquí para intentar llegar a un consenso sobre la redacción antes de proponer una edición final.

WCAG 2.1 proporciona la Técnica G152: Configurar imágenes gif animadas para que dejen de parpadear después de n ciclos (dentro de 5 segundos)

Se permiten los GIF en bucle siempre que dejen de repetirse de forma que el tiempo total de animación sea de 5,0 segundos o menos. Por lo tanto:

Espero que esto quede claro (lo cual creo que la redacción actual de la página no logra).

Thisisnotatest ( discusión ) 07:11 27 sep 2024 (UTC) [ responder ]

Basta decir que esto requiere una conversación, ya que casi nadie actúa basándose en este entendimiento, incluso si está bien fundamentado. Remsense  ‥ 论07:13, 27 de septiembre de 2024 (UTC) [ responder ]
Por lo que tengo entendido (y soy muy poco lector de literatura, así que esto es en parte anecdótico, así que perdónenme), hay una distinción significativa en la accesibilidad entre las animaciones cortas que se repiten y las animaciones largas. SC 2.2.2: Pausar, Detener, Ocultar dice
La oración operativa utiliza la palabra "parpadeo" de una manera que me parece un poco vaga: intuiría alguna distinción que muchas personas percibirían entre "parpadeo", simplemente "bucle", y contenido animado "en curso" en términos de su potencial para interferir con su capacidad para concentrarse o leer cómodamente. Más adelante, "parpadeo" se define como "contenido que causa un problema de distracción", lo que lamentablemente es un poco circular para nuestros propósitos. Si parpadear es coterminoso con moverse, ¿por qué no se usa moverse? Remsense  ‥ 论07:22, 27 de septiembre de 2024 (UTC) [ responder ]
Según entendí en el momento en que el elemento HTML BLINK quedó obsoleto por primera vez, se debe a que ciertas frecuencias de parpadeo pueden provocar convulsiones. Nunca escuché que una animación en bucle hiciera eso, a menos que la animación sea esencialmente dos imágenes que se muestran de manera alternada. -- Red rose64 🌹 ( discusión ) 08:20, 27 de septiembre de 2024 (UTC) [ responder ]
No solo dice parpadear, también dice moverse o desplazarse. El área de preocupación es "La intención de este criterio de éxito es evitar distraer a los usuarios durante su interacción con una página web". Las animaciones de formato largo deben realizarse a través de un video que se pueda pausar en lugar de un GIF animado incontrolable. Thisisnotatest ( discusión ) 09:57, 27 de septiembre de 2024 (UTC) [ responder ]
Estoy tratando de entender completamente qué dice el artículo 2.2.2 del Código Civil y por qué. En concreto, dice:
  • El contenido que se mueve o se actualiza automáticamente puede ser un obstáculo para quienes tienen problemas para leer texto estático rápidamente, así como para quienes tienen problemas para seguir objetos en movimiento. También puede causar problemas a los lectores de pantalla.
  • El contenido en movimiento también puede ser una distracción grave para algunas personas. Algunos grupos, en particular aquellos con trastornos de déficit de atención, encuentran que el contenido parpadeante los distrae, lo que les dificulta concentrarse en otras partes de la página web.
El primer punto se refiere al contenido en movimiento en general y no se aplica realmente a nuestra conversación sobre GIF en bucle en particular. El segundo aborda específicamente el contenido parpadeante , que es la distinción que actualmente no tengo clara. Remsense  ‥ 论10:04, 27 de septiembre de 2024 (UTC) [ responder ]
Me parece extraño que parezcan centrarse tanto en parpadear. El problema es que si algo en mi pantalla se anima cuando intento leer otro contenido en la página, entonces tendré dificultades para concentrarme en ese otro contenido. No importa si el contenido animado parpadea o muestra cómo funciona una plataforma petrolífera. Si no tengo forma de detenerlo, no puedo concentrarme en el contenido en el que estoy interesado.
He visto informes de pruebas de usabilidad en las que la gente levanta la mano para ocultar la animación imparable, y yo también lo he hecho. Eso supone que una persona sin discapacidad puede mantener la mano en alto durante un período prolongado de tiempo; alguien con problemas de atención y discapacidad de movilidad del brazo no tendría esa solución. Aún así, distraería parte de su atención (o la mía) de intentar absorber el contenido de interés. Y está haciendo que el visitante del sitio se adapte al sitio en lugar de que el sitio se adapte al visitante. Espero que esto lo deje claro. Thisisnotatest ( discusión ) 23:51, 29 de septiembre de 2024 (UTC) [ responder ]
Por supuesto. Como admití, mi comprensión previa se basaba parcialmente en mi propia experiencia anecdótica, en la que solo puedo recordar a personas de mi vida que me hablaron de una incapacidad para concentrarse en medio de estímulos que yo habría caracterizado como "parpadeo" o "continuo" anteriormente, en lugar de "bucle". Por supuesto, no dudo en absoluto de que el problema también cubriera esa área; simplemente había una pregunta lo suficientemente clara en mi mente como para que me pareciera apropiado hacerla explícita.
Pregunta general que puedo publicar en WP:VPT : ¿qué viabilidad habría en crear una herramienta que pueda ayudarnos a lograr esta tarea? Parecería requerir la transcodificación de cada GIF en una página activa a un video; no hay ninguna ventaja real en usar GIF, ¿verdad? Remsense  ‥ 论23:58, 29 de septiembre de 2024 (UTC) [ responder ]

¿Necesitamos nombrar los colores del equipo y del tránsito debajo del color?

He observado muchos problemas en Wikipedia en los que el texto tiene problemas de contraste porque alguien ha duplicado los colores de los equipos o de las rutas de transporte. ¿Queremos mencionar específicamente que el uso de los colores de los equipos y del transporte público para el texto no está exento de cumplir con los requisitos de contraste y que la accesibilidad tiene prioridad sobre la marca sin logotipo?

Ejemplo de equipo

Los Geelong West Giants utilizan mucho texto blanco sobre un fondo naranja. El texto o los fondos naranjas son particularmente problemáticos porque el blanco sobre naranja no supera la prueba de contraste WCAG 2.x, pero algunas personas consideran que el naranja sobre negro es más difícil de leer. El logotipo no necesita cumplir con el contraste, pero el texto sí. La mejor práctica probablemente sería abandonar el fondo naranja.
El color #FFFFFF (blanco) en #F15C22 (naranja) tiene un contraste de 3,33:1, lo que falla para texto más pequeño que 18,66 px en negrita o 24 px no en negrita.

Ejemplo de tránsito

{{ Transporte en la Ciudad de México }} temas de colores por ruta y modo. Varias de las rutas utilizan un contraste insuficiente, como la línea 1 del Cablebús , que tiene blanco sobre azul claro, lo que viola el contraste en todos los tamaños.
El color #FFFFFF (blanco) en #4EC3E0 (azul claro) tiene un contraste de 2.05:1, lo que falla para texto en todos los tamaños. Este problema es complicado porque el ícono lo proporciona el gobierno de la Ciudad de México, pero la licencia permite modificaciones, como hacer que el "1" sea negro en lugar de blanco (cambiando fill="#FFFFFF"a fill="#000000"en el código SVG). Pero podría ser más simple y menos molesto usar texto real en lugar de una imagen SVG.

Thisisnotatest ( discusión ) 21:24 27 sep 2024 (UTC) [ responder ]

Estos colores siempre han sido horribles, y no solo por cuestiones de accesibilidad. Mira la plantilla:Geelong Football League , el hipervínculo en el título está completamente oculto. Gonnym ( discusión ) 21:32 27 sep 2024 (UTC) [ responder ]
Hace muchos años, el WikiProject de hockey sobre hielo pasó a utilizar bordes de color en lugar de fondos de color para mejorar la accesibilidad (incluida la legibilidad). Véase Template:Montreal Canadiens para ver un ejemplo. (A algunos editores de hockey sobre hielo no les gusta cómo se ve, mientras que a otros sí, pero el consenso se ha mantenido). Creo que este enfoque es un equilibrio razonable entre los objetivos de diseño visual y debería considerarse para otros escenarios similares. isaacl ( discusión ) 16:22, 28 de septiembre de 2024 (UTC) [ responder ]
No le veo el sentido. Es una digresión. Supongo que la gente que lo hace cree que añade un factor de genialidad, pero esto no es TikTok. No estamos aquí para ser geniales, sino para informar, y la genialidad es una distracción.
Cuando tenemos una lista de nombres de frutas, no precedemos cada una de ellas con un icono que represente la fruta. Las listas de tipos de letra (gracias a las fuerzas que existen) no muestran el nombre de cada tipo de letra en esa tipografía. Pero algunas personas, cuando crean o ven una lista de países, sienten el impulso de anteponer a cada nombre la bandera del país, como si cada mención de un país mereciera otro recordatorio al lector de cómo es la bandera de ese país. Esta situación es la misma. Es una enciclopedia, no un catálogo de fuentes ni una revista deportiva ni una hoja de resultados. Identifique tipos de letra, países, rutas, equipos, etc., por su nombre, sin decoración. Y no solo los adornos de color no sirven para ningún propósito útil, sino que, como señalas, rompen la accesibilidad. Largoplazo ( discusión ) 17:13 28 sep 2024 (UTC) [ responder ]
Curiosamente, prefiero que la lista de tipos de letra muestre ejemplos de cómo se ve cada tipo de letra (y realmente creo que eso es informativo) que ver otra lista con la bandera de un país. Gonnym ( discusión ) 10:27 29 sep 2024 (UTC) [ responder ]
¿Cuál es entonces el camino a seguir en este sentido?
¿Cómo logramos un consenso para trasladar todas las plantillas deportivas al modelo de hockey sobre hielo? ¿Necesitamos un bot para realizar esta edición, dado que se trata de cientos de páginas? Además, parte de este estilo se ha trasladado a los encabezados de sección en el contenido editado manualmente, por ejemplo, los encabezados de tabla sobre Geelong West Giants .
¿Y cuál sería una solución para el transporte público? No tengo ningún problema en entrar, por ejemplo, en el metro de Nueva York y reemplazar todos los iconos con texto. (He comprobado el historial y no hay ninguna mención de "accesibilidad" o "contraste" en ninguna de las revisiones). Supongo que podría ser atrevido y ver qué pasa, pero sin un consejo específico aquí en Wikipedia:Manual de estilo/Accesibilidad, no creo tener el consejo concreto que me respalde. No quiero entrar en una guerra de ediciones.
Sugiero agregar el siguiente texto a Wikipedia:Manual de estilo/Accesibilidad :
No utilice logotipos ni colores temáticos en lugar de los enlaces de texto con colores predeterminados. Pueden impedir que las personas con baja visión que no utilizan lectores de pantalla puedan leer el enlace y pueden causar problemas de concentración a las personas con discapacidades cognitivas.
Thisisnotatest ( discusión ) 23:36 29 sep 2024 (UTC) [ responder ]

Además, cuando se utilizan colores de fondo que no sean blancos, puede interferir con la capacidad de ver si un subrayado de enlace indica que la página vinculada existe o no. De hecho, puede interferir con la capacidad de ver el subrayado del enlace en absoluto. Thisisnotatest ( discusión ) 04:58, 1 octubre 2024 (UTC) [ responder ]

También noto plantillas donde el texto de la barra de título está sobre un fondo degradado, donde uno de los colores de fondo tomaría texto blanco correctamente y el otro tomaría texto negro correctamente, lo que hace imposible elegir un color de texto accesible que funcione con ambos. Por ejemplo, {{ MARTA Red and Gold lines }} , {{ MARTA Blue and Green lines }} , y {{ Richmond station (California) }} . Thisisnotatest ( discusión ) 22:34 4 oct 2024 (UTC) [ responder ]