מנגישים את הנגשת האתרים – חלק שלישי – הקוד

נגישות אתר מתחילה בקוד, לא בתוסף שמתלבש מעליו. החלק השלישי בסדרה מתמקד במה שמפתח צריך לעשות בפועל בתוך ה-HTML, ה-CSS וה-JavaScript כדי שאתר יעבוד עבור גולש שמנווט במקלדת או בקורא מסך. הכל מיושר לתקן הישראלי המחייב, ת"י 5568 ברמה AA, שמבוסס על WCAG.

הבסיס: לעבוד מסודר ולכתוב HTML סמנטי

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

המבנה הסמנטי של ה-HTML הוא מה שקורא מסך נשען עליו כדי להבין מה כל אזור בעמוד. כמה כללי ברזל:

1. רשימות ותפריטים בתוך <ul> / <ol> עם <li>, ולא רצף של <div>.
2. כותרות בהיררכיה נכונה: <h1> אחד לעמוד, ואז <h2>, <h3> בלי לדלג על רמות.
3. אזורי עמוד בתגיות הנכונות: <header>, <nav>, <main>, <footer>. הן מספקות נקודות ניווט מובנות לקורא המסך.
4. תמונות עם alt משמעותי. דאגו שמערכת הניהול תאפשר ללקוח להוסיף טקסט חלופי בנוחות.

ככל שה-HTML סמנטי יותר, כך תצטרכו פחות תיקונים ידניים בהמשך. רוב מה שאנשים מנסים לתקן עם JavaScript אפשר לפתור פשוט בבחירת התגית הנכונה.

פוקוס: לזרוק את ה-jQuery, להשתמש ב-CSS מודרני

נקודה שמפתחים רבים מפספסים: אם יש אפקט שמופעל ב-:hover (תמונה שנגללת, תפריט שנפתח), הוא חייב לעבוד גם למי שמנווט במקלדת ולא בעכבר. גולש מקלדת לא "מרחף" מעל אלמנט, הוא מקבל עליו focus.

בעבר נהוג היה לזייף את זה ב-jQuery, להאזין ל-focus ולשגר אירוע mouseenter. זו גישה שבירה ומיושנת. ב-2026 הפתרון הוא CSS טהור: פשוט מצרפים את מצב ה-focus לאותו כלל עיצוב כמו ה-hover.

.card:hover,
.card:focus-within {
  /* האפקט שלכם כאן */
}

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

.button:focus-visible {
  outline: 2px solid #1a73e8;
  outline-offset: 2px;
}

כלל קריטי: לעולם אל תכבו את מסגרת המיקוד עם outline: none בלי לספק חלופה נראית. אלמנט ממוקד שלא ניתן לזהות ויזואלית הוא כשל נגישות מובהק לפי הקריטריון Focus Visible ב-WCAG.

tabindex: הטעות הנפוצה ביותר

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

tabindex קובע האם אלמנט נכלל בסדר הניווט של מקש TAB:

• tabindex="0" מכניס את האלמנט לסדר ה-TAB הטבעי, לפי מיקומו ב-DOM. זה מה שצריך כשרוצים שמשתמש מקלדת יוכל להגיע לאלמנט שאינו לחיץ באופן טבעי.
• tabindex="-1" מוציא את האלמנט מסדר ה-TAB. אי אפשר להגיע אליו עם מקש TAB. הוא משמש רק כדי לאפשר העברת focus תכנותית (דרך JavaScript עם element.focus()), למשל קפיצה ליעד אחרי פעולה.
• tabindex חיובי (1 ומעלה) נחשב anti-pattern. הוא משבש את סדר הניווט הטבעי ויוצר באגים. אל תשתמשו בו.

המסקנה המעשית: אם רוצים שגולש מקלדת יגיע לאלמנט, הערך הוא 0, לא -1.

<!-- נכון: האלמנט נכנס לסדר הניווט במקלדת -->
<div tabindex="0" role="button">לחצן מותאם</div>

<!-- שימוש נכון ל-1: יעד לקפיצת focus תכנותית בלבד -->
<div id="result" tabindex="-1">תוצאה שהפוקוס יקפוץ אליה</div>

חשוב לזכור: ברגע שהפכתם <div> לאינטראקטיבי עם tabindex="0", אתם גם אחראים להפעיל אותו במקלדת (Enter ו-Space), וגם להגדיר לו role נכון. כאן נכנס ARIA.

ARIA: כשהסמנטיקה הטבעית לא מספיקה

הכלל הראשון של ARIA הוא: אם יש אלמנט HTML מובנה שעושה את העבודה, השתמשו בו. <button> תמיד עדיף על <div role="button">, כי הוא מגיע עם ניהול focus, הפעלה במקלדת ותפקיד מובנים. ARIA נועד למקרים שבהם בניתם רכיב מותאם שאין לו מקבילה סמנטית טבעית.

שלושת סוגי המאפיינים שכדאי להכיר:

1. Roles – מגדירים מה האלמנט. למשל role="dialog" לחלון מודאלי, role="tablist" למערכת טאבים. הם אומרים לקורא המסך כיצד להתייחס לרכיב.
2. Properties – מתארים מאפיינים יחסית קבועים. aria-label נותן שם נגיש לאלמנט בלי תווית נראית, aria-labelledby מקשר לתווית קיימת, aria-describedby מקשר להסבר נוסף.
3. States – מתארים מצב משתנה. aria-expanded="true/false" לאקורדיון או תפריט נפתח, aria-hidden="true" להסתרת אלמנט דקורטיבי מקורא המסך, aria-current="page" לפריט הפעיל בתפריט.

דוגמה לכפתור אייקון בלי טקסט נראה, שבלי aria-label קורא המסך פשוט יקרא "לחצן" בלי הקשר:

<button aria-label="סגירת החלון">
  <svg aria-hidden="true"><!-- אייקון X --></svg>
</button>

כלל אצבע: ARIA שגוי גרוע מ-ARIA שלא קיים. מאפיין שמתאר מצב לא נכון (למשל aria-expanded שלא מתעדכן) מבלבל את הגולש יותר מאשר היעדרו. אם אתם לא בטוחים, העדיפו אלמנט סמנטי טבעי.

עדכון: <div> בתוך <a> מותר

מדריכים ישנים (כולל קודמים שלנו) קבעו שאסור להכניס <div> או אלמנטים בלוק לתוך קישור, ושמותר רק inline כמו <span>. זה כבר לא נכון. ב-HTML5 מותר לעטוף תוכן בלוק שלם בתוך <a>, כל עוד אין בתוכו אלמנט אינטראקטיבי אחר (כפתור או קישור נוסף).

המשמעות: כדי להפוך כרטיס שלם ללחיץ, אין צורך יותר בטריק jQuery שמחפש class ומפעיל קישור פנימי. פשוט עוטפים:

<a href="/product/" class="card">
  <h3>שם המוצר</h3>
  <p>תיאור קצר</p>
</a>

זה תקין סמנטית, נגיש למקלדת מחוץ לקופסה, ולא דורש שורת JavaScript אחת. עדיין דאגו ש-aria-label או הטקסט הפנימי יתארו את יעד הקישור בבירור.

למה תוסף נגישות לא יחליף את זה

שווה לומר את זה במפורש: ה-overlays האוטומטיים (accessiBe, UserWay, Vee וכדומה) לא מחליפים את העבודה שתוארה כאן. בדיקות חוזרות מראות שהם מתקנים רק כ-10 עד 16 אחוז מדרישות WCAG, ובינואר 2025 ה-FTC קנס את accessiBe במיליון דולר על הטענה הכוזבת ש-ה-widget הופך אתר ל-compliant. overlay אינו עמידה בתקן 5568, והנגישות האמיתית נבנית בקוד. הרחבנו על כך במדריך למה תוסף נגישות (overlay) לא מספיק.

לתמונה המלאה של מה שהתקן דורש, מבנה ה-HTML ועד הצהרת הנגישות, ראו את המדריך המלא להנגשת אתר וורדפרס לפי תקן 5568. כשהקוד תקין, נשאר לתעד אותו בהצהרת נגישות לאתר כפי שמחייב החוק.

בדיקת נגישות קוד דרך OCW

אם אתם רוצים לדעת איפה האתר שלכם עומד בפועל מול ת"י 5568, ולא להסתמך על ציון של widget, אנחנו בודקים. חבילת אחריות 360 של OCW כוללת פילר נגישות לצד אבטחה, פרטיות ותחזוקה טכנית, עם audit ידני של הקוד ותיקונים שוטפים. אפשר גם לבצע audit חד-פעמי. דברו איתנו דרך עמוד הקשר ונבדוק את האתר.

שאלות נפוצות

מה ההבדל בין tabindex="0" ל-tabindex="-1"?

tabindex="0" מכניס אלמנט לסדר הניווט הטבעי של מקש TAB, כך שגולש מקלדת מגיע אליו. tabindex="-1" מוציא אותו מסדר ה-TAB ומאפשר רק העברת focus תכנותית דרך JavaScript. כדי שמשתמש יוכל להגיע לאלמנט במקלדת, השתמשו ב-0.

האם מותר להכניס div לתוך קישור?

כן. ב-HTML5 מותר לעטוף תוכן בלוק, כולל <div>, בתוך <a>, כל עוד אין בתוכו אלמנט אינטראקטיבי אחר כמו כפתור או קישור נוסף. הכלל הישן שאסר זאת אינו תקף יותר.

האם ARIA מחליף HTML סמנטי?

לא. אלמנט HTML מובנה כמו <button> תמיד עדיף על <div> עם role, כי הוא מגיע עם ניהול focus והפעלה במקלדת. ARIA נועד רק לרכיבים מותאמים שאין להם מקבילה סמנטית טבעית, ו-ARIA שגוי מזיק יותר מהיעדרו.

האם תוסף נגישות הופך אתר לתקני?

לא. overlays מתקנים כ-10 עד 16 אחוז מדרישות WCAG בלבד, וה-FTC קנס את accessiBe במיליון דולר על טענה כזו. עמידה בת"י 5568 נבנית בקוד.