چرا بسیاری از وب‌سایت‌ها همچنان برای افراد نابینا قابل استفاده نیستند؟
برای میلیون‌ها کاربر، وب‌گردی با موانعی همراه است که دیگران حتی متوجه آن‌ها نمی‌شوند. چرا بسیاری از سایت‌ها هنوز برای نابینایان دسترس‌پذیر نیستند؟
برای میلیون‌ها کاربر، وب‌گردی با موانعی همراه است که دیگران حتی متوجه آن‌ها نمی‌شوند. چرا بسیاری از سایت‌ها هنوز برای نابینایان دسترس‌پذیر نیستند؟
فناوری برای همه، بدون استثنا؛ روز جهانی عصای سفید در زومیت
تصور کنید می‌خواهید بلیت قطار بخرید. مقصد و تاریخ را انتخاب می‌کنید، اما وقتی به دکمه‌ی پرداخت می‌رسید، نرم‌افزاری که محتوای صفحه را برایتان می‌خواند فقط می‌گوید: «دکمه». چند بار کلید تب را فشار می‌دهید؛ نشانگر میان بخش‌های صفحه می‌چرخد و ناگهان در پنجره‌ای گیر می‌افتد. برای کاربری که صفحه را می‌بیند، شاید مسئله با یک کلیک حل شود؛ برای فردی نابینا، همین نقص می‌تواند خرید بلیت را ناممکن کند. مشکل اغلب از فناوری‌های کمکی نیست؛ وب‌سایت اطلاعات لازم را در اختیار آن‌ها نمی‌گذارد.
آمار نشان می‌دهد چنین تجربه‌ای استثنایی نیست. مؤسسه‌ی WebAIM در بهمن ۱۴۰۴ صفحه‌ی اصلی یک میلیون وب‌سایت پربازدید را با ابزار خودکار بررسی کرد. در ۹۵٫۹ درصد صفحات، دست‌کم یک خطای قابل‌شناساییِ مرتبط با استاندارد دسترس‌پذیری پیدا شد؛ میانگین، ۵۶٫۱ خطا برای هر صفحه بود.
در ۵۳٫۱ درصد صفحات، تصویری بدون متن جایگزین وجود داشت و ۵۱ درصد صفحات دست‌کم یک فیلد فرم فاقد برچسب مناسب داشتند. البته این اعداد به‌معنای غیرقابل‌استفاده‌بودن تمام این وب‌سایت‌ها نیست؛ بررسی فقط صفحه‌ی اصلی و خطاهای قابل‌تشخیص با ابزار را در بر می‌گیرد. بااین‌حال، تا حد زیادی ابعاد مشکل را نشان می‌دهد.
بسیاری از افراد نابینا با صفحه‌خوان‌هایی مانند NVDA و JAWS و VoiceOver وب‌گردی می‌کنند. این نرم‌افزارها اطلاعاتی را که مرورگر از ساختار صفحه دریافت می‌کند، به گفتار یا نمایشگر بریل تبدیل می‌کنند.
کاربر می‌تواند به‌جای استفاده از ماوس، با صفحه‌کلید میان تیترها، لینک‌ها، کادرهای ورود اطلاعات و دکمه‌ها جابه‌جا شود. اما صفحه‌خوان نمی‌تواند اطلاعات تعریف‌نشده را حدس بزند؛ اگر طراح نام، نقش یا وضعیت یک عنصر را درست مشخص نکرده باشد، ممکن است چیزی برای اعلام‌کردن وجود نداشته باشد.
اگر تصویر، متن جایگزین معنادار نداشته باشد، مشتری نابینا ممکن است نداند در حال خرید چه کالایی است
نمونه‌ی ساده، تصویر محصولی است که زیر آن فقط قیمت نوشته شده است. اگر تصویر، متن جایگزین معنادار نداشته باشد، مشتری نابینا ممکن است نداند در حال خرید چه کالایی است. متن جایگزین یا alt باید اطلاعات ضروری تصویر را منتقل کند، نه اینکه فقط بنویسد «عکس.» البته تصاویر صرفاً تزئینی بهتر است با متن جایگزین خالی مشخص شوند تا صفحه‌خوان بی‌دلیل مکث نکند. در نمودارهای خبری نیز توضیح چندکلمه‌ای کافی نیست؛ اعداد و روند اصلی باید به‌شکل متنی قابل‌دسترسی باشند.
مشکل بزرگ‌تر وقتی شروع می‌شود که قرار است کاری انجام شود. برچسبی که از نظر ظاهری کنار کادر «شماره‌ی تماس» قرار دارد، اگر در کد به همان کادر متصل نشده باشد، صفحه‌خوان ممکن است تنها عبارت «ویرایش متن» را اعلام کند. دکمه‌ای که با یک عنصر گرافیکیِ سفارشی ساخته شده، شاید با ماوس کار کند اما با صفحه‌کلید فعال نشود. پیام خطای فرم یا تغییر مبلغ سبد خرید هم اگر به‌درستی اعلام نشود، کاربر متوجه اتفاقی که افتاده نخواهد شد.
ساختار تیترها نیز حیاتی است. در نظرسنجی تابستان ۲۰۲۶ مؤسسه‌ی WebAIM با ۱٬۷۸۰ پاسخ معتبر، ۶۷٫۸ درصد پاسخ‌دهندگان گفته‌اند هنگام جست‌وجوی اطلاعات در یک صفحه‌ی طولانی، نخست میان تیترها حرکت می‌کنند. وقتی تیتر فقط متنی بزرگ و ضخیم باشد، اما در کد به‌عنوان تیتر شناخته نشود، این مسیر میان‌بُر از بین می‌رود. این نظرسنجی نماینده‌ی آماری تمام کاربران صفحه‌خوان نیست، اما روش استفاده‌ی پاسخ‌دهندگان را روشن می‌کند.
موانع به صفحات معمولی محدود نمی‌شوند. فایل PDF اسکن‌شده‌ای که متن قابل‌انتخاب و ساختار درست ندارد، ممکن است برای صفحه‌خوان تقریباً خاموش باشد. در همان نظرسنجی، ۸۵٫۶ درصد پاسخ‌دهندگان گفته‌اند احتمال دارد فایل‌های PDF مشکلات جدی دسترس‌پذیری ایجاد کنند. آزمون‌های تصویری تشخیص انسان، منوهای بازشونده‌ی نامناسب و تغییرات ناگهانی صفحه نیز می‌توانند روند انجام کار را متوقف کنند.
پشت این خطاها اغلب زنجیره‌ای از تصمیم‌های کوچک قرار دارد. طراح ظاهر صفحه را تأیید می‌کند، برنامه‌نویس عملکرد را با ماوس می‌سنجد و دبیر سایت انتشار سریع تصویر و فایل را در اولویت می‌گذارد. وقتی آزمون با صفحه‌کلید و صفحه‌خوان بخشی از فرایند انتشار نباشد، مشکل پنهان می‌ماند. قالب‌های آماده نیز مسئولیت بررسی خروجی را از میان نمی‌برند.
کنسرسیوم جهانی وب، W3C، استاندارد «راهنمای دسترس‌پذیری محتوای وب» یا WCAG را برای کاهش این موانع تدوین کرده است. نسخه‌ی ۲٫۲ بر چهار اصل استوار است: محتوا باید قابل‌دریافت، قابل‌کنترل، قابل‌فهم و سازگار با فناوری‌های کمکی باشد. معیارهای آن در سه سطح A و AA و AAA دسته‌بندی می‌شوند. سطح AA معمولاً هدف عملی بسیاری از پروژه‌ها است و برای رسیدن به آن باید تمام معیارهای قابل‌اعمال سطوح A و AA رعایت شوند؛ انتخاب چند مورد دلخواه کافی نیست.
محتوا باید قابل‌دریافت، قابل‌کنترل، قابل‌فهم و سازگار با فناوری‌های کمکی باشد
WCAG 2.2 نسبت‌به نسخه‌ی ۲٫۱، نُه معیار تازه اضافه کرده است. ازجمله، عنصر انتخاب‌شده با صفحه‌کلید نباید کاملاً پشت نوارهای ثابت پنهان شود؛ عملیاتی که نیازمند کشیدن با ماوس است باید، به‌جز استثناهای مشخص، با روش ساده‌تری هم انجام شود؛ و ورود به حساب کاربری نباید بدون راه‌حل جایگزین، کاربر را مجبور به آزمون حافظه یا حل معما کند.
این نسخه همچنین برای اندازه‌ی ناحیه‌ی قابل‌کلیک، دسترسی یکسان به راهنما و خودداری از درخواست دوباره‌ی اطلاعات ثبت‌شده ضابطه دارد. همه‌ی این موارد مخصوص نابینایان نیستند؛ دسترس‌پذیری، نیازهای افراد کم‌بینا، دارای محدودیت حرکتی و دیگر گروه‌ها را نیز در بر می‌گیرد.
برای وب‌سایت فارسی، تعیین زبان صفحه و رعایت ترتیب راست‌به‌چپ هم اهمیت دارد. وقتی زبان متن، برچسب دکمه یا ترتیب خواندن بخش‌ها اشتباه تعریف شده باشد، خروجی صفحه‌خوان ممکن است گیج‌کننده شود؛ به‌خصوص در صفحه‌هایی که فارسی، انگلیسی و عدد را کنار هم نمایش می‌دهند. رسیدن به نتیجه‌ی خوب فقط به نصب صفحه‌خوان وابسته نیست؛ کد و محتوای سایت باید از ابتدا درست طراحی شده باشند.
برای دسترس‌پذیرکردن یک وب‌سایت نمی‌توان قیمت ثابتی تعیین کرد. افزودن برچسب درست به یک کادر، اصلاح رنگ نوشته برای کاربران کم‌بینا یا نوشتن متن جایگزین برای تصویر ممکن است تغییر کوچکی باشد. اما اگر سامانه‌ی پرداخت با اجزای سفارشیِ غیرقابل‌کنترل با صفحه‌کلید ساخته شده باشد، اصلاح آن می‌تواند بازنویسی چند بخش، آزمایش دوباره و هماهنگی با پیمانکار را الزامی کند. تعداد الگوهای صفحه، کیفیت کد، حجم اسناد و میزان وابستگی به ابزارهای متفرقه، هزینه را تغییر می‌دهد.
هزینه فقط دستمزد برنامه‌نویس نیست: ارزیابی اولیه، اولویت‌بندی خطاها، آموزش طراحان و تولیدکنندگان محتوا، آزمایش با صفحه‌خوان و مشارکت کاربران نابینا هم باید در بودجه دیده شوند.
دسترس‌پذیری زمانی جدی می‌شود که بخشی از تعریف «کارکرد درست» محصول باشد، نه وصله‌ای پس از انتشار
به‌گفته‌ی راهنمای مالی W3C، واردکردن دسترس‌پذیری از ابتدای طراحی معمولاً کم‌هزینه‌تر از اصلاح سامانه‌ی آماده است. اصلاح یک مؤلفه‌ی مشترک، مانند فرم یا منوی اصلی، می‌تواند هم‌زمان ده‌ها یا صدها صفحه را بهتر کند؛ برعکس، تولید مستمر اسناد و تصاویر بدون توضیح، هزینه‌ی نگهداری را افزایش می‌دهد.
ابزارهای خودکار برای پیداکردن برچسب‌های جاافتاده و برخی خطاهای فنی مفیدند، اما نمی‌توانند تشخیص دهند توصیف یک نمودار واقعاً مفهوم آن را منتقل می‌کند یا خرید بلیت از ابتدا تا انتها برای کاربر نابینا ممکن است. بنابراین امتیاز بالای یک افزونه یا نصب دکمه‌ی «دسترس‌پذیری» روی سایت، تضمین انطباق با WCAG نیست. آزمون واقعی باید مسیرهایی مانند ثبت‌نام، جست‌وجو، پرداخت و بازیابی رمز عبور را با صفحه‌کلید و فناوری‌های کمکی پوشش دهد.
این موضوع در بعضی کشورها الزام حقوقی نیز پیدا کرده است. قانون دسترس‌پذیری اروپا از سال ۲۰۲۵ برای گروه‌هایی از خدمات، ازجمله تجارت الکترونیک و خدمات بانکی، اعمال شده است؛ هرچند دامنه و استثناهای مشخصی دارد.
خود WCAG به‌تنهایی قانون همه‌ی کشورها نیست؛ اما حتی خارج از الزام قانونی نیز مسئله روشن است: وب‌سایتی که امکان خواندن خبر، ثبت درخواست یا پرداخت را از کاربر نابینا می‌گیرد، بخشی از خدماتش را عملاً به او ارائه نمی‌کند. دسترس‌پذیری زمانی جدی می‌شود که بخشی از تعریف «کارکرد درست» محصول باشد، نه وصله‌ای پس از انتشار.