נגישות אתרים: המלצות להנגשת אתר אינטרנט ועבודה עם תקן WCAG 2.0

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

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

למען הסר ספק, יובהר כי בכל מקרה של סתירה בין הכתוב במסמך זה ובחוקי מדינת ישראל, ובהם חוק שוויון זכויות לאנשים עם מוגבלות התשנ"ח-1998 (כולל התיקונים והתקנות הנלווים לחוק זה ובפרט  חובת הנגישות משנת 2005 וקובץ התקנות לחוק הנ”ל מתאריך 25.40.13, ובמיוחד תקנה 35 לחוק הנ"ל,  כמו גם תקנים מחייבים לנושא נגישות ובהם תקן  Wcag 2.0  וההתאמות אליו בתקן מכון התקנים ת"י 5568), יהיה הכתוב בחוקי המדינה ובתקנים הנ"ל המקור הקובע.

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

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

1.   הנגשת אתרי אינטרנט - היתרונות

החל מתאריך 01.07.13, התאמת נגישות הינה חובה חוקית לכל אתר, ואי ביצועה משמעותה לא רק הפרת החוק, כי אם הסתכנות בתביעה, בסנקציות כלכליות ופליליות על האתר ואישית כנגד מנהלי החברה, ובתביעות אזרחיות (עד 50,000 ₪ ללא הוכחת נזק).

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

• הגדלת קהל היעד הפוטנציאלי ומספר המשתמשים באתר: ע"י שיפור האפשרות למתן שירות לאוכלוסיה גדולה יותר של משתמשים, האתר מגדיל באופן אוטומטי את קהל היעד אליו הוא פונה, ומצרף קהל גולשים חדש שלא קיבל ממנו שירות, לפני ביצוע התאמות הנגישות.
• שיפור תאימות למנועי חיפוש והגדלת נפח התנועה לאתר: ביצוע התאמות נגישות משפר פעמים רבות את התאימות למנועי חיפוש (לדוגמא, ע"י סימון נכון יותר של ההיררכיה במסמך, הוספת טקסט חלופי לטקסט שהופיע בתמונות ולא היה נגיש למנועי חיפוש ועוד). כתוצאה, פעמים רבות גדל מספר הכניסות לאתר ממקור תנועה חשוב זה.
• שיפור מדדי השימושיות באתר: הפיכת עמודי האתר לנגישים, לרוב הופכת אותם גם לברורים וקלים יותר לשימוש לא רק לבעלי מוגבלויות, אלא גם לקהל הרחב. כתוצאה, פעמים רבות הגולשים נוטים לעשות שימוש נרחב יותר בתכני האתר, שכולל ביצוע פעולות רבות יותר והמרות רבות יותר.
• שיפור התדמית הארגונית: אין ספק שביצוע התאמות נגישות, ברמה גבוהה ככל האפשר, מהווה היום חלק מהותי ממארג האחריות החברתית והאחריות הארגונית. ההנגשה עשויה לשפר את תדמיתו של כל אתר, קטן כגדול, לא רק בעיני גולשים בעלי מוגבלות, אלא גם בעיני הציבור הרחב. סקר של המכון לגאוקרטוגרפיה עבור נציבות שוויון זכויות לאנשים עם מוגבלות משנת 2009 מצא כי 89% מהציבור מעריכים באופן חיובי עסק המאפשר שירות נגיש לאנשים עם מוגבלות. (לפרטים נוספים, ראו את המסמך הזווית העסקית של נגישות  באתר נציבות שוויון זכויות).
• הקטנת הוצאות החברה: כאמור, ביצוע התאמות נגישות מגדיל את מספר המשתמשים באתר ואת מספר הפעולות שהם מבצעים בו. כתוצאה, מספר הפונים ישירות לבית עסק עשוי לרדת, ובהתאם, יפחתו הוצאות בית העסק על מערך התמיכה והשירות.

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

אז איך מתחילים להנגיש? הנה כמה הצעות, שלב אחר שלב:

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

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

• קבעו את רמת הנגישות הנדרשת: הצעד הראשון שיש לבצע הוא לברר מה נדרש ומה רוצים לבצע באתר. מבחינת החוק, ברירת המחדל היא ביצוע התאמות נגישות ברמה AA. במידה ומדובר באתר קטן או כזה שבו הנטל הנדרש להשגת רמת AA כבד מדי, ניתן לקבל הקלות ולבצע התאמות ברמה A בלבד (בסוף המאמר תמצאו פירוט מלא לכל אחת מרמות ההנגשה הנדרשות - A, AA, או AAA).
• מנגישים אתר קיים או אתר חדש? הגישה להליך ההנגשה כולו תלויה בנקודת המוצא - האם אנו עומדים בפני הנגשת אתר קיים או יצירת אתר חדש כאתר נגיש. ללא ספק, האפשרות הקלה והזולה יותר היא בנייה של אתר חדש כאתר נגיש מלכתחילה - פשוט ומהיר יותר לתת לצוות הפיתוח לבנות מודול נגיש, מאשר לבנות מודול ולאחר מכן לעצבו מחדש ולשנותו על מנת שיהיה נגיש. נכון לכתיבת שורות אלו, נותרו עוד כשנתיים לתקופת ההתאמה (על-פי החוק עד אוקטובר 2017 - כל האתרים צריכים להנגיש את עצמם). זהו זמן ארוך דיו כדי שאתרים רבים יבחרו ממילא להשיק גרסה מחודשת של האתר ללא קשר לנגישות, ולכן יהיה קל יותר לבצע את הליך ההנגשה עם חידוש פני האתר.

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

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

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

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

בשני המקרים, ועוד לפני תחילת הפיתוח בפועל, מומלץ להיעזר במומחים מעודכנים בתחום, על-מנת לקבל נקודת מבט מקצועית על התוכניות.

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

באלמנטים תוכניים לרוב לא ניתן לטפל בצורה זו. התוכן שונה מעמוד לעמוד ולכן ההתייחסות הנדרשת היא פרטנית. טיפול זה נעשה לרוב "In-House", ע"י הדרכת צוות התוכן של האתר להנגשת תכנים, ולכן צריך להתבצע בנפרד ובמקביל להליך הפיתוח. רצוי לבצע זאת מוקדם ככל האפשר ולא להמתין לאתר הסופי, מפני שהנגשת התכנים מצריכה לעיתים זמן רב (למשל, במקרים של תמלול תכני וידאו או שמע). באתר קיים מומלץ להתחיל קודם לטפל בתכנים קיימים ובתבניות עמודים לפי נפח השימוש - להתחיל בעמודים הנצפים ביותר ולהתקדם משם לעמודים ותכנים פחות שימושיים.

• תיקון ידני או אוטומציה: כאמור, ובדומה לתיקוני SEO, עבודת תיקונים על תוכן קיים עשויה להיות סיזיפית מאוד. עם זאת, נגישות ו-SEO הולכים לרוב יד ביד, ולכן באתר שהתוכן שלו טופל היטב מבחינת SEO - וכולל כותרות (H1, H2 וכו) מוגדרות היטב בכל עמוד, תגי מטא לכל תמונה, קישורים עם טקסט עוגן רלוונטי וכיו"ב - חלק גדול מעבודת התוכן הנדרשת לצרכי נגישות כבר בוצעה.

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

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

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

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

• עיגון הדרישה לרמת הנגישות שנבחרה בחוזה ההתקשרות עם חברת הפיתוח: לחלק זה משמעויות חוקיות וכלכליות נרחבות. היות ובעלי האתר נדרשים עפ"י חוק לספק אתר נגיש, אך אינם בונים אותו בפועל, מומלץ לעגן  בחוזה ההתקשרות עם חברת הפיתוח את רמת הנגישות הנדרשת באופן מחייב חוקית. המלצה זו נכונה גם לפיתוח ובנייה של אתר חדש וגם בביצוע שינויים באתר קיים. שימו לב שלאור השינויים התכופים בתחום וטכניקות ההתאמה הרבות הקיימות (מעל ל-400 הנחיות רק במסמך ה WCAG 2.0), מומלץ לעגן את הדרישות לרמת הנגישות הנדרשת (קרי A, AA או AAA) ולא להתאמת נגישות ספציפית.

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

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

נגישות אתרים - הליך שלם

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

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

יישמתי את כל ההתאמות - מה עכשיו?

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

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

האתר מוכן? ספרו לעולם

ברכותינו, זה הזמן לספר לעולם על התהליך החיובי שהשלמתם באתרכם. מעבר לרצון להראות לכולם שהאתר שלכם נגיש, קיימת גם חובה חוקית לציין באתר כי בוצעו התאמות לנגישות [ראו תקנה 35/ח (04.2013) לחוק שוויון הזכויות לאנשים עם מוגבלות (1998)]. החוק מציין כי יש לסמן זאת במקום בולט, אך אין פרוט בחוק לדרך הציון.

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

הנגשת אתרים - צורת עבודה ולא הליך חד פעמי

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

לכן, אם תעשו שימוש במערכות אוטומטיות, תגלו שתג המחיר כולל גם עלויות "תחזוקה" לשנים הבאות.

אם ביצעתם את התאמות הנגישות בעזרת הצוות שלכם (in-house), רצוי למנות באתר רכז נגישות, שידאג שכל שינוי באתר יעמוד בתקן.

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

הלכתי לאיבוד - למי לפנות לעזרה?

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

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

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

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

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

צריכים גם אתם להנגיש אתר אינטרנט? זקוקים לייעוץ ולהכוונה? רוצים ליהנות מניסיוננו הרחב בתחום הנגשת אתר? כנסו לדף "ייעוץ וליווי הנגשת אתרי אינטרנט" ונסייע לכם ליצור אתר נגיש לכלל הגולשים

עבודה עם תקן הנגישות WCAG 2.0

הסעיפים הבאים מפרטים את הכללים הנדרשים להשגת כל אחת מרמות הנגישות המפורטות בחוק (ובתקן WCAG 2.0 ותקן ת"י 5568). רמות הנגישות בנויות זו על גבי זו, משמע - להשגת רמה AA, יש לעמוד בכל הדרישות להשגת רמה A  ובדרישות נוספות. באופן דומה, להשגת רמה AAA, יש להשיג את כל הדרישות לרמה A ובכל הדרישות לרמה AA ובדרישות נוספות.

החוק ממליץ לכלל אתרי האינטרנט לשאוף להשיג את רמת הנגישות הגבוהה ביותר (AAA), אך בפועל אינו מחייבם להשיג רמה זו (מסתפק ב AA).

תקן WCAG 2.0 כולל 4 עקרונות איכותיים להתאמת אתר (ראו פרוט בתרשים המצורף), מהם נגזרות 12 הנחיות. כל הנחיה מכילה מספר דרישות לתאימות לנגישות. הדרישות הינן מה שיש לבצע בפועל, ועמידה בהן מבטיחה יצירת אתר נגיש. עם זאת - הדרישות אינן מסבירות איך לבצע.

ישנן מאות טכניקות ביניהן נאלצים מפתחים לבחור (בהתאם למצב) על-מנת  ליישם את הדרישות הנ"ל.

נשמע ערטילאי? ובכן, הכי פשוט יהיה להביט בתקן עצמו על מנת להבין. צילום המסך המצורף מראה את המבנה הנ"ל. שימו לב שתמיד העיקרון ממוספר ברמה הראשונה בהיררכיה (קרי 1, 2, 3 או 4), ההנחיה ברמה שנייה (1.1), והדרישה ברמה שלישית (1.1.1).  שימו לב גם כי כל דרישה בתקן מכילה קישור להסבר ("הבנת הנחיה") וכן לטכניקות הנדרשות ליישום על מנת לעמוד בדרישה ("כיצד לענות על...").

מבנה עקרונות והנחיות בתקן WCAG 2.0 (צילום מסך מתוך: https://www.isoc.org.il/w3c-wai/guidelines.html#text-equiv)

לחיצה על הקישור לטכניקות (בצילום המסך לעיל - הקישור "כיצד לענות על 1.1.1") תעביר את הגולש למיקום מדויק בנספחי התקן המכיל הנחיות טכניות מפורטות למפתחים:

• הסבר ההנחיה
• טכניקות פיתוח מומלצות שיישומן יאפשר השגת רמת הנגישות הנדרשת (Sufficient techniques)
• טכניקות פיתוח מומלצות שיישומן אינו נדרש לעמידה בעיקרון, אך יסייע להשגת רמת נגישות מקבילה או גבוהה מהנדרש (Advisory techniques)
• דוגמאות לטכניקות נפוצות שאינן עומדות בדרישות (שיישומן יביא לכישלון ביישום העיקרון- Failure to achieve required level)
• דוגמאות ליישום מוצלח

טכניקות ליישום הנחיות בתקן WCAG 2.0 (צילום מסך מתוך: http://www.w3.org/WAI/WCAG20/quickref/#qr-content-structure-separation-sequence)

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

תקציר דרישות ההתאמה עפ"י רמת הנגישות הנדרשת בחוק

רמת נגישות A - כלל אתרי האינטרנט המחויבים בהתאמה לנגישות  

זוהי  רמת הנגישות הנמוכה ביותר בתקן. כל אתר אינטרנט הכפוף לחוק הישראלי מחויב בהשלמת כל ההתאמות המפורטות ברמה זו (כחלק מהדרישה לעמידה ברמה AA יש צורך לעמוד גם ב A).

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

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

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

• פקדים, קלט: אם תוכן שאינו טקסט הוא פקד (למשל, שדות הזנה בטופס), או מקבל קלט מהמשתמש, יהיה לו שם המתאר את תכליתו (ראו הנחיה 4.1 לדרישות נוספות בעניין פקדים ותוכן המקבל קלט מן המשתמש).
• מדיה מבוססת־זמן: אם תוכן שאינו טקסט הוא מדיה מבוססת זמן (כגון וידאו או שמע), תספק החלופה הטקסטואלית, לכל הפחות, אמצעי זיהוי שיש בו כדי לתאר את התוכן (ראו הנחיה 1.2 לדרישות נוספות בעניין מדיה).
• מבחן: אם תוכן שאינו טקסט משמש למבחן או לתרגיל, והצגתו כטקסט סותרת את תכליתו, תספק החלופה הטקסטואלית, לכל הפחות, אמצעי זיהוי שיש בו כדי לתאר את התוכן.
• חוויה חושית: אם תוכן שאינו טקסט נועד בעיקר ליצור חוויה חושית מסוימת, תספק החלופה הטקסטואלית, לכל הפחות, אמצעי זיהוי שיש בו כדי לתאר את התוכן.
• CAPTCHA : אם מטרתו של תוכן שאינו טקסט לוודא שהניגש לתוכן הוא אדם ולא מחשב, יש לספק חלופה טקסטואלית שתזהה את התוכן ותתאר את תכליתו, בנוסף לצורות חלופיות של CAPTCHA המכוונות לתפיסה בחושים אחרים, ומתאימות למוגבלויות שונות.
• קישוט, עיצוב, תוכן בלתי נראה: אם תוכן שאינו טקסט הוא קישוט בלבד, או אם הוא משמש אך ורק לעיצוב חזותי, או אם הוא אינו מוצג למשתמש, הוא ימומש באופן המאפשר לטכנולוגיה מסייעת להתעלם ממנו.

קישור למפתחים: איך לבצע את 1.1.1

1.3 גמישות: יש ליצור תכנים הניתנים להצגה בדרכים שונות (למשל, בפריסה פשוטה יותר) בלי איבוד מידע או מבנה .

1.3.1  מידע וקשרים: מידע, מבנה וקשרים המועברים למשתמש באמצעות עיצוב יהיו ניתנים לזיהוי על־ידי תוכנה או שיהיו זמינים כטקסט (למשל: שימוש באלמנט H1 לתיוג כותרת, ולא רק שימוש ב-CSS  בכדי לעצב את הטקסט שיראה ככותרת. כך, גם ללא CSS ניתן יהיה לזהות כי מדובר בכותרת).

קישור למפתחים: איך לבצע את 1.3.1

1.3.2  סדר בעל משמעות: במקרה שבו סדר הצגת התוכן משפיע על משמעותו, סדר הקריאה הנכון יהיה ניתן לזיהוי על־ידי תוכנה.
2 דוגמאות ל"סדר בעל משמעות":

• שילוב משפט באנגלית, או מילים באנגלית המופרדות בפסיק בתוך טקסט עברי.
• טבלה המשמשת לעיצוב שבה האלמנטים נמצאים באותה עמודה אך בשורות שונות (שימו לב כי מומלץ להשתמש בטבלאות לשם הצגת תוכן טבלאי, ולא לשם עיצוב מראה הדף).

קישור למפתחים: איך לבצע את 1.3.2

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

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

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

1.4.2  שליטה בשמע: במקרה שבו קטע שמע מתנגן באופן אוטומטי למשך יותר מ־3 שניות, יהיה מנגנון המאפשר לעצור את הנגינה או להפסיק אותה כליל, או מנגנון לשליטה בעוצמת השמע בלי תלות בעוצמת השמע הכללית במערכת.
הערה: כל תוכן שאינו עונה על הקריטריון הזה עלול להפריע לשימוש בדף כולו. לפיכך, תוכן הדף כולו חייב לעמוד בקריטריון הזה (בין אם הוא משמש לעמידה בקריטריונים אחרים, ובין אם לאו) ראו דרישת התאמה 5: מניעת הפרעות.
קישור למפתחים: איך לבצע את 1.4.2

2.1 נגישות מהמקלדת: יש לדאוג לאפשרות לבצע את כל הפעולות באמצעות המקלדת.

2.1.1  מקלדת: כל הפעולות הקשורות בתוכן יהיו ניתנות לביצוע באמצעות מנשק מקלדת, בלי דרישה לקצב הקלדה מסוים, למעט מקרים שבהם הקלט תלוי במעקב אחר תנועות המשתמש ולא רק בערך הסופי של ההקלדה.
הערה 1: החריג הנזכר לעיל מתייחס לקלט הנדרש לשם השלמת הפעולה, ולא לשיטת ההזנה של הקלט. לדוגמה, אם המשתמש מזין טקסט באמצעות כתיבה ידנית, שיטת הזנת הקלט (כתב יד) אמנם תלויה במעקב אחר תנועות המשתמש, אבל להשלמת הפעולה נדרש רק הטקסט הסופי.
הערה 2: אין הכוונה לאסור על הזנת קלט באמצעות העכבר, או בדרך אחרת, בנוסף לאפשרות השימוש במקלדת – מתן אפשרויות כאלה מקובל בהחלט.
קישור למפתחים: איך לבצע את 2.1.1

2.1.2  בלי "מלכודות מקלדת: "יש לאפשר הסרה של מוקד המקלדת (הפוקוס) ממרכיב כלשהו בדף באמצעות מנשק המקלדת בלבד, אם העברת המוקד למרכיב נעשית באמצעות המקלדת. יש ליידע את המשתמש לגבי אופן הסרת מוקד המקלדת, אלא אם מדובר בשימוש במקש "טאב", במקשי החצים הרגילים או בדרך סטנדרטית אחרת לביצוע פעולה כזאת.
הערה: כל תוכן שאינו עונה על הקריטריון הזה עלול להפריע לשימוש בדף כולו. לפיכך, תוכן הדף כולו חייב לעמוד בקריטריון הזה (בין אם הוא משמש לעמידה בקריטריונים אחרים, ובין אם לאו) ראו דרישת התאמה 5: מניעת הפרעות.
קישור למפתחים: איך לבצע את 2.1.2

2.2 משך זמן מספיק: יש לתת למשתמשים זמן מספיק כדי לקרוא את התוכן ולהשתמש בו .

2.2.1  אפשרות להתאמה אישית של מגבלות הזמן: בכל מקרה שבו התוכן קובע מגבלת זמן, יש   לדאוג לפחות לאחד הדברים הבאים:

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

חריגים:

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

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

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

• תנועה, הבהוב, גלילה: יש לקבוע מנגנון שיאפשר למשתמש לעצור, להפסיק או להסתיר מידע המופיע נע, מהבהב או נגלל, אם הוא (1) מופיע באופן אוטומטי, (2) נמשך יותר מחמש שניות, (3) מוצג במקביל לתוכן אחר; למעט מקרים שבהם התנועה, ההבהוב או הגלילה מהותיים לפעולה מסוימת.
• עדכון אוטומטי: יש לקבוע מנגנון שיאפשר למשתמש לעצור, להפסיק או להסתיר מידע המתעדכן באופן אוטומטי, או שיאפשר שליטה בתדירות העדכון, אם המידע (1) מופיע באופן אוטומטי, (2) מוצג במקביל לתוכן אחר; למעט מקרים שבהם העדכון האוטומטי מהותי לפעולה.

הערה 1: לדרישות בעניין תוכן עם הבזקים או הבהובים ("פליקרים", "פלאשים"), ראוהנחיה 2.3.

הערה 2: כל תוכן שאינו עונה על הקריטריון הזה עלול להפריע לשימוש בדף כולו. לפיכך, תוכן הדף כולו חייב לעמוד בקריטריון הזה (בין אם הוא משמש לעמידה בקריטריונים אחרים, ובין אם לאו) ראו דרישת התאמה 5: מניעת הפרעות.

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

הערה 4: הנְפּשׁה (אנימציה) המופיעה כחלק מפתיח לפני טעינת התוכן, או במצב דומה אחר, יכולה להיחשב מהותית, אם אין כל אפשרות לאינטראקציה עם אף אחד מהמשתמשים, ואם היעדר סימון להתקדמות עלול לבלבל את המשתמשים או לגרום להם לחשוב שהתוכן נתקע או התקלקל.
קישור למפתחים: איך לבצע את 2.2.2

2.3 התקפים אפילפטיים: אין לעצב תכנים באופן הידוע כגורם להתקפים אפילפטיים .

2.3.1  לא יותר משלושה הבזקים או מתחת לסף: אין לכלול בדפי רשת דבר היוצר יותר משלושה הבזקים בשנייה אחת, אלא אם תדירות ההבזקים היא מתחת לסף הכללי להבזקים ולהבזקים אדומים.
הערה: כל תוכן שאינו עונה על הקריטריון הזה עלול להפריע לשימוש בדף כולו. לפיכך, תוכן הדף כולו חייב לעמוד בקריטריון הזה (בין אם הוא משמש לעמידה בקריטריונים אחרים, ובין אם לאו) ראו דרישת התאמה 5: מניעת הפרעות.
קישור למפתחים: איך לבצע את 2.3.1

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

2.4.1  עקיפת קטעים חוזרים: יש לקבוע מנגנון שיאפשר למשתמש לעקוף קטעי תוכן שחוזרים שוב ושוב בדפי רשת רבים באתר.
קישור למפתחים: איך לבצע את 2.4.1

2.4.2  כותרת לכל דף: יש לתת לדפי רשת כותרות שיתארו את נושא הדף או את תכליתו.
קישור למפתחים: איך לבצע את 2.4.2

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

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

3.1 קריאוּת: יש ליצור תוכני טקסט קריאים ונהירים.

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

3.2 תפקוד באופן צפוי: יש ליצור דפי רשת שיופיעו ויתפקדו באופן צפוי .

3.2.1  מיקוד (on focus): העברת המוקד (פוקוס) למרכיב מסוים בדף רשת לא תגרום לשינוי בקונטקסט. למשל, אין להציג חלון קופץ כתוצאה מפוקוס על רכיב מסוים.
קישור למפתחים: איך לבצע את 3.2.1

3.2.2  קלט (on input): שינוי רכיב בדף דרך מרכיב כלשהו במנשק המשתמש (כגון הזנת טקסט או בחירת אפשרות בטופס) לא יגרום לשינוי בקונטקסט באופן אוטומטי, אלא אם המשתמש קיבל התרעה על כך לפני השימוש במרכיב (למשל, אין להעביר לדף חדש מתוך combo-box).
קישור למפתחים: איך לבצע את 3.2.2

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

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

3.3.2  תוויות או הוראות: יש לספק תוויות (labels) או הוראות (instructions) כאשר התוכן מחייב קלט מהמשתמש.
קישור למפתחים: איך לבצע את 3.3.2

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

4.1.1  תחביר תקין (Parsing): בתוכן המופק באמצעות שפת סימני עריכה
(markup language) יהיו לכל הרכיבים תגיות פתיחה וסיום בשלמותן. קינון הרכיבים יהיה לפי הוראות השימוש בהם. הרכיבים לא יכללו תכונות כפולות (duplicate attributes). כל סימני הזיהוי (ID)  יהיו ייחודיים. חריגה מהכללים האלה אפשרית אך ורק אם הוראות השימוש ברכיב מתירות זאת.
הערה: תגיות פתיחה וסיום שחסר בהן תו הכרחי, למשל סוגר זוויתי (<), מרכאות (") המקיפות ערך של תכונה וכדומה, לא ייחשבו כתגיות המופיעות בשלמותן.
קישור למפתחים: איך לבצע את 4.1.1

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

4.2.  רמת נגישות AA - אתרי רשויות ציבוריות וכל אתר שלא קיבל פטור מרמה זו

עפ"י חוק, ברמה AA מחויבים כל אתרי רשויות ציבוריות, החל מה 01.07.13 (עם "תקופת התאמה" לביצוע השינויים הנדרשים עד ה 01.01.16 לאתרים קיימים, או 01.07.15 לאתרים שיושקו לאחר כניסת החוק לתוקף).

כל אתר אחר (אתרים עם 30 עמודים ומעלה שאינם אתרי רשויות ציבוריות) מחויב לבצע התאמות נגישות ברמה AA אלא אם כן קיבל פטור מכך:
לפי עקרון הנטל הכבד (ראו סעיף 19 יב ו19 יג בחוק שוויון הזכויות לאנשים עם מוגבלות, ותקנות החוק לשוויון זכויות לאנשים עם מוגבלות (התאמת נגישות לשרות) מתאריך 25.04.13), אם נטל ההתאמות כבד מידי או לא סביר לביצוע, ניתן באישור מורשה נגישות לקבל פטור ולבצע התאמות לרמה A בלבד. עם זאת, עם השקת גרסה חדשה לאתר יהיה צורך בביצוע ההתאמות לAA (או להוכיח שוב שלא ניתן לבצע ההתאמות).

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

להלן פרוט הקריטריונים הנדרשים להשגת רמה AA. לשם הנוחות, המספר המצוין ליד כל הנחיה הינו מספר הקריטריון בתקן Wcag 2.0:

1.2 מדיה מבוססת־זמן: יש לספק חלופות למדיה מבוססת־זמן. (יש לשים לב כי דרוג החובה בישראל של סעיף זה ותת סעיפיו 1.2.1, 1.2.2 ו 1.2.3 שונה לרמה AA ע"י התקן הישראלי ת"י 5568 ולא A כפי שהופיע במקור ב Wcag 2.0).

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

• שמע־בלבד מוקלט מראש: יש לספק חלופה למדיה מבוססת־הזמן, חלופה טקסטואלית שתעביר את כל המידע הכלול בתוכנו של קטע השמע־בלבד המוקלט מראש.
• וידאו־בלבד מוקלט מראש: יש לספק חלופה טקסטואלית למדיה מבוססת־הזמן, או פס־קול, כך שיעבירו את אותו המידע הכלול בתוכנו של קטע הווידאו־בלבד המוקלט מראש.

קישור למפתחים: איך לבצע את 1.2.1

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

1.2.3  תיאור בשמע או חלופה למדיה (הקלטה מראש): למדיה מסונכרנת יש לספק חלופה למדיה מבוססת־הזמן, ו תיאור בשמע של תוכני הווידאו המוקלטים מראש, בערוץ שמע נפרד, למעט במקרה שהמדיה היא חלופה לטקסט ומסומנת כך באופן ברור. על החלופה הטקסטואלית להעביר את כל ההתרחשות (כולל תיאור רעשים, מאורעות והתנהלות ולא רק מלל).
קישור למפתחים: איך לבצע את 1.2.3

1.2.4  כתוביות (שידור חי): יש לספק כתוביות במדיה מסונכרנת לכל שידור חי של תוכן בשמע.
קישור למפתחים: איך לבצע את 1.2.4

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

1.4.3  ניגוד (מינימום): הצגה חזותית של טקסט ושל תמונות טקסט תקיים יחס־ניגוד של 4.5:1 לפחות, למעט במקרים הבאים:

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

קישור למפתחים: איך לבצע את 1.4.3

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

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

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

הערה: טקסט שהוא חלק מסמליל נחשב למקרה יוצא־דופן, לפי סעיף "הכרחיוּת" לעיל.

קישור למפתחים: איך לבצע את 1.4.5

2.4.5  ריבוי דרכים: איתור של דף רשת בתוך סדרה של דפים יהיה אפשרי ביותר מדרך אחת, אלא אם הדף הוא תוצאה של תהליך או שלב במהלכו.
קישור למפתחים: איך לבצע את 2.4.5

2.4.6  כותרות ותוויות: יש להשתמש בכותרות (headings) ותוויות (labels) כדי לתאר נושא או תכלית.
קישור למפתחים: איך לבצע את 2.4.6

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

2.4.10  כותרות לקטעים: (יש לשים לב כי דרוג החובה של סעיף זה בישראל שונה ל AA ע"י התקן הישראלי ת"י 5568 ולא AAA כפי שהופיע במקור ב Wcag 2.0)
יש להשתמש בכותרות קטעים (section headings) לשם ארגון התוכן- בכל דף רשת המכיל תוכן טקסטואלי בעל מבנה היררכי, יצוינו כותרות בתגית כותרת ב HTML (H1, H2 וכן הלאה).
הערה 1: המונח "כותרת" (heading) משמש כאן במשמעותו הרחבה, כך שהוא כולל titles ודרכים אחרות להוספת כותרות לסוגים שונים של תוכן.
הערה 2: קריטריון זה נוגע לקטעים בתוכן כתוב, ולא למרכיבים במנשק המשתמש. קריטריון 4.1.2 עוסק במרכיבים של מנשק המשתמש.
קישור למפתחים: איך לבצע את 2.4.10.

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

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

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

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

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

1. הפיכוּת: פעולות המשתמש יהיו הפיכות.
2. בדיקה: הנתונים שהמשתמש הזין ייבדקו לאיתור שגיאות בקלט, והמשתמש יקבל הזדמנות לתקן את השגיאות.
3. אישור: ייקבע מנגנון שיאפשר למשתמש לסקור את המידע שהכניס, לאשר אותו, או לתקן אותו, לפני השלמת הפעולה.

קישור למפתחים: איך לבצע את 3.3.4

רמת נגישות AAA - רשות לכלל האתרים

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

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

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

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

1.2.9  שמע־בלבד (שידור חי): יש לספק חלופה למדיה מבוססת־הזמן כך שתעביר את אותו המידע הכלול בתוכנו של קטע ה שמע־בלבד המשודר בשידור חי .
קישור למפתחים: איך לבצע את 1.2.9

1.4.6  ניגוד (מוגבר): הצגה חזותית של טקסט ושל תמונות טקסט תקיים יחס־ניגוד של 7:1 לפחות, למעט במקרים הבאים:

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

קישור למפתחים: איך לבצע את 1.4.6

1.4.7  היעדר שמע, או שמע מתנגן ברקע בעוצמה נמוכה: כשמדובר בתוכן שמע בלבד, שהוקלט מראש, והוא (1) כולל בעיקר דיבור כתוכן עיקרי (ב"חזית"), (2) אינו CAPTCHA מושמע או סמליל קוֹלי, (3) אינו ביטוי־קולי שנועד בעיקרו להבעה מוזיקלית כגון שירה או "ראפ", יתקיים לפחות אחד מאלה:

• אין רקע: השֵמע אינו כולל קולות רקע.
• השתקה: אפשר להשתיק את קולות הרקע.
• פער של 20 דציבלים: העוצמה של קולות הרקע נמוכה ב־20 דציבלים לפחות מקולות הדיבור שב"חזית" (הקולות העיקריים), למעט קולות הנשמעים מדי פעם למשך שנייה או שתיים.

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

קישור למפתחים: איך לבצע את 1.4.7

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

1. אפשרות לבחירת צבעי החזית והרקע בידי המשתמש.
2. רוחב שאינו עולה על 80 תווים או גליפים (40 במקרה של סימניות בשפות מזרח אסיאתיות).
3. הטקסט אינו מיושר לשני הצדדים.
4. ריווּח שורות של 1.5 לפחות (כלומר, המרווח בין השורות לא יפחת מגובה שורה וחצי). הרווח בין הפסקאות יהיה פי 1.5 לפחות מהרווח בין השורות.
5. אפשרות לשנות את גודל הטקסט בשיעור של עד 200% בלי שימוש בטכנולוגיית עזר, ובלי לאלץ את המשתמש להשתמש בגלילה אופקית כדי לקרוא שורה כלשהי בטקסט בתצוגת מסך מלא.

קישור למפתחים: איך לבצע את 1.4.8

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

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

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

2.2.4  הפרעות: יש לאפשר למשתמש לדחות הפרעות או להשעות אותן, אלא אם מדובר בהפרעות עקב מצב חירום.
קישור למפתחים: איך לבצע את 2.2.4

2.2.5  אימות מחדש של זהות: יש לאפשר למשתמש להמשיך בביצוע פעולה בלא אובדן נתונים, לאחר אימות מחדש של זהותו, אם תוקפו של השׂיח (session) פקע.
קישור למפתחים: איך לבצע את 2.2.5

2.3.2  לא יותר משלושה הבזקים: אין לכלול בדפי רשת דבר היוצר יותר משלושה הבזקים בשנייה אחת.
קישור למפתחים: איך לבצע את 2.3.2

2.4.8  מיקום: מידע על מיקומו של המשתמש בתוך סדרה של דפי רשת יהיה זמין.
קישור למפתחים: איך לבצע את 2.4.8

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

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

3.1.4  קיצורים: יש לקבוע מנגנון שיאפשר לקבל, עבור קיצורים, את הביטוי המלא שהם מייצגים או את פירושם.
קישור למפתחים: איך לבצע את 3.1.4

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

3.1.6  הגייה: במקרה שבו מילה בהקשר הנתון היא רב־משמעית, אלא אם יודעים איך להגות אותה, יש לקבוע מנגנון שיאפשר למשתמש לזהות את אופן ההגייה הייחודי של המילה.
קישור למפתחים: איך לבצע את 3.1.6

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

3.3.5  עזרה: יש לספק עזרה תלוית הקשר.
קישור למפתחים: איך לבצע את 3.3.5

3.3.6  מניעת שגיאות (הכול): דפי רשת הדורשים מהמשתמש למסור מידע, יקיימו לפחות אחד מהדברים הבאים:

1. הפיכוּת: פעולות המשתמש יהיו הפיכות.
2. בדיקה: הנתונים שהמשתמש הזין ייבדקו לאיתור שגיאות בקלט, והמשתמש יקבל הזדמנות לתקן את השגיאות.
3. אישור: ייקבע מנגנון שיאפשר למשתמש לסקור את המידע שהכניס, לאשר אותו, ולתקן אותו, לפני השלמת הפעולה.

קישור למפתחים: איך לבצע את 3.3.6

קישורים ומקורות נוספים לנושא

חוקים ותקנים

חוק שוויון זכויות לאנשים עם מוגבלות התשנ"ח-1998

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

תקן מכון התקנים ת"י 5568 (קישור לתקן באתר מכון התקנים הישראלי)- מהווה מקור חוקי להתאמות הנדרשות לכל אתר, אך מכיל בפועל הפנייה לתקן ה Wcag 2.0 והתאמות ישראליות מחייבות ל Wcag 2.0

תקן Wcag 2.0  בעברית (קישור לתקן באתר ארגון W3c)- התקן המפרט בפועל את התאמות הנגישות הנדרשות לביצוע:

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

http://www.w3.org/WAI/WCAG20/quickref

תקן לפרסום "הצהרת התאמה חלקית" לעמוד עם תוכן ממקור חיצוני שלא ניתן להתאמה (מתוך תקן Wcag 2.0)

http://www.w3.org/TR/2008/REC-WCAG20-20081211/#conformance-partial

אתרים רלוונטיים

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

http://www.justice.gov.il/MOJHeb/NetzivutNEW

מרכז המידע לנגישות של הנציבות לשוויון זכויות לאנשים עם מגבלות (אתר המשפטים)

http://index.justice.gov.il/Units/NetzivutShivyon/MercazHameidaLenegishut/Pages/default.aspx

אתר עמותת נגישות ישראל:

http://www.aisrael.org

אתר "אתר נגיש"- מקור מידע לנגישות אתרים באינטרנט
http://www.nagish.org.il

כלים וטכניקות לנושאים נפוצים

כלים לבדיקת קונטראסט

• Colour Contrast Check
• Colour Contrast Analyser
• Colour Contrast Visualiser
• Contrast Analyser, Version 2.0

רשימת קישורים להסברים על יצירת כתוביות לפורמטים המרכזיים:

• כתוביות לQuicktime
• כתוביות לRealPlayer
• כתוביות לWindows Media
• כתוביות לReal-Time
• הוראות להוספת כתוביות לסרטונים ב you tube. אם אתם מוסיפים כתוביות לסרט בyoutube ניתן להגדיר שהכתוביות יוצגו כברירת מחדל.

טכניקות לטיפול בגודל טקסט

1. הגדירו גודל הפונט ביחידות יחסיות – אחוזים, שם (small, large….), ו- em.
2. חישוב גודל ומיקום לתמיכה בהגדלה תקינה של טקסט
3. מתן אמצעי להגדלת הטקסט באתר עד 200%
4. שימוש ב  liquid layout