טכניקות

 

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

 

 

 

השפעות נראות לעין

 

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

 

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

 

אבל לכל האפקטים הויזואלים האחרים, תיאור כזה צריך להיכלל.

 

דוגמא:

לכלול alt text פונקציונלי עם סקריפט שיופיע בתמונה (כמו תמונה של כפתור המשמש לשנות את הגודל של המסגרת) ולתת הסבר על הפונקציה שממלא הסקריפט (כמו "הוסף פריט").

 

דוגמא:

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

 

דוגמא:

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

  

 

חלונות קופצים

 

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

 

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

 

 

פתרון

 

פונקציה המשנה את הקדימויות. לדוגמה שימוש בקישור רגיל לדף אלטרנטיבי (ללא pop up) ובמקום זה onclick לאלה שמשתמשים בדפדפן העובד עם javascript. ה-on-click  יחזיר "שגוי" בכדי לאפשר לדפדפן שעובד עם javasdript לראות את הpop-up :

 

<a href="alternativepage.html" onclick ="activateFunction();return false">

עם זאת, יש לזכור את המגבלות של מנהלי אירועים תלויי-התקן, כגון on-click. זכרו שכל javascript שאתם כותבים צריך להיות זמין למשתמשים חסרי עכבר (בדוגמא הזו, צריך להוסיף מנהל אירוע של "onkeypress" למשתמשים במקלדת.

 

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

 

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

 

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

 

 

גרימת אירוע

 

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

 

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

 

 

 

נושאים והמלצות במנהלי אירועים ספציפיים

1.לא להשתמש ב-ondbkckick. אין לזה מקבילה במקלדת.

2. לא להשתמש mouse-coordinate event handler.

3.מקרים אחרים של שימושי עכבר יכולים לעבוד עם מקבילה במקלדת:

·        Onmousedown with onkeydown.

·        Onmouseup with onkeyup.

·        Onckick with onkeypress – אפשרי לספק onclick לבד ,כיוון שאצל משתמשים רבים שאופציה זו נגישה גם מהמקלדת ,אבל היישום הזה דורש בדיקה יסודית.

3.מקרים אחרים של שימושי עכבר יכולים לעבוד עם מקבילה במקלדת:4. Onmouseover – חייב לבוא ביחד עם onfocus (ו- onblur יחד עם Onmousout) כדי לאפשר לקלוט רק מהמקלדת. הפתרון הזה יכול לדרוש את התוספת של TABINDEX . זה ידרוש בדיקה יסודית, והקוד יראה קצת לא יציב. ראה דוגמאות ליישומים ב- discussion of event handler issues .

 

 

תפריטים מתרחבים 

 

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

 

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

 

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

 

 

תפריטי גלילה

 

אל תיצור תפריטי גלילה אשר בוחרים שימוש בonChange handler.אדם המשתמש רק במקלדת לא יצליח לעבור בין כל האפשרויות, ויבחר את מה שמופיע ראשון בתפריט, כפי שראית בדוגמא של Types of cancer .AwindowsE key combination (ALT+Down Arrow key) יאפשרו למשתמשים במקלדת לעבור בתוך הרשימה, אבל זה לא עובד בNetScape וגם לא עובד בIEMac, והרבה משתמשים שהם חדשים בשימוש במקלדת לא יכירו את הקומבינציה של המקרים האלה. חוץ מזה לחיצה על שני מקשים בו זמנית יכול להוות מכשול לאנשים עם מוגבלויות שונות.

 

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

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

 

פתרונות

 

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

 

פתרון מס' 2: ישנה אפשרות ליצור תפריט גלילה נגיש ב-javascript ללא צורך להשתמש בתוכנת צד-שרת, ראה מדריך בנושא תפריטי גלילה נגישים עם javascript מאת Bill Trefzqer.  

 

כדאי להסתכל גם על הפתרון של Broun  שנעשה עבור NCI Library Online Oriject שמשתמש בjavascript popup  אבל מאפשר למשתמש לכבות את האופציה הזו ולהשתמש בפתרון נגיש במקום.

 

 

המלצות נוספות

 

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

 

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

 

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

 

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

 

דוגמא:

 

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

 

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