در بخش اول این فصل، ما در مورد آنچه که ممکن است به مناطق زنده نیاز داشته باشیم و نحوه ایجاد آنها با استفاده از HTML و ARIA بحث کردیم.
در این قسمت به این می پردازیم که مناطق زنده چیست نه مناسب برای و چرا، و ما در مورد راه های قوی تر برای پیاده سازی برخی از الگوهای رابط کاربری رایج که در غیر این صورت ممکن است استفاده از مناطق زنده را در نظر بگیرید، بحث خواهیم کرد. در مرحله بعد، ما به برخی از بهترین روش‌ها برای اجرای مناطق زنده در زمانی که نیاز به استفاده از آنها برای نمایش مواردی مانند پیام‌های وضعیت در برنامه‌های کاربردی وب خود دارید، نگاه می‌کنیم.
مناطق زنده به راحتی قابل سوء استفاده و برای استفاده بیش از حد. جدا از پشتیبانی ناسازگار مرورگر و صفحه‌خوان، قابلیت‌های ذاتی مناطق زنده محدود است. با طراحی، آنها را برای انواع خاصی از به روز رسانی محتوا نامناسب می کند.
مناطق زنده از متن غنی استفاده نمی کنند
مناطق زنده از متن غنی استفاده نمی کنند. این بدان معنی است که معنای عناصری مانند عنوان، لیست، پیوند، دکمه و سایر عناصر ساختاری یا تعاملی هنگامی که محتوای یک منطقه زنده اعلام می شود، منتقل نمی شود. به عنوان مثال، اگر یک منطقه زنده حاوی دکمه باشد، صفحه خوان متن دکمه را هنگامی که به منطقه زنده تزریق می شود، بدون اشاره به نقش دکمه اعلام می کند:
div aria-live="polite">
button>You'll have to guess what I represent!button>
div>این واقعیت که متن نشان دهنده برچسب یک دکمه است توسط صفحه خوان در پیام منطقه زنده گزارش نمی شود. (نمونه وام گرفته شده از مقاله اسکات اوهارا)
هنگامی که دکمه را با استفاده از جاوا اسکریپت به یک منطقه زنده اضافه می کنید، VoiceOver با سافاری چگونه دکمه ای را اعلام می کند:
یک صفحه خوان کل محتوای یک منطقه زنده را به عنوان یک رشته متن طولانی، بدون هیچ ساختاری اعلام می کند.
به همین دلیل است شما نباید تمام بخش های محتوا را در یک منطقه زنده بپیچید. در غیر این صورت، کل محتوای برگه به عنوان یک رشته متن طولانی اعلام می شود و در نتیجه تجربه کاربری ضعیفی ایجاد می شود.
زمانی که به‌روزرسانی‌های محتوا برای بخش‌های بزرگ محتوا اتفاق می‌افتد، اغلب راه بهتری برای انتقال این به‌روزرسانی‌ها به کاربران صفحه‌خوان وجود دارد.
به عنوان مثال، فرض کنید در حال ساخت یک جزء فیلتر برای یک وب سایت تجارت الکترونیک یا هر وب سایتی هستید که امکان فیلتر کردن محتوا در بخش اصلی سایت را ارائه می دهد.
در اکثر برنامه های وب، به محض اینکه کاربر یکی از فیلترهای موجود را انتخاب کند، محتوای موجود در برگه اصلی به صورت پویا فیلتر می شود. اما فقط به این دلیل که محتوای بخش در حال به روز رسانی است به این معنی نیست که بخش باید منطقه فعال باشد.
پس چگونه انجام دهید به کاربر اطلاع دهید که محتوای موجود در برگه در حال به روز رسانی است؟
ارائه دستورالعمل‌های ساده‌ای که انتظارات کاربر را از آنچه در هنگام تعامل با یک عنصر روی می‌دهد تعیین می‌کند، گاهی اوقات بیش از اندازه کافی است که کاربر را از به‌روزرسانی‌های محتوا حتی قبل از وقوع آنها مطلع کند.
برای مؤلفه فیلتر، این بدان معناست که می‌توانید دستورالعملی را در بالای گروه فیلتر قرار دهید تا به کاربر اطلاع دهید که تغییر فیلترها باعث تغییر محتوا در قسمت اصلی می‌شود. به این ترتیب، انتظارات کاربر را در مورد اتفاقی که هنگام انتخاب فیلتر می‌افتد تعیین می‌کنید، بنابراین دیگر نیازی به اعلام هیچ‌گونه اعلامیه‌ای در زمان به‌روزرسانی محتوا ندارید. کاربر می داند که می تواند به سادگی به قسمت اصلی رفته و شروع به کاوش در محتوای فیلتر شده کند.
وب سایت مرجع سریع WCAG اجرای زنده این رویکرد را ارائه می دهد.
قبل از فیلترهای محتوا در نوار کناری سمت چپ مرجع سریع، یادداشتی وجود دارد که به کاربر اطلاع می دهد که “تغییر فیلترها معیارها و تکنیک های موفقیت لیست شده را تغییر می دهد.” زمانی که این ماکت دائمی برای همه کاربران از جمله کاربران صفحه‌خوان نمایش داده می‌شود، نیازی به یک منطقه زنده نیست.
یکی دیگر از مؤلفه‌های رابط کاربری بسیار رایج که می‌تواند از یک رویکرد پیاده‌سازی مشابه بهره‌مند شود، مؤلفه جستجوی پویا است – به‌ویژه یکی از اجزای جستجوی پویا که در آن کادر جستجویی دارید که نتایج را فیلتر کرده و در حین تایپ در فیلد نمایش می‌دهد، مانند مؤلفه جستجویی که می‌توانید در وب‌سایت مجله Smashing پیدا کنید.
کاری که بسیاری از توسعه دهندگان هنگام ایجاد کامپوننتی مانند این انجام می دهند (و البته این اشتباهی است که من در اوایل کارم مرتکب شدم) این است که ظرف نتایج جستجو را به عنوان منطقه فعال تعریف می کنند (همانطور که مجله Smashing در حال حاضر انجام می دهد)، فقط به این دلیل که محتوای موجود در کانتینر به صورت پویا و همزمان با تایپ کاربر در فیلد به روز می شود. این منجر به یک تجربه کاربری بسیار پر سر و صدا می شود. به این صورت است که VoiceOver در macOS پس از تایپ یک کلمه کلیدی جستجو در آن، محتویات محفظه نتایج را اعلام می کند:
یک رویکرد ساده‌تر، قوی‌تر و کاربرپسندتر برای پیاده‌سازی این الگو، ارائه یک دستورالعمل (یعنی یک توضیح قابل دسترسی برای فیلد ورودی) است که به کاربر می‌گوید وقتی شروع به تایپ کردن در فیلد کند، چه اتفاقی می‌افتد. شرح ممکن است به عنوان “نتایج خواهد بود [ filter / display / etc. ] در حین نوشتن». به عنوان مثال، مؤلفه جستجوی وب سایت a11ysupport.io اجرای زنده این رویکرد را ارائه می دهد. توضیحات مفید جعبه جستجو به شما این امکان را می دهد که “ویژگی ها در حین تایپ فیلتر می شوند.”
ماکت باید با فیلد جستجو مرتبط باشد aria-describedby بنابراین صفحه خوان ها می توانند آن را به کاربران خود اعلام کنند.
ارائه دستورالعمل های آموزشی برای همه کاربران مفید است. اما اگر نمی‌خواهید توضیحات قابل مشاهده باشد، می‌توانید به صورت بصری آن را با استفاده از عبارت پنهان کنید visually-hidden کلاس سودمند فقط مطمئن شوید که به درستی به فیلد ورودی با استفاده از لینک مرتبط است aria-describedby.
با اطلاع دادن به کاربر صفحه‌خوان که نتایج در هنگام تایپ نمایش داده می‌شوند، دیگر نیازی به برقراری ارتباط در هنگام نمایش نتایج ندارید و کاربر می‌داند که پس از اتمام تایپ کلمه کلیدی خود در فیلد، می‌تواند به نتایج جستجو برود.
با این حساب، با این حال، شما می خواهید از یک منطقه فعال زنده برای اطلاع دادن به کاربر استفاده کنید نه نتایج یافت شد.
در حالی که نمی‌خواهیم مدام حرف افراد را در حین نوشتن قطع کنیم، اما لازم است وقتی کارها اشتباه می‌شود، صحبت را قطع کنیم
مهندس دسترس‌پذیری، اسکات اوهارا، در مقاله‌اش در نظر گرفتن نتایج جستجوی پویا و محتوا می‌گوید. به طور خاص، هنگامی که شخصی درخواستی را وارد می کند که هیچ نتیجه ای ندارد، فوراً به او اطلاع دهید. به تأخیر انداختن چنین پیامی منجر به اتلاف زمان و عدم اطمینان احتمالی در مورد “زمانی” که درخواست کسی کار نمی کند، می شود. […] افرادی که می توانند رابط کاربری را ببینند، احتمالاً بلافاصله متوجه خشک شدن محتوای پویا خواهند شد. سپس آنها می توانند بلافاصله با تصحیح پرس و جو خود این را تصحیح کنند. همین کمک ها باید به افراد دارای معلولیت ارائه شود.
در مقاله خود، اسکات بیشتر در مورد تمام ملاحظات قابلیت استفاده که باید هنگام اجرای یک جزء جستجوی پویا در نظر داشته باشید، توضیح می دهد. سپس راه حلی ارائه می دهد که چگونه می توانید آن را به روشی قوی تر و فراگیرتر پیاده سازی کنید. من به شدت توصیه می کنم مقاله را بررسی کنید و اگر می توانید مدل استقرار او را دنبال کنید.
اسکات علاوه بر استفاده از یک توضیح قابل دسترس برای کادر جستجو و یک منطقه زنده برای گزارش در صورت یافتن هیچ نتیجه ای، همچنین پیشنهاد می کند تمرکز صفحه کلید کاربر را به عنوانی که نتایج را معرفی می کند، منتقل کنید. وارد کنید کلید فشرده شده است البته، اگر جزء جستجوی شما عنوانی را ارائه نمی کند، نیازی به انجام این کار نخواهید داشت. اما این یک افزودنی خوب است که تجربه کاربری را برای کاربران صفحه کلید بهبود می بخشد، و صفحه خوان ها تعداد نتایج یافت شده را هنگامی که تمرکز روی عنوان حرکت می کند، اعلام می کنند.
در اینجا نحوه کار دمو اسکات با NVDA در فایرفاکس آمده است:
در این ویدئو، NVDA فیلد جستجو و به دنبال آن توضیحات موجود را اعلام می کند، زمانی که تمرکز من به سمت میدان حرکت می کند. توضیحات قابل دسترس نشان می دهد که نتایج به عنوان تایپ من ظاهر می شوند. ابتدا کلمه کلیدی “یک” را در کادر جستجو وارد می کنم. سپس Enter را فشار می دهم. با فشار دادن Enter، فوکوس صفحه کلید به عنوانی منتقل می شود که نتایج را ارائه می دهد و تعداد نتایج یافت شده را گزارش می کند. سپس کلید Escape را فشار می دهم. با فشار دادن Escape، تمرکز من به قسمت جستجو برمی گردد. وقتی یک کلمه کلیدی با بیش از پنج کاراکتر تایپ می کنم، مثال ساختگی می گوید هیچ نتیجه ای یافت نشد. از آنجایی که اسکات از یک منطقه زنده برای برقراری ارتباط در صورت یافتن نتیجه استفاده می کند، NVDA اعلام می کند “نتیجه ای یافت نشد!”.
در اینجا یک جاسازی شده از نسخه ی نمایشی اسکات است:
به قلم نگاه کن
نسخه ی نمایشی سریع نمایش/گزارش نتایج پویا توسط اسکات (@scottohara) در CodePen.
مناطق زنده برای اعلان های دارای عناصر تعاملی مناسب نیستند
مناطق فعال نباید برای پیام‌ها یا اعلان‌هایی که حاوی عناصر تعاملی هستند استفاده شوند، به‌ویژه اگر کاربر ممکن است نیاز به انجام آن اعلان‌ها داشته باشد.
همانطور که قبلا ذکر شد، هنگامی که یک صفحه خوان محتوای یک منطقه زنده را اعلام می کند، محتوای متن خام در منطقه را بدون ساختار یا معنایی اعلام می کند. این بدان معنی است که معنای هر عنصر تعاملی منتقل نخواهد شد.
علاوه بر این، هنگامی که یک به روز رسانی در یک منطقه فعال رخ می دهد، صفحه خوان ها فقط محتوای منطقه فعال را اعلام می کنند، اما تمرکز کاربر به منطقه منتقل نمی شود. و هیچ مکانیزمی وجود ندارد که به کاربر اجازه دهد به راحتی به یک منطقه زنده حرکت کند تا با هر محتوایی که ممکن است در آن باشد تعامل داشته باشد.
بنابراین، مگر اینکه مسیر روشنی برای کاربران صفحه‌خوان و صفحه‌کلید فراهم کنید تا به اعلانی که حاوی عناصر تعاملی است (مثلاً یک میان‌بر صفحه‌کلید کاملاً مستند) برسند، بسته به موقعیت منطقه فعال در DOM، دسترسی کاربر به محتوای تعاملی در اعلان دشوار – اگر غیرممکن نباشد – می‌تواند، به خصوص اگر اعلان پس از مدت کوتاهی منتظر بماند.
به همین دلیل است که پیام های تست حاوی عناصر تعاملی مشکل ساز هستند. متأسفانه، پیام‌های تست حاوی عناصر تعاملی بسیار رایج هستند. شما می توانید نمونه هایی از این موارد را در سیستم طراحی متریال گوگل مشاهده کنید.
اما این پیام‌ها برای کاربران صفحه‌خوان و همچنین سایر کاربران فناوری کمکی، مانند کاربرانی که در حال مرور وب با استفاده از ذره‌بین هستند، و همچنین کاربران صفحه‌کلید، مشکلات قابلیت استفاده و دسترسی دارند.
آدریان روزلی مرتبط‌ترین خطاهای WCAG را که پیام‌های تست تمایل به شکستن آنها دارند، مستند و فهرست کرده است، به‌ویژه اگر حاوی عناصر تعاملی باشند. من به شدت توصیه می‌کنم اینجا توقف کنید و چند دقیقه وقت بگذارید و مقاله آدریان را بخوانید، به خصوص اگر در برنامه‌های خود از نان تست استفاده می‌کنید.
اگر اعلان حاوی یک عنصر تعاملی است، باید مطمئن شوید که کاربر می تواند به راحتی به آن پیمایش کند. و بهترین راه برای انجام این کار این است که تمرکز کاربر را روی آن قرار دهید.
را alert و status نقش‌های منطقه‌ای زنده برای نمایش پیام‌های کوتاهی در نظر گرفته شده‌اند که نیازی به تغییر تمرکز کاربر ندارند (یعنی حاوی کودکان تعاملی نیستند).
نویسندگان باید یک عنصر با نقش ارائه کنند
statusدر نتیجه تغییر وضعیت فوکوس دریافت نمی کند.[…]
نه نویسندگان و نه عوامل کاربر نیازی به تنظیم یا مدیریت تمرکز روی یک هشدار برای پردازش آن ندارند. از آنجایی که برای دریافت فوکوس نیازی به هشدارها نیست، نویسندگان نباید از کاربران بخواهند که هشدار را ببندند. اگر نویسنده ای بخواهد هنگام ارسال پیام، فوکوس به آن منتقل شود، نویسنده باید از آن استفاده کند
alertdialogبه جای هشدار– مشخصات ARIA
اگر اعلان حاوی یک عنصر تعاملی باشد، نباید یک منطقه فعال باشد. و لازم نیست نان تست نیز باشد. در عوض، شما باید تمرکز کاربر را به سمت آن ببرید و آن را پایدار کنید.
برای اعلان‌های هشدار تعاملی، به جای استفاده از پیام نان تست، از کادر گفتگوی هشدار استفاده کنید. آریا alertdialog نقش برای نمایش یک نوع گفتگو که حاوی یک پیام هشدار است استفاده می شود.
همانطور که از نامش پیداست، alertdialog ترکیبی است از dialog و alert نقش ها این بدان معنی است که انتظار دارد تعاملات صفحه کلید مشابهی مانند دیالوگ های مدال را نیز داشته باشد. پیاده‌سازی گفتگوی هشدار فراتر از محدوده این فصل است، اما می‌توانید الزامات تعامل معنایی و صفحه‌کلید را برای اجرای گفتگوهای هشدار در دسترس مستند شده در وب‌سایت APG بیابید.
برای اعلان‌های وضعیتی که حاوی عناصر تعاملی هستند، می‌توانید به جای آن از یک گفتگوی مودال یا غیرمدال استفاده کنید و فوکوس را در آن دیالوگ‌ها هنگامی که ظاهر می‌شوند کنترل کنید، همانطور که در صفحه مثال گفتگوی مدال APG مستند شده است.
این را در نظر داشته باشید حرکت دادن فوکوس باید به عنوان پاسخی فوری به اقدام کاربر انجام شود. اگر چیزی به صورت ناهمزمان یا پس از تأخیر رخ دهد، مثلاً نان تستی ظاهر شود که کاربر آن را نخوانده است، نباید تمرکز او را روی آن قرار دهید، در غیر این صورت تجربه کاربر را مختل می کند. تصمیم بگیرید که آیا تمرکز را بر اساس انتظارات کاربران تغییر دهید یا خیر.
مناطق زنده جایگزینی برای ویژگی های ایالت ARIA نیستند
هنگامی که یک ویژگی ARIA برای انجام این کار وجود دارد، از مناطق زنده برای انتقال تغییرات حالت استفاده نکنید.
برای مثال، اگر دکمه ای قابلیت مشاهده برخی از محتواها را در یک صفحه تغییر می دهد (مانند یک “کشویی”)، از آن استفاده کنید. aria-expanded ویژگی برای انتقال وضعیت محتوا (خواه گسترش یافته یا کوچک شده) به کاربر. برای گزارش اینکه محتوا گسترش یافته یا جمع شده است، به یک منطقه فعال نیاز ندارید.
button aria-expanded="[ true | false ]">Terms of usebutton>به همین ترتیب، برای مثال، اگر با استفاده از دکمه جابجایی، تغییر دهنده تم تیره می‌سازید، از آن استفاده کنید aria-pressed ویژگی برای اینکه به خوانندگان صفحه نمایش بگوید که تم تیره در حال حاضر “روشن” یا “خاموش” است.
button aria-pressed="[ true | false ]">Dark themebutton>چه زمانی aria-pressed به الف اعلام می شود ، نگاشت نقش ARIA دکمه در اکثر APIهای دسترسی تغییر می کند و به عنوان نمایان می شود toggle button (نه فقط یک دکمه ساده) که نشان دهنده این است عملکرد خاصی را روشن و خاموش می کند. زمانی که ارزش aria-pressed درست است، به خوانندگان صفحه می گوید که عملکرد در حال حاضر “روشن” است. همراه با نام قابل دسترسی دکمه، ویژگی state به کاربر اجازه می دهد تا بداند وقتی دکمه را فعال می کند چه اتفاقی می افتد. برای اعلام اینکه تم تیره روی صفحه اعمال شده است، نیازی به یک منطقه فعال ندارید.
در اینجا یک نسخه نمایشی زنده از یک تغییر موضوع ساده با استفاده از دو دکمه جابه‌جایی وجود دارد که می‌توانید با یک صفحه‌خوان امتحان کنید:
به قلم نگاه کن
بدون عنوان سارا سویدان (@SaraSoueidan)
در CodePen.
وقتی دکمه جابجایی فعال است، صفحه‌خوان وضعیت دکمه را (چه فشار داده شده یا نه) هنگام گزارش نقش دکمه و نام موجود گزارش می‌دهد. هنگامی که موضوعی “روشن” یا “خاموش” است، وضعیت دکمه برای برقراری ارتباط کافی است. می توانید آن را برای خودتان در نسخه اشکال زدایی این تغییر کننده تم امتحان کنید.
تغییرات مالکیت ایالتی ممکن است مانند مناطق فعال به کاربر اعلام نشود، اما نه هر تغییری نیاز دارد اعلام شود. استفاده از معنایی مناسب، ارائه نام‌های قابل دسترسی معنادار، و استفاده از ویژگی‌های حالت مناسب گاهی برای کاربران صفحه‌خوان کافی است تا بفهمند هنگام تعامل با یک عنصر چه اتفاقی می‌افتد.
بنابراین قبل از استفاده از یک منطقه زنده، از خود بپرسید که آیا ویژگی حالتی وجود دارد که آنچه شما نیاز دارید را انجام دهد. و اگر وجود دارد، از آن ویژگی استفاده کنید.
بهترین روش‌ها برای پیاده‌سازی پیام‌های وضعیت (قوی‌تر) با مناطق فعال
مناطق زنده برای پیاده‌سازی پیام‌های حالت کوتاه و غیرتعاملی که تغییری در زمینه ایجاد نمی‌کنند (مانند حرکت فوکوس) و نمی‌توانند به هیچ طریق دیگری با کاربران صفحه‌خوان ارتباط برقرار کنند، مناسب‌تر هستند. مناطق زنده در حال حاضر راه اصلی برای برآورده کردن معیار موفقیت هستند 4.1.3 پیام های وضعیت (سطح AA).
اگر پیام‌های وضعیت را در برنامه(های) وب خود پیاده‌سازی می‌کنید، بهترین روش‌ها وجود دارد که اکثر متخصصان دسترسی با آن موافق هستند که می‌تواند به شما در دستیابی به حداکثر سازگاری بین جفت مرورگر و صفحه‌خوان کمک کند:
اطمینان حاصل کنید که کانتینر ناحیه فعال در DOM در اولین فرصت ممکن است
عنصری که به عنوان منطقه فعال تعریف می شود زمانی که مرورگر محتوا را تجزیه می کند و درخت دسترسی صفحه را ایجاد می کند، باید در صفحه وجود داشته باشد. این تضمین می کند که عنصر در هنگام رخ دادن تغییرات، نظارت می شود و این تغییرات به صفحه خوان و کاربر اطلاع داده می شود.
بنابراین هنگام ایجاد یک منطقه زنده، آن را در اسرع وقت در DOM قرار دهید (در حالت ایده آل زمانی که صفحه بارگیری می شود)، قبل از اینکه هر گونه به روز رسانی را برای آن منتشر کنید. اگر یک منطقه زنده را در DOM وارد کنید یا یک کانتینر را به یک منطقه فعال تبدیل کنید زمانی که شما نیاز دارید، احتمال زیادی وجود دارد که کار نکند.
اگر منطقه زنده قابل مشاهده نیست، یک تکنیک پنهان سازی مناسب را انتخاب کنید
اگر پیام وضعیت برای همه کاربران قابل مشاهده نیست، آن را به صورت بصری با استفاده از مخفی کنید visually-hidden کلاس سودمند
منطقه زنده را با استفاده پنهان نکنید display: none; یا aria-hidden="true"یا هر تکنیک پنهان سازی دیگری که آن را از درخت دسترسی حذف می کند. مناطق زنده پنهان اعلام نشده است.
تعداد مناطق زنده در یک صفحه را محدود کنید
در حالی که هیچ قانونی درباره تعداد مناطق زنده که می توانید در یک صفحه داشته باشید وجود ندارد، باید تعداد مناطق زنده ایجاد شده را محدود کنید.
همانطور که مهندس دسترسی، اسکات اوهارا در مقاله خود آیا ما زندگی می کنیم؟
لطفاً توجه داشته باشید که تنها چیزی که بدتر از تزریق مناطق زنده به یک صفحه وب و سپس عدم اطلاع‌رسانی است، صفحه‌ای است که تعداد زیادی منطقه زنده در آن به کاربران فناوری کمکی می‌گوید.
این یک تمرین خوب است که فقط دو منطقه فعال در صفحه داشته باشید: یک منطقه قاطع و یک منطقه مودب که در بارگذاری صفحه در صفحه درج می شوند. سپس به‌روزرسانی‌ها را به این دو منطقه تزریق می‌کنید و با استفاده از جاوا اسکریپت صف پیام را در آنها مدیریت می‌کنید.
اگر چندین منطقه فعال در یک صفحه دارید، ممکن است با یکدیگر تداخل داشته باشند و برخی از پیام ها اصلاً اعلام نشوند.
با توجه به مشخصات:
مواردی که فوری هستند بلافاصله ارائه می شوند و به دنبال آن موارد مودبانه ارائه می شود. عامل‌های کاربر یا فناوری‌های کمکی ممکن است انتخاب کنند که تغییرات صف زمانی که تغییر قاطعانه رخ می‌دهد پاک کنند. (به عنوان مثال، تغییرات در یک منطقه ادعایی می تواند تمام تغییرات در صف را حذف کند)
این به این معنی است که سطح ادب نشان داده شده توسط aria-live ویژگی به عنوان مکانیزم سفارش به روز رسانی کار می کند. در مواردی که چندین منطقه زنده در یک صفحه دارید، polite به روز رسانی ها اولویت کمتری دارند. و assertive به‌روزرسانی‌ها اولویت بیشتری دارند و حتی می‌توانند به‌طور بالقوه دیگر به‌روزرسانی‌هایی را که در صف اعلام هستند پاک یا لغو کنند. این باعث می شود برخی از پیام ها گم شوند یا فقط به طور جزئی اعلام شوند.
طراحی دقیق توالی رویدادها در چندین منطقه فعال صفحه بهترین رویکرد شما برای دستیابی به حداکثر سازگاری خواهد بود.
پیام خود را با یک حرکت در منطقه زنده بنویسید و درج کنید
شما باید محتوای پیام اعلان را از قبل بنویسید و آن را به یکباره در منطقه قرار دهید. برای ایجاد یک پیام، چندین درج DOM را انجام ندهید، در غیر این صورت صفحه خوان ممکن است چندین مورد را انجام دهد به طور جداگانه پیام هایی در مورد پیام ها، که آن چیزی نیست که شما می خواهید.
مطالب را کوتاه و مختصر نگه دارید و از محتوای غنی خودداری کنید
محتوای پیام را محکم نگه دارید. و آن را تا حد امکان کوتاه نگه دارید. هیچ محدودیتی برای کاراکتر در پیام اعلان وجود ندارد، اما به یاد داشته باشید که پیام‌های زنده منطقه‌ای گذرا هستند و قابل پخش نیستند. بنابراین مطمئن شوید که پیام در هنگام اولین بار اعلام آسان است. کوتاه نگه داشتن آن همچنین تضمین می کند که اختلال کمتری در جریان کاربر ایجاد می کند.
از محتوای غنی، عناصر تعاملی و عناصر غیر متنی خودداری کنید تصاویر مشابه، زیرا برای کاربران صفحه‌خوان ارائه نمی‌شوند.
منطقه زنده را خالی کنید و بین به روز رسانی ها کمی صبر کنید
اگر پیام وضعیت برای همه قابل مشاهده نیست یا پس از یک انتظار کوتاه حذف می شود، برای حذف متن اعلان از منطقه زنده، یک بازه زمانی تعیین کنید (مثلاً 350-500 میلی ثانیه). شما نیازی به خالی کردن یک منطقه زنده پس از اعلام محتوای آن ندارید، زیرا زمانی که محتوا به طور پیش فرض اضافه می شود، پیام ها فعال می شوند، اما خالی کردن منطقه زنده بین به روز رسانی ها تضمین می کند که پیام های عجیب و غریب یا تکراری دریافت نمی کنید.
setTimeout(() => {
}, 350);خالی کردن منطقه زنده زمانی که دیگر قابل مشاهده نیست همچنین تضمین می کند که کاربران صفحه خوان نمی توانند در زمانی که در نظر گرفته نشده است به آن پیمایش کنند.
بنابراین مطمئن شوید که مناطق زنده بین به‌روزرسانی‌ها پاک شده‌اند و قبل از ارسال به‌روزرسانی‌های جدید، کمی صبر کنید. و هنگامی که یک به روز رسانی جدید را وارد می کنید، پیام جدید را یکباره وارد کنید.
اشکال زدایی مناطق زنده
اگر از مناطق زنده استفاده می‌کنید، می‌خواهید آنها را زمانی که آن‌طور که انتظار می‌رفت کار نمی‌کنند، حذف کنید، مانند زمانی که صفحه‌خوان چیزی غیرمنتظره را گزارش می‌کند. بخشی از اشکال زدایی مناطق زنده این است که ببینیم چه چیزی و چه زمانی وارد آنها می شود.
برای اشکال زدایی مناطق زنده در یک صفحه، می توانید از پسوند مرورگر NerdeRegion استفاده کنید.
NerdeRegion یک افزونه ابزار توسعه دهنده برای اشکال زدایی مناطق زنده در یک صفحه وب است. وقتی فعال باشد، تمام مناطق فعال ARIA را فهرست می‌کند و رکوردی از تمام جهش‌هایی که در منطقه رخ داده است را حفظ می‌کند.
شما می توانید از NerdeRegion برای موارد زیر استفاده کنید:
- بررسی کنید که یک منطقه فعال به درستی به روز می شود،
- بررسی کنید که محاسبه نام‌های موجود (بتا) به درستی انجام شود،
- بررسی کنید که منطقه زنده به درستی مورد استفاده مجدد قرار گرفته است.
برای استفاده از برنامه افزودنی، ابزارهای توسعه دهنده مرورگر خود را باز کرده و تب NerdeRegion را باز کنید. در آنجا می‌توانید پیام‌ها را با مهر زمانی و عنصر خروجی که از آن منشا گرفته‌اند، ردیابی کنید.
در این ویدیو من یک منطقه قاطع زنده در صفحه دارم. وقتی به پنل NerdeRegion در Edge DevTools میروم، تعداد مناطق زنده در صفحه در نوار کناری سمت چپ و همچنین نوع منطقه زنده (مطمئنانه یا مؤدبانه) در ناحیه اصلی پانل را فهرست می‌کند. سپس وقتی دکمهای را که منطقه زنده را با یک پیام جدید پر می‌کند، فعال می‌کنم، NerdeRegion زمان تغییر منطقه زنده را به همراه یک مهر زمانی از تغییر آن نشان می‌دهد.
از آنجایی که ممکن است خطاها و ناهماهنگی‌هایی با نحوه اعلام مناطق زنده ARIA با صفحه‌خوان‌های مختلف وجود داشته باشد، باید به طور مداوم مناطق زنده خود را بررسی کنید تا مطمئن شوید که طبق برنامه به کار خود ادامه می‌دهند.
همانطور که قبلا ذکر شد، باید سعی کنید تعداد مناطق زنده ای را که استفاده می کنید به دو یا کمتر محدود کنید. اما اگر قطعاً باید بیشتر از آن استفاده کنید، NerdeRegion می تواند به شما کمک کند تا بفهمید که آیا مشکل به طور بالقوه ناشی از کد شما است یا ترکیبی از دستگاه ها.
در صورت امکان از مناطق زنده خودداری کنید
من می دانم که این توصیه ای نیست که در پایان یک فصل کامل در مورد مناطق زندگی انتظار دارید. اما به من گوش کن
مناطق زنده ناسازگار و غیرقابل پیش بینی هستند. در اجرای آنها اشتباه کردن آسان است. کارهای دستی زیادی برای کارکرد صحیح آنها وجود دارد.
علاوه بر این، طراحی مناطق زندگی می‌خواهد حداکثر انعطاف‌پذیری را به صفحه‌خوان‌ها بدهد تا تجربه‌ای را که برای کاربرانشان بهترین است، اجرا کنند.
این بدان معنی است که ARIA فقط دارایی های منطقه ای زندگی می کنند پیشنهادات قوی در مورد اینکه چگونه می‌خواهید مناطق زنده اعلام شوند، اما ارزش این ویژگی‌ها (و به طور گسترده: رفتار مناطق زنده) می تواند توسط مرورگرها، فناوری های کمکی یا کاربر لغو شود. این، همراه با باگ‌های مداوم و شکاف‌های پیاده‌سازی، به این معنی است که نمی‌توانید تضمین کنید که یک منطقه زنده همیشه به همان صورتی که طراحی کرده‌اید کار می‌کند. این یکی از دلایلی است که شما باید سعی کنید تا حد امکان کمتر به مناطق زنده تکیه کنید و در صورت امکان از رویکردهای جایگزین و قوی تر استفاده کنید.
به یاد داشته باشید که پخش زنده منطقه ای گذرا است. اگر کاربر پیامی را از دست بدهد، آن را از دست می دهد. بسته به اهمیت و فوریت پیام، این می تواند به راحتی قابلیت استفاده از برنامه وب شما را کاهش دهد و منجر به یک تجربه کاربر خسته کننده شود.
بنابراین اگر می‌توانید به‌روزرسانی‌ها را با استفاده از روش‌های دیگر و قوی‌تر مانند حرکت تمرکز یا ارائه راهنما به اطلاع کاربران خود برسانید، باید این کار را در نظر بگیرید.
لازم نیست هر چیزی که در پس‌زمینه به‌روزرسانی می‌شود، یک منطقه فعال باشد. برای مثال، رابط‌های چت معمولاً کاندیدای عالی برای مناطق زنده هستند و با استفاده از آن پیاده‌سازی می‌شوند log نقش ARIA، اما همیشه اینطور نیست نیاز دارند به عنوان مناطق زنده اجرا شود. مگر اینکه چت رابط اصلی صفحه باشد، احتمالاً همینطور است شما مجبور نیستید حتی اگر یک منطقه زنده باشد.
برای کارهای روزمره خود، کمتر از آنچه فکر می کنید به مناطق زنده نیاز خواهید داشت، حتی اگر در حال ساخت برنامه های وب پویا مانند SPA هستید.
به عنوان مثال، فرض کنید در حال ساخت ناوبری برای یک SPA هستید. در اکثر پیمایش‌های SPA، فعال کردن یک پیوند، یک صفحه جدید را بدون بازخوانی صفحه بارگیری می‌کند.
به طور معمول، هنگامی که یک کاربر پیوندی را فعال می کند و پیوند او را به صفحه جدیدی می برد، صفحه خوان ها ابتدا عنوان صفحه جدید را اعلام می کنند و به کاربر اطلاع می دهند که در کجا فرود آمده است. اما در اسپا این اتفاق نمی افتد. بنابراین کاری که بسیاری از توسعه دهندگان انجام خواهند داد این است که از مناطق زنده برای اعلام زمان آپلود محتوای جدید استفاده خواهند کرد. اما نه تنها این کار غیر ضروری است، بلکه حتی می توانید به کاربر اطلاع دهید که محتوای جدید به روشی کارآمد بارگذاری شده است.
به جای تکیه بر یک منطقه زنده برای اعلام تغییر صفحه، می توانید فوکوس صفحه کلید را به صفحه اصلی ارسال کنید of the page which, as we mentioned in the heading structure chapter, should describe the primary topic of the contents of the page and ideally be identical to the page’s
با انتقال تمرکز کاربر به عنوان، صفحه‌خوان محتوای عنوان را به کاربر اعلام می‌کند و به آن زمینه مشابه صفحه می‌دهد.
انتقال تمرکز به عنوان صفحه اصلی برای کاربران صفحه کلید نیز مفید است. به طور معمول، زمانی که صفحه به‌روزرسانی می‌شود و کاربر شروع به پیمایش در صفحه می‌کند، پیوند پرش باید اولین عنصری باشد که روی آن تمرکز می‌کند و می‌تواند از آن پیوند برای پرش مستقیم به محتوای اصلی صفحه استفاده کند. اما اگر صفحه به‌روزرسانی نشود، ممکن است مجبور شوند قبل از اینکه به محتوای جدید برسند، عناصر زیادی را مرور کنند. بنابراین انتقال تمرکز آنها به عنوان اصلی، ناوبری صفحه آنها را کارآمدتر می کند.
مناطق زنده موارد استفاده (محدود) خود را دارند – به ویژه برای پیام های وضعیت همانطور که در WCAG توضیح داده شده است. اما همانطور که مهندس دسترسی، اسکات اوهارا می گوید:
اگر بتوانید رابطی ایجاد کنید که بتواند تعداد مناطق زنده مورد نیاز را محدود کند – هیچکدام کامل نیستند – آن وقت چیز خوبی خواهد بود.
هدف اصلی شما بهعنوان یک طراح یا توسعهدهنده، اطلاع‌رسانی به کاربران در مورد به‌روزرسانی‌های محتوای جدید در صورت وقوع است. اما برای اکثر طراحیهای رابط کاربری، راههای دیگری نیز وجود دارد که می‌توانید به این هدف دست یابید، و این راهها اغلب قوی‌تر و قابل اعتمادتر از مناطق زنده هستند و در مجموع تجربه بهتری را برای کاربران شما به ارمغان میآورند.
نمونه دیگری از این مورد توانست از مناطق زنده استفاده کنید، اما این را می توان اعمال کرد و به روشی پایدارتر یک سبد خرید در یک وب سایت تجارت الکترونیک است. یک الگوی رایج در بسیاری از وبسایتها امروزه این است که وقتی یک کالای جدید به سبد خرید اضافه می‌شود، یک پوشش کامل از سبد خرید نمایش داده می‌شود.
به جای استفاده از مناطق زنده برای اعلام اینکه یک آیتم جدید به سبد خرید اضافه شده است، می توانید از این الگو استفاده کنید و هنگام نمایش فوکوس صفحه کلید کاربر را به سبد خرید منتقل کنید. این رویکرد چندین مزیت دارد، یکی از آنها این است که کاربران صفحه‌کلید را آسانتر می‌کند تا به سبد خرید، دیدن و/یا ویرایش آنچه در آن است، و ادامه بررسی اینکه آیا این همان کاری است که میخواهند انجام دهند، آسانتر می‌شود.
توجه داشته باشید که در این مورد باید سبد خرید را به عنوان یک دیالوگ مودال در نظر بگیرید و فوکوس را بر اساس آن مدیریت کنید، به خصوص زمانی که محتوای صفحه پس از نمایش سبد خرید کم رنگ می شود. می توانید الزامات کنترل فوکوس صفحه کلید برای گفتگوهای مدال را در صفحه گفتگوی Modal در وب سایت APG بیابید.
به عنوان یک قانون کلی: اگر می توانید بدون استفاده از مناطق زنده به همان نتیجه برسید، احتمالاً این کار را انجام دهید. هرچه کمتر از ARIA استفاده کنید، بهتر است. به یاد داشته باشید: هیچ ARIA بهتر از ARIA بد نیست.
اگر از مناطق زنده در برنامه های وب خود استفاده می کنید، مطمئن شوید که این کار را انجام می دهید به طور کامل تست کنید در همه مرورگرها و جفت های صفحه خوان. و فراموش نکنید که با نمایشگرهای بریل نیز تست کنید. و تست های قابلیت استفاده را با کاربران صفحه خوان اجرا کنید. آزمایش قابلیت استفاده نه تنها به شما ایده می‌دهد که کاربران شما از برنامه چه انتظاراتی دارند و چه چیزی را ندارند، بلکه به شما کمک می‌کند تا روش‌های مختلف استفاده کاربران صفحه‌خوان از برنامه شما و اینکه چگونه بر پیامهایی که می‌خواهید با مناطق زنده ارسال می‌کنید، تأثیر بگذارد.
منابع، منابع و خواندن توصیه شده
