Accessibility چیست و چرا باید برای همه کاربران طراحی کنیم؟
تعریف دسترس‌پذیری وب، اصول POUR در WCAG 2.2، سطح‌های A/AA/AAA، و شروع عملی با ارجاع W3C و MDN و web.dev.
SE
6 min readSoheil Ebrahimpour
Founder & product engineer
دسترس‌پذیری وب یا Accessibility (اغلب a11y به‌خاطر ۱۱ حرف میانی) یعنی طراحی و ساخت سایت و اپلیکیشن طوری که افراد با توانایی‌ها و محدودیت‌های گوناگون بتوانند به‌صورت معنادار و برابر با آن کار کنند. MDN می‌نویسد برای بسیاری فناوری کار را آسان می‌کند؛ برای افراد دارای معلولیت، فناوری کار را ممکن می‌کند.
W3C یادآوری می‌کند وب اساساً برای همه طراحی شده — صرف‌نظر از سخت‌افزار، نرم‌افزار، زبان، مکان یا توانایی. وقتی این هدف برآورده شود، افراد با طیف متنوع شنوایی، حرکت، بینایی و توانایی شناختی می‌توانند استفاده کنند. Accessibility فقط «برای نابینایان» نیست؛ شامل صفحه‌کلید، کنتراست، صرع حساس به نور، اختلال شناختی، و استفادهٔ موقت با دست شکسته هم می‌شود.
این مقاله تعریف، چارچوب WCAG 2.2، سطح انطباق، و مسیر شروع تیم را با منابع رسمی جمع می‌کند.
پاسخ کوتاه
Accessibility مجموعه‌ای از اصول، تکنیک‌ها و آزمون‌هاست تا محتوای وب برای انسان‌های بیشتر قابل ادراک، قابل‌عمل، قابل‌فهم و سازگار با فناوری‌های کمکی باشد. استاندارد مرجع بین‌المللی Web Content Accessibility Guidelines است؛ نسخهٔ توصیه‌شدهٔ جاری برای کار تازه معمولاً WCAG 2.2 است.
چرا برای همه طراحی کنیم؟ چون معلولیت دائمی، موقت یا موقعیتی است؛ چون در بسیاری حوزه‌ها الزام قانونی/قراردادی وجود دارد؛ و چون همان اصلاحات (کنتراست، برچسب، ساختار معنایی، صفحه‌کلید) کیفیت را برای همه بالا می‌برد. نادیده گرفتن a11y یعنی حذف تعمدی بخشی از مشتریان و افزایش ریسک.
دسترس‌پذیری ویژگی لوکس بعد از لانچ نیست؛ کیفیت پایهٔ ورود به محصول است.
WCAG به زبان غیرحقوقی
طبق مرور W3C روی WCAG، این اسناد توضیح می‌دهند چگونه محتوای وب را برای افراد دارای معلولیت دسترس‌پذیرتر کنید. WCAG 2.2 سیزده guideline دارد زیر چهار اصل که با سرواژهٔ POUR شناخته می‌شوند. برای هر guideline، Success Criteria آزمون‌پذیر در سطوح A، AA و AAA تعریف شده است. انطباق روی برآوردن همین معیارها تعریف می‌شود.
W3C تشویق می‌کند از آخرین نسخه استفاده کنید؛ محتوای منطبق با 2.2 با 2.1 و 2.0 نیز سازگار پس‌رو است. نسخهٔ 2.2 در اکتبر ۲۰۲۳ به‌عنوان W3C Recommendation منتشر شد و به‌روزرسانی‌هایی داشته است. برای کار روزمره، Quick Reference «How to Meet WCAG 2» نقطهٔ ورود عملی است.
چهار اصل POUR
| اصل | معنی کوتاه | نمونه الزام |
|---|---|---|
| Perceivable | قابل ادراک باشد | متن جایگزین تصویر؛ زیرنویس |
| Operable | قابل استفاده با ورودی‌های گوناگون | صفحه‌کلید؛ زمان کافی؛ بدون حملهٔ صرعی |
| Understandable | قابل فهم | خوانایی؛ پیش‌بینی‌پذیری؛ کمک به خطا |
| Robust | با فناوری‌های کمکی سازگار | نام/نقش/مقدار برای کنترل‌ها |
معیار 1.1.1 Non-text Content در سطح A نمونهٔ کلاسیک است: محتوای غیرمتنی باید جایگزین متنی هم‌ارز داشته باشد مگر موارد مشخص (تزئینی، CAPTCHA با جایگزین و غیره). جزئیات در Quickref WCAG 2.2 آمده است.
سطح A، AA، AAA
A حداقل است؛ AA هدف رایج بسیاری سازمان‌ها و سیاست‌هاست؛ AAA بالاترین و گاهی برای کل سایت غیرعملی است. انتخاب سطح را با نیاز قانونی بازار، قرارداد مشتری، و ریسک محصول تعیین کنید — نه با شعار. حتی اگر AAA کامل نمی‌کنید، برخی معیارهای AAA می‌توانند هدف صفحه‌های خاص باشند.
چه کسانی سود می‌برند؟
- کاربران صفحه‌خوان و بزرگ‌نمایی.
- کاربران فقط-صفحه‌کلید یا سوئیچ.
- افراد با کوررنگی یا کنتراست پایین محیط.
- کاربران با محدودیت شناختی یا توجه.
- کاربران موقت: آفتاب شدید، دست پر، شبکهٔ کند، زبان دوم.
طراحی فراگیر دایرهٔ مشتری را باز می‌کند؛ این جدای از بُعد اخلاقی است.
شروع عملی برای تیم
- HTML معنایی: عنوان‌ها، لیست، دکمه واقعی، label برای input.
- ترتیب فوکوس و نشانگر فوکوس قابل‌دیدن.
- کنتراست متن و اجزای UI.
- متن جایگزین معنادار؛ تزئینی را خالی و درست علامت بزنید.
- آزمون صفحه‌کلید روی جریان‌های اصلی.
- ابزار خودکار (به‌عنوان تور ایمنی نه اثبات کامل) + آزمون دستی.
MDN و دورهٔ Learn Accessibility در web.dev مسیر یادگیری ساخت‌یافته می‌دهند. ARIA را فقط وقتی HTML کافی نیست اضافه کنید؛ ARIA غلط بدتر از نبودش است.
دسترس‌پذیری و UX Writing
پیام خطا، نام دکمه، و وضعیت زنده (live region) بخشی از فهم‌پذیری‌اند. متن مبهم برای همه بد است؛ برای کاربر صفحه‌خوان می‌تواند بن‌بست کامل باشد. هماهنگی Writer و توسعه‌دهنده اینجا حیاتی است.
اسطوره‌های رایج
- «مخاطب ما معلول ندارد» — آمار و معلولیت موقعیتی خلافش را می‌گوید.
- «بعد از لانچ یک پلاگین می‌گذاریم» — پلاگین جادویی جایگزین طراحی معنایی نیست.
- «فقط برای دولت لازم است» — بازار خصوصی، سازمانی و بین‌المللی هم الزام/ریسک دارد.
- «زشت می‌شود» — a11y خوب اغلب ظاهر را منظم‌تر و خواناتر می‌کند.
اندازه‌گیری و فرایند
معیارها را به Definition of Done فیچرهای کاربر-رو اضافه کنید. ممیزی دوره‌ای با نمونهٔ صفحات نماینده. درباگ‌های a11y مثل باگ کارکردی اولویت دهید نه «بدهی زیباسازی». آموزش کوتاه برای طراح و فرانت هزینهٔ بازکاری را کم می‌کند.
قانون و استانداردهای مرتبط
W3C اشاره می‌کند WCAG در سیاست‌ها و قوانین بسیاری کشورها نقش دارد و در اروپا اغلب کنار EN 301 549 مطرح می‌شود. جزئیات حقوقی حوزهٔ شما را با مشاور محلی بررسی کنید؛ این مقاله جایگزین مشاورهٔ حقوقی نیست. از نظر فنی، پایبندی به WCAG 2.2 AA نقطهٔ شروع مشترک خوبی است.
جمع‌بندی برای تصمیم
Accessibility یعنی امکان استفادهٔ برابر و معنادار برای طیف گستردهٔ انسان‌ها. WCAG 2.2 با اصول POUR و معیارهای سطح‌بندی‌شده زبان مشترک تیم و ممیزی است. از HTML معنایی، صفحه‌کلید، کنتراست و متن جایگزین شروع کنید و a11y را در Done بگنجانید. طراحی برای همه کیفیت محصول را بالا می‌برد نه اینکه آن را کند کند.
این هفته جریان اصلی محصول را فقط با صفحه‌کلید طی کنید و هر بن‌بست را به‌عنوان باگ ثبت کنید.
منابع و مراجع
- W3C WAI — WCAG 2 Overview — https://www.w3.org/WAI/standards-guidelines/wcag/
- W3C WAI — How to Meet WCAG 2.2 (Quick Reference) — https://www.w3.org/WAI/WCAG22/quickref/
- W3C — Web Content Accessibility Guidelines (WCAG) 2.2 — https://www.w3.org/TR/WCAG22/
- MDN — Accessibility — https://developer.mozilla.org/en-US/docs/Web/Accessibility
- web.dev — Learn Accessibility — https://web.dev/learn/accessibility/
برای اتصال a11y به ترک کاربر و کیفیت UI، مقالات ۰۸۸ و ۰۹۵ مکمل‌اند.
Author
SE
Soheil Ebrahimpour is the founder of FutureForge. He works on product design, architecture, and getting custom software into production.
Related notes
If you are unsure about architecture or the build path, we can talk about the project.
Describe the problem and the constraints. If there is a fit, we will schedule a conversation.
