به سمت دسترسی

جمعه پایان روز کاری است. اخبار بد همیشه در پایان روز کاری روز جمعه می آید.

شما در شرف خروج از دفتر هستید، نامه جدیدی در مورد سازماندهی مجدد دیگری به تازگی از طریق پست ارسال شده است.

با تشکر از شما xxxx، yyyy از امروز شما zzzz را گزارش خواهید کرد
...
و تیم هیو اطمینان حاصل خواهد کرد که محصولات ما برای افراد دارای معلولیت قابل دسترسی است.

وای نه! چرا من لیاقت این را داشتم؟ آیا آنها می خواهند من بروم؟ خود را برای تلاش بی‌شکر و تلاش برای تصحیح اشتباهات دیگران آماده کنید. این قطعا یک شکست است ...

این در دسترس بودن چند سال پیش بود. به برخی افراد بیچاره وظیفه "تمیز کردن" رابط کاربری داده شد تا سعی کنند آن را برای افراد دارای معلولیت در دسترس قرار دهند.

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

اما ناگهان "اشکالات" با سرعت یک بهمن شروع به تکثیر کردند.

صفحه خوان های مختلف (مهندس Screen Readers) و مرورگرها کاملاً متفاوت عمل کردند.

کاربران از غیرقابل استفاده بودن برنامه شکایت کرده اند.

به محض اینکه یک خطا در یک مکان تصحیح شد، خطای دیگری در جایی دیگر ظاهر شد.

و به سادگی تغییر و اصلاح خطاهای رابط کاربری نیاز به تلاش های هرکولی داشت.

من آنجا بودم. من زنده ماندم، اما "موفق نشدیم" - از نظر فنی ما چیزهای زیادی را تمیز کردیم، توضیحات میدانی، نقش های زیادی اضافه کردیم و به سطحی از انطباق دست یافتیم، اما هیچ کس راضی نبود. کاربران همچنان شکایت داشتند که نمی توانند برنامه را مرور کنند. مدیر همچنان از جریان مداوم خطاها شکایت داشت. مهندسان شکایت داشتند که مشکل به اشتباه مطرح شده است، بدون راه‌حل «درست» مشخص و مشخص که در همه موارد کارساز باشد.

در طول سفر من به سمت درک دسترسی، لحظاتی چشمگیر بود.
شاید اولین مورد درک این موضوع بود که افزودن قابلیت دسترسی به محصول نهایی دشوار است. و حتی سخت تر است که مدیران را متقاعد کنیم که این کار فوق العاده دشوار است! نه، این فقط «افزودن چند برچسب» نیست و رابط کاربری به خوبی کار خواهد کرد. نه، این را نمی توان در سه هفته تکمیل کرد، حتی سه ماه نیز کافی نخواهد بود.
لحظه بعدی حقیقت من زمانی فرا رسید که از نزدیک دیدم که چگونه کاربران نابینا واقعاً از برنامه ما استفاده می کنند. این با نگاه کردن به پیام های خطا بسیار متفاوت است.

من بارها و بارها به این موضوع باز خواهم گشت، اما تقریباً تمام "فرض‌های" ما در مورد نحوه استفاده مردم از برنامه ما اشتباه بود.

پیمایش یک رابط کاربری پیچیده با استفاده از کلید Tab/Shift+Tab - این بد است! ما به چیز بهتری نیاز داریم. میانبرهای صفحه کلید، هدرها.

از دست دادن تمرکز هنگام تغییر رابط کاربری مشکل بزرگی نیست، اینطور است؟ بیایید دوباره فکر کنیم - این فوق العاده گیج کننده است.

من ادامه دادم، مدتی روی پروژه های مختلف کار کردم، و سپس پروژه جدیدی را با رابط کاربری پیچیده و نصب واضح شروع کردیم تا در نهایت این بار دسترسی درست را بدست آوریم.

بنابراین، ما یک گام به عقب برداشتیم و به این موضوع نگاه کردیم که چگونه می‌توانیم این کار را متفاوت اجرا کنیم و موفق شویم و این روند را خسته‌کننده‌تر کنیم!

خیلی سریع به چند نتیجه رسیدیم:

1. ما نمی‌خواستیم افرادی که رابط کاربری را توسعه می‌دهند با برچسب‌ها/نقش‌های آریا و البته ساختار HTML اجزاء به هم بخورند. ما باید مولفه‌های مناسبی را برای آنها فراهم می‌کردیم که دسترسی را به درستی از جعبه ایجاد می‌کرد.
2. دسترسی == سهولت استفاده - به عنوان مثال. این فقط یک چالش فنی نیست. ما نیاز داشتیم که کل فرآیند طراحی را تغییر دهیم و اطمینان حاصل کنیم که قابلیت دسترسی قبل از شروع طراحی UI در نظر گرفته شده و مورد بحث قرار گرفته است. شما باید زود به این فکر کنید که کاربران چگونه هر گونه عملکردی را کشف می کنند، چگونه حرکت می کنند و راست کلیک کردن از صفحه کلید چگونه کار می کند. دسترسی باید بخشی جدایی ناپذیر از فرآیند طراحی باشد - برای برخی از کاربران، بسیار بیشتر از ظاهر برنامه است.
3. ما از همان ابتدا می خواستیم از کاربران نابینا و سایر نابینایان در مورد سهولت استفاده از برنامه بازخورد دریافت کنیم.
4. ما به روش‌های واقعاً خوبی نیاز داشتیم تا رگرسیون‌های دسترسی را دریافت کنیم.

خب، از نقطه نظر مهندسی، قسمت اول بسیار سرگرم کننده به نظر می رسید - توسعه یک معماری و اجرای کتابخانه ای از اجزا. و در واقع اینطور بود.

یک قدم به عقب برمی‌گردد، نگاه می‌کند نمونه های ARIA و با در نظر گرفتن این مسئله به عنوان یک مشکل طراحی به جای یک مسئله "برازش در"، چند انتزاع را معرفی کردیم. یک جزء دارای یک «ساختار» (شامل عناصر HTML) و یک «رفتار» (نحوه تعامل آن با کاربر) است. به عنوان مثال، در اسنیپت های زیر یک لیست ساده و بدون ترتیب داریم. با افزودن "رفتارها" نقش های مربوطه به لیست اضافه می شود تا مانند یک لیست عمل کند. ما همین کار را برای منو انجام می دهیم.

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

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

شما می توانید این را در عمل مشاهده کنید https://stardust-ui.github.io/react/ – کتابخانه UX واکنش نشان می دهند، که از ابتدا با در نظر گرفتن قابلیت دسترسی طراحی و پیاده سازی شده است.

بخش دوم - تغییر رویکرد و فرآیندهای پیرامون طراحی در ابتدا من را ترساند: مهندسان حقیر که تلاش می‌کنند تغییرات سازمانی را به پیش ببرند، همیشه به خوبی ختم نمی‌شود، اما معلوم شد که یکی از جالب‌ترین زمینه‌هایی است که در آن مشارکت قابل توجهی در این فرآیند داشته‌ایم. . به طور خلاصه، روند ما به این صورت بود: عملکرد جدید توسط یک تیم توسعه می‌یابد، سپس تیم رهبری ما پیشنهاد را بررسی/تکرار می‌کند، و پس از تأیید، طرح معمولاً به تیم مهندسی تحویل داده می‌شود. در این مورد، تیم مهندسی عملاً «مالک» قابلیت دسترسی بود، زیرا مسئولیت آن‌ها رفع مشکلات مرتبط با آن بود.

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

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

اگر در این جلسات (یا جلسات بعدی) کاربران نابینا و ناتوان داشتیم، می‌توانیم این کار را حتی بهتر انجام دهیم - سازماندهی این امر دشوار بود، اما اکنون با سازمان‌ها و شرکت‌های نابینای محلی کار می‌کنیم که آزمایش‌های خارجی را برای تأیید جریان اجرا در اوایل انجام می‌دهند. توسعه - هم در سطح جریان جزء و هم در اجرا.

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

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

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

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

"درک" بعدی این است که کاربران نابینا فناوری پیشرفته را هدایت می کنند - آنها کسانی هستند که نه تنها از تغییراتی که قبلاً توضیح دادیم، بلکه همچنین از این که رویکردها و ایده های جدید توسط ML/AI امکان پذیر شده اند بیشترین بهره را می برند. به عنوان مثال، فناوری Immersive Reader به کاربران این امکان را می دهد که متن را راحت تر و واضح تر ارائه دهند. می توان آن را با صدای بلند خواند، ساختار جمله از نظر دستوری شکسته می شود و حتی معانی کلمات به صورت گرافیکی نمایش داده می شود. این به هیچ وجه با ذهنیت قدیمی "در دسترس قرار دهید" نمی گنجد - این یک ویژگی قابل استفاده است که به همه کمک می کند.

ML/AI روش‌های کاملاً جدیدی را برای تعامل و کار فراهم می‌کند، و ما هیجان‌زده هستیم که بخشی از مراحل بعدی این سفر پیشرفته باشیم. نوآوری ناشی از تغییر در تفکر است - بشریت برای هزاران سال وجود داشته است، ماشین ها برای صدها سال، وب سایت ها برای چندین دهه، و تلفن های هوشمند حتی کمتر، فناوری باید با مردم سازگار شود، و نه برعکس.

PS مقاله با انحرافات جزئی از اصل ترجمه شده است. به عنوان یکی از نویسندگان این مقاله، من با هیو در مورد این انحرافات موافق بودم.

فقط کاربران ثبت نام شده می توانند در نظرسنجی شرکت کنند. ورود، لطفا.

آیا به دسترسی به برنامه های کاربردی خود توجه می کنید؟

• بله

• بدون

• این اولین بار است که در مورد دسترسی به برنامه می شنوم.

17 کاربر رای دادند. 5 کاربر رای ممتنع دادند.

منبع: www.habr.com