Tabs / Selector de Personas: Formato, Reglas y Ejemplos
Usa pestañas y selectores de personas para dirigir a los lectores hacia el contenido relevante manteniendo cada panel en el DOM, accesible, indexable y extraíble.
Un selector de pestañas/personas ofrece a varios lectores rutas distintas a través de un tema acotado sin enviarlos a páginas separadas. Las etiquetas identifican la ruta; seleccionar una revela su panel en la misma ubicación. El elemento solo es útil cuando los paneles son genuinamente equivalentes y cada panel permanece presente en el HTML inicial de la página.
Elige tu equipo
Convierte el brief en un borrador repetible
Comienza con la respuesta requerida, la evidencia y el conjunto de elementos. Redacta el razonamiento completo antes de aplicar componentes, luego verifica que cada afirmación siga teniendo sentido cuando se extrae de su tratamiento visual.
Verifica el descubrimiento y la extracción
Inspecciona el HTML renderizado, los enlaces internos, los encabezados y los campos estructurados. Confirma que el contenido de los paneles inactivos llegue en la primera respuesta en lugar de aparecer solo después de una interacción del lado del cliente.
Revisa el sistema, no solo la página
Aprueba la promesa común una vez, luego revisa dónde cada audiencia necesita realmente pruebas, flujo de trabajo o siguiente acción diferentes. Elimina las diferencias que son solo cambios de tono.
El estado renderizado muestra un panel activo, pero los otros dos paneles también están en el modelo de objetos del documento (DOM), la representación estructurada de la página en el navegador. Están ocultos con el atributo nativo hidden, no se solicitan después de un clic. Un motor de renderizado en producción añade el comportamiento de teclado y puntero descrito a continuación; el contrato de contenido creado permanece igual en todas las plataformas.
Por qué es importante este elemento
Los lectores filtran una página según su rol, objetivo y nivel de responsabilidad. Un especialista en contenido puede querer instrucciones de redacción, un especialista en SEO puede querer reglas de validación y un líder de equipo puede querer pautas de gobierno. Un selector de personas bien etiquetado reduce el esfuerzo de traducir consejos genéricos a «¿qué significa esto para mí?». También mantiene la premisa compartida en un solo lugar, lo que evita que tres páginas casi duplicadas compitan por la misma intención.
La ventaja psicológica es el reconocimiento sobre la interpretación. Un lector puede reconocer una etiqueta como «Equipos SEO» más rápido que escanear tres párrafos para inferir cuál le corresponde. Las pestañas también preservan el contexto espacial: el panel cambia en el mismo lugar, por lo que el lector puede comparar rutas equivalentes sin desplazarse repetidamente más allá de la introducción compartida.
Esa conveniencia crea una compensación en la extractabilidad por parte de las máquinas. La extractabilidad por máquinas es la capacidad de un rastreador, índice de búsqueda, tecnología de asistencia o sistema de recuperación para aislar contenido preservando su tema y relaciones. Los encabezados y párrafos visibles aparecen en una secuencia de lectura obvia. Las pestañas introducen un estado de interacción: una es visible, varias no lo son, y el software debe conectar cada etiqueta de pestaña con el panel correcto. Una implementación débil deja solo el panel activo en el HTML, carga otros paneles después de un clic o repite encabezados genéricos como «Beneficios» sin el nombre de la persona. En cada caso, una máquina recibe menos contexto del que ve el lector.
Incluso una implementación correcta puede reducir la extractabilidad en comparación con las secciones ordinarias. Algunos sistemas priorizan el texto inicialmente visible, simplifican las relaciones interactivas u omiten contenido oculto de los extractos. Por lo tanto, las pestañas son una herramienta de enrutamiento de información, no una forma de ocultar respuestas esenciales. Coloca la respuesta compartida, definición, advertencia, condición de elegibilidad y conclusión fuera del conjunto de pestañas. Usa los paneles para aplicaciones, ejemplos, flujos de trabajo o pruebas específicos de la audiencia que sigan siendo útiles después de conocer la respuesta común.
Aplica las reglas de escritura de elementos : redacta primero la explicación completa, luego clasifica un conjunto genuino de rutas de lectura equivalentes como este elemento tipificado. Las reglas de esta página tienen prioridad para el mapeo de paneles, la interacción y los límites de contenido.
Cuándo usarlo
Usa un selector de pestañas/personas cuando se cumplan todas estas condiciones:
- De dos a cinco audiencias, contextos o modos reconocibles necesitan diferentes aplicaciones del mismo tema.
- Cada panel responde a la misma pregunta con una profundidad comparable.
- La mayoría de los lectores necesitan un panel a la vez, mientras que una minoría puede comparar dos o más.
- La respuesta común puede expresarse fuera del elemento sin obligar al lector a abrir cada pestaña.
- Mantener las rutas en una página es más claro que mantener páginas separadas con introducciones en gran medida duplicadas.
Los usos sólidos incluyen orientación de implementación para «Desarrolladores / Editores / Revisores», rutas de incorporación para «Solo / Equipo / Agencia» y una capacidad explicada a través de «Planificar / Producir / Medir». Las etiquetas de persona deben reflejar diferencias significativas en el flujo de trabajo, la evidencia, los permisos o el resultado deseado, no suposiciones demográficas.
Los casos límite a menudo provienen de intentar acortar una página. No pongas pasos secuenciales en pestañas; ocultar el paso dos hasta que el lector lo seleccione destruye el orden del procedimiento. No pongas en pestañas una lista corta de definiciones, porque los encabezados ordinarios exponen la misma información con menos interacción. No uses pestañas para una comparación detallada de funcionalidades: una tabla comparativa mantiene los criterios simultáneamente visibles. No uses pestañas como navegación entre temas no relacionados y no dividas la información simplemente porque la página parece larga.
Un acordeón es más adecuado cuando las secciones son preguntas independientes en un flujo de lectura vertical o cuando varias respuestas deben permanecer abiertas. Las páginas separadas son mejores cuando cada audiencia necesita una intención de búsqueda, título, conjunto de evidencias, ruta de conversión o más de aproximadamente 300 palabras de contenido único. Si un lector necesita todos los paneles para actuar de forma segura o correcta, las pestañas son el componente equivocado.
Dónde colocarlo
Coloca el selector después de la respuesta compartida y del párrafo que explica por qué las rutas difieren. El lector debe entender el tema común antes de elegir una etiqueta. En una página de producto o solución, eso suele ser después de la propuesta de valor central y la explicación de la capacidad compartida, pero antes de las pruebas detalladas y la acción de cierre principal. En la documentación, colócalo inmediatamente antes de las instrucciones específicas del rol que controla.
No coloques un conjunto de pestañas antes de la respuesta directa, definición o advertencia obligatoria de la página. No lo coloques entre una afirmación y su fuente, entre un requisito previo y el procedimiento que rige, o entre un precio y sus condiciones. Esas relaciones deben sobrevivir incluso cuando ningún panel está seleccionado. Un conjunto de pestañas no puede colocarse junto a otro conjunto de pestañas, un acordeón, una cuadrícula de comparación grande o un carrusel; los modelos de interacción adyacentes crean controles en competencia y un orden de lectura poco claro.
Evita las pestañas anidadas. La opción externa oculta la opción interna, crea un comportamiento de teclado difícil y hace que el enlace profundo sea ambiguo. Evita también colocar un selector de personas inmediatamente encima de otro selector de audiencia en un formulario o CTA. Si ambos controles usan etiquetas similares, los lectores pueden no saber si están cambiando el contenido visible o enviando una preferencia.
Anatomía
La anatomía tiene un contenedor etiquetado, una lista ordenada de pestañas y un panel para cada pestaña. La captura de pantalla debe mostrar los paneles inactivos en el inspector del DOM además del estado visible, porque la presencia en el código fuente es parte del elemento, no un detalle de implementación.
- Título compartido: Indica la pregunta o tarea común que aborda cada panel.
- Lista de pestañas: Agrupa de dos a cinco etiquetas equivalentes en un orden de creación estable.
- Etiqueta de pestaña: Nombra una audiencia, contexto o modo en un lenguaje que los lectores reconozcan.
- Estado seleccionado: Comunica la pestaña activa mediante semántica de texto y un tratamiento visual, no solo con color.
- Panel: Contiene un encabezado autocontenido y el contenido para una etiqueta.
- Relación programática:
aria-controlsen la pestaña yaria-labelledbyen el panel conectan cada par. - Orden de respaldo: Mantiene el título compartido, las etiquetas y todo el contenido del panel con sentido cuando los scripts o estilos no se ejecutan.
El espaciado, borde, forma del indicador, animación y punto de interrupción pertenecen al motor de renderizado. Los autores controlan las etiquetas, el orden en el código fuente, el contenido del panel y un identificador de fragmento estable opcional.
Ejemplos de diseño
El componente admite cuatro variantes. Cada variante usa el mismo modelo de contenido y requisito de DOM.
Pestañas de persona: Usa etiquetas de rol cuando los flujos de trabajo, las pruebas o las siguientes acciones difieran genuinamente según el lector. Prefiere el lenguaje establecido del cliente como «Equipos internos» sobre personas inventadas como «Gurús del crecimiento».
Pestañas de contexto: Usa estados que no sean de persona, como tamaño del equipo, modelo operativo o modo de implementación. El título compartido debe nombrar la dimensión cambiante para que las etiquetas no se confundan con navegación de página.
Pestañas verticales: Úsalas solo cuando las etiquetas necesiten más espacio horizontal y no haya más de cinco. El orden en el DOM y el teclado sigue siendo pestaña uno a pestaña cinco, seguidas de sus paneles asociados según la implementación accesible elegida.
Estado de ventana estrecha y de respaldo: Las etiquetas pueden desplazarse horizontalmente cuando una señal visual hace evidente el desbordamiento, o el motor de renderizado puede mostrar los paneles como secciones etiquetadas apiladas. No debe truncar las etiquetas en fragmentos ambiguos ni eliminar el contenido inactivo del HTML.
Parámetros
El contrato de contenido mantiene la relación explícita mientras deja el comportamiento visual y adaptable al motor de renderizado.
| Nombre | Tipo | Obligatorio | Mín./máx. | Valor predeterminado | Origen |
|---|---|---|---|---|---|
title | Cadena simple | Sí | 3–10 palabras; 80 caracteres como máximo | Ninguno | Primer encabezado en el cuerpo padre |
items | Colección ordenada | Sí | 2–5 elementos; 3–4 preferido | Ninguno | Cuerpos item anidados |
item.label | Cadena simple | Sí | 1–4 palabras; 28 caracteres como máximo | Ninguno | Atributo de elemento label |
item.title | Cadena simple | Sí | 3–10 palabras; 80 caracteres como máximo | Ninguno | Primer encabezado en cada cuerpo de elemento |
item.content | Markdown limitado | Sí | 40–180 palabras recomendado; 300 como máximo | Ninguno | Cuerpo del elemento después de su primer encabezado |
item.id | Token slug | No | 3–40 caracteres en minúscula, números y guiones | Generado desde item.label | Atributo de elemento id |
variant | Enumeración | No | horizontal o vertical | horizontal | Atributo padre |
default | ID de elemento | No | Debe coincidir con un ID de elemento | Primer elemento | Atributo padre |
Las etiquetas son atributos porque operan el control; los títulos de los paneles provienen del primer encabezado porque pertenecen al contenido. Ambos pueden ser similares, pero una etiqueta de pestaña concisa puede mapearse a un encabezado de panel más completo y extraíble. Los cuerpos de los paneles admiten párrafos, una lista corta, código en línea, una imagen y una acción contextual. No admiten otro conjunto de pestañas, acordeón, tabla de datos, formulario, reproductor de video o procedimiento de varios pasos.
Sintaxis y ejemplos de código
Las tres notaciones preservan un título, etiquetas ordenadas, encabezados de panel, cuerpos de panel, ID estables y el valor predeterminado inicial. La directiva Markdown portátil es la forma canónica de creación.
Directiva Markdown portátil
:::tabs-persona-switcher{default=content-teams variant=horizontal}
## Choose your team
::item{label="Content teams" id=content-teams}
### Turn the brief into a repeatable draft
Start with the required answer, evidence, and element set. Draft the reasoning in full before applying components.
::
::item{label="SEO teams" id=seo-teams}
### Verify discovery and extraction
Inspect the rendered HTML, internal links, headings, and structured fields. Confirm that every panel arrives in the initial response.
::
::item{label="Team leaders" id=team-leaders}
### Review the system, not just the page
Approve the shared promise once, then review where each audience genuinely needs a different workflow, proof point, or next action.
::
:::
El primer encabezado del cuerpo padre se asigna a title. Cada elemento anidado toma label e id de los atributos, asigna su primer encabezado a item.title y el resto a item.content.
Shortcode de Hugo
{{< tabs-persona-switcher title="Choose your team" default="content-teams" variant="horizontal" >}}
{{< tab-item label="Content teams" id="content-teams" title="Turn the brief into a repeatable draft" >}}
Start with the required answer, evidence, and element set. Draft the reasoning in full before applying components.
{{< /tab-item >}}
{{< tab-item label="SEO teams" id="seo-teams" title="Verify discovery and extraction" >}}
Inspect the rendered HTML, internal links, headings, and structured fields. Confirm that every panel arrives in the initial response.
{{< /tab-item >}}
{{< tab-item label="Team leaders" id="team-leaders" title="Review the system, not just the page" >}}
Approve the shared promise once, then review where each audience genuinely needs a different workflow, proof point, or next action.
{{< /tab-item >}}
{{< /tabs-persona-switcher >}}
El adaptador usa solo parámetros con nombre. Debe renderizar todos los cuerpos de los elementos durante la respuesta del servidor, rechazar ID duplicados e inicializar la interacción sin reescribir el modelo de contenido.
Bloque de WordPress
<!-- wp:amicited/tabs-persona-switcher {"title":"Choose your team","default":"content-teams","variant":"horizontal"} -->
<!-- wp:amicited/tab-item {"label":"Content teams","id":"content-teams","title":"Turn the brief into a repeatable draft"} -->
<p>Start with the required answer, evidence, and element set. Draft the reasoning in full before applying components.</p>
<!-- /wp:amicited/tab-item -->
<!-- wp:amicited/tab-item {"label":"SEO teams","id":"seo-teams","title":"Verify discovery and extraction"} -->
<p>Inspect the rendered HTML, internal links, headings, and structured fields. Confirm that every panel arrives in the initial response.</p>
<!-- /wp:amicited/tab-item -->
<!-- wp:amicited/tab-item {"label":"Team leaders","id":"team-leaders","title":"Review the system, not just the page"} -->
<p>Approve the shared promise once, then review where each audience genuinely needs a different workflow, proof point, or next action.</p>
<!-- /wp:amicited/tab-item -->
<!-- /wp:amicited/tabs-persona-switcher -->
WordPress debe limitar los bloques internos a elementos de pestaña registrados. La vista previa, el marcado guardado y la representación en el front-end deben conservar cada panel; la conveniencia del editor no debe convertir los elementos inactivos en contenido obtenido del lado del cliente.
Ejemplos
Ejemplo correcto
Elige una ruta de implementación
Plataforma alojada — Lanza sin mantener infraestructura
Conecta la fuente de datos aprobada, configura los roles y valida la salida en un espacio de trabajo de pruebas. El proveedor mantiene las actualizaciones y la supervisión del tiempo de ejecución; tu equipo es dueño de la aprobación del contenido y la revisión de accesos.
Autogestionado — Controla el despliegue y los límites de datos
Despliega el paquete compatible en tu entorno, conecta la misma fuente de datos aprobada y asigna un responsable para actualizaciones, supervisión, copias de seguridad y revisión de accesos.
Esto funciona porque ambos paneles responden a la misma pregunta de implementación, nombran la diferencia operativa y contienen responsabilidades comparables. «Plataforma alojada» y «Autogestionado» son etiquetas reconocibles. La decisión compartida sigue siendo clara si ambos paneles se aplastan en el orden del código fuente.
Ejemplo incorrecto
Explora todo
Resumen: Nuestra plataforma hace más efectivos a los equipos modernos.
Precios: Contacta con ventas para obtener un presupuesto personalizado y condiciones contractuales importantes.
Seguridad: Lee nuestra documentación de seguridad.
Carreras: Únete a nuestro equipo en crecimiento.
Esto es navegación del sitio disfrazada de pestañas. Los paneles no responden a una pregunta compartida, las etiquetas mezclan información del comprador con contenido corporativo y condiciones importantes de precios están ocultas tras una interacción. Reemplaza el conjunto con secciones de página ordinarias y navegación real. Si las opciones de precios necesitan evaluación simultánea, usa una estructura de precios o comparativa en lugar de pestañas.
Marcado de esquema y accesibilidad
Las pestañas y los selectores de personas no crean un tipo de Schema.org dedicado. Su contenido sigue siendo parte del Article, TechArticle, Product o WebPage contenedor cuando esa página califica de forma independiente. No marques las pestañas como ItemList simplemente porque se repiten, y no generes múltiples entidades Person a partir de etiquetas de persona. Una etiqueta como «Agencia» describe una ruta de lectura, no una afirmación de entidad factual.
Usa el patrón de pestañas WAI-ARIA solo cuando la interfaz realmente se comporte como pestañas. El contenedor tiene role="tablist"; cada control tiene role="tab", un ID único, aria-controls y un valor preciso de aria-selected; cada panel tiene role="tabpanel" y aria-labelledby. Usa botones para los controles, no enlaces con destinos falsos. La pestaña seleccionada pertenece al orden de tabulación de la página; las pestañas inactivas usan tabindex="-1" de tipo rotativo y siguen siendo accesibles con las teclas de flecha. Inicio y Fin se mueven a la primera y última pestaña. La activación puede seguir al foco solo cuando el cambio de panel es inmediato; de lo contrario, Enter o Barra espaciadora activan la pestaña enfocada.
El foco debe permanecer predecible. Seleccionar una pestaña no empuja el foco automáticamente a su panel. Un panel puede usar tabindex="0" cuando su primer contenido no es enfocable de otra manera, permitiendo a los usuarios de teclado moverse hacia él. Un indicador de foco visible y un indicador de selección deben diferir, y ninguno puede basarse solo en el color.
Todos los paneles deben renderizarse en la respuesta HTML inicial. Ocultar paneles inactivos con hidden, CSS o un equivalente mejorado progresivamente es aceptable; crearlos solo después de un clic no lo es. Sin JavaScript, la alternativa debe exponer cada panel etiquetado en el orden del código fuente o proporcionar enlaces reales a destinos renderizados en el servidor. Los fragmentos estables pueden activar un panel, pero la página canónica sigue siendo una URL. Prueba el zoom, las pantallas estrechas, las etiquetas traducidas largas, las relaciones con lectores de pantalla, el orden del teclado y el fallo de scripts.
Reglas de escritura
Comienza con la pregunta compartida. Si cada panel propuesto responde a una pregunta diferente, no uses pestañas. Escribe de dos a cinco elementos, siendo tres o cuatro lo preferible. Mantén las etiquetas de una a cuatro palabras y 28 caracteres cuando sea posible. Usa gramática paralela: todos los roles («Editores / Revisores»), todos los modos («Alojado / Autogestionado») o todas las etapas («Planificar / Producir / Medir»). No mezcles un rol, un verbo y una frase de marketing.
Proporciona a cada panel un encabezado de 3 a 10 palabras que nombre tanto la ruta relevante como su resultado cuando la etiqueta de la pestaña por sí sola sea insuficiente. Escribe de 40 a 180 palabras por panel, con 300 como máximo absoluto. Los paneles deben tener una profundidad comparable, pero no necesitan recuentos de palabras idénticos. Usa un lenguaje directo y diferencias concretas en tareas, evidencia, permisos, restricciones o acciones. Cambiar solo los pronombres de «tú» a «tu equipo» no justifica otro panel.
Mantén la información común fuera del elemento. Repetir la misma frase inicial en cada panel crea desviación de mantenimiento y hace que los pasajes extraídos parezcan duplicados. Coloca las diferencias dentro de los paneles y haz que cada diferencia sea lo suficientemente explícita para sobrevivir a la extracción. Prefiere «Los equipos de agencia pueden asignar roles a nivel de cliente» a «Tienes más control», que pierde su sujeto cuando se separa de la etiqueta seleccionada.
Nunca pongas esto dentro de un conjunto de pestañas:
- La única definición, respuesta directa, conclusión, advertencia de seguridad, condición legal, regla de elegibilidad o atribución de fuente de la página.
- Pasos secuenciales que todo lector debe completar, o requisitos previos que rigen contenido fuera de un panel.
- Otro conjunto de pestañas, acordeón, carrusel, tabla de datos compleja, formulario de varios campos o contenido multimedia con reproducción automática.
- Más de una llamada a la acción principal por panel, o acciones que conducen a etapas del embudo no relacionadas.
- Contenido cargado solo después de la interacción, incluso cuando el estado de carga sea rápido para un usuario humano.
- Etiquetas como «Otros», «Más», «General» o «Recursos» que ocultan una relación no definida.
Si cada panel supera las 300 palabras, necesita su propio conjunto de evidencias o se dirige a una intención de búsqueda diferente, publica secciones o páginas dedicadas. Si los lectores necesitan comparar varios criterios a la vez, usa una tabla. Si el contenido es simplemente un detalle opcional, usa prosa o un acordeón según la relación.
Tipos de publicación que lo usan
El campo postTypes del frontmatter es la fuente de esta tabla. La inclusión significa que el formato puede admitir pestañas; no las hace obligatorias.
| Tipo de publicación | Uso típico | Posición recomendada | Mal uso común |
|---|---|---|---|
| Guía definitiva | Aplicación específica por rol de un marco compartido | Después de explicar el marco en prosa visible | Ocultar capítulos necesarios para que una guía larga parezca más corta |
| Artículo de documentación | Instrucciones que difieren según el rol, entorno o modo compatible | Después de los requisitos previos compartidos y antes de las acciones específicas de la ruta | Poner pasos consecutivos en paneles separados |
| Página de producto | Resultados o flujos de trabajo para audiencias calificadas distintas | Después de la promesa y capacidad compartida del producto | Ocultar precio, términos o limitaciones en un panel inactivo |
| Página de funcionalidad | Una capacidad aplicada por diferentes equipos o modos de operación | Después de la explicación común de la funcionalidad | Repetir beneficios idénticos con nombres de persona intercambiados |
| Página de solución | Responsabilidades de diferentes partes interesadas dentro de una solución | Después del problema y el enfoque compartido | Mezclar industrias, puestos y recursos no relacionados en un solo control |
| Página de caso de uso | Rutas de ejecución para segmentos de audiencia que comparten el caso de uso | Después del resultado común y antes de las pruebas detalladas | Usar pestañas cuando cada audiencia necesita realmente una página de intención dedicada |
Lista de verificación de control de calidad
- Una pregunta compartida: Cada panel responde a la misma pregunta acotada para una audiencia, contexto o modo diferente.
- Cantidad adecuada: El conjunto contiene de dos a cinco pestañas, preferiblemente tres o cuatro, con etiquetas paralelas concisas.
- Respuesta común visible: La definición, respuesta central, condición obligatoria y conclusión permanecen fuera del conjunto de pestañas.
- Presencia en el DOM inicial: Cada panel y su contenido completo creado aparece en el HTML inicial renderizado por el servidor.
- Contexto explícito: Cada encabezado y frase inicial del panel siguen siendo comprensibles cuando se extraen sin el estado visual de la pestaña.
- Relaciones correctas: Los ID de pestañas y paneles son únicos;
aria-controlsyaria-labelledbylos emparejan correctamente. - Comportamiento de teclado: El comportamiento de Flecha, Inicio, Fin, Enter, Barra espaciadora, Tabulador y Mayús+Tabulador coincide con el modelo de activación elegido.
- Claridad del foco: El foco y la selección son visualmente distintos, y la selección no mueve el foco inesperadamente.
- Respaldo estable: El fallo de scripts expone contenido etiquetado o destinos utilizables renderizados por el servidor sin perder información.
- Comportamiento adaptable: Las etiquetas permanecen completas y detectables en anchos estrechos, zoom al 200% y con texto traducido más largo.
- Colocación segura: El componente no separa una afirmación de su evidencia, una advertencia de su alcance, ni los requisitos previos de las instrucciones.
- Sin anidamiento complejo: Los paneles contienen prosa acotada y contenido de apoyo simple, no otro sistema de interacción.
- Moderación del esquema: El motor de renderizado no inventa esquemas de lista, persona o audiencia a partir de etiquetas de presentación.
- Paridad de notación: Markdown, Hugo y WordPress preservan el mismo orden, ID, valor predeterminado, etiquetas, encabezados y cuerpos de panel.
Un revisor debe rechazar el componente cuando el contenido inactivo requiera una solicitud de red activada por clic, cuando información esencial exista solo dentro de un panel, o cuando las etiquetas no describan rutas equivalentes. Esos son fallos de contenido y arquitectura; el refinamiento visual no puede repararlos.
Preguntas frecuentes
Las entradas estructuradas de preguntas frecuentes en el frontmatter abordan la indexación, las URL con fragmentos, la cantidad de pestañas, las llamadas a la acción y la distinción entre pestañas y acordeones. Están intencionadamente fuera del elemento interactivo para que cada lector y motor de renderizado reciba la misma orientación de implementación.
Más tutoriales en esta sección
¿Listo para ponerlo en práctica?
Revisión gratuita · Prueba de 7 días · sin tarjeta de crédito