בתהליך העבודה שלהם, הרבה אנשים משתמשים בפיתוח מבוסס-רכיבים באמצעות מדריכי סגנון של תבניות, ספריות רכיבים ומערכות תכנון מלאות. גם אם לא השתמשתם בכלים האלה באופן רשמי, סביר להניח שתשתמשו בתהליך דומה כדי לפצל עיצוב גדול של אתר, אפליקציה או מוצר דיגיטלי אחר לחלקים שניתן לנהל.
בדומה לבניית מבנה פיזי, חשוב לבנות חלק אחד בכל פעם. קודם כול, היסודות, המבנה, הקירות, החלונות, הגג וכל מה שביניהם. כלי פיתוח מבוססי-רכיבים מאפשרים לנו לעשות זאת באתרים, באפליקציות ובמוצרים דיגיטליים אחרים.
בין היתרונות של פיתוח מבוסס-רכיבים, כמו פירוק לחלקים שניתן לנהל, יש צורך בזמן הפיתוח של הרכיבים שניתנים לשימוש חוזר. היא מאפשרת למעצבים, למפתחי קצה עורפי ולמפתחים ובקרת איכות לעבוד בו-זמנית. לקוחות, מעצבים, מנהלי קמפיינים ועוד מעדיפים אותו, כי הם יכולים לראות תצוגה מקדימה של תהליך הבנייה ולהשתמש במדריך סגנון פעיל כחומר עזר אחרי השקת האתר.
עם זאת, כשאנחנו בוחנים דפוסים, רכיבים ומערכות תכנון מתוך מחשבה על נגישות, יש שאלות. איך יודעים אילו דפוסים הכי טובים כשמדובר בנגישות? האם כדאי להשתמש בתבנית/ספרייה קיימת או ליצור תבניות/ספרייה חדשות? איך אפשר לדעת אם הדפוסים האלה באמת יעזרו למשתמשים?
מתוך מגוון האפשרויות הקיימות, הנושא הזה מתבלבל בקלות. מטרת המודול הזה היא לספק מידע כללי על הערכה של תבניות, רכיבים ותכנון של מערכות נגישות, והוא נקודת התחלה שתעזור לכם לקבל החלטות נגישות יותר.
חשוב באופן ביקורתי
בחירת תבנית, רכיב או מערכת עיצוב נגישים אינה מדע טילים, אך היא כרוכה בהשקעת זמן וחשיבה ביקורתית. למעשה, אין דבר כזה "דפוס מושלם אחד", אבל יכולות להיות אפשרויות רבות שיכולות להתאים. חשוב ללמוד איך לבחור את האפשרות המתאימה ביותר למצב הייחודי שלכם.
במודולים הבאים של הבדיקות, תלמדו על השיטות והשיטות להערכת תבניות, רכיבים ומערכות תכנון לנגישות. אבל לפני השלב הזה, אתם צריכים צעד אחורה ולשאול את עצמכם כמה שאלות בסיסיות, למשל:
- האם כבר קיימים דפוס, רכיב או מערכת עיצוב נגישים וזמינים?
- באילו דפדפנים וטכנולוגיה מסייעת (AT) אני תומך?
- האם יש מגבלות על הקוד/ה-framework או צורכי משתמש/שילובים אחרים שצריך לקחת בחשבון?
בהתאם לסביבת הפיתוח ולצורכי המשתמש, ייתכן שיהיו שאלות נוספות או שונות מאלה. כדאי להתייחס לשאלות האלה כנקודת ההתחלה בהערכת הנגישות.
משאבים מבוססים
לפני שאתם יוצרים משהו חדש, בדקו היטב מה כבר קיים מבחינת תבניות, רכיבים ומערכות תכנון. לאחר מחקר קצר, ייתכן שתופתעו למצוא פתרון – או יותר – פתרון שמתאים לצרכים שלכם.
כמה משאבים מעולים לתבניות, רכיבים ומערכות עיצוב נגישים:
- רכיבים נגישים
- ספריית ARIA של אוניברסיטת Deque
- מערכת עיצוב Gov.UK
- רכיבים נכללים
- MagentaA11y
- U.S. Web Design System (USWDS), שנוצר עבור הממשל הפדרלי של ארה"ב
- רשימה של תבניות נגישות מ-Smashing Magazine
ב-frameworks של JavaScript, המשאבים הבאים נגישים יחסית, או שקל להתאים אותם אישית לנגישות:
- כשרמת ה-CSS לא מספיקה: דרישות JavaScript לרכיבים נגישים
- תגובה
- זוויתית: ספריית Material
- מקום: Vuetensils
עם זאת, חשוב לשים לב לכך שלא ניתן פשוט להעתיק ולהדביק קוד, ולהניח שהוא מתאים לסביבה שלכם ועונה על צורכי המשתמשים באופן אוטומטי. הדבר נכון לגבי כל התבניות, הרכיבים ומערכות העיצוב, גם אם הם מתויגים כנגישים באופן מלא.
צריך להתייחס לכל המשאבים כנקודת התחלה. אל תשכחו לבדוק את הכול.
תמיכה בדפדפנים ובטכנולוגיה מסייעת (AT)
אחרי שתבדקו כמה תבניות בסיסיות, רכיבים או מערכת עיצוב מלאה שעשויה להתאים לסביבת הפיתוח שלכם, תוכלו לעבור לתמיכה בטכנולוגיה מסייעת. אחד הסוגים העיקריים של AT שמומלץ להתמקד בו כשמעריכים את התבניות, הרכיבים ומערכות העיצוב, הוא קוראי מסך.
קוראי מסך נוצרו מתוך מחשבה על דפדפנים ספציפיים, ויפעלו בצורה הטובה ביותר כשתתאמו לדפדפנים האלה. נעסוק בנושא הזה בפירוט רב יותר במודול על בדיקות של AT, אבל למטרות של הערכת תבניות, חשוב להבין את השילובים הקיימים ולהבין מה אתם צריכים מבחינת התמיכה.
קורא מסך | מערכת ההפעלה | תאימות דפדפן | עלות |
---|---|---|---|
גישה למשימה באמצעות דיבור (JAWS) | Windows | Chrome, Firefox, Edge | נדרש רישיון (קיימת גרסה בחינם של 40 דקות) |
גישה שאינה ויזואלית למחשב (NVDA) | Windows | Chrome ו-Firefox | בחינם (נדרשת הורדה) |
Narrator | Windows | Edge | בחינם (מובנה במחשבי Windows) |
VoiceOver | macOS | Safari | בחינם (מובנה במחשבי macOS) |
אורקה | Linux | Firefox | בחינם (מובנה בהפצות מבוססות Gnome) |
TalkBack | Android | Chrome ו-Firefox | חינם (מובנה בגרסאות מסוימות של Android OS) |
VoiceOver | iOS | Safari | חינם (במכשירי iOS) |
באופן כללי התמיכה בדפדפנים היא מורכבת, והדברים הופכים להיות מסובכים עוד יותר כשמוסיפים מכשירי AT ומפרטי ARIA לשילוב.
אבל אלה לא חדשות רעות. למרבה המזל, משאבים מעולים כמו נגישות HTML5, תמיכה בנושא נגישות ורשימת המשימות ל-Custom Control Accessible Development של WCAG עוזרים לנו להבין טוב יותר את התמיכה הנוכחית בדפדפנים ומכשירי AT, ואפילו מתי כדאי להשתמש ב-ARIA מלכתחילה.
משאבים אלה מפרטים את רכיבי המשנה השונים של דפוסי HTML ו-ARIA הזמינים, כולל בדיקות קהילתיות של קוד פתוח. אפשר גם לראות דוגמאות של דפוסי הדפסה גם למחשבים שולחניים וגם לדפדפנים בנייד/מכשירי AT. לכן, המשאבים האלה יכולים לעזור לכם לקבל החלטה נגישה יותר לגבי תבניות, רכיבים ומערכות תכנון שכדאי להשתמש בהן.
שיקולים נוספים
אחרי שבוחרים כמה תבניות או רכיבים נגישים ונגישים, ומביאים בחשבון תמיכה בדפדפן ובמכשיר AT, אפשר להמשיך לשאלות ספציפיות יותר לפי הקשר לגבי הדפוס, הרכיב, מערכת העיצוב וסביבת הפיתוח.
לדוגמה, אם אתם עובדים במערכת ניהול (CMS) או שיש לכם קוד מדור קודם, יכול להיות שיש מגבלות מסוימות לגבי התבניות שבהן תוכלו להשתמש. לאחר הבדיקה, ייתכן שכמה תבניות אפשריות ייקטעו במהירות לאפשרות אחת או שתיים.
מסגרות JavaScript רבות מאפשרות למפתחים להשתמש כמעט בכל תבנית שהם בוחרים. במקרים כאלה, יכול להיות שיהיו לכם פחות הגבלות ותוכלו לבחור באפשרות הנגישה ביותר לקו ביטול נעילה.
יש שיקולים נוספים שצריך לקחת בחשבון כשבוחרים תבנית, רכיב או מערכת עיצוב, למשל:
- ביצועים
- אבטחה
- אופטימיזציה למנועי חיפוש
- תמיכה בתרגום שפות
- שילובי צד שלישי
אין ספק שהגורמים האלה ישפיעו על בחירת התבנית, אבל צריך להביא בחשבון גם את האנשים שיוצרים את התוכן ואת הקוד עצמו. הדפוס שבוחרים צריך להיות חזק מספיק כדי להתמודד עם מגבלות אפשריות לגבי תוכן שנוצר על ידי עורכים או תוכן שנוצר על ידי משתמשים, והוא צריך להיות בנוי באופן שמפתחים של כל ידע בנושא נגישות יכולים להשתמש בו.
בדיקת ההבנה
בחינת הידע שלכם לגבי דפוסים
האם רכיבים נגישים תמיד נשארים נגישים למשתמשים?