دسترس‌پذیری وب؛ چک‌لیست کاربردی

۰۱دسترس‌پذیری وب یعنی چه و چرا مهم است؟

دسترس‌پذیری (accessibility، به‌اختصار a11y) یعنی طراحی و کدنویسی به‌شکلی که افراد با توانایی‌های متفاوت بتوانند محتوا را ببینند، بشنوند، بفهمند و با آن کار کنند. این گروه فقط افراد دارای معلولیت دائمی نیستند: دست شکسته، نور زیاد، اینترنت کند و صفحه‌ی کوچک هم محدودیت موقت ایجاد می‌کنند.

مرجع بین‌المللی این حوزه دستورالعمل‌های WCAG از ابتکار دسترس‌پذیری وب W3C است که اصول چهارگانه‌ی «قابل‌درک، قابل‌استفاده، قابل‌فهم و مقاوم» را تعریف می‌کند. خبر خوب این است که رعایت آن، به‌طور جانبی سئو و کیفیت کد را هم بهتر می‌کند؛ مثلاً ساختار عنوان‌ها و متن جایگزین تصاویر برای گوگل هم سیگنال مفیدی است (در راهنمای سئوی تکنیکال بیشتر درباره‌ی آن نوشته‌ایم).

۰۲HTML معنادار: ۸۰٪ کار

صفحه‌خوان‌ها و کیبورد از ساختار HTML استفاده می‌کنند. یک <div onclick> برای ماوس دکمه است، اما برای کیبورد و صفحه‌خوان فقط یک جعبه است. عنصر درست را انتخاب کنید و همه‌چیز رایگان می‌آید: فوکوس، فعال‌سازی با Enter و Space و اعلام نقش.

<!-- Bad: not focusable, no role -->
<div class="btn" onclick="save()">Save</div>

<!-- Good -->
<button type="button" onclick="save()">Save</button>

<header>…</header>
<nav aria-label="Main">…</nav>
<main id="main">
  <h1>Page title</h1>
  <section aria-labelledby="s1"><h2 id="s1">Section</h2></section>
</main>
<footer>…</footer>

• فقط یک <h1> در هر صفحه و سطح‌های عنوان بدون پرش (h2 زیر h1، h3 زیر h2).
• لینک برای رفتن به نشانی، دکمه برای انجام کار. این دو را جابه‌جا نکنید.
• نشانه‌گذاری‌های header، nav، main و footer به کاربر صفحه‌خوان اجازه می‌دهند مستقیم به بخش دلخواه بپرد.
• یک لینک «پرش به محتوا» در ابتدای صفحه بگذارید.

۰۳کیبورد و فوکوس

بخش بزرگی از کاربران فقط با کیبورد کار می‌کنند: نابینایان، کاربران ابزارهای کمکی و افراد با مشکلات حرکتی. آزمون ساده این است که ماوس را کنار بگذارید و با Tab و Shift+Tab کل صفحه را بپیمایید. ترتیب فوکوس باید با ترتیب بصری یکی باشد و همیشه معلوم باشد فوکوس کجاست.

/* Never remove the outline without a replacement */
:focus-visible {
  outline: 3px solid #1a73e8;
  outline-offset: 2px;
}

/* Visually hidden but available to screen readers */
.sr-only {
  position: absolute; width: 1px; height: 1px;
  margin: -1px; padding: 0; overflow: hidden;
  clip: rect(0 0 0 0); white-space: nowrap; border: 0;
}

خطای رایج دیگر، پنجره‌های مودال است. هنگام باز شدن مودال فوکوس باید داخل آن برود، با Tab از آن بیرون نیفتد، با Esc بسته شود و پس از بستن به دکمه‌ی بازکننده برگردد. عنصر <dialog> با showModal() بیشتر این رفتارها را بومی انجام می‌دهد.

۰۴رنگ، کنتراست و متن

پیشنهاد WCAG سطح AA این است که متن عادی دست‌کم نسبت کنتراست ۴٫۵ به ۱ با پس‌زمینه داشته باشد و متن بزرگ (حدود ۱۸ پوینت یا ۱۴ پوینت ضخیم) ۳ به ۱. خاکستری روشن روی سفید، رایج‌ترین جایی است که این معیار رعایت نمی‌شود. با ابزار بررسی کنتراست داخل DevTools مرورگر می‌توانید در چند ثانیه آن را بسنجید.

• هرگز اطلاعات را فقط با رنگ منتقل نکنید؛ برای خطا علاوه بر قرمزی، آیکون و متن هم بگذارید.
• اندازه‌ی متن را با واحد نسبی (rem) بنویسید تا با تنظیم مرورگر بزرگ شود، و صفحه تا ۲۰۰٪ بزرگ‌نمایی بدون شکستن چیدمان کار کند.
• هدف‌های لمسی دست‌کم حدود ۴۴ در ۴۴ پیکسل باشند و فاصله کافی داشته باشند.
• انیمیشن‌ها را با prefers-reduced-motion محدود کنید؛ این موضوع در انیمیشن‌های CSS و جاوااسکریپت بیشتر بررسی شده است.

۰۵تصاویر، فرم‌ها و ARIA

متن جایگزین تصاویر

هر تصویر معنادار یک alt می‌خواهد که کارکرد تصویر را بگوید، نه فقط ظاهرش را. تصویر تزئینی باید alt="" داشته باشد تا صفحه‌خوان از آن بگذرد. عبارت «تصویر از…» را نیاورید؛ صفحه‌خوان خودش می‌گوید این یک تصویر است.

برچسب و خطای فرم

هر فیلد باید یک <label> واقعی داشته باشد؛ placeholder جایگزین برچسب نیست چون با شروع تایپ ناپدید می‌شود. پیام خطا را با aria-describedby به فیلد وصل کنید.

<label for="email">Email</label>
<input id="email" type="email" name="email"
       autocomplete="email" required
       aria-invalid="true" aria-describedby="email-err">
<p id="email-err" role="alert">Enter a valid email, e.g. [email protected]</p>

ARIA فقط وقتی لازم است

قاعده‌ی اول ARIA این است که اگر عنصر HTML بومی همان کار را می‌کند، از ARIA استفاده نکنید. ARIA فقط معنا را به فناوری کمکی می‌گوید و رفتار نمی‌سازد؛ یک role="button" هنوز کلید Enter را خودش مدیریت نمی‌کند. برای ویجت‌های پیچیده مثل تب و منوی کشویی، الگوهای مستند MDN درباره‌ی دسترس‌پذیری را دنبال کنید.

۰۶تست سریع: بدون ابزار گران

ابزارهای خودکار مثل Lighthouse و axe بخشی از مشکل‌ها را پیدا می‌کنند، اما تشخیص «آیا این تجربه قابل‌استفاده است؟» به آزمون دستی نیاز دارد. این ترتیب برای یک بررسی ده‌دقیقه‌ای خوب است:

1. اسکن خودکار با Lighthouse یا افزونه‌ی axe و رفع خطاهای آشکار.
2. پیمایش کامل با کیبورد: همه‌چیز قابل‌دسترسی است؟ فوکوس دیده می‌شود؟
3. بزرگ‌نمایی ۲۰۰٪ و نمایش روی عرض ۳۲۰ پیکسل؛ چیزی بریده یا روی هم نمی‌افتد؟
4. گوش‌دادن به صفحه با یک صفحه‌خوان (NVDA در ویندوز، VoiceOver در مک و iOS) برای جریان اصلی، مثلاً ثبت‌نام یا خرید.
5. بررسی کنتراست و حالت‌های خطا و بارگذاری.

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