چک‌لیست WCAG 2.2 AA برای محصولات SaaS و اپلیکیشن‌های وب
چک‌لیست WCAG 2.2 AA برای SaaS: ورود، فرم‌ها، دیالوگ‌ها، ناوبری تک‌صفحه‌ای، جدول‌ها، نمودارها، کشیدن و رها کردن، مهلت جلسه و ACR موردنیاز خریداران.
تیم تحریریه FixReports10 دقیقه مطالعه
یک محصول SaaS دو سطح دسترسپذیری دارد: سایت بازاریابی که آن را می‌فروشد و اپلیکیشنی که افراد هر روز از آن استفاده میکنند. سایت بازاریابی به همان شکل‌هایی خطا دارد که هر وب‌سایت دیگری: کنتراست پایین، نبود متن جایگزین و فرم‌های بدون برچسب. اپلیکیشن مشکلات خودش را هم اضافه میکند: فرایندهای ورود که جلوی مدیرهای رمز عبور را می‌گیرند، دیالوگ‌هایی که فوکوس صفحه‌کلید را به دام می‌اندازند، ناوبری اپلیکیشن تک‌صفحه‌ای که صفحه‌خوان‌ها متوجهش نمی‌شوند، جدول‌های داده و نمودارهای بدون متن، کشیدن و رها کردن بدون جایگزین، و جلساتی که بدون هشدار منقضی می‌شوند. این چک‌لیست WCAG 2.2 سطح AA را بر اساس بخش‌های یک محصول SaaS معمولی مرور میکند.
نکات کلیدی
- WCAG 2.2 در اکتبر 2023 به توصیه‌نامه W3C تبدیل شد و 9 معیار موفقیت اضافه کرد که 6 مورد از آن‌ها در سطح A یا AA هستند (W3C (در زبانه جدید باز می‌شود)).
- معیار Accessible Authentication (3.3.8، AA) یعنی ورود به حساب نباید به حفظ کردن یا رونویسی رمز عبور وابسته باشد، مگر اینکه افراد بتوانند آن را جای‌گذاری (paste) کنند یا از مدیر رمز عبور استفاده کنند (W3C (در زبانه جدید باز می‌شود)).
- اهداف تعاملی باید دست‌کم 24 در 24 پیکسل CSS باشند یا فضای کافی در اطرافشان داشته باشند (2.5.8، AA) (W3C (در زبانه جدید باز می‌شود)).
- پیام‌هایی مانند «ذخیره شد» یا «3 نتیجه» باید بدون جابه‌جا کردن فوکوس به صفحه‌خوان‌ها برسند (4.1.3، AA) (W3C (در زبانه جدید باز می‌شود)).
- خریداران تجاری و بخش دولتی اغلب گزارش انطباق دسترسپذیری (Accessibility Conformance Report) می‌خواهند که معمولاً بر اساس قالب VPAT شورای صنعت فناوری اطلاعات (ITI) نوشته می‌شود (ITI (در زبانه جدید باز می‌شود)).
چرا دسترسپذیری برای SaaS مهم‌تر از یک سایت معرفی است؟
افراد ساعت‌ها از یک محصول SaaS استفاده میکنند، اغلب چون کارفرمایشان آن را انتخاب کرده است. یک مانع در صفحه بازاریابی یک بازدیدکننده را از دست می‌دهد؛ یک مانع در محصول میتواند کسی را از انجام کارش بازدارد. به همین دلیل مشتریان بزرگ‌تر، دانشگاه‌ها و نهادهای عمومی پیش از خرید بیش از پیش درباره دسترسپذیری می‌پرسند، و به همین دلیل پاسخ باید اپلیکیشن را هم پوشش دهد، نه فقط وب‌سایت را.
این موضوع همچنین مهم است چون تست‌های خودکار فقط بخشی از مشکل را پیدا میکنند. ابزارهایی مانند axe-core خطاهای کد HTML، مانند نبود برچسب و کنتراست پایین، را پیدا میکنند. اما نمیتوانند بگویند یک دیالوگ فوکوس را به جای درست برمی‌گرداند یا نه، داده‌های یک نمودار به‌صورت متن در دسترس است یا نه، یا یک گردش کار را می‌توان با صفحه‌کلید تکمیل کرد یا نه. یک اپلیکیشن هم به بررسی‌های خودکار نیاز دارد و هم به تست دستی.
چگونه ثبت‌نام و ورود را دسترسپذیر کنیم؟
احراز هویت جایی است که WCAG 2.2 مهم‌ترین الزام جدید را برای SaaS اضافه کرده است.
- اجازه جای‌گذاری و استفاده از مدیر رمز عبور را بدهید (3.3.8، AA). جلوی جای‌گذاری (paste) در فیلدهای رمز عبور یا کد را نگیرید، و از
autocomplete="username"،autocomplete="current-password"وautocomplete="one-time-code"استفاده کنید تا مرورگرها و مدیرهای رمز عبور بتوانند آن‌ها را پر کنند. - از معما به‌عنوان تنها راه ورود پرهیز کنید. CAPTCHAای که از افراد می‌خواهد متن مخدوش را رونویسی کنند یا معمایی را حل کنند، یک آزمون کارکرد شناختی است. یک جایگزین ارائه دهید و بررسی‌هایی را ترجیح دهید که به اقدام کاربر نیاز ندارند (W3C (در زبانه جدید باز می‌شود)).
- برای هر فیلد برچسب بگذارید (1.3.1 و 3.3.2، A). از یک
<label>قابل مشاهده که به فیلد ورودی متصل است استفاده کنید؛ متن placeholder با شروع تایپ ناپدید می‌شود و برچسب نیست. - خطاها را با متن مشخص کنید (3.3.1، A) و راه اصلاح پیشنهاد دهید (3.3.3، AA). «رمز عبور باید دست‌کم 12 کاراکتر داشته باشد» کمک میکند؛ یک حاشیه قرمز به‌تنهایی نه.
- دو بار نپرسید (3.3.7، A). اگر یک ثبت‌نام چندمرحله‌ای قبلاً نام شرکت یا آدرس را پرسیده، آن را خودکار پر کنید یا اجازه دهید افراد آن را انتخاب کنند، به‌جای اینکه دوباره تایپ کنند.
- راهنما را در همان جا نگه دارید (3.2.6، A). اگر چت، لینک راهنما یا اطلاعات تماس ارائه می‌دهید، آن‌ها را در همان موقعیت نسبی در همه صفحات فرایند قرار دهید.
کدام الگوهای فرم و خطا بیشترین خطاها را ایجاد میکنند؟
بیشتر خطاهای اپلیکیشن‌ها در فرم‌ها هستند. بررسی WebAIM در سال 2026 از یک میلیون صفحه اصلی، نبود برچسب فرم را در 51% آن‌ها پیدا کرد (WebAIM (در زبانه جدید باز می‌شود))، و اپلیکیشن‌ها فرم‌های بسیار بیشتری از صفحات اصلی دارند.
- به هر فیلد ورودی یک نام برنامه‌نویسی‌شده (programmatic name) بدهید و کنترل‌های مرتبط، مانند دکمه‌های رادیویی، را با
<fieldset>و<legend>گروه‌بندی کنید. - خطاها را جایی اعلام کنید که افراد متوجهشان شوند: فوکوس را به خلاصه خطاها در بالای فرم، یا به اولین فیلد نامعتبر ببرید، و هر مورد خلاصه را به فیلد مربوطش لینک دهید.
- فیلدهای الزامی را با متن مشخص کنید، نه فقط با رنگ (1.4.1، A).
- وقتی کسی فقط یک گزینه را انتخاب میکند، فرم را ارسال نکنید یا زمینه را تغییر ندهید (3.2.2، A)؛ منتظر یک اقدام صریح بمانید.
دیالوگ‌ها، منوها و پاپ‌اورها چگونه باید رفتار کنند؟
کامپوننتهای سفارشی جایی هستند که پشتیبانی از صفحه‌کلید و صفحه‌خوان بیش از همه از کار می‌افتد. راهنمای WAI-ARIA Authoring Practices Guide رفتار مورد انتظار هر الگو را توضیح می‌دهد (W3C (در زبانه جدید باز می‌شود)).
- دیالوگ‌ها: وقتی دیالوگ باز می‌شود فوکوس را به داخل آن ببرید، تا وقتی باز است Tab را درون آن نگه دارید، با Escape آن را ببندید و فوکوس را به کنترلی که آن را باز کرده برگردانید. از عنصر بومی
<dialog>یاrole="dialog"همراه باaria-modal="true"و یک نام استفاده کنید. - بدون تله صفحه‌کلید (2.1.2، A): باید بتوان با صفحه‌کلید از هر کامپوننت خارج شد.
- فوکوس قابل مشاهده (2.4.7، AA) که پشت هدرهای چسبان، بنرهای کوکی یا ابزارک‌های چت پنهان نشود (2.4.11، AA، جدید در 2.2).
- تولتیپ‌ها و پاپ‌اورها (1.4.13، AA) که افراد بتوانند با Escape آن‌ها را ببندند، نشانگر را بدون ناپدید شدنشان روی آن‌ها ببرند، و تا زمان بسته شدن باقی بمانند.
- میان‌برهای تک‌کلیدی (2.1.4، A): اگر فشردن یک کلید حرف عملی را اجرا میکند، به افراد اجازه دهید میان‌برها را خاموش یا دوباره تعریف کنند، یا آن‌ها را فقط وقتی فعال کنید که کامپوننت مربوط فوکوس دارد.
ناوبری در اپلیکیشن تک‌صفحه‌ای را چگونه مدیریت کنیم؟
در یک اپلیکیشن تک‌صفحه‌ای (single-page app)، URL بدون بارگذاری صفحه تغییر میکند، بنابراین ممکن است صفحه‌خوان‌ها اعلام نکنند که اتفاقی افتاده است.
- با هر تغییر مسیر، عنوان سند را به‌روز کنید تا هر نما عنوان توصیفی داشته باشد (2.4.2، A).
- فوکوس را به سرتیتر اصلی نمای جدید ببرید، یا تغییر را در یک ناحیه زنده مؤدبانه (polite live region) اعلام کنید؛ فریم‌ورک‌هایی مانند Next.js برای این کار یک route announcer دارند.
- ترتیب منطقی فوکوس را حفظ کنید (2.4.3، A): پس از حذف یک مورد، فوکوس باید به یک مورد مجاور معقول برود، نه اینکه به بالای صفحه برگردد.
- راهی برای رد شدن از ناوبری تکراری فراهم کنید (2.4.1، A)، مانند یک لینک پرش یا نشانه‌های ساختاری (landmarks).
چگونه داشبوردها، جدول‌های داده و نمودارها را دسترسپذیر کنیم؟
- جدول‌ها: از نشانه‌گذاری واقعی
<table>با<th>وscopeبرای سرستون‌ها و یک عنوان (caption) استفاده کنید (1.3.1، A). شبکه‌هایی که از عناصر<div>ساخته شده‌اند به الگوی کامل ARIA grid نیاز دارند که درست پیاده کردنش بسیار دشوارتر است. - نمودارها: به هر نمودار یک جایگزین متنی بدهید که نکته اصلی را بیان کند، و داده‌ها را به‌صورت جدول ارائه دهید (1.1.1، A). برای تمایز سری‌ها فقط به رنگ تکیه نکنید (1.4.1، A)؛ برچسب یا الگو اضافه کنید.
- کنتراست: متن به 4.5:1 نیاز دارد (1.4.3، AA)، و خطوط نمودار، آیکون‌ها و حاشیه فیلدهای ورودی به 3:1 در برابر پس‌زمینه‌شان (1.4.11، AA). حالت تیره را جداگانه بررسی کنید. ابزار بررسی کنتراست رنگ ما هر جفت‌رنگی را تست میکند.
- پیامهای وضعیت (4.1.3، AA): «ذخیره شد»، «آپلود کامل شد» و تعداد نتایج باید از
role="status"یا یک ناحیه زنده استفاده کنند تا کاربران صفحه‌خوان بدون گم کردن جای خود آن‌ها را بشنوند.
معیارهای جدید WCAG 2.2 چه چیزی را در اپلیکیشن‌های وب تغییر می‌دهند؟
| معیار | سطح | معنای آن در یک اپلیکیشن |
|---|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | AA | نوار ابزارهای چسبان، بنرها و ابزارک‌های چت نباید عنصر دارای فوکوس را کاملاً بپوشانند |
| 2.5.7 Dragging Movements | AA | هر کاری که با کشیدن انجام می‌شود، مانند مرتب‌سازی دوباره یک بورد kanban، به یک جایگزین تک‌اشاره‌گر نیاز دارد، مثلاً یک منو یا دکمه‌های بالا و پایین |
| 2.5.8 Target Size (Minimum) | AA | دکمه‌ها و لینک‌ها دست‌کم 24 × 24 پیکسل CSS، یا با فاصله‌ای که دایره‌ای 24 پیکسلی دور هر کدام با دیگری هم‌پوشانی نداشته باشد |
| 3.2.6 Consistent Help | A | لینک‌های راهنما، چت و اطلاعات تماس در همان موقعیت نسبی در همه صفحات |
| 3.3.7 Redundant Entry | A | اطلاعاتی که قبلاً در همان فرایند وارد شده، خودکار پر می‌شود یا قابل انتخاب است |
| 3.3.8 Accessible Authentication (Minimum) | AA | ورود بدون حفظ کردن یا رونویسی، مگر اینکه جای‌گذاری، مدیر رمز عبور یا روش دیگری مجاز باشد |
WCAG 2.2 همچنین 4.1.1 Parsing را حذف کرد که دیگر اثر عملی بر دسترسپذیری ندارد (W3C (در زبانه جدید باز می‌شود)).
مهلت جلسه، چیدمان و بزرگ‌نمایی چه؟
- مهلت جلسه (2.2.1، A): پیش از منقضی شدن جلسه به افراد هشدار دهید و اجازه دهید با یک اقدام ساده آن را تمدید کنند، مگر اینکه محدودیت زمانی ضروری یا بیش از 20 ساعت باشد. ذخیره کار در حال انجام از بدترین نتیجه جلوگیری میکند.
- Reflow (1.4.10، AA): محتوا باید در عرض 320 پیکسل CSS (معادل بزرگ‌نمایی 400% روی صفحه‌ای با عرض 1280 پیکسل) بدون پیمایش در دو جهت کار کند؛ جدول‌های داده و محتوای مشابه مستثنا هستند.
- فاصله‌گذاری متن (1.4.12، AA): افزایش ارتفاع خط و فاصله حروف نباید باعث بریده شدن متن شود، اتفاقی که در ظرف‌های با ارتفاع ثابت زیاد رخ می‌دهد.
- جهت صفحه (1.3.4، AA): اپلیکیشن را به حالت عمودی یا افقی قفل نکنید، مگر اینکه ضروری باشد.
ACR چیست و آیا به آن نیاز دارید؟
گزارش انطباق دسترسپذیری (Accessibility Conformance Report یا ACR) مستند میکند که یک محصول هر معیار دسترسپذیری را چگونه برآورده میکند: پشتیبانی میکند، تا حدی پشتیبانی میکند یا پشتیبانی نمیکند، همراه با توضیحات. بیشتر این گزارش‌ها بر اساس قالب VPAT نوشته می‌شوند که شورای صنعت فناوری اطلاعات (ITI) منتشر میکند و ویرایش‌هایی برای WCAG، استانداردهای Section 508 آمریکا و استاندارد اروپایی EN 301 549 دارد (ITI (در زبانه جدید باز می‌شود)).
آژانس‌های فدرال آمریکا بر اساس Section 508 موظف به خرید فناوری دسترس‌پذیرند (Section508.gov (در زبانه جدید باز می‌شود))، و نهادهای عمومی اتحادیه اروپا به EN 301 549 ارجاع می‌دهند، بنابراین از محصولات B2B که به این مشتریان می‌فروشند اغلب در فرایند خرید ACR خواسته می‌شود. یک ACR صادقانه، که کاستی‌های شناخته‌شده را فهرست میکند، برای خریداران مفیدتر از گزارشی است که ادعای پشتیبانی کامل دارد. این گزارش باید بر اساس تست محصول، از جمله تست دستی، تهیه شود؛ یک اسکن خودکار به‌تنهایی نمی‌تواند آن را پر کند.
اگر به مصرف‌کنندگان در اتحادیه اروپا می‌فروشید، ممکن است قانون دسترسپذیری اروپا هم بر نحوه فروش آنلاین شما اعمال شود؛ راهنمای EAA ما دامنه آن را توضیح می‌دهد. این مشاوره حقوقی نیست.
یک تیم SaaS چگونه باید دسترسپذیری را تست کند؟
- موارد پایه را خودکار کنید. axe-core یا موتوری مشابه را در تست‌های end-to-end و روی سایت بازاریابی اجرا کنید و در صورت بروز تخلف جدید، build را ناموفق کنید. ابزار رایگان بررسی دسترسپذیری ما همین موتور را روی هر صفحه عمومی اجرا میکند.
- با صفحه‌کلید تست کنید. گردش‌کارهای اصلی خود، مانند ثبت‌نام، ایجاد یک رکورد و تغییر تنظیمات، را فقط با Tab، Shift+Tab، Enter، Space، Escape و کلیدهای جهت‌نما کامل کنید.
- با صفحه‌خوان تست کنید. NVDA روی Windows و VoiceOver روی macOS و iOS رایگان هستند. بررسی کنید که نام‌ها، نقش‌ها، وضعیت‌ها و پیام‌ها اعلام می‌شوند.
- بزرگ‌نمایی و تغییر اندازه را بررسی کنید. بزرگ‌نمایی متن 200% و پنجره‌ای با عرض 320 پیکسل را امتحان کنید.
- در سیستم طراحی اصلاح کنید. بیشتر خطاها از کامپوننتهای مشترک می‌آیند؛ اصلاح یک دکمه یا دیالوگ در یک جا، آن را همه جا اصلاح میکند.
پرسش‌های متداول
آیا WCAG برای بخش‌هایی از اپلیکیشن وب که نیاز به ورود دارند هم اعمال می‌شود؟
WCAG برای هر محتوای وب، از جمله صفحات پشت ورود به حساب، اعمال می‌شود. اینکه قانونی یک محصول خاص را به رعایت آن ملزم کند یا نه به حوزه قضایی و مشتری بستگی دارد، اما خریدارانی که درباره دسترسپذیری می‌پرسند معمولاً کل محصول را در نظر دارند.
آیا یک ابزار اورلی میتواند محصول SaaS را دسترسپذیر کند؟
خیر. اورلیها کد زیربنایی کامپوننتهای سفارشی را تغییر نمیدهند، و خطاهای اپلیکیشن دقیقاً همانجاست. راهنمای ما درباره ابزارهای اورلی دسترسپذیری اقدام FTC علیه یکی از فروشندگان پیشرو اورلی را بررسی میکند.
ابزارهای خودکار چه مقدار از WCAG را میتوانند بررسی کنند؟
فقط بخشی از آن را. قواعد خودکار بهطور قابلاعتماد نبود نام، برچسب و خطاهای کنتراست را پیدا میکنند، اما بسیاری از معیارها، مانند ترتیب معنادار فوکوس، متن جایگزین مفید و پیامهای خطای قابلفهم، به قضاوت انسان نیاز دارند.
کدام نسخه WCAG را باید هدف بگیریم؟
WCAG 2.2 سطح AA نسخه فعلی است. بسیاری از قوانین و مقررات خرید هنوز به WCAG 2.1 AA ارجاع می‌دهند؛ رعایت 2.2 AA، به‌جز معیار حذف‌شده Parsing، 2.1 AA را هم پوشش می‌دهد.
آیا باید سطح AAA را رعایت کنیم؟
W3C الزام AAA را برای کل محصولات توصیه نمیکند، چون برخی محتواها نمیتوانند همه معیارهای AAA را برآورده کنند. سطح AA هدف معمول است.
منابع
- W3C: موارد جدید در WCAG 2.2 (در زبانه جدید باز می‌شود)
- W3C: رهنمودهای دسترسپذیری محتوای وب (WCAG) 2.2 (در زبانه جدید باز می‌شود)
- W3C: توضیح معیار 3.3.8 Accessible Authentication (Minimum) (در زبانه جدید باز می‌شود)
- W3C: توضیح معیار 2.5.8 Target Size (Minimum) (در زبانه جدید باز می‌شود)
- W3C: توضیح معیار 4.1.3 Status Messages (در زبانه جدید باز می‌شود)
- W3C: ARIA Authoring Practices Guide: الگوی دیالوگ (مودال) (در زبانه جدید باز می‌شود)
- W3C: دسترس‌ناپذیری CAPTCHA (Inaccessibility of CAPTCHA) (در زبانه جدید باز می‌شود)
- ITI: قالب داوطلبانه دسترسپذیری محصول (VPAT) (در زبانه جدید باز می‌شود)
- GSA: Section508.gov (در زبانه جدید باز می‌شود)
- WebAIM: The WebAIM Million (2026) (در زبانه جدید باز می‌شود)
همه راهنماها
- آیا اصلاح وب‌سایت ارزشش را دارد؟ آنچه مطالعات منتشرشده درباره سرعت، سئو و دسترسپذیری نشان میدهندتستهای A/B و مطالعات منتشرشده پس از بهبود سرعت، داده‌های ساختاریافته و دسترسپذیری چه چیزی را سنجیدند و چگونه اثرش را در فروشگاه خود تخمین بزنید و بسنجید.
- چک‌لیست دسترسپذیری برای وب‌سایت شرکتها: صفحات استخدام، فایلهای PDF، صفحات سرمایهگذاران و فرمهاچکلیست دسترسپذیری وب‌سایت شرکتها: ناوبری، صفحات استخدام و درخواست شغل، فایلهای PDF و گزارش سالانه، ویدیو، فرم‌ها، بنر کوکی و بیانیه دسترسپذیری.
- چک‌لیست سئو تکنیکال برای وبسایتهای SaaSسئو تکنیکال برای SaaS: دور نگه داشتن اپلیکیشن از جستوجو، رندر برای خزندهها، مستندات و تغییرنامهها، کنونیکال، داده ساختاریافته، سرعت و خزندههای AI.