راهنمای طراحی، توسعه و آزمون محصول دیجیتال فراگیر
کاربری که نمیتواند Modal را با کیبورد ببندد، فردی که پیام خطای قرمز را نمیبیند، سالمندی که کد پیامکی پیشین را باید دوباره وارد کند و مشتری فارسیزبانی که عدد و متن انگلیسی در رابط RTL بههم ریخته میبیند، چهار «Edge case» جدا نیستند؛ هر چهار نفر با تصمیم طراحی ما از انجام کار محروم شدهاند.
طراحی فراگیر یعنی تنوع واقعی انسان، ابزار و موقعیت را از مرحلهٔ تعریف مسئله وارد کنیم؛ دسترسپذیری را به Definition of Done ببریم؛ و نتیجه را با معیار فنی، آزمون دستی و مشارکت کاربران دارای معلولیت بسنجیم. این راهنما شعار نیست: Scope، WCAG ۲.۲، الگوهای رابط، روش تست، Severity و برنامهٔ ۹۰روزه ارائه میدهد.
طراحی فراگیر وب چیست؟
طراحی فراگیر (Inclusive Design) روشی برای شناخت طرد، یادگیری از افرادی است که بیشتر تحت تأثیر آناند و ساخت راههای متنوع برای مشارکت. هدف، یک رابط خیالی «برای همه» نیست؛ هدف کاهش موانع قابل پیشبینی و دادن انتخابهای معادل است.
دسترسپذیری وب بر قابل استفاده بودن فناوری برای افراد دارای معلولیت تمرکز دارد. این تمرکز نباید در عبارت مبهم «همه کاربران» محو شود. W3C تأکید میکند Accessibility دربارهٔ افراد است و استاندارد و چکلیست باید در خدمت نیاز واقعی افراد دارای معلولیت باشند.
| مفهوم | پرسش اصلی | شاهد | خطای رایج |
|---|---|---|---|
| Accessibility | آیا افراد دارای معلولیت میتوانند کار را انجام دهند؟ | WCAG، تست AT/Keyboard و کاربران | تقلیل به Alt و Contrast |
| Usability | کار تا چه حد مؤثر، کارآمد و رضایتبخش انجام میشود؟ | Task success، خطا، زمان و مشاهده | آزمون فقط با کاربران خبره |
| Inclusive Design | چه کسی و در کدام Context طرد شده و در تصمیم حضور ندارد؟ | مشارکت متنوع، Barrier map و Outcome | Persona بدون مشارکت واقعی |
| Universal Design | چگونه محیط/محصول تا حد ممکن برای طیف وسیع قابل استفاده باشد؟ | اصول و ارزیابی سیستم | تصور یک راهحل واحد برای همه |
برای پیوند Research، Journey و Delivery، راهنمای جامع تجربه کاربری را نیز بهکار ببرید.
معلولیت فقط ویژگی فرد نیست؛ تعامل با مانع است
توانایی و Context ثابت نیستند. یک کنترل صوتی ممکن است برای فرد نابینا ضروری، برای راننده مفید و در محیط شلوغ نامناسب باشد. Caption برای فرد ناشنوا ضروری و برای کاربر در مترو یا یادگیرندهٔ زبان مفید است.
| بعد | دائمی | موقت | موقعیتی | پاسخ طراحی |
|---|---|---|---|---|
| بینایی | نابینایی/کمبینایی | جراحی چشم | نور شدید | Semantics، Contrast، Zoom، Text alternative |
| شنوایی | ناشنوایی/کمشنوایی | عفونت گوش | محیط پرصدا | Caption، Transcript و اعلان بصری |
| حرکتی | محدودیت حرکت | دست شکسته | استفاده یکدستی | Keyboard، Target مناسب و جایگزین Drag |
| شناختی | اختلال یادگیری/حافظه | خستگی/دارو | استرس پرداخت | زبان روشن، Consistency و Error recovery |
| گفتار | محدودیت گفتار | گلودرد | فضای عمومی | جایگزین غیرصوتی |
طبق برآورد سازمان جهانی بهداشت، حدود ۱٫۳ میلیارد نفر یا ۱۶٪ جمعیت جهان معلولیت قابل توجهی را تجربه میکنند. این عدد دلیل انسانی و بازار را نشان میدهد، اما نیازهای یک محصول را باید با پژوهش کاربران خودش فهمید.
فراگیری فقط معلولیت نیست، اما معلولیت را محو نکنید
زبان، سواد، سن، جنسیت، فرهنگ، درآمد، دستگاه، کیفیت اتصال و امنیت موقعیتی بر تجربه اثر دارند. Intersectionality یعنی یک فرد ممکن است چند مانع همزمان داشته باشد؛ مثلاً کاربر سالمند کمبینا با سواد دیجیتال محدود روی موبایل ارزان و اینترنت ناپایدار.
- گزینهٔ پیشفرض را «کاربر جوان، بینا، راستدست، پرسرعت و فنی» فرض نکنید.
- گروهها را با کلیشه طراحی نکنید؛ الگوی رفتاری را با شواهد بسنجید.
- نیاز Accessibility افراد دارای معلولیت را به «محدودیت موقعیتی برای همه» تقلیل ندهید.
- امنیت، Privacy و اختیار را برای گروه آسیبپذیر قربانی سادگی نکنید.
چرا طراحی فراگیر برای کسبوکار مهم است؟
| Outcome | مکانیسم | KPI | Guardrail |
|---|---|---|---|
| دسترسی به خدمت | حذف مانع Task بحرانی | Task success بر اساس نیاز دسترسی | رضایت و استقلال |
| Conversion | فرم/پرداخت قابل فهم و قابل کنترل | Completion و Error recovery | عدم Dark pattern |
| هزینه پشتیبانی | خطای واضح و Self-service | Contact reason و Reopen | کیفیت حل مسئله |
| ریسک Delivery | Component و تست در CI | Defect escape و Regression | False confidence ابزار |
| اعتماد | احترام، اختیار و ارتباط روشن | شکایت/اعتماد کیفی | Privacy و Consent |
هیچ Outcome تجاری را قطعی فرض نکنید. اثر را با Baseline و Segment مناسب بسنجید؛ افراد دارای معلولیت را به «بازار جدید» یا ابزار اثبات ROI تقلیل ندهید. برای Business case دقیق، راهنمای محاسبه ROI تجربه کاربری مفید است.
WCAG ۲.۲ چیست و چه جایگاهی دارد؟
WCAG ۲.۲ استاندارد بینالمللی W3C برای دسترسپذیرتر کردن محتوای وب است. ۱۳ Guideline زیر چهار اصل سازمان یافتهاند: Perceivable، Operable، Understandable و Robust. Success criterionها سه سطح A، AA و AAA دارند.
| اصل | پرسش | نمونه مانع | نمونه کنترل |
|---|---|---|---|
| Perceivable | اطلاعات در شکل قابل ادراک ارائه میشود؟ | ویدئوی بیCaption، متن کمContrast | Alternative، Caption، Reflow و Contrast |
| Operable | رابط با روشهای ورودی مختلف قابل کنترل است؟ | Trap کیبورد، Drag اجباری | Keyboard، Focus، Target و جایگزین Drag |
| Understandable | محتوا و رفتار قابل فهم/پیشبینی است؟ | خطای مبهم، ورود تکراری | Label، Help، Error suggestion و Consistency |
| Robust | ساختار برای Browser و AT قابل تفسیر است؟ | Button با div بدون Name/Role/State | HTML native و Semantics معتبر |
سطح AA هدف رایجی برای محصول است، اما هدف قراردادی/حقوقی را از Requirement همان پروژه بگیرید. این مقاله مشاوره حقوقی نیست؛ قوانین حوزه و کشور هدف را با متخصص بررسی کنید.
چه چیزهایی در WCAG ۲.۲ پررنگتر شدند؟
WCAG ۲.۲ نه Success criterion جدید اضافه کرد و ۴.۱.۱ Parsing را منسوخ دانست. تغییرها به Focus، Drag، Target، Help، ورود تکراری و Authentication قابل دسترس توجه بیشتری میدهند.
| موضوع | اثر عملی | Test نمونه |
|---|---|---|
| Focus not obscured | Focus پشت Header/Modal پنهان نشود | Tab در Zoom و Sticky header |
| Dragging alternatives | عمل Drag با Click/Keyboard قابل انجام باشد | Reorder بدون Drag |
| Target size minimum | Target کوچک/چسبیده مانع نشود | Mobile و motor test |
| Consistent help | راه کمک در صفحات سازگار بماند | مقایسه مسیرهای فرایند |
| Redundant entry | اطلاعات واردشده دوباره درخواست نشود یا قابل انتخاب باشد | Checkout چندمرحلهای |
| Accessible authentication | Task شناختی اجباری بدون جایگزین نباشد | Password manager، paste و alternative |
Conformance چه معنایی دارد و چه معنایی ندارد؟
- Conformance برای صفحهٔ کامل و فرایند کامل سنجیده میشود؛ Checkout ناقص با Home سالم جبران نمیشود.
- همهٔ Success criterionهای سطح هدف باید در Scope پاس شوند؛ میانگین امتیاز جای Pass/Fail نیست.
- Accessibility-supported technology و روش استفاده باید مشخص باشد.
- ابزار خودکار نمیتواند Conformance کامل را تعیین کند.
- Conformance فنی بهتنهایی تضمین تجربهٔ خوب برای هر فرد نیست؛ Usability و User testing مکملاند.
- Overlay یا Widget خودکار، اصلاح Source و فرایند را جایگزین نمیکند.
فرایند طراحی فراگیر از Discovery تا Delivery
| مرحله | اقدام فراگیر | خروجی |
|---|---|---|
| Scope | Journey بحرانی، جمعیت، Context و هدف WCAG | Accessibility charter و Risk |
| Research | مشارکت افراد دارای معلولیت و تنوع زمینه | Barrier map و Need statement |
| Design | راههای معادل، Content/Interaction spec و Annotation | Prototype و acceptance criteria |
| Build | Native HTML، Component و lint/unit/integration | Accessible component library |
| Test | Automated + Manual + AT + User | Issue log با Severity/Evidence |
| Release | Gate، Known issue، Support و rollback | Conformance/evaluation report محدود |
| Operate | Feedback، regression، content QA و SLA اصلاح | Dashboard و backlog |
افراد دارای معلولیت را چگونه در Research درگیر کنیم؟
- هدف روشن: مسئله و تصمیمی که Study تغییر میدهد مشخص باشد.
- Recruitment متنوع: فقط یک نوع معلولیت یا یک Screen reader expert نمایندهٔ همه نیست.
- دسترسی Session: دعوتنامه، Consent، ابزار تماس، زمان و محل قابل دسترس باشند.
- جبران خدمت منصفانه: زمان، تخصص و هزینهٔ همراه/رفتوآمد در سیاست لحاظ شود.
- فناوری خود فرد: در صورت امکان Participant با AT و تنظیمات خودش کار کند.
- Privacy: فقط دادهٔ لازم جمع و نیاز دسترسی جدا از تشخیص پزشکی ثبت شود.
- تحلیل بدون کلیشه: مشاهده را به Barrier و Context وصل کنید، نه نسبتدادن به «ناتوانی کاربر».
شبیهساز تاری دید، خاموشکردن Mouse یا Persona آموزشی میتواند Awareness بسازد، اما جای مشارکت و آزمون واقعی نیست. برای طراحی Study و تحلیل Task از راهنمای تست کاربردپذیری استفاده کنید.
Barrier map؛ از گروه کاربر به شکست Journey برسید
| Task | Barrier | افراد تحت تأثیر | شدت | Acceptance |
|---|---|---|---|---|
| ورود | CAPTCHA فقط تصویری و Paste مسدود | نابینا، شناختی، motor | Blocker | روش جایگزین و Password manager |
| جستوجو | Autocomplete بدون Name/State/Keyboard | Screen reader و Keyboard | Critical | Pattern و announce نتیجه |
| فرم | Placeholder جای Label | شناختی، کمبینا، voice input | Critical | Label visible/programmatic |
| پرداخت | Timeout بدون هشدار/تمدید | motor، شناختی، اتصال کند | Blocker | هشدار و تمدید/حفظ داده |
| محتوا | ویدئو بیCaption | ناشنوا/کمشنوا، محیط شلوغ | High | Caption دقیق و قابل کنترل |
Severity را از Impact × Reach × Frequency × Workaround بسازید. «فقط ۲٪ کاربران» دفاع مناسبی برای Blocker نیست.
Design token و Component؛ دسترسپذیری را سیستماتیک کنید
اصلاح صفحهبهصفحه مقیاسپذیر نیست. Token و Component باید Stateهای Default، Hover، Focus، Active، Disabled، Error، Loading و High contrast را پوشش دهند.
| لایه | Spec لازم | تست |
|---|---|---|
| Color | Foreground/background pair و non-text state | Contrast در همه Themeها |
| Typography | Scale، line-height، spacing و reflow | Zoom ۲۰۰% و text spacing |
| Focus | Token رنگ/ضخامت/offset و stacking | Visible و not obscured |
| Target | Hit area و spacing | Touch و pointer |
| Motion | duration، trigger و reduced-motion variant | OS preference و pause |
| Semantics | Element/role/name/state و keyboard contract | Accessibility tree و AT |
WCAG حداقل عمومی ۱۶px برای متن تعیین نمیکند. خوانایی را با Resize، Reflow، Contrast، spacing، Font، زبان و Context بسنجید؛ عدد ثابت را جای تست نگذارید.
ساختار Semantic؛ HTML native قبل از ARIA
- برای عمل از
<button>و برای مقصد از<a href>استفاده کنید. - Headingها ساختار محتوا را نشان دهند؛ چند H1 ذاتاً WCAG violation نیست، اما Outline باید منطقی باشد.
- Landmarkهای Header/Nav/Main/Footer و Skip link مسیر سریع بدهند.
- Table دادهای Caption و Header درست داشته باشد؛ Table برای Layout نباشد.
- ARIA رفتار native نمیسازد؛ Role بدون Keyboard/State کامل، کنترل ناقص است.
برای Widgetهای پیچیده مانند Dialog، Tabs، Combobox و Menu، ARIA Authoring Practices Guide الگوی Semantics و Keyboard ارائه میکند؛ APG راهنماست، نه Design system یا جای تست در محصول شما.
Keyboard و Focus؛ فقط Tab و Enter نیست
| Pattern | Interaction مورد انتظار | خطای رایج |
|---|---|---|
| Button | Enter و Space | div با onClick |
| Dialog | Focus ورود، Trap منطقی، Escape، بازگشت Focus | Focus پشت Modal |
| Tabs | Arrow و Home/End مطابق Pattern | Tab stop برای همه Tabها |
| Combobox | Arrow، announce option/state و Escape | نتیجه فقط بصری |
| Menu | Arrow navigation و Escape | بازشدن فقط Hover |
| Carousel | Pause، کنترل Keyboard و announce محدود | Auto-advance بیتوقف |
ترتیب Focus باید با Task و DOM معنادار باشد؛ tabindex مثبت برای وصلهکردن Visual order بدهی میسازد.
فرم دسترسپذیر؛ Label، Help، Error و Recovery
راهنمای فرم W3C توصیه میکند کنترلها Label توصیفی و مرتبط داشته باشند. Placeholder که با تایپ ناپدید میشود جای Label visible نیست.
| جزء | Spec | Test |
|---|---|---|
| Label | متن visible + ارتباط for/id یا روش معتبر | Name در Accessibility tree |
| Instruction | قبل از خطا، نزدیک فیلد و قابل ارجاع | بدون اتکا به Placeholder |
| Required | متن/علامت + programmatic state | رنگ تنها نباشد |
| Error | Summary + field error + پیشنهاد اصلاح | Focus/announce و حفظ داده |
| Format | مثال و inputmode/autocomplete مناسب | Mobile/voice/password manager |
| Submit | حالت Loading و جلوگیری از تکرار بدون قفل مبهم | Slow network و double submit |
در فرم فارسی، تاریخ، شماره ملی/تلفن، کد پستی، مبلغ ریال/تومان، جداکننده و متن خطا را با کاربر واقعی تست کنید. تغییر خودکار رقم فارسی/لاتین نباید داده را خراب کند.
Authentication فراگیر و امن
- Paste و Password manager را مسدود نکنید.
- رمز را قابل نمایش/پنهانسازی با Button نامدار کنید.
- OTP را با autocomplete و ورود دستی قابل استفاده نگه دارید.
- Timeout را پیشاپیش اعلام و امکان تمدید بدهید.
- CAPTCHA شناختی/تصویری اجباری تنها راه نباشد.
- بازیابی حساب و تغییر شماره را به کانال واحد غیرقابل دسترس وابسته نکنید.
- خطا نباید اطلاعات امنیتی افشا کند، اما باید راه بعدی روشن داشته باشد.
تصویر، Icon و Alt؛ هدف را منتقل کنید
| نوع | Alternative | نمونه |
|---|---|---|
| Informative | معنا در Context | نمودار: Insight اصلی در متن/شرح |
| Functional | عمل/مقصد، نه ظاهر | «دانلود فاکتور»، نه «آیکون فلش» |
| Decorative | alt="" | Pattern پسزمینه بدون اطلاعات |
| Text in image | ترجیح متن واقعی؛ معادل کامل | پوستر رویداد با جزئیات متنی |
| Complex | خلاصه کوتاه + توضیح/داده مفصل | Chart با Table/Analysis |
طبق راهنمای تصاویر تزئینی W3C، تصویر بیاطلاعات باید Alt خالی داشته باشد تا Screen reader آن را نادیده بگیرد؛ نبودن Attribute ممکن است نام فایل را اعلام کند. «برای همه تصاویر متن توصیفی بنویسید» قاعدهٔ درستی نیست.
ویدئو و صوت؛ Alternative معادل بر اساس محتوا
- Caption دقیق، همزمان و شامل صدای معنادار برای محتوای دارای گفتار.
- Transcript ساختاریافته برای مرور، Search و دسترسی متنی.
- Audio description وقتی اطلاعات بصری برای فهم ضروری است.
- Player با Keyboard، Label، Focus و کنترل حجم/پخش.
- Autoplay صوتی را اجتناب و Pause/Stop فراهم کنید.
- زیرنویس خودکار را Draft بدانید؛ نام، عدد، اصطلاح و فارسی/انگلیسی بازبینی شوند.
رنگ، Contrast و Theme
Contrast را برای Pair واقعی متن/پسزمینه و Stateها بسنجید. متن عادی در سطح AA معمولاً ۴٫۵:۱ و متن بزرگ ۳:۱ نیاز دارد؛ Component و Focus نیز معیارهای non-text مربوط دارند. اندازه «بزرگ» تعریف فنی دارد؛ آن را از ظاهر حدس نزنید.
- اطلاعات را فقط با رنگ منتقل نکنید؛ Text/Icon/Pattern اضافه کنید.
- Placeholder، Disabled، Error، Focus و Link در همه Themeها تست شوند.
- Dark mode ترجیح است، نه جای Contrast درست در Light mode.
- High contrast/forced colors سیستم را در Component سفارشی امتحان کنید.
- Brand color نامناسب را برای Text role اصلاح کنید، نه اینکه Contrast را دور بزنید.
فارسی، RTL و Bidirectional content
| حوزه | خطر | Test |
|---|---|---|
| Direction | استفاده از text-align بهجای dir | Accessibility tree و متن ترکیبی |
| شماره/کد | جابهجایی رقم، خط تیره و پرانتز | تلفن، IBAN، کد رهگیری و Email |
| Icon | فلش جهتدار اشتباه | Back/Next و Progress |
| Table/Chart | ترتیب ستون و Legend مبهم | Screen reader و Mobile reflow |
| Font | شکل حرف/عدد و وزن ناخوانا | Zoom، Android/iOS/Windows |
| Language | تلفظ متن انگلیسی با زبان فارسی | lang برای قطعهٔ زبان دیگر |
از متن واقعی فارسی، نه Lorem ipsum، در Component و Screenshot regression استفاده کنید.
محتوای فراگیر و زبان روشن
- Outcome و عمل را در ابتدای عنوان/دکمه روشن کنید.
- اصطلاح ضروری را یکبار تعریف و نامها را در Journey ثابت نگه دارید.
- پاراگراف، List، Heading و Summary برای Scan بسازید.
- از زبان تحقیرآمیز، ترحمآمیز یا کلیشهای دربارهٔ معلولیت دوری کنید.
- محدودیت، هزینه، شرط و پیامد تصمیم را پنهان نکنید.
- ترجمهٔ ماشینی را برای متن حقوقی/سلامت/خطای بحرانی بدون Review منتشر نکنید.
سادگی نباید اطلاعات لازم یا اختیار کاربر را حذف کند؛ اصول طراحی اخلاقی و Consent در راهنمای طراحی اخلاقی تکمیل شدهاند.
Motion، زمان و اعلان
prefers-reduced-motionرا برای حرکت غیرضروری رعایت کنید.- حرکت Parallax، Flash و Auto-advance را محدود و قابل توقف کنید.
- Timeout را اعلام، قابل تمدید و در صورت امکان قابل حذف کنید.
- Toast کوتاه تنها مسیر اطلاع نباشد؛ State پایدار و قابل بازگشت بدهید.
- Live region را محدود و متناسب با فوریت استفاده کنید؛ اعلان زیاد Screen reader را مختل میکند.
- Loading state باید Name/State و پایان قابل تشخیص داشته باشد.
Performance و اتصال ضعیف بخشی از Inclusion است
JavaScript سنگین، تصویر بزرگ و Dependency ناپایدار برخی کاربران را بیشتر طرد میکند. Progressive enhancement، HTML معنادار، Cache، Asset budget و Recovery برای شبکهٔ قطعووصلدار ضروریاند.
- عمل اصلی پیش از بار کامل Third-partyها قابل استفاده باشد.
- Form data در خطای شبکه حفظ و ارسال تکراری کنترل شود.
- تصویر Responsive و Font محدود استفاده شود.
- Skeleton باعث Layout shift و گیجی Focus نشود.
- RUM بر اساس Device، Network/ISP و Assistive setting قابل تفکیک باشد، بدون Fingerprinting یا نقض Privacy.
برای Performance budget و Regression از راهنمای Core Web Vitals و RUM استفاده کنید.
AI و طراحی فراگیر؛ Draft، نه داور نهایی
AI میتواند Alt draft، خلاصه، Caption یا کد پیشنهاد دهد، اما Context، صحت و تجربهٔ Assistive Technology را تضمین نمیکند.
- Alt تولیدی را بر اساس هدف تصویر و متن پیرامون Review کنید.
- Caption خودکار نام، عدد، لهجه و Code-switch فارسی/انگلیسی را خطا میکند.
- کد ARIA تولیدی را با Keyboard و Accessibility tree تست کنید.
- دادهٔ معلولیت یا Session پژوهش را بدون Consent/Policy وارد ابزار عمومی نکنید.
- مدل تشخیص معلولیت از رفتار کاربر نسازید؛ ترجیح را از تنظیم/انتخاب محترمانه بگیرید.
مرز Accessibility و SEO
ساختار Semantic، Alt مناسب، Transcript، لینک واقعی و Performance میتوانند هم فهم کاربر و هم Crawl را بهتر کنند، اما Accessibility «فاکتور مستقیم تضمینشدهٔ رتبه» نیست. Conformance را برای حق دسترسی و کیفیت محصول انجام دهید، نه ترفند SEO.
Alt باید هدف تصویر را منتقل کند، نه کلمه کلیدی را تکرار کند. Heading برای Navigation و ساختار است، نه فقط جایدادن عبارت جستوجو. Speed نیز فقط یکی از ابعاد تجربه است.
هرم تست دسترسپذیری
W3C توصیه میکند Accessibility زود و در سراسر توسعه ارزیابی شود و تصریح میکند هیچ ابزار واحدی Conformance را تعیین نمیکند؛ ارزیابی انسانی آگاه لازم است.
| لایه | پوشش | محدودیت | زمان |
|---|---|---|---|
| Lint/static | Attribute و pattern پایه | Context/behavior را نمیفهمد | هر Commit |
| Unit/component | Name/role/state و keyboard contract | Journey و AT واقعی محدود | CI |
| Automated page scan | Contrast، label و ruleهای قابلکدنویسی | فقط بخشی از معیارها | CI/Staging |
| Manual keyboard/zoom | Focus، order، reflow و operation | نیاز مهارت و تکرار | هر Feature/Release |
| Assistive technology | Screen reader، voice، magnification | ترکیبها متنوعاند | مسیر بحرانی |
| User testing | Barrier واقعی، strategy و mental model | Conformance audit کامل نیست | Discovery/Validation |
ماتریس تست پیشنهادی برای سایت فارسی
| محور | ترکیب حداقل | Task |
|---|---|---|
| Keyboard | Tab/Shift+Tab/Enter/Space/Arrow/Escape | Nav، Dialog، Form، Checkout |
| Screen reader | حداقل ترکیبهای هدف محصول روی Desktop/Mobile | Heading، Form، Error، dynamic update |
| Zoom/Reflow | ۲۰۰% و viewport باریک | بدون scroll دوبعدی غیرضروری/پوشاندن عمل |
| Contrast | Light/Dark/High contrast و Stateها | Text، Icon، Focus، Error |
| Motion | Reduced motion | Carousel، transition، loading |
| RTL/Bidi | فارسی + عدد/Email/کد انگلیسی | Form، Table، Breadcrumb، OTP |
| Network | کند/قطع/Retry | حفظ داده و Recovery |
ترکیب Browser/AT را بر اساس Analytics، کاربران و Support matrix انتخاب و نسخهها را ثبت کنید؛ «روی یک Screen reader کار کرد» پوشش جهانی نیست.
Severity و اولویت اصلاح
| سطح | تعریف | نمونه | SLA نمونه |
|---|---|---|---|
| Blocker | Task بحرانی غیرممکن و Workaround معقول ندارد | پرداخت فقط Mouse، CAPTCHA بدون جایگزین | Block release/Hotfix |
| Critical | مانع شدید یا ریسک مستقلبودن | Form بدون Label/Error قابل درک | پیش از Release |
| High | Task ممکن ولی پرخطا/پرهزینه | Focus ضعیف یا Heading آشفته | Sprint جاری/بعد |
| Medium | اصطکاک با Workaround روشن | Link text مبهم | Backlog زماندار |
| Low | بهبود بدون مانع محسوس | توضیح تکمیلی بهتر | Maintenance |
SLA را با Risk سازمان تنظیم کنید؛ معیار WCAG، تعداد کاربران، Frequency و حساسیت Journey در اولویت دخیلاند.
Definition of Done دسترسپذیر
- نیازهای Accessibility و WCAG criterion مرتبط در Story هستند.
- Design annotation شامل name/role/state، Focus، Keyboard، Error و Motion است.
- Component از الگوی تأییدشده Design system استفاده میکند.
- Content، Alt، Heading، Link و Label Review شدهاند.
- Automated scan خطای Blocker/Critical ندارد.
- Manual keyboard، Zoom/Reflow، Contrast و RTL پاس شدهاند.
- Dynamic update با AT هدف آزموده شده است.
- Loading، Empty، Error، Timeout و Offline state پوشش دارند.
- Known issue با Impact، Workaround، Owner و Deadline ثبت است.
- Regression test و Monitoring پس از Release وجود دارد.
RACI؛ مسئولیت فقط با Front-end نیست
| نقش | مسئولیت | تحویل |
|---|---|---|
| Product | Scope، Priority، Risk و Outcome | Charter و roadmap |
| Research | مشارکت فراگیر و Barrier evidence | Need/Barrier map |
| Design | Interaction، visual و annotation | Prototype/spec |
| Content | زبان، Alt، Caption و error copy | Content QA |
| Engineering | Semantic، behavior، tests و fix | Accessible build |
| QA/Accessibility | روش، matrix، evidence و severity | Evaluation report |
| Support | Feedback و راه جایگزین | Issue intake/runbook |
| Procurement/Legal | الزام Supplier و حوزه حقوقی | Contract/acceptance |
ممیزی وبسایت موجود؛ از Critical journey شروع کنید
- Scope صفحه، Template، Component، PDF/Video و Third-party را ثبت کنید.
- هدف WCAG، Browser/AT support و محدودیت حقوقی/قراردادی را تعیین کنید.
- Journeyهای ورود، ثبتنام، جستوجو، خرید/فرم و پشتیبانی را اولویت دهید.
- نمونهای نماینده از Template، State و Locale انتخاب کنید.
- Automated و Manual/AT test را با Evidence اجرا کنید.
- Issue را به Component/Root cause وصل کنید، نه فقط URL.
- Fix را در Design system و CMS guardrail ببرید.
- Regression و User validation را اجرا و Report محدودیتدار منتشر کنید.
یک Badge «Accessible» دائمی نسازید؛ Version، Scope، تاریخ، روش، Known issue و کانال Feedback را شفاف کنید.
مثال فرضی؛ فرم درخواست خدمت در ایران
فرم هفتمرحلهای با OTP، Upload مدرک و پرداخت، نرخ رهاشدگی بالایی دارد. Audit نشان میدهد Labelها Placeholder هستند، Focus پس از خطا گم میشود، Timer OTP تمدید نمیشود، Upload فقط Drag است و مبلغ تومان در API ریال بدون توضیح نمایش داده میشود.
- Journey با کاربران Screen reader، کمبینا، motor و سواد دیجیتال متفاوت تست میشود.
- Label visible، Error summary و Focus management اضافه میشود.
- Drag با File picker و Keyboard معادل میشود.
- OTP Paste/autocomplete، Resend و تمدید زمان میگیرد.
- دادهٔ مرحلههای قبل حفظ و ورود تکراری حذف میشود.
- واحد مبلغ در UI/API/درگاه Contract میشود.
- Task success و Error recovery در کنار Conversion اندازهگیری میشود.
اگر Completion بهتر شود، Attribution را با Before/After کنترلشده یا Experiment و Guardrail بررسی کنید؛ از یک تغییر همزمان نتیجهٔ قطعی نگیرید.
برنامه ۳۰/۶۰/۹۰روزه طراحی فراگیر
| بازه | اقدام | خروجی |
|---|---|---|
| روز ۱ تا ۳۰ | Charter، Scope، Baseline، آموزش نقشمحور و Critical fix | Risk/Barrier map، target و backlog |
| روز ۳۱ تا ۶۰ | Token/Component، Research مشارکتی، Test matrix و CI | Library، DoD و evidence pack |
| روز ۶۱ تا ۹۰ | Journey audit، اصلاح ریشهای، user validation و Feedback loop | Evaluation report، SLA و roadmap فصلی |
چکلیست نهایی طراحی وب فراگیر
- افراد دارای معلولیت در Research/Validation حضور و جبران خدمت دارند.
- هدف WCAG ۲.۲ و Scope محصول صریح است.
- چهار اصل POUR به Acceptance criterion تبدیل شدهاند.
- HTML native بر ARIA سفارشی ترجیح دارد.
- Keyboard pattern، Focus و Escape/Return تعریف شدهاند.
- فرم Label visible، Help، Error و Recovery دارد.
- Authentication با Password manager/Paste و جایگزین قابل استفاده است.
- Alt بر اساس هدف تصویر است؛ تزئینی Alt خالی دارد.
- Caption/Transcript و در صورت نیاز Audio description وجود دارد.
- Contrast همه State/Themeها و Color independence تست شدهاند.
- Zoom، Reflow، Text spacing و High contrast پاس شدهاند.
- فارسی/RTL/Bidi با عدد، Email، کد و واحد واقعی تست شدهاند.
- Reduced motion، Timeout و Live update کنترل دارند.
- Automated، Manual، AT و User test ترکیب شدهاند.
- Blocker/Critical Release gate و SLA دارند.
- Feedback دسترسپذیر، Owner و پیگیری شفاف دارد.
پرسشهای متداول طراحی فراگیر
تفاوت طراحی فراگیر و دسترسپذیری چیست؟
دسترسپذیری بر قابل استفاده بودن فناوری برای افراد دارای معلولیت و معیارهایی مانند WCAG تمرکز دارد. طراحی فراگیر فرایندی گستردهتر برای شناخت طرد، مشارکت افراد متنوع و ساخت راههای معادل است؛ این دو مکملاند.
آیا WCAG ۲.۲ سطح AA برای همه پروژهها کافی است؟
AA Baseline رایجی است، اما هدف واقعی به محصول، کاربران، قرارداد و قانون حوزه بستگی دارد. پاسکردن AA نیز تضمین تجربهٔ عالی برای همه نیست؛ آزمون Usability و کاربران دارای معلولیت لازم است.
آیا ابزار خودکار میتواند دسترسپذیری سایت را تأیید کند؟
خیر. ابزار بخشی از خطاهای قابلکدنویسی را مییابد. Keyboard، Focus، معنی Alt، وضوح خطا، رفتار Screen reader و موفقیت Task به ارزیابی انسانی و User testing نیاز دارند.
آیا همه تصاویر باید Alt توصیفی داشته باشند؟
خیر. تصویر Informative به Alternative متناسب با Context، تصویر Functional به توضیح عمل و تصویر Decorative به alt="" نیاز دارد. توصیف اضافه میتواند برای Screen reader نویز بسازد.
آیا طراحی فراگیر سئو را بهتر میکند؟
برخی روشها مانند Semantic HTML، Alt درست، Transcript و Performance با SEO همراستا هستند، اما Accessibility تضمین رتبه یا ترفند SEO نیست. آن را برای دسترسی و کیفیت بسازید و اثر جستوجو را جدا بسنجید.
جمعبندی؛ فراگیری یک Release نیست، یک سیستم است
طراحی فراگیر با Contrast checker تمام نمیشود. از اینکه چه کسی در Discovery حضور دارد تا Content، Component، CI، Support و Procurement ادامه دارد. WCAG زبان مشترک و Baseline میدهد؛ تجربهٔ افراد دارای معلولیت نشان میدهد این Baseline در جهان واقعی چگونه کار میکند.
بهترین نقطهٔ شروع یک Journey بحرانی است: مانع را با کاربر پیدا کنید، Root cause را در Component و فرایند اصلاح کنید، با Manual/AT/User test اعتبار دهید و Regression را در Definition of Done ببندید. محصولی فراگیرتر است که افراد بیشتری بتوانند مستقل، امن و با اختیار کارشان را کامل کنند.
