چگونه وب‌سایت را قابل دسترسی کنیم: راهنمای شروع WCAG 2.2

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

«قابل دسترسی» در عمل یعنی چه

دسترسی درباره آدم‌هاست: کسی که نابیناست و از خواننده صفحه استفاده می‌کند، کسی که لرزش دست دارد و با صفحه‌کلید حرکت می‌کند، کسی با بینایی ضعیف که تا ۲۰۰٪ بزرگ‌نمایی می‌کند، کسی که زیر نور تند خورشید می‌خواند، کسی که موقتاً مچ دستش شکسته است. دسترسی خوب معمولاً سایت را برای همه بهتر می‌کند — ساختار واضح‌تر، متن خواناتر، فرم‌هایی که خطاهایشان را توضیح می‌دهند.

استاندارد مرجع، راهنماهای دسترسی محتوای وب (WCAG) از W3C است. از سپتامبر ۲۰۲۶، نسخه فعلی WCAG 2.2 است (منتشرشده در اکتبر ۲۰۲۳، به‌روزشده در دسامبر ۲۰۲۴)؛ WCAG 3 پیش‌نویس اولیه است. WCAG بر چهار اصل سازمان یافته است — محتوا باید قابل درک با حس، قابل کار کردن، قابل فهم و مقاوم باشد — و سه سطح انطباق دارد:

قوانین در چند کشور به WCAG ارجاع می‌دهند — برای نمونه قانون دسترسی اروپا (European Accessibility Act) که از ژوئن ۲۰۲۵ برای بسیاری از خدمات دیجیتال مصرف‌کننده در اتحادیه اروپا اعمال شده است. کدام قواعد برای شما اعمال می‌شود به این بستگی دارد که کجا فعالیت می‌کنید و چه می‌فروشید؛ اگر مطمئن نیستید با یک مشاور صحبت کنید. این راهنما به کار عملی می‌پردازد.

گزینه‌ها: چگونه به آنجا برسیم

برای بیشتر سایت‌های کوچک، دو رویکرد اول کافی است: به هوش مصنوعی بگویید از اول قابل دسترسی بسازد، و قبل از انتشار بررسی کنید.

اصلاحاتی که بیشترین اهمیت را دارند

از عناصر درست HTML استفاده کنید

بیشتر دسترس‌پذیری با HTML درست رایگان می‌آید. یک <button> قابل فوکوس است، با Enter و Space کار می‌کند و به‌عنوان دکمه اعلام می‌شود. یک <div> با یک کنترل کلیک چنین چیزی نیست. کد تولیدشده با هوش مصنوعی گاهی همه چیز را با divهای استایل‌دار می‌سازد؛ عناصر معنادار بخواهید:

• <button> برای کنش‌ها، <a href> برای ناوبری
• یک <h1> در هر صفحه، سپس <h2> و <h3> به ترتیب — کاربران خواننده صفحه بین سرفصل‌ها می‌پرند
• نشانه‌های ناوبری: <header>، <nav>، <main>، <footer>
• یک <label> به هر فیلد فرم وصل شده باشد
• زبان صفحه در <html lang="fa"> باشد

از ویژگی‌های ARIA فقط وقتی استفاده کنید که هیچ عنصر بومی مناسب نیست — برای مثال یک مجموعه تب سفارشی یا combobox. ARIA اشتباه بدتر از نبودن آن است.

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

هر کاری که با ماوس می‌توانید انجام دهید باید فقط با صفحه‌کلید هم ممکن باشد (WCAG 2.1.1). صفحه را با Tab بگردید: هر لینک، دکمه و فیلد باید با ترتیب منطقی قابل رسیدن باشد و همیشه ببینید فوکوس کجاست (2.4.7 Focus Visible). WCAG 2.2 اضافه کرد که عنصر فوکوس‌شده نباید کاملاً پشت سرصفحه‌های چسبان یا بنرهای کوکی پنهان شود (2.4.11، سطح AA).

خطاهای رایج: منوهایی که فقط با hover باز می‌شوند، مودال‌هایی که فوکوس را نگه نمی‌دارند یا با Escape بسته نمی‌شوند، و outline: none در CSS بدون چیزی به‌جایش.

متن جایگزین

هر تصویر معنادار به متن جایگزینی نیاز دارد که در زمینه‌اش بگوید چه نشان می‌دهد («سرآشپز در حال چیدن منوی چندمرحله‌ای»، نه «image1.jpg»). تصاویر تزئینی یک alt="" خالی می‌گیرند تا خواننده صفحه از آن‌ها بگذرد. دکمه‌های فقط‌آیکونی به نام قابل دسترس نیاز دارند («بستن»، «جستجو»). ویدیوها به زیرنویس و صداها به متن پیاده‌شده نیاز دارند.

رنگ و کنتراست

WCAG 2.2 سطح AA نسبت کنتراست حداقل ۴٫۵:۱ برای متن معمولی و ۳:۱ برای متن بزرگ (1.4.3)، و ۳:۱ برای بخش‌های رابط مانند حاشیه فیلدهای ورودی و آیکون‌های معنادار (1.4.11) می‌خواهد. متن خاکستری‌روشن placeholder و دکمه‌های کم‌رنگ شکست‌های رایج هستند. همچنین هرگز فقط با رنگ معنا منتقل نکنید — حاشیه قرمز یک فیلد نامعتبر باید پیام خطا هم داشته باشد.

تغییر اندازه و چیدمان مجدد

متن باید وقتی تا ۲۰۰٪ بزرگ‌نمایی می‌شود قابل استفاده بماند (1.4.4)، و محتوا باید در عرض ۳۲۰ پیکسل CSS بدون اسکرول افقی کار کند (1.4.10). یک چیدمان واکنش‌گرا بیشتر این موارد را پوشش می‌دهد.

اندازه هدف، فرم‌ها و خطاها

• اندازه هدف: WCAG 2.2 سطح AA برای هدف‌های اشاره‌گر حداقل ۲۴ در ۲۴ پیکسل CSS، یا فاصله کافی برای هدف‌های کوچک‌تر می‌خواهد (2.5.8). بزرگ‌تر بودن برای گوشی مهربان‌تر است.
• فرم‌ها: برچسب‌های قابل‌دیدن (نه فقط placeholder)، دستورهای واضح، و پیام‌های خطایی که بگویند چه اشتباهی شده و چطور درست کنند، کنار همان فیلد.
• ورود: از مردم نخواهید پازل حل کنند یا کدی را بدون جایگزین بازنویسی کنند؛ مدیران رمز عبور و چسباندن را مجاز بدانید (3.3.8 Accessible Authentication).

پرامپت‌هایی که جواب می‌دهند

این سایت را طوری بساز که با WCAG 2.2 سطح AA مطابق باشد: landmarkهای معنادار HTML، یک h1 در هر صفحه با سرفصل‌های به ترتیب، عناصر واقعی button و link، برچسب برای همه فیلدهای فرم، استایل فوکوس قابل‌دیدن، کنتراست متن حداقل ۴٫۵:۱، متن جایگزین برای تصاویر معنادار و alt="" برای تصاویر تزئینی، و تنظیم html lang.

صفحات /signup و /checkout را از نظر دسترسی بررسی کن. دسترسی فقط با صفحه‌کلید، ترتیب فوکوس، فوکوس قابل‌دیدن، برچسب‌ها، پیام‌های خطا، کنتراست و نام‌های خواننده صفحه برای دکمه‌های آیکونی را چک کن. هر مشکل را با معیار WCAG فهرست کن، سپس آن‌ها را بدون تغییر بیشتر از حد لازم در طراحی بصری درست کن.

منوی موبایل با صفحه‌کلید قابل استفاده نیست. آن را به یک دکمه با aria-expanded تبدیل کن، وقتی باز می‌شود فوکوس را به داخل منو ببر، با Escape بسته شود و فوکوس به دکمه برگردد.

گام‌به‌گام

1. یک بررسی خودکار اجرا کنید. بخش Accessibility در Lighthouse داخل DevTools کروم، یا افزونه مرورگر axe، روی هر صفحه اصلی. هر چیزی را که گزارش می‌دهد درست کنید.
2. ماوس را کنار بگذارید. با Tab در هر صفحه بروید و هر کار اصلی را کامل کنید — ثبت‌نام، جستجو، پرداخت. هر چیزی را که نمی‌توانید به آن برسید، فوکوسش را نمی‌بینید، یا نمی‌توانید از آن خارج شوید یادداشت کنید.
3. تا ۲۰۰٪ بزرگ‌نمایی کنید و پنجره را به عرض گوشی ببرید. چیزی نباید بریده شود یا اسکرول افقی بخواهد.
4. ده دقیقه با خواننده صفحه امتحان کنید: VoiceOver روی Mac و iPhone، TalkBack روی اندروید، یا NVDA روی ویندوز (رایگان). سرفصل‌ها، لینک‌ها و فیلدهای فرم را گوش کنید. «دکمه» بدون نام، یا «لینک، اینجا کلیک کنید»، یعنی کار مانده است.
5. کنتراست متن، دکمه‌ها و فیلدها را با یک بررسی‌گر کنتراست چک کنید.
6. اصلاح کنید، سپس همان کارها را دوباره آزمایش کنید.
7. یک بیانیه دسترسی منتشر کنید که بگوید به چه استانداردی هدف می‌گیرید و چطور مشکلات را گزارش دهند — و به آن گزارش‌ها پاسخ دهید.

اشتباه‌های رایج

• تکیه بر ویجت پوششی به‌جای درست کردن کد.
• حذف خط‌های فوکوس چون ظاهرشان نامرتب است، بدون جایگزین.
• placeholder به‌عنوان تنها برچسب. وقتی کاربر شروع به تایپ می‌کند ناپدید می‌شود و اغلب کنتراست پایین دارد.
• لینک‌های «اینجا کلیک کنید» و «ادامه مطلب». بیرون از زمینه، کاربران خواننده صفحه فهرستی از لینک‌های یکسان می‌شنوند.
• متن جایگزین پر از کلیدواژه. متن جایگزین برای آدم‌هاست؛ تصویر را توصیف کنید.
• یک‌بار آزمایش کردن. هر امکان تازه می‌تواند دسترسی با صفحه‌کلید را خراب کند. یک گذر با صفحه‌کلید به آزمایش پیش از راه‌اندازی اضافه کنید.

چک‌لیست دسترسی

• بررسی خودکار (Lighthouse یا axe) روی صفحات اصلی بدون خطا
• هر کاری فقط با صفحه‌کلید قابل انجام است
• فوکوس همیشه دیده می‌شود و هرگز پشت عناصر چسبان پنهان نیست
• سرفصل‌ها، landmarkها، دکمه‌ها و لینک‌های معنادار؛ lang تنظیم شده
• متن جایگزین معنادار؛ تصاویر تزئینی با alt=""؛ زیرنویس برای ویدیو
• کنتراست متن ≥ ۴٫۵:۱ (متن بزرگ ≥ ۳:۱)؛ بخش‌های رابط ≥ ۳:۱
• کار کردن در بزرگ‌نمایی ۲۰۰٪ و عرض ۳۲۰ پیکسل
• هر فیلد فرم برچسب قابل‌دیدن و پیام‌های خطای واضح دارد
• بیانیه دسترسی با راهی برای گزارش مشکلات

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

دسترسی در Mythex

Mythex با هر استانداردی که بخواهید می‌سازد، پس «WCAG 2.2 AA» را در پرامپت اول و در پیام‌های بعدی بگذارید. می‌توانید از قاب اندازه گوشی در Preview برای بررسی صفحه‌های کوچک استفاده کنید (Preview and Code)، اما آزمون‌های صفحه‌کلید، بزرگ‌نمایی و خواننده صفحه بهترین نتیجه را روی نشانی منتشرشده یا پیش‌نمایشی دارند که در تب جداگانه باز شده. از عامل بخواهید یک صفحه را بررسی کند، آنچه پیدا می‌کند را درست کند، و بعد خودتان نتیجه اصلاحات را بیازمایید؛ بررسی خودکار شروع کار است، نه تأیید نهایی.

پرسش‌ها