تست دسترس‌پذیری؛ راهنمای WCAG ۲.۲ با چک‌لیست

اگر کاربر با صفحه‌کلید بتواند محصول را انتخاب کند اما Focus پشت نوار ثابت «پرداخت» پنهان شود، فرایند خرید دسترس‌پذیر نیست. اگر Screen reader قیمت را بخواند ولی خطای فرم اعلام نشود نیز مشکل حل نشده است. دسترس‌پذیری با نصب یک اسکنر یا افزودن چند Alt به پایان نمی‌رسد؛ باید کل کارِ کاربر، در حالت‌ها و فناوری‌های کمکی هدف، قابل درک و انجام باشد.

این راهنما تست دسترس‌پذیری وب و اپ را بر مبنای WCAG 2.2 به یک فرایند اجرایی تبدیل می‌کند: انتخاب دامنه، اسکن خودکار، Keyboard، Zoom/Reflow، Screen reader، فرم و احراز هویت، فارسی/RTL، گزارش نقص و معیار خروج. هدف، ادعای حقوقی یا «تضمین دسترس‌پذیری برای همه» نیست؛ هدف تولید شواهد قابل‌ردیابی و رفع موانع واقعی است.

تست دسترس‌پذیری چیست؟

Accessibility Testing یا A11y فرایند ارزیابی محصول دیجیتال برای کشف موانعی است که افراد دارای معلولیت هنگام ادراک، درک، ناوبری و تعامل با محتوا تجربه می‌کنند. A11y کوتاه‌نویسی Accessibility است؛ عدد ۱۱ به حروف میان A و Y اشاره دارد.

دامنهٔ نیازها گسترده است:

• نابینایی، کم‌بینایی و تفاوت در تشخیص رنگ؛
• ناشنوایی و کم‌شنوایی؛
• محدودیت حرکتی، لرزش، استفاده‌نکردن از ماوس یا Touch دقیق؛
• تفاوت‌های شناختی، یادگیری، حافظه، توجه و زبان؛
• حساسیت به حرکت، چشمک‌زدن یا صدا؛
• ترکیب چند نیاز و استفاده از فناوری‌های کمکی متفاوت.

معلولیت می‌تواند دائمی، موقت یا موقعیتی باشد، اما دلیل اصلی Accessibility برابری دسترسی افراد دارای معلولیت است؛ اینکه بعضی اصلاح‌ها برای کاربران دیگر نیز مفیدند، نباید این هدف را کمرنگ کند.

دسترس‌پذیری، کاربردپذیری و طراحی فراگیر چه تفاوتی دارند؟

حوزه	پرسش اصلی	شاهد نمونه
Accessibility	آیا افراد با نیازها و فناوری‌های کمکی هدف می‌توانند کار را انجام دهند و معیارها را برآورده کنیم؟	WCAG، Keyboard، نام/نقش/وضعیت، AT matrix
Usability	کاربران مشخص، کار مشخص را با اثربخشی، کارایی و رضایت انجام می‌دهند؟	Completion، Error، Time، Observation
Inclusive design	از آغاز چه تنوعی در توانایی، زمینه و روش تعامل در طراحی دیده شده است؟	نیاز کاربر، محدودیت، Design decision و Co-design

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

WCAG ۲.۲ چیست؟

Web Content Accessibility Guidelines 2.2 توصیه‌نامهٔ فعلی W3C برای دسترس‌پذیری محتوای وب است. W3C استفاده از تازه‌ترین نسخه را تشویق می‌کند. WCAG ۲.۲ معیارهای نسخه‌های قبل را نگه می‌دارد، ۹ Success Criterion اضافه می‌کند و معیار ۴.۱.۱ Parsing را منسوخ و حذف می‌کند.

چهار اصل POUR

• Perceivable | قابل‌ادراک: اطلاعات و اجزا باید به شکلی قابل دریافت ارائه شوند؛ مانند متن جایگزین و Caption.
• Operable | قابل‌عملیات: تعامل با Keyboard، Pointer و روش‌های دیگر ممکن باشد؛ Focus و زمان مانع نشوند.
• Understandable | قابل‌فهم: محتوا، Navigation، ورودی و خطا قابل پیش‌بینی و فهم باشند.
• Robust | سازگار/مقاوم: معنا و وضعیت برای User agent و Assistive Technology قابل‌تفسیر باشند.

Guidelineها چارچوب می‌دهند و Success Criterionها قابل‌آزمون‌اند. Techniqueهای W3C راه‌های Informative برای پاسخ به معیارند، نه اینکه تنها پیاده‌سازی مجاز باشند.

سطح‌های A، AA و AAA

سطح AA شامل همهٔ معیارهای A و AA است؛ انتخاب چند معیار AA به معنای Conformance سطح AA نیست. W3C توصیه نمی‌کند AAA به‌عنوان سیاست عمومی برای تمام سایت‌ها الزامی شود، چون بعضی محتواها امکان برآورده‌کردن همهٔ معیارهای AAA را ندارند.

سطح معیار نیز Severity یک باگ نیست. نقض معیار A ممکن است در یک جریان کم‌استفاده باشد و نقض AA در پرداخت همهٔ کاربران را متوقف کند. اولویت را اثر روی کاربر، اهمیت Task، تعداد صفحات/کامپوننت‌ها، وجود Workaround و ریسک کسب‌وکار تعیین می‌کند.

۹ معیار تازهٔ WCAG ۲.۲

• ۲.۴.۱۱ Focus Not Obscured (Minimum) ـ AA؛
• ۲.۴.۱۲ Focus Not Obscured (Enhanced) ـ AAA؛
• ۲.۴.۱۳ Focus Appearance ـ AAA؛
• ۲.۵.۷ Dragging Movements ـ AA؛
• ۲.۵.۸ Target Size (Minimum) ـ AA؛
• ۳.۲.۶ Consistent Help ـ A؛
• ۳.۳.۷ Redundant Entry ـ A؛
• ۳.۳.۸ Accessible Authentication (Minimum) ـ AA؛
• ۳.۳.۹ Accessible Authentication (Enhanced) ـ AAA.

جزئیات و مثال‌های هر مورد در صفحهٔ رسمی تغییرات WCAG ۲.۲ آمده است.

Conformance دقیقاً چه معنایی دارد؟

Pass شدن چند صفحه یا صفرشدن خطای ابزار، ادعای انطباق نمی‌سازد. WCAG برای Conformance الزام‌هایی دارد:

• سطح کامل: همهٔ معیارهای سطح انتخاب‌شده و پایین‌تر برآورده شوند.
• صفحهٔ کامل: نمی‌توان بخش مشکل‌دار یک صفحه را از ادعا کنار گذاشت؛ حالت‌های Responsive همان صفحه نیز مشمول‌اند.
• فرایند کامل: اگر Checkout چند مرحله دارد، همهٔ صفحات/مراحل فرایند باید سطح را برآورده کنند.
• روش‌های Accessibility-supported: راه‌های مورد اتکا باید با User agent و AT هدف پشتیبانی شوند.
• عدم مداخله: فناوری غیرمتکی نباید دسترسی به بقیهٔ صفحه را مسدود کند.

برای یک سایت بزرگ، WCAG-EM روشی برای تعریف دامنه، انتخاب نمونهٔ نماینده، ارزیابی و گزارش ارائه می‌کند. Sampling باید Templateها، صفحه‌های کلیدی، حالت‌ها و فرایندهای کامل را پوشش دهد؛ انتخاب چند URL آسان، نتیجهٔ کل سایت نیست.

WCAG و قانون یکی نیستند

WCAG یک استاندارد فنی است. الزام قانونی/قراردادی به کشور، صنعت، نوع سازمان، قرارداد و نسخهٔ ارجاع‌شده بستگی دارد. «WCAG ۲.۲ AA» را بدون تعیین Scope و نظر مسئول حقوقی، معادل انطباق قانونی ایران یا هر حوزهٔ دیگری معرفی نکنید. این مقاله مشاورهٔ حقوقی نیست.

اپ Native چطور؟

تعریف Conformance در WCAG برای صفحه‌های وب است. برای اسناد و نرم‌افزار غیروب، از جمله اپ Native، WCAG2ICT 2.2 راهنمای Informative تطبیق معیارهاست و به‌تنهایی الزام Normative تازه ایجاد نمی‌کند. راهنمای Platform، استاندارد قراردادی و قوانین قابل‌اعمال نیز باید وارد Test Basis شوند. راهنمای تست اپلیکیشن موبایل VoiceOver/TalkBack، Font scale، Orientation و Touch را در Matrix دستگاه می‌گذارد.

دامنه و ماتریس تست دسترس‌پذیری

پیش از اجرا این قرارداد را ثبت کنید:

Target	WCAG ۲.۲ Level AA + معیارهای اضافی محصول
Scope	دامنه‌ها، Templateها، Componentها، PDF/Media و بخش‌های ثالث
Complete processes	ثبت‌نام، Login، خرید، پرداخت، بازیابی و پشتیبانی
User agents	Browser/OSهای پشتیبانی‌شده بر اساس کاربران و قرارداد
Assistive technology	ترکیب‌های هدف مثل NVDA/Windows، VoiceOver/iOS یا TalkBack/Android
Viewports	Desktop، Mobile، Zoom/Reflow و Text spacing
Locale	فارسی RTL، محتوای ترکیبی و زبان‌های پشتیبانی‌شده
Build/date	نسخه، Commit، Feature flag و تاریخ ارزیابی

هر Screen reader با هر Browser یکسان رفتار نمی‌کند. Matrix را از Support policy و کاربران هدف بسازید؛ یک ترکیب تنها نمی‌تواند همهٔ کاربران را نمایندگی کند و اجرای بی‌مهارت Screen reader نیز نتیجهٔ قابل‌اعتماد نمی‌دهد.

فرایند تست دسترس‌پذیری؛ از اسکن تا کاربر

۱. Test Basis و Scope را تثبیت کنید

نسخهٔ WCAG، سطح هدف، قوانین/قراردادهای قابل‌اعمال، فناوری‌ها و استثناهای دامنه را بنویسید. Inventory از Template، Component، حالت Dynamic، Media، PDF و محتوای ثالث بسازید. Owner هر بخش مشخص باشد.

۲. نمونهٔ نماینده و فرایندهای کامل را انتخاب کنید

• Homepage و Navigation اصلی؛
• هر Template یکتا؛
• صفحهٔ دارای Table، Form، Modal، Tabs و Dynamic update؛
• صفحه‌های پرترافیک و پرریسک؛
• حالت Empty، Loading، Error، Success و Permission؛
• کل مسیرهای ثبت‌نام، خرید و بازیابی؛
• نمونه‌های Responsive و زبان فارسی.

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

۳. اسکن خودکار را اجرا کنید

ابزار می‌تواند نبود Accessible name، برخی خطاهای ARIA، Contrast قابل‌محاسبه، Label و ساختار را سریع پیدا کند. اما نمی‌فهمد Alt معنی درست دارد، Focus order منطقی است، پیام خطا قابل‌فهم است یا یک سفر واقعاً انجام‌پذیر است. W3C صریح می‌گوید هیچ ابزار واحدی نمی‌تواند تعیین کند سایت همهٔ رهنمودها را برآورده می‌کند؛ ارزیابی انسانی آگاه لازم است.

مقالهٔ ابزارهای تست دسترس‌پذیری پس از بازبینی اختصاصی، Scannerها و Screen readerها را با مرز کاربردشان مقایسه خواهد کرد.

۴. Keyboard-only را بررسی کنید

ماوس و Touch را کنار بگذارید. با Tab و Shift+Tab، Enter، Space، Arrow و Escape مطابق الگوی Component حرکت کنید:

• همهٔ کنترل‌های قابل‌عمل، قابل Focus و فعال‌سازی باشند.
• ترتیب Focus با معنا و ترتیب بصری/DOM هم‌خوان باشد.
• Focus indicator همیشه قابل‌دیدن و پشت Header/Cookie bar پنهان نشود.
• Skip link یا راه سریع برای عبور از بخش تکراری کار کند.
• Modal Focus را به‌درستی وارد کند، داخل تجربهٔ Modal مدیریت کند و پس از بستن به Trigger برگرداند.
• Keyboard trap وجود نداشته باشد؛ خروج کنترل‌شده ممکن باشد.
• Custom widget از Keyboard pattern شناخته‌شده پیروی کند.
• Drag تنها راه انجام عمل نباشد و جایگزین Single-pointer داشته باشد.

استفادهٔ بی‌دلیل از tabindex مثبت معمولاً ترتیب را شکننده می‌کند. ترتیب منطقی را از DOM و Component درست بسازید، نه با وصلهٔ عددی.

۵. Structure و Semantics را بخوانید

• Title صفحه و زبان اصلی درست است.
• Headingها ساختار را توصیف می‌کنند، نه صرفاً اندازهٔ بصری.
• Landmarkها Navigation را قابل‌پرش می‌کنند.
• Link و Button نام قابل‌فهم در Context دارند.
• Table دارای Header و رابطهٔ درست است.
• List واقعاً با Semantics فهرست پیاده شده است.
• وضعیت Expand/Selected/Checked/Invalid به AT منتقل می‌شود.
• Status message بدون جابه‌جایی ناموجه Focus اعلام می‌شود.

HTML بومی را بر ARIA سفارشی ترجیح دهید. ARIA رفتار Keyboard یا State management را خودکار اضافه نمی‌کند. برای Widgetهای پیچیده، ARIA Authoring Practices Guide الگو و مدل تعامل می‌دهد؛ APG خود استاندارد Normative یا Design system نیست.

۶. تصویر، Icon و Media را ارزیابی کنید

نوع	انتظار
تصویر اطلاعاتی	Text alternative هدف و اطلاعات لازم را منتقل کند.
تصویر تزئینی	از Accessibility tree حذف شود تا نویز نسازد.
تصویر عملکردی	نامِ عمل یا مقصد را بدهد، نه شکل ظاهری را.
Chart پیچیده	خلاصه، روند و داده/جدول معادل قابل‌دسترسی داشته باشد.
Video	Caption دقیق و در صورت نیاز Audio description؛ کنترل Keyboard-accessible.
Audio	Transcript یا Alternative متناسب با معیار و هدف.

Alt طولانی و پر از کلیدواژه SEO برای کاربر مفید نیست. Text alternative باید در Context تصمیم بگیرد چه اطلاعاتی لازم است.

۷. رنگ، Contrast و Presentation را بسنجید

• Text عادی در AA معمولاً حداقل Contrast ۴.۵:۱ و Text بزرگ ۳:۱ می‌خواهد.
• اجزای UI و اطلاعات گرافیکی لازم معمولاً Contrast غیرمتنی ۳:۱ می‌خواهند.
• رنگ تنها نشانهٔ خطا، انتخاب، وضعیت یا نمودار نباشد.
• در Zoom ۲۰۰% محتوا و عمل اصلی باقی بمانند.
• در Reflow تا عرض متناظر ۳۲۰ CSS pixel، Scroll دوبعدی برای محتوای معمول لازم نشود؛ استثناهای معیار لحاظ شوند.
• با Text spacing سفارشی، متن قطع یا کنترل پنهان نشود.
• در High contrast/Forced colors و Dark mode معنا از بین نرود.
• Target size حداقل WCAG ۲.۲ با استثناهای معیار سنجیده شود؛ صرف اندازهٔ بصری کافی نیست.

عدد Contrast را روی رنگ محاسبه‌شده و Stateهای Hover/Focus/Disabled بررسی کنید. Placeholder کم‌رنگ جای Label نیست.

۸. Form، Error و Authentication را تست کنید

• هر کنترل Label قابل‌مشاهده و Programmatic دارد.
• Required، Format و محدودیت پیش از خطا تا حد لازم روشن‌اند.
• Error با Text شناسایی، به Field متصل و قابل‌اصلاح است.
• Error summary به موارد لینک/Focus مناسب می‌دهد.
• دادهٔ واردشده پس از خطای دیگر بی‌دلیل پاک نمی‌شود.
• اطلاعات قبلاً واردشده در همان فرایند دوباره مطالبه نمی‌شود، مگر استثنا.
• Password manager، Paste و Autofill بی‌دلیل مسدود نمی‌شوند.
• Authentication تنها به حفظ‌کردن، رونویسی یا Puzzle شناختی وابسته نیست یا سازوکار کمکی/جایگزین معیار را فراهم می‌کند.
• عمل حقوقی/مالی امکان Review، اصلاح یا تأیید متناسب دارد.

برای فارسی، Label، Help و Error باید در Accessibility name/description زبان درست داشته باشند. نمایش «خطا» بدون نام Field برای Screen reader کافی نیست.

۹. Screen reader را روی Task اجرا کنید

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

• Heading/landmark navigation مسیر سریع می‌دهد.
• Name، Role، Value و State هر کنترل درست اعلام می‌شود.
• ترتیب خواندن و Focus با معنای RTL هم‌خوان است.
• Modal، Menu، Tab، Combobox و Accordion الگوی قابل‌انتظار دارند.
• Loading، نتیجهٔ جست‌وجو، افزودن به سبد و Error اعلام می‌شوند.
• Focus پس از افزودن/حذف/ارسال فرم به محل مفید می‌رود.
• Text مخفی یا تکراری نویز غیرضروری نمی‌سازد.

نام Screen reader، نسخه، OS، Browser، Build و تنظیمات مهم را در شاهد ثبت کنید. اختلاف رفتار میان دو ترکیب ممکن است مشکل محصول، Browser، AT یا روش استفاده باشد و Triage فنی بخواهد.

۱۰. کاربران دارای معلولیت را درگیر کنید

آزمون با کاربران، موانع واقعی و الگوهای استفاده‌ای را آشکار می‌کند که Audit معیارمحور نمی‌بیند. اما W3C هشدار می‌دهد مطالعهٔ چند کاربر به‌تنهایی Conformance یا تجربهٔ همهٔ افراد دارای معلولیت را تعیین نمی‌کند. User evaluation و Standards evaluation مکمل‌اند.

راهنمای W3C برای مشارکت کاربران توصیه می‌کند Scope، روش و ویژگی‌های مشارکت‌کنندگان گزارش شود و نتیجه بیش از دامنهٔ مطالعه تعمیم نیابد. مشارکت باید با رضایت، دستمزد منصفانه، ابزار آشنای کاربر و دسترسی واقعی برگزار شود.

نمونهٔ عملی: Checkout فارسی و RTL

فرایند کامل شامل سبد، آدرس، ارسال، پرداخت Sandbox و تأیید است. یک بستهٔ آزمون کوچک:

ریسک	آزمون	شاهد
Focus پنهان	Keyboard در Mobile viewport با نوار ثابت پایین	ویدئو + Focus path + SC ۲.۴.۱۱
خطای نامفهوم	ارسال آدرس ناقص با Screen reader	اعلان Error، ارتباط Field و امکان اصلاح
RTL/DOM mismatch	مرور Summary فارسی با کد رهگیری لاتین	Reading order و متن اعلام‌شده
Authentication	OTP با Paste/Autofill و خطای انقضا	Completion بدون رونویسی اجباریِ بدون کمک
Target کوچک	تغییر تعداد و حذف آیتم با Touch	اندازه/فاصله و Alternative action
Reflow	Zoom و عرض ۳۲۰ CSS px	عدم قطع قیمت/دکمه و Scroll موردنیاز
پرداخت	بازگشت از Sandbox به وضعیت نتیجه	Heading/Focus/Status و امکان بازیابی

جزئیات فارسی که باید عمدی تست شوند

• lang=”fa” و dir=”rtl” در سطح درست؛
• بخش انگلیسی/عدد با Language of parts و Bidi مناسب؛
• ترتیب DOM مستقل از جابه‌جایی صرفاً بصری CSS؛
• خوانش مبلغ ریال/تومان، تاریخ و شماره رهگیری؛
• نام Accessible فارسی برای Iconهای بدون متن؛
• نیم‌فاصله و متن طولانی در Label/Heading؛
• Caption/Transcript فارسی دقیق و قابل جست‌وجو؛
• Font فارسی در Zoom، Text spacing و High contrast.

Screen readerهای مختلف ممکن است عدد و نشانه‌گذاری فارسی را متفاوت بخوانند. مشکل را با ترکیب هدف ثبت کنید و Oracle را از فهم Task بسازید، نه سلیقهٔ تلفظ.

اتوماسیون دسترس‌پذیری در CI/CD

اتوماسیون باید Regressionهای قابل‌ماشین را سریع متوقف کند، نه اینکه درصد «Accessibility score» را به گواهی تبدیل کند.

• Lint و Component test برای نام، Role و ARIA ناسازگار؛
• Unit/Story test برای Stateهای Error، Disabled، Expanded و Loading؛
• Scanner روی صفحات/Storyهای تغییرکرده در Pull request؛
• Crawl گستردهٔ زمان‌بندی‌شده روی Templateها؛
• Keyboard smoke برای Journeyهای حیاتی؛
• Screenshot/Visual check در Zoom، RTL و Theme با ارزیابی انسانی؛
• Manual/AT session در Release cadence؛
• User evaluation در تغییرهای مهم Journey و Design system.

Baseline کردن خطاهای قدیمی ممکن است مهاجرت را ممکن کند، اما هر مورد باید Owner و برنامهٔ کاهش داشته باشد. «خطای تازه ممنوع» نباید بدهی موجود را برای همیشه پنهان کند. معیار انتخاب اتوماسیون را با راهنمای اتوماسیون تست تطبیق دهید.

تست دسترس‌پذیری را در چرخه توسعه کجا بگذاریم؟

Discovery و Design

• نیازهای Accessibility و فناوری‌های هدف را با کاربر/ذی‌نفع مشخص کنید.
• Contrast، Focus order، Error، Motion و Text resizing را در Design review ببینید.
• Componentهای Native/HTML را بر Custom widget ترجیح دهید.

Development

• Semantic HTML/Platform API، Label و State را همراه رفتار بسازید.
• Design system برای Focus، Contrast، Target و Error قرارداد داشته باشد.
• Keyboard و Screen reader smoke روی Component قبل از ادغام انجام شود.

Test و Release

• Scan، Manual، AT و فرایند کامل را بر Scope مصوب اجرا کنید.
• نقص‌های Blocker و ریسک باقیمانده مالک و تصمیم داشته باشند.
• Conformance claim فقط با دامنه، نسخه، تاریخ و شواهد کافی نوشته شود.

Production

• صفحه/کامپوننت تازه، Content و Third-party widget پایش شوند.
• کانال Feedback دسترس‌پذیر و پاسخ‌گو باشد.
• اصلاح Hotfix دوباره با روش و AT مرتبط Retest شود.

چطور تست‌کیس A11y بنویسیم؟

عنوان «صفحه را با NVDA تست کن» قابل‌تکرار نیست. Test case باید این موارد را داشته باشد:

• معیار/نیاز و اثر مورد انتظار بر کاربر؛
• Build، URL/Screen، State و داده؛
• Browser/OS/AT و نسخه‌ها؛
• روش ورودی: Keyboard، Touch، Voice یا Screen reader command؛
• گام‌های Taskمحور و Oracle؛
• شاهد: Focus path، خروجی اعلام‌شده، Contrast یا DOM؛
• Cleanup و محدودیت پوشش.

برای قالب عمومی، راهنمای نوشتن تست‌کیس را با این داده‌های Accessibility تکمیل کنید.

گزارش نقص دسترس‌پذیری

گزارش خوب فقط نمی‌گوید «Screen reader کار نمی‌کند». قالب پیشنهادی:

• عنوان: [Checkout][Keyboard] Focus دکمه پرداخت پشت نوار ثابت پنهان می‌شود؛
• اثر کاربر: کاربر کم‌بینا/Keyboard نمی‌داند Focus کجاست و ادامه دشوار می‌شود؛
• معیار: WCAG ۲.۲ SC ۲.۴.۱۱ AA؛
• محیط: Browser، OS، AT، Viewport، Zoom و Build؛
• مراحل: کوتاه، قابل‌تکرار و Taskمحور؛
• Observed/Expected: رفتار دقیق، نه راه‌حل حدسی؛
• شاهد: ویدئو، Screenshot، DOM/Accessibility tree در حد لازم؛
• دامنه: Component/Templateهای دیگری که احتمالاً متاثرند؛
• Retest: همان ترکیب و Regression پیرامونی.

Severity را از مانع Task بسازید: Blocker، Major، Moderate یا Minor طبق قرارداد تیم. سطح A/AA/AAA را جای شدت قرار ندهید. برای اصول شواهد و Retest، گزارش باگ حرفه‌ای را ببینید.

متریک‌های مفید دسترس‌پذیری

متریک	پرسش تصمیم	هشدار
پوشش Template/Process	کدام جریان کامل هنوز ارزیابی نشده؟	تعداد URL عمق پوشش نیست.
پوشش معیار با روش	کدام SC فقط Scan و کدام Manual/AT دارد؟	ابزار همهٔ SCها را نمی‌سنجد.
Blocker age	موانع حیاتی چند وقت باز مانده‌اند؟	میانگین، مورد بحرانی قدیمی را پنهان می‌کند.
Component recurrence	کدام نقص در Design system تکرار می‌شود؟	شمار باگ بدون Root cause بازی‌پذیر است.
Retest success	اصلاح واقعاً مانع را برداشته؟	بسته‌شدن Ticket شاهد نیست.
User task outcome	کاربران هدف کجا متوقف یا سردرگم می‌شوند؟	مطالعهٔ کوچک قابل تعمیم به همه نیست.
Feedback response	گزارش کاربر چقدر سریع دریافت و حل می‌شود؟	فقط زمان پاسخ، کیفیت حل را نمی‌سنجد.

اشتباه‌های رایج تست دسترس‌پذیری

• Score سبز برابر Conformance: ابزار فقط بخشی از معیارها را می‌بیند.
• Alt برای همهٔ تصویرها: تصویر تزئینی نویز می‌سازد و Alt بدتر از سکوت است.
• ARIA به‌جای HTML: Role بدون Keyboard و State رفتار قابل‌استفاده نمی‌سازد.
• Placeholder به‌جای Label: با ورود متن ناپدید می‌شود و ارتباط Programmatic ممکن است نباشد.
• تست فقط با Tab: Semantics، Reading order، Status و Touch جا می‌مانند.
• تست فقط با یک Screen reader: Support matrix و کاربران دیگر نادیده می‌شوند.
• تکیه فقط بر کاربر نابینا: نیازهای حرکتی، شنوایی، شناختی و کم‌بینایی جا می‌مانند.
• یکی‌دانستن AA با قانون: Scope، نسخه و حوزهٔ قضایی مشخص نیست.
• اولویت بر اساس سطح SC: اثر واقعی Task پنهان می‌شود.
• رفع موضعی: Component مشترک اصلاح نمی‌شود و باگ برمی‌گردد.
• ادعای SEO: هم‌پوشانی Semantic ممکن است وجود داشته باشد، اما Accessibility نباید تاکتیک رتبه‌گیری تقلیل یابد.

چک‌لیست نهایی A11y

• نسخه WCAG، سطح، Scope، Build و تاریخ ثبت شده‌اند.
• قانون/قرارداد قابل‌اعمال جدا از استاندارد فنی تعیین شده است.
• Templateها، حالت‌ها، Third-party و فرایندهای کامل در نمونه‌اند.
• Scan خودکار با Keyboard، Manual و AT ترکیب شده است.
• Heading، Landmark، Name/Role/Value و Status درست‌اند.
• Focus order، indicator، عدم انسداد و عدم Trap بررسی شده‌اند.
• Alt/Media alternative بر اساس هدف محتوا ارزیابی شده‌اند.
• Contrast، Color، Zoom، Reflow، Text spacing و Target پوشش دارند.
• Form، Error، Authentication و عمل مالی قابل انجام و اصلاح‌اند.
• فارسی/RTL، Language، Bidi و خوانش عدد/مبلغ آزمون شده‌اند.
• کاربران دارای معلولیت به‌صورت مکمل و با Scope روشن مشارکت کرده‌اند.
• گزارش‌ها اثر کاربر، SC، محیط، شاهد و Retest دارند.

سوالات متداول تست دسترس‌پذیری

WCAG ۲.۲ AA یعنی سایت کاملاً دسترس‌پذیر است؟

AA یک سطح Conformance فنی با الزام‌های دقیق است و شواهد مهمی می‌دهد، اما همهٔ نیازهای هر کاربر یا Usability را تضمین نمی‌کند. Conformance نیز به صفحهٔ کامل، فرایند کامل، Scope و فناوری‌های پشتیبانی‌شده وابسته است.

آیا ابزار خودکار برای تست A11y کافی است؟

خیر. ابزار برخی خطاهای ماشینی را سریع پیدا می‌کند، اما کیفیت Alt، منطق Focus، قابل‌فهم‌بودن Error و انجام‌پذیری Task را کامل نمی‌سنجد. Keyboard، Manual، AT و درگیری کاربر لازم‌اند.

از کدام Screen reader برای فارسی استفاده کنیم؟

از ترکیب‌های واقعی کاربران و Support policy شروع کنید؛ برای مثال NVDA با Browser هدف در Windows، VoiceOver در Apple یا TalkBack در Android. هیچ ترکیب واحدی نمایندهٔ همه نیست. نسخه‌ها و خروجی فارسی واقعی را ثبت کنید.

تفاوت تست دسترس‌پذیری و تست کاربردپذیری چیست؟

Accessibility روی رفع موانع افراد دارای معلولیت و معیارهای فنی/تعامل با AT تمرکز دارد؛ Usability انجام Task توسط کاربران مشخص را از نظر اثربخشی، کارایی و رضایت مطالعه می‌کند. در یک ارزیابی بالغ، هر دو مکمل‌اند.

هر چند وقت یک‌بار Accessibility را تست کنیم؟

قواعد و Componentها باید در هر تغییر مرتبط بازخورد سریع بگیرند؛ Template و Journeyهای حیاتی در Release cadence ارزیابی شوند؛ Audit دامنه‌دار و User evaluation پس از تغییر بزرگ یا طبق ریسک تکرار شود. Content و Third-party widget نیز بعد از Release پایش می‌خواهند.

منابع و یادداشت بازبینی

نسخه و Conformance با WCAG ۲.۲، روش نمونه‌گیری با WCAG-EM، نرم‌افزار غیروب با WCAG2ICT ۲.۲ و مشارکت کاربران با راهنمای W3C WAI تطبیق داده شده است. آخرین بازبینی محتوایی: ۱۵ مرداد ۱۴۰۵. قوانین و استانداردهای قراردادی ممکن است نسخه و دامنهٔ دیگری بخواهند؛ Test Plan باید مرجع دقیق پروژه را ثبت کند.

جمع‌بندی: Accessibility یک تیک ابزار نیست. دامنه و فرایند کامل را تعریف کنید، معیار را با اثر کاربر پیوند دهید، Scan را با Keyboard و AT و کاربر تکمیل کنید، فارسی/RTL را عمدی بسنجید و Root cause را در Component مشترک رفع کنید. در این صورت گزارش شما از «چند خطای A11y» به شواهدی برای دسترسی واقعی تبدیل می‌شود.