פרק #15 | המשך לבדיקות נגישות עם אלון פרידמן ויסברד
המשך לבדיקות נגישות עם אלון פרידמן ויסברד והפעם נכנסים לנושאים טכניים
בדיקות נגישות חלק ב
חלק ב' בנושא נגישות עם אלון פרידמן ויסברד, מומחה נגישות דיגיטלית בחברת Wix.
נתמקד בכלים ובאיך בודקים נגישות.
בפרק זה נצלול לבדיקות הנגישות עצמן. נכיר כלים ונעשה את הבדיקות hands-on, כאשר למעשה מדובר בפורמט של פודקאסט, המבוסס על שמיעה, אנחנו נתאר הכל באופן שיהיה נגיש למאזינים וגם לעיוורים.
הנחיות WCAG:
פועלים לפי הנחיות של ארגון האינטרנט הבינלאומי. קובץ ההנחיות לתוכן הנגיש באינטרנט הנקרא WCAG. בגרסה עדכנית 2.2. הגרסה מורכבת מעשרות קריטריונים, אשר מחולקים ל-4 קטגוריות-על עיקריות: Perceivable, Operable, Understandable, Robus. הקריטריונים מחולקים לשלוש רמות: A, AA, AAA. רמה A - הדרישות הבסיסיות ביותר.
רמה AA - דרישות חשובות ביותר אבל פחות.
רמה AAA - זה רמת ה nice-to-have שתיתן נגישות טובה מאוד, אבל לא מצופה שכל אתר יעמוד בכל הסעיפים האלה. רוב החקיקות בעולם וגם בישראל, סובבות סביב רמה AA.
כשניגשים לצ'קליסט כזה, חשוב תמיד לזכור קודם כל את המשתמשים ולהבין איך הם משתמשים באינטרנט, וכיצד הקריטריונים האלה עוזרים או מפריעים להם בחוויה שלהם.
בפודקאסט לא נעבור על כל הרשימה. ניקח כמה דוגמאות. מומלץ להיכנס ל WCAG ולקרוא בעצמכם.
בדיקות עם מקלדת:
ציועדת עבור אנשים המסוגלים להשתמש רק במקלדת ולא בעכבר, בגלל מוגבלות פיזית כלשהי משמש גם עבור אנשים שמשתמשים בכל טכנולוגיה מסייעת אחרת (כגון סוויצ'ים, ג'ויסטיקים וכו'). לדוגמה: אדם שמחזיק מקל בפה ומקליד בעזרתה במקלדת שמונחת אנכית מולו. חשוב לזכור את המשתמשים הללו, ולכבד את המאמץ שהם משקיעים.
מה בודקים?
נשתמש במקש ה-TAB המשמש אותנו לעבור בין אלמנטים אינטראקטיביים (קישורים, כפתורים, שדות טפסים וכו'). יש לשים לב שאלמנטים לא אינטראקטיביים כמו סתם טקסט לא אמורים להגיע אליהם עם TAB.
דבר ראשון - לוחצים על כפתור ה-TAB ועוברים על כל העמוד. רוצים לראות שמגיעים לכל דבר אינטראקטיבי. כלומר, אם דילגנו על כפתור, זו בעיה.
דבר שני - לשים לב שתמיד יש סימון ברור לפוקוס (דוגמת המלבן הכחול שיש מסביב). אחרת לא נדע איפה הפוקוס.
לגבי דפדפן הספארי - כברירת מחדל ה-TAB לא עובר בין כל האינטרקטיביים, אז מומלץ להיכנס להגדרות הנגישות ולסדר שיתנהג כ-TAB רגיל.
דבר שלישי - בלי עצירות מיותרות. כלומר, אם יש לנו תבנית של רשימת אירועים, ולכל אחד יש תמונה, כותרת ו"קרא עוד" וכל אחד מהם הוא לינק לאותו מקום, אז יש כאן סתם 3 לינקים במקום אחד. וכאמור, על חלק מהמשתמשים זה ממש מכביד.
דבר רביעי - יש לדאוג שהכל יהיה שמיש במלואו. כלומר, לא מספיק שהגעתי ללינק/כפתור, אם אני הגעתי ואני לוחץ ENTER ולא קורה כלום - זאת גם בעיה. בקיצור - לחזור על אותן בדיקות פונקציונליות של עכבר, עם מקלדת.
דבר חמישי - לוודא שיש "מעקף בלוקים". בשביל להקל על משתמשי מקלדת שכבר נמצאים באתר, ולא רוצים בכל עמוד לנווט דרך כל התפריט שנמצא ב-HEADER, אז מוסיף קישור שמדלג באופן ישיר אל התוכן הראשי. איך בודקים את זה? עושים קליק אחד בשדה של ה-URL בדפדפן, ומשם מתחילים ללחוץ על TAB. הדבר הראשון שאמורים להגיע אליו זה "קישור לתוכן הראשי", ולחיצה על ENTER עליו, הקישור אמור לדלג ישירות לתוכן הראשי.
הערה: ב-WIX זה מוטמע אוטומטית בכל האתרים, כך שגם לבודק אין מה לבדוק את זה בכל אתר מחדש וגם למי שבונה את האתר אין צורך לדאוג לזה. אלון ציין שזה אחד הדברים היפים ב-WIX, כשמוסיפים פיצ'ר כזה זה מתקן בבת אחת עשרות מיליוני אתרים.
נקודה אחרונה לגבי מקלדת - ניהול פוקוס. למשל לחצתי על כפתור - לאן הפוקוס עובר? דוגמה: לחצתי על כפתור לפתיחת מודול. השאלה האם הפוקוס נשאר על הכפתור "מאחורה" או שהוא עובר ישר לתוך המודול שנפתח. ההתנהגות הצפויה בפועל היא - שהפוקוס ייכנס לתוך המודאל (למשל לתוך שדה בטופס), אבל במקרה הכי גרוע - שיישאר מאחור ועם טאבים תשוטט באתר ולא יתאפשר כניסה למודול.
צבעים
נתחיל במה שמפריע למשתמשים שהם עיוורי צבעים: שימוש בצבע כאמצעי יחיד להעברת מידע. אם למשל אני נכנס לאתר של תוצאות כדורסל של קבוצה מסוימת, אם כתוב ליד כל תוצאה W או L לציון ניצחון/הפסד, ומופיע צבע ירוק/אדום בהתאם, זה בסדר. אבל (אם) לא יהיה את הסימון W/L אלא רק את הצבע - אז עיוורי צבעים לא יוכלו לקבל את המידע הזה. תוסף סימולטור של מוגבלויות, כולל עיוורון צבעים מסוגים שונים.
עוד טריק לבדיקה - לעשות "הדפסה בשחור לבן" ואז לראות אם כל התוכן ברור גם ללא צבעים.
ניגודיות צבעים
חישוב הניגודיות/קונטרסט נעשה בעזרת נוסחה מסובכת במסמכי WCAG. היחס בין שני הצבעים תמיד בטווח שבין 1:1 (הצבע על עצמו) לבין 21:1 (שחור על לבן / לבן על שחור - זה אותו דבר מבחינת החישוב).
ב-WCAG הרף המינימלי לניגודיות צבעים בין טקסטים היא 4.5:1.
בשביל לתת קצת מושג - למשל אדום על לבן זה 4:1.
לטקסטים גדולים יש "הנחה" קלה, ומספיק 3:1.
איך בודקים?
השיטה הכי מהירה וקלה - ה-inspector של CHROME - דרך F12 או ישירות CTRL+SHIFT+C שפותח ישר את הסמן של ה-INSPECTOR. ואם אני ארחף עם הסמן מעל טקסט, הוא יכתוב לי את הקונטרסט שלו, וגם יעשה לי V ירוק או X אדום שכבר מחשב אם זה עובר או לא את המינימום הנדרש. שימו לב שהחישוב שלו כבר לוקח בחשבון את גודל הטקסט, ולכן למשל 4:1 יקבל V ירוק אם הטקסט גדול מספיק.
שימו לב שאם רוצים לבדוק מצב HOVER של כפתור - הדבר היחיד שניתן לעשות, הוא לגרום למצב ה-HOVER ואז ללחוץ על קיצור המקלדת CTRL+SHIFT+C לפתיחת ה-INSPECTOR ואז תזוזה קטנה על הכפתור תיתן את קונטרסט הHOVER.
איך בודקים כשזה לא רקע אחיד? או כשזה על רקע של תמונה?
כלי בדיקה ראשון ה-CONTRAST CHECKER של WEBAIM. פשוט נכנסים לאתר שלהם בוחרים את שני הצבעים שרוצים למדוד את היחס ביניהם; כשבאים לבחור צבעים, ניתן להשתמש שם בטפטפת לדגימת צבעים. (שימו לב שצריך דפדפן כרום בשביל שהטפטפת תעבוד.)
כלי בדיקה שני: להשתמש בדפדפן פיירפוקס, ואפשר לעשות שם INSPECT לבדיקת קונטרסט אם יש רקע שאינו חלק, אז הוא נותן את כל טווח הקונטרסטים בין הטקסט לרקעים שסמוכים אליו.
ניגודיות של דברים שאינם טקסט - נגיד למשל אייקון של פייסבוק או של זכוכית מגדלת. שם הדרישה היא ל 3:1 בלבד (בדומה לטקסט גדול).
זום
בעבר הדרישה הייתה רק להגדלה של הטקסט ל 200%, ולראות שלא נעלם שום דבר והכל עובד.
מאז זה הפך להיות דרישה לזום של 400%, וצריך לוודא שלא רק ששום דבר לא נשבר או לא עובד, אלא שגם אין גלילה אופקית (או ליתר דיוק גלילה דו מימדית). כלומר מה שמעוניינים למנוע כאן זה את העובדה שמי שהגדיל את הטקסט יצטרך לגלול ימינה/שמאלה כל הזמן בשביל לקרוא את הטקסט. מה שרוצים שבעצם יקרה זה REFLOW - כלומר שהכל יסתדר בעמודה אחת ויתאים את הטקסט לרוחב הנתון.
מצד אחד צריך לשים לב שבמובייל לא מבטלים את ה-GESTURE של PINCH TO ZOOM. חובה לתמוך באפשרות של היוזר לעשות זום.
מצד שני, כדאי שתדעו, שיש לדפדפנים כיום אפשרות לדרוס את החסימה של האתר, ובכל זאת לאפשר זום במכשירי מגע.
טקסט ספייסינג
עוד בדיקה של מניפולציות של סטיילינג שהיוזר יכול לעשות:
יש דרישה שנקראת TEXT SPACING שאומרת בעצם שאם היוזר עשה רווח מסויים בין אותיות ובין השורות ובין פסקאות עדיין הכל צריך לעבוד ולהיות זמין.
הבדיקה לזה היא בעזרת BOOKMARKLET פשוט - בקישור הזה יש את הכלי - פשוט גוררים את זה לBOOKMARKS BAR ואז בקליק זה מייצר את הריווחים כפי הנדרש.
כיוון המסך
שימו לב שיש בדיקה חשובה - לוודא שבמובייל האתר מתאים את הכיווניות שלו בין מצב של PORTRAIT ו LANDSCAPE. זה נועד עבור משתמשים עם מגבלה פיזית אשר יושבים מול מכשיר שהוא מקובע בכיווניות מסוימת (לדוגמה LANDSCAPE) ואז הוא בעצם לא מסוגל לסובב את המסך ועל כן בלי להתאים את האתר לשני הכיוונים, זה לא יהיה שמיש עבורו.
הערה: יש מקרים חריגים שבהם זה מחייב כיוון מסויים, אז זה בסדר שאי אפשר לסובב. דוגמת אפליקציית פסנתר שהייתה מחייבת תצוגת LANDSCAPE ולא הייתה עובדת ב PORTRAIT וזה לגיטימי. (לעומת בלוג שסתם לא מסתובב - ששם זה באג שצריך לתקן).
קורא מסך
מתחילים בהדגמה קצרה של איך אתר סטארבאקס נשמע עם קורא מסך.
קורא מסך הינה תוכנה שלוקחת את הAPI של ה ACCESSIBILITY TREE שהיא נגזרת של ה DOM. מפשיטים מה HTML את כל הדברים העיצוביים הלא חשובים. מה שחשוב זה התוכן, הסדר שלו, ומה הסמנטיקה של הדברים - האם זה כפתור / לינק / תמונה / כותרת וכו'.
לאחר מכן זה מעביר דרך מנוע דיבור לקול עם מבטא כזה או אחר.
יש דרכים אחרות לתווך את המידע - כגון מסכי ברייל, שבהן המילים במקום להיות מוקראות פשוט מוצגות כטקסט ברייל.
בהדגמה שמענו כשקורא המסך לא מתאר סמנטית במדויק את מה שרואים על המסך. וגם נתקלנו בדוגמה שנעשתה פעולה אבל לא היה שום חיווי לקורא המסך. עשינו שימוש בדילוג אל תוכן ראשי. שמענו את הכותרת הראשית והכרנו את קיצור המקלדת H של קורא המסך NVDA אשר מעביר אותנו בין כותרות בעמוד. בנוסף, יש קיצורים 1-6 לצורך דילוג את הכותרת מסוג H1 / H2 / H3 הבא.
באתר הזה ראינו שיש H1 שהוא קיים ויחיד ברמה הטכנית אבל לא ממש מתאר את העמוד באופן מוצלח.
להורדת קורא המסך NVDA שהוא חינמי ופועל על מערכת ההפעלה WINDOWS.
מקווים שהפרק היה ברור ומועיל.
מוזמנים לשלוח תגובות ושאלות לקראת הפרק השלישי
בדיקות נגישות חלק ב
חלק ב' בנושא נגישות עם אלון פרידמן ויסברד, מומחה נגישות דיגיטלית בחברת Wix.
נתמקד בכלים ובאיך בודקים נגישות.
בפרק זה נצלול לבדיקות הנגישות עצמן. נכיר כלים ונעשה את הבדיקות hands-on, כאשר למעשה מדובר בפורמט של פודקאסט, המבוסס על שמיעה, אנחנו נתאר הכל באופן שיהיה נגיש למאזינים וגם לעיוורים.
הנחיות WCAG:
פועלים לפי הנחיות של ארגון האינטרנט הבינלאומי. קובץ ההנחיות לתוכן הנגיש באינטרנט הנקרא WCAG. בגרסה עדכנית 2.2. הגרסה מורכבת מעשרות קריטריונים, אשר מחולקים ל-4 קטגוריות-על עיקריות: Perceivable, Operable, Understandable, Robus. הקריטריונים מחולקים לשלוש רמות: A, AA, AAA. רמה A - הדרישות הבסיסיות ביותר.
רמה AA - דרישות חשובות ביותר אבל פחות.
רמה AAA - זה רמת ה nice-to-have שתיתן נגישות טובה מאוד, אבל לא מצופה שכל אתר יעמוד בכל הסעיפים האלה. רוב החקיקות בעולם וגם בישראל, סובבות סביב רמה AA.
כשניגשים לצ'קליסט כזה, חשוב תמיד לזכור קודם כל את המשתמשים ולהבין איך הם משתמשים באינטרנט, וכיצד הקריטריונים האלה עוזרים או מפריעים להם בחוויה שלהם.
בפודקאסט לא נעבור על כל הרשימה. ניקח כמה דוגמאות. מומלץ להיכנס ל WCAG ולקרוא בעצמכם.
בדיקות עם מקלדת:
ציועדת עבור אנשים המסוגלים להשתמש רק במקלדת ולא בעכבר, בגלל מוגבלות פיזית כלשהי משמש גם עבור אנשים שמשתמשים בכל טכנולוגיה מסייעת אחרת (כגון סוויצ'ים, ג'ויסטיקים וכו'). לדוגמה: אדם שמחזיק מקל בפה ומקליד בעזרתה במקלדת שמונחת אנכית מולו. חשוב לזכור את המשתמשים הללו, ולכבד את המאמץ שהם משקיעים.
מה בודקים?
נשתמש במקש ה-TAB המשמש אותנו לעבור בין אלמנטים אינטראקטיביים (קישורים, כפתורים, שדות טפסים וכו'). יש לשים לב שאלמנטים לא אינטראקטיביים כמו סתם טקסט לא אמורים להגיע אליהם עם TAB.
דבר ראשון - לוחצים על כפתור ה-TAB ועוברים על כל העמוד. רוצים לראות שמגיעים לכל דבר אינטראקטיבי. כלומר, אם דילגנו על כפתור, זו בעיה.
דבר שני - לשים לב שתמיד יש סימון ברור לפוקוס (דוגמת המלבן הכחול שיש מסביב). אחרת לא נדע איפה הפוקוס.
לגבי דפדפן הספארי - כברירת מחדל ה-TAB לא עובר בין כל האינטרקטיביים, אז מומלץ להיכנס להגדרות הנגישות ולסדר שיתנהג כ-TAB רגיל.
דבר שלישי - בלי עצירות מיותרות. כלומר, אם יש לנו תבנית של רשימת אירועים, ולכל אחד יש תמונה, כותרת ו"קרא עוד" וכל אחד מהם הוא לינק לאותו מקום, אז יש כאן סתם 3 לינקים במקום אחד. וכאמור, על חלק מהמשתמשים זה ממש מכביד.
דבר רביעי - יש לדאוג שהכל יהיה שמיש במלואו. כלומר, לא מספיק שהגעתי ללינק/כפתור, אם אני הגעתי ואני לוחץ ENTER ולא קורה כלום - זאת גם בעיה. בקיצור - לחזור על אותן בדיקות פונקציונליות של עכבר, עם מקלדת.
דבר חמישי - לוודא שיש "מעקף בלוקים". בשביל להקל על משתמשי מקלדת שכבר נמצאים באתר, ולא רוצים בכל עמוד לנווט דרך כל התפריט שנמצא ב-HEADER, אז מוסיף קישור שמדלג באופן ישיר אל התוכן הראשי. איך בודקים את זה? עושים קליק אחד בשדה של ה-URL בדפדפן, ומשם מתחילים ללחוץ על TAB. הדבר הראשון שאמורים להגיע אליו זה "קישור לתוכן הראשי", ולחיצה על ENTER עליו, הקישור אמור לדלג ישירות לתוכן הראשי.
הערה: ב-WIX זה מוטמע אוטומטית בכל האתרים, כך שגם לבודק אין מה לבדוק את זה בכל אתר מחדש וגם למי שבונה את האתר אין צורך לדאוג לזה. אלון ציין שזה אחד הדברים היפים ב-WIX, כשמוסיפים פיצ'ר כזה זה מתקן בבת אחת עשרות מיליוני אתרים.
נקודה אחרונה לגבי מקלדת - ניהול פוקוס. למשל לחצתי על כפתור - לאן הפוקוס עובר? דוגמה: לחצתי על כפתור לפתיחת מודול. השאלה האם הפוקוס נשאר על הכפתור "מאחורה" או שהוא עובר ישר לתוך המודול שנפתח. ההתנהגות הצפויה בפועל היא - שהפוקוס ייכנס לתוך המודאל (למשל לתוך שדה בטופס), אבל במקרה הכי גרוע - שיישאר מאחור ועם טאבים תשוטט באתר ולא יתאפשר כניסה למודול.
צבעים
נתחיל במה שמפריע למשתמשים שהם עיוורי צבעים: שימוש בצבע כאמצעי יחיד להעברת מידע. אם למשל אני נכנס לאתר של תוצאות כדורסל של קבוצה מסוימת, אם כתוב ליד כל תוצאה W או L לציון ניצחון/הפסד, ומופיע צבע ירוק/אדום בהתאם, זה בסדר. אבל (אם) לא יהיה את הסימון W/L אלא רק את הצבע - אז עיוורי צבעים לא יוכלו לקבל את המידע הזה. תוסף סימולטור של מוגבלויות, כולל עיוורון צבעים מסוגים שונים.
עוד טריק לבדיקה - לעשות "הדפסה בשחור לבן" ואז לראות אם כל התוכן ברור גם ללא צבעים.
ניגודיות צבעים
חישוב הניגודיות/קונטרסט נעשה בעזרת נוסחה מסובכת במסמכי WCAG. היחס בין שני הצבעים תמיד בטווח שבין 1:1 (הצבע על עצמו) לבין 21:1 (שחור על לבן / לבן על שחור - זה אותו דבר מבחינת החישוב).
ב-WCAG הרף המינימלי לניגודיות צבעים בין טקסטים היא 4.5:1.
בשביל לתת קצת מושג - למשל אדום על לבן זה 4:1.
לטקסטים גדולים יש "הנחה" קלה, ומספיק 3:1.
איך בודקים?
השיטה הכי מהירה וקלה - ה-inspector של CHROME - דרך F12 או ישירות CTRL+SHIFT+C שפותח ישר את הסמן של ה-INSPECTOR. ואם אני ארחף עם הסמן מעל טקסט, הוא יכתוב לי את הקונטרסט שלו, וגם יעשה לי V ירוק או X אדום שכבר מחשב אם זה עובר או לא את המינימום הנדרש. שימו לב שהחישוב שלו כבר לוקח בחשבון את גודל הטקסט, ולכן למשל 4:1 יקבל V ירוק אם הטקסט גדול מספיק.
שימו לב שאם רוצים לבדוק מצב HOVER של כפתור - הדבר היחיד שניתן לעשות, הוא לגרום למצב ה-HOVER ואז ללחוץ על קיצור המקלדת CTRL+SHIFT+C לפתיחת ה-INSPECTOR ואז תזוזה קטנה על הכפתור תיתן את קונטרסט הHOVER.
איך בודקים כשזה לא רקע אחיד? או כשזה על רקע של תמונה?
כלי בדיקה ראשון ה-CONTRAST CHECKER של WEBAIM. פשוט נכנסים לאתר שלהם בוחרים את שני הצבעים שרוצים למדוד את היחס ביניהם; כשבאים לבחור צבעים, ניתן להשתמש שם בטפטפת לדגימת צבעים. (שימו לב שצריך דפדפן כרום בשביל שהטפטפת תעבוד.)
כלי בדיקה שני: להשתמש בדפדפן פיירפוקס, ואפשר לעשות שם INSPECT לבדיקת קונטרסט אם יש רקע שאינו חלק, אז הוא נותן את כל טווח הקונטרסטים בין הטקסט לרקעים שסמוכים אליו.
ניגודיות של דברים שאינם טקסט - נגיד למשל אייקון של פייסבוק או של זכוכית מגדלת. שם הדרישה היא ל 3:1 בלבד (בדומה לטקסט גדול).
זום
בעבר הדרישה הייתה רק להגדלה של הטקסט ל 200%, ולראות שלא נעלם שום דבר והכל עובד.
מאז זה הפך להיות דרישה לזום של 400%, וצריך לוודא שלא רק ששום דבר לא נשבר או לא עובד, אלא שגם אין גלילה אופקית (או ליתר דיוק גלילה דו מימדית). כלומר מה שמעוניינים למנוע כאן זה את העובדה שמי שהגדיל את הטקסט יצטרך לגלול ימינה/שמאלה כל הזמן בשביל לקרוא את הטקסט. מה שרוצים שבעצם יקרה זה REFLOW - כלומר שהכל יסתדר בעמודה אחת ויתאים את הטקסט לרוחב הנתון.
מצד אחד צריך לשים לב שבמובייל לא מבטלים את ה-GESTURE של PINCH TO ZOOM. חובה לתמוך באפשרות של היוזר לעשות זום.
מצד שני, כדאי שתדעו, שיש לדפדפנים כיום אפשרות לדרוס את החסימה של האתר, ובכל זאת לאפשר זום במכשירי מגע.
טקסט ספייסינג
עוד בדיקה של מניפולציות של סטיילינג שהיוזר יכול לעשות:
יש דרישה שנקראת TEXT SPACING שאומרת בעצם שאם היוזר עשה רווח מסויים בין אותיות ובין השורות ובין פסקאות עדיין הכל צריך לעבוד ולהיות זמין.
הבדיקה לזה היא בעזרת BOOKMARKLET פשוט - בקישור הזה יש את הכלי - פשוט גוררים את זה לBOOKMARKS BAR ואז בקליק זה מייצר את הריווחים כפי הנדרש.
כיוון המסך
שימו לב שיש בדיקה חשובה - לוודא שבמובייל האתר מתאים את הכיווניות שלו בין מצב של PORTRAIT ו LANDSCAPE. זה נועד עבור משתמשים עם מגבלה פיזית אשר יושבים מול מכשיר שהוא מקובע בכיווניות מסוימת (לדוגמה LANDSCAPE) ואז הוא בעצם לא מסוגל לסובב את המסך ועל כן בלי להתאים את האתר לשני הכיוונים, זה לא יהיה שמיש עבורו.
הערה: יש מקרים חריגים שבהם זה מחייב כיוון מסויים, אז זה בסדר שאי אפשר לסובב. דוגמת אפליקציית פסנתר שהייתה מחייבת תצוגת LANDSCAPE ולא הייתה עובדת ב PORTRAIT וזה לגיטימי. (לעומת בלוג שסתם לא מסתובב - ששם זה באג שצריך לתקן).
קורא מסך
מתחילים בהדגמה קצרה של איך אתר סטארבאקס נשמע עם קורא מסך.
קורא מסך הינה תוכנה שלוקחת את הAPI של ה ACCESSIBILITY TREE שהיא נגזרת של ה DOM. מפשיטים מה HTML את כל הדברים העיצוביים הלא חשובים. מה שחשוב זה התוכן, הסדר שלו, ומה הסמנטיקה של הדברים - האם זה כפתור / לינק / תמונה / כותרת וכו'.
לאחר מכן זה מעביר דרך מנוע דיבור לקול עם מבטא כזה או אחר.
יש דרכים אחרות לתווך את המידע - כגון מסכי ברייל, שבהן המילים במקום להיות מוקראות פשוט מוצגות כטקסט ברייל.
בהדגמה שמענו כשקורא המסך לא מתאר סמנטית במדויק את מה שרואים על המסך. וגם נתקלנו בדוגמה שנעשתה פעולה אבל לא היה שום חיווי לקורא המסך. עשינו שימוש בדילוג אל תוכן ראשי. שמענו את הכותרת הראשית והכרנו את קיצור המקלדת H של קורא המסך NVDA אשר מעביר אותנו בין כותרות בעמוד. בנוסף, יש קיצורים 1-6 לצורך דילוג את הכותרת מסוג H1 / H2 / H3 הבא.
באתר הזה ראינו שיש H1 שהוא קיים ויחיד ברמה הטכנית אבל לא ממש מתאר את העמוד באופן מוצלח.
להורדת קורא המסך NVDA שהוא חינמי ופועל על מערכת ההפעלה WINDOWS.
מקווים שהפרק היה ברור ומועיל.
מוזמנים לשלוח תגובות ושאלות לקראת הפרק השלישי
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.