ممیزی دسترس‌پذیری وب؛ تست WCAG ۲.۲ و رفع ایراد

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

یک Scanner می‌تواند نبود Label یا Contrast مشکوک را سریع پیدا کند، اما نمی‌فهمد متن جایگزین تصویر برای هدف صفحه مناسب است، ترتیب Focus منطقی است یا کاربر Screen reader می‌تواند خرید را کامل کند. ممیزی معتبر، ابزار خودکار را با تست دستی، فناوری کمکی، بررسی کد و مشارکت افراد دارای معلولیت ترکیب می‌کند.

ممیزی Accessibility چه خروجی‌ای باید بدهد؟

خروجی مفید یک فهرست بلند از Selectorها نیست. تصمیم‌گیر باید بداند Barrier کجاست، چند کاربر/صفحه را درگیر می‌کند، کدام Journey را می‌شکند و Fix در کدام لایه انجام می‌شود.

مقاله حاضر روی Audit و Remediation متمرکز است. اگر به اصول Inclusive design، مشارکت کاربر، WCAG در فرایند طراحی و Governance سراسری نیاز دارید، ابتدا راهنمای طراحی فراگیر و WCAG ۲.۲ را بخوانید.

پنج مفهوم را با هم اشتباه نگیرید

این روش‌ها مکمل‌اند. تست با چند کاربر جای Audit معیاربه‌معیار را نمی‌گیرد و پاس‌شدن WCAG نیز همه موانع کاربردپذیری را تضمین نمی‌کند. برای طراحی مطالعه Task-based از راهنمای تست کاربردپذیری استفاده کنید.

WCAG ۲.۲ را برای Audit چگونه بخوانیم؟

WCAG 2.2 معیارهای موفقیت را زیر چهار اصل POUR سازمان می‌دهد: Perceivable، Operable، Understandable و Robust. معیارها در سطح A، AA و AAA قرار می‌گیرند. انتخاب Target باید در Scope نوشته شود؛ عبارت «مطابق آخرین استاندارد» کافی نیست.

نسخه، سطح و دامنه را صریح کنید

نمونه عبارت دقیق: «ارزیابی صفحات و Flowهای فهرست‌شده در نسخه Production مورخ X، بر مبنای WCAG ۲.۲ سطح A و AA، با محیط‌های آزمون ثبت‌شده». اگر صرفاً یک بررسی سریع انجام شده، آن را Conformance audit ننامید.

انطباق برای صفحه کامل و فرایند کامل است

نمی‌توان Header یا Widget مشکل‌دار را از صفحه کنار گذاشت و همان صفحه را منطبق اعلام کرد. در فرایندی مثل خرید، همه مرحله‌ها از انتخاب تا تأیید باید سطح هدف را برآورده کنند. نسخه Responsive صفحه نیز بخشی از همان صفحه است.

AAA را هدف عمومی اجباری اعلام نکنید

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

Conformance claim اختیاری اما دقیق است

اگر ادعای رسمی می‌کنید، تاریخ، نسخه WCAG، سطح، Scope URLها و فناوری‌های متکی را ثبت کنید. عبارت بازاریابی «۱۰۰٪ دسترس‌پذیر» بدون Scope، Evidence و محدودیت قابل دفاع نیست.

Audit brief را پیش از نصب ابزار بنویسید

یک Brief خوب جلوی نمونه‌گیری سلیقه‌ای و اختلاف بر سر خروجی را می‌گیرد.

• هدف: Baseline، پیش از Launch، Procurement، شکایت، Regression یا ادعای Conformance؛
• Scope: دامنه، Subdomain، Web app، نسخه موبایل وب و فایل‌های دانلودی؛
• Standard: WCAG ۲.۲ و سطح هدف؛
• Journey: ثبت‌نام، جست‌وجو، خرید، پرداخت، رزرو، شکایت و مدیریت حساب؛
• Technology: HTML/CSS/JS، Framework، CMS و Widget ثالث؛
• Environment: Browser، OS، Viewport، Zoom و Assistive technology؛
• State: مهمان/واردشده، Empty/Error/Loading، سطح دسترسی و زبان؛
• Evidence: Screenshot، ویدئو، DOM/Code، Steps و نتیجه مورد انتظار؛
• Limit: چیزهای آزموده‌نشده، دسترسی‌های ناقص و محتوای ثالث؛
• Retest: پنجره اصلاح، محیط، نسخه Build و معیار بسته‌شدن Issue.

Inventory را براساس صفحه، Template، Component و Journey بسازید

ممیزی صرفاً بر URLهای پربازدید، Component مشترک و Stateهای پنهان را جا می‌اندازد. چهار View موازی لازم است:

از Analytics برای اولویت استفاده کنید، نه حذف. صفحه کم‌ترافیکِ بازیابی رمز یا شکایت ممکن است Business critical باشد. گزارش پشتیبانی، Feedback کاربران، Known issues و تغییرات Release اخیر نیز به Inventory اضافه شوند.

نمونه نماینده را با WCAG‑EM انتخاب کنید

راهنمای WCAG‑EM پنج گام دارد: تعریف Scope، شناخت سایت، انتخاب Sample نماینده، ارزیابی Sample و گزارش یافته‌ها. نسخه ۱.۰ روش تثبیت‌شده وب‌سایت است و WCAG‑EM ۲.۰ در Snapshot این مقاله هنوز Draft است؛ Status سند را در گزارش بنویسید.

نمونه Structured

صفحات و Stateهایی را انتخاب کنید که تنوع واقعی را نمایندگی کنند:

• هر Template و Layout اصلی؛
• تمام مرحله‌های Journey بحرانی؛
• صفحه با جدول، فرم، رسانه و محتوای پیچیده؛
• صفحه‌های دارای Widget/Plugin ثالث؛
• محتوای فارسی، انگلیسی و Code-switch؛
• صفحه با سطح دسترسی و State متفاوت؛
• صفحه جدید و Legacy با فناوری متفاوت.

نمونه Random

چند URL تصادفی از Scope نیز اضافه کنید تا خطاهای محتوایی و Variationهایی که Inventory ندیده آشکار شوند. نسبت ثابت و جادویی برای همه سایت‌ها وجود ندارد؛ اندازه Sample را با تنوع، ریسک و Confidence تعیین و دلیلش را ثبت کنید.

هرم تست: از Automation تا کاربر واقعی

W3C در راهنمای انتخاب ابزار ارزیابی صریح است که ابزارها نمی‌توانند همه جنبه‌ها را خودکار بررسی کنند و برای قضاوت به انسان نیاز است. Score ابزار را KPI داخلی همان ابزار بدانید، نه درصد Accessibility یا مدرک WCAG.

Quick scan اولیه در ۲۰ دقیقه

این بررسی برای Triage است، نه نتیجه نهایی. Easy Checks رسمی WAI نیز آن را مرور مقدماتی و غیرجامع معرفی می‌کند.

1. Title صفحه و lang="fa"/dir="rtl" را بررسی کنید.
2. بدون Mouse با Tab و Shift+Tab حرکت و Focus را دنبال کنید.
3. تا ۲۰۰٪ Zoom و Viewport باریک، Reflow و خوانایی را ببینید.
4. Headingها، Landmarkها، Link text و Label فرم را مرور کنید.
5. تصاویر مهم/تزئینی و Alt را با هدف محتوا تطبیق دهید.
6. Contrast متن، Component و Focus indicator را اندازه بگیرید.
7. Motion، Carousel، Auto-play و Flash را Pause/Stop کنید.
8. یک Automated scan روی State اولیه و پس از تعامل اجرا کنید.
9. یک فرم را عمداً غلط بفرستید و Error/Focus را بررسی کنید.

اگر مانع بحرانی مانند Keyboard trap، Login غیرقابل استفاده یا خطای پرداختِ اعلام‌نشده پیدا شد، پیش از Audit گسترده Containment و Fix آن را آغاز کنید.

پروتکل تست Keyboard

Mouse را کنار بگذارید و هر Journey منتخب را از ابتدا تا انتها اجرا کنید. کلیدهای دقیق به Pattern بستگی دارند؛ مثلاً Arrow key در Tabs یا Menu می‌تواند نقش داشته باشد. رفتار Component را با قرارداد خودش بسنجید.

• ترتیب Focus با ترتیب بصری و معنایی هماهنگ است.
• Focus همیشه دیده می‌شود و زیر Sticky header/Modal پنهان نمی‌ماند.
• تمام کنترل‌های تعاملی قابل رسیدن و فعال‌کردن‌اند.
• عنصر غیرفعال یا پنهان Focus نمی‌گیرد.
• Skip link به محتوای اصلی می‌رسد.
• Modal هنگام بازشدن Focus مناسب می‌گیرد، Trap درست دارد و پس از بستن Focus را برمی‌گرداند.
• Esc فقط جایی که قرارداد Component می‌طلبد خروج امن ایجاد می‌کند.
• Drag یا Gesture ضروری، Alternative قابل‌عملیات دارد.
• Timeout هشدار، تمدید یا حفظ داده مناسب دارد.
• هیچ Keyboard trap ناخواسته‌ای وجود ندارد.

نتیجه را با Sequence ثبت کنید: «از Header با هفت بار Tab به دکمه X رسیدیم؛ Focus دیده نشد» بسیار مفیدتر از «Keyboard مشکل دارد» است.

Zoom، Reflow، Contrast، رنگ و Motion را جدا تست کنید

Responsive بودن به‌تنهایی Reflow یا Zoom سالم را ثابت نمی‌کند. در Viewport هدف و Zoom لازم، این موارد را کنترل کنید:

• متن، کنترل و پیام بدون برش یا هم‌پوشانی باقی می‌مانند.
• Scroll افقی فقط برای محتوای واقعاً دوبعدی مانند جدول پیچیده لازم است.
• بزرگ‌کردن فاصله متن، Label و Button را خراب نمی‌کند.
• رنگ تنها وسیله انتقال Error، انتخاب، وضعیت یا نمودار نیست.
• Contrast متن، متن بزرگ، UI component و Focus با معیار مربوط سنجیده می‌شود.
• Motion ناشی از Interaction قابل کاهش و انیمیشن خودکار قابل Pause است.
• prefers-reduced-motion رفتار پرخطر/غیرضروری را کاهش می‌دهد.

عدد Contrast را همراه Foreground، Background، State، اندازه/وزن متن و معیار WCAG ثبت کنید. «به‌نظر کم‌رنگ است» Evidence قابل Retest نیست.

ساختار، Landmark و Navigation را بررسی کنید

• یک main معنادار و Landmarkهای تکراری با نام متمایز وجود دارند.
• Headingها موضوع و سلسله‌مراتب محتوا را نشان می‌دهند؛ انتخاب Level صرفاً برای اندازه بصری نیست.
• Page title مقصد و Context را روشن می‌کند.
• لینک‌ها از متن یا Context نزدیک قابل تشخیص‌اند و «اینجا» تکراری نیستند.
• Current page/step فقط با رنگ مشخص نشده و حالت برنامه‌پذیر دارد.
• Breadcrumb، منو و Help در صفحات مشابه رفتار سازگار دارند.
• Skip link و Heading navigation راه عبور از Blockهای تکراری می‌دهند.

تعداد دقیق H1 به‌تنهایی معیار WCAG نیست؛ مسئله، ساختار قابل فهم و Headingهای توصیفی است. خروجی ابزار Heading outline را با معنی واقعی محتوا بازبینی کنید.

Accessible name، Role، State و Value را Audit کنید

هر کنترل باید نام قابل فهم و نقش درست داشته باشد؛ State و Value تغییرپذیر باید به فناوری کمکی منتقل شوند. نام دیداری و Accessible name نیز نباید آن‌قدر متفاوت باشند که کاربر Speech input نتواند کنترل را با متن روی صفحه فراخوانی کند.

از عنصر Native شروع کنید؛ ARIA جای رفتار، Focus و Keyboard را نمی‌گیرد. ARIA Authoring Practices Guide Pattern و نمونه ارائه می‌دهد، اما خود APG استاندارد Normative یا Design system آماده Production نیست. مثال را با نیاز، Browser/AT و کد خودتان آزمون کنید.

Screen reader را با ماتریس نسخه‌دار تست کنید

یک ترکیب Screen reader/Browser نتیجه همه کاربران نیست. ماتریس را از Analytics، دستگاه مخاطب، پشتیبانی رسمی فناوری و تحقیق کاربر بسازید. برای هر ترکیب، نسخه OS، Browser، AT، زبان و تاریخ را ثبت کنید.

Taskهای حداقلی

1. Page title، زبان، Landmark و Heading list را مرور کنید.
2. Link/Button/Form control list را برای نام‌های تکراری یا مبهم بررسی کنید.
3. Navigation و Skip link را اجرا کنید.
4. Form را صحیح و غلط ارسال و Error summary/field error را بشنوید.
5. Modal، Menu، Tab، Combobox و Disclosure را باز و بسته کنید.
6. Loading، Error، Success و تغییر Async را بدون جابه‌جایی بی‌دلیل Focus دریافت کنید.
7. Journey کامل را با Browse و Focus mode مناسب انجام دهید.

ویژگی‌های خاص فارسی و RTL

• زبان اصلی صفحه fa و بخش انگلیسی لازم با lang="en" مشخص است.
• dir="rtl" روی Container درست است و عبارت‌های ترکیبی Bidi به‌هم نمی‌ریزند.
• تلفن، کد، ایمیل، درصد، تاریخ و مبلغ ترتیب شنیداری/دیداری قابل فهم دارند.
• Label فارسی با Control ارتباط برنامه‌پذیر دارد؛ Placeholder جای Label نیست.
• رقم فارسی و لاتین در ورودی‌هایی مانند موبایل، کدملی و OTP طبق Requirement پذیرفته یا راهنمایی می‌شوند.
• متن جایگزین، Caption و Transcript فارسی با تلفظ نام برند بازبینی شده‌اند.
• ترتیب Arrow و آیکون‌ها در RTL معنا را وارونه یا مبهم نمی‌کند.

دستگاه و مرورگر واقعی را در ماتریس نگه دارید؛ شبیه‌ساز DevTools همه رفتار Keyboard، Touch، Zoom و AT را بازتولید نمی‌کند. چارچوب تست Responsive و شبکه در راهنمای موبایل‌فرندلی تکمیل شده است.

تصویر و Alt را با تصمیم‌نامه محتوا ارزیابی کنید

قاعده «برای همه تصاویر Alt توصیفی بنویس» غلط است. سؤال این است که تصویر در Context چه کاری انجام می‌دهد.

برای نمودار فارسی، Trend، نتیجه و دسترسی به داده پایه را بررسی کنید. رنگ نباید تنها راه تمایز Series باشد و Legend باید با بزرگ‌نمایی/Screen reader قابل استفاده بماند.

فرم، احراز هویت و خطا را End-to-end تست کنید

فرم ممکن است در حالت خالی پاس شود و پس از Validation غیرقابل استفاده گردد. آموزش رسمی Form در WAI بر Label، گروه‌بندی، Instruction و Feedback قابل فهم تأکید می‌کند.

• هر Field نام دیداری و برنامه‌پذیر دارد.
• Required، Format و مثال پیش از خطا روشن‌اند.
• autocomplete و inputmode متناسب‌اند و Zoom را مختل نمی‌کنند.
• Error با متن، Field و Summary مرتبط است؛ فقط Border قرمز نیست.
• پس از Submit ناموفق، Focus یا Summary کاربر را به خطا هدایت می‌کند.
• داده معتبرِ قبلی حفظ می‌شود و اصلاح یک Field بقیه را پاک نمی‌کند.
• فرمت موبایل، کدملی، کارت، تاریخ و مبلغ فارسی/لاتین آزمایش می‌شود.
• OTP امکان Paste و زمان کافی/ارسال دوباره روشن دارد.
• CAPTCHA یک راه جایگزین قابل استفاده و Support دارد.
• نمایش/پنهان‌کردن رمز، Password manager و Authentication بدون آزمون شناختی ناموجه کار می‌کنند.
• Success/Failure پرداخت به‌صورت متنی و برنامه‌پذیر اعلام می‌شود.

Validation سمت کاربر برای تجربه است، نه امنیت؛ داده در Server نیز باید اعتبارسنجی شود. برای فروشگاه، تمام Flow جست‌وجو تا پرداخت را با راهنمای UX فروشگاه اینترنتی تطبیق دهید.

محتوای صوتی، ویدئویی و فایل دانلودی را فراموش نکنید

• Caption هم گفتار و هم صدای معنادار را منتقل می‌کند و Sync است.
• Transcript برای محتوای صوتی/ویدئویی متناسب و قابل دسترسی است.
• Audio description وقتی اطلاعات بصری ضروری در Audio نیست بررسی می‌شود.
• Player با Keyboard و Screen reader کار و Focus واضح دارد.
• Auto-play، صدا و Motion کنترل مناسب دارند.
• PDF، Word، فایل Office و Downloadها در Scope یا Exclusion صریح‌اند.
• اطلاعات حیاتی فقط در تصویر اسکن‌شده یا فایل غیرقابل‌دسترسی محبوس نیست.

صرف داشتن Transcript جای Caption همگام یا Audio description لازم را نمی‌گیرد؛ Alternative را براساس نوع محتوا و معیار هدف انتخاب کنید.

Third-party widget را از Scope حذف نکنید

کاربر تفاوت کد شما و Vendor را نمی‌بیند. درگاه، Chat، Map، CAPTCHA، Cookie banner، Video player و Booking می‌توانند Journey را مسدود کنند. اگر کنترل مستقیم ندارید:

1. Barrier و اثرش را مانند Issue داخلی مستند کنید.
2. Ticket و SLA Vendor را ثبت کنید.
3. Alternative معادل و قابل‌کشف بسازید، نه مسیر درجه‌دو پنهان.
4. نسخه و تغییر Vendor را مانیتور کنید.
5. Accessibility requirement و Evidence را در Procurement بیاورید.
6. اگر مانع Non-interference یا Journey بحرانی است، Replacement plan داشته باشید.

Severity را از Impact واقعی بسازید

سطح WCAG و Severity محصول یکی نیستند. یک Fail سطح A ممکن است در صفحه کم‌استفاده باشد و یک مانع سطح AA در پرداخت، درآمد و استقلال کاربر را قطع کند. مدل داخلی را با این ابعاد بسازید:

Priority = User impact × Task criticality × Reach × Recurrence × Confidence ÷ Fix effort

این فرمول یک مدل داخلی است، نه امتیاز W3C. Gateهای ایمنی، حقوقی یا Keyboard trap را با Effort پایین نیاورید.

Issue قابل اصلاح و Retest بنویسید

هر Issue باید به‌تنهایی برای بازتولید کافی باشد:

• ID، عنوان Barrierمحور و Severity؛
• URL، Template، Component، State و User role؛
• WCAG version/Success Criterion/Level؛
• OS، Browser، AT، Viewport و نسخه‌ها؛
• پیش‌شرط و Steps دقیق؛
• Actual result و Expected behavior؛
• اثر بر کاربر/Task و Workaround؛
• Screenshot، Video، DOM/Code یا Output ابزار؛
• پیشنهاد Fix در لایه درست، بدون نسخه کور؛
• Owner، Target release و وضعیت؛
• Retest date/build/result و Regression test.

عنوان خوب: «پس از خطای کدملی، Focus روی ابتدای صفحه می‌ماند و پیام برای Screen reader اعلام نمی‌شود». عنوان ضعیف: «فرم Accessible نیست».

ریشه را در Component و فرایند اصلاح کنید

اگر Button بدون Accessible name در ۴۰۰ صفحه تکرار شده، ۴۰۰ Patch محتوایی نسازید. Component، Documentation، Test و Migration را اصلاح کنید. ترتیب معمول Remediation:

1. Blockerهای Journey و Non-interference؛
2. Token/Componentهای پرتکرار؛
3. Template و Navigation سراسری؛
4. Form، Authentication و Status؛
5. محتوای پرترافیک/پرریسک؛
6. Long tail محتوا و فایل‌ها؛
7. Third-party replacement یا Alternative.

Fix را با همان محیط و Steps Retest کنید و سپس Cross-check روی نمونه‌های دیگر Component انجام دهید. تغییر ARIA بدون فهم ممکن است Regression بدتری بسازد؛ Native semantics و رفتار ساده معمولاً نقطه شروع بهتری است.

گزارش Audit چه بخش‌هایی داشته باشد؟

تعداد Failها را Ranking تیم‌ها نکنید. یک ابزار ممکن است یک Root cause را صد بار و ابزار دیگر یک‌بار بشمارد. روند Barrierهای بحرانی، Coverage، زمان رفع، نرخ Reopen و Regression برای مدیریت مفیدترند.

کاربران دارای معلولیت را منصفانه در ارزیابی مشارکت دهید

راهنمای WAI برای مشارکت کاربران تأکید می‌کند تست با کاربران، مسائل کاربردپذیری واقعی را آشکار می‌کند اما جای ارزیابی Conformance برای طیف وسیع معلولیت‌ها را نمی‌گیرد. از تجربه یک نفر به همه افراد تعمیم ندهید.

• Segment را براساس مخاطب، Task و شیوه تعامل انتخاب کنید؛ نه «یک فرد نابینا» به‌عنوان نماینده همه.
• فناوری، نسخه و مهارت شرکت‌کننده را ثبت کنید.
• Recruitment، Consent، ضبط، محرمانگی و حذف داده روشن باشند.
• جبران خدمت منصفانه و روش پرداخت در دسترس فراهم شود.
• محیط تست، Material و جلسه خودشان Accessible باشند.
• Barrier را به کاربر نسبت ندهید و راه‌حل را پیش از فهم مسئله تحمیل نکنید.

تست کاربر را پس از رفع Blockerهای شناخته‌شده انجام دهید تا وقت مشارکت‌کننده صرف خطاهای واضح نشود؛ سپس یافته‌ها را کنار WCAG audit و داده Support تحلیل کنید. چارچوب گسترده‌تر تحقیق و سنجش در راهنمای تجربه کاربری آمده است.

Regression را در Design system و CI ببندید

Audit یک‌باره پس از هر Release فرسوده می‌شود. کنترل‌ها را در نزدیک‌ترین لایه به خطا قرار دهید.

Automation فقط معیارهای قابل ماشین را Gate می‌کند؛ Passing CI برابر Conformance نیست. نمونه‌های Manual و AT را براساس Risk در Release calendar نگه دارید و با تغییر Framework، Design system یا Widget ثالث دوباره اجرا کنید.

ملاحظات عملی برای سایت فارسی و ایران

• RTL/Bidi را در تمام Componentها، نه فقط صفحه مقاله، تست کنید.
• کدملی، موبایل، پلاک، کارت، شبا، ریال/تومان و تاریخ با رقم فارسی/لاتین Requirement روشن داشته باشند.
• OTP، CAPTCHA، پیامک و درگاه را با Timeout، Paste، Error و بازگشت به سایت آزمایش کنید.
• Font فارسی در Zoom و وزن‌های مختلف خوانا بماند و Glyph ناقص نداشته باشد.
• Caption/Transcript فارسی، Code-switch و نام برند توسط انسان بازبینی شود.
• AT matrix را از کاربران واقعی خود بسازید؛ فرض محبوبیت یک Screen reader خارجی کافی نیست.
• تست Remote با اینترنت ناپایدار نباید خطای شبکه را به ناتوانی کاربر نسبت دهد.
• فرایند شکایت و پشتیبانی Alternative غیرصوتی/غیرMouse داشته باشد.
• الزام قراردادی یا حقوقی ایران/بازار مقصد را جدا از Audit فنی استعلام کنید.

Performance و Accessibility یکی نیستند، اما Script سنگین، Layout shift و Timeout می‌توانند استفاده را دشوار کنند. داده میدانی LCP/INP/CLS و شبکه/دستگاه را با راهنمای Core Web Vitals و RUM بسنجید.

برنامه ۳۰روزه ممیزی و اصلاح

چک‌لیست نهایی ممیزی دسترس‌پذیری

• هدف، Scope، WCAG ۲.۲، سطح و تاریخ Build مشخص‌اند.
• Template، Component، Journey، State، Media و Third party Inventory شده‌اند.
• Sample نماینده و Random با دلیل انتخاب ثبت شده‌اند.
• ابزار خودکار روی Stateهای پس از تعامل نیز اجرا شده است.
• نتیجه ابزار معادل Conformance یا درصد Accessibility معرفی نشده است.
• Keyboard، Focus، Zoom، Reflow، Contrast، Color و Motion دستی تست شده‌اند.
• Landmark، Heading، Link و Accessible name/Role/State بررسی شده‌اند.
• AT matrix نسخه، زبان، Browser، OS و تاریخ دارد.
• فارسی/RTL، Bidi، رقم، تلفن، کدملی، OTP و مبلغ تست شده‌اند.
• Form در حالت Error/Success و پرداخت End-to-end آزموده شده است.
• Image/Chart/Audio/Video/PDF Alternative متناسب دارند.
• Widget ثالث در Scope و دارای Alternative/SLA است.
• Severity از اثر کاربر و Task ساخته شده، نه فقط Level معیار.
• هر Issue Steps، Environment، Evidence، SC، Owner و Retest دارد.
• Root cause در Component/Template اصلاح و Cross-check شده است.
• کاربران دارای معلولیت با Consent و جبران منصفانه مشارکت کرده‌اند.
• Design system، CI، Release smoke و Production feedback Regression را پوشش می‌دهند.
• ادعای Conformance فقط با Scope، نسخه، سطح و Evidence دقیق منتشر می‌شود.

پرسش‌های متداول

آیا امتیاز ۱۰۰ Lighthouse یا ابزار Accessibility یعنی سایت مطابق WCAG است؟

خیر. ابزار فقط بخشی از معیارهای قابل ماشین را در Page/State آزموده‌شده بررسی می‌کند و ممکن است خطای مثبت یا منفی داشته باشد. Conformance به بررسی انسانی، صفحه و فرایند کامل، Scope و معیارهای نسخه/سطح مشخص نیاز دارد.

برای ممیزی دسترس‌پذیری چند صفحه را تست کنیم؟

عدد ثابت برای همه سایت‌ها وجود ندارد. Sample باید Templateها، Componentها، Journeyهای کامل، Stateها، فناوری‌ها و محتوای متنوع را نمایندگی کند و چند صفحه Random نیز داشته باشد. اندازه به تنوع، ریسک و Confidence موردنیاز بستگی دارد.

آیا تست با Screen reader به‌تنهایی کافی است؟

خیر. یک Screen reader/Browser همه فناوری‌های کمکی، معلولیت‌ها یا معیارهای WCAG را پوشش نمی‌دهد. آن را با Keyboard، Zoom/Reflow، Contrast، بررسی کد، ابزار خودکار و مشارکت کاربران دارای معلولیت ترکیب کنید.

تفاوت WCAG A، AA و AAA چیست؟

سطوح مجموعه معیارهای لازم را مشخص می‌کنند: AA شامل A و AA و AAA شامل هر سه است. Target رایج باید با نیاز حقوقی/قراردادی و مخاطب تعیین شود. W3C توصیه نمی‌کند AAA برای کل سایت سیاست عمومی اجباری باشد، هرچند برخی معیارهای AAA می‌توانند هدف محصول باشند.

اول کدام ایراد Accessibility را رفع کنیم؟

مانع‌های بدون Workaround در Journey حیاتی، Keyboard trap و موارد Non-interference را اول مهار کنید؛ سپس Root causeهای پرتکرار در Token/Component و Template، فرم و محتوا را اصلاح کنید. سطح WCAG را کنار اثر کاربر، Reach، تکرار و Task criticality بخوانید.

جمع‌بندی

ممیزی دسترس‌پذیری یک Snapshot قابل تکرار از Barrierهاست، نه Badge دائمی. Scope و استاندارد را روشن کنید، سایت را به Template/Component/Journey/State بشکنید، نمونه نماینده و تصادفی بسازید و Automation را با Keyboard، Manual، AT و کاربر واقعی ترکیب کنید.

ارزش Audit وقتی آزاد می‌شود که Issue بازتولیدپذیر، Severity کاربرمحور، Fix در لایه ریشه، Retest و Regression gate داشته باشد. برای وب فارسی، RTL، Bidi، اعداد، فرم هویتی، OTP، درگاه و زبان فناوری کمکی را صریحاً وارد ماتریس کنید؛ چیزی که تست نشده، نباید در ادعای انطباق پنهان شود.