تست دسترسی دستی

اصول اولیه تست دستی

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

با پیشرفت فناوری، آزمایش‌های بیشتری می‌توانند صرفاً توسط ابزارهای خودکار پوشش داده شوند ، اما امروزه، برای پوشش تمام نقاط بررسی WCAG مربوطه، باید هم بررسی‌های دستی و هم بررسی‌های فناوری کمکی به پروتکل‌های آزمایش شما اضافه شوند.

مزایای تست‌های دسترسی‌پذیری دستی:

• نسبتاً ساده و سریع برای اجرا
• درصد بالاتری از مشکلات را نسبت به تست‌های خودکار به تنهایی شناسایی می‌کند
• ابزار و تخصص کمی برای موفقیت لازم است

معایب تست‌های دسترسی‌پذیری دستی:

• پیچیده‌تر و زمان‌برتر از تست‌های خودکار
• تکرار آن در مقیاس بزرگ ممکن است دشوار باشد
• برای اجرای آزمایش‌ها و تفسیر نتایج، به تخصص بیشتری در زمینه دسترسی‌پذیری نیاز است

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

انواع تست‌های دستی

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

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

بررسی‌های صفحه‌کلید

تخمین زده می‌شود که حدود ۲۵٪ از کل مشکلات دسترسی دیجیتال مربوط به عدم پشتیبانی از صفحه کلید است. همانطور که در ماژول فوکوس صفحه کلید آموختیم، این موضوع بر همه نوع کاربر، از جمله کاربران بینا که فقط از صفحه کلید استفاده می‌کنند، کاربران کم بینا/نابینا در صفحه خوان و افرادی که از نرم‌افزار تشخیص صدا استفاده می‌کنند که از فناوری مبتنی بر دسترسی به محتوا از طریق صفحه کلید نیز استفاده می‌کند، تأثیر می‌گذارد.

تست‌های کیبورد به سوالاتی مانند موارد زیر پاسخ می‌دهند:

• آیا صفحه وب یا ویژگی مورد نظر برای عملکرد به ماوس نیاز دارد؟
• آیا ترتیب تب‌بندی منطقی و قابل فهم است؟
• آیا نشانگر فوکوس کیبورد همیشه قابل مشاهده است؟
• آیا ممکن است در عنصری گیر کنید که نباید فوکوس را به دام بیندازد؟
• آیا می‌توانید پشت یا اطراف عنصری که باید فوکوس را به دام بیندازد، حرکت کنید؟
• هنگام بستن عنصری که فوکوس روی آن اعمال شده بود، آیا نشانگر فوکوس به جای منطقی خود بازگشت؟

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

بررسی‌های بصری

بررسی‌های بصری بر عناصر بصری صفحه تمرکز دارند و از ابزارهایی مانند بزرگنمایی صفحه یا بزرگنمایی مرورگر برای بررسی وب‌سایت یا برنامه از نظر دسترسی‌پذیری استفاده می‌کنند.

بررسی‌های بصری می‌توانند به شما بگویند:

• آیا مشکلاتی در کنتراست رنگ وجود دارد که یک ابزار خودکار نتوانسته آن را تشخیص دهد، مانند متن روی یک گرادیان یا تصویر؟
• آیا عناصری وجود دارند که شبیه سرتیترها، فهرست‌ها و سایر عناصر ساختاری باشند اما به این صورت کدگذاری نشده باشند؟
• آیا لینک‌های ناوبری و ورودی‌های فرم در سراسر وب‌سایت یا برنامه سازگار هستند؟
• آیا چشمک زدن، استروبینگ یا انیمیشنی وجود دارد که از حد توصیه شده تجاوز کند؟
• آیا محتوا فاصله‌گذاری مناسبی برای حروف، کلمات، خطوط و پاراگراف‌ها دارد؟
• آیا می‌توانید تمام محتوا را با استفاده از ذره‌بین صفحه یا بزرگنمایی مرورگر ببینید؟

بررسی محتوا

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

بررسی محتوا به سوالاتی مانند موارد زیر پاسخ می‌دهد:

• آیا عناوین صفحات، سرتیترها و برچسب‌های فرم واضح و توصیفی هستند؟
• آیا جایگزین‌های تصویر مختصر، دقیق و مفید هستند؟
• آیا رنگ به تنهایی به عنوان تنها راه انتقال معنا یا اطلاعات استفاده می‌شود؟
• آیا لینک‌ها توصیفی هستند یا از متن‌های عمومی مانند «بیشتر بخوانید» یا «اینجا کلیک کنید» استفاده می‌کنید؟
• آیا تغییراتی در زبان درون یک صفحه ایجاد می‌شود؟
• آیا از زبان ساده استفاده شده و آیا همه کلمات اختصاری در اولین ارجاع به طور کامل بیان شده‌اند؟

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

نسخه آزمایشی: تست دستی

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

مرحله ۱

نسخه آزمایشی CodePen به‌روزرسانی‌شده ما، تمام به‌روزرسانی‌های خودکار دسترسی‌پذیری را اعمال کرده است.

برای ادامه آزمایش‌های بعدی، آن را در حالت اشکال‌زدایی (debug mode) مشاهده کنید. این مهم است، زیرا <iframe> که صفحه وب آزمایشی را احاطه کرده است و ممکن است با برخی از ابزارهای آزمایش تداخل داشته باشد را حذف می‌کند. درباره حالت اشکال‌زدایی CodePen بیشتر بدانید.

مرحله ۲

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

مشکل ۱: نشانگر فوکوس قابل مشاهده

شما باید اولین مشکل صفحه‌کلید را فوراً ببینید - یا بهتر است بگوییم، نباید آن را ببینید - زیرا نشانگر فوکوس قابل مشاهده حذف شده است. وقتی CSS را در نسخه آزمایشی بررسی می‌کنید، باید عبارت "outline: none" که به کدبیس اضافه شده است را پیدا کنید.

  :focus {
    outline: none;
  }

بیایید آن را درست کنیم.

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

:focus {
  outline: 3px dotted #008576;
}

مشکل ۲: ترتیب فوکوس

وقتی نشانگر فوکوس را تغییر دادید و قابل مشاهده شد، حتماً با حرکت دادن کلید Tab در صفحه، آن را مرور کنید. هنگام انجام این کار، باید متوجه شوید که فیلد ورودی فرم که برای عضویت در خبرنامه استفاده می‌شود، فوکوس دریافت نمی‌کند. این فیلد به دلیل وجود یک tabindex منفی، از ترتیب فوکوس طبیعی حذف شده است.

<input type="email" placeholder="Enter your e-mail address" aria-hidden="true" tabindex="-1" required>

بیایید آن را درست کنیم.

از آنجایی که می‌خواهیم افراد از این فیلد برای ثبت نام در خبرنامه ما استفاده کنند، تنها کاری که باید انجام دهیم این است که tabindex منفی را حذف کنیم یا آن را روی صفر تنظیم کنیم تا ورودی دوباره قابل تنظیم با کیبورد شود.

<input type="email" placeholder="Enter your e-mail address" aria-hidden="true" required>

مرحله ۳

پس از بررسی فوکوس کیبورد، به بررسی‌های بصری و محتوایی می‌پردازیم.

مشکل ۳: کنتراست رنگ لینک

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

برای اینکه صفحه ما قابل دسترس باشد، لینک‌ها باید از متن اطراف متمایز باشند و با حرکت موس و فوکوس کیبورد، تغییر سبک غیر رنگی داشته باشند.

بیایید آن را درست کنیم.

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

اگر تصمیم دارید زیرخط اضافه نکنید، باید رنگ‌ها را به گونه‌ای تغییر دهید که الزامات مربوط به پس‌زمینه و متن را برآورده کند.

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

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

مشکل ۴: کنتراست رنگ آیکون‌ها

یکی دیگر از مشکلات کنتراست رنگ که به آن توجه نشده، آیکون‌های رسانه‌های اجتماعی است. در ماژول رنگ و کنتراست ، یاد گرفتید که آیکون‌های ضروری باید کنتراست رنگی ۳:۱ نسبت به پس‌زمینه داشته باشند. با این حال، در نسخه آزمایشی، آیکون‌های رسانه‌های اجتماعی نسبت کنتراست ۱.۳:۱ دارند.

بیایید آن را درست کنیم.

برای برآورده کردن الزامات کنتراست رنگ ۳:۱، آیکون‌های رسانه‌های اجتماعی به خاکستری تیره‌تر تغییر یافته‌اند.

مشکل ۵: طرح‌بندی محتوا

اگر به طرح‌بندی محتوای پاراگراف نگاه کنید، متن کاملاً تراز شده است. همانطور که در ماژول تایپوگرافی آموختید، این باعث ایجاد "رودخانه‌هایی از فضا" می‌شود که ممکن است خواندن متن را برای برخی از کاربران دشوار کند.

p.bullet {
   text-align: justify;
}

بیایید آن را درست کنیم.

برای تنظیم مجدد تراز متن در نسخه آزمایشی، می‌توانید کد را به text-align: left; به‌روزرسانی کنید یا آن خط را به طور کامل از CSS حذف کنید، زیرا ترازبندی پیش‌فرض برای مرورگرها left است. حتماً کد را آزمایش کنید، در صورتی که سایر سبک‌های به ارث برده شده، ترازبندی پیش‌فرض متن را حذف کنند.

p.bullet {
   text-align: left;
}

مرحله ۴

پس از شناسایی و رفع تمام مشکلات دسترسی دستی که در مراحل قبلی ذکر شد، صفحه شما باید شبیه به تصویر صفحه ما باشد.

ممکن است در بررسی‌های دستی خود با مشکلات دسترسی بیشتری نسبت به آنچه در این ماژول پوشش دادیم، مواجه شوید. بسیاری از این مشکلات را در ماژول بعدی کشف خواهیم کرد.

مرحله بعدی

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

حالا، به آخرین ماژول تست که بر تست فناوری‌های کمکی تمرکز دارد، بروید.