دسترسپذیری کجای مسیر توسعه گم میشه؟
فرانتاندخلاصهٔ کاملتر
نیک استینهوت میگه بارها موقع بررسی طراحی قبل از توسعه، جلسه با یه جواب خیالتراحتکن تموم شده: «این میتونه دسترسپذیر پیاده بشه.» نه «این دسترسپذیره»، نه «این دسترسپذیر میشه». تیمها این جواب رو کافی میدونن چون طراحی جلوی دسترسپذیری رو نمیگیره.
بعد از ماهها که ویژگی نهایی رو ممیزی میکنه، نتیجه اغلب غافلگیرکنندهست: عکسهای اطلاعاتی بدون alt-text، مودالی که فوکوس صفحهکلید رو نگه نمیداره، آپدیتهای داینامیک که به screen reader اعلام نمیشن، و بخشهایی که اصلاً با صفحهکلید در دسترس نیستن.
استینهوت میگه راحت میشه گفت دولوپرها اهمیت نمیدن یا آموزش کافی ندیدن، ولی این توضیح این پروژه رو نمیده؛ چون تیم قبلاً رو محصولات دسترسپذیر کار کرده بود. اون میگه بررسی طراحی فقط جواب میده که آیا یه ایده اصلاً میتونه دسترسپذیر پیاده بشه یا نه؛ جزئیات پیادهسازی مثل نحوهٔ مدیریت فوکوس، اینکه کدوم تغییرات به ابزارهای کمکی اعلام میشن، یا چطور یه کامپوننت سفارشی معنای خودش رو نشون میده، تصمیمهای سطح توسعهان که کسی باید بگیرتشون، مستندشون کنه و چک کنه واقعاً اتفاق افتادن یا نه.
به گفتهٔ اون، دونستن دربارهٔ دسترسپذیری با ساختنِ دسترسپذیر فرق داره؛ دولوپرها همزمان با منطق کسبوکار، API، مدیریت state، پرفورمنس و ددلاین دستوپنجه نرم میکنن و اگه دسترسپذیری بخشی از کار روزمره نشه، وسط اینهمه چیز گم میشه. جالب اینه که چند نفر از تیم پروژه، کاربر حرفهای صفحهکلید بودن، ولی این باعث نشد رابطهای صفحهکلید-پسند بسازن؛ چون تایپ کردن با کیبورد با گشتن تو یه رابط بدون موس، دو مهارت کاملاً جدان.
استینهوت مشکل رو تو گذرگاه بین مرحلهها میبینه: تیم طراحی مالک طراحیه، دولوپرها مالک کد، QA مالک تست، و تیم دسترسپذیری مالک ممیزیه؛ ولی هیچکس مالک انتقال دسترسپذیری از یه مرحله به مرحلهٔ بعد نیست. جزئیاتی که برای کاربر ناتوان مهمن، عمداً حذف نمیشن؛ فقط هیچوقت به مرحلهٔ بعد منتقل نمیشن. مشکل دیگه این بود که تنها چکپوینت دسترسپذیری بعد از طراحی، یه ممیزی جامع نزدیک پایان پروژه بود؛ درست مثل اینکه اولین بار امنیت یه کد رو بعد از نوشتنِ کامل همهچیز بررسی کنی.
راهحل پیشنهادی اون سه بخشیه: تو مرحلهٔ طراحی، الزامات دسترسپذیری مثل ترتیب فوکوس، رفتار صفحهکلید و اعلامها باید کنار مشخصات بصری نوشته بشن و به معیار پذیرش تبدیل بشن؛ تو مرحلهٔ توسعه، یه نفر باید مالک انتقال از طراحی به پیادهسازی باشه، تیم از یه کتابخونهٔ کامپوننت دسترسپذیر مشترک استفاده کنه و چکهای خودکار دسترسپذیری تو پایپلاین build قرار بگیرن؛ و تو مرحلهٔ اعتبارسنجی، یه بررسی متمرکز حین توسعه، نه فقط ممیزی نهایی، مشکلات رو زودتر و ارزونتر پیدا کنه.
نکات کلیدی:
- تایید طراحی («این میتونه دسترسپذیر پیاده بشه») تضمینی برای دسترسپذیر بودن محصول نهایی نیست.
- مشکلات رایج بعد از توسعه: نبود alt-text، فوکوس مودال، اعلام تغییرات به screen reader، و ناوبری صفحهکلید.
- علت اصلی، گم شدن مالکیت دسترسپذیری بین چهار مرحلهٔ طراحی، توسعه، QA و ممیزیه، نه بیتوجهی تیم.
- راهکار: الزامات دسترسپذیری بهعنوان معیار پذیرش تو طراحی، مالکیت مشخص تو توسعه، و چک خودکار تو پایپلاین build.
