دسترسی‌پذیری وب در ایران را نمی‌توان با یک درصد بی‌منبع توصیف کرد. متن قبلی این صفحه عددهایی درباره جمعیت دارای معلولیت و رعایت‌نکردن WCAG در سایت‌های ایرانی داشت، بدون اینکه جامعه آماری، روش سنجش یا گزارش مشخصی معرفی کند. این اعداد حذف شده‌اند. برای یک تیم ایرانی، نقطه شروع عملی بررسی مسیرهای واقعی سایت خود با کاربران و معیارهای روشن است. فرم ثبت‌نام، انتخاب محصول و پرداخت باید برای کسانی که با صفحه‌کلید، بزرگ‌نمایی یا فناوری کمکی کار می‌کنند قابل استفاده باشند، مستقل از اینکه آمار کل کشور چه باشد.
محدوده بررسی را مشخص کنید
یک صفحه ظاهراً سالم، وضعیت تمام سایت را نشان نمی‌دهد. ممکن است صفحه اصلی ساختار خوبی داشته باشد، اما ورود، جست‌وجو یا فرم درخواست مشکل داشته باشند. برای بررسی، چند مسیر مهم انتخاب کنید و آغاز تا پایان هر مسیر را ببینید. کاربر باید بتواند بفهمد کجاست، چه اطلاعاتی لازم است و بعد از اقدام چه اتفاقی افتاده است. خطاهای توقف کامل را از اشکال‌های کم‌اثر جدا کنید تا اصلاح‌ها بر اساس پیامد واقعی اولویت بگیرند.
معیار باید معلوم باشد. معرفی WCAG در W3C و Quick Reference منابع اصلی برای شناخت معیارهای موفقیت‌اند. سطح A، AA و AAA مجموعه الزامات متفاوتی دارند و عبارت «تست دسترسی‌پذیری پاس شد» بدون نسخه و محدوده مبهم است. اگر فقط چند صفحه بررسی شده‌اند، همان را گزارش کنید. از نتیجه یک ابزار خودکار، انطباق کامل یک سامانه را استنتاج نکنید؛ بخش‌هایی از ارزیابی به رفتار و محتوای واقعی نیاز دارند.
دسترسی‌پذیری را به یک نوع کاربر محدود نکنید. فرد ممکن است صفحه را با بزرگ‌نمایی بخواند، ماوس نداشته باشد، با Screen Reader کار کند یا در محیط پرنور کنتراست بیشتری بخواهد. محدودیت موقت هم وجود دارد، مثل آسیب دست یا استفاده از دستگاه با صفحه کوچک. شناخت این شرایط به طراحی بهتر کمک می‌کند، اما تجربه افراد دارای معلولیت را نباید صرفاً به یک مثال موقت تقلیل داد. حضور کاربران واقعی در بررسی، چیزهایی نشان می‌دهد که حدس تیم از روی ظاهر نمی‌بیند.
صفحه‌کلید باید مسیر کامل داشته باشد
هر کنترل تعاملی لازم باید با صفحه‌کلید قابل استفاده باشد. لینک، دکمه و ورودی native رفتار پایه شناخته‌شده‌ای دارند؛ div کلیک‌پذیر این رفتار را خودکار ندارد. اگر component سفارشی می‌سازید، مسئولیت نقش، نام و تعامل را هم پذیرفته‌اید. از Tab برای حرکت میان عناصر استفاده می‌شود و ترتیب باید با ساختار محتوا سازگار باشد. جابه‌جایی نمایشی عناصر با CSS نباید خواننده را به مسیری نامفهوم ببرد. انتخاب markup درست بخشی از طراحی تعامل است و فقط کار توسعه‌دهنده در پایان پروژه نیست.
Focus باید دیده شود. حذف outline بدون جایگزین، کاربر صفحه‌کلید را از موقعیت فعلی بی‌خبر می‌کند. ظاهر focus لازم نیست شبیه حالت hover باشد؛ هدفش نشان‌دادن عنصر فعال است. در پس‌زمینه‌های متفاوت و کنار عناصر نزدیک، آن را واضح نگه دارید. اگر header ثابت دارید، کنترل فعال نباید زیر آن پنهان بماند. این مسئله در فرم‌های بلند و ناوبری داخلی بیشتر دیده می‌شود. حرکت درست focus و دیده‌شدن آن را جدا بررسی کنید؛ یکی بدون دیگری تجربه کامل نمی‌سازد.
Dialog و منوهای بازشونده به قرارداد روشن نیاز دارند. کاربر باید بتواند آن‌ها را باز کند، محتوای مرتبط را بخواند و به جای مناسب برگردد. بستن dialog نباید focus را به ابتدای صفحه پرتاب کند. اگر صفحه پس‌زمینه همچنان تعاملی است، رفتار آن باید عمدی باشد. تقلید صرف ظاهر یک پنجره از طرح، رفتار لازم را نمی‌سازد. برای component پیچیده، الگوی معتبر و مستند انتخاب کنید و تصمیم‌های خودتان را به رفتار واقعی وصل کنید.
فرم فارسی به label و پیام روشن نیاز دارد
Placeholder جای label را نمی‌گیرد. وقتی کاربر تایپ می‌کند، باید همچنان بداند فیلد چه داده‌ای می‌خواهد. برای نام، تلفن یا شناسه، قالب مورد انتظار را در متن راهنما توضیح دهید. اگر فقط یک نوع رقم را می‌پذیرید، کاربر فارسی‌زبان ممکن است با خطای نامفهوم روبه‌رو شود. در صورت امکان ورودی معادل را normalize کنید و قرارداد را روشن بنویسید. موضوع تبدیل رقم با جهت نمایش فرق دارد؛ یک فیلد شماره می‌تواند داخل صفحه راست‌به‌چپ به نمایش چپ‌به‌راست نیاز داشته باشد.
خطا باید به فیلد مربوط وصل شود و روش اصلاح را بگوید. «ورودی نامعتبر» برای شماره تلفن اطلاعات کمی می‌دهد. توضیح دقیق‌تر می‌گوید چه چیزی کم است یا چه قالبی پذیرفته می‌شود. خطا را فقط با قرمزشدن border نشان ندهید؛ متن و ارتباط معنایی هم لازم‌اند. بعد از ارسال ناموفق، ورودی‌های سالم را بی‌دلیل پاک نکنید. کاربر باید بتواند اشتباه را اصلاح و ادامه دهد، بدون اینکه دوباره تمام اطلاعات را وارد کند.
موفقیت ارسال هم باید اعلام شود. اگر فرم ناپدید می‌شود و متن تازه‌ای می‌آید، کاربر فناوری کمکی باید از تغییر باخبر شود. پیام موفقیت باید واقعاً با پاسخ سرور هماهنگ باشد؛ نمایش «ثبت شد» پیش از تأیید عملیات اعتماد را خراب می‌کند. مقاله طراحی فرم‌های وب ادامه مناسبی برای بررسی حالت‌هاست. دسترسی‌پذیری و UX در این بخش به یک قرارداد مشترک متکی‌اند: کاربر بداند عملیات در چه وضعیتی است و چه اقدام بعدی دارد.
خواندن محتوا در RTL
زبان و جهت document را درست تعریف کنید و برای محتوای ترکیبی تصمیم جدا بگیرید. نشانی اینترنتی، کد و نام محصول انگلیسی ممکن است در متن فارسی ترتیب ظاهری دشواری داشته باشند. انتخاب جهت مناسب برای همان بخش از سردرگمی جلوگیری می‌کند. ترتیب DOM باید با ترتیب منطقی خواندن هماهنگ بماند. اگر layout با order عناصر را جابه‌جا می‌کند، ببینید خواننده صفحه‌کلید و Screen Reader چه ترتیبی دریافت می‌کنند. شباهت تصویر نهایی به طرح برای اثبات ترتیب منطقی کافی نیست.
Headingها به ساختار محتوا کمک می‌کنند. عنوان بخش را با متن بزرگ داخل div جایگزین نکنید، چون اندازه فونت نقش heading را ایجاد نمی‌کند. از سطح‌ها بر پایه رابطه بخش‌ها استفاده کنید و برای هر چند سطر تیتر مصنوعی نسازید. متن لینک هم مقصد را روشن کند؛ چند لینک «اینجا کلیک کنید» در یک صفحه درباره مسیرها اطلاعات کافی نمی‌دهند. اگر لینک فایل است، نوع فایل و موضوعش می‌تواند در متن یا توضیح نزدیک آن بیاید.
در بزرگ‌نمایی، محتوا نباید پشت یک ارتفاع ثابت پنهان شود. کارت و دکمه با متن بلند ممکن است به فضای بیشتری نیاز داشته باشند. برای فارسی، طول واژه‌ها و شکستن خط را با نمونه واقعی ببینید. قطع‌کردن متن با ellipsis فقط وقتی قابل قبول است که راه دسترسی به اطلاعات کامل وجود داشته باشد و حذف به نیاز کار آسیب نزند. جدول، فهرست و فرم هرکدام رفتار متفاوتی دارند. یک قاعده ثابت برای همه اجزا اغلب به پنهان‌شدن اطلاعات ضروری منجر می‌شود.
تصویر و رنگ را بر اساس کاربرد ارزیابی کنید
Alt باید کار تصویر را در همان صفحه توضیح دهد. برای عکس تزئینی، متن اضافه می‌تواند خواندن را شلوغ کند. برای نمودار، نام کلی «نمودار فروش» اطلاعات کافی نیست و داده مهم باید در متن هم قابل دسترسی باشد. اگر تصویر شامل متن ضروری است، آن متن را تنها راه دریافت اطلاعات نگذارید. هنگام تولید تصویر با AI، از متن و آمار ساختگی پرهیز کنید؛ کیفیت بصری تصویر، صحت اطلاعات یا دسترسی‌پذیری آن را تضمین نمی‌کند.
کنتراست به ترکیب رنگ متن و پس‌زمینه وابسته است. رنگ برند به تنهایی معیار کافی برای متن کوچک نیست. حالت disabled، لینک و پیام خطا را هم بررسی کنید. مقاله Color Contrast و دسترسی‌پذیری درباره این بخش توضیح می‌دهد. اگر وضعیت فقط با رنگ نشان داده می‌شود، نشانه متنی یا شکل قابل فهم اضافه کنید. کاربر نباید برای فهم «موفق» و «ناموفق» مجبور باشد دو رنگ نزدیک را از هم تشخیص دهد.
ابزار خودکار را در کنار بررسی انسانی قرار دهید
ابزارهای خودکار بعضی خطاهای markup و کنتراست را پیدا می‌کنند، اما معنی درست alt یا روشن‌بودن پیام خطا را کامل نمی‌فهمند. نتیجه بدون هشدار درباره تجربه کامل کاربر حکم نمی‌دهد. خروجی ابزار را با بررسی صفحه‌کلید، بزرگ‌نمایی و فناوری کمکی تکمیل کنید. برای گزارش، روش و محیط را ثبت کنید تا دیگران بدانند یافته از کجا آمده است. اگر یک حالت تعاملی بررسی نشده، آن را خارج از محدوده بنویسید؛ این صداقت گزارش را قابل استفاده‌تر می‌کند.
یافته را به پیامد و محل اصلاح وصل کنید. «دکمه مشکل دارد» مبهم است؛ «دکمه ارسال با Tab قابل دسترسی نیست و مسیر فرم متوقف می‌شود» مشخص‌تر است. سپس مالک و اولویت را تعیین کنید. خطاهای مشابه می‌توانند از یک component مشترک بیایند و اصلاح همان component چند صفحه را بهتر کند. این فرصت را در Design System دنبال کنید تا تیم هر بار همان خطا را در طرح جدید تکرار نکند. اصلاح پایدار از علت مشترک شروع می‌شود.
برای شروع در یک سایت ایرانی، مسیر ورود یا درخواست خدمت را انتخاب کنید و موانع توقف را ثبت کنید. عنوان و label، ترتیب focus، خطا و حالت موفقیت را کنار هم بررسی کنید. اعداد بی‌منبع درباره کل کشور برای این تصمیم لازم نیستند. بعد از اصلاح نخستین مسیر، قواعد آن را در اجزای مشترک ثبت کنید و مسیر بعدی را انتخاب کنید. این روال، دسترسی‌پذیری را به کار قابل پیگیری تیم تبدیل می‌کند و اجازه می‌دهد درباره وضعیت واقعی سایت خودتان گزارش دقیق بدهید.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!