یک فرم فارسی ممکن است از نظر ظاهری مرتب باشد و همچنان انجام کار را برای بعضی کاربران دشوار کند. کاربری که با صفحه‌کلید حرکت می‌کند باید محل تمرکز را ببیند؛ کسی که از صفحه‌خوان استفاده می‌کند باید بداند هر ورودی چه چیزی می‌خواهد؛ و کاربری که خطا گرفته باید راه اصلاح را پیدا کند. زیبایی فرم زمانی به تجربهٔ مفید تبدیل می‌شود که این مسیرها هم طراحی شده باشند.
در این راهنما، یک فرم فرضی درخواست پشتیبانی را بررسی می‌کنیم: نام، راه تماس، موضوع و شرح درخواست. هدف ارائهٔ یک روش طراحی و بازبینی است، نه اعلام انطباق کامل یک محصول با استاندارد دسترس‌پذیری. مثال‌ها و تصاویر آموزشی‌اند. برای ارزیابی یک فرم واقعی، رفتار مرورگر، صفحه‌خوان، صفحه‌کلید و مسیر ثبت در سرور باید در همان محصول آزموده شوند.
۱. برچسب را به خود ورودی وصل کنید
راهنمای برچسب‌گذاری کنترل‌ها در W3C بر شناسایی ورودی‌ها با برچسب تأکید می‌کند. در حالت معمول HTML، می‌توان مقدار for در label را با id ورودی برابر گذاشت. این ارتباط به کاربر کمک می‌کند نام ورودی را در مسیرهای مختلف تعامل دریافت کند. متن راهنمای داخل کادر، جای برچسب دائمی را نمی‌گیرد؛ با وارد شدن مقدار، آن متن ممکن است از دید کاربر کنار برود.
در فرم فرضی، برچسب «راه تماس» به‌تنهایی ممکن است مبهم باشد. اگر سامانه شمارهٔ تلفن یا ایمیل را می‌پذیرد، همین انتخاب را در راهنمای نزدیک ورودی توضیح دهید. اگر فقط ایمیل پذیرفته می‌شود، نام فیلد و نوع ورودی با آن هماهنگ باشند. از کاربر نخواهید با آزمون و خطا بفهمد کدام قالب معتبر است. توضیح لازم باید پیش از نخستین تلاش برای ثبت قابل پیدا کردن باشد.
برای یک مجموعهٔ گزینه، مانند انتخاب روش پاسخ‌گویی، ارتباط گروهی را نیز بررسی کنید. برچسب هر گزینه و عنوان مجموعه دو نیاز متفاوت‌اند. همچنین معلوم کنید کدام فیلد ضروری است و این وضعیت را فقط با رنگ یا نشانه‌ای بدون توضیح نمایش ندهید. در بازبینی، نام ورودی‌ها را بدون نگاه کردن به ظاهر فرم بخوانید و ببینید آیا انجام کار همچنان قابل فهم است.
۲. متن فارسی و دادهٔ لاتین را جدا طراحی کنید
راست‌به‌چپ بودن صفحه به این معنا نیست که تمام داده‌ها هم باید همان جهت را داشته باشند. ایمیل و نشانی وب معمولاً به نمایش متفاوتی از یک شرح فارسی نیاز دارند. انتخاب جهت مناسب ورودی و محل نشان دادن مقدار، باید با نوع داده آزموده شود. در نمونهٔ پیشنهادی، شرح درخواست در جهت فارسی باقی می‌ماند و برای ایمیل، ترتیب نویسه‌ها و محل نشانگر جداگانه بررسی می‌شود.
راهنمای اعتبارسنجی ورودی در W3C توصیه می‌کند قالب‌های متنوع داده تا جای ممکن پذیرفته شوند. برای شمارهٔ تماس، شکل ارقام، فاصله و جداکننده‌ها را در مجموعهٔ آزمون قرار دهید. تصمیم دربارهٔ تبدیل ارقام فارسی یا حذف فاصله باید در برنامه روشن باشد و نتیجهٔ نهایی را به کاربر نشان دهد. این توصیه به معنای پذیرش هر مقدار یا نادیده گرفتن قواعد داده نیست.
یک بررسی کاربردی، ورود چند ترکیب واقعی است: نام فارسی همراه عدد، ایمیل طولانی، متن شامل پرانتز و شرحی که یک نشانی لاتین در میان آن دارد. جابه‌جایی نشانه‌ها ممکن است خواندن مقدار را دشوار کند. مسئله را با همان مرورگرها و اندازه‌های نمایشی هدف بررسی کنید. برای هر ورودی از یک قاعدهٔ جهت یکسان و بی‌توجه به داده استفاده نکنید.
۳. خطا باید محل و راه اصلاح داشته باشد
پیام «اطلاعات نامعتبر است» برای اصلاح یک فرم چندفیلدی کافی نیست. در طراحی پیشنهادی، هر خطا به ورودی مرتبط اشاره می‌کند و توضیح می‌دهد چه تغییری لازم است. برای مثال فرضی، پیام ایمیل می‌تواند روشن کند که بخش دامنه وارد نشده است. پیام باید با قواعد واقعی سرور هماهنگ باشد؛ رابط کاربر نباید قالبی را قبول کند که مرحلهٔ ثبت بدون توضیح دیگری رد می‌کند.
راهنمای اطلاع‌رسانی فرم در W3C روش‌هایی برای نمایش و اعلام خطا ارائه می‌کند. نشانهٔ رنگی می‌تواند کمک‌کننده باشد، اما متن و ارتباط با فیلد نیز اهمیت دارند. در یک فرم طولانی، خلاصهٔ خطاها با پیوند به محل اصلاح می‌تواند پیدا کردن مشکل را آسان‌تر کند. رفتار انتقال تمرکز باید آزموده شود تا کاربر جای خود را از دست ندهد.
مقادیر معتبر را پس از شکست ثبت نگه دارید. اگر کاربر چند پاراگراف شرح نوشته، پاک شدن همهٔ متن به علت یک خطای کوچک، هزینهٔ اصلاح را بالا می‌برد. هنگام خطای ارتباط هم روشن کنید چه چیزی معلوم است: آیا درخواست ثبت نشده، یا نتیجه هنوز نامشخص است؟ در حالت نامشخص، راه پیگیری و جلوگیری از ثبت تکراری باید در طراحی سرویس مشخص شود. متن پیام نمی‌تواند ابهام عملیات سرور را به‌تنهایی برطرف کند.
۴. مسیر صفحه‌کلید و پیام وضعیت را بررسی کنید
فرم را یک‌بار بدون ماوس کامل کنید. ترتیب حرکت میان کنترل‌ها، دیده شدن تمرکز، دسترسی به گزینه‌ها و امکان فعال کردن دکمهٔ ثبت را بررسی کنید. چیدمان بصری زیبا نباید ترتیب تعامل را نامفهوم کند. اگر یک فیلد تنها پس از انتخاب گزینه‌ای ظاهر می‌شود، باز شدن آن و موقعیت بعدی کاربر نیز باید قابل بررسی باشند. صرف وجود یک دکمهٔ قابل کلیک، مسیر صفحه‌کلید کامل نمی‌سازد.
راهنمای اطلاع‌رسانی W3C برای پیام‌های پویا نمونهٔ aria-live="polite" را توضیح می‌دهد؛ چنین ناحیه‌ای می‌تواند تغییر وضعیت را بدون قطع فوری کار جاری به فناوری کمکی منتقل کند. انتخاب رفتار مناسب به اهمیت پیام و جریان فرم وابسته است. استفادهٔ یکسان از اعلان‌های فوری برای همهٔ تغییرات، ممکن است تعامل را شلوغ کند. لازم است نتیجه با صفحه‌خوان واقعی بررسی شود.
برای فرم فرضی، وضعیت‌های «در حال ثبت»، «ثبت شد» و «ثبت انجام نشد» را جدا طراحی کنید. تغییر ظاهر دکمه بهتر است با توضیح قابل دریافت همراه باشد. آزمون کنید که پیام نهایی پس از پاسخ سرور اعلام می‌شود و به نتیجهٔ واقعی عملیات مربوط است. اگر دکمه هنگام ثبت غیرفعال می‌شود، در مسیر خطا باید دوباره امکان اقدام روشن وجود داشته باشد. کاربر نباید فقط با ناپدید شدن یک نشانگر، نتیجه را حدس بزند.
۵. آزمون را با رفتار واقعی فرم کامل کنید
دسترس‌پذیری فرم فقط به شکل HTML وابسته نیست. راهنمای اعتبارسنجی W3C یادآوری می‌کند که اعتبارسنجی مرورگر به‌تنهایی امنیت داده را تضمین نمی‌کند و بررسی در سرور نیز لازم است. در آزمون پیشنهادی، درخواست کامل، ورودی ناقص، خطای سرور و قطع ارتباط را جدا اجرا کنید. نتیجهٔ قابل مشاهدهٔ فرم باید با وضعیت ثبت در سرویس هماهنگ باشد.
اندازهٔ کوچک نمایشگر و بزرگ کردن متن را نیز در برنامهٔ بازبینی قرار دهید. برچسب نباید روی ورودی بیفتد و پیام خطا نباید خارج از محدودهٔ قابل مشاهده پنهان شود. نمونه‌های طولانی فارسی برای این بررسی مفیدند؛ یک نام کوتاه یا یک جملهٔ آزمایشی، همهٔ مشکلات چیدمان را نشان نمی‌دهد. در صورت امکان، بازخورد کاربرانی را هم بگیرید که از روش‌های مختلف تعامل استفاده می‌کنند.
گزارش تحویل فرم را کوتاه و دقیق بنویسید: چه مسیرهایی آزموده شدند، با چه محیطی، چه خطاهایی اصلاح شدند و چه چیزی هنوز بررسی نشده است. گفتن «فرم دسترس‌پذیر است» بدون تعیین دامنهٔ آزمون، برای تصمیم فنی کافی نیست. یک فرم کوچک با برچسب روشن، خطای قابل اصلاح و وضعیت قابل پیگیری، نقطهٔ شروع مناسبی است؛ کیفیت نهایی از بررسی رفتار واقعی و اصلاح پیوسته به دست می‌آید.
منابع و مطالعهٔ بیشتر
بررسی منابع: ۲۲ مهر ۱۴۰۵. تحلیل‌ها و پیشنهادهای اجرایی، جمع‌بندی نویسنده‌اند.
