دسترس‌پذیری وب چیست؟ WCAG و طراحی فراگیر توضیح داده‌شده
دسترس‌پذیری وب یعنی ساختن وب‌سایت‌ها و اپ‌ها به‌گونه‌ای که افراد دارای معلولیت بتوانند از آن‌ها استفاده کنند — چه نابینا باشند و از صفحه‌خوان استفاده کنند، چه نتوانند از ماوس استفاده کنند، چه کم‌بینا یا دارای کوررنگی باشند، چه ناشنوا باشند، یا معلولیت شناختی یا یادگیری داشته باشند. در عمل به چیزهایی مثل متن جایگزین برای تصاویر، کنتراست رنگ کافی، فرم‌هایی با برچسب درست و کار کردن همه‌چیز فقط با صفحه‌کلید برمی‌گردد. استاندارد بین‌المللی آن WCAG است، یعنی Web Content Accessibility Guidelines از W3C.
دسترس‌پذیری اغلب کوتاه‌شده به a11y نوشته می‌شود — «a»، سپس ۱۱ حرف، و بعد «y».
چرا وقتی با هوش مصنوعی می‌سازید دسترس‌پذیری مهم است
سازنده‌های هوش مصنوعی در ساختن اپ‌هایی که درست به نظر می‌رسند خوب هستند. دسترس‌پذیری بیشتر درباره‌ی چیزهایی است که در یک اسکرین‌شات دیده نمی‌شوند: اینکه آیا یک دکمه واقعاً دکمه است، آیا یک ورودی برچسبی دارد که صفحه‌خوان بتواند اعلام کند، و آیا می‌توانید با کلید Tab به منو برسید.
به همین دلیل پرسیدن درباره‌اش مهم است:
- به‌راحتی از چشم می‌افتد. یک منوی کشویی با استایل سفارشی می‌تواند کاملاً زیبا باشد و بدون ماوس غیرقابل استفاده. اگر آن را آزمایش نکنید متوجه نمی‌شوید.
- درست کردنش از اول ارزان‌تر است. از همان پرامپت اول درخواست کامپوننت‌های دسترس‌پذیر تقریباً هزینه‌ای ندارد. اصلاح یک اپ تمام‌شده یعنی دست زدن به همه‌ی صفحات.
- به همه کمک می‌کند. زیرنویس به افراد در محیط‌های پرسروصدا کمک می‌کند، کنتراست خوب به کسانی که زیر نور آفتاب با گوشی کار می‌کنند کمک می‌کند، و برچسب‌های واضح به همه کمک می‌کنند فرم‌ها را سریع‌تر پر کنند.
- با SEO هم همپوشانی دارد. عنوان‌های درست، لینک‌های توصیفی و متن جایگزین به موتورهای جستجو هم کمک می‌کنند صفحات شما را بفهمند — SEO برای وب‌سایت‌های ساخته‌شده با هوش مصنوعی را ببینید.
- ممکن است الزامی باشد. بسته به محل فعالیت و مخاطبانتان، دسترس‌پذیری می‌تواند یک تعهد قانونی باشد.
یک تشبیه روزمره
ورودی یک ساختمان را تصور کنید.
پله برای خیلی از افراد خوب کار می‌کند. سطح شیب‌دار برای افراد روی ویلچر کار می‌کند — و همچنین برای والدین با کالسکه، کارگران تحویل با چرخ‌دستی و مسافرانی با چمدان. درِ خودکار، تابلوهای واضح، خط بریل روی دکمه‌های آسانسور و نورپردازی خوب هر کدام مانعی را برای کسی برمی‌دارند.
دسترس‌پذیری وب همان ایده برای فضاهای دیجیتال است: سطح شیب‌دار، تابلو و نرده‌های اپ شما. و درست مثل ساختمان، گنجاندن سطح شیب‌دار در نقشه‌ها بسیار آسان‌تر از اضافه کردنش بعد از بتن‌ریزی است.
WCAG در یک نگاه
WCAG توسط Web Accessibility Initiative در W3C منتشر می‌شود. نسخه‌ی فعلی WCAG 2.2 است که اول اکتبر ۲۰۲۳ منتشر شد. با نسخه‌های قبلی سازگار به عقب است: محتوایی که WCAG 2.2 را برآورده کند، WCAG 2.1 و 2.0 را هم برآورده می‌کند، و W3C استفاده از آخرین نسخه را توصیه می‌کند. WCAG 2.2 همچنین به‌عنوان استاندارد بین‌المللی ISO/IEC 40500:2025 تأیید شده است. یک WCAG 3 کاملاً متفاوت در حال توسعه است، به‌صورت پیش‌نویس اولیه، نه استاندارد نهایی.
WCAG بر اساس چهار اصل سازمان‌دهی شده است که اغلب با عبارت POUR به خاطر سپرده می‌شود:
| اصل | معنی | نمونه‌ها |
|---|---|---|
| Perceivable (قابل‌درک با حس) | افراد می‌توانند محتوا را با حس‌هایی که استفاده می‌کنند دریافت کنند | متن جایگزین برای تصاویر، زیرنویس برای ویدیو، کنتراست کافی |
| Operable (قابل‌بهره‌برداری) | افراد می‌توانند کنترل‌ها را به کار ببرند و حرکت کنند | دسترسی با صفحه‌کلید، بدون محدودیت زمانی که قابل تمدید نباشد، فوکوس قابل‌مشاهده |
| Understandable (قابل‌فهم) | محتوا و رفتار معنی‌دار هستند | برچسب‌های واضح، پیام‌های خطای مفید، ناوبری یکدست |
| Robust (مقاوم) | با مرورگرها و فناوری‌های کمکی گوناگون کار می‌کند | عناصر درست HTML، نام‌ها و نقش‌های صحیح برای کنترل‌ها |
هر رهنمود معیارهای موفقیت قابل‌آزمایش در سه سطح دارد:
- سطح A — حداقل. رد شدن از این‌ها بعضی افراد را کاملاً متوقف می‌کند.
- سطح AA — هدف استاندارد، و سطحی که بیشتر قوانین و سیاست‌ها به آن اشاره می‌کنند.
- سطح AAA — بالاترین سطح. در بعضی جاها هدف خوبی است، اما W3C توصیه نمی‌کند الزامش کنید برای کل سایت‌ها، چون برخی محتواها نمی‌توانند به آن برسند.
WCAG 2.2 نه معیار موفقیت به ۲.۱ اضافه کرده، از جمله Target Size (Minimum) در سطح AA — اهداف قابل‌کلیک معمولاً باید حداقل ۲۴ در ۲۴ پیکسل CSS باشند، با استثناهایی — و Accessible Authentication (Minimum) که مراحل ورودی را که به حافظه یا معماهی‌ها تکیه دارند محدود می‌کند، مثل اینکه کاربر رمز عبور را دوباره تایپ کند بدون اینکه اجازه‌ی چسباندن آن را داشته باشد. معیار قدیمی «Parsing» را هم به‌عنوان منسوخ حذف کرده است.
یک مثال کامل: فرم ثبت‌نام
این یک فرم ثبت‌نام است که هوش مصنوعی ممکن است بسازد، و آنچه یک بررسی دسترس‌پذیری پیدا می‌کند:
| مشکل | چه کسانی تحت تأثیرند | رفع |
|---|---|---|
| ورودی‌ها به‌جای برچسب از متن placeholder («Email») استفاده می‌کنند | کاربران صفحه‌خوان؛ هر کسی که وقتی شروع به تایپ می‌کند یادش می‌رود آن فیلد چه بود | یک <label> قابل‌مشاهده که به هر ورودی وصل است |
| متن خاکستری روشن روی سفید، با کنتراست خیلی کمتر از ۴.۵:۱ | افراد کم‌بینا، هر کسی که بیرون است | متن تیره‌تری که نسبت کنتراست ۴.۵:۱ را برآورده کند |
| خطاها فقط با یک حاشیه‌ی قرمز نشان داده می‌شوند | کاربران کوررنگ، کاربران صفحه‌خوان | یک پیام متنی کنار فیلد که برای صفحه‌خوان اعلام شود |
«Sign up» یک <div> با استایل است، نه <button> | کاربران صفحه‌کلید و صفحه‌خوان نمی‌توانند آن را فعال کنند | استفاده از عنصر واقعی <button> |
| وقتی با Tab بین فیلدها حرکت می‌کنید خط فوکوس قابل‌مشاهده نیست | کاربران صفحه‌کلید گم می‌شوند که کجا هستند | یک استایل فوکوس واضح |
| تصویر لوگو متن جایگزین ندارد | کاربران صفحه‌خوان نام یک فایل می‌شنوند | متن جایگزینی مثل «Acme Bookings» |
هیچ‌کدام از این رفع‌ها ظاهر فرم را زیاد تغییر نمی‌دهند. همه‌ی آن‌ها تغییر می‌دهند که آیا بعضی افراد اصلاً می‌توانند از آن استفاده کنند یا نه.
اصطلاحات کلیدی
| اصطلاح | معنی |
|---|---|
| Screen reader (صفحه‌خوان) | نرم‌افزاری که صفحه را با صدا بلند یا به نمایشگر بریل می‌خواند، مثل VoiceOver، NVDA یا JAWS. |
| Alt text (متن جایگزین) | توصیف متنی یک تصویر که صفحه‌خوان‌ها می‌خوانند. تصاویر تزئینی متن جایگزین خالی می‌گیرند تا رد شوند. |
| Contrast ratio (نسبت کنتراست) | میزان تفاوت رنگ متن و پس‌زمینه، از ۱:۱ تا ۲۱:۱. |
| Keyboard navigation (ناوبری با صفحه‌کلید) | استفاده از سایت با کلیدهای Tab، Enter، Space و فلش‌ها به‌جای ماوس. |
| Focus indicator (نشانگر فوکوس) | خط قابل‌مشاهده‌ای که نشان می‌دهد صفحه‌کلید روی کدام عنصر است. |
| Semantic HTML (HTML معنایی) | استفاده از عنصر درست برای کار — <button>، <nav>، <h2> — تا مرورگرها و فناوری‌های کمکی صفحه را بفهمند. |
| ARIA | ویژگی‌های اضافی که کنترل‌های سفارشی را برای فناوری کمکی توصیف می‌کنند. بهتر است با احتیاط استفاده شوند؛ عناصر بومی HTML مقدم‌اند. |
| Assistive technology (فناوری کمکی) | ابزارهایی که مردم برای دسترسی به رایانه استفاده می‌کنند، از صفحه‌خوان تا دستگاه‌های سوییچ و کنترل صوتی. |
باورهای غلط رایج
- «دسترس‌پذیری فقط برای کاربران نابینا مهم است.» معلولیت‌های بینایی، حرکتی، شنوایی، گفتاری و شناختی را پوشش می‌دهد، و همچنین شرایط موقتی مثل شکستگی دست.
- «سایت‌های دسترس‌پذیر ساده به نظر می‌رسند.» دسترس‌پذیری چند چیز را محدود می‌کند — کنتراست، استایل فوکوس، اندازه‌ی متن — اما سایت‌های دسترس‌پذیر خوش‌ظاهر قاعده‌اند، نه استثنا.
- «ابزار خودکار ۱۰۰ می‌دهد، پس تمام شد.» ابزارهای خودکار فقط بعضی مشکلات را می‌گیرند. اینکه آیا متن جایگزین واقعاً معنی‌دار است یا یک جریان با صفحه‌خوان قابل‌فهم است، نیاز به بررسی انسان دارد.
- «یک ویجت پوشش ما را مطابق می‌کند.» نوار ابزارهایی که روی سایت بسته می‌شوند نمی‌توانند برچسب‌های جا افتاده یا دسترسی شکسته با صفحه‌کلید را در کد شما درست کنند. منبع را درست کنید.
- «کاربر دارای معلولیت نداریم.» شاید فقط ندانید. بسیاری از معلولیت‌ها دیده نمی‌شوند و کسانی که به یک مانع برمی‌خورند معمولاً فقط می‌روند.
از سازنده‌ی هوش مصنوعی‌تان چه بخواهید
- «این را طوری بساز که WCAG 2.2 سطح AA را برآورده کند.»
- «از HTML معنایی استفاده کن: دکمه‌ها، لینک‌ها و عنوان‌های واقعی به ترتیب، و برچسب برای هر فیلد فرم.»
- «مطمئن شو هر عنصر تعاملی فقط با صفحه‌کلید کار می‌کند و استایل فوکوس قابل‌مشاهده دارد.»
- «رنگ همه‌ی متن‌ها و آیکون‌ها را از نظر کنتراست بررسی کن — ۴.۵:۱ برای متن عادی، ۳:۱ برای متن بزرگ و آیکون‌ها.»
- «به تصاویر اطلاع‌رسان متن جایگزین معنی‌دار و به تصاویر تزئینی متن جایگزین خالی بده.»
- «خطاهای فرم را به‌صورت متن، متصل به فیلد نشان بده، نه فقط با رنگ.»
- «تنظیم کاهش حرکت کاربر را برای انیمیشن‌ها رعایت کن.»
- «یک بررسی خودکار دسترس‌پذیری اجرا کن و فهرستی از مواردی که نمی‌تواند آزمایش کند بده تا خودم دستی بررسی کنم.»
سپس خودتان آزمایش کنید: ماوس را کنار بگذارید و سعی کنید جریان اصلی‌تان را فقط با Tab، Shift+Tab، Enter و Space کامل کنید. صفحه‌خوان داخلی گوشی‌تان را روی صفحه‌ی اصلی امتحان کنید. مرورگر را روی ۲۰۰٪ زوم کنید و ببینید آیا چیزی خراب می‌شود.
دسترس‌پذیری در Mythex
Mythex ابزار بررسی اختصاصی دسترس‌پذیری ندارد، پس دسترس‌پذیری را بخشی از پرامپت‌ها و آزمایش‌تان بدانید. از اولین پرامپت WCAG 2.2 AA بخواهید، نتیجه را در Preview با صفحه‌کلید بررسی کنید، و از /test استفاده کنید تا عامل جریان‌های اصلی را قبل از انتشار کلیک کند — تست اپ را ببینید. دستور SEO هم عنوان‌های معنایی و متن جایگزین معنی‌دار می‌خواهد، که هر دو هدف را پوشش می‌دهند.
برای چک‌لیست عملی، نحوه‌ی دسترس‌پذیر کردن وب‌سایت‌تان را ببینید. برای طراحی، نحوه‌ی طراحی یک اپ خوش‌ظاهر با هوش مصنوعی را بخوانید، و قبل از راه‌اندازی، نحوه‌ی آزمایش اپ قبل از راه‌اندازی. مرجع معتبر، مرور WCAG روی سایت W3C است.
پرسش‌ها
دسترس‌پذیری وب به زبان ساده چیست؟
دسترس‌پذیری وب یعنی وب‌سایت‌ها و اپ‌ها طوری طراحی و ساخته شوند که افراد دارای معلولیت بتوانند آن‌ها را درک کنند، بفهمند، در آن حرکت کنند و از آن استفاده کنند. این شامل افراد نابینایی که از صفحه‌خوان استفاده می‌کنند، کسانی که نمی‌توانند از ماوس استفاده کنند، افراد کم‌بینا یا دارای کوررنگی، کاربران ناشنوا و افراد دارای معلولیت شناختی می‌شود.
WCAG چیست؟
WCAG (Web Content Accessibility Guidelines) استاندارد بین‌المللی دسترس‌پذیری وب است که توسط W3C منتشر شده. نسخه‌ی فعلی WCAG 2.2 است که اول اکتبر ۲۰۲۳ منتشر شد. معیارهای موفقیت آن در سطوح A، AA و AAA رتبه‌بندی می‌شوند و سطح AA هدفی است که بیشتر سازمان‌ها و قوانین به آن ارجاع می‌دهند.
WCAG چه کنتراست رنگی‌ای لازم دارد؟
در سطح AA، متن عادی حداقل به نسبت کنتراست ۴.۵:۱ با پس‌زمینه‌اش نیاز دارد و متن بزرگ (تقریباً ۱۸ پوینت، یا ۱۴ پوینت ضخیم) حداقل ۳:۱. آیکون‌ها و بخش‌های قابل‌مشاهده‌ی کنترل‌ها حداقل ۳:۱ نسبت به عناصر کناری‌شان نیاز دارند.
آیا دسترس‌پذیری وب الزام قانونی است؟
در بسیاری از کشورها و برای بسیاری از سازمان‌ها، بله. قوانین بسته به کشور و بخش فعالیت فرق می‌کنند؛ مثلاً European Accessibility Act بسیاری از محصولات و خدمات دیجیتال مصرفی در اتحادیه‌ی اروپا را پوشش می‌دهد. قوانین مربوط به خودتان را بررسی کنید یا از مشاور حقوقی بپرسید.
آیا یک ویجت یا پوشش دسترس‌پذیری می‌تواند سایتم را مطابق کند؟
به‌تنهایی نه. پوشش‌ها یک نوار ابزار روی سایت شما اضافه می‌کنند، اما نمی‌توانند مشکلات اصلی مثل برچسب‌های جا افتاده، ناوبری غیرقابل استفاده با صفحه‌کلید یا ساختار نامشخص را به‌طور قابل‌اعتماد برطرف کنند. روش مطمئن این است که کد و محتوای خود سایت را درست کنید.