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

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

خلاصه: هیچ کسی به تنهایی متخصص سطح دسترسی نیست. این یک مسئولیت مشترک است و همه توسعه‌دهندگان باید از دانش دیگران برای افزایش درک و تجلی خود در مورد توسعه نرم‌افزار‌هایی با دسترسی بیش‌تر استفاده کنند. در همین راستا چارچوب‌های اصلی (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 همه‌جانبه در نظر گرفت. آن‌ها باید در کنار ابزارها و تست‌های دیگر استفاده شوند و برای ایجاد دسترسی بیش‌تر و مطلوب‌تر به سمت جلو پیش روند.

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

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