فردی نابینا در حال استفاده از اینترنت است و عینک آفتابی به چشم دارد و از کیبیورد استفاده میکند

دسترس‌پذیرسازی فرم‌های اینترنتی برای افراد نابینا

دسترس‌پذیرسازی فرم‌های اینترنتی رزرو برای افراد نابینا

مبتنی بر معیارهای موفقیت WCAG 2.0

مقدمه

افراد نابینا برای تعامل با فرم‌های اینترنتی به صفحه‌خوان‌ها (Screen Readers) مانند NVDA، JAWS یا VoiceOver متکی هستند. این فناوری‌ها ساختار برنامه‌نویسی‌شده صفحه را به گفتار یا خط بریل تبدیل می‌کنند. اگر فرم‌ها به درستی نشانه‌گذاری نشده باشند، فرد نابینا قادر به درک چیستی هر فیلد، تشخیص خطاها یا اتمام موفقیت‌آمیز فرآیند رزرو نخواهد بود.

بر اساس گزارش سازمان ناظر نروژی UU، اگرچه ۹۲٪ وب‌سایت‌ها از برچسب‌های توصیفی برای فیلدها استفاده می‌کنند، اما تنها ۲۳٪ از آن‌ها دارای نشانگر فوکوس مرئی مناسب هستند و ۳۳٪ نشانه‌گذاری صحیح فرم‌ها را پیاده‌سازی کرده‌اند. این آمار نشان می‌دهد که علی‌رغم پیشرفت‌ها، هنوز شکاف قابل توجهی در دسترس‌پذیری فرم‌ها برای کاربران نابینا وجود دارد.

در این مقاله، تمام شاخص‌های موفقیت WCAG 2.0 مؤثر بر دسترس‌پذیری فرم‌های رزرو برای افراد نابینا، به صورت نظام‌مند و سطح‌بندی‌شده ارائه می‌شود.


بخش اول: شاخص‌های سطح A (الزامات پایه و حیاتی)

این شاخص‌ها کمترین سطح پذیرش را دارند و عدم رعایت هریک از آن‌ها به منزله ایجاد مانع جدی برای کاربران نابینا محسوب می‌شود.

۱.۱ نام، نقش و مقدار (۴.۱.۲ – سطح A)

هدف: اطمینان از این که صفحه‌خوان بتواند نام، نقش (نوع فیلد) و وضعیت (انتخاب‌شده، چک‌شده و غیره) هر المان فرم را به کاربر اعلام کند.

الزامات فنی:

  • هر فیلد ورودی باید دارای یک نام قابل دسترس (Accessible Name) باشد که صفحه‌خوان آن را اعلام کند
  • نوع فیلد (textbox، checkbox، radio، button، combobox) باید به درستی در HTML مشخص شود
  • وضعیت‌های فیلد مانند انتخاب شدن (checked)، غیرفعال بودن (disabled)، یا توسعه/جمع‌شدگی (expanded/collapsed) باید برنامه‌نویسی شده باشند

مثال: استفاده از <input type="checkbox" checked> به جای ساخت سفارشی با جاوااسکریپت که وضعیت را به صفحه‌خوان منتقل نمی‌کند.

۱.۲ اطلاعات و روابط (۱.۳.۱ – سطح A)

هدف: اطمینان از این که روابط ساختاری بین فیلدها، برچسب‌ها و گروه‌ها قابل تعیین برنامه‌نویسی باشد.

الزامات فنی:

  • گروه‌بندی فیلدهای مرتبط با استفاده از <fieldset> و <legend>
  • اتصال صریح برچسب‌ها به فیلدها با <label for="id">
  • استفاده از نشانه‌گذاری معنایی مناسب برای لیست‌ها، جداول و هدینگ‌ها

کاربرد در فرم رزرو:

  • گروه‌بندی اطلاعات مسافر (نام، نام خانوادگی، تلفن) در یک <fieldset> با عنوان <legend>اطلاعات مسافر</legend>
  • گروه‌بندی اطلاعات پرواز (مبدأ، مقصد، تاریخ) در <fieldset> مجزا

۱.۳ معنی‌دار بودن ترتیب (۱.۳.۲ – سطح A)

هدف: ترتیب خواندن صفحه توسط صفحه‌خوان باید منطقی و متناظر با ترتیب بصری باشد.

کاربرد: هنگام Tab زدن یا حرکت با صفحه‌خوان، فوکوس باید به ترتیب درست از فیلدهای بالا به پایین و چپ به راست حرکت کند، نه جهشی.

۱.۴ برچسب‌ها یا دستورالعمل‌ها (۳.۳.۲ – سطح A)

هدف: هر فیلد فرم باید دارای برچسب یا دستورالعملی باشد که هدف آن را شرح دهد.

این یکی از حیاتی‌ترین شاخص‌ها برای کاربران نابینا است. بدون برچسب مناسب، صفحه‌خوان صرفاً چیزی شبیه «ادیت باکس» اعلام می‌کند بدون این که کاربر بداند چه اطلاعاتی باید وارد کند.

روش‌های تأمین (به ترتیب اولویت):

۱. G131 + H44: استفاده از <label> با ویژگی for (روش ارجح)

   <label for="passenger-name">نام و نام خانوادگی مسافر</label>
   <input type="text" id="passenger-name" name="passenger_name">

۲. G89: ارائه مثال از فرمت مورد انتظار (مانند «تاریخ: YYYY/MM/DD»)

۳. H65: استفاده از ویژگی title (فقط زمانی که <label> امکان‌پذیر نیست – روش آخر)

۴. H71: استفاده از <fieldset> و <legend> برای گروه‌بندی فیلدها

توجه: برچسب باید به تنهایی هدف فیلد را شرح دهد. برچسب مبهم مانند «مقدار» یا «متن» کافی نیست.

۱.۵ متن جایگزین برای محتوای غیرمتنی (۱.۱.۱ – سطح A)

هدف: هر محتوای غیرمتنی (مانند تصاویر، کپچاها، دکمه‌های تصویری) باید دارای متن جایگزین باشد.

الزامات در فرم رزرو:

  • دکمه‌های تصویری (مانند دکمه جستجو با آیکون ذره‌بین) دارای alt توصیفی
  • تصاویر تزئینی دارای alt="" برای نادیده گرفته شدن توسط صفحه‌خوان
  • کپچاها باید دارای متن جایگزین یا راهکار جایگزین دسترس‌پذیر باشند

۱.۶ قابلیت استفاده از صفحه کلید (۲.۱.۱ – سطح A)

هدف: تمام قابلیت‌های فرم باید تنها با استفاده از صفحه کلید قابل اجرا باشند.

فرد نابینا به طور طبیعی از صفحه کلید (کلیدهای Tab، Enter، Space و کلیدهای جهت‌نما) برای پیمایش استفاده می‌کند. هیچ عملی نباید نیاز به ماوس داشته باشد.

موارد بررسی:

  • همه فیلدها، دکمه‌ها، چک‌باکس‌ها و رادیوباتن‌ها با Tab قابل دسترسی باشند
  • منوهای کشویی سفارشی باید با کلیدهای جهت‌نما قابل پیمایش باشند
  • دکمه‌ها با Enter و Space فعال شوند

۱.۷ عدم به دام افتادن فوکوس صفحه کلید (۲.۱.۲ – سطح A)

هدف: کاربر نباید در هیچ المانی به دام بیفتد؛ یعنی بتواند با صفحه کلید وارد المان شود و از آن خارج گردد.

مثال نقض: پنجره مدال که فوکوس را قفل می‌کند و کاربر نمی‌تواند بدون ماوس از آن خارج شود. باید راهی با کلید Escape وجود داشته باشد.

۱.۸ عدم استفاده صرف از ویژگی‌های حسی (۱.۳.۳ – سطح A)

هدف: دستورالعمل‌ها نباید صرفاً به ویژگی‌های حسی مانند مکان بصری، شکل یا صدا ارجاع دهند.

مثال نقض: «روی دکمه سمت راست کلیک کنید» (کاربر نابینا نمی‌داند راست کجاست). به جای آن: «روی دکمه «ادامه» کلیک کنید».

۱.۹ عدم استفاده صرف از رنگ (۱.۴.۱ – سطح A)

هدف: رنگ نباید تنها روش انتقال اطلاعات باشد.

کاربرد در فرم رزرو:

  • فیلدهای اجباری نباید تنها با رنگ قرمز مشخص شوند. از ستاره (*) یا عبارت «الزامی» نیز استفاده شود
  • خطاها نباید تنها با حاشیه قرمز نشان داده شوند. متن خطا نیز ارائه شود

۱.۱۰ عنوان صفحه (۲.۴.۲ – سطح A)

هدف: هر صفحه وب باید عنوانی توصیفی و منحصربه‌فرد داشته باشد.

کاربرد: <title>صفحه رزرو پرواز تهران-مشهد - مرحله ۱ از ۳</title>. این عنوان اولین چیزی است که صفحه‌خوان هنگام بارگذاری صفحه اعلام می‌کند.

۱.۱۱ شناسایی خطا (۳.۳.۱ – سطح A)

هدف: در صورت بروز خطا، فیلد خطادار و توضیح خطا به صورت متنی به کاربر شناسانده شود.

الزامات:

  • خطا باید به صورت متن در صفحه ظاهر شود (نه فقط در یک alert جاوااسکریپت)
  • فیلد خطادار به طور واضح مشخص شود (با متن، نه فقط رنگ)
  • در حالت ایده‌آل، فوکوس به اولین فیلد خطادار منتقل شود

مثال: «خطا: فیلد «تاریخ تحویل» خالی است. لطفاً یک تاریخ وارد کنید.»


بخش دوم: شاخص‌های سطح AA (استانداردهای رایج و توصیه‌شده)

این شاخص‌ها برای دسترس‌پذیری مطلوب ضروری هستند و در بسیاری از قوانین و خط‌مشی‌ها الزامی محسوب می‌شوند.

۲.۱ هدینگ‌ها و برچسب‌ها (۲.۴.۶ – سطح AA)

هدف: هدینگ‌ها و برچسب‌ها باید هدف یا موضوع را توصیف کنند.

این معیار فراتر از وجود برچسب (۳.۳.۲) است و به کیفیت توصیف‌گری آن‌ها تأکید دارد. برچسب «فیلد ۱» کافی نیست؛ باید «نام کامل مسافر» باشد.

هم‌چنین، استفاده از هدینگ‌های (<h1> تا <h6>) برای ایجاد ساختار سلسله‌مراتبی منطقی در فرم‌های چندبخشی ضروری است.

۲.۲ نشانگر فوکوس مرئی (۲.۴.۷ – سطح AA)

هدف: نشانگر بصری واضحی برای المانی که فوکوس صفحه کلید روی آن است وجود داشته باشد.

برای فرد نابینایی که از صفحه کلید استفاده می‌کند، نشانگر فوکوس مرئی برای افرادی که کم‌بینا هستند یا در پیگیری مکان خود روی صفحه مشکل دارند حیاتی است. گزارش UU نشان می‌دهد که تنها ۲۳٪ وب‌سایت‌ها این شرط را رعایت می‌کنند.

الزام:

  • استایل پیش‌فرض مرورگر برای :focus حذف نشود
  • یا استایل سفارشی با کنتراست مناسب (حداقل ۳:۱) ارائه شود
  • نشانگر باید در همه المان‌های تعاملی (فیلدها، دکمه‌ها، لینک‌ها) قابل مشاهده باشد

۲.۳ پیشنهاد اصلاح خطا (۳.۳.۳ – سطح AA)

هدف: علاوه بر شناسایی خطا، پیشنهاد اصلاح نیز به کاربر ارائه شود.

مثال:

  • به جای «فرمت تاریخ نامعتبر» → «لطفاً تاریخ را به فرمت YYYY/MM/DD وارد کنید، مانند ۱۴۰۳/۰۱/۱۵»
  • فیلد اجباری خالی → «این فیلد اجباری است. لطفاً مقدار آن را وارد کنید»

۲.۴ پیشگیری از خطا (۳.۳.۴ – سطح AA) – ویژه رزرو

هدف: برای فرم‌های دارای عواقب مالی یا قانونی (مانند رزرو بلیط هتل)، حداقل یکی از موارد زیر فراهم شود:

۱. قابل برگشت بودن: امکان لغو یا اصلاح رزرو پس از ثبت
۲. بررسی: صفحه خلاصه اطلاعات قبل از نهایی‌سازی با امکان ویرایش
۳. تأیید نهایی: گرفتن تأیید صریح کاربر قبل از ارسال نهایی

۲.۵ قابلیت بزرگنمایی متن (۱.۴.۴ – سطح AA)

هدف: متن باید تا ۲۰۰٪ بدون از دست رفتن کارایی یا محتوا قابل بزرگنمایی باشد.

کاربران کم‌بینا که از ذره‌بین صفحه استفاده می‌کنند باید بتوانند متن فیلدها و دکمه‌ها را بدون شکستگی صفحه بخوانند.

۲.۶ کنتراست رنگ (۱.۴.۳ – سطح AA)

هدف: نسبت کنتراست بین متن و پس‌زمینه حداقل ۴.۵:۱ برای متن معمولی و ۳:۱ برای متن بزرگ باشد.

این معیار برای کاربران کم‌بینا که با صفحه‌خوان کار نمی‌کنند اما دید محدودی دارند ضروری است.


بخش سوم: شاخص‌های سطح AAA (حداکثر دسترس‌پذیری)

این شاخص‌ها برای شرایط خاص و بهبود تجربه کاربری پیشرفته‌تر طراحی شده‌اند.

۳.۱ وضعیت نشان دادن مکان (۲.۴.۸ – سطح AAA)

هدف: آگاهی از موقعیت فعلی کاربر در ساختار سایت (مانند نان‌دانه‌ها یا نمایش «مرحله ۲ از ۵»).

۳.۲ زبان بخش‌ها (۳.۱.۲ – سطح AAA)

هدف: زبان هر بخش از محتوا به صورت برنامه‌نویسی قابل تعیین باشد تا صفحه‌خوان با تلفظ صحیح آن را بخواند.


جمع‌بندی و چک‌لیست سریع

اولویتشاخصسطحتأثیر بر نابینایان
حیاتی۴.۱.۲ Name, Role, ValueAصفحه‌خوان نوع و وضعیت فیلد را اعلام کند
حیاتی۱.۳.۱ Info and RelationshipsAاتصال برچسب به فیلد و گروه‌بندی معنایی
حیاتی۳.۳.۲ Labels or InstructionsAوجود برچسب توصیفی برای هر فیلد
حیاتی۲.۱.۱ KeyboardAقابلیت پیمایش کامل با Tab
بسیار مهم۲.۴.۷ Focus VisibleAAنشانگر مرئی فوکوس صفحه کلید
بسیار مهم۳.۳.۳ Error SuggestionAAپیشنهاد اصلاح برای خطاها
بسیار مهم۳.۳.۴ Error PreventionAAصفحه تأیید و خلاصه برای رزرو
مهم۱.۴.۳ ContrastAAخوانایی متن برای کم‌بینایان
مهم۱.۴.۴ Resize TextAAبزرگنمایی تا ۲۰۰٪ بدون شکستگی

منابع مورد استفاده

  • UU Agency Norway, Status of Universal Design of ICT 2020
  • CWTSatoTravel, E2 Solutions VPAT2 – Section 508 Conformance Statement
  • W3C WAI, Forms: Concepts (Draft)
  • FormAssembly, How to Meet ADA and Section 508 Standards
  • govt.nz, Form labels and instructions – Web Accessibility Guidance
  • U.S. Access Board, Section 508 ICT Testing Baseline – 10. Forms
  • WAIC, F81: Failure due to using color only to identify required/error fields
  • WebAIM, WCAG 2 Checklist
  • W3C, Understanding WCAG 2.0 – SC 3.3.2, 3.3.3, 3.3.4
  • MDN, Understanding WCAG – Perceivable Principle

برچسب‌های به‌کار رفته در این مقاله:

دسته‌بندی موضوعی:


دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

error: اجازه کپی محتوا وجود ندارد