Accessibility

تم تاریک

چه چیزهایی باید حس خطر ما را فعال کنند؟ ​

با تمرین، متوجه خواهیم شد که برخی مشکلات accessibility در وب از فاصله‌ی خیلی دور هم قابل تشخیص هستند. داشتن کنجکاوی و پیروی از یک روند بررسی منظم بسیار مهم است. (در ادامه به آن خواهیم پرداخت)

در اینجا برخی از مشکلات رایج را معرفی می‌کنیم که باید شاخک‌های ما را بلند کنند! هدف این است که کنیم آن‌ها را در code review و دموها شناسایی کنیم.

در مواجهه با این موارد باید با مهربانی برخورد کرد و قضاوت نکرد، اما در عین حال باید مشکلات accessibility را — ترجیحاً پیش از انتشار — شناسایی کرد:

label‌گذاری فرم با span ​

این مورد برای بسیاری از ما آشناست: یک input معمولی در فرم که متن label آن در کنار آن آمده، اما با یک تگ عمومی مثل span یا div نوشته شده است.

html
<div className="form-control">
    <span className="label-text">First Name</span>
    <input type="text" id="first-name" name="first-name" required />
</div>

نویسنده‌ی این کد ممکن است استفاده از تگ label را فراموش کرده باشد یا هنوز با آن آشنا نشده باشد. در اکثر موارد، جایگزینی span با label (با استفاده از for و id یا wrap کردن label دور input) ساده است.

مزیت دیگر: label‌گذاری صحیح input، یک accessible name ایجاد می‌کند و ناحیه‌ی قابل کلیک را بزرگ‌تر می‌کند.

راه‌کار ساده

برای چک کردن اینکه یک label به درستی داخل یک فرم ست شده، می‌توان روی label کلیک کرد و انتظار این را داشت که روی خود input فکوس قرار بگیرد.

کنترل‌های سفارشی ​

کنترل‌های فرم همواره یکی از چالش‌های accessibility بوده‌اند، چون استایل‌دهی به آن‌ها دشوار بوده است.

خوشبختانه، در سال‌های اخیر این موضوع تا حد زیادی بهبود یافته، چون مرورگرها امکانات استایل‌دهی و APIهای جدیدی اضافه کرده‌اند. اما هر زمان که با کنترل‌های سفارشی مثل dropdown، select، date picker، یا typeahead مواجه شدید، حتماً آن را تست کنید. ممکن است در پروژه‌های سازمانی، نتوانید از آخرین فناوری‌های مرورگر استفاده کنید. با این حال، اکنون در دوران طلایی UIهای وب قرار داریم.

منبع: What’s new in HTML and CSS in 2023? از Una Kravenoff و Jason Lengstorf

رنگ‌ها ​

کنتراست یکی از مشکلات رایج accessibility در وب است. تشخیص این مورد اغلب نیاز به تست در مرورگر دارد تا نسبت کنتراست نامناسب مشخص شود.

ابزارهای خودکار می‌توانند مشکلات کنتراست را که به‌صورت برنامه‌ریزی‌شده قابل محاسبه هستند شناسایی کنند. اما بسیاری از تست‌های خودکار به گونه‌ای تنظیم شده‌اند که اجازه عبور کد با مشکلات accessibility را می‌دهند.

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

modal‌ها و لایه‌ها ​

modal‌ها یکی از بخش‌های مهم هستند. هر چیزی که به‌صورت یک لایه‌ی جدید روی محتوای دیگر باز می‌شود، الزامات خاصی برای accessibility دارد، از جمله:

  • انتقال focus به محتوای جدید هنگام باز شدن.
  • بازگرداندن focus به عنصری که کاربر قبلاً روی آن بود پس از بسته شدن لایه.
  • جلوگیری از تعامل کیبورد و screen reader با عناصر پس‌زمینه.
  • استفاده از نقش dialog، دکمه‌ها و CTAهای قابل focus و دارای label.

دیالوگ‌های غیرmodal تمام این الزامات مربوط به پس‌زمینه را ندارند. اما هدف همچنان این است که focus به محتوای مرتبط منتقل شود، چه هنگام باز شدن، چه هنگام بسته شدن دیالوگ.

تعامل فقط با ماوس ​

این مورد بسیار رایج است؛ استفاده از یک تگ عمومی مثل DIV برای اجرای رویداد کلیک:

javascript
<div onClick={clickHandler}>
    Renew Contract
</div>

تقریباً هیچ‌وقت در این موارد معادل accessible برای عملکرد فراهم نشده است. بنابراین فقط کاربران ماوس قادر به اجرای این عملکرد هستند، چون تگ DIV نه focus‌پذیر است و نه با کیبورد تعاملی دارد. وضعیت برای screen reader نیز مناسب نخواهد بود.

در بخش بعدی به این موضوع بیشتر خواهیم پرداخت!