دسترس پذیری در طراحی؛ کنتراست، فوکوس و کاهش حرکت | درس 51 + پروژه درس

دسترس پذیری در طراحی یعنی ظاهر صفحه به کاربران بیشتری اجازه خواندن، پیدا کردن کنترل ها و انجام کارها را بدهد. یک صفحه ممکن است زیبا باشد، اما متن کم رنگ، فوکوس نامشخص یا حرکت غیرضروری استفاده از آن را دشوار کند. در درس 51 دوره HTML و CSS ارومیا دیزاین، سه بخش عملی را بررسی می کنیم: کنتراست متن، فوکوس صفحه کلید و احترام به ترجیح کاهش حرکت.

در درس 50 و بهینه سازی CSS، کدهای مشترک را سازماندهی کردیم. حالا همان نظم را برای ساخت تجربه قابل استفاده به کار می بریم. پروژه این درس یک صفحه فارسی با پیوند پرش، ناوبری، پیام متنی و حرکت تزئینی اختیاری است. این نمونه، تمرین بخشی از دسترس پذیری است و به معنی انطباق کامل سایت با همه معیارهای WCAG نیست.

دسترس پذیری از ساختار شروع می شود

پیش از نوشتن CSS، عناصر مناسب HTML را انتخاب کنید. برای رفتن به مقصد از پیوند، برای انجام کنش از button و برای انتخاب دوحالته از checkbox واقعی استفاده کنید. کنترل بومی مرورگر رفتار صفحه کلید و معنای پایه را در اختیار کاربر قرار می دهد. افزودن رنگ یا tabindex به یک div، آن را به دکمه کامل تبدیل نمی کند.

در درس دسترس پذیری در HTML درباره ساختار، تصویر و فرم صحبت کرده ایم. تمرکز امروز روی طراحی دیداری و حرکت است. ترتیب منطقی عنوان ها، برچسب روشن کنترل و محتوای قابل فهم همچنان باید حفظ شوند.

کنتراست متن را اندازه بگیرید

کنتراست، تفاوت روشنایی نسبی رنگ متن و زمینه است. برای متن معمولی، معیار حداقل کنتراست WCAG در سطح AA نسبت 4.5:1 را مشخص می کند. برای متن بزرگ این حد 3:1 است؛ تعریف متن بزرگ در این معیار، حداقل 18pt معمولی یا 14pt ضخیم است. برای شروع، هدف 4.5:1 را برای متن های معمول صفحه نگه دارید.

این اعداد را با حدس یا نگاه کردن به مانیتور تعیین نکنید. رنگ واقعی متن و زمینه را در ابزار سنجش کنتراست وارد کنید. تصویر پشت متن، شفافیت و حالت hover ممکن است نتیجه را تغییر دهند. نسبت متن را هم از کنتراست مرز کنترل و نشانگر فوکوس جدا بررسی کنید؛ یک نسبت واحد برای همه اجزای رابط وجود ندارد.

:root {
  --ink: #0f172a;
  --paper: #ffffff;
  --accent: #075985;
}
body {
  color: var(--ink);
  background-color: #f1f5f9;
}
.panel { background-color: var(--paper); }

در پروژه، سفید روی #075985 حدود 7.56:1 و #0f172a روی سفید حدود 17.85:1 است. این محاسبه برای همین جفت رنگ های تخت انجام شده است. اگر opacity، رنگ یا زمینه را عوض کنید، باید دوباره نسبت را اندازه بگیرید. بررسی چند رنگ نیز جای ارزیابی کل صفحه را نمی گیرد.

پیام را فقط با رنگ منتقل نکنید

یک کادر آبی یا قرمز به تنهایی معنای کافی ندارد. در پروژه، پیام با واژه «توجه» شروع می شود و متن توضیحی دارد. رنگ و کادر نقش مکمل دارند. همین روش را در خطای فرم هم به کار ببرید: توضیح خطا را بنویسید و آن را به فیلد مربوط متصل کنید؛ فقط قرمز کردن حاشیه کافی نیست.

برای پیوندهای داخل متن، زیرخط می تواند تشخیص مقصد قابل کلیک را ساده کند. اگر آن را حذف می کنید، باید تمایز قابل تشخیص دیگری در نظر بگیرید و حالت های مختلف را بررسی کنید. محتوای ضروری را تنها در hover قرار ندهید، چون کاربر لمسی یا صفحه کلید ممکن است به آن دسترسی مناسب نداشته باشد.

فوکوس صفحه کلید باید دیده شود

با Tab بین کنترل های تعاملی حرکت کنید. کاربر باید بداند اکنون کدام پیوند یا ورودی فعال است. focus-visible راهی برای نمایش نشانگر در وضعیتی است که مرورگر آن را لازم تشخیص می دهد، معمولا هنگام کار با صفحه کلید. حالت hover جای فوکوس را نمی گیرد.

a:focus-visible,
input:focus-visible {
  outline: 3px solid #0f172a;
  outline-offset: 4px;
}

در این نمونه، outline از کادر عنصر فاصله دارد و فضای چیدمان را مثل border اضافه تغییر نمی دهد. با این حال، والد دارای overflow محدود می تواند آن را ببرد. نشانگر را در حالت واقعی بررسی کنید: کنار زمینه های مختلف، داخل کارت و نزدیک لبه نمایشگر. از outline: none بدون جایگزین قابل مشاهده استفاده نکنید.

اگر داخل یک والد، نشانگر بریده شد، ابتدا علت محدود شدن را پیدا کنید. توضیح رفتار سرریز در درس overflow در CSS آمده است. اضافه کردن کادر ضخیم به تنهایی کافی نیست اگر بخشی از آن دیده نشود یا هدر ثابت کنترل را بپوشاند.

پیوند پرش به محتوای اصلی

کاربری که هر بار وارد صفحه می شود نباید مجبور باشد تمام ناوبری تکراری را طی کند. اولین عنصر پروژه، پیوند «رفتن به محتوای اصلی» است. در حالت عادی از بالای صفحه بیرون قرار می گیرد و هنگام فوکوس نمایش داده می شود. برای این کار display: none به آن نمی دهیم، زیرا باید در مسیر صفحه کلید باقی بماند.

<a class="skip-link" href="#main">رفتن به محتوای اصلی</a>
<main id="main" tabindex="-1">
  <h1>طراحی برای همه کاربران</h1>
</main>

مقدار tabindex برابر -1، main را به ترتیب عادی Tab اضافه نمی کند، اما آن را برای دریافت فوکوس قابل هدف گیری می کند. رفتار انتقال فوکوس با پیوند داخلی را در مرورگر هدف بررسی کنید. از tabindex مثبت برای بازچینی مصنوعی ترتیب کنترل ها استفاده نکنید؛ ترتیب DOM باید با ترتیب خواندن و استفاده هماهنگ باشد.

در ناوبری پروژه، همه پیوندها با wrap در عرض کم روی سطر بعد می روند. اگر منوی کامل تری می سازید، درس منوی واکنش گرا را مرور کنید و ترتیب صفحه کلید را پس از هر تغییر چیدمان دوباره آزمایش کنید.

کاهش حرکت را به تصمیم کاربر متصل کنید

برخی کاربران حرکت های بزرگ یا تکراری را آزاردهنده تجربه می کنند. prefers-reduced-motion ترجیح کاهش حرکت را از تنظیمات محیط دریافت می کند. این ویژگی به تنهایی هیچ انیمیشنی را حذف نمی کند؛ شما باید برای آن قاعده مناسب بنویسید. همچنین خاموش بودن این ترجیح به معنی مجاز بودن هر نوع حرکت نیست.

در پروژه، حرکت پس از انتخاب checkbox شروع می شود و فقط چهار چرخه 600 میلی ثانیه ای دارد. نقطه تزئینی است و aria-hidden دارد؛ آن را نشانه انجام یک درخواست واقعی معرفی نکرده ایم. کاربر می تواند انتخاب را بردارد تا حرکت حذف شود. با فعال شدن کاهش حرکت، نقطه ثابت باقی می ماند و هیچ محتوایی ناپدید نمی شود.

@keyframes nudge {
  from { transform: translateX(0); }
  to { transform: translateX(-48px); }
}
#run:checked ~ .track .dot {
  animation: nudge 600ms ease-in-out 4 alternate;
}
@media (prefers-reduced-motion: reduce) {
  #run:checked ~ .track .dot { animation: none; }
}

برای مرور تعریف مراحل، جهت alternate و تعداد چرخه ها، درس انیمیشن و keyframes را ببینید. اگر حرکت، اطلاعات واقعی را منتقل می کند، حذف آن باید همراه نمایش جایگزین معنادار باشد. در این پروژه اطلاعات به نقطه وابسته نیست.

یک قاعده سراسری که زمان همه انیمیشن ها را تقریبا صفر کند، ممکن است منطق اجزایی را که به رویداد پایان وابسته اند مختل کند. بهتر است حرکت هر جزء را آگاهانه تنظیم کنید. انتقال های کوتاه هم باید با همین نگاه بررسی شوند؛ درس transition جزئیات مدت و ویژگی انتقال را توضیح می دهد.

خوانایی در موبایل و بزرگ نمایی

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

به کار بردن clamp به تنهایی دسترس پذیری را تضمین نمی کند. خوانایی و رفتار بزرگ نمایی را روی نتیجه واقعی بسنجید. برای مرور محدود کردن اندازه ها، درس توابع min و clamp در CSS را بخوانید. اگر یک کادر کد عریض است، اسکرول افقی همان کادر بهتر از بیرون زدن کل صفحه است.

آزمایش عملی پروژه درس 51

1. ZIP را استخراج و index.html را باز کنید. اولین Tab باید پیوند پرش را نشان دهد.
2. با Enter به محتوای اصلی بروید؛ سپس با Tab و Shift+Tab مسیر کنترل ها را بررسی کنید.
3. گزینه حرکت را با Space فعال کنید. با برداشتن انتخاب، حرکت باید حذف شود.
4. کاهش حرکت را در سیستم یا بخش Rendering ابزار توسعه مرورگر فعال کنید. گزینه را دوباره امتحان کنید؛ نقطه باید ثابت بماند.
5. عرض 320 پیکسل و بزرگ نمایی 200 درصد را بررسی کنید. متن و کنترل ها باید در دسترس بمانند.
6. رنگ های حالت عادی و هر حالت تازه ای که اضافه می کنید را با ابزار کنتراست اندازه بگیرید.

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

تمرین: حالت فوکوس و هاور یک پیوند

practice.css را پس از style.css به صفحه متصل کنید. برای practice-link در حالت focus-visible یک outline به ضخامت 3px با فاصله 4px بسازید. در hover ضخامت زیرخط را به 2px افزایش دهید. رنگ متن و زمینه را نگه دارید و هیچ قاعده ای برای حذف فوکوس پیش فرض اضافه نکنید.

<link rel="stylesheet" href="style.css">
<link rel="stylesheet" href="practice.css">

پس از حل مستقل، solution.css را به جای practice.css متصل کنید. فایل پاسخ جداست و در صفحه اولیه بارگذاری نمی شود. با ماوس و صفحه کلید آزمایش کنید؛ یک ظاهر مناسب برای hover نمی تواند نبود نشانگر فوکوس را جبران کند.

پرسش های متداول

آیا دسترس پذیری فقط برای صفحه خوان است؟

خیر. خوانایی، صفحه کلید، بزرگ نمایی، حرکت و روش های مختلف تعامل هم بخشی از موضوع هستند.

آیا پس زمینه تیره همیشه خواناتر است؟

خیر. نسبت رنگ متن و زمینه و شرایط استفاده مهم است. هر دو تم روشن و تیره نیاز به بررسی دارند.

آیا رعایت این سه موضوع یعنی سایت کاملا دسترس پذیر است؟

خیر. این درس فقط بخشی از طراحی را پوشش می دهد. ساختار، فرم ها، رسانه، پیام ها و مسیرهای کامل انجام کار هم باید ارزیابی شوند.

درس قبلی: بهینه سازی CSS و جلوگیری از کدهای تکراری

منابع: حداقل کنتراست متن در W3C، فوکوس قابل مشاهده در W3C و کاهش حرکت در MDN.