Toggle Switch برای انتخاب میان دو وضعیت مانند روشن و خاموش به کار می‌رود. اما هر انتخاب دوحالته الزاماً Switch نمی‌خواهد. مهم است کاربر بفهمد چه چیزی عوض می‌شود، چه زمانی اثر می‌کند و آیا ذخیره شده است. شکل کشویی کوچک، به‌تنهایی این قرارداد را منتقل نمی‌کند. اگر نتیجه به ارسال فرم یا تأیید بعدی وابسته است، باید این تفاوت روشن باشد. کنترل را از روی رفتار انتخاب کنید و سپس ظاهر آن را طراحی کنید.
برای مثال فرضی، کاربر می‌خواهد نمایش جزئیات یک فهرست را روشن کند. اگر نتیجه همان لحظه در صفحه دیده می‌شود، Switch می‌تواند انتخاب مناسبی باشد. در مقابل، انتخاب چند علاقه‌مندی در فرم ثبت‌نام که بعداً ارسال می‌شوند، شاید با Checkbox روشن‌تر باشد. حذف حساب یا انتشار عمومی داده نیز صرفاً یک ترجیح کم‌اثر نیست. شباهت داشتن دو وضعیت نباید باعث شود ریسک و تعهد آن‌ها یکسان دیده شود.
اثر فوری را از انتخاب فرم جدا کنید
پرسش نخست این است که تغییر کنترل چه زمانی اعمال می‌شود. اگر کاربر با روشن کردن، قابلیت را فعال می‌کند، بازخورد فوری لازم است. اگر باید دکمه ذخیره بزند، این رفتار باید از ساختار فرم فهمیده شود. ترکیب چند Switch با بعضی تغییرهای فوری و بعضی تغییرهای منتظر ذخیره، بدون مرز روشن، ابهام می‌سازد. در یک گروه، قرارداد یکسان نگه دارید یا تفاوت را آشکار توضیح دهید.
Checkbox برای انتخاب در یک مجموعه نیز مناسب است و می‌تواند مستقل یا وابسته باشد. Radio برای یکی از چند گزینه است. اگر سه وضعیت روشن، خاموش و پیروی از سیستم دارید، Switch دوحالته کافی نیست. گزینه «خودکار» را نباید در یکی از دو وضعیت پنهان کرد. طراحی Settings برای دسته‌بندی و دامنه تنظیم مرتبط است. نام الگو نباید جای بررسی تعداد و معنای حالت‌ها را بگیرد.
برچسب باید نام ویژگی را ثابت نگه دارد
برچسبی مانند «نمایش جزئیات» با وضعیت روشن و خاموش قابل فهم است. اگر متن با تغییر وضعیت به «مخفی کردن جزئیات» تبدیل شود، ممکن است معلوم نباشد نام کنترل است یا عمل بعدی. نام ثابت و وضعیت جدا معمولاً روشن‌ترند. برای عبارت منفی مثل «غیرفعال کردن اعلان‌ها» نیز دقت کنید؛ روشن بودن کنترل ممکن است به معنای خاموش شدن اعلان باشد و تفسیر را دشوار کند.
توضیح کوتاه می‌تواند دامنه را روشن کند: فقط همین صفحه، همین دستگاه یا تمام حساب. اگر اثر بر دیگران وجود دارد، آن را پیش از انتخاب نشان دهید. در مثال تیم، یک تنظیم شخصی نباید ظاهری مشابه کنترل اعلان همه اعضا داشته باشد بدون اینکه دامنه گفته شود. ارتباط روشن در محصول از نظر بیان نیاز و محدودیت مرتبط است. متن باید به رفتار واقعی متصل باشد و وعده ذخیره ناموجود ندهد.
رنگ تنها نشانه وضعیت نباشد
تفاوت جای دسته، متن وضعیت و ساختار معنایی می‌توانند در کنار رنگ کمک کنند. سبز و خاکستری بدون نشانه دیگر برای همه کاربران کافی نیست. کنتراست کنترل و Focus را حفظ کنید. اگر حالت غیرفعال وجود دارد، علت آن را توضیح دهید؛ کاربر نباید برای فهم محدودیت فقط یک رنگ کم‌رنگ ببیند. کنترل غیرقابل تغییر با وضعیت خاموش فرق دارد و این تفاوت باید قابل دریافت باشد.
الگوی Switch در W3C APG درباره نام، وضعیت و تعامل صفحه‌کلید توضیح می‌دهد. استفاده از عنصر بومی می‌تواند بخشی از رفتار را فراهم کند. افزودن role بدون پیاده‌سازی درست، دسترس‌پذیری را کامل نمی‌کند. اگر کنترل سفارشی می‌سازید، باید نام و حالت و تعامل را هماهنگ نگه دارید. ظاهر مشابه با یک الگو، به معنای رفتار صحیح آن نیست.
نمونه کامل محلی با کنترل بومی
فایل زیر را با نام switch-demo.html ذخیره و در مرورگر باز کنید؛ وابستگی و نصب ندارد. Checkbox با role برابر switch، برچسب ثابت و توضیح مرتبط ساخته شده است. Space پس از Focus وضعیت را تغییر می‌دهد و انتخاب برچسب نیز کنترل را عوض می‌کند. نتیجه فقط نمایش جزئیات همین صفحه است. داده به سرور نمی‌رود و پس از بارگذاری دوباره به وضعیت اولیه برمی‌گردد؛ این نمونه ادعای ذخیره دائمی ندارد.
<!doctype html>
<html lang="fa" dir="rtl">
<meta charset="utf-8">
<meta name="viewport" content="width=device-width,initial-scale=1">
<title>نمونه Switch محلی</title>
<style>
body {font:1rem/1.9 system-ui,sans-serif;max-width:45rem;margin:2rem auto;padding:0 1rem;background:#fff;color:#172231}
label {display:inline-flex;align-items:center;gap:.8rem;cursor:pointer;padding:.5rem}
input {appearance:none;width:3.2rem;height:1.8rem;border:2px solid #555;border-radius:1rem;background:#eee;position:relative;cursor:pointer}
input::before {content:'';position:absolute;width:1.2rem;height:1.2rem;border-radius:50%;background:#333;top:.15rem;right:.15rem}
input:checked {background:#1452a0;border-color:#1452a0}
input:checked::before {right:auto;left:.15rem;background:#fff}
@media (forced-colors:active) {input {appearance:auto} input::before {display:none}}
input:focus-visible {outline:3px solid #aa5000;outline-offset:4px}
#details {border:1px solid #777;padding:1rem}
</style>
<body>
<main>
<h1>نمایش جزئیات</h1>
<label for="details-switch">
<input id="details-switch" type="checkbox" role="switch" aria-describedby="scope">
نمایش جزئیات
</label>
<p id="scope">فقط نمایش همین صفحه تغییر می‌کند؛ این انتخاب ذخیره دائمی ندارد.</p>
<p id="status" role="status">وضعیت: خاموش</p>
<section id="details" hidden>
<h2>جزئیات نمونه</h2>
<p>این بخش با روشن شدن کنترل دیده می‌شود.</p>
</section>
</main>
<script>
const toggle = document.getElementById('details-switch');
const details = document.getElementById('details');
const status = document.getElementById('status');
function updateView() {
details.hidden = !toggle.checked;
status.textContent = toggle.checked ? 'وضعیت: روشن' : 'وضعیت: خاموش';
}
toggle.addEventListener('change', updateView);
updateView();
</script>
</body>
</html>
در این فایل، checked منبع وضعیت کنترل است و متن جدا، نتیجه فعلی را نشان می‌دهد. استفاده از aria-describedby رابطه توضیح دامنه و کنترل را مشخص می‌کند. بخش جزئیات با hidden تغییر می‌کند و برای نتیجه، پیام متنی وجود دارد. این نمونه برای آموزش رفتار است؛ در محصول واقعی باید با نیاز صفحه، قالب و سیاست ذخیره هماهنگ شود. کپی ظاهر بدون توجه به دامنه و بازخورد می‌تواند همان ابهام قبلی را حفظ کند.
ذخیره شبکه‌ای وضعیت‌های بیشتری دارد
اگر تغییر به سرور فرستاده می‌شود، روشن شدن ظاهری لزوماً به معنای ثبت نیست. حالت در حال ذخیره، موفق و خطا را در نظر بگیرید. می‌توانید تا پاسخ، کنترل را طبق طراحی محدود کنید یا تغییر خوش‌بینانه را با امکان برگشت مدیریت کنید. در هر دو روش، کاربر باید بداند چه اتفاقی افتاده است. چند درخواست پشت سر هم نباید پاسخ قدیمی را روی انتخاب تازه اعمال کنند.
اگر ذخیره شکست خورد، وضعیت قبلی یا وضعیت نامطمئن را روشن نمایش دهید و راه تلاش دوباره بدهید. پیام «ذخیره شد» قبل از تأیید واقعی مناسب نیست. راهنمای اعلان فرم W3C بر پیام واضح و راه اصلاح توجه دارد. برای تغییر حساس، برگشت وضعیت فقط مسئله ظاهری نیست؛ باید بدانید سمت سرور چه چیزی اعمال شده تا متن رابط واقعیت را نشان دهد.
وابستگی میان گزینه‌ها را توضیح دهید
گاهی روشن شدن یک قابلیت، چند گزینه دیگر را در دسترس قرار می‌دهد. رابطه را با گروه‌بندی و توضیح نشان دهید. پنهان شدن ناگهانی فیلد ممکن است کاربر را درباره داده قبلی نگران کند. مشخص کنید خاموش کردن قابلیت چه اثری بر مقدارهای زیرمجموعه دارد: حفظ می‌شوند، پاک می‌شوند یا فقط استفاده نمی‌شوند. این تصمیم باید پیش از پیاده‌سازی روشن باشد و با رفتار واقعی ذخیره سازگار بماند.
برای نقش فاقد اختیار، کنترل را به‌عنوان گزینه قابل تغییر نمایش ندهید. علت محدودیت و در صورت وجود، مسیر درخواست دسترسی را بگویید. کنترل دسترسی باید سمت سرور نیز اعمال شود؛ غیرفعال کردن عنصر در مرورگر امنیت ایجاد نمی‌کند. طراحی فرم به این رابطه و پیام مرتبط است. ترکیب مجوز، وابستگی و ذخیره را در یک رنگ خاکستری خلاصه نکنید، چون علت‌ها متفاوت‌اند.
تغییر پرریسک همیشه Switch مناسب ندارد
اگر اقدام داده را حذف می‌کند یا تعهد مهم می‌سازد، دکمه و تأیید متناسب ممکن است روشن‌تر باشد. Switch معمولاً حس یک وضعیت قابل برگشت می‌دهد. برای انتشار عمومی، اگر داده پس از دیده شدن قابل پس گرفتن کامل نیست، این محدودیت مهم است. کنترل را فقط به خاطر کم‌جا بودن انتخاب نکنید. در تصمیم، امکان برگشت، اثر بر دیگران و نیاز به توضیح را کنار هم ببینید.
برای ترجیح کم‌اثر نیز تأییدهای پی‌درپی نسازید. توقف هر تغییر با دیالوگ می‌تواند کار را سخت کند و خواندن هشدارهای مهم را کم‌رنگ سازد. برگشت‌پذیری در تصمیم برای این سنجش مرتبط است. ریسک باید اندازه بررسی را تعیین کند، نه یک قاعده ثابت که همه کنترل‌ها را به یک شکل رفتار دهد. هدف، انتخاب قابل فهم و اثر قابل پیش‌بینی است.
در رابط راست‌به‌چپ، جهت حرکت را با ظاهر و متن وضعیت هماهنگ کنید. کاربر باید بتواند روشن و خاموش را بدون تکیه بر جای دسته بفهمد. از الگوی آشنای محصول استفاده کنید و معنای وضعیت را در همه صفحه‌ها یکسان نگه دارید.
با وظیفه و خطای واقعی بازبینی کنید
ببینید کاربر نام، وضعیت و دامنه را می‌فهمد و پس از تغییر از نتیجه مطمئن می‌شود یا نه. موبایل، صفحه‌کلید، متن طولانی فارسی و خطای ذخیره را در طراحی لحاظ کنید. Mobile First و تعریف شاخص مرتبط‌اند. زیبایی حرکت دسته، معیار کامل موفقیت نیست. Switch زمانی مناسب است که دو وضعیت، اثر و روش ثبت آن برای کاربر و سیستم یک قرارداد روشن داشته باشند.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!