منبع: بنیاد طراحی تعامل (IxDF) · بازنویسی آزاد: سپنتا پویا · مرداد ۱۴۰۵ · زمان مطالعه: حدود ۱۱ دقیقه

فناوری کمکی (Assistive Technology) چیست؟

💡 این متن «بازنویسی آزاد» است: ایده‌ها و مفاهیم مطلب اصلی با نگارش کاملاً مستقل فارسی و مثال‌های تازه بازگو شده‌اند و ترجمهٔ کلمه‌به‌کلمه نیست. بخش‌های افزودهٔ مترجم در جعبهٔ منبع مشخص شده‌اند.

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

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

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

پنج دسته و ابزارهایشان

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

• - بینایی: صفحه‌خوان (NVDA، JAWS، VoiceOver)، نمایشگر بریل، درشت‌نما.
• - شنوایی: زیرنویس، رونویسی خودکار، هشدار دیداری به‌جای صوتی.
• - حرکتی: صفحه‌کلید روی صفحه، موس و صفحه‌کلید سازگارشده، صفحه‌کلید یک‌دستی، سوئیچ‌کنترل، و امکاناتی مثل StickyKeys که ترکیب کلیدها را به فشردن پیاپی تبدیل می‌کند.
• - شناختی و یادگیری: تبدیل متن به گفتار، قلم‌های ویژهٔ نارساخوانی، ابزارهای ارتباط جایگزین.
• - گفتاری: دستگاه‌های تولید گفتار و نرم‌افزارهایی که متن تایپ‌شده را با صدا بیان می‌کنند.

و یک نکتهٔ آماری که در تصمیم‌گیری کمک می‌کند: بر پایهٔ برآورد سازمان جهانی بهداشت، حدود ۱٫۳ میلیارد نفر — نزدیک به یک نفر از هر شش نفر — نوعی معلولیت دارند. این عدد را کنار بحث طیف توانایی در طراحی فراگیر بگذارید: بسیاری از این افراد چند محدودیت هم‌زمان دارند، و بسیاری دیگر به‌طور موقت یا موقعیتی در همین وضعیت قرار می‌گیرند.

صفحه‌خوان صفحهٔ شما را چطور می‌بیند؟

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

نتیجه‌اش این است که کاربر صفحه‌خوان، صفحه را مثل شما «نگاه» نمی‌کند؛ در آن پیمایش می‌کند، و ابزارهای پیمایشش این‌هاست:

• - پرش میان عنوان‌ها. بیشتر کاربران باتجربه اول فهرست عنوان‌های صفحه را می‌گیرند و از آن‌جا وارد بخش موردنظر می‌شوند — درست مثل نگاه‌کردن شما به تیترها. اگر عنوان‌ها را با div و اندازهٔ قلم ساخته باشید نه با h2، این فهرست خالی است و کاربر باید همه‌چیز را از اول بشنود.
• - پرش میان نواحی. ناحیهٔ اصلی، ناوبری، جست‌وجو، پابرگ. این‌ها از عناصر معنایی ساخته می‌شوند و به کاربر اجازه می‌دهند ناوبری تکراری را رد کند.
• - فهرست پیوندها و دکمه‌ها. و همین‌جاست که پیوندهایی با متن «اینجا کلیک کنید» بی‌فایده می‌شوند: کاربر فهرستی از ده «اینجا» می‌شنود که هیچ‌کدام نمی‌گوید به کجا می‌رود.
• - حرکت خطی با Tab. برای عناصر تعاملی، به همان ترتیبی که در کد آمده‌اند — نه به ترتیبی که روی صفحه دیده می‌شوند. اگر با CSS جای دو بخش را عوض کرده باشید، ترتیب شنیده‌شده با ترتیب دیده‌شده نمی‌خواند.

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

باور غلط: «با صفحه‌خوان کار می‌کند، پس دسترس‌پذیر است»

پرتکرارترین اشتباه در تیم‌هایی که تازه به دسترس‌پذیری فکر می‌کنند این است: یک بار صفحه را با صفحه‌خوان امتحان می‌کنند، کار می‌کند، و پرونده بسته می‌شود. اما صفحه‌خوان تنها یک بعد از چند بعد است:

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

و دو نکته که در عمل بیشتر از فهرست بالا اهمیت دارند. اول اینکه بسیاری از کاربران چند محدودیت هم‌زمان دارند؛ راه‌حلی که هر بعد را جدا در نظر بگیرد ممکن است در ترکیب شکست بخورد. دوم اینکه آزمون خودکار فقط بخش کوچکی را می‌گیرد — ابزارها کنتراست و نبود متن جایگزین را پیدا می‌کنند، اما نمی‌فهمند متن جایگزین شما بی‌معناست یا ترتیب فوکوس گیج‌کننده است. آن‌ها کف را تضمین می‌کنند، نه کیفیت را؛ درست مثل تفاوتی که در سنجه‌های تجربهٔ کاربری میان عدد و فهم گذاشتیم.

فناوری کمکی در زبان فارسی

این بخش افزودهٔ مترجم است. همهٔ توصیه‌های بالا برای زبانی نوشته شده‌اند که فناوری کمکی آن را خوب می‌فهمد. فارسی این‌طور نیست، و تفاوت‌ها فنی و مشخص‌اند:

• - مصوت‌های کوتاه نوشته نمی‌شوند. «کرم» می‌تواند کَرَم، کِرم یا کِرِم باشد. موتور تبدیل متن به گفتار باید از بافت جمله حدس بزند، و در نام محصول یا کد یا کلمهٔ تک‌افتاده — که در رابط فراوان است — بافتی وجود ندارد. نتیجه‌اش خواندن نادرست است، نه صرفاً لهجهٔ ماشینی.
• - کسرهٔ اضافه نوشته نمی‌شود. «کیف من» باید «کیفِ من» خوانده شود و این را باید از نحو استنتاج کرد. همین یک مورد، بخش بزرگی از لحن رباتیک خواندن فارسی را می‌سازد.
• - حروف دوشکلی، تطبیق را می‌شکنند. «ی» و «ک» فارسی در برابر عربی، از نظر کاربر یکی‌اند و از نظر رایانه دو نویسهٔ متفاوت. متنی که با نویسهٔ عربی نوشته شده ممکن است در فرهنگ واژگان موتور گفتار پیدا نشود و حرف‌به‌حرف خوانده شود.
• - نیم‌فاصله. اگر به‌جای نویسهٔ درست از فاصلهٔ معمولی استفاده شده باشد، «می‌روم» به دو تکه می‌شکند و جور دیگری خوانده می‌شود.
• - ترتیب فوکوس در راست‌به‌چپ. ترتیب Tab از ترتیب کد می‌آید نه از ظاهر. در صفحه‌ای که با ویژگی‌های منطقی CSS آینه شده، این دو معمولاً می‌خوانند؛ در صفحه‌ای که با جابه‌جایی دستی آینه شده، نه — و کاربر صفحه‌کلید مسیری را طی می‌کند که هیچ ربطی به آنچه می‌بیند ندارد.
• - پشتیبانی ناهموار و کمبود سخت‌افزار. کیفیت صدای فارسی در سامانه‌های مختلف یکسان نیست و نمایشگر بریل فارسی در دسترس بسیاری نیست. یعنی نمی‌توانید فرض کنید کاربر شما ابزار خوبی در اختیار دارد.

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

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

جمع‌بندی

• - فناوری کمکی ابزارهایی است که محصول دیجیتال را برای افراد دارای معلولیت قابل استفاده می‌کند؛ پنج دستهٔ اصلی‌اش بینایی، شنوایی، حرکتی، شناختی و گفتاری است.
• - صفحه‌خوان از ظاهر صفحه کار نمی‌کند، از ساختار معنایی آن کار می‌کند. عنوانی که با div ساخته شده، برای او عنوان نیست.
• - کاربران صفحه‌خوان با پرش میان عنوان‌ها و نواحی پیمایش می‌کنند؛ پیوند «اینجا کلیک کنید» در فهرست پیوندها بی‌معناست.
• - ترتیب Tab از کد می‌آید نه از ظاهر؛ جابه‌جایی بصری با CSS این دو را از هم جدا می‌کند.
• - «با صفحه‌خوان کار می‌کند» یعنی یک بعد از چهار بعد بررسی شده. حرکتی، شنوایی، شناختی و گفتاری هرکدام آزمون خودشان را می‌خواهند.
• - آزمون خودکار کف را تضمین می‌کند نه کیفیت را: بی‌معنا بودن متن جایگزین یا گیج‌کننده بودن ترتیب فوکوس را نمی‌فهمد.
• - در فارسی، مصوت کوتاه نانوشته، کسرهٔ اضافه، حروف دوشکلی و نیم‌فاصله همگی کار موتور گفتار را دشوار می‌کنند — و هرچه فناوری کمکی زبان را بدتر بفهمد، نشانه‌گذاری درست اهمیت بیشتری پیدا می‌کند.