طراحی برای نورودایورسیتی؛ COGA، WCAG و تست واقعی

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

نورودایورجنت‌ها یک گروه همگن نیستند. دو فرد اوتیستیک، دو فرد دارای ADHD یا دو خواننده دارای نارساخوانی ممکن است ترجیحات متفاوت یا حتی متعارض داشته باشند. یک نفر Motion را مزاحم می‌داند و دیگری از همان Motion برای فهم تغییر وضعیت کمک می‌گیرد. یک نفر متن کوتاه می‌خواهد و دیگری برای اعتماد به جزئیات نیاز دارد. بنابراین «پالت آرام»، «فونت مخصوص» یا «حالت تمرکز» به‌تنهایی طراحی فراگیر نمی‌سازند.

نورودایورسیتی، نورودایورجنت و دسترسی شناختی چه تفاوتی دارند؟

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

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

W3C در معرفی موانع شناختی و یادگیری بر گستردگی تفاوت‌ها، نامرئی‌بودن بسیاری از آن‌ها و احتمال نداشتن یا افشا نکردن تشخیص رسمی تأکید می‌کند. پس برای تحقیق محصول، اثبات تشخیص شرط مناسبی نیست؛ درباره مانع، روش ارتباط و Accommodation موردنیاز بپرسید.

زبان محترمانه را از خود افراد بپرسید

برخی افراد زبان هویت‌محور مانند «فرد اوتیستیک» و برخی زبان فردمحور مانند «فرد دارای اوتیسم» را ترجیح می‌دهند. در متن عمومی می‌توان هر دو را با دقت به‌کار برد، اما در تحقیق و ارتباط فردی ترجیح مشارکت‌کننده مقدم است. از «عادی» در برابر «نورودایورجنت»، «مبتلا» به‌عنوان پیش‌فرض، یا ادعای الهام‌بخش/قهرمانانه پرهیز کنید.

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

پنج میان‌بُر جذاب که شواهد کافی ندارند

یک پژوهش روی کودکان دارای نارساخوانی، برتری فونت Dyslexie را نسبت به گزینه مقایسه‌شده تأیید نکرد و اثر فاصله را برجسته کرد؛ این نتیجه نیز حکم جهانی برای همه زبان‌ها نیست. رکورد پژوهش در PubMed یادآور می‌شود که «بهترین فونت» باید با زبان، خط، محتوا و کاربران هدف آزموده شود، نه با نام تجاری فونت.

WCAG ۲.۲ و COGA؛ کدام الزام است و کدام راهنمای تکمیلی؟

WCAG 2.2 استاندارد W3C با معیارهای قابل‌آزمون در سطوح A، AA و AAA است و در ۵ اکتبر ۲۰۲۳ Recommendation شد. Conformance باید برای صفحه/Process کامل، سطح هدف و روش آزمون مستند شود؛ انتخاب چند معیار دلخواه معادل «WCAG compliant» نیست.

راهنمای Making Content Usable از گروه COGA در W3C یک Working Group Note است، نه مجموعه الزام‌های Conformance. الگوهای آن نیازهای شناختی و یادگیری را فراتر از WCAG ۲.x پوشش می‌دهند: فهم کنترل‌ها، پیداکردن محتوا، متن روشن، جلوگیری و اصلاح خطا، تمرکز، کاهش اتکا به حافظه، کمک و پشتیبانی و شخصی‌سازی.

راهنمای طراحی فراگیر وب و WCAG ۲.۲ Conformance، Keyboard، Screen reader، ARIA و Governance عمومی را پوشش می‌دهد. این مقاله مالک لایه شناختی/نورودایورسیتی و تبدیل Barrier به الگوی طراحی و Research است.

از Diagnosis به Barrier Contract بروید

Personaهایی مانند «علی، ۲۸ساله، ADHD دارد» اقدام طراحی مشخصی تولید نمی‌کنند و خطر کلیشه دارند. Barrier Contract باید به این پرسش‌ها پاسخ دهد:

یک Barrier می‌تواند برای چند گروه مهم باشد و یک تشخیص می‌تواند چند Barrier متفاوت داشته باشد. Backlog را با Barrier و Impact مرتب کنید، نه با تعداد برچسب‌های پزشکی فرضی.

محتوای روشن؛ ساده‌سازی بدون تحقیر

Plain language به معنای کودکانه‌نویسی یا حذف اطلاعات مهم نیست. هدف این است که مخاطب در اولین خواندن، منظور را بفهمد و بداند چه کاری انجام دهد. هدف COGA برای محتوای روشن و قابل‌فهم الگوهای تکمیلی را ارائه می‌کند.

• نتیجه و اقدام اصلی را پیش از جزئیات قرار دهید؛
• یک اصطلاح را برای یک مفهوم حفظ کنید؛ «سبد»، «کیف» و «Cart» را بی‌دلیل جابه‌جا نکنید؛
• عنوان‌ها را توصیفی و ساختار را قابل‌اسکن کنید؛
• دستور را به گام‌های واقعی بشکنید و پیش‌نیاز را قبل از شروع بگویید؛
• استعاره، کنایه و طنز را در پیام‌های عملیاتی با احتیاط به‌کار ببرید؛
• مثال درست و نمونه فرمت ورودی را کنار فیلد نشان دهید؛
• Summary را کنار جزئیات قابل‌گسترش ارائه کنید؛ جزئیات حیاتی را پنهان نکنید؛
• تصویر، Diagram یا صوت را به‌عنوان مسیر مکمل و با جایگزین متنی ارائه دهید.

قرارداد محتوای فارسی

در فارسی، طول جمله تنها مسئله نیست. واژه عربی/انگلیسی نامأنوس، نیم‌فاصله نامنظم، عدد فارسی/لاتین، تومان/ریال و تاریخ شمسی/میلادی می‌توانند بار اضافی بسازند. Policy محصول باید واحد پول، فرمت تاریخ، شیوه نمایش شماره سفارش و معادل اصطلاحات را روشن کند.

جزئیات `lang`، `dir`، Bidi، تایپوگرافی، اعداد، فرم و QA در راهنمای طراحی سایت فارسی و RTL آمده است.

پیداکردن مسیر؛ ناوبری و معماری اطلاعات

بار شناختی اغلب از Taxonomy سازمانی و مسیرهای نامعلوم می‌آید، نه از رنگ صفحه. ناوبری باید نشان دهد کاربر کجاست، چه گزینه‌هایی دارد و بازگشت چه اثری دارد.

• نام دسته و لینک را بر اساس واژگان کاربر انتخاب کنید؛
• مسیرهای اصلی را در جای ثابت نگه دارید؛
• صفحه جاری، Breadcrumb و مرحله فرایند را واضح کنید؛
• Search را با غلط املایی، ی/ک، نیم‌فاصله و واژه مترادف فارسی تست کنید؛
• گزینه‌ها را گروه‌بندی کنید اما مسیر حیاتی را پشت Hover یا منوی مبهم پنهان نکنید؛
• Back باید State و داده واردشده را حفظ کند؛
• Help مرتبط با همان Task و قابل‌یافتن در محل ثابت باشد.

برای Taxonomy، Tree test و Navigation governance به راهنمای ساختار سایت و معماری اطلاعات مراجعه کنید.

تمرکز و توجه؛ مزاحمت را حذف کنید، نه Context را

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

• در هر View یک اقدام اصلی روشن و اقدامات ثانویه با سلسله‌مراتب قابل‌تشخیص داشته باشید؛
• Popup، Badge، Toast و Notification هم‌زمان را محدود و Queue کنید؛
• تبلیغ، Chat bubble و CTA چسبان نباید کنترل یا متن حیاتی را بپوشاند؛
• در Task طولانی، گام فعلی، گام بعد و امکان خروج امن را نشان دهید؛
• پس از وقفه، Summary وضعیت و «ادامه از کجا» ارائه کنید؛
• حالت Focus اختیاری باشد؛ دسترسی به Help و جزئیات را قطع نکند.

اعلان باید قابل‌کنترل و قابل‌بازیابی باشد

Toast سه‌ثانیه‌ای که ناپدید می‌شود، برای کاربری که توجهش جای دیگری است قابل اتکا نیست. پیام مهم را در History یا وضعیت صفحه نگه دارید، کانال و Frequency را قابل‌تنظیم کنید و Action فوری را فقط وقتی بخواهید که واقعاً Deadline دارد.

پیش‌بینی‌پذیری و کنترل

کنترل یکسان باید نام و رفتار یکسان داشته باشد. تغییر Context ناگهانی، Submit خودکار، بازشدن Tab بدون هشدار یا عوض‌شدن ترتیب گزینه‌ها می‌تواند نقشه ذهنی را بشکند.

فرم، خطا و Recovery؛ حافظه را شرط موفقیت نکنید

فرم خوب فقط کوتاه نیست. گاهی حذف Label یا توضیح برای کوتاه‌کردن صفحه، Task را سخت‌تر می‌کند. هر فیلد باید Purpose، Format، Requirement، Error و Recovery مشخص داشته باشد.

• Label پایدار و Programmatic داشته باشید؛ Placeholder جای Label نیست؛
• Required/Optional و دلیل درخواست داده حساس را قبل از ورود نشان دهید؛
• `autocomplete` و Input purpose مناسب را فعال کنید؛
• Paste را برای رمز، OTP، کد ملی یا شماره پیگیری مسدود نکنید؛
• اعداد فارسی/لاتین و فاصله‌های رایج را Normalize کنید؛
• اطلاعاتی را که در همان Process داده شده دوباره نخواهید یا Auto-populate کنید؛
• Error را کنار فیلد و در Summary بالای فرم با لینک Focus ارائه کنید؛
• مقدار درست را حفظ کنید و فقط مورد خطادار را اصلاح بخواهید؛
• پیش از اقدام مهم، Review و امکان Correction؛ پس از آن Receipt و Undo/Recovery ممکن؛
• در فرایند طولانی Save/Resume و زمان انقضای قابل‌فهم داشته باشید.

برای طراحی Message، فرم و Measurement در Conversion، راهنمای لندینگ پیج و فرم مرز تجاری این موضوع را تکمیل می‌کند.

نمونه ایرانی: OTP، کد ملی و درگاه

کاربر شماره موبایل را وارد می‌کند، برای خواندن پیامک از Browser خارج می‌شود و صفحه Reload می‌شود. راه‌حل فقط افزایش Timer نیست: State باید حفظ شود؛ OS autofill و Paste کار کند؛ شماره مقصد Mask‌شده دیده شود؛ «ارسال دوباره» زمان روشن داشته باشد؛ تغییر شماره ممکن باشد؛ Error علت و اقدام بعد را بگوید؛ و پس از بازگشت از درگاه، وضعیت پرداخت با شماره پیگیری قابل بازیابی باشد.

احراز هویت بدون آزمون حافظه

WCAG ۲.۲ معیار ۳.۳.۸ Accessible Authentication (Minimum) می‌خواهد آزمون عملکرد شناختی مانند به‌خاطرسپردن یا حل معما شرط ورود نباشد، مگر راه جایگزین یا سازوکار کمک وجود داشته باشد. Password manager، Autofill و Copy/Paste نمونه سازوکار کمک‌اند.

• Managerها را با `autocomplete` نادرست یا فیلد سفارشی نشکنید؛
• ورود OTP را از Clipboard و Autofill پشتیبانی کنید؛
• CAPTCHA شناختی را تنها مسیر نگذارید؛
• Recovery را از Login اصلی سخت‌تر و مبهم‌تر نسازید؛
• Session timeout را اعلام و امکان تمدید بدهید؛
• امنیت را با Rate limit، Risk-based control و Verification مناسب حفظ کنید؛ دسترس‌پذیری به معنای حذف امنیت نیست.

زمان، حافظه و Taskهای طولانی

Deadline نامرئی و Timeout کوتاه می‌تواند پرونده سلامت، ثبت‌نام آموزشی یا خرید را از بین ببرد. زمان لازم را از روی حدس تیم تعیین نکنید؛ با کاربران و شبکه واقعی آزمایش کنید.

Motion، صدا، رنگ و حساسیت حسی

یک «پالت نورودایورجنت» وجود ندارد. رنگ باید Contrast، معنا، Brand و ترجیح کاربر را با هم پاسخ دهد؛ معنا را فقط با رنگ منتقل نکنید. Dark mode نیز برای همه بهتر نیست و کنتراست یا Halo می‌تواند خواندن را دشوار کند.

• صدا و ویدئو را خودکار شروع نکنید مگر ضروری و قابل‌کنترل؛
• برای محتوای متحرک طبق WCAG 2.2 Pause, Stop, Hide کنترل فراهم کنید؛
• Motion تزئینی را در ترجیح کاهش حرکت حذف یا جایگزین کنید؛
• Focus، Error و تغییر وضعیت را فقط با Animation اعلام نکنید؛
• فلش و الگوهای خطرناک را مطابق معیارهای Seizure/physical reaction کنترل کنید؛
• تنظیم صدا، Caption/Transcript و امکان Pause را فراهم کنید؛
• فضای سفید را ابزار Grouping بدانید، نه هدف زیبایی؛ فاصله بیش از حد نیز ارتباط را مبهم می‌کند.

ویژگی CSS در MDN برای `prefers-reduced-motion` از ژانویه ۲۰۲۰ Baseline و فراگیر است. مقدار `reduce` به معنای ترجیح کاهش Motion غیرضروری است، نه الزام به خاموش‌کردن همه بازخوردها. نسخه Reduced را مانند نسخه اصلی QA کنید.

فونت و خوانایی فارسی؛ انتخاب را به یک نام تقلیل ندهید

خوانایی حاصل سیستم است: شکل حروف و تمایز Glyph، اندازه مؤثر، Line height، فاصله، طول خط، Weight، کنتراست، Render دستگاه، Zoom، جهت متن و آشنایی خواننده. نسخه لاتین Arial یا OpenDyslexic درباره فونت فارسی پاسخ قطعی نمی‌دهد.

• فونتی با پوشش کامل فارسی، اعداد، علائم و Weight واقعی انتخاب کنید؛
• متن بلند را Justify کامل نکنید اگر فاصله‌های نامنظم می‌سازد؛
• Zoom، Text spacing override و Reflow را بدون قطع/هم‌پوشانی پاس کنید؛
• عرض خط و Line height را با مقاله، فرم و جدول جدا تست کنید؛
• Bold و رنگ را تنها روش برجسته‌سازی نکنید؛ سلسله‌مراتب معنایی حفظ شود؛
• اگر انتخاب فونت/فاصله می‌دهید، کنترل ساده، قابل‌بازگشت و Persistشونده باشد.

شخصی‌سازی با اختیار کاربر، نه استنتاج تشخیص

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

Choice باید منصفانه باشد. استفاده از فشار زمانی، Shame، Confirmshaming یا Consent نامتقارن با دسترسی شناختی تعارض دارد؛ راهنمای طراحی اخلاقی و حذف Dark pattern این مرز را پوشش می‌دهد.

تحقیق UX با افراد نورودایورجنت

تیم نباید فقط با Persona یا Caregiver درباره افراد طراحی کند. مشارکت مستقیم، با Accommodation و رضایت، ضروری است. W3C توصیه می‌کند درگیرکردن کاربران دارای معلولیت را با ارزیابی Conformance ترکیب کنید؛ هیچ‌کدام جای دیگری را نمی‌گیرد.

Recruitment بدون Gate پزشکی

• Screener بر تجربه Task و مانع تمرکز کند؛ مدرک تشخیص نخواهید مگر دلیل اخلاقی/پژوهشی موجه و مصوب دارید؛
• تنوع در شیوه ارتباط، سطح حمایت، سواد، سن، جنسیت، شهر، دستگاه و تجربه دیجیتال را جست‌وجو کنید؛
• Caregiver یا Support person در صورت خواست فرد حضور داشته باشد، اما صدای او را جایگزین نکنید؛
• جبران خدمت را شفاف، منصفانه و مستقل از «عملکرد خوب» پرداخت کنید؛
• تعداد شرکت‌کننده قانون جادویی ندارد؛ Coverage مانع‌ها، Severity و تکرار دورها را مستند کنید.

Accommodation را پیش از جلسه بپرسید

یک فرم کوتاه و اختیاری بپرسد: فرمت اطلاعات، کانال ارتباط، Camera، زمان/وقفه، نور/صدا، حضور Support person، نیاز به Caption، سؤال‌های ازپیش‌ارسال‌شده یا جلسه Asynchronous. پاسخ‌ها را فقط برای اجرای مطالعه، با Retention محدود نگه دارید.

تسهیل‌گری؛ رفتار متفاوت را خطا ندانید

Think aloud برای همه راحت نیست؛ سکوت، حرکت تکراری، نگاه‌نکردن به دوربین یا پاسخ کتبی نشانه بی‌همکاری نیست. Task را نتیجه‌محور و بدون آموزش راه‌حل بنویسید. زمان را ثبت کنید اما فشار زمانی نسازید. اگر کمک لازم شد، نوع و نقطه Assistance را ثبت کنید.

روش Research plan، Consent، Task، Moderation و Severity در راهنمای تست کاربردپذیری با جزئیات آمده است.

چه چیزی را در آزمون اندازه بگیریم؟

Severity را با Blocker بودن، پیامد، تکرار، تعداد مسیرهای جایگزین و خطر برای کاربر بسازید. «سه نفر مشکل داشتند» بدون توضیح نمونه و Context، نرخ جمعیتی نیست.

پشته آزمون؛ ابزار خودکار کافی نیست

1. Lint و automated scan: خطاهای قابل‌ماشین مانند نام accessible یا Contrast مشخص؛
2. بازبینی دستی WCAG: Keyboard، Focus، Zoom/Reflow، Text spacing، Motion، Form و Authentication؛
3. بازبینی محتوا/COGA: واژگان، Instructions، Error، Help، Memory و Predictability؛
4. Task test با کاربران: Barrier، Workaround، Assistance، Recovery و احساس کنترل؛
5. Production telemetry: Abandonment، Retry، Timeout، Support contact و Feedback با Privacy؛
6. Regression: Component و Journeyهای حیاتی در هر Release.

W3C درباره درگیرکردن کاربران در ارزیابی صریح است که تجربه یک فرد همه افراد را نمایندگی نمی‌کند و User evaluation جای Conformance evaluation را نمی‌گیرد. هر دو را در Definition of Done بگذارید.

ماتریس پذیرش نمونه

برای تبدیل Task، Success، Error، Recovery و QA به قرارداد تحویل، راهنمای طراحی سایت کاربرپسند و Usability QA مفید است.

سناریوهای واقعی برای محصول فارسی و ایران

سامانه آموزشی و ثبت‌نام

فهرست مدارک را پیش از شروع بدهید؛ Draft را ذخیره کنید؛ واژه اداری را توضیح دهید؛ تاریخ شمسی را کامل بنویسید؛ Deadline و Timezone روشن باشد؛ آپلود شکست‌خورده از ابتدا شروع نشود؛ و شماره پیگیری قابل‌کپی بماند.

نوبت و خدمت حساس

نام خدمت و پیامد انتخاب باید مستقیم باشد؛ اطلاعات سلامت را برای Personalization غیرضروری جمع نکنید؛ زمان جلسه و مدارک خلاصه شوند؛ Cancel/Reschedule قابل‌یافتن باشد؛ و Error نباید فرد را با پیام مبهم رها کند. در تصمیم حساس، Human support روشن ارائه دهید.

فروشگاه و پرداخت

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

پشتیبانی و چت

ربات نباید مسیر انسان را پنهان کند. Transcript، وضعیت پرونده، شماره پیگیری، زمان پاسخ و امکان بازگشت فراهم شود. چند سؤال را هم‌زمان نپرسید و وقتی Bot نمی‌داند، Context را همراه پرونده به اپراتور منتقل کنید.

حریم خصوصی، افشا و Stigma

در برخی محیط‌های ایرانی، افشای تشخیص یا تفاوت عصبی ممکن است پیامد اجتماعی، تحصیلی یا شغلی داشته باشد. محصول نباید برای ارائه یک تنظیم ساده، کاربر را به اعلام تشخیص وادار کند.

• Preference را از Diagnosis جدا کنید؛
• هدف، Retention، دسترسی و حذف داده Research را روشن کنید؛
• ضبط صدا/تصویر جداگانه و اختیاری باشد؛
• نقل‌قول را De-identify کنید و رضایت استفاده بگیرید؛
• Analytics را برای تشخیص یا امتیازدهی افراد به‌کار نبرید؛
• Accommodation نباید در اختیار مدیر یا تبلیغات قرار گیرد مگر رضایت و ضرورت روشن؛
• مسیر حذف یا پس‌گرفتن رضایت عملی باشد.

Workflow تیم؛ از Research تا Regression

فرایند عمومی Research→Design→Prototype→Test→Measure در راهنمای تجربه کاربری UX آمده است؛ این مقاله Acceptanceهای ویژه دسترسی شناختی را به آن اضافه می‌کند.

برنامه ۹۰روزه برای یک تیم محصول

چک‌لیست طراحی برای نورودایورسیتی

• Task، Context و Barrier به‌جای Persona تشخیصی ثبت شده است؛
• WCAG ۲.۲ level و Scope صفحه/Process مشخص است؛
• الگوهای COGA مرتبط به Requirement و Acceptance نگاشت شده‌اند؛
• عنوان، Label، Instruction و Error مستقیم و سازگارند؛
• Summary و جزئیات هر دو در دسترس‌اند؛
• Navigation، Help و کنترل‌ها جای ثابت و رفتار قابل‌پیش‌بینی دارند؛
• Form داده معتبر را حفظ و خطا را قابل‌اصلاح می‌کند؛
• Paste، Autofill و Password manager مسدود نشده‌اند؛
• Timeout هشدار/تمدید و Task طولانی Save/Resume دارد؛
• اعلان مهم History و کنترل Frequency دارد؛
• Motion/Audio قابل‌کنترل و Reduced-motion تست شده است؛
• فونت فارسی با Zoom، Text spacing، طول خط و دستگاه واقعی آزموده شده است؛
• Preferences اختیاری، قابل‌بازگشت و بدون استنتاج Diagnosis هستند؛
• کد ملی، موبایل، OTP، تومان، تاریخ و Bidi با Fixture واقعی تست شده‌اند؛
• افراد نورودایورجنت با Accommodation و جبران منصفانه مشارکت کرده‌اند؛
• Consent، ضبط، Retention و حذف داده Research روشن است؛
• Task success، Comprehension، Error، Assistance و Recovery ثبت می‌شوند؛
• Automated، manual، Content و User testing با هم اجرا شده‌اند؛
• Issueها Owner، Severity، SLA و Regression test دارند؛
• Known limitation و مسیر Support برای کاربر قابل‌یافتن است.

جمع‌بندی؛ طراحی برای تفاوت، با شواهد نه کلیشه

طراحی برای نورودایورسیتی یک Theme آرام، فونت خاص یا فهرست «برای اوتیسم/برای ADHD» نیست. محصول باید تفاوت نیازها را تحمل کند: متن قابل‌فهم و در عین حال کامل، مسیر قابل‌پیش‌بینی، حافظه و زمان کمتر، Recovery، کنترل Motion و اعلان، تنظیمات اختیاری، احراز هویت دسترس‌پذیر و Privacy.

WCAG ۲.۲ کف قابل‌آزمون را می‌دهد؛ COGA الگوهای شناختی تکمیلی را روشن می‌کند؛ اما شواهد نهایی از Task واقعی و مشارکت محترمانه کاربران می‌آید. اگر تیم هر Barrier را به Requirement و Acceptance test تبدیل، Release را Gate و Failure را در Production دنبال کند، «فراگیری» از شعار به کیفیت محصول تبدیل می‌شود.

سؤالات متداول طراحی برای نورودایورسیتی

آیا نورودایورسیتی همان ناتوانی است؟

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

آیا پاس‌کردن WCAG ۲.۲ برای دسترسی شناختی کافی است؟

WCAG ۲.۲ کف ضروری و قابل‌آزمون است، اما همه نیازهای شناختی در معیارهای Normative آن پوشش داده نشده‌اند. الگوهای تکمیلی COGA، بازبینی محتوا و آزمون با افراد دارای نیازهای متنوع باید کنار Conformance اجرا شوند.

بهترین فونت و رنگ برای کاربران دارای نارساخوانی یا اوتیسم چیست؟

یک فونت یا پالت جهانی وجود ندارد. برای فارسی، پوشش Glyph، اندازه، فاصله، طول خط، کنتراست، Zoom، Text spacing و ترجیح فرد مهم‌اند. Default باید قابل‌استفاده باشد و در صورت امکان کنترل‌های ساده و قابل‌بازگشت ارائه شود؛ نتیجه را با کاربران هدف بسنجید.

چگونه بدون درخواست مدرک تشخیص با کاربران تست کنیم؟

Recruitment را بر تجربه Task و موانع موردنظر بنا کنید و Accommodation، کانال ارتباط و ترجیحات جلسه را اختیاری بپرسید. تشخیص را فقط وقتی جمع کنید که ضرورت پژوهشی روشن، رضایت، حفاظت داده و روش اخلاقی متناسب دارید. رفتار جلسه را به تشخیص تبدیل نکنید.

با بودجه کم از کجا شروع کنیم؟

یک Journey حیاتی مانند ورود، فرم یا پرداخت را انتخاب کنید؛ WCAG/COGA و Ticketهای پشتیبانی را مرور کنید؛ Label/Error/State/Timeout/Paste/Save را اصلاح کنید؛ سپس Prototype را با چند مشارکت‌کننده متنوع در دورهای تکرارشونده آزمایش کنید. موفقیت را با Task، Recovery و Critical error بسنجید، نه تعداد نکته‌های چک‌لیست.