# צ׳קליסט WCAG 2.2 AA למוצרי SaaS ולאפליקציות ווב

<https://www.fixreports.com/he/blog/wcag-2-2-checklist-saas-web-apps>

עודכן ב-2026-10-26

למוצר SaaS יש שני משטחי נגישות: אתר השיווק שמוכר אותו, והאפליקציה שאנשים משתמשים בה כל יום. אתר השיווק נכשל באותן דרכים כמו כל אתר: ניגודיות נמוכה, טקסט חלופי חסר וטפסים בלי תוויות. האפליקציה מוסיפה בעיות משלה: תהליכי התחברות שחוסמים מנהלי סיסמאות, חלונות דיאלוג שלוכדים את הפוקוס של המקלדת, ניווט באפליקציית עמוד יחיד שקוראי מסך לא מבחינים בו, טבלאות נתונים ותרשימים בלי טקסט, גרירה ושחרור בלי חלופה, וסשנים שפגים בלי אזהרה. הצ׳קליסט הזה עובר על WCAG 2.2 ברמה AA לפי החלקים של מוצר SaaS טיפוסי.

**עיקרי הדברים**

- WCAG 2.2 הפך להמלצה של W3C באוקטובר 2023 והוסיף תשעה קריטריוני הצלחה, שישה מהם ברמה A או AA ([W3C](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/)).
- Accessible Authentication (3.3.8, AA) פירושו שהתחברות לא יכולה להיות תלויה בזכירה או בהעתקה ידנית של סיסמה, אלא אם אפשר להדביק אותה או להשתמש במנהל סיסמאות ([W3C](https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum)).
- יעדים אינטראקטיביים חייבים להיות בגודל 24 על 24 פיקסלי CSS לפחות, או שיהיה סביבם מספיק מרווח (2.5.8, AA) ([W3C](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum)).
- הודעות כמו "נשמר" או "3 תוצאות" צריכות להגיע לקוראי מסך בלי להזיז את הפוקוס (4.1.3, AA) ([W3C](https://www.w3.org/WAI/WCAG22/Understanding/status-messages)).
- קונים עסקיים ומהמגזר הציבורי מבקשים לעיתים קרובות דוח תאימות נגישות (Accessibility Conformance Report), שנכתב בדרך כלל על בסיס תבנית ה-VPAT של ה-Information Technology Industry Council ([ITI](https://www.itic.org/policy/accessibility/vpat)).

## למה נגישות חשובה יותר ב-SaaS מאשר באתר תדמית?

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

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

## איך הופכים הרשמה והתחברות לנגישות?

אימות הוא התחום שבו WCAG 2.2 הוסיף את הדרישה החדשה החשובה ביותר למוצרי SaaS.

- **אפשרו הדבקה ומנהלי סיסמאות (3.3.8, AA).** אל תחסמו הדבקה בשדות של סיסמה או קוד, והשתמשו ב-`autocomplete="username"`, ב-`autocomplete="current-password"` וב-`autocomplete="one-time-code"` כדי שדפדפנים ומנהלי סיסמאות יוכלו למלא אותם.
- **הימנעו מחידות כדרך היחידה להיכנס.** CAPTCHA שמבקש מאנשים להעתיק טקסט מעוות או לפתור חידה הוא מבחן של תפקוד קוגניטיבי. הציעו חלופה, והעדיפו בדיקות שלא דורשות פעולה מהמשתמש ([W3C](https://www.w3.org/TR/turingtest/)).
- **תנו תווית לכל שדה (1.3.1 ו-3.3.2, A).** השתמשו ב-`<label>` גלוי שמקושר לשדה הקלט; טקסט placeholder נעלם כשמתחילים להקליד, והוא לא תווית.
- **זהו שגיאות בטקסט (3.3.1, A) והציעו תיקונים (3.3.3, AA).** "הסיסמה חייבת להכיל לפחות 12 תווים" עוזר; מסגרת אדומה לבדה לא.
- **אל תבקשו פעמיים (3.3.7, A).** אם הרשמה מרובת שלבים כבר ביקשה שם חברה או כתובת, מלאו אותם מראש או אפשרו לבחור אותם במקום להקליד מחדש.
- **השאירו את העזרה באותו מקום (3.2.6, A).** אם אתם מציעים צ׳אט, קישור לעזרה או פרטי יצירת קשר, הציבו אותם באותו מיקום יחסי בכל דף בתהליך.

## אילו דפוסי טפסים ושגיאות גורמים להכי הרבה כשלים?

רוב הכשלים באפליקציות נמצאים בטפסים. הסקר של WebAIM לשנת 2026, שבדק מיליון דפי בית, מצא תוויות טופס חסרות ב-51% מהם ([WebAIM](https://webaim.org/projects/million/)), ובאפליקציות יש הרבה יותר טפסים מאשר בדפי בית.

- תנו לכל שדה קלט שם פרוגרמטי, וקבצו פקדים קשורים, כמו כפתורי רדיו, באמצעות `<fieldset>` ו-`<legend>`.
- הודיעו על שגיאות במקום שבו אנשים ישימו לב אליהן: העבירו את הפוקוס לסיכום שגיאות בראש הטופס, או לשדה הלא תקין הראשון, וקשרו כל פריט בסיכום לשדה שלו.
- סמנו שדות חובה בטקסט, לא רק בצבע (1.4.1, A).
- אל תשלחו טופס ואל תשנו הקשר רק כי מישהו בחר אפשרות (3.2.2, A); חכו לפעולה מפורשת.

## איך צריכים להתנהג חלונות דיאלוג, תפריטים וחלונות קופצים?

רכיבים מותאמים אישית הם המקום שבו התמיכה במקלדת ובקוראי מסך נשברת הכי הרבה. המדריך WAI-ARIA Authoring Practices Guide מתאר את ההתנהגות הצפויה לכל דפוס ([W3C](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/)).

- **חלונות דיאלוג**: העבירו את הפוקוס לתוך הדיאלוג כשהוא נפתח, השאירו את Tab בתוכו כל עוד הוא פתוח, סגרו אותו עם Escape והחזירו את הפוקוס לפקד שפתח אותו. השתמשו ברכיב `<dialog>` המובנה, או ב-`role="dialog"` עם `aria-modal="true"` ושם.
- **בלי מלכודות מקלדת (2.1.2, A)**: כל רכיב חייב לאפשר יציאה ממנו עם המקלדת.
- **פוקוס גלוי (2.4.7, AA)** שלא מוסתר מאחורי כותרות נעוצות, באנרים של עוגיות או וידג׳טים של צ׳אט (2.4.11, AA, חדש ב-2.2).
- **תיבות עזר וחלונות קופצים (1.4.13, AA)** שאפשר לסגור עם Escape, להעביר מעליהם את העכבר בלי שייעלמו, ושנשארים עד שסוגרים אותם.
- **קיצורי מקש יחיד (2.1.4, A)**: אם לחיצה על מקש של אות מפעילה פעולה, אפשרו לכבות את הקיצורים או למפות אותם מחדש, או הפעילו אותם רק כשהרכיב הרלוונטי בפוקוס.

## איך מטפלים בניווט באפליקציית עמוד יחיד?

באפליקציית עמוד יחיד (single-page app) כתובת ה-URL משתנה בלי טעינת דף, ולכן ייתכן שקוראי מסך לא יכריזו שמשהו קרה.

- עדכנו את כותרת המסמך בכל שינוי נתיב, כך שלכל תצוגה תהיה כותרת תיאורית (2.4.2, A).
- העבירו את הפוקוס לכותרת הראשית של התצוגה החדשה, או הכריזו על השינוי באזור חי מנומס (polite live region); מסגרות כמו Next.js כוללות לשם כך route announcer.
- שמרו על סדר פוקוס הגיוני (2.4.3, A): אחרי מחיקת פריט, הפוקוס צריך לעבור לפריט שכן מתאים, ולא לחזור לראש הדף.
- ספקו דרך לדלג על ניווט שחוזר על עצמו (2.4.1, A), כמו קישור דילוג או אזורי ציון דרך (landmarks).

## איך הופכים לוחות מחוונים, טבלאות נתונים ותרשימים לנגישים?

- **טבלאות**: השתמשו ב-markup אמיתי של `<table>` עם `<th>` ו-`scope` לכותרות, ועם כיתוב (caption) (1.3.1, A). רשתות שבנויות מרכיבי `<div>` צריכות את דפוס ה-ARIA grid המלא, שהרבה יותר קשה לבצע נכון.
- **תרשימים**: תנו לכל תרשים חלופה טקסטואלית שמציינת את הנקודה העיקרית, והציעו את הנתונים כטבלה (1.1.1, A). אל תסתמכו רק על צבע כדי להבחין בין סדרות (1.4.1, A); הוסיפו תוויות או דוגמאות מילוי.
- **ניגודיות**: טקסט צריך 4.5:1 (1.4.3, AA), וקווים בתרשימים, אייקונים ומסגרות של שדות קלט צריכים 3:1 מול הרקע (1.4.11, AA). בדקו את מצב הכהה בנפרד. [בדיקת ניגודיות הצבעים](/he/color-contrast-checker) שלנו בודקת כל זוג צבעים.
- **הודעות סטטוס (4.1.3, AA)**: "נשמר", "ההעלאה הושלמה" ומספרי תוצאות צריכים להשתמש ב-`role="status"` או באזור חי, כדי שקוראי מסך ישמעו אותם בלי לאבד את המקום.

## מה הקריטריונים החדשים של WCAG 2.2 משנים באפליקציות ווב?

| קריטריון | רמה | מה המשמעות באפליקציה |
|---|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | AA | סרגלי כלים נעוצים, באנרים ווידג׳טים של צ׳אט לא יכולים להסתיר לגמרי את הרכיב שבפוקוס |
| 2.5.7 Dragging Movements | AA | כל מה שנעשה בגרירה, כמו סידור מחדש של לוח kanban, צריך חלופה עם מצביע יחיד, למשל תפריט או כפתורי למעלה ולמטה |
| 2.5.8 Target Size (Minimum) | AA | כפתורים וקישורים בגודל 24 × 24 פיקסלי CSS לפחות, או מרוחקים כך שעיגול של 24 פיקסלים סביב כל אחד לא חופף לאחר |
| 3.2.6 Consistent Help | A | קישורי עזרה, צ׳אט ופרטי יצירת קשר באותו מיקום יחסי בכל דף |
| 3.3.7 Redundant Entry | A | מידע שכבר הוזן באותו תהליך מתמלא מראש או ניתן לבחירה |
| 3.3.8 Accessible Authentication (Minimum) | AA | התחברות בלי שינון או העתקה ידנית, אלא אם מתאפשרים הדבקה, מנהלי סיסמאות או שיטה אחרת |

WCAG 2.2 גם הסיר את 4.1.1 Parsing, שכבר אין לו השפעה מעשית על נגישות ([W3C](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/)).

## ומה לגבי פסקי זמן, פריסה וזום?

- **פסקי זמן של סשן (2.2.1, A)**: הזהירו אנשים לפני שסשן פג ואפשרו להאריך אותו בפעולה פשוטה, אלא אם מגבלת הזמן הכרחית או ארוכה מ-20 שעות. שמירה של עבודה שבתהליך מונעת את התוצאה הגרועה ביותר.
- **Reflow (1.4.10, AA)**: התוכן צריך לעבוד ברוחב 320 פיקסלי CSS (שווה ערך לזום של 400% במסך ברוחב 1280 פיקסלים) בלי גלילה בשני כיוונים; טבלאות נתונים ותוכן דומה פטורים.
- **ריווח טקסט (1.4.12, AA)**: הגדלת גובה השורה והריווח בין האותיות לא צריכה לחתוך טקסט, מה שקורה לעיתים קרובות במכלים עם גובה קבוע.
- **כיוון מסך (1.3.4, AA)**: אל תנעלו את האפליקציה לתצוגה לאורך או לרוחב, אלא אם זה הכרחי.

## מה זה ACR, והאם צריך אותו?

דוח תאימות נגישות (Accessibility Conformance Report, ACR) מתעד איך מוצר עומד בכל קריטריון נגישות: תומך, תומך חלקית או לא תומך, עם הערות. רוב הדוחות נכתבים על בסיס תבנית ה-VPAT שמפרסם ה-Information Technology Industry Council, שיש לה מהדורות ל-WCAG, לתקני Section 508 האמריקאיים ולתקן האירופי EN 301 549 ([ITI](https://www.itic.org/policy/accessibility/vpat)).

סוכנויות פדרליות בארצות הברית חייבות לרכוש טכנולוגיה נגישה לפי Section 508 ([Section508.gov](https://www.section508.gov/)), וגופים ציבוריים באיחוד האירופי מסתמכים על EN 301 549, ולכן ממוצרי B2B שמוכרים ללקוחות כאלה מבקשים לעיתים קרובות ACR בתהליך הרכש. ACR כן, שמפרט פערים ידועים, שימושי יותר לקונים מדוח שטוען לתמיכה מלאה. הוא צריך להתבסס על בדיקה של המוצר, כולל בדיקה ידנית; סריקה אוטומטית לבדה לא יכולה למלא אותו.

אם אתם מוכרים לצרכנים באיחוד האירופי, ייתכן שגם חוק הנגישות האירופי חל על האופן שבו אתם מוכרים אונליין; [המדריך שלנו ל-EAA](/he/blog/european-accessibility-act-online-stores) מסביר את היקפו. זה לא ייעוץ משפטי.

## איך צוות SaaS צריך לבדוק נגישות?

1. **הפכו את הבסיס לאוטומטי.** הריצו את axe-core או מנוע דומה בבדיקות ה-end-to-end ובאתר השיווק, והכשילו builds כשמופיעות הפרות חדשות. [בדיקת הנגישות החינמית](/he/website-accessibility-checker) שלנו מריצה את אותו מנוע על כל דף ציבורי.
2. **בדקו עם מקלדת.** השלימו את תהליכי העבודה העיקריים, כמו הרשמה, יצירת רשומה ושינוי הגדרות, רק עם Tab, Shift+Tab, Enter, Space, Escape ומקשי החיצים.
3. **בדקו עם קורא מסך.** NVDA ב-Windows ו-VoiceOver ב-macOS וב-iOS הם חינמיים. בדקו ששמות, תפקידים, מצבים והודעות מוכרזים.
4. **הגדילו ושנו גודל.** בדקו זום טקסט של 200% וחלון ברוחב 320 פיקסלים.
5. **תקנו במערכת העיצוב.** רוב הכשלים מגיעים מרכיבים משותפים; תיקון של כפתור או דיאלוג פעם אחת מתקן אותו בכל מקום.

## שאלות נפוצות

### האם WCAG חל על החלקים של אפליקציית ווב שדורשים התחברות?

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

### האם תוסף נגישות יכול להפוך מוצר SaaS לנגיש?

לא. תוספי נגישות לא משנים את הקוד הבסיסי של רכיבים מותאמים אישית, ושם נמצאים הכשלים של אפליקציות. המדריך שלנו על [תוספי נגישות](/he/blog/accessibility-overlays-ftc-order) עוסק בצעד של ה-FTC נגד ספקית מובילה של תוספים כאלה.

### כמה מ-WCAG כלים אוטומטיים יכולים לבדוק?

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

### לאיזו גרסה של WCAG כדאי לכוון?

WCAG 2.2 ברמה AA היא הגרסה הנוכחית. חוקים וכללי רכש רבים עדיין מפנים ל-WCAG 2.1 AA; מי שעומד ב-2.2 AA עומד גם ב-2.1 AA, חוץ מקריטריון ה-Parsing שהוסר.

### האם צריך לעמוד ברמה AAA?

W3C לא ממליץ לדרוש AAA למוצרים שלמים, כי חלק מהתוכן לא יכול לעמוד בכל קריטריוני ה-AAA. רמה AA היא היעד המקובל.

## מקורות

- W3C: [מה חדש ב-WCAG 2.2](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/)
- W3C: [ההנחיות לנגישות תוכן אינטרנט (WCAG) 2.2](https://www.w3.org/TR/WCAG22/)
- W3C: [הבנת 3.3.8 Accessible Authentication (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum)
- W3C: [הבנת 2.5.8 Target Size (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum)
- W3C: [הבנת 4.1.3 Status Messages](https://www.w3.org/WAI/WCAG22/Understanding/status-messages)
- W3C: [ARIA Authoring Practices Guide: דפוס חלון דיאלוג (מודאלי)](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/)
- W3C: [חוסר הנגישות של CAPTCHA (Inaccessibility of CAPTCHA)](https://www.w3.org/TR/turingtest/)
- ITI: [Voluntary Product Accessibility Template (VPAT)](https://www.itic.org/policy/accessibility/vpat)
- GSA: [Section508.gov](https://www.section508.gov/)
- WebAIM: [The WebAIM Million (2026)](https://webaim.org/projects/million/)