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