דלג לתוכן הראשי
Niquelao נגישות אינטרנט ופיתוח front-end: תקני WCAG, ווידג'טים נגישים ותוספים ל-Firefox, כולל הסברים עם קוד אמיתי.

חלק מהקישורים באתר זה הם קישורי שותפים: רכישה דרכם עשויה להניב לנו עמלה ללא עלות נוספת עבורכם. הדבר אינו משפיע על ההמלצות שלנו. לפרטים נוספים, עיינו בהצהרת השותפים שלנו. גילוי שותפים.

לחצן תפקיד ARIA: Guía Completa y Práctica

התפקיד role="button" הוא תפקיד ARIA שגורם לטכנולוגיות מסייעות להכריז על מיכל גנרי ככפתור, אך הוא אינו מספק התנהגות: יש להוסיף tabindex="0", לטפל במקשי Enter ורווח, ולשקף את המצב באמצעות aria-pressed או aria-disabled. מפרט WAI-ARIA 1.2 מגדיר תפקיד זה בתוך קטגוריית הווידג’טים, והכלל הראשון של ARIA ממליץ להשתמש ב-<button> מובנה בכל פעם שניתן.

התפקיד button שייך לטקסונומיית התפקידים של WAI-ARIA, התקן של W3C המתאר סמנטיקה נגישה עבור ממשקי אינטרנט. כאשר אלמנט מקבל role="button", עץ הנגישות שבונים קוראי המסך (NVDA, JAWS, VoiceOver, Narrator) מפסיק להציג אותו כ-div או span גנרי ומציג אותו כבקר שניתן להפעלה. ההבדל הוא עצום עבור מי שגולש עם קורא מסך: ללא התפקיד, המשתמש שומע “קבוצה” או פשוט טקסט; עם התפקיד, הוא שומע “כפתור” ויודע שהוא יכול להפעילו.

הבלבול הנפוץ הוא להאמין ש-role="button" הופך div לכפתור פונקציונלי. הוא לא עושה זאת. התפקיד משנה רק את הסמנטיקה המוכרזת; ההתנהגות — קבלת פוקוס, תגובה למקלדת, הפעלת הפעולה — נשארת באחריותו של המפתח. הפרדה זו בין סמנטיקה להתנהגות היא השורש של רוב השגיאות הנבצעות עם תפקיד זה.

WAI-ARIA פורסם כהמלצה של W3C וגרסה 1.2 היא הרפרנס הנוכחי לתפקידים, מצבים ומאפיינים. התפקיד button הוא אחד מתפקידי הווידג’ט הוותיקים והיציבים ביותר במפרט, שקיים כבר מ-ARIA 1.0.

מתי להשתמש ב-role=“button” ומתי לא

הכלל הראשון של ARIA, המופיע בפרקטיקות הכתיבה של WAI-ARIA (WAI-ARIA Authoring Practices), הוא נחרץ: אם קיים אלמנט HTML מובנה עם הסמנטיקה וההתנהגות שאתה צריך, השתמש בו. <button> ya trae el roll implícito, el foco por teclado, la activación con Enter y Espacio, y el estado deshabilitado. Reimplementar todo eso con el aria role role="button" es trabajo extra y fuente de bugs.

עם זאת, קיימים תרחישים לגיטימיים לתפקיד זה. El más común es cuando el marcado está condicionado por el framework o el CMS y no puedes introducir un <button> sin romper el layout o el JavaScript existente. מקרה אחר הוא של רכיבים שחייבים להתנהג ככפתור אך המבנה הפנימי שלהם מחייב מיכל ספציפי, כמו ווידג’טים מסוימים של צד שלישי.

קשורים: — עם תוכנית חינם עבור empezar hoy mismo.

תרחיש שלישי, שנוי במחלוקת יותר, הוא של אלמנטים שכבר יש להם תפקיד מובנה שונה והם צריכים להופיע ככפתור. כאן כדאי לשאול אם העיצוב לא כופה סמנטיקה שגויה. אם משהו נראה כמו כפתור אך למעשה מנווט לדף אחר, הנכון הוא להשתמש בקישור <a>, לא בכפתור.

סיטואציהפתרון מומלץסיבה
פעולה בטופס או ממשק<button> מובנהתפקיד, פוקוס ומקלדת כלולים
ניווט לכתובת URL אחרת<a href>סמנטיקה נכונה של קישור
מיכל שאינו ניתן לשינויrole="button" + מקלדת + מצביםהמקרה היחיד שבו התפקיד תורם
כפתור החלפה (on/off)<button aria-pressed>מצב שנחשף באופן מובנה
כפתור מושבת<button disabled>ניהול מצב ופוקוס

Cómo implementar un botón con role=“button” correctamente

Un botón basado en role="button" necesita cubrir cuatro frentes: foco, teclado, estado y nombre accesible. השמטה של אחד מהם תגרום לבקר ש”נראה” נגיש אך נכשל בבדיקות ממשיות.

El foco se habilita con tabindex="0", que inserta el elemento en el orden de tabulación natural. לעולם אל תשתמש ב-tabindex עם ערכים חיוביים: הם משנים את סדר הטאב של כל הדף ויוצרים קפיצות בלתי צפויות. El valor 0 es el correcto para elementos interactivos personalizados.

שווה להסתכל: — גישה לתנועה: משולבת אוטומטית עם רוויזיון אנושי.

El teclado requiere manejar dos teclas: Enter y Espacio. אם <כפתור> נגיב בשיחה, אך עם div עם תפקיד אחד של בוטון. Hay que escuchar keydown y ejecutar la acción cuando la tecla es Enter o Space, evitando además el desplazamiento de página que provoca Espacio por defecto. Este detalle se pasa por alto con frecuencia y deja botones que solo funcionan con ratón.

El estado se comunica contributos ARIA. Un botón de alternancia usa aria-pressed="true" o "false" para indicar si está activo. Un botón deshabilitado usa aria-disabled="true", que anuncia el estado pero no impide la interracción por sí solo: hay que bloquear la acción en el código. La diferencia entre aria-disabled y el atributo nativo disabled importa, porque el primero mantiene el elemento enfocable y el segundo lo saca del orden de tabulación.

El nombre accesible se construye con el texto visible del elemento o, si no hay texto, con aria-label o aria-labeledby. Un botón sin nombre accesible es un botón que el lector de pantalla anuncia como “botón” a secas, sin pista de qué hace.

<div
  role="button"
  tabindex="0"
  aria-pressed="false"
  id="btn-modo"
>
  מודו אוסקורו
</div>

<script>
  const btn = document.getElementById('btn-modo');
  function toggle() {
    const activo = btn.getAttribute('aria-pressed') === 'true';
    btn.setAttribute('aria-pressed', String(!activo));
  }
  btn.addEventListener('click', toggle);
  btn.addEventListener('keydown', (e) => {
    if (e.key === 'Enter' || e.key === ' ') {
      e.preventDefault();
      toggle();
    }
  });
</script>

הדוגמה הקדמית של קובייה קדמית. Es el minimo viable para que el control ים שמיש con lector de pantalla y teclado.

שגיאות תדירות y cómo detectarlos

El error más extendido es aplicar role="button" sin tabindex, lo que produce un botón inalcanzable por teclado. Las herramientas automáticas lo detectan como “elemento con rol interactivo no enfocable”, una de las violaciones más reportadas en auditorías de accesibilidad.

El segundo error es no gestionar el teclado. Un div con un aria role de botón y tabindex pero sin manejadores de tecla recibe foco y no response a Enter ni Espacio. El usuario de teclado queda atrapado: puede enfocar el botón pero no activarlo.

קשורים: — La certificación profesional que acredita tu experiencia en accesibilidad.

השגיאה הראשונה היא בשימוש role="button" sobre unenlace. Esto rompe la semántica de navegación y confunde a los lectores de pantalla, que anuncian “botón” cuando el usuario espera un enlace. Si el elemento navega, debe ser un enlace.

El cuarto error es olvidar el estado en botones de alternancia. Un botón que cambia entre dos modos sin aria-pressed deja al usuario sin saber en qué estado se encuentra. El atributo es la única forma de comunicar ese estado de forma programática.

Para detectar estos problemas, las herramientas automáticas como axe, Lighthouse o WAVE señalan las violaciones de rol y foco, pero no validan el comportamiento de teclado ni la logica de estado. Esa parte exige prueba manual: navegar con Tab, activar con Enter y Espacio, y escuchar la salida del lector de pantalla. La combinación de auditoría automática y prueba manual es la única forma fiable de validar un botón personalizado.

אם אתה עושה קניות: — Superposición de IA que promete cumplimiento WCAG ב-48 שעות.

Cómo probar un botón con role=“button”

La prueba empieza por el teclado. Recorre la página con Tab y comprueba que el botón con el aria roll button recibe foco visible. Pulsa Enter y Espacio por separado: ambos deben disparar la acción. Si Espacio desplaza la página en lugar de activar el botón, falta el preventDefault.

La segunda prueba es con lector de pantalla. NVDA ב-Windows, VoiceOver ו-macOS ו-Narrator ו-Windows בעלות הפניות נוספות בארה”ב. Al enfocar el botón, el lector debe anunciar el rol (“botón”), el nombre accesible y el estado si lo tiene. Si anuncia “grupo” o no menciona el estado, algo falla.

La tercera prueba es de orden de foco. El botón debe aparecer en el orden lógico de tabulación, ni antes ni después de donde corresponde visualmente. Los tabindex positivos rompen este orden y son un indicador claro de mala implementación.

La cuarta prueba es de contraste y foco visible. El indicador de foco no debe eliminarse con outline: none sin sustituirlo por una alternative visible. Un botón que recibe foco pero no lo muestra deja al usuario de teclado sin referencia de dónde está.

לחצן אלטרנטיבות מודרניות

El elemento <button> nativo segue siendo la mejor opción en 2024 y en cualquier proyecto nuevo. Aporta roll, foco, teclado y estados sin código adicional, y los navegadores lo tratan de forma consistente.

או אלמנטים מותאמים אישית o רכיבי אינטרנט שלאחר מכן. Un componente que extiende HTMLElement puede encapsular el comportamiento de botón y exponerlo con la semántica correcta, unque requiere gestionar manualmente el foco y el teclado igual que con role="button". La ventaja es la reutilización; la desventaja, la misma responsabilidad de implementación.

Las ARIA ב-HTML (Reglas que definen qué roles ARIA se permiten sobre cada elemento HTML) desaconsejan sobrescribir rolls nativos. אפליקציית אל aria role role="button" a un <button> es redundante; aplicarlo a un <a> con href es contraproducente. La recomendación general es reservar el rol para contenedores sin semántica propia.

נקודות חשובות

  • role="button" cambia solo la semántica anunciada; el foco, el teclado y el estado hay que implementarlos a mano.
  • La primera regla de ARIA recomienda usar <button> nativo siempre que el marcado lo permita.
  • Un botón con aria role button necesita tabindex="0", manejo de Enter y Espacio, nombre accesible y estado con aria-pressed o aria-disabled.
  • Las herramientas automáticas detectan la falta de foco, pero el comportamiento de teclado y estado exige prueba manual con lector de pantalla.
  • Nunca משתמש ב-tabindex positivo ni apliques role="button" sobre enlaces que navegan.

שאלות נפוצות

¿Cuál es la diferencia entre role=“button” y el elemento button?

El elemento <button> nativo incluye el roll implícito, el foco por teclado, la activación con Enter y Espacio y el estado deshabilitado sin código adicional. El atributo role="button" solo aporta la semántica anunciada; el resto del comportamiento debe programarse. Por eso la primera regla de ARIA recomienda el elemento nativo siempre que sea posible.

¿Necesito tabindex con role=“button”?

סִי. Un div o span con role="button" no es enfocable por defecto, así que sin tabindex="0" queda fuera del orden de tabulación y es inalcanzable con teclado. El valor correcto es 0; los valores positivos alteran el orden de tabulación de toda la página y deben evitarse.

¿Cómo hago que un div con role=“button” responda a Enter y Espacio?

Hay que escuchar el evento keydown y ejecutar la acción cuando la tecla es Enter או Space. En el caso de Espacio conviene llamar a preventDefault para evitar el desplazamiento de página. Sin estos manejadores, el botón recibe foco pero no se active con teclado.

¿Cómo indico que un botón está activo o deshabilitado?

Para un botón de alternancia usa aria-pressed="true" o "false" según el estado. Para un botón deshabilitado usa aria-disabled="true", que anuncia el estado pero no bloquea la interracción por sí solo: hay que impedir la acción en el código. El atributo nativo disabled es עדיף cuando se usa un <button>.

¿Es mala práctica usar role=“button” en un enlace?

אז, צריך להוסיף כתובת URL אחרת. Sobrescribir el roll de un <a href> con role="button" rompe la semántica de navegación y confunde a los lectores de pantalla, que anuncian “botón” cuando el usuario espera un enlace. Si el elemento navega, debe conservar su roll de enlace.

¿Qué herramientas detectan errores con role=“button”?

Herramientas automáticas como axe, Lighthouse או WAVE señalan violaciones como la falta de foco en elementos con roll interactive. אמברגו חטא, אין תוקף לתקשורת לא לוגיקה דה estado, que la validation fiable combina auditoría automática con prueba manual usando NVDA, VoiceOver או Narrator.


¿Cumplir WCAG sin tocar el código?

Superposición de IA que promete cumplimiento WCAG ב-48 שעות