שיטות מומלצות לשימוש בטופס כניסה לחשבון

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

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

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

רשימת המשימות

יש להשתמש ב-HTML בעל משמעות

צריך להשתמש באלמנטים שמיועדים למשימה: <form>, <label> ו-<button>. הן מאפשרות פונקציונליות מובנית של הדפדפן, משפרות את הנגישות ומוסיפים משמעות לתגי העיצוב.

שימוש ב-<form>

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

שימוש ב-<label>

כדי להוסיף תווית לקלט, יש להשתמש בסימן <label>.

<label for="email">Email</label>
<input id="email" …>

יש שתי סיבות:

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

אל תשתמשו ב-placeholders כתוויות קלט. אנשים עלולים לשכוח את תוכן הקלט אחרי שהתחילו להזין טקסט, במיוחד אם דעתם מוסחת ("האם הזנתי כתובת אימייל, מספר טלפון או מזהה חשבון?"). יש הרבה בעיות אפשריות אחרות ב-placeholders: אם אינכם משוכנעים, מומלץ לקרוא את המאמר לא להשתמש במאפיין Placeholder ואת המאמר placeholders בשדות טפסים מזיקים.

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

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

פותחים את הגליץ' label-position במכשיר נייד כדי לראות בעצמכם.

שימוש ב-<button>

השתמשו ב-<button> ללחצנים! רכיבי הלחצן מספקים התנהגות נגישה ופונקציונליות מובנית לשליחת טפסים, ואפשר לסגנן אותם בקלות. אין טעם להשתמש ב-<div> או ברכיב אחר שנראה כאילו הוא לחצן.

מוודאים שלחצן השליחה מציין מה הוא עושה. לדוגמה: Create account או Sign in, ולא Submit או Start.

איך מוודאים שהטופס נשלח

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

  • צריך לעבור לדף אחר.
  • אמולציה של הניווט באמצעות History.pushState() או History.replaceState() והסרת טופס הסיסמה.

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

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

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

אין להכפיל את אפשרויות הקלט

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

הפקת התועלת המקסימלית ממאפייני הרכיבים

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

מומלץ לשמור על פרטיות הסיסמאות, אבל לאפשר למשתמשים לראות אותן אם הם רוצים

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

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

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

תנו למשתמשים בנייד את המקלדת הנכונה

השתמש ב-<input type="email"> כדי לתת למשתמשים ניידים מקלדת מתאימה ולהפעיל אימות כתובת אימייל מובנית בסיסית על ידי הדפדפן... אין צורך ב-JavaScript!

אם צריך להשתמש במספר טלפון במקום בכתובת אימייל, <input type="tel"> מפעיל לוח חיוג בטלפון בנייד. אפשר גם להשתמש במאפיין inputmode כשצריך: inputmode="numeric" הוא אידיאלי למספרי קוד אימות. כל מה שרצית לדעת על מצב קלט כולל יותר פרטים.

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

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

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

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

צילום מסך של טופס כניסה בטלפון Android: הלחצן &#39;כניסה&#39; לא מוסתר על ידי המקלדת של הטלפון.
המקלדת לא מסתירה את הלחצן כניסה.

בדיקה במגוון מכשירים

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

צילומי מסך של טופס כניסה במכשירי iPhone 7, 8 ו-11. במכשירי iPhone 7 ו-8, הלחצן &#39;כניסה&#39; מוסתר על ידי המקלדת של הטלפון, אבל לא ב-iPhone 11.
הלחצן כניסה: מוסתר ב-iPhone 7 ו-8, אבל לא ב-iPhone 11.

מומלץ להשתמש בשני דפים

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

צילום מסך של טופס כניסה באתר Amazon: אימייל/טלפון וסיסמה בשני &#39;דפים&#39; נפרדים.
כניסה דו-שלבית: אימייל או טלפון ואז סיסמה.

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

לעזור למשתמשים להימנע מהזנה חוזרת של נתונים

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

תהליך היצירה מורכב משני חלקים:

  1. המאפיינים autocomplete, name, id ו-type עוזרים לדפדפנים להבין את התפקיד של ערכי קלט כדי לאחסן נתונים שאפשר להשתמש בהם מאוחר יותר למילוי אוטומטי. כדי לאפשר אחסון של נתונים למילוי אוטומטי, דפדפנים מודרניים דורשים גם שקלט יהיה ערך יציב של name או id (לא נוצר באופן אקראי בכל טעינת דף או פריסה של אתר), והם צריכים להיות בתוך <form> עם לחצן submit.

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

לקלט של כתובות אימייל צריך להשתמש ב-autocomplete="username", כי מנהלי הסיסמאות מזהים את username בדפדפנים מודרניים – אפילו שכדאי להשתמש ב-type="email", וכדאי גם להשתמש ב-id="email" וב-name="email".

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

יש להשתמש ב-autocomplete="new-password" וב-id="new-password" לסיסמה חדשה

  • השתמשו ב-autocomplete="new-password" וב-id="new-password" כקלט הסיסמה בטופס הרשמה, או בסיסמה החדשה בטופס לשינוי סיסמה.

יש להשתמש ב-autocomplete="current-password" וב-id="current-password" לסיסמה קיימת

  • השתמשו ב-autocomplete="current-password" וב-id="current-password" כקלט הסיסמה בטופס כניסה, או כקלט של הסיסמה הישנה של המשתמש בטופס לשינוי סיסמה. פעולה זו מורה לדפדפן להשתמש בסיסמה הנוכחית שנשמרה עבור האתר.

עבור טופס הרשמה:

<input type="password" autocomplete="new-password" id="new-password" …>

כדי להיכנס:

<input type="password" autocomplete="current-password" id="current-password" …>

מנהלי סיסמאות לתמיכה

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

צילומי מסך של שלושה שלבים של תהליך כניסה ב-Safari במחשב: מנהל סיסמאות, אימות ביומטרי, מילוי אוטומטי.
כניסה באמצעות השלמה אוטומטית – אין צורך בהזנת טקסט!

ב-Chrome במחשב מוצגות הצעות לאימייל, מנהל הסיסמאות ומילוי אוטומטי של הסיסמה.

צילומי מסך של ארבעת השלבים של תהליך הכניסה ב-Chrome במחשב: השלמת אימייל, הצעת אימייל, מנהל סיסמאות, מילוי אוטומטי לאחר הבחירה.
השלמה אוטומטית של תהליך הכניסה ב-Chrome 84.

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

מילוי אוטומטי: מה שמפתחי האינטרנט צריכים לדעת, אבל אין להם מידע רב יותר על השימוש ב-name וב-autocomplete. מפרט HTML מציג את כל 59 הערכים האפשריים.

יש להפעיל את הדפדפן כדי להציע סיסמה חזקה

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

כך Safari עושה זאת במחשב.

צילום מסך של מנהל הסיסמאות של Firefox במחשב
תהליך ההצעות לסיסמאות ב-Safari.

(הצעת סיסמה ייחודית חזקה כבר זמינה ב-Safari מגרסה 12.0).

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

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

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

צילום מסך של דפדפן Firefox ו-Chrome ל-Android במחשב שבו מוצגת הבקשה &#39;יש למלא את השדה הזה&#39; כדי לאתר נתונים חסרים.
הצגת בקשה והתמקדות בנתונים חסרים ב-Firefox למחשב (גרסה 76) וב-Chrome ל-Android (גרסה 83).

עיצוב לאצבעות ולאצבעות

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

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

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

צילום מסך של טופס לא מעוצב ב-Chrome למחשב וב-Chrome ל-Android.

לפי הנחיות הנגישוּת של Android, גודל היעד המומלץ לאובייקטים במסך מגע הוא 7 עד 10 מ"מ. בהנחיות בממשק של Apple יש תמיכה בגודל 48x48 פיקסלים, וב-W3C יש הצעה לפחות בגודל 44x44 פיקסלים של CSS. על הבסיס הזה, צריך להוסיף (לפחות) כ-15 פיקסלים של מרווח פנימי לאלמנטים וללחצנים בניידים, וכ-10 פיקסלים במחשב. נסו להשתמש במכשיר נייד אמיתי באצבע או באגודל אמיתי. אתם אמורים להיות מסוגלים להקיש על כל אחד מהקלטים והלחצנים בנוחות.

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

עיצוב לאגודלים

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

הטקסט צריך להיות גדול מספיק

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

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

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

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

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

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

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

חשוב לוודא שהקלט מוצג באופן ברור

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

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

צילום מסך של טופס מעוצב ב-Chrome ל-Android.
טקסט קריא, גבולות קלט גלויים, מרווח פנימי ושוליים מתאימים.

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

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

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

אפשר להשתמש בסלקטור ב-CSS :invalid כדי להדגיש נתונים לא חוקיים. כדאי להשתמש ב-:not(:placeholder-shown) כדי להימנע מבחירת מקורות קלט שאין בהם תוכן.

input[type=email]:not(:placeholder-shown):invalid {
  color: red;
  outline-color: red;
}

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

שימוש ב-JavaScript במקרה הצורך

הצגה או הסתרה של הסיסמאות

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

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

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

HTML:

<section>
  <label for="password">Password</label>
  <button id="toggle-password" type="button" aria-label="Show password as plain text. Warning: this will display your password on the screen.">Show password</button>
  <input id="password" name="password" type="password" autocomplete="current-password" required>
</section>

כדי שהלחצן ייראה כמו טקסט פשוט:

button#toggle-password {
  background: none;
  border: none;
  cursor: pointer;
  /* Media query isn't shown here. */
  font-size: var(--mobile-font-size);
  font-weight: 300;
  padding: 0;
  /* Display at the top right of the container */
  position: absolute;
  top: 0;
  right: 0;
}

וקוד ה-JavaScript להצגת הסיסמה:

const passwordInput = document.getElementById('password');
const togglePasswordButton = document.getElementById('toggle-password');

togglePasswordButton.addEventListener('click', togglePassword);

function togglePassword() {
  if (passwordInput.type === 'password') {
    passwordInput.type = 'text';
    togglePasswordButton.textContent = 'Hide password';
    togglePasswordButton.setAttribute('aria-label',
      'Hide password.');
  } else {
    passwordInput.type = 'password';
    togglePasswordButton.textContent = 'Show password';
    togglePasswordButton.setAttribute('aria-label',
      'Show password as plain text. ' +
      'Warning: this will display your password on the screen.');
  }
}

הנה התוצאה הסופית:

צילומי מסך של טופס הכניסה עם טקסט הסיסמה &#39;button&#39;, ב-Safari ב-Mac וב-iPhone 7.
טופס כניסה עם הטקסט 'button' הצגת הסיסמה, ב-Safari ב-Mac וב-iPhone 7.

הזנת סיסמה נגישה

אפשר להשתמש ב-aria-describedby כדי לתאר כללי סיסמה באמצעות המזהה של הרכיב שמתאר את האילוצים. קוראי מסך מספקים את טקסט התווית, את סוג הקלט (סיסמה) ואת התיאור.

<input type="password" aria-describedby="password-constraints" …>
<div id="password-constraints">Eight or more characters with a mix of letters, numbers and symbols.</div>

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

<button id="toggle-password"
        aria-label="Show password as plain text.
                    Warning: this will display your password on the screen.">
  Show password
</button>

אפשר לראות את שתי התכונות של ARIA בפעולה בתקלה הבאה:

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

אימות בזמן אמת ולפני השליחה

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

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

מידע נוסף: שימוש ב-JavaScript לאימות מורכב יותר בזמן אמת.

Analytics ו-RUM

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

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

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

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

הנחיות כלליות

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

  • אל תגרום למשתמשים לחפש כניסה! עליך להוסיף קישור לטופס הכניסה בחלק העליון של הדף, ולכלול ניסוח שמנוסח היטב כמו Sign In (כניסה), Create Account (יצירת חשבון) או Register (הרשמה).
  • חשוב לשמור על ריכוז. טופסי הרשמה הם לא המקום להסיח את דעתם של אנשים באמצעות מבצעים ותכונות אחרות באתר.
  • מזער את המורכבות של ההרשמה. ניתן לאסוף נתוני משתמשים אחרים (כמו כתובות או פרטי כרטיס אשראי) רק כשהמשתמשים רואים תועלת ברורה במסירת הנתונים האלה.
  • לפני שהמשתמשים מתחילים למלא את טופס ההרשמה, חשוב להבהיר מהי הצעת הערך. איך הכניסה לחשבון מועילה להם? לתת למשתמשים תמריצים ממשיים להשלים את ההרשמה.
  • אם אפשר, כדאי לאפשר למשתמשים להזדהות באמצעות מספר טלפון נייד במקום כתובת אימייל, כי יכול להיות שחלק מהמשתמשים לא משתמשים באימייל.
  • אפשרו למשתמשים לאפס את הסיסמה שלהם בקלות והבהירו את הקישור שכחת את הסיסמה?
  • קישור למסמכים של התנאים וההגבלות ומדיניות הפרטיות: הבהירו למשתמשים כבר מההתחלה איך להגן על הנתונים שלהם.
  • חשוב לכלול את הלוגו והשם של החברה או הארגון בדפי ההרשמה והכניסה, ולוודא בשפה, בגופנים ובסגנונות שמתאימים לשאר האתר. טפסים מסוימים לא מרגישים שהם שייכים לאותו אתר כמו תוכן אחר, במיוחד אם יש להם כתובת URL שונה באופן משמעותי.

להמשיך ללמוד

תמונה מאת Meghan Schiereck ב-UnFlood.