۳ استراتژی برای توسعه نرم‌افزارهای با قابلیت دسترسی بیش‌تر

نویسنده: تیم مارکتینگ

دسته بندی: مقالات HBR
4 دقیقه زمان مطالعه
1401/04/19
بدون دیدگاه

دسترس‌پذیری وب (که  به عنوان a11y هم شناخته می‌شود) برای ایجاد وب‌سایت‌هایی اشاره دارد که می‌تواند توسط هر کسی استفاده شود. چه فردی دارای معلولیت، یک connection آهسته، سخت‌افزار قدیمی یا خراب یا صرفاً فردی در یک محیط نامساعد.

خلاصه: هیچ کسی به تنهایی متخصص دسترسی  نیست. این یک مسئولیت مشترک است و همه توسعه‌دهندگان باید از دانش دیگران برای افزایش درک و تجلی خود در مورد توسعه نرم‌افزار با دسترسی بیش‌تر استفاده کنند. در همین راستا، چارچوب‌های اصلی (frame work) که توسعه‌دهندگان از آن استفاده می‌کنند را نمی‌توان به‌ عنوان یک framework همه‌جانبه  در نظر گرفت. برنامه‌نویسان برای ایجاد یک قابلیت جدید در نرم‌افزار خود فقط از یک ابزار استفاده نمی‌کنند، آن‌ها باید چندین ورودی در اختیار داشته باشند که انها را از طریق دسترسی راهنمایی کند. هرچه دسترسی برای برنامه‌نویسان بهتر باشد، آنها راحت‌تر و بهتر می‌توانند به افراد مختلف با نیازهای متنوع خدمت کنند. نویسنده سه راه را برای توسعه‌دهندگان ارائه می‌کند تا ازاستفاده از ابزارها و دستورالعمل‌های دسترسی نامناسب و ناکافی خودداری کنند و با آستانه تغییر دسترسی همگام شوند.

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

اما فراتر از حداقل‌ها، این کار  نیاز به داشتن ذهنیت متفاوتی از سوی توسعه‌دهندگان نرم افزار دارد. بسیاری از افرادی که وظیفه دارند تسک‌ها بررسی و ایجاد کنند، به شدت به مجموعه کوچکی از ابزارها متکی هستند که در هنگام ساختن به آن‌ها، دید تونلی می دهد. React، Vue، و Svelte همگی قابلیت دسترسی را در خود دارند، اما توسعه‌دهندگانی که فقط از مواردی که محدود هستند استفاده می کنند، در خطر تمرکز تک بعدی هستند. بسیاری از ابزارها عناصر بصری دسترسی را در اولویت قرار می‌دهند، زیرا آن‌ها قابل توجه‌ترین هستند، اما کاربرانی که مشکلات شنوایی یا حرکتی دارند چطور؟

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

ابزارهای دسترسی خود را با هم ترکیب و هماهنگ کنید.

هر پلتفرم توسعه مجموعه ای از دستورالعمل‌ها و الزامات دسترسی خود را دارد. به عنوان مثال، استانداردهای دسترسی (a‌۱y) برای وب در دستورالعمل‌های دسترسی به محتوای وب (WCAG) به تفصیل آمده است، اپل از دستورالعمل‌های رابط انسانی (HIG) استفاده می‌کند، و Android مجموعه‌ای از دستورالعمل‌های خاص خود را دارد. کتابخانه‌های وب مانند React و Vue بخش‌هایی دارند که در مورد بهترین روش‌ها برای دسترسی است،همچنین آن‌ها کتابخانه‌های خاص مانند React Select و Vue Select هم دارند.

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

بهترین راه برای جلوگیری از این مشکل، ترکیب و تطبیق ابزارها و دستورالعمل ها است. اگر  framework شما بیش‌تر به سمت تعامل بصری گرایش دارد، آن را با درخت دسترس‌پذیری Google یا با سیستم دسترسی فایرفاکس هماهنگ کنید، این کار  به توسعه‌دهندگان کمک می‌کند تا بفهمند محتوا چگونه در معرض فناوری کمکی قرار می‌گیرد. اگر نیازهای شما عمدتاً برای افراد دارای اختلالات شنوایی است، صفحه‌خوان Orca را برای رایانه‌های رومیزی مانند MATE، GNOME و Unity امتحان کنید. پروژه سونار گنو/لینوکس برای پذیرایی و خدمت کردن به  کاربران با مشکلات بصری عالی است.

همچنین ابزارهای زیادی وجود دارد که توسعه‌دهندگان می‌توانند از آنها برای آزمایش (test) دسترسی در سراسر پلتفرم‌ها استفاده کنند. Linter ها برای بررسی کد، عالی هستند، در حالی که افزونه‌های a11y می‌توانند از نوشتن اجزای (component) در Storybook پشتیبانی کنند.

هر چه ابزارهای بیش‌تری را در کنار الزامات دسترسی پلت فرم اولیه خود استفاده کنید، تصویر شما از دسترسی کامل‌تر است. این ابزارها نیز نباید صرفاً ابزارهای توسعه باشند، بحث در مورد جامعه دسترسی به وب Reddit، Stack Overflow و کانال دسترسی Slack می‌تواند به شما مکان‌هایی را نشان دهد که دستورالعمل‌های اصلی شما این موارد را پوشش نمی‌دهند.

از قوانین دسترسی محلی بیاموزید.

توسعه‌دهندگان باید در هنگام ساخت محصولات، ذهنیتی جهانی داشته باشند و به نوبه خود تصدیق کنند که پایبندی به دسترسی بر اساس مکان تغییر می‌کند. قابلیت دسترسی بسیار بیش‌تر و پیچیده‌تر از ترجمه متن و کپی پیست از framework است که در جاهای دیگر و کد‌‌های دیگر کار می‌کند. آن چه ممکن است در یک کشور از نظر قانونی سازگار یا فراگیر باشد، احتمالاً در کشور دیگر متفاوت است. به عنوان مثال، قانون دسترس‌پذیری برای افراد دارای معلولیت انتاریایی (AODA) مشخصات استاندارد اروپایی برای دسترسی دیجیتال (EN 301 549) را ندارد. و این نوع قوانین فراتر از چارچوب‌های فنی framework  محبوبی مانند React هستند، بنابراین توسعه‌دهندگان نمی‌توانند محصولات سازگار خود را فقط با مراجعه انحصاری به آن framework ها ایجاد کنند. به عنوان مثال، EN301 549 بیان می‌کند که بیومتریک نمی‌تواند تنها به عنوان وسیله‌ای  برای شناسایی کاربر استفاده شود. با این حال، WCAG   مجموعه‌ای اصلی از دستورالعمل‌ها در فناوری – هیچ اشاره ای به بیومتریک ندارد.

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

از طریق تست کاربر، مناطق خاکستری framework های مستقل را کشف کنید.

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

بررسی دسترس‌پذیری به چیزی بیش از دانلود کل کتابخانه‌هایی که در دسترس دارید است. زیرساخت‌های شما  ممکن است در دسترس باشند، اما این تضمین نمی‌کند که محصول نهایی قابل دسترسی باشد. توسعه‌دهندگان مسئولیت دارند، محصول را تست  کنند زیرا آن را در مقیاس‌‌های کوچک و به طور کامل می‌سازند. این نکته‌ها باید در زمینه خودش قرار بگیرد تا تایید شود که دسترسی قابل قبولی داشته است. توسعه‌دهندگان باید بارها و بارها محصولات و ویژگی‌ها را به صورت حضوری یا از راه دور با گروه متنوعی از کاربران با قابلیت‌ها، سنین و پیشینه‌های مختلف مورد تست  قرار دهند. در استارک، ما در صورت امکان شخصاً آزمایش می‌کنیم، اما اگر تحت شرایطی این امکان وجود نداشت از Zoom برای برگزاری جلسات بازخورد، اطمینان از برآورده شدن شرح‌ها، تفسیر زبان اشاره و سایر نیازهای کاربر استفاده می‌کنیم. Fable یک پلت فرم درخشان برای درگیر کردن افراد دارای معلولیت در راستای تحقیقات کاربر (UX) و برجسته کردن روش‌های تستی  است که مناطق خاکستری framework های مستقل را نشان می‌دهد. برای ما، آزمایش کاربر نشان داد که framework ها توسعه‌دهندگان را از تنظیم نادرست ترتیب فوکوس برای کاربران صفحه کلید (keyboard users) منع نمی‌کند. ما این مورد را فقط با صحبت با افرادی که از پیمایش صفحه کلید برای وب سایت‌ها استفاده می‌کنند، یاد گرفتیم.

هیچ کس به تنهایی متخصص دسترسی  نیست. این یک مسئولیت مشترک است و همه توسعه‌دهندگان باید از دانش دیگران برای افزایش درک و تجلی خود در مورد توسعه نرم‌افزار با دسترسی بیش‌تر استفاده کنند. در همین راستا، چارچوب‌های اصلی (frame work) که توسعه‌دهندگان از آن استفاده می‌کنند را نمی‌توان به‌عنوان یک framework همه‌جانبه در نظر گرفت. آن‌ها باید در کنار ابزارها و تست  های دیگر استفاده شوند و برای ایجاد دسترسی بیش‌تر و مطلوب‌تر به سمت جلو پیش روند.

این پست ترجمه شده مقاله: 

۳استراتژی برای توسعه نرم‌افزارهای با قابلیت دسترسی بیش‌تر است