למה רוב האתרים בעברית נראים "כמעט נכון" — וזה בדיוק הבעיה
עיצוב אתר בעברית RTL הוא לא "לקחת תבנית ולהפוך את הכיוון". מי שעושה את זה מקבל אתר שנראה סביר במבט ראשון, ומתפרק ברגע שמשתמש אמיתי מנסה למלא טופס, לקרוא מספר טלפון או ללחוץ על חץ. הפערים האלה קטנים בעין ועצומים בתוצאה: משתמש שמרגיש שמשהו "לא יושב" לא יודע להסביר למה, הוא פשוט עוזב.
ב-RAMS Studio אנחנו בונים אתרים בעברית מהיסוד, לא כתרגום של אתר באנגלית. אספנו כאן את עשר הטעויות שאנחנו פוגשים שוב ושוב בבדיקות UX של אתרים ישראליים, כולל אתרים של חברות גדולות עם תקציבים גדולים. כל טעות מגיעה עם תיקון קונקרטי.
1. אייקונים שמצביעים לכיוון הלא נכון
הטעות הנפוצה ביותר בעיצוב אתר בעברית RTL: חץ "הבא" שמצביע ימינה, כפתור "חזרה" עם חץ שמאלה, ו-chevron בתפריט נפתח שמוביל את העין הצידה במקום לתוך התוכן. בממשק עברי כיוון הזרימה הוא מימין לשמאל, כלומר "קדימה" זה שמאלה ו"אחורה" זה ימינה. חץ שלא הפוך שובר את המודל המנטלי של המשתמש בשבריר שנייה, וזה מספיק.
אבל שימו לב: לא כל אייקון צריך להתהפך. אייקון שעון, סימן וי, לוגו של חברה, אייקון Play ומדיה, כולם נשארים כמו שהם, כי הם מייצגים אובייקטים פיזיים או מוסכמות בינלאומיות. ההיפוך הגורף של כל האייקונים בעזרת transform: scaleX(-1) על כל ה-SVG הוא טעות לא פחות חמורה מאי-היפוך.
התיקון: להגדיר מראש רשימה של אייקונים "כיווניים" (חצים, chevrons, אייקוני יציאה וכניסה, back/forward) ולהפוך רק אותם. במערכת עיצוב מסודרת זה משתנה אחד בקומפוננטה, לא תיקון ידני בכל עמוד.
2. מספרי טלפון שנשברים באמצע
"050-123-4567" הופך ל-"4567-123-050" או, גרוע מזה, למספר שנראה תקין אבל מועתק הפוך. זה קורה כי אלגוריתם ה-bidi של הדפדפן מתייחס למקפים כתווים "ניטרליים" שיורשים את הכיוון של הפסקה. בפסקה בעברית, המקפים מקבלים כיוון RTL והמספר מתפרק.
התיקון: כל מספר טלפון, מספר כרטיס, מספר הזמנה ותאריך עוטפים באלמנט עם dir="ltr" ומגדירים unicode-bidi: isolate. זה שומר על המספר כיחידה אחת שלא מושפעת מהטקסט מסביב. אין פתרון "עיצובי" לבעיה הזו, זה תיקון בקוד וזהו.
3. כתובות, אימיילים ו-URL בתוך טקסט עברי
אותה בעיה בדיוק, עם תוצאה מביכה יותר. כתובת כמו "רחוב הברזל 12, תל אביב" עלולה להציג את המספר במקום הלא נכון. כתובת אימייל שמופיעה באמצע משפט בעברית עלולה להישבר סביב ה-@ או הנקודה. ו-URL עם פרמטרים ומקפים הוא כמעט מובטח שייראה שגוי.
התיקון: אותו עיקרון של בידוד. בנוסף, בכתובות פיזיות אנחנו ממליצים לכתוב את המספר לפני שם הרחוב בטקסט ("12 הברזל") רק כשזה נדרש בממשקים צפופים, ואחרת לבודד את המספר. הכלל הפשוט: כל רצף של ספרות ותווים לטיניים בתוך עברית מקבל בידוד כיווני, בלי יוצא מן הכלל.
הרבה מפתחים מכירים את unicode-bidi: embed ומשתמשים בו כברירת מחדל. הבעיה: embed מאפשר לתווים ניטרליים בקצוות (רווחים, סימני פיסוק, סוגריים) "לדלוף" ולקבל את הכיוון של האלמנט הפנימי, מה שגורם לסוגר סוגריים לקפוץ לצד הלא נכון. isolate (וה-tag העטוף <bdi>) מתייחס לאלמנט כיחידה אטומה שהתווים סביבה לא רואים. זה הסטנדרט הנכון ל-2025, ותמיכת הדפדפנים בו מלאה. ב-RAMS Studio אנחנו מגדירים את זה ברמת ה-Global CSS פעם אחת: כל [dir="ltr"] בתוך [dir="rtl"] מקבל isolate אוטומטית.
4. טפסים שמיושרים לצד הלא נכון
הטופס הוא המקום שבו אתר עברי מרוויח או מפסיד את הליד. וברוב הטפסים שאנחנו בודקים יש לפחות אחת מהבעיות הבאות: תוויות (labels) מיושרות לשמאל בעוד השדות מיושרים לימין, placeholder באנגלית בתוך שדה שמצפה לעברית, שדה טלפון שבו הסמן מתחיל מימין והמספר נכתב הפוך, והודעות שגיאה שמופיעות מתחת לשדה הלא נכון.
מחקרי Baymard Institute על טפסי צ'קאאוט מראים באופן עקבי שתווית שממוקמת מעל השדה, מיושרת לאותו כיוון של השדה, נסרקת מהר יותר מתווית בצד. ב-RTL זה אומר: תווית מעל, מיושרת לימין, שדה מיושר לימין, וכל שדה מספרי עם dir="ltr" ו-text-align: right (או text-align: end) כדי שהמספר יוקלד נכון אבל יישאר ויזואלית בקו של שאר הטופס.
התיקון: לכל שדה סוג מוגדר: טקסט חופשי בעברית = RTL. אימייל, טלפון, מספר כרטיס, סיסמה = LTR עם יישור לימין. Placeholder בעברית תמיד. הודעת שגיאה מוצמדת לשדה עם aria-describedby, לא צפה אי שם למעלה.
5. טיפוגרפיה עברית שנבחרה בגלל האנגלית
מעצב מתאהב בפונט לטיני, מגלה שאין לו גליפים עבריים, והדפדפן נופל ל-fallback: Arial או David. התוצאה היא כותרת מרשימה באנגלית ופסקה בעברית שנראית כאילו הגיעה ממסמך Word מ-2009. זה לא פרט קטן. הפונט הוא 90% מהתחושה של "אתר מקצועי".
הבעיה השנייה: הגדרות שנכתבו לפונט לטיני ומוחלות על עברית. letter-spacing שלילי שעובד יפה ב-Inter הורס אותיות עבריות שנוגעות אחת בשנייה. line-height של 1.2 שמתאים לכותרת באנגלית חותך את הרגליים של ק', ך' ו-ן'. ומשקל 300 (Light) שנראה אלגנטי ב-Helvetica הופך לבלתי קריא בעברית על מסך.
התיקון: בוחרים פונט עם עברית מלאה מתוכננת, לא "עם תמיכה" (Heebo, Assistant, Rubik, Frank Ruhl Libre, Ploni הם התחלה טובה). מגדירים :lang(he) ב-CSS עם ערכים נפרדים: line-height של 1.5 לפחות לגוף טקסט, letter-spacing של 0 עד -0.02em מקסימום לכותרות, ומשקל מינימלי של 400 לטקסט רץ.
אתר בעברית שנבנה על תבנית באנגלית תמיד ירגיש כמו תרגום. גם אם כל מילה בו נכונה.— RAMS Studio
6. סימני פיסוק שקופצים לצד הלא נכון
סימן שאלה בתחילת המשפט. נקודה שמופיעה לפני המילה האחרונה. סוגריים שנפתחים בצד הלא נכון של שם באנגלית. כל אלה הם תסמין של אותה מחלה: טקסט עברי שמוצג בתוך אלמנט שכיוונו LTR (או ללא הגדרת כיוון בכלל), ותווי הפיסוק הניטרליים נדבקים לכיוון ברירת המחדל.
התיקון: dir="rtl" על תג ה-html, לא רק על ה-body ולא רק על הקונטיינר. ובכל מקום שבו מוזרק תוכן דינמי (תגובות, פיד, תוצאות חיפוש), לוודא שהעוטף יורש את הכיוון. אם משתמשים ב-dir="auto" לתוכן מעורב, לבדוק שהמילה הראשונה בטקסט היא לא באנגלית, אחרת כל הפסקה תיושר שמאלה.
7. CSS עם מאפיינים פיזיים במקום לוגיים
הטעות שיוצרת 80% מהעבודה הכפולה בפרויקטים דו-לשוניים. margin-left, padding-right, left: 0, border-right, float: left. כל אחד מהם צריך override ידני ב-RTL, וברגע שמישהו מוסיף קומפוננטה חדשה ושוכח, יש באג.
התיקון: מאפיינים לוגיים בלבד: margin-inline-start במקום left, padding-inline-end במקום right, inset-inline-start במקום left ב-position, ו-text-align: start במקום right. הקוד נכתב פעם אחת ועובד בשני הכיוונים. Flexbox ו-Grid כבר מכבדים כיוון אוטומטית, מה שמבטל את רוב הצורך ב-float מלכתחילה.
אנחנו עוברים על הטפסים, הטיפוגרפיה וה-CSS שלכם ומחזירים רשימת תיקונים מדויקת. בלי הערכות, בלי ניחושים.
8. קרוסלות וסליידרים שגוללים הפוך
הרוב המוחלט של ספריות הסליידרים נבנו ל-LTR. באתר עברי הן מציגות את השקופית הראשונה בצד שמאל, החץ "הבא" מוביל ימינה, וכשמשתמש מחליק אצבע במובייל, התוכן זז לכיוון ההפוך מהאינטואיציה. גם אם הספרייה מציעה מצב RTL, הוא לרוב חצי-אפוי: הנקודות (dots) מתהפכות אבל ה-swipe לא, או להיפך.
התיקון: לבדוק תמיכת RTL של הספרייה לפני הבחירה, לא אחרי. Swiper ו-Embla מטפלים בזה נכון כשמגדירים להם כיוון מפורש. ואם אפשר, לוותר על הקרוסלה: ברוב המקרים גריד סטטי ממיר טוב יותר, טוען מהר יותר ולא סובל מבעיות כיוון בכלל.
9. CTA שממוקם לפי הרגלי LTR
בממשק LTR הכפתור הראשי יושב בפינה הימנית התחתונה של הטופס או הכרטיס, כי לשם העין מגיעה בסוף הסריקה. ב-RTL הסריקה מתחילה מימין למעלה ומסתיימת משמאל למטה, כלומר הכפתור הראשי צריך להיות משמאל. אתרים רבים משאירים אותו בצד ימין, ואז המשתמש נתקל בכפתור "ביטול" לפני שהוא מגיע ל"שליחה".
Nielsen Norman Group תיעדו שדפוס הסריקה בצורת F, שנצפה במחקרי מעקב עיניים, מתהפך לצורת F מראה בממשקי RTL. זה אומר שההיררכיה הוויזואלית כולה, כותרת, תת-כותרת, כפתור, חייבת להיבנות מחדש, לא רק להיות "מיושרת לימין".
התיקון: כפתור ראשי בסוף כיוון הקריאה (שמאל). כפתור משני לימינו, בעיצוב מוחלש. חץ בתוך הכפתור פונה שמאלה, בכיוון ההתקדמות. וטקסט הכפתור בפועל: "לתיאום שיחה", "לקבלת הצעה", לא "Submit" בעברית.
10. מספרים, אחוזים וטווחים בתוך משפט
"עלייה של 40%-25% בהמרות". רואים את הבעיה? הטווח נכתב 25%-40%, אבל ה-bidi הפך אותו. אותו דבר קורה עם תאריכים ("2025-2024"), שעות פעילות ("18:00-9:00") ומחירים עם מטבע. זו טעות שמשתמשים לא שמים לב אליה במודע, אבל היא פוגעת באמינות: אתר שמציג מספרים "לא הגיוניים" נתפס כלא מדויק.
התיקון: טווחים ותאריכים עוטפים ב-<bdi> או ב-span עם בידוד. לחלופין, בטקסט שיווקי, מנסחים מחדש בלי טווח: "בין 25 ל-40 אחוז". ובמערכות תוכן (WordPress, Elementor) מוסיפים לצוות התוכן כלל ברור: מספר עם מקף = תמיד בתוך bdi.
הבדיקה שאנחנו מריצים על כל אתר לפני שהוא עולה
עשר הטעויות האלה לא מופיעות בבדיקות אוטומטיות. Lighthouse לא יגיד לכם שהחץ פונה לכיוון הלא נכון. לכן הבדיקה שלנו היא ידנית ומבוססת תרחישים: מילוי טופס מלא במובייל, העתקת מספר טלפון מהאתר ובדיקה שהוא מודבק נכון, קריאה של כל פסקה עם מספרים ותאריכים, ומעבר על כל אייקון כיווני. לוקח שעתיים, חוסך חודשים של לידים שנופלים.
עיצוב אתר בעברית RTL שנעשה נכון לא נראה "מיוחד". הוא פשוט נראה נכון, והמשתמש לא חושב על זה בכלל. זה הסטנדרט, וזה מה שאנחנו מהנדסים.
נבדוק את האתר הקיים שלכם או נבנה חדש מהיסוד, עם RTL שעובד בכל שדה, בכל אייקון ובכל מספר.
