קריטריון 3.3.3: הצעה לתיקון שגיאה רמה AA

פרטי הקריטריון

מה דורש קריטריון 3.3.3?

קריטריון 3.3.3 בונה על 3.3.1 (זיהוי שגיאות) ומוסיף עליו שכבה נוספת: לא רק לזהות ולתאר את השגיאה, אלא גם להציע כיצד לתקן אותה - כאשר הדבר ידוע לתוכנה.

• שגיאת פורמט - אם המשתמש הזין תאריך בפורמט שגוי, הצע את הפורמט הנכון: "יש להזין את התאריך בפורמט DD/MM/YYYY".
• ערך מחוץ לטווח - אם קיבוץ מחירים מוגבל לטווח מסוים, ציין את הטווח המותר.
• שדה חובה ריק - ציין במפורש שהשדה נדרש ולא ניתן להמשיך ללא מילויו.
• חריגה: הצעה לתיקון אינה נדרשת אם היא תסכן את האבטחה (למשל, לא ניתן לרמוז "הסיסמה שהזנת קצרה מדי - הוסף עוד תו").

למי זה עוזר?

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

איך עומדים בקריטריון?

• ניסחו הודעות שגיאה ספציפיות: "כתובת הדוא"ל חייבת לכלול את הסימן @" עדיפה על "כתובת לא תקינה".
• כאשר יש רשימה מוגבלת של ערכים חוקיים - הציגו אותם במפורש.
• כאשר קיים פורמט נדרש - ציינו אותו בהצעת התיקון: "הזינו את הטלפון בפורמט 05X-XXXXXXX".
• השתמשו ב-aria-describedby כדי לקשר את השדה להצעת התיקון, כך שקורא המסך יקריא אותה.
• ודאו שהצעת התיקון גלויה ומוצגת בסמוך לשדה השגוי, לא רק בראש הדף.

איך בודקים?

• בדיקה ידנית: הגישו טפסים עם שגיאות מכוונות ובדקו האם הודעת השגיאה כוללת הצעה ספציפית לתיקון.
• קורא מסך (NVDA / VoiceOver): ודאו שהצעות התיקון מוקראות בעת מיקוד על שדות שגויים.
• בדקו שהצעות התיקון מוצגות ללא עיכוב מיותר ובמיקום קרוב לשדה הרלוונטי.
• בדיקה אנושית: הכלים האוטומטיים אינם יכולים לבדוק את איכות ההצעה - נדרשת בדיקה על ידי אנשים.