تست راهکارهای ARIA
اشتباه در استفاده از ARIA بسیار رایج است، چون اکثر توسعهدهندگان استفاده از ویژگیها را سادهتر از تست کردن آنها میدانند. نباید آنقدر به تیم QA وابسته بود که انتظار داشته باشیم آنها موارد خاص ARIA را بررسی کنند (حتی اگر تیم QA داشته باشید)، چون چرخه بازخورد در این حالت بسیار غیرضروری و طولانی خواهد شد. به همین دلایل، تست کردن راهکارهای خودتان در مراحل اولیه و بهصورت مکرر ضروری است.
در ادامه چند نکته برای تست یک راهکار ARIA (پس از اینکه تمام گزینههای پیشفرض HTML را امتحان کردهاید):
- آمار سایت خود را با نتایج نظرسنجی WebAIM درباره screen readerها مقایسه کنید تا بدانید کاربران از چه ترکیبهایی از screen reader و مرورگر استفاده میکنند. این کار به اولویتبندی شما کمک میکند.
همچنین میتوانید به منابع زیر مراجعه کنید:
- بررسی A11ySupport.io برای پشتیبانی از ویژگیهای خاص.
- راهنماهای ARIA Authoring Practices ممکن است پیشنهادهایی داشته باشند، اگرچه معمولاً برای استفاده در محیط production آماده نیستند.
- بررسی issue trackerهای ریپوی پروژههای مهم مانند: NVDA، WAI-ARIA، WCAG، WebKit و Safari، و دیگر موارد.
- همچنین میتوانید آرشیو گفتوگوهای لیست ایمیل WebAIM را بررسی کنید یا در صورت نیاز، پرسش جدیدی مطرح نمایید.
به یاد داشته باشید: screen reader تنها بخشی از accessibility است
توسعهدهندگان معمولاً سعی میکنند مسائل را با استفاده از ویژگیها و نشانهگذاریها حل کنند — که تأثیر آن عمدتاً متوجه کاربران screen reader است. اما فراموش نکنید که screen reader تنها یکی از بخشهای accessibility است. باید به پشتیبانی از کیبورد، کنتراست بصری، reflow و zoom، و حتی ناوبری صوتی (که وابسته به HTML معنایی است) نیز توجه داشته باشید.
لینکهای پرش (skip links) نمونه خوبی هستند:
«چرا لینکهای پرش باید قابل مشاهده باشند وقتی فقط برای کاربران screen reader هستند؟»
در واقع، skip links برای همه کاربران کیبورد هستند. بسیاری از افراد باید آنها را ببینند، و همچنین باید در screen reader هم قابل استفاده باشند.
بخشهای مختلفی از accessibility وجود دارد که باید همزمان با سایر دغدغههای توسعه وب به آنها رسیدگی کرد. بنابراین هنگام اولویتبندی وظایف با اندازهها و پیچیدگیهای متفاوت، گروههای متنوع کاربران و تأثیر مسائل بر accessibility را مد نظر داشته باشید.