تست دسترسی خودکار

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

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

هر تست، چه خودکار، چه دستی و چه با فناوری کمکی، برای دستیابی به در دسترس‌ترین محصول ممکن بسیار مهم است. تست‌های ما به استانداردهای سطح A و AA دستورالعمل‌های دسترسی به محتوای وب (WCAG) 2.1 متکی هستند.

به یاد داشته باشید که صنعت، نوع محصول، قوانین و سیاست‌های محلی و کشوری یا اهداف کلی دسترسی‌پذیری شما، دستورالعمل‌های لازم و سطوح مورد نیاز را تعیین می‌کنند. اگر برای پروژه خود به استاندارد خاصی نیاز ندارید، توصیه می‌شود از آخرین نسخه WCAG پیروی کنید. برای اطلاعات کلی در مورد ممیزی‌های دسترسی‌پذیری، انواع/سطوح انطباق، WCAG و POUR به « دسترسی‌پذیری دیجیتال چگونه اندازه‌گیری می‌شود؟ » مراجعه کنید.

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

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

اصول اولیه تست خودکار

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

مزایای تست‌های دسترسی خودکار:

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

معایب تست‌های دسترسی خودکار:

• ابزارهای خودکار همه خطاهای دسترسی‌پذیری در محصول شما را تشخیص نمی‌دهند
• گزارش‌های مثبت کاذب (مشکل گزارش شده‌ای که نقض واقعی WCAG نیست)
• ممکن است برای انواع و نقش‌های مختلف محصول، ابزارهای متعددی مورد نیاز باشد

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

انواع ابزارهای خودکار

یکی از اولین ابزارهای تست دسترسی خودکار آنلاین در سال ۱۹۹۶ توسط مرکز فناوری ویژه کاربردی (CAST) با نام « گزارش بابی » توسعه داده شد. امروزه بیش از ۱۰۰ ابزار تست خودکار برای انتخاب وجود دارد!

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

اینکه کدام ابزار خودکار را انتخاب کنید می‌تواند به عوامل زیادی بستگی داشته باشد، از جمله:

• با کدام استانداردها و سطوح انطباق، تست را انجام می‌دهید؟ این موارد ممکن است شامل WCAG 2.2، WCAG 2.1، بخش ۵۰۸ ایالات متحده یا فهرست اصلاح‌شده‌ای از قوانین دسترسی باشد.
• چه نوع محصول دیجیتالی را آزمایش می‌کنید؟ این می‌تواند یک وب‌سایت، اپلیکیشن وب، اپلیکیشن موبایل، PDF، کیوسک یا محصول دیگری باشد.
• در کدام بخش از چرخه عمر توسعه نرم‌افزار، محصول خود را آزمایش می‌کنید؟
• راه‌اندازی و استفاده از این ابزار چقدر طول می‌کشد؟ برای یک فرد، تیم یا شرکت؟
• چه کسی این آزمایش را انجام می‌دهد: طراحان، توسعه‌دهندگان، تضمین کیفیت یا شخص دیگری؟
• چند وقت یکبار می‌خواهید دسترسی‌پذیری بررسی شود؟ چه جزئیاتی باید در گزارش گنجانده شود؟ آیا باید مشکلات مستقیماً به سیستم تیکتینگ مرتبط شوند؟
• کدام ابزارها در محیط شما و برای تیمتان بهترین عملکرد را دارند؟

عوامل بسیار دیگری نیز باید در نظر گرفته شوند. برای اطلاعات بیشتر در مورد نحوه انتخاب بهترین ابزار برای خود و تیمتان، مقاله WAI با عنوان « انتخاب ابزارهای ارزیابی دسترسی‌پذیری وب » را بررسی کنید.

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

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

نسخه آزمایشی ما وب‌سایتی است که برای یک سازمان ساختگی به نام باشگاه اسرار پزشکی ساخته شده است. این سایت عمداً برای نسخه آزمایشی غیرقابل دسترس شده است. بخشی از این عدم دسترسی ممکن است برای شما قابل مشاهده باشد و بخشی (اما نه همه) در آزمایش خودکار ما مشخص خواهد شد.

مرحله ۱

با استفاده از مرورگر کروم خود، افزونه Lighthouse را نصب کنید.

روش‌های زیادی برای ادغام Lighthouse در گردش کار تست شما وجود دارد. ما برای این نسخه آزمایشی از افزونه Chrome استفاده می‌کنیم.

مرحله ۲

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

درباره حالت اشکال‌زدایی CodePen بیشتر بدانید.

مرحله ۳

Chrome DevTools را باز کنید و به تب Lighthouse بروید. همه گزینه‌های دسته‌بندی به جز «Accessibility» را پاک کنید. حالت را به صورت پیش‌فرض نگه دارید و نوع دستگاهی را که می‌خواهید آزمایش‌ها را روی آن اجرا کنید، انتخاب کنید.

مرحله ۴

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

پس از اتمام آزمایش‌ها، Lighthouse امتیازی را نشان می‌دهد که میزان دسترسی‌پذیری محصولی که آزمایش می‌کنید را اندازه‌گیری می‌کند. امتیاز Lighthouse بر اساس تعداد مشکلات، انواع مشکلات و تأثیر مشکلات شناسایی‌شده بر کاربران محاسبه می‌شود.

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

مرحله ۵

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

شماره ۱: نقش‌های ARIA

اولین مشکل بیان می‌کند: «عناصری با [role] ARIA که به فرزندانی نیاز دارند که شامل یک [role] خاص باشند، برخی یا همه آن فرزندان مورد نیاز را ندارند. برخی از نقش‌های والد ARIA باید شامل نقش‌های فرزند خاصی باشند تا عملکردهای دسترسی مورد نظر خود را انجام دهند.» درباره قوانین نقش ARIA بیشتر بدانید.

در نسخه آزمایشی ما، دکمه اشتراک خبرنامه با خطا مواجه می‌شود:

<button role="list" type="submit" tabindex="1">Subscribe</button>

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

دکمه‌ی «اشتراک» در کنار فیلد ورودی، نقش ARIA نادرستی دارد. در این صورت، می‌توان نقش را به طور کامل حذف کرد.

<button type="submit" tabindex="1">Subscribe</button>

شماره ۲: ARIA پنهان

عناصر "[aria-hidden="true"] حاوی فرزندان قابل فوکوس هستند. فرزندان قابل فوکوس درون یک عنصر [aria-hidden="true"] مانع از دسترسی کاربران فناوری‌های کمکی مانند صفحه‌خوان‌ها به آن عناصر تعاملی می‌شوند. درباره قوانین aria-hidden بیشتر بدانید .

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

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

فیلد ورودی دارای ویژگی aria-hidden="true" بود. اضافه کردن این ویژگی، عنصر (و هر چیزی که در زیر آن قرار دارد) را از دید فناوری کمکی پنهان می‌کند.

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

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

مشکل ۳: نام دکمه

دکمه‌ها نام قابل دسترسی ندارند. وقتی یک دکمه نام قابل دسترسی نداشته باشد، صفحه‌خوان‌ها آن را به عنوان «دکمه» اعلام می‌کنند و آن را برای کاربرانی که به صفحه‌خوان‌ها متکی هستند، غیرقابل استفاده می‌کنند.

درباره قوانین نام دکمه بیشتر بدانید .

<button role="list" type="submit" tabindex="1">Subscribe</button>

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

وقتی نقش نادرست ARIA را از عنصر دکمه در شماره ۱ حذف می‌کنید، کلمه "Subscribe" به نام قابل دسترسی دکمه تبدیل می‌شود. این قابلیت در عنصر دکمه HTML معنایی تعبیه شده است. گزینه‌های الگوی اضافی برای موقعیت‌های پیچیده‌تر وجود دارد که باید در نظر گرفته شوند.

<button type="submit" tabindex="1">Subscribe</button>

مشکل ۴: ویژگی‌های جایگزین تصویر

عناصر تصویر فاقد ویژگی [alt] هستند. عناصر آموزنده باید متن جایگزین کوتاه و توصیفی داشته باشند. عناصر تزئینی را می‌توان با ویژگی alt خالی نادیده گرفت. درباره قوانین متن جایگزین تصویر بیشتر بدانید .

<a href="index.html">
  <img src="https://upload.wikimedia.org/wikipedia/commons/….png">
</a>

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

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

<a href="index.html">
  <img src="https://upload.wikimedia.org/wikipedia/commons/….png"
    alt="Go to the home page.">
</a>

مشکل ۵: متن پیوند

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

<a href="#!"><svg><path>...</path></svg></a>

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

تمام تصاویر قابل استفاده در صفحه باید شامل اطلاعاتی در مورد اینکه لینک کاربران را به کجا هدایت می‌کند، باشند. یک روش برای رفع این مشکل، اضافه کردن متن جایگزین به تصویر در مورد هدف آن است، همانطور که در تصویر لوگو در مثال انجام دادید. این روش برای تصویری که از تگ <img> استفاده می‌کند، عالی عمل می‌کند، اما تگ‌های <svg> نمی‌توانند از این روش استفاده کنند.

برای آیکون‌های رسانه‌های اجتماعی که از تگ‌های <svg> استفاده می‌کنند، می‌توانید از الگوی توصیف جایگزین متفاوتی که SVGها را هدف قرار می‌دهد استفاده کنید، اطلاعات را بین تگ‌های <a> و <svg> اضافه کنید و سپس آن را از نظر بصری از دید کاربران پنهان کنید، یک ARIA پشتیبانی‌شده اضافه کنید یا گزینه‌های دیگری را انتخاب کنید. بسته به محیط و محدودیت‌های کد شما، ممکن است یک روش بر روش دیگر ارجحیت داشته باشد.

از ساده‌ترین گزینه الگو با بیشترین پوشش فناوری کمکی استفاده کنید، که شامل اضافه کردن role="img" به برچسب <svg> و گنجاندن یک عنصر <title> است.

<a href="#!">
  <svg role="img">
    <title>Connect on our Twitter page.</title>
    <path>...</path>
  </svg>
</a>

مسئله ۶: کنتراست رنگ

رنگ‌های پس‌زمینه و پیش‌زمینه نسبت کنتراست کافی ندارند. خواندن متن با کنتراست پایین برای بسیاری از کاربران دشوار یا غیرممکن است. درباره قوانین کنتراست رنگ بیشتر بدانید .

دو نمونه گزارش شد.

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

مشکلات کنتراست رنگ زیادی در صفحه وب شناسایی شده است. همانطور که در ماژول رنگ و کنتراست یاد گرفتید، متن با اندازه معمولی (کمتر از 18pt / 24px) نیاز به کنتراست رنگ 4.5:1 دارد، در حالی که متن با اندازه بزرگ (حداقل 18pt / 24px یا 14pt / 18.5px پررنگ) و آیکون‌های ضروری باید الزام 3:1 را برآورده کنند.

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

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

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

مشکل ۷: ساختار لیست

آیتم‌های لیست ( <li> ) درون عناصر والد <ul> یا <ol> قرار نمی‌گیرند. صفحه‌خوان‌ها برای اینکه آیتم‌های لیست ( <li> ) به درستی نمایش داده شوند، نیاز دارند که درون عناصر والد <ul> یا <ol> قرار بگیرند.

درباره قوانین فهرست بیشتر بدانید .

<div class="ul">
  <li><a href="#">About</a></li>
  <li><a href="#">Community</a></li>
  <li><a href="#">Donate</a></li>
  <li><a href="#">Q&A</a></li>
  <li><a href="#">Subscribe</a></li>
</div>

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

ما در این نسخه آزمایشی به جای استفاده از تگ <ul> از یک کلاس CSS برای شبیه‌سازی لیست نامرتب استفاده کردیم. وقتی این کد را به طور نادرست نوشتیم، ویژگی‌های معنایی ذاتی HTML که در این تگ وجود داشت را حذف کردیم. با جایگزینی کلاس با یک تگ <ul> واقعی و اصلاح CSS مرتبط، این مشکل دسترسی‌پذیری را حل می‌کنیم.

<ul>
  <li><a href="#">About</a></li>
  <li><a href="#">Community</a></li>
  <li><a href="#">Donate</a></li>
  <li><a href="#">Q&A</a></li>
  <li><a href="#">Subscribe</a></li>
</ul>

شماره ۸: tabindex

برخی از عناصر مقدار tabindex بزرگتر از ۰ دارند. مقداری بزرگتر از ۰ به معنای ترتیب ناوبری صریح است. اگرچه از نظر فنی معتبر است، اما اغلب برای کاربرانی که به فناوری‌های کمکی متکی هستند، تجربیات ناامیدکننده‌ای ایجاد می‌کند. درباره قوانین tabindex بیشتر بدانید .

<button type="submit" tabindex="1">Subscribe</button>

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

مگر اینکه دلیل خاصی برای بهم زدن ترتیب طبیعی تب‌ها در یک صفحه وب وجود داشته باشد، نیازی به داشتن یک عدد صحیح مثبت برای ویژگی tabindex نیست. برای حفظ ترتیب طبیعی تب‌ها، می‌توانیم tabindex را به 0 تغییر دهیم یا این ویژگی را به طور کلی حذف کنیم.

<button type="submit">Subscribe</button>

مرحله ۶

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

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

مرحله بعدی

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