Componentها Accessible هستن؛ محصول هم هست؟

یکی از مهم‌ترین مسئولیت‌های یک Design System این است که Accessibility را از ابتدا در Componentها قرار دهد. اگر Button، Input، Select، Modal و سایر Componentهای پایه از نظر Contrast، Keyboard Navigation، Focus، Screen Reader و Stateهای مختلف درست طراحی و پیاده‌سازی شده باشند، تیم‌های محصول دیگر مجبور نیستند هر بار این مسائل را از ابتدا حل کنند.این یکی از ارزش‌های واقعی Design System است، چون بخشی از Accessibility را از یک تصمیم تکراری در هر محصول به یک قابلیت مشترک در سطح سیستم تبدیل می‌کند.اما همین مزیت می‌تواند یک برداشت اشتباه هم ایجاد کند:اگر تمام Componentهای Design System از نظر Accessibility درست باشند، محصولی که با آن‌ها ساخته می‌شود هم Accessible خواهد بود.مشکل این فرض این است که Accessibility فقط ویژگی Component نیست. بخش بزرگی از Accessibility زمانی شکل می‌گیرد که Componentها کنار هم قرار می‌گیرند، Content واقعی وارد آن‌ها می‌شود و کاربر تلاش می‌کند یک Task کامل را انجام دهد.به همین دلیل ممکن است تمام اجزای یک صفحه به‌تنهایی Accessible باشند، اما تجربه‌ای که از ترکیب آن‌ها ساخته شده همچنان Accessibility Problem داشته باشد.

Component می‌تواند درست باشد، اما استفاده از آن اشتباه باشد

فرض کنید Modal موجود در Design System تمام الزامات Accessibility مورد انتظار را رعایت می‌کند. Focus هنگام باز شدن وارد Modal می‌شود، Keyboard Navigation درست کار می‌کند، Screen Reader اطلاعات لازم را دریافت می‌کند و پس از بسته شدن Modal هم Focus به نقطه مناسبی برمی‌گردد.از نظر Component همه‌چیز درست است.حالا تیم محصول همین Modal را برای هر تصمیم کوچک کاربر استفاده می‌کند؛ برای تغییر یک Filter، خروج از یک صفحه، ذخیره یک Draft و حتی نمایش اطلاعاتی که می‌توانست مستقیماً داخل صفحه قرار بگیرد.در این شرایط Accessible بودن خود Modal نمی‌تواند تضمین کند تجربه نهایی مناسب است. Component همان کاری را که برایش طراحی شده درست انجام می‌دهد، اما Product آن را در Context نامناسب استفاده کرده است.همین اتفاق درباره Componentهای ساده‌تر هم می‌تواند رخ دهد. یک Button می‌تواند Keyboard Accessible باشد، Focus State مناسبی داشته باشد و Contrast آن کاملاً استاندارد باشد، اما اگر Label آن مبهم باشد و پنج Button مختلف صفحه همگی «ادامه» نام داشته باشند، کاربر همچنان برای فهمیدن نتیجه هر Action با مشکل روبه‌رو می‌شود.بنابراین باید بین دو سؤال تفاوت بگذاریم:«آیا این Component Accessible است؟» و:«آیا استفاده از این Component در این Context Accessible است؟»Design System می‌تواند برای سؤال اول پاسخ بسیار قوی‌ای فراهم کند، اما سؤال دوم بدون شناخت محصول قابل پاسخ دادن نیست.

Accessibility در Composition هم می‌تواند شکسته شود

مسئله زمانی پیچیده‌تر می‌شود که چند Component سالم را کنار هم قرار می‌دهیم.فرض کنید Heading، Input، Button و Alert موجود در Design System هرکدام به‌صورت مستقل Accessibility مناسبی دارند. تیم محصول با همین Componentها یک Form می‌سازد.کاربر Form را Submit می‌کند، سه Field دارای Error هستند و بالای صفحه یک Alert نمایش داده می‌شود.هر Component همچنان به‌تنهایی درست است، اما سؤال‌های جدیدی ایجاد شده‌اند. آیا کاربر متوجه شده Form ارسال نشده است؟ آیا Screen Reader ایجاد Error را اعلام می‌کند؟ آیا پیام Error مشخص می‌کند مشکل مربوط به کدام Field است؟ آیا Focus باید جابه‌جا شود؟ آیا کاربر می‌تواند سریع اولین Error را پیدا کند؟ اگر چند Error وجود داشته باشد، ترتیب اصلاح آن‌ها قابل فهم است؟هیچ‌کدام از این سؤال‌ها را نمی‌توان صرفاً با بررسی Accessibility خود Input یا Alert پاسخ داد.چون مسئله دیگر در سطح Component نیست؛ در سطح Composition و Flow قرار دارد.همین نکته نشان می‌دهد که Accessibility می‌تواند هنگام عبور از Component به Pattern و از Pattern به Product تغییر کند. یک Design System ممکن است اجزای سالمی ارائه دهد، اما نحوه ترکیب آن‌ها همچنان نیازمند تصمیم‌های Accessibility باشد.

بعضی Accessibility Problemها اصلاً داخل Component دیده نمی‌شوند

اگر Accessibility را فقط در Storybook یا محیط تست Component بررسی کنیم، بخشی از مشکلات اساساً قابل مشاهده نیستند.برای مثال، یک Select می‌تواند در Isolation تمام تست‌های مورد انتظار را پاس کند، اما وقتی داخل یک Form واقعی قرار می‌گیرد، Label نامناسبی داشته باشد. یک Button ممکن است به‌تنهایی Accessible باشد، اما در Flow واقعی ترتیب Focus منطقی نباشد. یک Card ممکن است Markup مناسبی داشته باشد، اما Heading Level آن زمانی که داخل صفحه قرار می‌گیرد ساختار Headingهای کل صفحه را به‌هم بزند.حتی USWDS که Componentهای خود را با روش‌های مختلف از جمله Screen Reader، Keyboard، Zoom، Touch، ابزارهای Automated و تست دستی بررسی می‌کند، تأکید می‌کند که Componentها در Isolation تست می‌شوند و تیم محصول باید Implementation واقعی را در Context خودش دوباره بررسی کند.این تفاوت مهم است، چون Component Test می‌تواند کیفیت Building Block را بررسی کند، اما نمی‌تواند تمام کیفیت تجربه‌ای را که بعداً با آن ساخته می‌شود پیش‌بینی کند.

شاید Accessibility را باید در چند سطح ببینیم

برای جلوگیری از این شکاف، می‌توانیم Accessibility در Design System را نه یک Check واحد، بلکه در سه سطح بررسی کنیم.سطح اول Component Accessibility است. در این سطح بررسی می‌کنیم خود Building Block چگونه کار می‌کند؛ Contrast، Focus State، Keyboard Interaction، Semantic Markup، Screen Reader Behavior، Touch Target و Stateهای مختلف در همین سطح قرار می‌گیرند.سطح دوم Composition Accessibility است. اینجا سؤال دیگر درباره یک Component مستقل نیست، بلکه درباره رابطه Componentهاست. Focus بین چند Element چگونه حرکت می‌کند؟ Headingها چه Hierarchyای می‌سازند؟ Errorها چگونه به Fieldها مرتبط می‌شوند؟ وقتی State صفحه تغییر می‌کند آیا کاربر از آن مطلع می‌شود؟ آیا ترتیب Content در تجربه واقعی همچنان قابل فهم است؟سطح سوم Journey Accessibility است. در این سطح باید ببینیم آیا کاربر واقعاً می‌تواند Task را از ابتدا تا انتها انجام دهد. ممکن است تمام Screenهای یک Flow به‌صورت جداگانه استاندارد باشند، اما یک کاربر Keyboard-only یا Screen Reader در مرحله‌ای از Journey نتواند ادامه دهد، نتواند خطا را اصلاح کند یا متوجه نتیجه Action خودش نشود.این سه سطح یک استاندارد رسمی نیستند، بلکه یک مدل پیشنهادی برای مشخص کردن محدوده مسئولیت Accessibility در Design System هستند:Component → Composition → Journeyهرچه از Component به Journey نزدیک‌تر می‌شویم، Context محصول اهمیت بیشتری پیدا می‌کند و Design System کنترل مستقیم کمتری روی نتیجه دارد.

Design System باید Accessibility را تا کجا بر عهده بگیرد؟

ممکن است از این بحث نتیجه بگیریم که اگر Accessibility در نهایت به Context محصول وابسته است، پس مسئولیت Design System فقط ساخت Componentهای Accessible است.اما این مرز هم کافی نیست.اگر Design System فقط Component سالم تحویل دهد و هیچ Guidanceای درباره استفاده Accessible از آن ارائه نکند، بخشی از دانش لازم برای حفظ Accessibility را به تیم محصول منتقل نکرده است.برای مثال، ارائه یک Modal Accessible کافی نیست. Documentation باید توضیح دهد چه زمانی Modal انتخاب مناسبی است، Focus چگونه باید مدیریت شود و چه نوع Content یا Interactionهایی ممکن است استفاده از آن را مسئله‌دار کنند.همین موضوع درباره Formها، Error Handling، Navigation، Notifications و بسیاری از Patternهای دیگر وجود دارد.در واقع Design System نمی‌تواند تمام Contextهای آینده را کنترل کند، اما می‌تواند احتمال تصمیم Accessible را افزایش دهد.این تفاوت کوچکی نیست.هدف Design System نباید این باشد که بگوید «اگر Componentهای ما را استفاده کنید، Accessibility حل شده است». هدف بهتر این است که Accessible Path را برای تیم‌های محصول به ساده‌ترین مسیر تبدیل کند؛ یعنی Defaultها درست باشند، Guidance واضح باشد و شکستن Accessibility نیازمند تصمیم آگاهانه باشد، نه اینکه رعایت Accessibility نیازمند دانش تخصصی در هر بار استفاده باشد.

شاید Accessibility یک ویژگی قابل انتقال نباشد

اینجا به یکی از مهم‌ترین محدودیت‌های Design System می‌رسیم.بسیاری از ویژگی‌های Component تقریباً همراه آن منتقل می‌شوند. اگر Button از Token مشخصی برای Border Radius استفاده کند، هرجا Component را ببریم همان Radius را خواهیم داشت. اگر Typography داخل Component تعریف شده باشد، همان Style هم منتقل می‌شود.اما Accessibility همیشه این‌طور رفتار نمی‌کند.بخشی از آن داخل Component قابل Encode شدن است، اما بخش دیگری فقط در Context معنا پیدا می‌کند.یک Component می‌تواند Accessible Name را پشتیبانی کند، اما Design System نمی‌تواند تضمین کند تیم محصول نام مناسبی برای آن نوشته است. سیستم می‌تواند Error State فراهم کند، اما نمی‌تواند تضمین کند Error Message قابل فهم است. می‌تواند Focus Management مناسب داخل Dialog ایجاد کند، اما نمی‌تواند تصمیم بگیرد آیا این Interaction اصلاً باید Dialog باشد.بنابراین شاید بهتر باشد Accessibility را یک Property کاملاً قابل انتقال از Design System به Product نبینیم.Design System می‌تواند Accessibility Capacity ایجاد کند، اما محصول همچنان باید آن ظرفیت را درست استفاده کند.

پس موفقیت Accessibility در Design System را چطور بسنجیم؟

اگر فقط تعداد Componentهایی را که Accessibility Test را پاس کرده‌اند اندازه بگیریم، درواقع فقط سطح اول مسئله را اندازه گرفته‌ایم.این Metric همچنان ارزشمند است، اما کافی نیست.یک سیستم می‌تواند گزارش کند که ۹۵ درصد Componentهایش تست Accessibility دارند و هم‌زمان محصولاتی که با همان Library ساخته شده‌اند مشکلات جدی در Keyboard Flow، Content Structure، Form Errors یا Screen Reader Experience داشته باشند.برای همین بهتر است کنار Component Compliance، سؤال‌های دیگری هم مطرح شوند: آیا Patternهای پرتکرار Accessibility Guidance دارند؟ آیا تیم‌ها Implementation واقعی را در Context محصول تست می‌کنند؟ آیا مشکلات Accessibility کشف‌شده در محصولات دوباره به Design System برمی‌گردند؟ آیا مسئله‌ای که در یک Product پیدا شده می‌تواند در Component یا Documentation اصلاح شود تا محصولات دیگر دوباره همان اشتباه را تکرار نکنند؟اینجا Design System می‌تواند نقش مهم دیگری داشته باشد؛ نه فقط توزیع Componentهای Accessible، بلکه توزیع Learning حاصل از Accessibility Problems در کل سازمان.اگر یک تیم متوجه شود Pattern خاصی در Form Validation برای Screen Reader مشکل ایجاد می‌کند، این نباید فقط به‌عنوان Bug همان Product بسته شود. باید بررسی شود آیا Component، Pattern یا Documentation سیستم می‌تواند تغییر کند تا احتمال تکرار همان مشکل در محصولات دیگر کاهش پیدا کند.در این حالت Accessibility از یک Checklist قبل از Release به یک Feedback Loop تبدیل می‌شود:System → Product → Testing → Finding → Systemهر بار که مسئله‌ای در Context واقعی کشف می‌شود، بخشی از آن Learning می‌تواند دوباره وارد سیستم شود و Defaultهای آینده را بهتر کند.

جمع‌بندی

Accessible بودن Componentهای Design System اهمیت زیادی دارد، اما فقط نقطه شروع است.یک Button می‌تواند کاملاً Accessible باشد و در Context اشتباه استفاده شود. یک Input می‌تواند تمام تست‌های خودش را پاس کند، اما در Form واقعی Error Experience نامناسبی ایجاد شود. چند Component سالم هم می‌توانند در کنار هم Flowای بسازند که برای Keyboard یا Screen Reader قابل استفاده نباشد.برای همین شاید بهتر باشد Accessibility را در سه سطح ببینیم:Component → Composition → JourneyDesign System بیشترین کنترل را روی سطح اول دارد، می‌تواند برای سطح دوم Pattern و Guidance فراهم کند و در سطح سوم باید به تیم‌های محصول کمک کند تجربه واقعی را با کاربران، Assistive Technology و روش‌های مختلف Testing ارزیابی کنند.بنابراین سؤال مهم برای یک Design System فقط این نیست که:«چند درصد Componentهای ما Accessible هستند؟»سؤال مهم‌تر این است:«آیا محصولاتی که با این Componentها ساخته می‌شوند، همچنان می‌توانند Accessible باقی بمانند؟»تفاوت این دو سؤال، مرز بین Accessible Components و Accessible Experiences است.

منابع