ניווט במקלדת הוא היכולת להשתמש בכל האתר בלי עכבר: לעבור בין קישורים, כפתורים ושדות עם Tab, להפעיל אותם עם Enter או רווח, ולסגור חלונות עם Esc. הוא חשוב לאנשים עם מוגבלות מוטורית, למשתמשי קוראי מסך (שעובדים כמעט רק עם מקלדת), ולכל מי שפשוט מעדיף אותה. זו גם הבדיקה הכי פשוטה שיש: מניחים את העכבר בצד ומנסים לבצע את הפעולה החשובה ביותר באתר. אם זה לא עובד — האתר לא נגיש, בלי קשר לשום תוסף.
מה ההנחיות דורשות
ארבעה קריטריונים של WCAG עוסקים ישירות במקלדת, וכולם חלק מרמה AA ולכן גם מהתקן הישראלי:
| קריטריון | מה הוא אומר |
|---|---|
| 2.1.1 מקלדת | כל הפונקציונליות זמינה גם במקלדת |
| 2.1.2 ללא מלכודת מקלדת | אם אפשר להיכנס לרכיב עם המקלדת, אפשר גם לצאת ממנו |
| 2.4.3 סדר פוקוס | סדר המעבר בין הרכיבים שומר על המשמעות והתפעול |
| 2.4.7 פוקוס נראה | תמיד רואים איזה רכיב נמצא בפוקוס |
ההסברים המלאים נמצאים בעמודי ההבנה של W3C — למשל מקלדת וללא מלכודת מקלדת. ב-WCAG 2.2 נוסף גם 2.4.11: הרכיב שבפוקוס לא יוסתר לגמרי על ידי תוכן אחר, כמו כותרת דביקה או באנר עוגיות.
הבעיות הנפוצות
1. מסגרת הפוקוס הוסרה
הדפדפן מסמן את הרכיב שבפוקוס במסגרת. מעצבים רבים לא אוהבים אותה ומוחקים אותה בשורת CSS אחת (outline: none). התוצאה: מי שגולש במקלדת לא יודע איפה הוא. הפתרון הוא לא לבטל אלא לעצב — מסגרת ברורה בצבע של המותג, עם :focus-visible כדי שתופיע רק בניווט מקלדת.
a:focus-visible, button:focus-visible {
outline: 3px solid #785EE8;
outline-offset: 2px;
}
2. "כפתורים" שהם בעצם div
רכיב שנבנה מ-div עם אירוע לחיצה עובד בעכבר, אבל לא מקבל פוקוס ולא מגיב ל-Enter. כפתור אמיתי (button) מקבל את כל זה בחינם. זה הכלל הראשון של ARIA: אם יש רכיב HTML מובנה שעושה את העבודה — משתמשים בו. ראו ARIA בקצרה.
3. תפריט שנפתח רק בריחוף
תפריט משנה שמופיע רק כשהעכבר מעליו לא נגיש במקלדת. צריך שאותו תפריט ייפתח גם בלחיצה או במקש, ושיהיה אפשר לסגור אותו ב-Esc. על מבנה תפריט נגיש כתבתי בתפריט ניווט לאתר.
4. חלון קופץ שלוכד או מפספס את הפוקוס
שתי בעיות הפוכות: חלון שנפתח אבל הפוקוס נשאר מאחוריו (והמשתמש ממשיך לעבור על העמוד המוסתר), או חלון שאי אפשר לצאת ממנו. הדרך הנכונה: כשהחלון נפתח הפוקוס עובר אליו, הוא נשאר בתוכו כל עוד הוא פתוח, Esc סוגר אותו, והפוקוס חוזר לכפתור שפתח אותו. ראו גם חלונות קופצים באתר.
5. סדר שלא תואם את המסך
כשמשנים סדר ויזואלי ב-CSS (למשל ב-flex או grid), סדר ה-Tab נשאר לפי הקוד. התוצאה: הפוקוס קופץ בעמוד בלי היגיון. באתר מימין לשמאל זה בולט במיוחד. וערכי tabindex חיוביים כמעט תמיד מחמירים את המצב.
6. רכיבים של צד שלישי
סליידרים, מפות, צ'אטים וטפסים מוטמעים מביאים איתם את הקוד שלהם. לפני שבוחרים רכיב כזה, בודקים אותו במקלדת.
קישור "דלג לתוכן"
קריטריון 2.4.1 דורש דרך לדלג על בלוקים שחוזרים בכל עמוד. הפתרון הנפוץ הוא קישור "דלג לתוכן הראשי" — הדבר הראשון שמקבל פוקוס בעמוד. הוא מוסתר עד שלוחצים Tab, ואז מופיע. בלעדיו, מי שגולש במקלדת עובר על כל פריטי התפריט בכל עמוד מחדש.
בדיקת עשר דקות
- טוענים את דף הבית ולוחצים Tab. האם הדבר הראשון הוא "דלג לתוכן"?
- ממשיכים עם Tab. האם תמיד רואים איפה הפוקוס?
- האם הסדר הגיוני — מימין לשמאל ומלמעלה למטה?
- פותחים את התפריט, כולל תפריטי משנה, ומגיעים לעמוד פנימי.
- פותחים חלון קופץ (חיפוש, עוגיות, תפריט מובייל) וסוגרים אותו ב-Esc.
- ממלאים ושולחים את הטופס — ראו נגישות טפסים.
- בחנות: מוסיפים מוצר לסל ומגיעים לתשלום.
אם נתקעתם בשלב כלשהו — זו הבעיה הראשונה לתקן. את הבדיקה המלאה פירטתי בבדיקת נגישות אתר.
שאלות נפוצות
מי באמת גולש בלי עכבר?
משתמשי קוראי מסך, אנשים עם מוגבלות מוטורית שמשתמשים במקלדת או במתגים, אנשים עם רעד בידיים, ומשתמשים מתקדמים שפשוט מהירים יותר במקלדת.
זה רלוונטי גם במובייל?
כן. משתמשים מחברים מקלדת לטאבלט, וקוראי המסך בנייד נשענים על אותו מבנה של רכיבים שמקבלים פוקוס.
האם תוסף נגישות פותר בעיות מקלדת?
כמעט אף פעם. רכיב שלא מקבל פוקוס צריך תיקון בקוד שלו. ראו תוסף נגישות לאתר.
ניווט מלא במקלדת הוא תנאי בסיס בכל תבנית שאני כותב. פירוט בעמוד הנגשת אתרים לפי ת״י 5568, ואפשר לפנות אליי לבדיקה.
אהבתם את המאמר?
