چکلیست دسترسپذیری وب: WCAG 2.2 برای طراحان حرفهای
یک چکلیست دسترسپذیری WCAG 2.2 که بر اساس مکان انجام کار سازماندهی شده: Figma، مرورگر، بعد از انتشار. به علاوه نقشه اشتباهات طراحان به معیارها.
بیشتر چکلیستهای دسترسپذیری وب برای طراحان بیفایدهاند. آنها بر اساس شماره معیار موفقیت WCAG سازماندهی شدهاند، که شیوهای است که یک وکیل مشخصات را میخواند و هیچکس اینطور نرمافزار نمیسازد.
طراحان Figma را با فکر کردن به معیار 1.4.3 باز نمیکنند. آنها Figma را باز میکنند و یک رنگ متن انتخاب میکنند. چکلیست مفید طراح را در جایی که تصمیم گرفته میشود ملاقات میکند، که به معنای سه لیست جداگانه است: یکی برای فایل طراحی، یکی برای مرورگر، یکی برای بعد از راهاندازی. هر روش دیگری سازماندهی کنید و از آن صرفنظر میشود.
WCAG 2.2 واقعاً چه الزاماتی دارد
WCAG 2.2 استاندارد جهانی فعلی از سال 2026 است و نه معیار موفقیت جدید به WCAG 2.1 اضافه میکند که بیشتر بر موبایل، اهداف لمسی، بار شناختی و احراز هویت متمرکز است.
نه معیار جدیدی که برای طراحان مهم هستند یک لیست کوتاه است. ظاهر فوکوس سختگیرانهتر میشود (2.4.11، 2.4.13). حرکات کشیدن اکنون نیاز به یک جایگزین بدون کشیدن دارند (2.5.7). اهداف لمسی حداقل اندازه 24 در 24 CSS pixel دارند مگر اینکه هدف فضای کافی اطراف آن داشته باشد (2.5.8). قرارگیری ثابت راهنما در صفحات الزامی است (3.2.6). فرمها نمیتوانند بدون دلیل همان اطلاعات را دوبار بخواهند (3.3.7). احراز هویت نمیتواند بدون یک جایگزین بر یک آزمون شناختی مانند به یاد آوردن رمز عبور متکی باشد (3.3.8، 3.3.9).
AA سطحی است که توسط بیشتر قوانین دسترسپذیری در سطح جهانی الزامی است، از جمله قانون دسترسپذیری اروپایی اتحادیه اروپا، بخش 508 در ایالات متحده، و مقررات دسترسپذیری بدنههای بخش عمومی انگلستان. AAA سختگیرانهتر است و بیشتر برای دولت، مراقبتهای بهداشتی و آموزش رزرو شده است.
یک چکلیست سازمانیافته بر اساس شمارههای بخش WCAG یک مشخصات است. یک چکلیست سازمانیافته بر اساس جایی که کار اتفاق میافتد یک ابزار است.
تنها فرمت چکلیستی که کار میکند
سه جایی وجود دارد که دسترسپذیری در آن تصمیمگیری میشود. فایل طراحی. رابط ساختهشده در مرورگر. سایت تولید بعد از راهاندازی.
تقریباً 70٪ از خرابیهای دسترسپذیری تصمیماتی هستند که در Figma گرفته میشوند، 20٪ در پیادهسازی گرفته میشوند، و 10٪ بعد از راهاندازی از طریق تغییرات محتوا، جاسازیهای شخص ثالث، یا مواد تولید شده توسط کاربر نشت میکنند. هر چکلیستی که به این سه مرحله نگاشت نشده باشد طراح را مجبور میکند از زبان مشخصات به زبان جریان کار ترجمه کند، و این ترجمه جایی است که موارد نادیده گرفته میشوند.
بقیه این مقاله سه لیست است، به ترتیب. آنها را به ترتیب اجرا کنید. هر چیزی که بررسی مرحله طراحی را رد نمیکند هرگز نباید به مرحله ساخت برسد. هر چیزی که مرحله ساخت را رد نمیکند هرگز نباید ارسال شود.
چکلیست مرحله طراحی (آنچه در Figma بررسی میکنید)
تقریباً 70٪ از خرابیهای دسترسپذیری تصمیماتی هستند که در فایل طراحی گرفته میشوند، که به این معنی است که ارزانترین مکان برای رفع آنها نیز همانجاست.
| بررسی | معیار WCAG 2.2 | نحوه تأیید در Figma |
|---|---|---|
| متن بدنه به کنتراست 4.5:1 در برابر پسزمینهاش میرسد | 1.4.3 کنتراست (حداقل) | Stark، Able، یا بررسیکننده کنتراست داخلی Figma |
| متن بزرگ (18pt+ یا 14pt+ bold) به 3:1 میرسد | 1.4.3 | همان ابزارها |
| عناصر UI غیرمتنی (دکمهها، حاشیهها، آیکونها، حلقههای فوکوس) به 3:1 میرسند | 1.4.11 کنتراست غیرمتنی | به صورت دستی جفت رنگها را روی بوم نمونهبرداری کنید |
| اهداف لمسی حداقل 24 در 24 CSS px هستند (48 در 48 توصیه میشود) | 2.5.8 اندازه هدف (حداقل) | ابعاد فریم را مستقیماً اندازهگیری کنید |
| اطلاعات تنها با رنگ منتقل نمیشوند | 1.4.1 استفاده از رنگ | فریم را به مقیاس خاکستری تبدیل کنید (پلاگین Figma یا فیلتر اسکرینشات) |
| هر فریم تصویر دارای متن جایگزین در متادیتای لایه است | 1.1.1 محتوای غیرمتنی | پنل دسترسپذیری Figma یا حالت dev |
| عناوین در ترتیب منطقی استفاده میشوند (H1، H2، H3، نه H1، H3، H2) | 1.3.1 اطلاعات و روابط | درخت عنوان را از بالا به پایین بخوانید |
| حالت فوکوس برای هر عنصر تعاملی طراحی شده است | 2.4.7 فوکوس قابل مشاهده، 2.4.11 فوکوس پنهان نشده | هر کامپوننت تعاملی یک نسخه فوکوس دارد |
| متن لینک خارج از بستر معنی دارد | 2.4.4 هدف لینک | بدون برچسب "اینجا کلیک کنید" یا "بیشتر بدانید" |
| برچسبهای فرم قابل مشاهده هستند، نه فقط placeholder | 3.3.2 برچسبها یا دستورالعملها | هر فیلد یک برچسب دائمی خارج از ورودی دارد |
فایل طراحی همچنین جایی است که معیارهای موبایل جدید WCAG 2.2 را میگیرید. اهداف ضربهای که 2.5.8 را رد نمیکنند تقریباً همیشه به این دلیل است که طراح در pixelهای دسکتاپ فکر میکرد و هدف یک آیکون 16 pixel بدون padding است.
برای بررسی عمیقتر کنتراست بهخصوص، به قوانین کنتراست و APCA مراجعه کنید. کار رنگ در مرحله طراحی جایی است که بیشتر سایتها قبل از نوشتن یک خط کد ممیزی را از دست میدهند.
چکلیست مرحله ساخت (آنچه در مرورگر بررسی میکنید)
مرورگر جایی است که تصمیمات دسترسپذیری اثبات یا آشکار میشوند، زیرا اولین جایی است که فناوری کمکی واقعی با کار شما تماس پیدا میکند.
| بررسی | معیار WCAG 2.2 | نحوه تأیید در مرورگر |
|---|---|---|
| هر صفحهای فقط با صفحهکلید کار میکند (tab، shift-tab، enter، space، کلیدهای جهتنما) | 2.1.1 صفحهکلید | موس را جدا کنید و در صفحه پیمایش کنید |
| ترتیب فوکوس از ترتیب بصری پیروی میکند (چپ به راست، بالا به پایین در LTR) | 2.4.3 ترتیب فوکوس | با Tab بروید و حلقه فوکوس را تماشا کنید |
| فوکوس هرگز توسط هدرهای چسبنده، بنرهای کوکی، یا مودالها پنهان نمیشود | 2.4.11 فوکوس پنهان نشده (حداقل) | هنگام Tab کردن اسکرول کنید تا دیده شدن را تأیید کنید |
| تعاملات کشیدن یک جایگزین کلیک یا ضربه دارند | 2.5.7 حرکات کشیدن | نوارهای لغزنده، لیستهای قابل مرتبسازی، کاروسلها را بررسی کنید |
| لینک رفتن به محتوا در اولین Tab ظاهر میشود | 2.4.1 دور زدن بلوکها | یک بار Tab در بارگذاری صفحه |
| نشانههای HTML استفاده میشوند (header، nav، main، footer، aside) | 1.3.1، 4.1.2 | طرح DOM را بررسی کنید |
| خطاهای فرم اعلام میشوند، نه فقط با رنگکدگذاری | 3.3.1، 3.3.3، 4.1.3 | یک فرم خراب را با یک screen reader ارسال کنید |
| Screen reader عناوین، لیستها و دکمهها را به درستی اعلام میکند | 4.1.2 نام، نقش، مقدار | NVDA در Windows، VoiceOver در Mac، TalkBack در Android |
| ویژگیهای تکمیل خودکار روی فیلدهای داده شخصی تنظیم شدهاند | 1.3.5 شناسایی هدف ورودی | autocomplete را روی فیلدهای نام، ایمیل، آدرس بررسی کنید |
| رسانه دارای زیرنویس، رونوشت، یا توضیحات صوتی است | 1.2.1 تا 1.2.5 | هر ویدیو را پخش کنید، tracks را بررسی کنید |
ابزارهای خودکار حدود 30٪ از این موارد را میگیرند. بقیه نیاز به یک انسان دارند که Tab را فشار دهد و به یک screen reader گوش دهد. هر دو مهم هستند و هیچکدام جایگزین دیگری نمیشوند.
بهترین مجموعه ابزار مرحله مرورگر در 2026 کوچک است: axe DevTools برای اسکن خودکار، Lighthouse برای ممیزیهای سطح صفحه، و یک screen reader واقعی برای پاس دستی. سه ابزار، ده دقیقه در هر صفحه، تقریباً هر چیزی را که یک ممیزی واقعی علامت میزند میگیرد.
چکلیست بعد از ارسال (آنچه در محیط تولید بررسی میکنید)
دسترسپذیری با راهاندازی تمام نمیشود، زیرا محتوا، جاسازیهای شخص ثالث، و مواد تولید شده توسط کاربر همه بعد از تأیید طراح ارسال میشوند.
| بررسی | معیار WCAG 2.2 | نحوه تأیید در محیط تولید |
|---|---|---|
| تصاویر نوشتهشده توسط CMS دارای متن جایگزین اجباری در سطح ویرایشگر هستند | 1.1.1 | CMS را آزمایش کنید: آیا یک نویسنده میتواند بدون alt منتشر کند؟ |
| ویجتهای شخص ثالث جاسازی شده (چت، نقشه، فرم) قابل دسترس هستند | متغیر | axe را روی صفحات با جاسازیها اجرا کنید |
| دانلودهای PDF و اسناد دارای تگ و قابل خواندن هستند | 1.1.1، 1.3.1، 2.4.6 | در بررسیکننده دسترسپذیری Acrobat باز کنید |
| لینکهای کمک، پشتیبانی و تماس در همان مکان در هر صفحه هستند | 3.2.6 کمک ثابت (جدید در WCAG 2.2) | ممیزی بصری در قالبها |
| فرمها در یک جریان اطلاعات اضافی و تکراری نمیخواهند | 3.3.7 ورودی اضافی (جدید در WCAG 2.2) | از طریق فرمهای چند مرحلهای قدم بزنید |
| احراز هویت یک جایگزین قابل دسترس دارد (passkeys، لینک ایمیل، SSO) | 3.3.8، 3.3.9 احراز هویت قابل دسترس (جدید در WCAG 2.2) | ثبتنام و ورود را با مسدود کردن password manager امتحان کنید |
| محتوای پویا (مودالها، toastها، مناطق زنده) اعلام میشود | 4.1.3 پیامهای وضعیت | هر کدام را با یک screen reader باز اجرا کنید |
| صفحه بعد از بزرگنمایی کاربر به 200٪ همچنان قوانین کنتراست و اندازه هدف را رعایت میکند | 1.4.4 تغییر اندازه متن، 1.4.10 Reflow | مرورگر را به 200٪ بزرگ کنید و بررسی کنید |
| رسانه با پخش خودکار وجود ندارد، یا رسانه دارای کنترل مکث است | 1.4.2 کنترل صدا، 2.2.2 مکث، توقف، پنهان کردن | صفحه را سرد بارگذاری کنید |
| بنر کوکی فوکوس صفحهکلید را به دام نمیاندازد | 2.1.2 بدون تله صفحهکلید | Tab را در بنر وارد کنید، Tab را برگردانید |
لیست بعد از ارسال جایی است که بیشتر تیمها شکست میخورند. طراحی به شکل قابل دسترس ارسال شد. نویسندگان CMS آن را با PDFهای بدون تگ، ویدیوهای با پخش خودکار، و یک ویجت چت با نسبت کنتراست 2:1 روی launcher پر میکنند. دسترسپذیری یک ویژگی سیستم است، نه یک نقطه عطف راهاندازی.
اشتباهات رایج طراح نگاشتشده به معیارهای WCAG
هر یافته ممیزی دسترسپذیری به یک معیار موفقیت WCAG خاص برمیگردد، و بیشتر طراحان همان پنج اشتباه را در برابر همان پنج معیار مرتکب میشوند.
| اشتباه طراح | واقعاً چیست | معیار WCAG 2.2 که نقض میکند |
|---|---|---|
| متن placeholder به عنوان تنها برچسب | کاربران برچسب را در لحظهای که شروع به تایپ میکنند از دست میدهند | 3.3.2 برچسبها یا دستورالعملها |
| دکمههای فقط آیکون بدون aria-label یا tooltip | Screen readerها "button" را بدون هدف اعلام میکنند | 4.1.2 نام، نقش، مقدار |
| پیامهای خطا فقط با حاشیه قرمز یا متن قرمز نشان داده میشوند | کاربران دارای کوررنگی هیچ خطایی نمیبینند | 1.4.1 استفاده از رنگ، 3.3.1 شناسایی خطا |
| حلقه فوکوس به خاطر زیباییشناسی حذف شده | کاربران صفحهکلید نمیتوانند ببینند کجا هستند | 2.4.7 فوکوس قابل مشاهده |
| اهداف ضربهای زیر 24 در 24 px بدون فاصله | کاربران موبایل دائماً اشتباه ضربه میزنند | 2.5.8 اندازه هدف (حداقل) |
| کنتراست پایین در UI "ظریف" (متن placeholder، حالتهای غیرفعال، متن کمکی) | خوانندگان در آفتاب یا با کاهش بینایی نمیتوانند آن را بخوانند | 1.4.3 کنتراست (حداقل)، 1.4.11 کنتراست غیرمتنی |
| مودالی که فوکوس را به دام میاندازد اما بستن با ESC ندارد | کاربران صفحهکلید در مودال گیر میکنند | 2.1.2 بدون تله صفحهکلید |
| کاروسلهایی با پیمایش فقط از طریق کشیدن | کاربران دارای اختلال حرکتی نمیتوانند پیشرفت کنند | 2.5.7 حرکات کشیدن |
| هدر چسبنده که عنصر فوکوس را هنگام Tab پنهان میکند | کاربران میبینند صفحه اسکرول میشود اما موقعیت خود را گم میکنند | 2.4.11 فوکوس پنهان نشده |
| ورود فقط با رمز عبور، بدون SSO یا لینک ایمیل | شکست بار شناختی | 3.3.8 احراز هویت قابل دسترس |
همان ده اشتباه اکثریت هر گزارش ممیزی را تشکیل میدهند. اینها را رفع کنید و قبل از اینکه هر مشاوری یک صفحهگسترده باز کند، 80٪ راه به WCAG 2.2 AA رسیدهاید.
مبانی دسترسپذیری همچنین به بقیه سلسلهمراتب بصری خوب متصل میشوند. کنتراست، اندازه هدف، و حالتهای فوکوس تصمیمات سلسلهمراتب هستند. طراحی که سلسلهمراتب را درست انجام میدهد بیشتر چکلیست دسترسپذیری را بهطور پیشفرض درست انجام میدهد، که دلیل همپوشانی تقریباً کامل بین نظریه رنگ خوب و طراحی قابل دسترس است.
نحوه اجرای چکلیست بدون سوختن یک هفته
چکلیست تنها زمانی مفید است که اجرای آن دقیقه طول بکشد، نه روزها، که به این معنی است که ابزارها باید بیشتر کار را انجام دهند.
ریتم کاری سه پاس است، یک پاس در هر مرحله، هر کدام در لحظهای که کار به آن مرحله میرسد انجام میشود. نه هر سه در پایان. نه یکی از آنها در پایان. سه پاس جداگانه، هر کدام ارزان، هر کدام تا جایی که ممکن است توسط ابزار اجرا میشود.
- پاس طراحی: 10 دقیقه در هر صفحه. Stark یا بررسیکننده کنتراست Figma روی هر جفت متن، فریم را به مقیاس خاکستری تبدیل کنید تا اطلاعات فقط رنگ را آزمایش کنید، هر هدف ضربهای را اندازهگیری کنید. قبل از تحویل انجام دهید، نه در حین بررسی.
- پاس ساخت: 10 دقیقه در هر قالب. اسکن axe DevTools، آزمایش پیمایش فقط صفحهکلید، یک پاس screen reader روی پربازدیدترین صفحات. axe-core را در CI ادغام کنید تا کد جدید نتواند با رگرسیونها ادغام شود.
- پاس ارسال: ماهانه، نه در هر انتشار. خزش axe یا pa11y کاملسایت روی محیط تولید، ممیزی PDF روی هر کتابخانه اسناد، پیمایش دستی فرمها و جریانهای احراز هویت.
این نیمروز کار در ماه در هر محصول است و شاید 15 دقیقه در هر تحویل طراحی. هر چیزی بیشتر از آن و تیم از اجرای آن دست میکشد. هر چیزی کمتر و ممیزیها بدون رفع برمیگردند.
سوالات متداول
آیا WCAG 2.2 از نظر قانونی الزامی است؟
بله، در بیشتر بازارهای اصلی. قانون دسترسپذیری اروپایی در ژوئن 2025 لازمالاجرا شد و به WCAG 2.1 حداقل اشاره میکند، با 2.2 به عنوان استاندارد کاری فعلی. بخش 508 در ایالات متحده به WCAG 2.0 اشاره دارد اما قراردادهای تدارکات به طور فزایندهای نیاز به 2.2 دارند. کانادا، انگلستان، استرالیا و ژاپن همه الزامات مشابهی مرتبط با WCAG 2.1 یا 2.2 دارند. اگر به هر یک از این بازارها ارسال میکنید، 2.2 AA هدف امن است.
معیارهای جدید WCAG 2.2 که واقعاً باید بدانم کدامند؟
چهار معیار برای طراحان بیشترین اهمیت را دارند. 2.5.7 حرکات کشیدن نیاز به یک جایگزین بدون کشیدن برای تعاملات کشیدن دارد. 2.5.8 اندازه هدف (حداقل) نیاز به اهداف ضربهای حداقل 24 در 24 CSS pixel با فاصله کافی دارد. 2.4.11 فوکوس پنهان نشده نیاز دارد که عنصر فوکوسشده از طریق اسکرول و پوششهای چسبنده قابل مشاهده بماند. 3.3.8 احراز هویت قابل دسترس آزمونهای شناختی مانند به یاد آوردن رمز عبور بدون یک جایگزین (SSO، passkey، یا لینک ایمیل) را ممنوع میکند.
آیا به یک چکلیست جداگانه برای موبایل نیاز دارم؟
خیر. WCAG 2.2 به صراحت برای پوشش موبایل و لمس نوشته شده است، که دلیل اینکه بسیاری از معیارهای جدید آن (اندازه هدف، کشیدن، فوکوس) آگاه از موبایل هستند. همان چکلیست سهمرحلهای برای وب موبایل و طراحی واکنشگرا کار میکند. اپلیکیشنهای بومی دارای دستورالعملهای خاص پلتفرم اضافی هستند (HIG Apple و دسترسپذیری Android) اما قوانین WCAG همچنان اعمال میشوند.
حداقل اندازه هدف لمسی در WCAG 2.2 چقدر است؟
24 در 24 CSS pixel حداقل تحت 2.5.8 اندازه هدف (حداقل) است، اما اگر اهداف فاصله کافی اطراف آنها داشته باشند یا inline با متن باشند، استثناهایی وجود دارد. هدف عملی که بیشتر طراحان باید دنبال کنند 48 در 48 CSS pixel است، که با توصیههای پلتفرم Apple و Google مطابقت دارد و از موارد استثنا در مشخصات WCAG اجتناب میکند.
چکلیست را ارسال کنید، نه حدسوگمان را
دسترسپذیری یک وظیفه انطباق نیست. این یک ویژگی طراحی است که در سه لحظه ساخته میشود، توسط ابزار اجرا میشود، توسط انسانها بررسی میشود.
تیمهایی که سایتهای قابل دسترس را بدون درد ارسال میکنند کسانی نیستند که بهترین ممیزان را دارند. آنها کسانی هستند که بررسیها را به مرحله طراحی، مرحله ساخت، و مرحله ارسال منتقل کردند، و از پیشرفت کار از هر یک از آنها با خرابیهای شناختهشده امتناع کردند.
سه لیست را اجرا کنید. ده اشتباه رایج را قبل از اینکه انباشته شوند بگیرید. اسکنهای مرحله مرورگر را در CI خودکار کنید. از دریفت بعد از ارسال ماهانه ممیزی کنید. WCAG 2.2 AA دیگر یک خط پایانی نیست و تبدیل به یک ویژگی نحوه کار تیم میشود.
امروز یک سطح محصول روی سایت خود انتخاب کنید. چکلیست مرحله طراحی را در برابر فایل Figma آن اجرا کنید. تعداد رفعها را بشمارید. آن تعداد هزینه عدم اجرای این کار زودتر است.
چکلیست را ارسال کنید، نه حدسوگمان را.
Need a site that passes WCAG 2.2 without a three-month remediation cycle? Brainy ships accessible design from the first Figma frame.
Get Started
