ممکن است axe و Lighthouse روی صفحه پرداخت هیچ خطایی گزارش نکنند، اما کاربر صفحهخوان بعد از فشردن «پرداخت» نداند خطای رمز پویا کجا ظاهر شده است. ممکن است همه فیلدها برچسب داشته باشند، اما ترتیب خواندن مبلغ، تخفیف و هزینه ارسال در رابط راستبهچپ گمراهکننده باشد. این تناقض نیست؛ هر ابزار فقط بخشی از مسئله را میبیند.
در این راهنما یاد میگیرید برای هر سؤال چه ابزاری انتخاب کنید، تست با NVDA و JAWS را چگونه تکرارپذیر اجرا کنید، فارسی و RTL را چگونه بسنجید و آزمونهای axe را چطور در CI/CD قرار دهید. اگر هنوز معیارها و سطوح A، AA و AAA را مرور نکردهاید، ابتدا راهنمای تست دسترسپذیری و WCAG ۲.۲ را بخوانید؛ این مقاله جای آن راهنمای پایه را نمیگیرد.
خلاصه عملی: انطباق فنی، سازگاری با فناوری کمکی، کاربردپذیری برای افراد دارای معلولیت و جلوگیری از رگرسیون چهار سؤال متفاوتاند. برای پاسخ قابل دفاع، شواهد کد و DOM، اسکن خودکار، تست مستقل صفحهکلید، ماتریس مرورگر و صفحهخوان و ارزیابی با کاربران هدف را کنار هم بگذارید.
ابزار تست دسترسپذیری دقیقاً چه چیزی را اثبات میکند؟
WCAG 2.2 یک استاندارد فنی با معیارهای موفقیت است؛ نه فهرستی از نرمافزارهایی که با اجرای آنها محصول «تأیید» شود. یک نتیجه سبز فقط میگوید قواعد اجراشده در همان صفحه، حالت، مرورگر و نسخه ابزار نقض قابل تشخیصی پیدا نکردهاند. این نتیجه درباره حالتهای بازنشده، فرایند کامل خرید، کیفیت متن جایگزین، تجربه کاربر یا همه ترکیبهای فناوری کمکی ادعایی ندارد.
چهار سؤال را از هم جدا کنید
| سؤال | شاهد مناسب | نتیجهای که نمیتوان گرفت |
|---|---|---|
| آیا صفحه یا فرایند با معیارهای هدف WCAG منطبق است؟ | ارزیابی معیاربهمعیار، دستی و خودکار، روی صفحه کامل و فرایند کامل | سبز بودن یک اسکن خودکار برابر با انطباق نیست |
| آیا محصول با ترکیب مشخص مرورگر، سیستمعامل و AT کار میکند؟ | سناریوی تکرارپذیر روی ترکیب نسخهدار | موفقیت NVDA و Firefox، موفقیت همه صفحهخوانها را ثابت نمیکند |
| آیا کاربران دارای معلولیت میتوانند هدفشان را با اطمینان انجام دهند؟ | پژوهش و آزمون کاربردپذیری با شرکتکنندگان نماینده | تست یک فرد برای همه افراد یا همه معلولیتها قابل تعمیم نیست |
| آیا یک تغییر، خطای شناختهشده را برگردانده است؟ | قواعد خودکار، تست کامپوننت و سناریوی رگرسیون | نبود رگرسیون شناختهشده یعنی نبود همه موانع نیست |
W3C نیز توصیه میکند ارزیابی با کاربران دارای معلولیت را با ارزیابی استانداردمحور ترکیب کنید؛ چون هرکدام مسائل متفاوتی پیدا میکنند. راهنمای رسمی مشارکت کاربران در ارزیابی دسترسپذیری همچنین هشدار میدهد تجربه یک نفر نماینده همه افراد همگروه نیست. پس یک تستر بینا با روشنکردن صفحهخوان، «تجربه فرد نابینا» را شبیهسازی نمیکند؛ او فقط قابلیت همکاری محصول با یک ترکیب فنی را بررسی میکند.
واژگان گزارش را دقیق نگه دارید
- Violation: یک قاعده اجرا شده و نمونهای ناسازگار یافته است.
- Incomplete یا Needs review: ابزار برای داوری قطعی به بررسی انسانی نیاز دارد.
- AT compatibility: یک وظیفه روی ترکیب ثبتشده AT، مرورگر و سیستمعامل انجام شده است.
- Usability finding: مانعی در مشاهده رفتار یک یا چند شرکتکننده دیده شده است.
- Conformance claim: ادعایی بسیار گستردهتر که باید صفحه کامل، حالتها، فناوریهای متکی و فرایندهای کامل را پوشش دهد.
پشته ابزارهای تست دسترسپذیری؛ هر خطا را زودتر بگیرید
یک ابزار «بهترین» برای همه تیمها وجود ندارد. پشته خوب، بازخورد ارزان را نزدیک محل تولید خطا میدهد و بررسیهای گرانتر را برای ریسکهای مهم نگه میدارد. این همان منطق تست پیوسته در DevOps است: یک اسکن بزرگ در پایان، جای کنترلهای کوچک در طول تحویل را نمیگیرد.
- طراحی و محتوا: کنتراست، ترتیب منطقی، متن لینک، پیام خطا، عنوان و زبان را پیش از کدنویسی بازبینی کنید.
- Lint در منبع: خطاهای قطعی JSX/HTML و الگوهای ممنوع تیم را در ویرایشگر بگیرید.
- کامپوننت: حالتهای دکمه، ورودی، منو، تب و دیالوگ را با axe در Storybook یا تست کامپوننت بسنجید.
- مرورگر واقعی: صفحه رندرشده و حالتهای بازشده را با Playwright و axe بررسی کنید.
- بررسی دستی بدون AT: صفحهکلید، فوکوس دیداری، بزرگنمایی، Reflow، کنتراست، حرکت و لمس را مستقل ارزیابی کنید.
- فناوری کمکی: وظایف پرریسک را روی ماتریس نسخهدار صفحهخوان، مرورگر و سیستمعامل اجرا کنید.
- کاربر هدف: موانع کاربردپذیری و راهبردهای واقعی کاربران دارای معلولیت را مشاهده کنید.
- تولید: کانال بازخورد دسترسپذیر، پایش خطا و فرایند پاسخگویی داشته باشید.
این لایهها جای یکدیگر را نمیگیرند. برای مثال، تست خودکار شاید نبود نام دسترسپذیر یک دکمه را پیدا کند؛ تست صفحهکلید مشخص میکند فوکوس در دیالوگ گیر میکند یا نه؛ صفحهخوان نشان میدهد نام، نقش و وضعیت چگونه اعلام میشوند؛ و شرکتکننده هدف ممکن است معلوم کند متن و ترتیب کار هنوز گیجکننده است.
ماتریس صفحهخوان را از سیاست پشتیبانی بسازید
انتخاب NVDA یا JAWS نباید براساس سلیقه تستر یا شهرت ابزار باشد. ابتدا سیستمعاملهای پشتیبانیشده، داده تحلیلی معتبر، پژوهش کاربر، قراردادها و ریسک مسیرهای اصلی را مشخص کنید. سپس کمترین ماتریسی را بسازید که بازار واقعی شما را نمایندگی کند. این تصمیم بخشی از استراتژی تست چندمرورگری است، با این تفاوت که AT نیز یک متغیر نسخهدار به ماتریس اضافه میکند.
| سکو | ترکیبهای نمونه برای بررسی | نکته انتخاب |
|---|---|---|
| Windows | NVDA با Firefox یا Chrome؛ JAWS با Chrome یا Edge | ترکیب نهایی را از سیاست پشتیبانی و کاربران واقعی انتخاب کنید |
| macOS | VoiceOver با Safari | رفتار Safari و VoiceOver را از نتیجه Chromium استنتاج نکنید |
| iOS | VoiceOver با Safari | ژست، صفحهکلید مجازی، چرخانک و تغییر جهت صفحه را پوشش دهید |
| Android | TalkBack با Chrome | سازنده دستگاه، نسخه Android و نسخه TalkBack میتوانند رفتار را تغییر دهند |
راهنمای رسمی گوگل برای مرور وب با TalkBack در Chrome ناوبری با Heading، Link و Control را توضیح میدهد، اما همین مستند هم جای سناریوی محصول شما را نمیگیرد. در گزارش هر اجرا، نسخه AT، مرورگر، سیستمعامل، دستگاه، موتور یا صدای گفتار، زبان، Viewport و تنظیمات اثرگذار را ثبت کنید.
ماتریس حداقلی با ماتریس کامل فرق دارد
برای هر Pull Request لازم نیست همه ترکیبها دستی اجرا شوند. یک الگوی معقول چنین است:
- در هر تغییر: lint، تست کامپوننت و اسکن خودکار حالتهای مرتبط؛
- برای تغییر کامپوننت تعاملی: صفحهکلید و یک ترکیب اصلی AT؛
- پیش از انتشار پرریسک: مسیرهای حیاتی روی همه ترکیبهای پشتیبانیشده؛
- بهصورت دورهای: نمونه نماینده صفحات و فرایندها بهعلاوه نمونه تصادفی؛
- پس از تغییر نسخه بزرگ مرورگر، AT یا Design System: آزمون سازگاری هدفمند.
روش ارزیابی WCAG-EM بر نمونه نماینده، کارکردهای ضروری و فرایندهای کامل تأکید دارد. بنابراین شمار URL اسکنشده معیار خوبی برای پوشش نیست؛ یک Checkout با شش حالت مهم میتواند از صد صفحه محتوایی تکراری پرریسکتر باشد.
مقایسه NVDA و JAWS برای تست دسترسپذیری
NVDA یک صفحهخوان آزاد و متنباز برای Windows است و نسخه قابلحمل نیز دارد. JAWS صفحهخوان تجاری Windows با مسیرهای پشتیبانی، آموزش و قابلیت اسکریپتنویسی محصول خود است؛ جزئیات کلیدها و راهاندازی در راهنمای رسمی JAWS آمده است. تفاوت مجوز بهتنهایی نمیگوید کدامیک برای محصول شما «بهتر» است.
| معیار | NVDA | JAWS |
|---|---|---|
| مجوز و تهیه | آزاد و متنباز؛ دانلود عمومی | تجاری؛ شرایط مجوز و تهیه باید در زمان خرید بررسی شود |
| سیستمعامل | Windows | Windows |
| نسخه قابلحمل | دارد، با محدودیتهایی که راهنمای نسخه توضیح میدهد | انتخاب تست را بر نصب و مجوز سازمان تنظیم کنید |
| سفارشیسازی | Add-on و تنظیمات گسترده | اسکریپتها و امکانات سازمانی محصول |
| زمان استفاده در QA | وقتی بخشی از جامعه کاربر یا سیاست پشتیبانی است؛ همچنین برای بازخورد سریع Windows | وقتی کاربران، قرارداد یا سیاست پشتیبانی آن را ایجاب میکند |
خرید JAWS فقط برای کاملکردن یک چکلیست منطقی نیست؛ همانطور که حذف آن فقط بهدلیل هزینه منطقی نیست. اگر دادهای از کاربران ندارید، با پشتیبانی مشتری، پژوهش دسترسپذیر و یک دوره مشاهده شروع کنید. تصمیم و تاریخ بازنگری آن را ثبت کنید.
آموزش فرمانها لازم است، اما کافی نیست
تستری که فقط کلید Tab میزند، رفتار واقعی Browse Mode، Focus/Form Mode، ناوبری با Heading، Landmark، Link، Form Field و Table را نمیسنجد. از سوی دیگر، حفظکردن همه فرمانها بدون فهم DOM و Accessibility Tree نیز ریشه خطا را پنهان میکند. تستر باید بداند خروجی شنیدهشده نتیجه همکاری محتوا، مرورگر، API دسترسپذیری، AT و موتور گفتار است.
صفحهخوان فارسی و RTL؛ «پشتیبانی از فارسی» یک پاسخ بله یا خیر نیست
در NVDA ممکن است رابط کاربری فارسی باشد، اما خواندن محتوای فارسی به موتور گفتار و صدای نصبشده هم وابسته است. تلفظ درست نیز با ترتیب DOM، مقدار lang، تغییر زبان میان متن، Unicode و تنظیمات نشانهخوانی ارتباط دارد. نمایش بریل موضوع دیگری است و به جدول ترجمه، نمایشگر و پیکربندی وابسته است. بنابراین در گزارش ننویسید «NVDA فارسی را پشتیبانی میکند»؛ دقیقاً بنویسید چه چیزی را با چه نسخه و تنظیمی آزمودهاید.
چکلیست محتوای فارسی
- زبان اصلی صفحه با
lang="fa"و تغییرهای واقعی زبان در عبارات انگلیسی مشخص شده است؟ - ترتیب DOM با ترتیب بصری RTL یکسان و معنادار است؟ CSS فقط ظاهر را برعکس نکرده است؟
- «ی/ی» و «ک/ک»، نیمفاصله، علائم و فاصلهگذاری باعث تلفظ یا جستوجوی نامنتظر نمیشوند؟
- اعداد فارسی، عربی و لاتین در کد ملی، موبایل، OTP و شماره کارت بهترتیب درست خوانده میشوند؟
- مبلغ، واحد ریال یا تومان و جداکننده هزارگان بدون ابهام اعلام میشود؟
- تاریخ شمسی یا میلادی همراه با نوع تقویم و ترتیب روز، ماه و سال قابل فهم است؟
- متن آمیخته فارسی و انگلیسی، URL، ایمیل، کد تخفیف و نام برند بههم نمیریزد؟
- مخففها، نشانهها و کاراکترهای نامرئی در Speech Viewer و DOM بررسی شدهاند؟
برای هر مورد، «متن مورد انتظار» را از «اعلان واقعی AT» جدا ثبت کنید. اگر مشکل فقط از یک صدای گفتار است، آن را بهاشتباه نقص DOM اعلام نکنید؛ اگر DOM غلط است، تغییر تلفظنامه شخصی را بهعنوان اصلاح محصول نپذیرید.
پروتکل تست با NVDA یا JAWS؛ از آمادهسازی تا شاهد
هدف پروتکل، تبدیل «برای من کار کرد» به اجرای قابل بازتولید است. ابتدا صفحهکلید را بدون صفحهخوان آزمایش کنید؛ روشنبودن AT بعضی فرمانها و حالتهای ورودی را تغییر میدهد و میتواند نقص پایه صفحهکلید را مخفی کند.
۱. پیششرط و دامنه را ثبت کنید
- Build، URL، حساب، داده و Feature Flag؛
- نام و نسخه سیستمعامل، مرورگر و AT؛
- موتور گفتار، صدا، زبان، سرعت و تنظیم نشانهها؛
- Viewport، Zoom، ورودی لمسی یا صفحهکلید و افزونههای فعال؛
- وظیفه کاربر، حالت شروع، خروجی مورد انتظار و معیار توقف.
۲. ساختار و راههای پرش را بررسی کنید
- عنوان صفحه و زبان اصلی را بشنوید.
- با Skip Link و Landmarkها به Main، Navigation و نواحی نامدار بروید.
- فهرست Headingها را باز کنید؛ سطحها باید ساختار را بیان کنند، نه ظاهر را.
- فهرست Linkها و Form Fieldها را مرور کنید؛ نامها خارج از متن اطراف هم معنادار باشند.
- List و Table را با فرمان مخصوص بخوانید؛ Header و رابطه سلولها را بررسی کنید.
۳. نام، نقش، وضعیت و مقدار را بسنجید
برای هر کنترل تعاملی، فقط متن شنیدهشده کافی نیست. نام دسترسپذیر، Role، State و Value را در Accessibility Tree مرورگر نیز ببینید. الگوهای ARIA Authoring Practices Guide برای رفتار صفحهکلید و الگوهای رایجی مانند Dialog، Tabs و Combobox مرجع مفیدی هستند، اما کپیکردن ARIA بدون رفتار و آزمون، دسترسپذیری ایجاد نمیکند.
- دکمه Toggle تغییر
aria-expandedرا اعلام میکند؟ - Tab انتخابشده و رابطه آن با Panel قابل تشخیص است؟
- Combobox تعداد نتیجه، گزینه فعال و حالت باز/بسته را منتقل میکند؟
- ورودی اجباری، قالب، راهنما و خطا را در زمان درست اعلام میکند؟
- Progress، اعلان موفقیت و خطای شبکه بدون جابهجایی اجباری فوکوس قابل دریافتاند؟
۴. فوکوس و تغییر حالت پویا را دنبال کنید
در SPA و رابطهای پویا، یک اسکن اولیه تقریباً همیشه ناکافی است. دیالوگ را باز کنید، خطا بسازید، Accordion را گسترش دهید، فیلتر را اعمال کنید و Route را تغییر دهید. بعد بپرسید:
- فوکوس پس از بازشدن دیالوگ کجاست و پس از بستن به کجا برمیگردد؟
- پس از خطای ارسال فرم، خلاصه خطا یا نخستین فیلد نامعتبر قابل یافتن است؟
- پیام زنده مهم اعلام میشود، بدون اینکه اعلانهای زیاد کار را مختل کنند؟
- پس از تغییر Route، عنوان یا Heading جدید به کاربر منتقل میشود؟
- هیچ Keyboard Trap یا تداخل میان Browse Mode و Focus Mode وجود ندارد؟
۵. وظیفه را از ابتدا تا انتها انجام دهید
تست تککامپوننت لازم است، اما برای ادعای فرایند کافی نیست. یک کار واقعی مانند «محصول را پیدا کن، تخفیف را وارد کن، روش ارسال را تغییر بده، پرداخت ناموفق را اصلاح کن و رسید را بیاب» تعریف کنید. WCAG انطباق را برای صفحه کامل و فرایند کامل در نظر میگیرد؛ موفقیت یک دکمه جداگانه، مسیر خرید را پوشش نمیدهد.
۶. شاهد را طوری ثبت کنید که قابل بازپخش باشد
ضبط صدا مفید است، اما تنها شاهد نیست. متن اعلان واقعی، گامها، عنصر هدف، Accessibility Tree، Screenshot، ویدئو، Log و تفاوت انتظار/مشاهده را ثبت کنید. اطلاعات شخصی و داده پرداخت را از Artifact حذف یا ماسک کنید. برای تفکیک «آیا درست ساختیم؟» از «آیا چیز مناسب را ساختیم؟» میتوانید از چارچوب Verification و Validation استفاده کنید.
مقایسه ابزارهای خودکار؛ axe، Lighthouse، WAVE و Accessibility Insights
| ابزار | بهترین کاربرد | محدودیت مهم |
|---|---|---|
| axe-core | قواعد قابل اتوماسیون در کامپوننت، مرورگر و CI؛ خروجی ماشینخوان | فقط محتوای رندرشده و حالت اجراشده را میسنجد؛ موارد Incomplete بازبینی میخواهند |
| Lighthouse | بازخورد سریع در DevTools و Pipeline همراه با Auditهای دیگر | امتیاز میانگین وزندار Auditهای خودش است، نه درصد انطباق WCAG |
| WAVE | بازبینی دیداری ساختار، ARIA، کنتراست و متن جایگزین در زمینه صفحه | نبود Error به معنای Accessible یا Compliant بودن نیست |
| Accessibility Insights | FastPass، Assessment هدایتشده و مرور Tab Stopها | ارزیابی هدایتشده همچنان به داوری و مهارت انسانی نیاز دارد |
راهنمای رسمی WAVE صریح میگوید ابزار نمیتواند اعلام کند صفحه دسترسپذیر است و بعضی یافتهها باید در زمینه بررسی شوند. بهجای تکرار اعداد عمومی مانند «ابزارها ۳۰ تا ۵۰ درصد خطاها را مییابند»، دامنه واقعی Ruleset خودتان را گزارش کنید: چه قواعدی، روی چه صفحات و حالتهایی، با چه نسخهای اجرا شدهاند و چه مواردی به بررسی دستی ماندهاند.
False positive، False negative و Incomplete
یک Violaton باید بازتولید و اثر آن تحلیل شود؛ Severity ابزار حکم نهایی اولویت کسبوکار نیست. از سوی دیگر، نتیجه Pass فقط درباره همان قاعده و نمونه است. موارد Incomplete را دور نریزید: اغلب همان جاهایی هستند که ابزار نمیتواند معنای متن جایگزین، ترتیب منطقی یا نقش محتوایی را بهتنهایی تشخیص دهد.
اتوماسیون تست دسترسپذیری با Playwright و axe
مستندات رسمی Accessibility Testing در Playwright نیز ترکیب تست خودکار، بررسی دستی و آزمون فراگیر با کاربر را توصیه میکند. نمونه زیر صفحه اولیه، دیالوگ بازشده و حالت خطای فرم را جدا اسکن میکند و خروجی هر حالت را به Artifact پیوست میکند:
import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';
const wcagTags = ['wcag2a', 'wcag2aa', 'wcag21a', 'wcag21aa', 'wcag22aa'];
async function auditState(page, testInfo, stateName) {
const result = await new AxeBuilder({ page })
.withTags(wcagTags)
.analyze();
await testInfo.attach(`axe-${stateName}.json`, {
body: Buffer.from(JSON.stringify({
state: stateName,
url: page.url(),
violations: result.violations,
incomplete: result.incomplete,
}, null, 2)),
contentType: 'application/json',
});
expect(result.violations, `${stateName}: axe violations`).toEqual([]);
}
test('checkout states have no detectable WCAG A/AA violations', async ({ page }, testInfo) => {
await page.goto('/checkout');
await auditState(page, testInfo, 'initial');
await page.getByRole('button', { name: 'افزودن کد تخفیف' }).click();
await expect(page.getByRole('dialog', { name: 'کد تخفیف' })).toBeVisible();
await auditState(page, testInfo, 'discount-dialog-open');
await page.getByRole('button', { name: 'ثبت کد' }).click();
await expect(page.getByText('کد تخفیف را وارد کنید')).toBeVisible();
await auditState(page, testInfo, 'discount-validation-error');
});این تست میتواند رگرسیونهای قابلتشخیص را متوقف کند؛ اما حتی با صفر Violation، انطباق صفحه یا کاربردپذیری Checkout اثبات نشده است. همچنین Assertion بر متن دیداری خطا ثابت نمیکند صفحهخوان آن را در زمان مناسب اعلام کرده است؛ برای آن، بررسی ساختار و اجرای AT لازم است.
چرا حالتها مهمتر از تعداد URL هستند؟
axe محتوای رندرشده را بررسی میکند. منوی بسته، Dialog بازنشده، پیام خطای تولیدنشده یا مرحله بعدی Wizard در اسکن اولیه وجود ندارد. برای هر مسیر حیاتی، «نقشه حالت» بسازید: Initial، Loading، Empty، Populated، Expanded، Error، Success، Timeout و Permission denied. فقط حالتهای مرتبط با کامپوننت را اسکن کنید تا Suite سریع و قابل نگهداری بماند.
تست را در سطح درست قرار دهید
- قاعدهای که در یک کامپوننت Design System قابل پیشگیری است، همانجا تست شود.
- رابطه چند کامپوننت و مدیریت فوکوس در تست مرورگر بررسی شود.
- مسیر حیاتی در تست End-to-End و پروتکل دستی AT پوشش داده شود.
- سازگاری موبایل Native یا Hybrid در Suite مخصوص سکو قرار گیرد؛ برای شروع اتوماسیون موبایل، راهنمای Appium را ببینید.
سیاست CI/CD؛ جلوی خطای جدید را بگیرید، بدهی قدیمی را پنهان نکنید
روشنکردن axe روی محصول قدیمی ممکن است صدها یافته بسازد. دو واکنش نامناسب عبارتاند از خاموشکردن سراسری Rules و شکست دائمی Pipeline بدون مالک اصلاح. یک Baseline کنترلشده بسازید و همزمان سیاست «رگرسیون جدید ممنوع» را اعمال کنید.
هر استثنا باید یک رکورد منقضیشونده باشد
برای هر مورد پذیرفتهشده این فیلدها را ثبت کنید:
- Rule و Selector یا شناسه پایدار کامپوننت؛
- گام بازتولید و حالت رابط؛
- دلیل فنی و اثر بر کاربر؛
- مالک، Ticket اصلاح و تصمیمگیر مجاز؛
- کنترل موقت و ریسک باقیمانده؛
- تاریخ انقضا و Trigger بازبینی.
Rule را برای کل پروژه Disable نکنید چون یک نمونه بحثبرانگیز است. Scope استثنا را حداقلی نگه دارید، Incompleteها را صف بازبینی بدهید و یافتههای Critical/Serious را پیش از Fail خودکار از نظر زمینه و تکرارپذیری کنترل کنید. ACT Rules برای شفافترشدن قواعد خودکار، نیمهخودکار و دستی ایجاد شدهاند؛ بااینحال خروجی پیادهسازی هر ابزار همچنان باید با Rule، نسخه و دامنه ثبت شود.
Artifact حداقلی هر اجرا
- Commit و Build؛ صفحه، فرایند و State؛
- مرورگر، Viewport، Locale و Feature Flag؛
- نام و نسخه ابزار و Ruleset یا Tagها؛
- Violations، Incomplete، Selector و Help URL؛
- Screenshot، Trace یا DOM لازم برای بازتولید؛
- Baseline مقایسهشده و موارد New، Existing، Fixed یا Expired.
تعداد Violation خام را KPI کیفیت نکنید؛ یک Rule تکرارشده روی صد عنصر میتواند یک ریشه مشترک داشته باشد و یک مانع فوکوس در پرداخت میتواند فقط یک مورد باشد. معیارهای بهتر شامل زمان رفع رگرسیون، درصد کامپوننتهای مشترک دارای Contract، پوشش حالتهای پرریسک، استثناهای منقضی و موفقیت وظیفه کاربران هدفاند. اصول طراحی و نگهداری Suite را در راهنمای اتوماسیون تست تکمیل کنید.
قالب شاهد و گزارش نقص دسترسپذیری
یک Ticket خوب باید هم برای توسعهدهنده بازتولیدپذیر باشد و هم اثر کاربر را برای Product روشن کند:
عنوان: فوکوس پس از بستن دیالوگ تخفیف به ابتدای صفحه میرود
وظیفه کاربر: اعمال کد تخفیف در Checkout
محیط: Windows 11 / Chrome 138 / NVDA 2026.1.1 / صدای ... / fa-IR
پیششرط: سبد دارای یک کالا؛ دیالوگ با دکمه «افزودن کد تخفیف» باز است
گامها: لغو را فعال کنید؛ سپس Shift+Tab بزنید
انتظار: فوکوس به دکمه بازکننده برگردد
مشاهده: فوکوس دیداری گم میشود و NVDA عنوان صفحه را اعلام میکند
شاهد: ویدئو، Speech Viewer، Accessibility Tree و DOM پیوست
اثر: کاربر باید دوباره کل صفحه را برای یافتن محل قبلی مرور کند
معیار/الگو: مرجع مرتبط + توضیح ارتباط، نه فقط شماره معیار
شدت پیشنهادی: زیاد برای مسیر Checkout؛ تصمیم نهایی با مالک ریسک
ترکیبهای دیگر: Firefox/NVDA ...؛ Chrome/JAWS ...
کنترل موقت و مالک اصلاح: ...شدت را از روی اثر وظیفه تعیین کنید
| اثر نمونه | برداشت اولیه | پرسشهای تکمیلی |
|---|---|---|
| کاربر نمیتواند پرداخت را کامل کند و مسیر جایگزین هم ندارد | مسدودکننده یا بسیار زیاد | چه کاربران و ترکیبهایی؟ کنترل جایگزین واقعاً همارز است؟ |
| وظیفه ممکن است، اما زمان و خطای کار بهشدت بالا میرود | زیاد | مسیر حیاتی است؟ چند بار در هر نشست تکرار میشود؟ |
| اطلاعات قابل دریافت است، اما ساختار یا اعلان مبهم است | متوسط | آیا تصمیم مالی یا حریم خصوصی را تحت تأثیر میگذارد؟ |
| بهبود تجربه بدون مانع اثباتشده | کم یا پیشنهاد | آیا با معیار یا الگوی Design System تعارض دارد؟ |
Severity ابزار را عیناً به اولویت محصول تبدیل نکنید. شدت به کاربران متأثر، احتمال، تکرار، اهمیت وظیفه، راه جایگزین و هزینه بازیابی بستگی دارد. در عین حال، فشار انتشار نباید شاهد یا دامنه اثر را کمرنگ کند؛ این موضوع با اخلاق حرفهای در تست نرمافزار پیوند مستقیم دارد.
مثال ایران: تست دسترسپذیری Checkout و پرداخت PSP
فرض کنید یک فروشگاه ایرانی مبلغ را به تومان نشان میدهد، رمز پویا میگیرد و برای پرداخت به PSP هدایت میشود. تیم اسکن صفحه Checkout را اجرا کرده و نتیجه سبز است. یک برنامه آزمون قابل دفاع باید این لایهها را هم پوشش دهد:
پیش از انتقال به PSP
- مبلغ «۱٬۲۵۰٬۰۰۰ تومان» همراه با واحد و تخفیف به ترتیب درست خوانده شود؛
- تغییر روش ارسال، جمع نهایی را هم دیداری و هم برنامهای بهروزرسانی کند؛
- شماره موبایل با رقم فارسی و لاتین اعتبارسنجی شود و خطا به ورودی مرتبط باشد؛
- تایمر OTP فقط با رنگ یا حرکت منتقل نشود و تمدید زمان قابل کنترل باشد؛
- بازشدن دیالوگ قوانین، فوکوس را داخل آن ببرد و بستن، فوکوس را برگرداند.
در انتقال، بازگشت و خطا
- تغییر دامنه و مقصد پرداخت برای کاربر قابل فهم باشد؛
- بازگشت موفق، ناموفق، لغوشده و Timeout هرکدام عنوان و Heading روشن داشته باشند؛
- وضعیت تراکنش فقط با آیکن یا رنگ بیان نشود؛
- در شبکه کند، Loading و امکان تلاش مجدد اعلام شوند؛
- رسید، شماره پیگیری و مبلغ با ترتیب قابل کپی و خواندن ارائه شوند؛
- روی Android، TalkBack، صفحهکلید نرمافزاری و بازگشت از اپ بانک نیز بررسی شوند.
اگر PSP خارج از کنترل مستقیم شماست، مسئله را از Scope حذف نکنید. وابستگی، ترکیب آزمودهشده، مانع مشاهدهشده، مسیر پشتیبانی، کنترل جایگزین و ریسک باقیمانده را مستند کنید. یادداشت «سرویس ثالث است» مانع کاربر را برطرف نمیکند و ادعای صفحه یا فرایند کامل را خودکار معتبر نمیسازد.
امتیازدهی به ابزار؛ قبل از خرید یا استانداردسازی
برای مقایسه ابزار رایگان و تجاری، Demo جذاب یا تعداد Ruleها کافی نیست. یک Proof of Concept با صفحات و حالتهای خودتان اجرا کنید و هر معیار را از ۱ تا ۵ امتیاز دهید:
- تناسب دامنه: Web، Mobile، PDF، Design System و فناوریهای شما؛
- شفافیت Rule: نگاشت معیار، منطق، موارد Incomplete و توضیح اصلاح؛
- ادغام: IDE، Git، CI، Ticketing، API و خروجی ماشینخوان؛
- حریم خصوصی: محل پردازش، داده ارسالی، نگهداری و کنترل دسترسی؛
- کاهش نویز: گروهبندی ریشه مشترک، Baseline و استثنای محدود؛
- بازتولیدپذیری: ثبت نسخه، State، Selector، Screenshot و Trace؛
- دسترسپذیری خود ابزار: آیا تستر دارای معلولیت میتواند از آن استفاده کند؟
- هزینه کل مالکیت: مجوز، آموزش، نگهداری، Triage و تغییر فرایند؛
- پشتیبانی: SLA، مستندات، بهروزرسانی و قابلیت خروج داده؛
- اعتبار Pilot: آیا خطاهای Seedشده و موانع واقعی شناختهشده را پیدا میکند؟
وزن معیارها را پیش از دیدن نتیجه تعیین کنید. ابزار ارزان با Triage سنگین ممکن است هزینه کل بیشتری داشته باشد؛ ابزار گران هم اگر در جریان توسعه استفاده نشود، ارزش ایجاد نمیکند. هیچ امتیازی جای بازبینی حقوقی قرارداد و الزامات حوزه شما را نمیگیرد.
برنامه ۳۰روزه استقرار ابزارهای دسترسپذیری
هفته اول: دامنه و خط مبنا
- سه وظیفه حیاتی، کاربران هدف و سیاست پشتیبانی را مشخص کنید.
- یک ماتریس اولیه مرورگر/AT و یک مجموعه صفحه/حالت نماینده بسازید.
- پنج مانع شناختهشده را بهعنوان Seed برای ارزیابی ابزار نگه دارید.
هفته دوم: بازخورد نزدیک کد
- lint و axe را روی یک کامپوننت مشترک و یک جریان مرورگر فعال کنید.
- Artifact، Naming، مالک Triage و SLA اولیه را تعریف کنید.
- صفحهکلید، Zoom/Reflow و پروتکل یک صفحهخوان را آموزش دهید.
هفته سوم: Pipeline و شاهد
- حالتهای پویا و خطا را به Playwright اضافه کنید.
- Baseline بدهی را با مالک و انقضا ثبت کنید؛ Rule سراسری را خاموش نکنید.
- یک مسیر Checkout را روی ماتریس منتخب اجرا و Ticketها را کالیبره کنید.
هفته چهارم: اعتبارسنجی و تصمیم
- با کاربران دارای معلولیت یا متخصص دارای تجربه زیسته، Pilot متناسب اجرا کنید.
- خطاهای پیداشده، زمان Triage، نویز، رگرسیون و شکاف ابزار را مرور کنید.
- پشته نهایی، بودجه، آموزش، معیارها و تاریخ بازنگری ماتریس را تصویب کنید.
برای سنجش نتیجه Pilot از نرخ تکمیل وظیفه، زمان، خطا، نیاز به کمک و بازخورد کیفی استفاده کنید؛ شیوه انتخاب و تفسیر این معیارها در راهنمای روشها و معیارهای تست کاربردپذیری توضیح داده شده است.
خطاهای رایج در استفاده از ابزارهای تست WCAG
- امتیاز ۱۰۰ را گواهی مینامید: نام ابزار، Ruleset و Scope را گزارش کنید؛ نه ادعای انطباق کلی.
- فقط صفحه اولیه را اسکن میکنید: Map حالت و فرایند کامل بسازید.
- Keyboard را با Screen Reader یکی میدانید: ابتدا بدون AT و سپس با AT تست کنید.
- یک ترکیب را نماینده همه میگیرید: ماتریس را به کاربر و سیاست پشتیبانی متصل کنید.
- تستر بینا را نماینده تجربه نابینایی میدانید: نتیجه را Compatibility بنامید و کاربران هدف را مشارکت دهید.
- فارسی را یک Checkbox میبینید: رابط، TTS، تلفظ، DOM، Unicode و بریل را جدا ثبت کنید.
- هر یافته قدیمی را Suppress میکنید: استثنای محدود، مالک، دلیل و انقضا داشته باشید.
- Severity ابزار را اولویت نهایی میگیرید: اثر وظیفه، کاربران متأثر و راه جایگزین را بسنجید.
- فقط صدا ضبط میکنید: اعلان، Tree، DOM، تنظیمات و گامها را هم نگه دارید.
- ابزار را بدون آزمون دسترسپذیری خودش میخرید: تسترهای دارای معلولیت را در ارزیابی ابزار وارد کنید.
پرسشهای متداول
بهترین ابزار تست دسترسپذیری وب چیست؟
یک ابزار واحد بهترین نیست. برای بازخورد خودکار در کد و CI، axe انتخاب رایجی است؛ Lighthouse برای بررسی سریع، WAVE برای بازبینی دیداری در زمینه صفحه و صفحهخوانها برای سازگاری AT مفیدند. انتخاب نهایی به فناوری، کاربران، حریم خصوصی، Pipeline، مهارت تیم و هزینه کل مالکیت بستگی دارد.
اگر axe یا Lighthouse هیچ خطایی ندهد، سایت با WCAG منطبق است؟
خیر. نتیجه فقط قواعد اجراشده را روی همان صفحه و حالت پوشش میدهد. انطباق WCAG به ارزیابی دستی و خودکار معیارها، صفحه کامل، حالتها، فناوریهای متکی و فرایند کامل نیاز دارد. موارد Incomplete و معیارهایی که خودکارشدنی نیستند نیز باید بررسی شوند.
برای تست دسترسپذیری NVDA بهتر است یا JAWS؟
پاسخ را کاربران و سیاست پشتیبانی تعیین میکنند. NVDA آزاد و متنباز و JAWS تجاری است؛ هر دو روی Windows استفاده میشوند و رفتارشان با مرورگرها میتواند متفاوت باشد. اگر هر دو در بازار هدف حضور معنادار دارند، مسیرهای پرریسک را روی هر دو ترکیب پشتیبانیشده اجرا کنید.
چگونه با NVDA سایت فارسی را تست کنیم؟
نسخه NVDA، Windows، مرورگر، موتور گفتار، صدای فارسی و تنظیم زبان را ثبت کنید. سپس عنوان و lang، Heading و Landmark، نام/نقش/وضعیت کنترلها، فرم و خطا، فوکوس، اعلان پویا و یک وظیفه کامل را بررسی کنید. اعداد، نیمفاصله، متن آمیخته، ریال/تومان، تاریخ و OTP را جدا بسنجید و اعلان واقعی را ثبت کنید.
چند صفحهخوان و مرورگر را باید تست کنیم؟
عدد ثابتی وجود ندارد. ماتریس را از سیستمعاملهای پشتیبانیشده، داده کاربران، قرارداد و ریسک وظایف بسازید. در هر تغییر یک ترکیب اصلی کافی است، اما پیش از انتشار پرریسک مسیرهای حیاتی را روی ترکیبهای پشتیبانیشده اجرا کنید و پس از ارتقای بزرگ AT یا مرورگر، ماتریس را بازبینی کنید.
جمعبندی؛ از خروجی ابزار تا تصمیم قابل دفاع
ابزارهای تست دسترسپذیری زمانی ارزش دارند که سؤال، دامنه و محدودیتشان روشن باشد. axe و ابزارهای مشابه رگرسیونهای قابلتشخیص را زود میگیرند؛ صفحهکلید و صفحهخوان قابلیت همکاری را در یک ترکیب واقعی نشان میدهند؛ ارزیابی معیاربهمعیار درباره انطباق شاهد میسازد؛ و مشارکت کاربران دارای معلولیت موانع کاربردپذیری را آشکار میکند. هیچکدام بهتنهایی جای سه مورد دیگر نیست.
برای شروع، یک جریان حیاتی مانند ورود یا پرداخت را انتخاب کنید، سه حالت مهم آن را با Playwright و axe اسکن کنید، همان جریان را با صفحهکلید و یک ترکیب نسخهدار AT اجرا کنید و شاهدها را در یک Ticket بازتولیدپذیر جمع کنید. سپس شکافها را بسنجید و ماتریس را براساس داده—نه عادت—گسترش دهید.
