1. כלי לבניית אתרים לא יהפוך אתכם לאנשי מקצוע

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

2. איכות גרועה

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

3. ממשק ניהול לא מותאם

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

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

4. האתר לא יהיה אצלכם

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

5. אתר חסר ייחוד

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

סיכום

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

הפוסט 5 סיבות לבנות אתר בוורדפרס ולא בוויקס הופיע ראשון בלביא פרצ'יק

מהי מערכת ניהול תוכן?

מערכת ניהול תוכן, כשמה כן היא - מערכת שמשמשת לניהול התכנים שבאתר. יש שני סוגי אתרים - אתר סטטי, אותו הלקוח לא יכול לעדכן בעצמו, ואתר עם מערכת ניהול תוכן, או Content Management System באנגלית (ראשי תיבות CMS) - שאותו הלקוח יכול לעדכן בעצמו.

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

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

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

מה זה אומר קוד פתוח?

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

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

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

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

למה חשוב שהקהילה תהיה פעילה?

ישנם מתכנתים רבים בארץ ובעולם שעובדים עם וורדפרס. זהו יתרון משמעותי לעומת מערכות מתחרות מכמה בחינות:

1. אבטחה

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

2. זמינות מתכנתים

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

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

3. עתיד המערכת

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

תבניות

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

סיכום

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

הפוסט מה זה וורדפרס בכלל? הופיע ראשון בלביא פרצ'יק

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

1. חוסר בידע

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

לצורך העניין, אם נבצע חיפוש בגוגל ״how to create a gallery jquery״ נקבל הרבה יותר תוצאות רלוונטיות מאשר כשנחפש ״how to create an accessible gallery״. וגם במדריכים המעטים שיש, המידע לעיתים קרובות אינו עדכני או מדוייק.

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

2. חוק קבוע בעולם משתנה

כמו בעולם בניית האתרים כולו, גם בתוך תחום הנגישות לאינטרנט יש שינויים - מה שנחשב פעם לנגיש נחשב כיום לדבר שאינו מומלץ. למשל: הוספת מאפיין title כדי לספק טקסט חלופי לקוראי מסך נחשב להרגל רע כיום בגלל היעדר תמיכה בקוראי מסך. דוגמה נוספת: חלק מהדרישות לאתר נגיש הן שהאתר יהיה לפי התקן של ה-w3c, אך תקן ה-html בעצמו משתנה - מתקן xhtml לתקן html5. גם בתוך html5 יש שינויים פנימיים. כלי הבדיקה האוטומטיים אינם מעודכנים עם כל השינויים, כמו למשל ״הכשרת״ תגיות i ו-b שנחשבו מיושנות ב-xhtml, או ההמלצה להסיר את מאפיין role מתגיות nav ו-header וכו׳.

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

3. עלות גבוהה

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

4. תחזוקה ותקלות

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

סיכום

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

הפוסט למה בוני האתרים לא אוהבים את חוק הנגישות? הופיע ראשון בלביא פרצ'יק

1. הינטינג

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

2. הסרת התווים באנגלית

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

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

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

<p>טקסט בעברית ואחריו <span class="en">text in English</span></p>

body { 
  font-family: 'SpoilerRegular',  sans-serif; 
}
.en { 
  font-family: 'Titillium Web', sans-serif; 
}

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

body { 
  font-family: 'SpoilerRegular', 'Titillium Web', sans-serif; 
}

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

סיכום

חברת פונטביט מספקת לרוכשי פונטי הרשת שלה שירות שמאפשר לפתור שתי בעיות:

1. בעיית הינטינג בפונטי הרשת
2. שילוב של הפונט העברי עם פונט לועזי

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

הטמעת הפונט באתר

צריכים עזרה להטמיע את הפונט באתר? תוכלו להיעזר בכלי שיצרתי ב-codepen ליצירת קוד ההטמעה:

See the Pen Web font embed code generator by Lavi Perchik (@laviperchik) on CodePen.

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

ישנם ארבעה קריטריונים לאתר נגיש לפי wcag 2.0:

1. ניתן לתפיסה
2. בר תפעול
3. מובן
4. איתן

ניתן לתפיסה

חלופה טקסטואלית

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

תכנים שאינם טקסטואליים

1. יש לספק טקסט חלופי לתמונות באמצעות המאפיין alt, המתאר את מהות התמונה (כולל תמונות של כפתורים בטפסים ותמונות של אזורים לחיצים ב-imagemap)
2. לתמונות המהוות קישור יש לספק טקסט חלופי המגדיר את מטרת הקישור
3. לתמונות שאינן מעבירות מידע, כלומר משמשות לקישוט בלבד, או לתמונות הכוללת מידע שקיים כבר בטקסט ואינן מהוות קישור, יש להגדיר טקסט חלופי ריק ""=alt או ליישמן כרקע ב CSS
4. יש לספק חלופות שוות ערך לתמונות מורכבות בהקשר נפרד (בסמוך לתמונה) או בדף נפרד (עם הפניה מהמאפיין longdesc)

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

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

אם בטפסים שבאתר צריכה להיות קאפצ׳ה (CAPTCHA) עליה להיות נגישה או שתהיה לה חלופה. בנוסף לחלופות אלו, יש לספק טקסט שיזהה את הקאפצ׳ה ויתאר את תכליתה.

מדיה מבוססת-זמן

יש לספק חלופות עבור מדיה מבוססת-זמן.

אודיו-בלבד ווידאו-בלבד (הקלטה מראש)

לאודיו בלבד (מוקלט מראש למשל webcast) - יש לספק תסריט המכיל את כל המידע האודיטורי הרלוונטי להבנת התוכן (הנ"ל יסופק במועד מוקדם ככל האפשר).

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

כתוביות

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

תיאורי אודיו או חלופה טקסטואלית למדיה (מוקלטת מראש)

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

תיאורי אודיו למדיה (מוקלטת מראש)

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

ניתן להתאמה

יש לבנות תכנים הניתנים להצגה בדרכים שונות (למשל בעיצוב פשוט יותר) ללא איבוד מידע או מבנה.

מידע ויחסים

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

כתיבת קוד סמנטי:

1. כותרות - יש להשתמש בתגיות <h1> עד <h6> לסימון כותרות
2. רשימות - יש להשתמש בתגיות <ul>, <ol>, או <dl> לרשימות או קבוצות של קישורים (כולל תפריטים)
3. טקסטים מיוחדים - יש להשתמש בקוד סמנטי כדי לסמן טקסט מודגש או מיוחד (לדוגמא <strong>, <code>, <abbr>, <blockquote>)
4. טבלאות - יש להשתמש בטבלה להצגת מידע טבלאי (th ומאפיין scope לתאים בראש הטבלה), באלמנט caption כדי לשייך כותרת לטבלה, וכן באלמנט summary בהתאם לצורך.
5. טפסים - יש להשתמש באלמנט label לשייך תוויות טקסט לשדות טופס. יש לתת תיאור לקבוצות של שדות הטופס באמצעות fieldset עם כותרת מסוג legend.
6. אזורים בעמוד - רצוי שאזורים בעמוד (תפריט ניווט, איזור ראשי וכד') יהיו מוגדרים באמצעות aria landmarks

יש לקיים הפרדה מלאה בין תוכן לעיצוב על ידי שימוש ב-CSS.

רצף בעל משמעות

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

מאפיינים חושיים

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

בר-הבחנה

שימוש בצבע

יש לוודא ש:

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

שליטה באודיו

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

קונטרסט

קונטרסט - יש לוודא שבכל הטקסטים בעמוד קיים יחס-קונטרסט של לפחות 4.5:1 בטקסט רגיל. בטקסט גדול (מעל 18 פיקסלים או 14 פיקסלים מודגש) יש לשמור על יחס של לפחות 3:1 (למעט: לוגו, טקסטים המשמשים כרקע לתמונה, טקסטים שלא נראים לאף אחד).
אם לא ניתן לעמוד בהנחיה הנ״ל, מותר לעשות שימוש בסט צבעים נוסף שיעמוד בהנחיה זו.

הגדלת טקסט

הגדלת טקסט - כאשר מגדילים את הטקסט ב 200% (פי 2) יש לוודא שהמידע נותר קריא ושיכולת השימוש בדף לא נפגעת.

תמונות של טקסט

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

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

בחזרה למעלה

בר תפעול

מקלדת נגישה

יש לאפשר תפקוד מלא באתר על ידי מקלדת.

מקלדת

יש לוודא ש:

1. כל הפעולות באתר יכולות להתבצע באמצעות מקלדת (לחיצה על מקש tab)
2. מעבר הפוקוס הגיוני - מעבר אינטואיטיבי ומותאם למבנה המסך בין קישורים, שדות טופס וכדו׳
3. רכיבים שאינם HTML מאפשרים שימוש מלא במקלדת המחקה את התנהגות רכיבי ה-html המקבילים
4. כאשר רכיב בדף מקבל פוקוס הדבר לא מעורר שינוי משמעותי בדף (פתיחת דף נוסף, הופעת פופאפ, העברת הפוקוס לרכיב אחר וכדו׳)

מלכודות מקלדת

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

זמן מספיק

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

כוונון זמן

בכל מצב בו יש הגבלת זמן לקריאה, לתגובה או לפעולה (כולל timeout), יש לתת למשתמש אפשרות לבטל, להאריך, או להתאים לעצמו את הגבלת הזמן. (למעט מקרים בהם הגבלת הזמן היא מעל 20 שעות).

הפסקה, עצירה, הסתרה

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

התקפים

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

הבהוב וריצוד

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

ניתן לניווט

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

עקיפת בלוקים

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

כותרת דף

יש לוודא שלכל העמודים יש כותרת (אלמנט title) ייחודית המתארת את התוכן / הפונקציונאליות של הדף.

סדר פוקוס

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

מטרת הקישור (מתוך הקשר)

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

ריבוי דרכים לאיתור דף באתר

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

כותרות ותוויות

יש לספק כותרות ותוויות ברורות המבהירות בברור את הנושא או המטרה.

פוקוס נראה לעין

הוספת אפקט ויזואלי בפוקוס - יש לוודא שכל מרכיב המקבל פוקוס בשימוש במקלדת מקבל אפקט ויזואלי (ע"י הדפדפן או ע"י שינוי עיצוב של הרכיב).

כותרות לקטעים

יש לעשות שימוש בכותרות כדי לסמן אזורים בדף (רמה AAA בלבד - ל.פ.).

בחזרה למעלה

מובן

קריא

יש ליצור תכני טקסט קריאים וניתנים להבנה.

השפה בדף

שפת כתיבה - יש לוודא שבעמוד מוגדרת שפת הכתיבה (עברית, ערבית, אנגלית) בתגית ה-html. לדוגמא, לאתר בעברית: "lang="he.

השפה בחלקים בעמוד

בכל מקום בתוכן בו יש שינוי של שפת הכתיבה יש לציין את השינוי בקוד באמצעות מאפיין lang.

צפוי

דפי האתר צריכים להיראות ולתפקד באופן צפוי.

בעת פוקוס (on focus)

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

הקלדת תוכן (on input)

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

ניווט עקבי

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

זיהוי עקבי

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

עזרה בקלט

יש לסייע למשתמשים להמנע משגיאות ולתקנן.

זיהוי שגיאה

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

תויות והוראות

כאשר המשתמש נדרש להזין מידע יש לוודא שמסופקות לו תוויות והוראות.

מניעת שגיאות (משפטי, פיננסי נתונים)

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

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

בחזרה למעלה

איתן

תואם

יש לדאוג לתאימות מרבית עם user agents קיימים ועתידיים, כולל טכנולוגיות מסייעות.

סטנדרטיזציה

בשימוש בשפות markup יש לוודא כי:

1. לכל אלמנט יש תגיות התחלה וסיום לפי הסטנדרטים
2. אין מאפיינים כפולים
3. כל ה-id ייחודיים
4. יש קינון תגיות נכון על פי הסטנדרטים

שם תפקיד וערך

1. שם תפקיד וערך - יש לוודא שעבור כל רכיבי ממשק המשתמש (למשל: אלמנטים בטופס, קישורים ורכיבים שנוצרו על ידי סקריפטים):
   • השם והתפקיד של הרכיב מזוהים בקוד
   • מצבים, מאפיינים וערכים שהמשתמש יכול לשנות מוגדרים בקוד
   • הודעה על שינויים בפריטים אלה זמינה ל-user agents, כולל טכנולוגיות מסייעות (כגון קוראי מסך)
2. כמו כן, לכל frame ו iframe יש להוסיף title המתאר את מטרתו

הפוסט הנחיות ברורות (יותר) לבדיקת נגישות הופיע ראשון בלביא פרצ'יק

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

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

תמונת המצב שגיבשתי בנושא הנגשת אתרים לאחר יום העיון היא כזו:

1. אימות חששות

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

2. נגישות ׳רגילה׳ לעומת נגישות אינטראקטיבית

לפי מה שאני מבין, נראה שיש שני סוגי נגישות:

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

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

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

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

3. אף אתר אינו נגיש לגמרי

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

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

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

כמה דברים חדשים שלמדתי

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

• קישורי ״קרא עוד״ או ״לחץ כאן״ - צריך להוסיף להם מאפיין title שמתאר לאן הם מובילים.
• הנגשה של מסמכי pdf היא בעייתית - מסתבר שיש דרך נכונה לייצא pdf, אך לא פירטו מהי.
• הנגשת טבלאות היא מורכבת - יש להימנע מתאים ריקים, יש להשתמש ב-th ו-scope בשורה הראשונה בטבלה וגם ב-caption.
• יש כמה כלים אוטומטיים לבדיקת נגישות: wat לאינטרנט אקספלורר, wave לפיירפוקס ו-accessibility developer tools לכרום (לא הזכירו בכנס, תוספת שלי). הכלים האוטומטיים לא בודקים את הנגישות האינטראקטיבית עליה דיברתי לעיל.
• כדאי לכתוב דף נגישות שבו מפורט מה הנגשתם ומה לא באתר האינטרנט וגם באתר הפיזי של הארגון. לדוגמה - דף הצהרת הנגישות באתר חברת קווים.
• אם אתם רוצים להתעניין וללמוד את aria - תוכלו לראות בקישור הבא כמה דוגמאות לשימוש בתקן aria ברכיבים אינטראקטיביים שונים.

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

עדכון [17.6.14] - ניתן לצפות בהרצאות בחשבון היוטיוב של האוניברסיטה הפתוחה: פלייליסט של כל ההרצאות מהכנס ביוטיוב.

הפוסט רשמים מכנס הנגישות – יוני 2014 הופיע ראשון בלביא פרצ'יק

עיצוב על פי תוכן

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

הנה כמה דוגמאות להשפעה של תכנים על עיצוב האתר:

א. כמות התכנים יכולה להשפיע על מבנה האתר

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

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

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

ג. תמונות ומדיה

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

בניית מערכת ניהול על פי התוכן

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

הזנת תכנים כבסיס לבדיקות

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

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

סיכום

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

הפוסט תוכן כבסיס לאתר מוצלח הופיע ראשון בלביא פרצ'יק

1. תצוגת טבלה

כל מי שהתחיל לפתח אתרים באמצע העשור הקודם יודע ש״טבלאות זה רע״. כלומר, רע להשתמש בטבלה כדי לעמד את הדף, במקום להשתמש בדיבים וב-css. מה אם היינו יכולים להשתמש בתצוגת טבלה כדי לעמד את הדף, מבלי להשתמש בטבלאות, אלא בדיבים ובשאר אלמנטי המבנה הסמנטיים של html5? לשם כך אפשר להשתמש ב-display:table.

• display: table - מחקה את תצוגת אלמנט table
• display: table-cell - מחקה את תצוגת אלמנט td

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

2. אלמנטים מדומים

בעבר כתבתי פוסט על אלמנטים מדומים ומה שאפשר לעשות איתם. בקצרה, בכל פעם שאתם רואים before ו-after ב-css, זהו אלמנט מדומה. אלמנטים אלו יכולים לנקות את ה-html שלכם מאלמנטי span ריקים, והם מאוד נוחים לשימוש.

3. מודל קופסה border-box

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

.myelement {
  width: 500px;
  padding: 10px;
  border: 1px solid black;
}

בקוד הנ״ל רוחב האלמנט יהיה 522 פיקסלים, כלומר: 500 רוחב + 10 פדינג מכל צד + 1 גבול מכל צד. אם נוסיף לסלקטור הנ״ל את השורה הבאה:

box-sizing: border-box;

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

לפעמים בהגדרת רוחב מבוססת אחוזים זהו המודל היחיד שאפשר להשתמש בו. למשל, אלמנט textarea, שנגדיר לו רוחב של 100% - במודל הקופסה הרגיל רוחבו יהיה 100 אחוז ועוד 2 פיקסלים - בהנחה שיש גבול של פיקסל אחד מכל צד. שימוש ב-border-box יכול לפתור את הבעיה. יש שמחילים את המודל הזה על כל האלמנטים במסמך בעזרת סלקטור *.

4. תצוגת אינליין-בלוק

עולם האלמנטים נחלק לשניים: אינליין ובלוק. אלמנט אינלייני נפוץ הוא קישור. אלמנט בלוק נפוץ הוא דיב.

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

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

5. קיצור טקסט ארוך עם שלוש נקודות

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

אם כל מה שאתם רוצים לעשות הוא לוודא שהטקסט לא יתפרס על שתי שורות, תוכלו להשתמש בשלושה כללי css כדי לפתור את הבעיה:

1. white-space:nowrap - מוודא שהטקסט לא עובר לשורה חדשה
2. overflow:hidden - מוודא שהטקסט החורג מרוחב האלמנט יוסתר
3. text-overflow:ellipsis - יוסיף שלוש נקודות היכן שהטקסט נחתך, אם הטקסט באמת נחתך

בעוד ששני הכללים הראשונים עובדים בכל הדפדפנים - הוספת שלושת הנקודות תעבוד רק בדפדפנים מודרניים (כולל אקספלורר 9 ומעלה). שימו לב שצריך גם להוסיף שורה עם קידומת ms כדי שזה יעבוד באקספלורר. ראו דוגמה שהכנתי ב-codepen.

<p class="ellipsis">הטקסט שמופיע בפסקה זו ייחתך לאחר שלא יהיה לו יותר מקום בשורה. נסו לשנות את גודל החלון ותראו שהמשפט מקבל סימן של שלוש נקודות היכן שהוא נחתך.</p>

p.ellipsis {
  white-space: nowrap;
  overflow: hidden;
  -ms-text-overflow: ellipsis;
  text-overflow: ellipsis;
}

הפוסט 5 דברים שאפשר לעשות ב-css אם לא תומכים ב-ie7 הופיע ראשון בלביא פרצ'יק

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

1. לא קשה להנגיש אתרים
2. יש כלים אוטומטיים לבדיקת נגישות האתר
3. החוק חל רק על חלק מהאתרים ולא על כולם
4. יש חוקים דומים בארצות מערביות אחרות, כמו בריטניה וארה״ב

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

״לא צריך להתרגש, כי לא קשה להנגיש אתרים״

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

הנה שני דברים שכדאי לקחת בחשבון:

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

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

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

ב. רכיבים אינטראקטיביים כמו גלריות, סליידרים ודרופדאונים

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

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

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

״אפשר להשתמש בכלים אוטומטיים כדי לבדוק האם האתר שלכם נגיש״

הכלים האוטומטיים לבדיקת נגישות יעזרו לכם למצוא פקדי טופס שחסרה להם תווית (label), למצוא תגיות img ללא alt, אבל לא הרבה מעבר לכך. למשל, מה בנוגע לתמונות חשובות שיש להם תגית alt ריקה? מה בנוגע לתפריטי דרופדאון, שקשה להשתמש בהם בעזרת מקש ה-tab? אף כלי אוטומטי, משוכלל ככל שיהיה, לא יוכל לדמות את הדרך שבה עיוור, או מוגבל ראיה, ישתמש באתר שלכם.

אם אתם באמת רוצים להבין איך עיוורים משתמשים באתר שלכם, עליכם להתקין קורא מסך. ממה שאני ראיתי יש קוראי מסך חינמיים, למשל - תוסף לכרום בשם chromevox, אך הם עובדים רק על אתרים באנגלית. אם תרצו קורא מסך שעובד גם בעברית - תוכלו לקנות את תוכנת jaws במחיר סימלי של 895$. כסף קטן, לא?

״החוק לא חל על כל האתרים״

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

״חוקים דומים קיימים כבר שנים בארצות המערב״

חיפשתי בגוגל את הביטוי ״accessibility law website״ ובתוצאה הראשונה הגעתי לדף של אתר בריטי שמדבר על נגישות. בדף כתובה הפסקה הבאה, שמתייחסת לחוק נגישות האתרים בבריטניה:

We are not aware of any case which has been brought to court in the United Kingdom to date, so there is no case law guidance. However, we are currently suing BMI Baby over its failure to deal with the poor accessibility of its website.

תרגום: ״אנחנו לא מודעים לשום מקרה שהובא לבית המשפט, חוץ ממקרה אחד שבו אנחנו תובעים את חברת BMI Baby על כשלונם להתמודד עם נגישות גרועה באתר שלהם״.

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

המבט שלי על חוק הנגישות

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

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

הפוסט מחשבות על חוק הנגישות הופיע ראשון בלביא פרצ'יק

בתחתית הפוסט מוטמעות כל הדוגמאות שהכנתי ב-codepen.

כללים

1. אפשר להגדיר גבול מבלי לכתוב צבע

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

border: 1px solid;

2. אפשר להגדיר צבעי גבול דרך border-color לפי כיוון השעון

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

border-color: #aaa #999 #777 #999;

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

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

font: italic bold 12px/1.5 arial, sans-serif;

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

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

span {
position: absolute;
display: block; /* אין צורך בהגדרה זו */
}
span {
float: left;
display: block; /* אין צורך בהגדרה זו */
}

דוגמאות

See the Pen cgDmn by Lavi Perchik (@laviperchik) on CodePen

הפוסט 4 כללים שיכולים ליעל את ה-css שלכם הופיע ראשון בלביא פרצ'יק