کاربر ممکن است بعد از خواندن صفحه به دنبال راه تماس، شرایط استفاده یا پاسخ یک سؤال درباره خرید باشد. Footer باید این مسیرهای تکمیلی را قابل یافتن کند. قرار دادن فهرست بلند تمام لینک‌ها در انتهای سایت، به خودی خود ناوبری خوبی نمی‌سازد. ابتدا مشخص کنید کدام اطلاعات در پایان صفحه لازم‌اند و هر لینک به کدام مقصد معتبر می‌رود.
Footer برای همه سایت‌ها ترکیب ثابت ندارد. سایت آموزشی، فروشگاه و پنل کاری نیازهای متفاوتی دارند. فرم خبرنامه، چند نماد و شبکه اجتماعی عناصر اجباری طراحی عمومی نیستند. اگر محصول راه پشتیبانی مشخصی دارد، همان راه را معرفی کنید. اگر خبرنامه‌ای منتشر نمی‌شود، افزودن یک فرم نمایشی صرفاً برای پر کردن فضای خالی تجربه قابل اعتمادی نمی‌سازد.
فهرست مقصدها را از نیاز کاربر بسازید
در نمونه فرضی یک فروشگاه، راه پیگیری سفارش، شرایط مرجوعی و اطلاعات تماس می‌توانند مقصدهای مهم باشند. این مثال نتیجه یک مشتری واقعی نیست. در سایت انتشار مقاله، درباره نویسنده و شیوه تماس اولویت دیگری دارند. از داده جست‌وجو، درخواست‌های پشتیبانی و مشاهده کار استفاده کنید تا بفهمید کدام مقصدها سخت پیدا می‌شوند؛ کپی Footer یک سایت بزرگ لزوماً همان نیاز را پاسخ نمی‌دهد.
برای هر لینک، عنوان و مقصد را کنار هم ثبت کنید. «پشتیبانی» ممکن است فرم درخواست، شماره تماس یا مرکز راهنما باشد. عنوان باید نوع مقصد را قابل پیش‌بینی کند. اگر فقط ایمیل ارائه می‌کنید، دکمه‌ای با نام «گفت‌وگوی فوری» وعده دیگری می‌دهد. کاربر نباید پس از انتخاب، تازه بفهمد مسیر معرفی‌شده با نام آن فرق دارد.
لینک‌های کم‌استفاده را صرفاً به دلیل وجود در ساختار داخلی سایت اضافه نکنید. Footer می‌تواند بعضی مسیرهای ثانویه را پوشش دهد، اما جای نقشه کامل پایگاه داده نیست. مسیر لازم برای کار اصلی باید در محتوای مربوط نیز دیده شود. برای نمونه، شرط مرجوعی نباید فقط در Footer باشد اگر در تصمیم خرید همان لحظه اهمیت دارد.
گروه‌ها عنوان قابل فهم داشته باشند
گروه‌بندی با نام‌هایی مانند «خرید و پیگیری» یا «درباره مجموعه» زمینه لینک‌ها را روشن می‌کند. عنوان‌هایی مثل «لینک‌های مفید» اغلب تفاوت گروه را توضیح نمی‌دهند. اگر فقط سه مقصد دارید، شاید دو ستون با عنوان‌های اضافی لازم نباشد. ساختار باید با تعداد و رابطه واقعی لینک‌ها هماهنگ باشد، نه با تقارن قالب.
ترتیب گروه‌ها را با نیاز و جهت نوشتار هماهنگ کنید. در فارسی، آغاز متن معمولاً راست است، ولی اهمیت یک مسیر باید در ترتیب DOM هم قابل فهم بماند. تغییر صرفاً دیداری ستون‌ها می‌تواند مسیر Keyboard را متفاوت کند. در عرض کوچک، گروه‌ها باید به ترتیب منطقی تبدیل شوند و عنوان هر گروه نزدیک لینک‌های خودش بماند.
اگر بخشی از Footer navigation است، آن را با nav مناسب و نام مشخص معرفی کنید. چند navigation در صفحه ممکن است به نام‌های متمایز نیاز داشته باشند تا کاربر فناوری کمکی آن‌ها را جدا کند. راهنمای Landmark Regions در WAI-ARIA APG به ساختار و نام‌گذاری ناحیه‌ها می‌پردازد. افزودن Landmark برای هر ستون کوچک هم می‌تواند فهرست ناحیه‌ها را بی‌دلیل شلوغ کند.
معنای HTML با جای دیداری Footer فرق دارد
طبق راهنمای footer در MDN، این عنصر اطلاعات پایانی نزدیک‌ترین محتوای بخش‌بندی‌شده یا صفحه را معرفی می‌کند. Footer یک article می‌تواند اطلاعات نویسنده همان مقاله باشد و با Footer کل سایت تفاوت دارد. قرار گرفتن یک کادر پایین صفحه، به تنهایی معنای آن را مشخص نمی‌کند؛ ساختار باید با محتوایی که معرفی می‌کند سازگار باشد.
برای Footer اصلی، آن را در ساختار مناسب صفحه نگه دارید و از تکرار غیرضروری role روی عنصر بومی دور بمانید. نام سایت یا توضیح کوتاه می‌تواند زمینه بدهد، اما لازم نیست header کامل دوباره ساخته شود. اگر متن معرفی طولانی است، مسیر «درباره ما» معمولاً محل مناسب‌تری برای جزئیات است. Footer باید مقصد را معرفی کند و پایان صفحه را بی‌دلیل سنگین نکند.
تاریخ copyright را با واقعیت انتشار و سیاست حقوقی مجموعه هماهنگ کنید. تغییر خودکار سال جاری به تنهایی مالکیت یا دامنه حق را توضیح نمی‌دهد. عبارت «تمام حقوق محفوظ است» هم جای شرایط استفاده یا مجوز محتوای مشخص را نمی‌گیرد. اگر سایت بخشی از محتوا را با مجوز متفاوت منتشر می‌کند، مسیر رسیدن به همان توضیح باید روشن باشد.
اطلاعات تماس باید قابل استفاده و به‌روز باشد
شماره تماس، ایمیل و زمان پاسخ‌گویی را با کانال واقعی هماهنگ کنید. اگر تماس فقط در ساعات مشخص پاسخ داده می‌شود، عبارت «پشتیبانی شبانه‌روزی» نگذارید. شماره و نشانی ایمیل باید قابل انتخاب و خواندن باشند. در متن RTL، رشته‌های شماره و ایمیل را با جهت مناسب نمایش دهید تا ترتیب آن‌ها در کنار علائم به هم نریزد.
درج نشانی محل فقط وقتی مفید است که برای مراجعه یا شناسایی مجموعه کاربرد دارد و انتشارش مناسب است. سایت شخصی لزوماً به نشانی خانه نیاز ندارد. برای مجموعه دارای چند شعبه، یک نشانی بی‌عنوان می‌تواند کاربر را به جای اشتباه بفرستد. نوع محل و روش مراجعه را توضیح دهید و اطلاعات منقضی را از Footer حذف یا اصلاح کنید.
کانال شبکه اجتماعی باید مقصد فعال و متعلق به همان مجموعه باشد. افزودن آیکون شبکه‌های متعدد بدون نگهداری، صفحه را معتبرتر نمی‌کند. نام قابل دسترس هر لینک باید مقصد را مشخص کند. اگر لینک در تب جدید باز می‌شود، دلیل و نشانه مناسب را در نظر بگیرید؛ کاربر باید از تغییر زمینه سرگردان نشود.
نماد را با ادعای اعتبار جایگزین نکنید
نماد اعتماد باید به وضعیت واقعی همان کسب‌وکار مربوط باشد. لوگوی کپی‌شده یا تصویر بدون مسیر بررسی، امکان تأیید ادعا را نمی‌دهد. در طراحی، محل نمایش و لینک رسمی بررسی را از اطلاعات واقعی مجموعه بگیرید. الزام مجوز یا نماد به نوع فعالیت و مقررات مربوط وابسته است؛ درباره همه سایت‌های ایرانی حکم یکسان ندهید و همه موارد را «ضروری» معرفی نکنید.
اگر وضعیت یک مجوز تغییر می‌کند، مالک نگهداری اطلاعات باید مشخص باشد. Footer معمولاً در تمام صفحه‌ها دیده می‌شود و ادعای قدیمی را گسترده تکرار می‌کند. درج نام ارائه‌دهنده پرداخت نیز به معنی تضمین کیفیت تمام خدمات فروشنده نیست. بین امکان پرداخت، هویت کسب‌وکار و تعهد کیفیت تفکیک کنید تا ظاهر یک نشان، ادعایی فراتر از واقعیت نسازد.
این مقاله دستور دریافت مجوز یا تفسیر قانون ارائه نمی‌کند. برای طراحی، نیاز اولیه جمع‌آوری اطلاعات معتبر و قابل بررسی از کسب‌وکار است. وقتی تیم درباره الزام فعالیت خاص تردید دارد، همان موضوع باید از مرجع مربوط بررسی شود. افزودن چند نشان تزئینی پاسخ این سؤال نیست و نباید جای فرایند واقعی تأیید را بگیرد.
خبرنامه را فقط با مسیر واقعی ارائه کنید
اگر خبرنامه دارید، توضیح دهید چه نوع محتوایی و با چه انتظار زمانی ارسال می‌شود. «عضو شوید» بدون معرفی فایده و نوع پیام، تصمیم روشنی نمی‌سازد. label ایمیل را پایدار نگه دارید و نتیجه ثبت را مشخص کنید. اگر تأیید ایمیل لازم است، پیام باید همان مرحله را توضیح دهد و ثبت نهایی را پیش از تأیید اعلام نکند.
شکست سرویس خبرنامه با نامعتبر بودن ایمیل فرق دارد. متن خطا باید روش ادامه درست بدهد. داده را برای چند کاربرد نامرتبط جمع نکنید و مسیر سیاست حریم خصوصی را قابل یافتن نگه دارید. فرم نمایشی که پیام موفقیت نشان می‌دهد ولی مقصد ثبت ندارد، کاربر را درباره عضویت گمراه می‌کند؛ در محصول، رفتار باید کامل باشد.
عضویت نباید مانع دسترسی به لینک‌های Footer شود. Popup اجباری در انتهای صفحه یا فرم بزرگی که همه مسیرهای ثانویه را پایین می‌برد، کاربر جویای تماس را معطل می‌کند. وزن این بخش را با هدف سایت هماهنگ کنید. مقاله طراحی CTA برای روشن کردن عمل و تفاوت گزینه اصلی و جایگزین ادامه مرتبط است.
عرض کوچک و دسترسی‌پذیری را همزمان طراحی کنید
فونت Footer را به دلیل ثانویه بودن محتوا بیش از حد کوچک یا کم‌رنگ نکنید. شرایط و راه تماس باید قابل خواندن باشند. فاصله لینک‌ها و ناحیه انتخاب، استفاده با لمس را آسان کند. خط Focus هم باید روی زمینه Footer قابل تشخیص باشد. مقاله دسترسی‌پذیری از روز اول این رفتارها را همراه ساختار و معیارهای مرتبط توضیح می‌دهد.
Accordion برای گروه‌های طولانی در موبایل می‌تواند مناسب باشد، ولی قرارداد بازشدن و Keyboard لازم دارد. برای چند لینک کوتاه، افزودن تعامل ممکن است فقط مرحله اضافی بسازد. اگر گروه‌ها بسته شروع می‌شوند، عنوان باید محتوا را به‌خوبی معرفی کند. پیاده‌سازی بدون JavaScript نیز نباید تمام مسیرها را غیرقابل دسترس کند؛ fallback را با نیاز محصول مشخص کنید.
Footer ثابت در پایین viewport با Footer پایان سند فرق دارد. ثابت کردن بخش بزرگ می‌تواند محتوا و Focus را بپوشاند. اگر فقط می‌خواهید در صفحه کوتاه به پایین برسد، layout صفحه راه دیگری دارد و به overlay دائمی نیاز ندارد. صفحات طولانی و محتوای بزرگ‌شده را نیز در قرارداد طراحی در نظر بگیرید، نه فقط صفحه معرفی کوتاه.
برای نگهداری، صاحب هر اطلاعات را مشخص کنید
فهرست لینک‌ها، راه تماس و ادعاهای اعتبار را با مسئول و دوره بازبینی ثبت کنید. اگر مسیرها از CMS می‌آیند، محدودیت عنوان و رفتار مقصد را روشن کنید. لینک حذف‌شده نباید ماه‌ها در تمام صفحه‌ها باقی بماند. عنوان مقصد نیز باید با محتوای فعلی آن هماهنگ باشد؛ تغییر نام یک بخش در navigation اصلی به Footer هم مربوط است.
در بررسی طراحی، از فرد بخواهید راه پیگیری یا شرایط را از پایان صفحه پیدا کند. محل توقف و تعبیر او از نام لینک را مشاهده کنید. UX Writing به اصلاح همین نام‌ها کمک می‌کند. Footer زمانی وظیفه‌اش را انجام می‌دهد که مسیر لازم معتبر، قابل فهم و قابل انتخاب باشد؛ تعداد ستون و آیکون معیار کافی برای آن نیست.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!