ویژگی «نقطه شروع ناوبری فوکوس متوالی» مشخص می‌کند که وقتی هیچ ناحیه متمرکزی وجود ندارد، ما شروع به جستجوی عناصر قابل فوکوس برای ناوبری فوکوس متوالی ([Tab] یا [Shift-Tab]) می‌کنیم. این به ویژه برای ویژگی‌های دسترسی مانند «پرش از پیوندها» و مدیریت تمرکز در سند مفید است.
HTML پشتیبانی داخلی زیادی را برای مقابله با تعاملات صفحه کلید در اختیار ما قرار می دهد، به این معنی که نوشتن صفحاتی که می توان از طریق صفحه کلید استفاده کرد بسیار آسان است - چه نقص حرکتی ما را از استفاده از ماوس باز دارد، یا ما بسیار کارآمد هستیم. برداشتن دست‌هایمان از صفحه‌کلید، میلی‌ثانیه‌های گرانبها را هدر می‌دهد.
کنترل صفحه کلید حول محور فوکوس می‌چرخد، که تعیین می‌کند رویدادهای صفحه‌کلید کجا در صفحه خواهند رفت. چند موقعیت وجود دارد که در آن، تا به حال، ما نیاز به انجام کارهای اضافی داشته ایم تا کارها برای کاربران صفحه کلید به خوبی انجام شود. متد focus() به ما اجازه می دهد تا با انتخاب انتخابی عنصری برای تمرکز در پاسخ به اقدام کاربر، تمرکز را مدیریت کنیم. با این حال، این بهترین روش از مشکلات زیادی رنج می‌برد و برای ارائه یک تجربه پایه به برخی از هکرهای جاوا اسکریپت نیاز دارد.
در حالی که این تکنیک به این زودی ها کاملاً از بین نمی رود، در Chrome 50 به لطف نقطه شروع ناوبری فوکوس متوالی در موارد کمتری لازم است. با این تغییر، صفحاتی که به خوبی تالیف شده اند به طور خودکار بدون نیاز به مدیریت فوکوس دستی اضافی در دسترس تر می شوند. بیایید به یک مثال نگاه کنیم.
پیوند در یک صفحه
سایت‌های سنگین متنی اغلب در یک صفحه به هم متصل می‌شوند تا به کاربران کمک کنند سریع به بخش‌های مهم بپرند.
<!-- Table of Contents -->
<a href="#recipes">Recipes</a>
<a href="#ingredients">Ingredients</a>
<!-- Recipes Section -->
<h2 id="recipes">Recipes</h1>
<h3>Vegemite Cheesecake</h3>
<p>
Vegemite cheesecake is delicious. We promise.
<a href="cheesecake.html">Read More</a>
</p>
اگر من یک کاربر صفحه کلید (و پرخور غذاهای استرالیایی) بودم، سری اقدامات بعدی من چیزی شبیه به این بود:
- دوبار
Tabفشار دهید تا پیوند Recipes را متمرکز کنید -
Enterفشار دهید تا به بخش Recipes بروید - دوباره
Tabفشار دهید تا پیوند Read More را متمرکز کنید
بیایید آن را در عمل با استفاده از Chrome 49 ببینیم.
اوه خوب که کاملا طبق برنامه پیش نرفت، اینطور نیست؟
به جای تمرکز روی پیوند Read More، فشار دادن Tab برای آخرین بار، فوکوس را به مورد بعدی در فهرست محتویات منتقل کرد. این به این دلیل است که توسعه دهنده tabindex="-1" روی هدر تنظیم نکرده است تا آن را قابل فوکوس کند. بنابراین با کلیک بر روی #recipes که انکر نام دارند، تمرکز حرکت نمی‌کند. این یک اشتباه ظریف است و اگر کاربر ماوس هستید، مشکل بزرگی نیست. اما اگر کاربر صفحه کلید یا سوئیچ دستگاه باشید، به طور بالقوه مشکل بسیار بزرگی است. میزان پیوند در یک صفحه معمولی ویکی پدیا را در نظر بگیرید؟ ناامید کننده خواهد بود که مجبور باشید دائماً از طریق همه آن لنگرها به جلو و عقب ضربه بزنید!
بیایید همین تجربه را در حال حاضر با استفاده از Chrome 50 ببینیم.
وای این دقیقاً همان چیزی است که ما می‌خواستیم، و از همه بهتر، ما مجبور نبودیم کد خود را تغییر دهیم. مرورگر به تازگی متوجه شد که بر اساس جایی که ما در سند هستیم، تمرکز باید کجا باشد.
چگونه کار می کند؟
قبل از اجرای نقطه شروع فوکوس، فوکوس همیشه از عنصر متمرکز قبلی یا بالای صفحه حرکت می‌کند. این بدان معناست که انتخاب چیزی که بعداً متمرکز می‌شود می‌تواند شامل انتقال تمرکز به چیزی باشد که واقعاً نباید قابل تمرکز باشد، مانند یک عنصر ظرف یا یک عنوان. این باعث انواع عجیب‌وغریب می‌شود، از جمله نشان دادن حلقه فوکوس در صورت کلیک بی‌حرکت روی چنین عنصری.
نقطه شروع فوکوس، همانطور که از نام آن پیداست، مکانیزمی را ارائه می‌کند که نشان می‌دهد وقتی Tab یا Shift-Tab فشار می‌دهیم، جستجوی عنصر قابل فوکوس بعدی را از کجا شروع کنیم.
می‌توان آن را به روش‌های مختلفی تنظیم کرد: اگر چیزی فوکوس داشته باشد، نقطه شروع ناوبری فوکوس نیز مانند قبل است. همچنین، درست مانند قبل، اگر هیچ چیز دیگری نقطه شروع ناوبری فوکوس را تنظیم نکرده باشد، آن document فعلی یا، در صورت موجود بودن و پشتیبانی، dialog فعال فعلی خواهد بود. اگر مانند مثال بالا به یک قطعه صفحه بروید، اکنون نقطه شروع فوکوس تعیین می شود. همچنین، اگر روی هر عنصری در صفحه کلیک کنیم، صرف نظر از اینکه آیا آن قابل فوکوس است یا خیر، اکنون نقطه شروع ناوبری فوکوس را تنظیم می کند. در نهایت، اگر عنصری که نقطه شروع فوکوس بود از DOM حذف شود، والد آن به نقطه شروع فوکوس تبدیل می شود. بدون تمرکز بیشتر ضربت زدن یک خال!
موارد استفاده دیگر
جدای از مثال بالا، سناریوهای زیادی وجود دارد که این ویژگی می تواند مفید واقع شود.
پنهان کردن عناصر
ممکن است زمان‌هایی وجود داشته باشد که کاربر روی موردی متمرکز شود که باید روی آن تنظیم شود visibility: hidden یا display: none . نمونه ای از این موارد می تواند موارد قابل کلیک در یک چرخ فلک باشد. در نسخه‌های قبلی کروم، پنهان کردن آیتم متمرکز فعلی به این روش، فوکوس را به نقطه شروع پیش‌فرض بازمی‌گرداند و چرخ فلک فوق‌الذکر را به تله‌ای بد برای کاربران دارای نقص موتور تبدیل می‌کند. با نقطه شروع فوکوس متوالی، این دیگر موردی نیست. اگر عنصری از طریق یکی از روش های بالا پنهان شود، با فشار دادن کلید Tab به سادگی به آیتم قابل فوکوس بعدی منتقل می شود.
رد شدن از پیوندها
پیوندهای پرش لنگرهای نامرئی هستند که فقط از طریق صفحه کلید قابل دسترسی هستند. آنها به کاربران اجازه می دهند عناصر ناوبری را "پرش" کنند تا مستقیماً به محتوای یک صفحه بپرند و می توانند برای کاربران صفحه کلید و سوئیچ دستگاه بسیار مفید باشند. همانطور که در سایت WebAIM توضیح داده شده است.
بسیاری از وب‌سایت‌های محبوب، پیوندهای پرش را پیاده‌سازی می‌کنند، اگرچه ممکن است هرگز به آنها توجه نکرده باشید.
از آنجایی که لینک‌های پرش به عنوان لنگر نامیده می‌شوند، به همان شکلی که نمونه فهرست اصلی ما کار می‌کنند، کار می‌کنند.
هشدارها و پشتیبانی
نقطه شروع ناوبری فوکوس متوالی در حال حاضر فقط در Chrome 50، Firefox و Opera پشتیبانی می شود. تا زمانی که در همه مرورگرها پشتیبانی نشود، همچنان باید tabindex="-1" (و طرح کلی فوکوس را حذف کنید) به اهداف لنگر نام‌گذاری شده خود اضافه کنید.
نسخه ی نمایشی
نقطه شروع ناوبری فوکوس متوالی افزودنی عالی به مجموعه اولیه دسترسی مرورگر است. کار کردن با آن آسان است و در واقع به ما امکان می دهد کد را از برنامه خود حذف کنیم و در عین حال تجربه را برای کاربران خود بهبود بخشیم. برد مضاعف! برای بررسی عمیق تر این ویژگی به نسخه ی نمایشی نگاه کنید.