خانهٔ دسترسی‌پذیری و کاربرد‌پذیری

تحلیل شاخص‌های موفقیت WCAG 2.0 برای کاربرانی که هم نابینا و هم ناشنوا هستند

چکیده

افراد نابینا-ناشنوا (Deaf-Blind) با چالش‌های منحصربه‌فردی در تعامل با فرم‌های اینترنتی مواجه هستند، زیرا نمی‌توانند از کانال‌های بصری یا شنیداری برای دریافت اطلاعات استفاده کنند. استاندارد WCAG 2.0 اگرچه شاخص مستقیمی با عنوان «ویژه نابینا-ناشنوایان» ندارد، اما از طریق ترکیب شاخص‌های طراحی‌شده برای نابینایان و ناشنوایان، نیازهای این گروه را پوشش می‌دهد. این مقاله به بررسی جامع این شاخص‌ها، نحوه ترکیب آن‌ها، و پیاده‌سازی در فرم‌های رزرو می‌پردازد.

مقدمه

جامعه نابینا-ناشنوا به افرادی اطلاق می‌شود که با درجات متفاوتی از نابینایی و ناشنوایی مواجه هستند. این افراد برای دسترسی به اطلاعات دیجیتال، معمولاً از صفحه‌خوان‌های خط بریل قابل تغییر (Refreshable Braille Display) استفاده می‌کنند – دستگاه‌هایی که متن دیجیتال را به پین‌های بریل در حال حرکت تبدیل می‌کنند.

طبق مستندات رسمی W3C، WCAG 2.0 «طیف گسترده‌ای از ناتوانی‌ها از جمله نابینایی و کم‌بینایی، ناشنوایی و کم‌شنوایی، ناتوانی‌های یادگیری، محدودیت‌های شناختی، محدودیت حرکتی، مشکلات گفتاری، حساسیت به نور و ترکیبی از این موارد» را پوشش می‌دهد.

فرم‌های رزرو اینترنتی – چه برای رزرو هتل، پرواز، تور یا خدمات دیگر – به دلیل ماهیت چندمرحله‌ای، نیاز به ورود دقیق اطلاعات، و عواقب مالی احتمالی اشتباهات، برای این گروه از کاربران چالش‌برانگیزتر از صفحات معمولی هستند. این مقاله نشان می‌دهد که چگونه رعایت مجموعه‌ای از شاخص‌های WCAG 2.0 می‌تواند این موانع را برطرف کند.

چرا شاخص مستقیم جداگانه برای نابینا-ناشنوایان وجود ندارد؟

سه دلیل اصلی برای عدم وجود شاخص موفقیت مستقیم و مجزا در WCAG 2.0 وجود دارد:

اول: رویکرد مبتنی بر اصول کلی (POUR). WCAG بر چهار اصل «قابل درک بودن (Perceivable)، قابل کار بودن (Operable)، قابل فهم بودن (Understandable) و پایدار بودن (Robust)» استوار است که به جای ناتوانی خاص، نیازهای کلی همه کاربران را هدف قرار می‌دهد.

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

سوم: ملاحظات آماری. جمعیت نابینا-ناشنوایان نسبت به سایر گروه‌های ناتوانی کوچک‌تر است و ایجاد شاخص‌های جداگانه برای هر ترکیب ممکن از ناتوانی‌ها (نابینا-ناشنوا، نابینا-معلول حرکتی، ناشنوا-معلول شناختی و …) عملاً غیرعملی و از نظر روش‌شناسی ناممکن خواهد بود.

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

بخش اول: شاخص‌های برگرفته از نیازهای نابینایان

این شاخص‌ها تضمین می‌کنند که محتوا برای تبدیل به خط بریل (یا گفتار، در صورت باقی‌ماندن شنوایی جزئی) قابل دسترس باشد.

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

هدف: تمام محتوای غیرمتنی باید دارای متن جایگزین باشد تا فناوری‌های کمکی بتوانند آن را به خط بریل تبدیل کنند.

الزامات فنی:

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

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

<!-- تصویر تبلیغاتی مقصد -->
<img src="tehran-tower.jpg" alt="برج میلاد تهران، نماد پایتخت ایران">

<!-- آیکون تقویم در کنار فیلد تاریخ -->
<img src="calendar-icon.png" alt="انتخاب تاریخ">

<!-- دکمه جستجو با آیکون -->
<button aria-label="جستجوی پرواز">
  <img src="search-icon.png" alt="">
  جستجو
</button>

تأثیر بر نابینا-ناشنوا: بدون متن جایگزین، صفحه‌خوان خط بریل هیچ اطلاعاتی از تصاویر ارائه نمی‌دهد و کاربر بخش قابل توجهی از محتوای صفحه را از دست می‌دهد.

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

هدف: نام، نقش (نوع فیلد) و وضعیت هر المان فرم باید به صورت برنامه‌نویسی قابل تعیین باشد.

الزامات فنی:

• هر فیلد ورودی دارای <label> با ویژگی for متصل به id فیلد
• وضعیت چک‌باکس‌ها (checked) و رادیوباتن‌ها در HTML مشخص شده باشد
• دکمه‌ها دارای متن توصیفی (نه صرفاً آیکون)
• برای المان‌های سفارشی ساخته‌شده با جاوااسکریپت، از ARIA برای اعلام نقش و وضعیت استفاده شود

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

<!-- برچسب متصل به فیلد -->
<label for="passenger-name">نام کامل مسافر</label>
<input type="text" id="passenger-name" name="passenger_name">

<!-- رادیوباتن با وضعیت مشخص -->
<fieldset>
  <legend>نوع بلیط</legend>
  <label><input type="radio" name="ticket-type" value="economy" checked> اقتصادی</label>
  <label><input type="radio" name="ticket-type" value="business"> بیزینس</label>
</fieldset>

تأثیر بر نابینا-ناشنوا: کاربر با خط بریل می‌تواند تشخیص دهد که در حال تعامل با «فیلد متنی به نام «نام کامل مسافر»» است یا «دکمه رادیویی انتخاب‌شده با عنوان «اقتصادی»».

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

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

الزامات فنی:

• گروه‌بندی فیلدهای مرتبط با <fieldset> و <legend>
• استفاده از هدینگ‌های <h1> تا <h6> برای ساختاردهی بخش‌های مختلف فرم
• استفاده از لیست‌های <ul> و <ol> برای نمایش گزینه‌های مرتبط

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

<h2>اطلاعات پرواز رفت</h2>
<fieldset>
  <legend>مبدأ و مقصد</legend>
  <label for="origin">مبدأ</label>
  <input type="text" id="origin" name="origin">
  <label for="destination">مقصد</label>
  <input type="text" id="destination" name="destination">
</fieldset>

<fieldset>
  <legend>تاریخ سفر</legend>
  <label for="departure">تاریخ رفت</label>
  <input type="date" id="departure" name="departure">
  <label for="return">تاریخ برگشت</label>
  <input type="date" id="return" name="return">
</fieldset>

تأثیر بر نابینا-ناشنوا: کاربر متوجه می‌شود که فیلدهای «مبدأ» و «مقصد» با هم مرتبط هستند و «تاریخ رفت» و «تاریخ برگشت» گروه دیگری را تشکیل می‌دهند. این ساختار، بار شناختی را کاهش می‌دهد.

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

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

الزامات فنی:

• ترتیب DOM (مدل شیءگرای سند) باید با ترتیب بصری مطابقت داشته باشد
• از تغییر ترتیب با CSS (مانند order در flexbox) که DOM را تغییر نمی‌دهد اما ترتیب بصری را تغییر می‌دهد، با احتیاط استفاده شود

تأثیر بر نابینا-ناشنوا: کاربر با خط بریل فیلدها را به همان ترتیبی دریافت می‌کند که یک کاربر بینا روی صفحه می‌بیند. اگر این ترتیب نامنطقی باشد (مثلاً فیلد «نام خانوادگی» قبل از «نام» خوانده شود)، کاربر سردرگم می‌شود.

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

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

نمونه‌های نقض ممنوع:

• ❌ «روی دکمه سمت راست کلیک کنید» (کاربر نمی‌داند راست کجاست)
• ❌ «فیلد قرمز رنگ را پر کنید» (کاربر رنگ را نمی‌بیند)
• ❌ «پس از شنیدن بیپ، دکمه تأیید را بزنید» (کاربر صدا را نمی‌شنود)
• ❌ «گزینه دایره‌شکل را انتخاب کنید» (کاربر شکل را نمی‌بیند)

نمونه‌های صحیح:

• ✅ «روی دکمه «ادامه» کلیک کنید»
• ✅ «فیلد اجباری (مشخص شده با ستاره) را پر کنید»
• ✅ «پس از نمایش پیام تأیید روی صفحه، دکمه تأیید را بزنید»
• ✅ «گزینه «اقتصادی» را انتخاب کنید»

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

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

الزامات فنی:

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

تأثیر بر نابینا-ناشنوا: کاربران نابینا-ناشنوا به طور کامل به صفحه کلید و خط بریل وابسته هستند. عدم پشتیبانی از صفحه کلید به معنای عدم دسترسی کامل است.

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

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

مثال نقض: پنجره مدال (Modal Dialog) که فوکوس را قفل می‌کند و کاربر نمی‌تواند با کلید Escape از آن خارج شود. در چنین حالتی، کاربر نابینا-ناشنوا در آن المان «به دام می‌افتد» و نمی‌تواند به بقیه صفحه دسترسی پیدا کند.

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

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

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

<title>رزرو پرواز تهران-مشهد - مرحله ۲ از ۳: اطلاعات مسافرین</title>

تأثیر بر نابینا-ناشنوا: عنوان صفحه اولین چیزی است که صفحه‌خوان خط بریل هنگام بارگذاری صفحه نمایش می‌دهد. این عنوان به کاربر می‌گوید در کدام مرحله از فرآیند رزرو قرار دارد.

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

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

الزامات فنی:

• برچسب‌ها باید واضح و توصیفی باشند
• فیلدهای اجباری با ستاره (*) مشخص شوند و توضیح معنی آن در ابتدای فرم درج شود
• فرمت مورد انتظار داده به عنوان مثال نمایش داده شود

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

<p>فیلدهای دارای <span aria-label="الزامی">*</span> اجباری هستند.</p>

<label for="phone">شماره تلفن همراه <span aria-label="الزامی">*</span></label>
<input type="tel" id="phone" name="phone" placeholder="مثال: 09121234567">
<span class="hint">شماره ۱۱ رقمی بدون فاصله وارد شود</span>

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

هدف: خطاها به صورت متنی شناسایی شوند و فیلد خطادار مشخص گردد.

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

<div class="error-summary" role="alert">
  <p>۲ خطا در فرم وجود دارد:</p>
  <ul>
    <li><a href="#phone">شماره تلفن همراه: باید ۱۱ رقم باشد</a></li>
    <li><a href="#email">ایمیل: فرمت نامعتبر است</a></li>
  </ul>
</div>

<label for="phone">شماره تلفن همراه</label>
<input type="tel" id="phone" aria-invalid="true" aria-describedby="phone-error">
<span id="phone-error" class="error">شماره تلفن باید ۱۱ رقم باشد</span>

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

هدف: پیشنهادهایی برای رفع خطا ارائه شود.

کاربرد: به جای «تاریخ نامعتبر» → «تاریخ تحویل باید بعد از تاریخ ۱۴۰۳/۰۱/۰۱ باشد».

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

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

کاربرد: صفحه «خلاصه رزرو» قبل از پرداخت، با امکان ویرایش هر بخش.

۱.۱۳ قابل تجزیه بودن کد (۴.۱.۱ – سطح A)

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

الزامات فنی:

• تگ‌ها به درستی باز و بسته شوند
• از تو رفتگی‌های نامعتبر خودداری شود
• از duplicate attributes پرهیز شود

بخش دوم: شاخص‌های برگرفته از نیازهای ناشنوایان

این شاخص‌ها تضمین می‌کنند که محتوای شنیداری برای افرادی که نمی‌توانند بشنوند، قابل درک باشد.

۲.۱ زیرنویس برای ویدیوهای ضبط‌شده (۱.۲.۲ – سطح A)

هدف: تمام ویدیوهای ضبط‌شده باید دارای زیرنویس هماهنگ (Synchronized Captions) باشند.

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

• اگر فرم رزرو دارای ویدیوی راهنمای استفاده است، زیرنویس ارائه شود
• ویدیوهای تبلیغاتی مقاصد گردشگری نیز باید زیرنویس داشته باشند

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

هدف: برای ویدیوها، رونوشت متن (Transcript) ارائه شود – یعنی تمام گفتارها و توصیف‌های صوتی مهم به صورت متن جداگانه.

تأثیر بر نابینا-ناشنوا: افرادی که از خط بریل استفاده می‌کنند، رونوشت متن را ترجیح می‌دهند زیرا می‌توانند با سرعت خود آن را بخوانند، در حالی که زیرنویس‌ها به صورت خودکار و با سرعت ویدیو پیش می‌روند.

۲.۳ کنترل صدا (۱.۴.۲ – سطح A)

هدف: اگر صفحه دارای صدای خودکاری است که بیش از ۳ ثانیه پخش می‌شود، کاربر باید قابلیت توقف یا mute کردن آن را داشته باشد.

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

• هیچ صدای پس‌زمینه خودکاری پخش نشود
• اگر اعلان صوتی (مانند «رزرو شما با موفقیت ثبت شد») وجود دارد، متن معادل آن نیز روی صفحه نمایش داده شود
• دکمه کنترل صدا (Play/Pause/Mute) به وضوح در دسترس باشد

بخش سوم: ترکیب و اولویت‌بندی شاخص‌ها برای نابینا-ناشنوایان

برای یک فرم رزرو دسترس‌پذیر برای افراد نابینا-ناشنوا، شاخص‌های زیر بالاترین اولویت را دارند (مرتب‌سازی شده بر اساس اهمیت):

رتبه	شاخص موفقیت	سطح	دلیل اهمیت برای نابینا-ناشنوا
۱	متن جایگزین (۱.۱.۱)	A	بدون متن جایگزین، تصاویر و آیکون‌ها کاملاً از دست می‌روند
۲	نام، نقش، مقدار (۴.۱.۲)	A	بدون آن، کاربر نمی‌داند با چه نوع فیلدی مواجه است
۳	قابلیت صفحه کلید (۲.۱.۱)	A	تنها روش تعامل ممکن
۴	برچسب‌ها (۳.۳.۲)	A	بدون برچسب، هدف فیلد نامشخص است
۵	ساختار و روابط (۱.۳.۱)	A	درک گروه‌بندی فیلدهای مرتبط
۶	شناسایی خطا (۳.۳.۱)	A	اطلاع از وجود خطا و محل آن
۷	عدم استفاده صرف از ویژگی‌های حسی (۱.۳.۳)	A	جلوگیری از ارجاع به «صدا» یا «مکان بصری»
۸	عنوان صفحه (۲.۴.۲)	A	درک موقعیت در فرآیند چندمرحله‌ای
۹	پیشنهاد اصلاح خطا (۳.۳.۳)	AA	کمک به رفع خطا بدون نیاز به آزمون و خطا
۱۰	پیشگیری از خطا (۳.۳.۴)	AA	جلوگیری از ثبت اشتباه رزرو با عواقب مالی
۱۱	زیرنویس (۱.۲.۲)	A	دسترسی به محتوای ویدیوهای راهنما
۱۲	کنترل صدا (۱.۴.۲)	A	جلوگیری از پخش صدای ناخواسته

نتیجه‌گیری و توصیه‌های نهایی

اگرچه WCAG 2.0 شاخص موفقیت مستقیم و جداگانه‌ای برای افراد نابینا-ناشنوا ندارد، اما ترکیب شاخص‌های طراحی‌شده برای نابینایان و ناشنوایان می‌تواند نیازهای این گروه را به طور کامل پوشش دهد. سه اصل کلیدی برای دسترس‌پذیری فرم‌های رزرو برای نابینا-ناشنوایان عبارتند از:

۱. اطمینان از وجود متن جایگزین برای همه محتواها

• همه تصاویر، آیکون‌ها، و المان‌های گرافیکی دارای alt توصیفی
• همه ویدیوها دارای زیرنویس و رونوشت متن
• همه صداها دارای معادل متنی روی صفحه

۲. عدم اتکا به هیچ کانال حسی واحد

• نه فقط به بینایی (چون کاربر نابینا است)
• نه فقط به شنوایی (چون کاربر ناشنوا است)
• ارجاعات دستورالعملی به «مکان بصری»، «رنگ»، «شکل» یا «صدا» ممنوع است

۳. قابلیت استفاده کامل با صفحه کلید و فناوری‌های کمکی

• پیمایش کامل با Tab
• نشانگر فوکوس مرئی (برای کاربران با باقی‌مانده بینایی)
• اتصال برنامه‌نویسی صحیح برچسب‌ها به فیلدها
• ساختار معنایی مناسب با <fieldset>، <legend>، و هدینگ‌ها

رعایت این اصول نه تنها به افراد نابینا-ناشنوا کمک می‌کند، بلکه تجربه کاربری همه افراد را بهبود می‌بخشد و فرم‌های رزرو را برای طیف گسترده‌تری از کاربران – از جمله سالمندان، افراد با اختلالات شناختی، و کاربران در محیط‌های پر سر و صدا یا کم‌نور – قابل استفاده می‌سازد.

منابع

• W3C, Web Content Accessibility Guidelines 2.0 (W3C Recommendation, 2008)
• MDN Web Docs, Perceivable Principle – WCAG 2.0/2.1
• W3C WAI, Forms Concepts (Draft)
• U.S. Access Board, Section 508 ICT Testing Baseline – Forms
• WebAIM, WCAG 2.0 Checklist