Consigna y alcance
Diseña un componente de contenido para kana japonés, Zhuyin de chino tradicional y Pinyin. ¿Cómo estructurarías el marcado ruby, admitirías anotaciones por capas, manejarías la búsqueda y copia, implementarías un fallback cuando CSS Ruby no esté disponible y evaluarías los riesgos para lectores de pantalla?
El W3C publicó el HTML Ruby Markup Extensions Candidate Recommendation Snapshot el 4 de junio de 2026. Este documento revisa la estructura ruby de HTML, restaura rb y rtc como elementos conformes y define unidades semánticas para bases, anotaciones, contenedores y múltiples niveles de anotación. No es un componente de traducción y no resuelve todas las estrategias de lectura de voz para lectores de pantalla; separa el marcado semántico, el layout y el comportamiento de las tecnologías de asistencia.
Qué evalúa el entrevistador
El entrevistador busca un emparejamiento estructurado de base a anotación, una elección fundamentada entre marcado intercalado (interleaved) y tabular, y el uso de CSS Ruby Layout en lugar de colocar la pronunciación en imágenes. Cubre atributos de idioma, búsqueda y copia, fallback con rp, consistencia en SSR/hidratación, seguridad contra XSS y los límites de las pruebas con lectores de pantalla.
Preguntas de clarificación antes de responder
- ¿La fuente del contenido proporciona pares base/anotación, o el componente debe segmentarlos y generarlos?
- ¿Puede una misma base tener múltiples niveles de idioma o de anotación, como Zhuyin y Pinyin juntos?
- Si el layout Ruby no está disponible, ¿el producto debería mostrar paréntesis en línea, ocultar las anotaciones o preservar la estructura cruda?
- ¿Qué deben conservar la búsqueda, la copia al portapapeles y la síntesis de voz (text-to-speech)?
- ¿Los usuarios pueden enviar contenido? ¿Qué elementos HTML, atributos, URLs y reglas de CSP están permitidos?
Un marco de respuesta de 30 segundos
“Modelaría los rangos base, los rangos de anotación, los idiomas y la política de presentación, para luego emitir ruby, rb, rt, rtc y rp semánticos. El marcado intercalado maneja pares simples; los contenedores explícitos o el marcado tabular manejan anotaciones de múltiples caracteres y por capas sin depender del emparejamiento implícito. CSS controla la posición de Ruby y el estilo de fallback; rp proporciona contenido visible en línea cuando el layout de Ruby no está disponible. La búsqueda y la copia siguen la semántica del producto y se prueban en navegadores reales. La salida para lectores de pantalla se prueba en lugar de asumirse a partir de la especificación. El contenido del usuario se sanitiza antes de renderizarse.”
Análisis detallado paso a paso
1. Definir el modelo de datos de anotaciones
Cada segmento contiene un rango base, uno o más rangos de anotación, etiquetas de idioma y una política de presentación. El japonés puede usar kana; el chino tradicional puede usar Zhuyin o Pinyin latino. Una base puede tener múltiples niveles de rtc, pero el nivel predeterminado debe ser explícito. Mantén el modelo separado del renderizado para que las reglas de segmentación no se dispersen por los componentes.
2. Elegir el marcado semántico
ruby es el contenedor general, rb una unidad base, rt el texto de anotación, rtc un contenedor de anotaciones y rp la presentación de fallback. Los casos simples pueden usar unidades base implícitas, pero el emparejamiento complejo de múltiples caracteres debe usar rb explícito para que el DOM, el comportamiento de copia y el layout sigan siendo predecibles.
3. Manejar el emparejamiento de múltiples caracteres y por capas
El marcado intercalado funciona para anotaciones simples uno a uno. El marcado tabular enumera varias unidades rb seguidas de sus correspondientes unidades rt, lo que representa mejor las palabras compuestas y las lecturas por capas. Agrupa elementos rt consecutivos con rtc; establece lang en cada capa de idioma. No coloques la pronunciación real en pseudoelementos CSS porque la búsqueda, la copia y las tecnologías de asistencia no pueden verla de manera confiable.
<ruby lang="zh-TW">
<rb>美</rb><rtc><rt>ㄇㄟˇ</rt></rtc>
<rtc lang="zh-Latn"><rt>měi</rt></rtc>
</ruby>4. Usar CSS para una mejora progresiva del layout
HTML aporta la estructura; CSS Ruby Annotation Layout controla ruby-position, el tamaño de fuente, la altura de línea y la alineación. Los valores predeterminados deben evitar que las anotaciones cubran las bases y deben permitir el zoom del texto. Cuando el layout Ruby no esté disponible, rp puede mostrar paréntesis u otra señal en línea; no ocultes todo el texto de anotación con display: none.
5. Diseñar la búsqueda, la copia y la extracción
La especificación analiza la interacción con la búsqueda y la copia, pero las implementaciones aún requieren pruebas en navegadores reales. Define si la copia contiene la base, la base más la anotación o una exportación estructurada. La búsqueda debe encontrar tanto la base como la anotación sin perder palabras debido a que las anotaciones interrumpan el DOM. Los índices del servidor pueden almacenar campos estructurados; el cliente no debería inferir pares con una expresión regular sobre el HTML renderizado.
6. Evaluar la tecnología de asistencia y la internacionalización
Ruby puede ayudar a niños, hablantes no nativos y personas con dificultades de lectura, pero los lectores de pantalla pueden emplear distintas heurísticas. Establece valores de lang precisos, preserva un orden de texto significativo y prueba lectores de pantalla, navegación por teclado, zoom y alto contraste. No afirmes que la especificación resuelve la síntesis de voz; documenta las diferencias conocidas y los fallbacks.
7. Verificar la seguridad, el rendimiento y la compatibilidad
Sanitiza las bases y anotaciones provistas por los usuarios con una lista de elementos y atributos permitidos; rechaza scripts, atributos de eventos y URLs peligrosas. SSR y la hidratación deben compartir el mismo algoritmo de emparejamiento para evitar parpadeos en las anotaciones o la reordenación del texto. Usa nodos estructurados y renderizado incremental para documentos extensos, almacena en caché el modelo de datos en lugar de HTML no seguro y realiza pruebas con WPT y una matriz de navegadores.
Respuesta de muestra de alta calidad
Modelaría los rangos base, los niveles de anotación, los idiomas y la política de presentación antes de emitir marcado ruby semántico. Los pares simples pueden usar una estructura intercalada; las anotaciones de múltiples caracteres y por capas utilizan rb y rtc explícitos, con lang en cada capa de idioma. CSS Ruby Layout controla la posición, el tamaño y la altura de línea, mientras que rp proporciona un fallback en línea cuando el layout Ruby no está disponible. La copia toma por defecto el texto base, la búsqueda indexa tanto la base como la anotación y el comportamiento exacto se prueba en navegadores reales. Dado que la lectura de voz en tecnologías de asistencia no está completamente unificada por esta especificación, probaría lectores de pantalla, teclado, zoom y alto contraste, y documentaría las diferencias. La entrada se sanitiza, SSR y el cliente utilizan un único modelo de datos y algoritmo de emparejamiento, y WPT junto con una matriz de navegadores verifican la estructura, el layout, la búsqueda, la copia y la seguridad.
Errores comunes
- Mostrar la pronunciación únicamente con pseudoelementos CSS → la búsqueda y la tecnología de asistencia pierden el texto → usa marcado Ruby semántico.
- Codificar de forma rígida cada carácter como un nodo intercalado → las lecturas compuestas y por capas se vuelven frágiles → usa emparejamiento estructurado y
rtc. - Tratar
rpcomo puntuación visible obligatoria → los navegadores compatibles muestran contenido duplicado → muéstralo únicamente en la presentación de fallback. - Ignorar
lang→ la síntesis de voz y la selección de fuentes son incorrectas → etiqueta las capas base y de anotación con precisión. - Prometer un orden idéntico en lectores de pantalla → la especificación no define un comportamiento completo de TTS → prueba en dispositivos y documenta las diferencias.
- Renderizar directamente el HTML del usuario → es posible la inyección de scripts → sanitiza elementos, atributos y URLs.
Preguntas de seguimiento y respuestas
¿Cuándo deberías usar rb en lugar de una base implícita?
Las bases implícitas funcionan bien para anotaciones simples de una sola capa. Usa rb explícito para palabras compuestas, marcado tabular o aplicaciones que necesitan un DOM estable para el emparejamiento, la copia y la depuración.
¿Qué ocurre si una base tiene kana y romanización?
Utiliza múltiples capas rtc o un contenedor de anotaciones explícito y define lang en cada una. El producto debe elegir una capa predeterminada y una política de cambio; CSS no debería decidir la semántica.
¿Cuál es el fallback cuando el layout Ruby no está disponible?
Mantén la estructura del texto y utiliza rp para paréntesis o separadores en línea, de modo que la base y la anotación sigan siendo legibles. No ocultes el contenido ni lo reemplaces con una imagen no seleccionable.
¿Cómo defines el comportamiento de copia?
Elige texto base, base más anotación o exportación estructurada según los objetivos del producto y luego realiza pruebas en Chromium, Firefox, Safari y dispositivos móviles. El orden del DOM no es automáticamente la cadena de texto deseada por el usuario.
¿Cómo demuestras que las anotaciones siguen siendo accesibles?
Verifica las etiquetas de idioma, el orden de foco, el zoom, el funcionamiento con teclado y la salida en lectores de pantalla en los modos sin anotación, de una sola capa, multicapa y fallback. Publica las diferencias conocidas de las tecnologías de asistencia.