שירותי נגישות דיגיטלית, מהבדיקה ועד ההצהרה

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

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

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

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

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

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

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

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

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

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

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

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

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

חד משמעית לא. תוספי נגישות או סרגלי נגישות משפיעים רק על רכיבי ה-HTML של דפי האתר. הם לא נכנסים לתוך קובצי PDF, Word או Excel ולא מתקנים את המבנה הפנימי. הנגשת מסמכים חייבת להתבצע על הקובץ עצמו.

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

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

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

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

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

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

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

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

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

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

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

תלוי בגודל האתר, בתבנית ובמורכבות הרכיבים. אחרי מיפוי מקבלים לוח זמנים והיקף ברורים לפני תחילת תיקונים.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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