عندما لا تكون CSS كافية: متطلبات JavaScript للمكونات التي يمكن الوصول إليها

بصفتي مؤلف ModernCSS.dev ، فأنا من أشد المؤيدين لحلول CSS. وأنا أحب رؤية الطرق الذكية التي يستخدمها الأشخاص لـ CSS من أجل تصميمات وتفاعلية خارجة عن المألوف حقًا! ومع ذلك ، فقد لاحظت وجود اتجاه نحو الترويج لمكونات "CSS-only" باستخدام طرق مثل "checkbox hack". لسوء الحظ ، فإن مثل هذه الاختراقات تترك عددًا كبيرًا من المستخدمين غير قادرين على استخدام واجهتك.

تغطي هذه المقالات العديد من المكونات الشائعة وسبب عدم كفاية CSS لتغطية إمكانية الوصول من خلال تفصيل متطلبات JavaScript. تستند هذه المتطلبات إلى إرشادات الوصول إلى محتوى الويب (WCAG) وأبحاث إضافية من خبراء الوصول. لن أصف حلول JavaScript أو CSS التجريبي ، ولكن بدلاً من ذلك أقوم بفحص ما يجب حسابه عند إنشاء كل مكون. يمكن بالتأكيد استخدام إطار عمل JavaScript ولكنه ليس ضروريًا لإضافة الأحداث والميزات التي تمت مناقشتها.

المتطلبات المدرجة ليست اختيارية إلى حد كبير - فهي ضرورية للمساعدة في ضمان إمكانية الوصول إلى المكونات الخاصة بك.

إذا كنت تستخدم إطار عمل أو مكتبة مكونة ، فيمكنك استخدام هذه المقالة للمساعدة في تقييم ما إذا كانت المكونات المتوفرة تفي بمتطلبات إمكانية الوصول . من المهم معرفة أن العديد من العناصر المذكورة لن تتم تغطيتها بالكامل بواسطة أدوات اختبار إمكانية الوصول الآلية مثل ax ، وبالتالي تحتاج إلى بعض الاختبارات اليدوية. أو يمكنك استخدام إطار اختبار مثل Cypress لإنشاء اختبارات للوظائف المطلوبة.

ضع في اعتبارك أن هذه المقالة تركز على إخبارك باعتبارات JavaScript لكل مكون من مكونات الواجهة. هذا ليس موردًا شاملاً لجميع تفاصيل التنفيذ لإنشاء مكونات يمكن الوصول إليها بالكامل ، مثل النغمات الضرورية أو حتى الترميز. يتم تضمين الموارد لكل نوع لمساعدتك في معرفة المزيد حول الاعتبارات الأوسع لكل مكون.

تحديد ما إذا كان CSS-Only هو الحل المناسب

فيما يلي بعض الأسئلة التي يجب طرحها قبل المتابعة مع حل CSS فقط. سنغطي بعض المصطلحات المقدمة هنا في سياق أكثر جنبًا إلى جنب مع المكونات ذات الصلة.

• هل هذا من أجل متعتك؟
  ثم انتقل بكل تأكيد إلى CSS ، وادفع الحدود وتعلم ما يمكن أن تفعله اللغة!
• هل تتضمن الميزة إظهار المحتوى وإخفائه؟
  ثم تحتاج إلى JS لتبديل aria على الأقل وتمكين الإغلاق على Esc . بالنسبة لأنواع معينة من المكونات التي تغير الحالة أيضًا ، قد تحتاج أيضًا إلى توصيل التغييرات من خلال تشغيل التحديثات داخل منطقة ARIA المباشرة.
• هل ترتيب التركيز الطبيعي هو الأكثر مثالية؟
  إذا فقد الترتيب الطبيعي العلاقة بين المشغل والعنصر الذي تم تشغيله ، أو إذا لم يتمكن مستخدم لوحة المفاتيح من الوصول إلى المحتوى عبر ترتيب علامات التبويب الطبيعي ، فأنت بحاجة إلى JS للمساعدة في إدارة التركيز.
• هل يوفر عنصر التحكم المنمق المعلومات الصحيحة حول الوظيفة؟
  يتلقى مستخدمو التكنولوجيا المساعدة مثل برامج قراءة الشاشة معلومات تستند إلى الدلالات و ARIA التي تساعدهم على تحديد ما يفعله عنصر التحكم. ويحتاج مستخدمو التعرف على الكلام إلى أن يكونوا قادرين على تحديد تسمية المكون أو نوعه للعمل على العبارة المراد استخدامها لتشغيل عناصر التحكم. على سبيل المثال ، إذا تم تصميم المكون الخاص بك مثل علامات التبويب ولكنه يستخدم أزرار الاختيار "للعمل" مثل علامات التبويب ، فقد يسمع قارئ الشاشة "زر الراديو" وقد يحاول مستخدم الكلام استخدام كلمة "علامة التبويب" لتشغيلها. في هذه الحالات ، ستحتاج إلى JS لتمكين استخدام عناصر التحكم والدلالات المناسبة لتحقيق الوظيفة المطلوبة.
• هل يعتمد التأثير على التمرير و / أو التركيز؟
  بعد ذلك ، قد تحتاج إلى JS للمساعدة في حل بديل لتوفير وصول متساوٍ أو وصول مستمر إلى المحتوى خاصةً لمستخدمي شاشة اللمس وأولئك الذين يستخدمون تكبير سطح المكتب بنسبة 200٪ + أو برنامج تكبير.

نصيحة سريعة : مرجع آخر عند إنشاء أي نوع من عناصر التحكم المخصصة هو قائمة التحقق من التطوير القابل للوصول للتحكم المخصص من دليل W3 "استخدام ARIA". هذا يذكر عدة نقاط أعلاه ، مع بعض الاعتبارات التصميمية والدلالية الإضافية.

تلميحات

يعد تضييق تعريف التلميح أمرًا صعبًا بعض الشيء ، ولكن في هذا القسم نتحدث عن تسميات نصية صغيرة تظهر عند تمرير الماوس بالقرب من عنصر التشغيل. إنها تراكب محتوى آخر ، ولا تتطلب تفاعلًا ، وتختفي عندما يزيل المستخدم التمرير أو التركيز.

قد يبدو حل CSS فقط هنا جيدًا تمامًا ، ويمكن تحقيقه بشيء مثل:

 <button class="tooltip-trigger">I have a tooltip</button> <span class="tooltip">Tooltip</span> .tooltip { display: none; } .tooltip-trigger:hover + .tooltip, .tooltip-trigger:focus + .tooltip { display: block; }

ومع ذلك ، فإن هذا يتجاهل تمامًا قائمة مخاوف إمكانية الوصول ويستبعد العديد من المستخدمين من الوصول إلى محتوى تلميح الأدوات.

مجموعة كبيرة من المستخدمين المستبعدين هم أولئك الذين يستخدمون شاشات تعمل باللمس حيث :hover لأنه على الشاشات التي تعمل باللمس ، يتم تشغيل حدث :hover بالتزامن مع :focus . هذا يعني أن أي إجراء مرتبط بعنصر التشغيل - مثل زر أو ارتباط - سيتم إطلاقه جنبًا إلى جنب مع الكشف عن تلميح الأداة. هذا يعني أن المستخدم قد يفقد التلميح ، أو لا يملك الوقت لقراءة محتوياته.

في حالة إرفاق تلميح الأداة بعنصر تفاعلي بدون أحداث ، فقد يظهر التلميح ولكن لا يمكن رفضه حتى يكتسب عنصر آخر التركيز ، وفي هذه الأثناء قد يحظر المحتوى ويمنع المستخدم من القيام بمهمة ما.

بالإضافة إلى ذلك ، فإن المستخدمين الذين يحتاجون إلى استخدام برنامج التكبير أو التكبير للتنقل يواجهون أيضًا عائقًا كبيرًا أمام استخدام تلميحات الأدوات. نظرًا للكشف عن تلميحات الأدوات عند التحويم ، إذا احتاج هؤلاء المستخدمون إلى تغيير مجال رؤيتهم عن طريق تحريك الشاشة لقراءة تلميح الأداة ، فقد يتسبب ذلك في اختفائها. تقوم تلميحات الأدوات أيضًا بإزالة التحكم من المستخدم حيث لا يوجد غالبًا ما يخبر المستخدم بأنه سيظهر تلميح أداة في وقت مبكر. قد يمنعهم تراكب المحتوى من القيام بمهمة ما. في بعض الحالات ، مثل تلميح أداة مرتبط بحقل نموذج ، يمكن للجوال أو لوحات المفاتيح الأخرى التي تظهر على الشاشة أن تحجب محتوى تلميح الأداة. وإذا لم تكن متصلة بشكل مناسب بالعنصر المشغل ، فقد لا يعرف بعض مستخدمي التكنولوجيا المساعدة حتى ظهور تلميح أداة.

يأتي التوجيه الخاص بسلوك تلميحات الأدوات من معيار نجاح WCAG 1.4.13 - المحتوى عند التمرير أو التركيز. يهدف هذا المعيار إلى مساعدة المستخدمين ضعاف البصر وأولئك الذين يستخدمون برامج التكبير والتصغير. تتضمن المبادئ التوجيهية لتلميح الأدوات (والمحتويات الأخرى التي تظهر عند التمرير والتركيز) ما يلي:

• مقبول
  يمكن رفض التلميح بدون تحريك الماوس أو التركيز
• تحوم
  يمكن التمرير فوق محتوى تلميح الأدوات الذي تم الكشف عنه دون أن يختفي
• مستمر
  لا يختفي المحتوى الإضافي بناءً على انقضاء المهلة ، ولكنه ينتظر أن يزيل المستخدم التمرير أو التركيز أو يرفضه بأي طريقة أخرى

للوفاء بهذه الإرشادات بشكل كامل يتطلب بعض مساعدة JavaScript ، لا سيما للسماح برفض المحتوى.

• سيفترض مستخدمو التكنولوجيا المساعدة أن سلوك الرفض مرتبط بمفتاح Esc ، الأمر الذي يتطلب مستمع JavaScript.
• وفقًا لبحث Sarah Higley الموضح في القسم التالي ، فإن إضافة زر "إغلاق" مرئي داخل تلميح الأداة سيتطلب أيضًا JavaScript للتعامل مع الحدث القريب.
• من الممكن أن تحتاج JavaScript إلى زيادة حل التصميم الخاص بك لضمان قدرة المستخدم على المرور فوق محتوى تلميح الأدوات دون رفضه أثناء تحريك المستخدم للماوس.

بدائل تلميحات الأدوات

يجب أن تكون تلميحات الأدوات هي الملاذ الأخير. تقدم سارة هيجلي - خبيرة في إمكانية الوصول ولديها شغف خاص بالثني عن استخدام التلميحات - هذا الاختبار البسيط:

"لماذا أقوم بإضافة هذا النص إلى واجهة المستخدم؟ أين يمكن أن تذهب أيضا؟ "

- سارة هيجلي من العرض التقديمي "تلميحات الأدوات: التحقيق في أربعة أجزاء"

بناءً على البحث الذي شاركت به سارة عن دورها في Microsoft ، فإن الحل البديل هو "toggletip" المخصص. يعني هذا بشكل أساسي توفير عنصر إضافي للسماح للمستخدم بتشغيل عرض المحتوى الإضافي وإخفائه عن قصد. على عكس تلميحات الأدوات ، يمكن أن تحتفظ toggletips بدلالات العناصر داخل المحتوى الذي تم الكشف عنه. كما أنها تمنح المستخدم مرة أخرى التحكم في تبديلها ، وتحتفظ بقابلية الاكتشاف والتشغيل من قبل المزيد من المستخدمين وخاصة مستخدمي الشاشات التي تعمل باللمس.

إذا كنت تتذكر أن سمة title موجودة ، فاعلم فقط أنها تعاني من نفس المشكلات التي لاحظناها من حل CSS فقط. بمعنى آخر - لا تستخدم title في ظل افتراض أنه حل تلميح مقبول.

لمزيد من المعلومات ، راجع العرض التقديمي لسارة على YouTube بالإضافة إلى مقالها الشامل حول تلميحات الأدوات. لمعرفة المزيد حول تلميحات الأدوات مقابل تلميحات toggletips ومزيد من المعلومات حول سبب عدم استخدام title ، راجع مقالة Heydon Pickering من Inclusive Components: Tooltips and Toggletips.

الوسائط

النماذج - المعروفة أيضًا باسم الصناديق المبسطة أو مربعات الحوار - هي نوافذ في الصفحة تظهر بعد إجراء التشغيل. إنها تراكب محتوى الصفحة الأخرى ، وقد تحتوي على معلومات منظمة بما في ذلك إجراءات إضافية ، وغالبًا ما تحتوي على خلفية شبه شفافة للمساعدة في تمييز النافذة النموذجية عن بقية الصفحة.

لقد رأيت بعض الاختلافات في نموذج CSS فقط (وأنا مذنب في صنع واحدة لإصدار أقدم من محفظتي). قد يستخدمون "اختراق مربع الاختيار" ، أو يستفيدون من سلوك :target ، أو يحاولون تصميمه من :focus (والذي من المحتمل أن يكون في الحقيقة تلميحًا زائدًا مقنعًا).

بالنسبة لعنصر dialog HTML ، اعلم أنه لا يمكن الوصول إليه بشكل شامل. لذلك ، بينما أشجع الناس تمامًا على استخدام HTML الأصلي قبل الحلول المخصصة ، للأسف هذا يكسر هذه الفكرة. يمكنك معرفة المزيد حول سبب عدم إمكانية الوصول إلى dialog HTML.

بخلاف تلميحات الأدوات ، تهدف النماذج إلى السماح بالمحتوى المنظم. هذا يعني احتمال وجود عنوان ، وبعض محتويات الفقرة ، وعناصر تفاعلية مثل الروابط أو الأزرار أو حتى النماذج. لكي يتمكن معظم المستخدمين من الوصول إلى هذا المحتوى ، يجب أن يكونوا قادرين على استخدام أحداث لوحة المفاتيح ، ولا سيما الجدولة. بالنسبة للمحتوى النموذجي الأطول ، يجب أن تحتفظ مفاتيح الأسهم أيضًا بالقدرة على التمرير. ومثل تلميحات الأدوات ، يجب أن تكون قابلة للرفض باستخدام مفتاح Esc - ولا توجد طريقة لتمكين ذلك باستخدام CSS فقط.

جافا سكريبت مطلوب لإدارة التركيز داخل النماذج. يجب أن تحبس الوسائط التركيز ، مما يعني أنه بمجرد أن يكون التركيز داخل النموذج ، يجب ألا يكون المستخدم قادرًا على الخروج منه في محتوى الصفحة خلفه. لكن أولاً ، يجب أن يدخل التركيز داخل النموذج ، والذي يتطلب أيضًا JavaScript من أجل حل مشروط يمكن الوصول إليه بالكامل.

إليك تسلسل الأحداث ذات الصلة بالشروط التي يجب إدارتها باستخدام JavaScript:

1. مستمع الحدث على زر يفتح المشروط
2. يتم وضع التركيز داخل النموذج ؛ أي عنصر يختلف بناءً على محتوى شكلي (انظر شجرة القرار)
3. يتم حجز التركيز داخل النموذج حتى يتم استبعاده
4. على نحو مفضل ، يكون المستخدم قادرًا على إغلاق نموذج باستخدام مفتاح Esc بالإضافة إلى زر إغلاق مخصص أو إجراء زر مدمر مثل "إلغاء" إذا كان الإقرار بالمحتوى الشرطي مطلوبًا
   1. إذا كان Esc مسموحًا به ، فإن النقرات على الخلفية المشروطة يجب أن تتجاهل الشرط أيضًا
5. عند الرفض ، إذا لم يحدث تنقل ، يتم إعادة التركيز على عنصر زر التشغيل

شجرة قرار التركيز المشروط

استنادًا إلى مثال الحوار النموذجي لممارسات التأليف WAI-ARIA ، إليك شجرة قرار مبسطة لمكان التركيز بمجرد فتح النموذج. سيحدد السياق دائمًا الاختيار هنا ، ومن الناحية المثالية ، تتم إدارة التركيز بشكل أكبر من مجرد "العنصر الأول القابل للتركيز". في الواقع ، في بعض الأحيان يجب تحديد العناصر غير القابلة للتركيز.

• الموضوع الأساسي للشكل هو النموذج.
  التركيز على حقل الشكل الأول.
• المحتوى الشرطي مهم من حيث الطول ويدفع الإجراءات المشروطة بعيدًا عن الأنظار.
  ركز على العنوان إذا كان موجودًا أو على الفقرة الأولى.
• الغرض من النموذج إجرائي (مثال: تأكيد الإجراء) مع العديد من الإجراءات المتاحة.
  ركز على الإجراء "الأقل تدميراً" بناءً على السياق (مثال: "موافق").
• الغرض من النموذج إجرائي بإجراء واحد.
  ركز على العنصر الأول القابل للتركيز

نصيحة سريعة : في حالة الحاجة إلى التركيز على عنصر غير قابل للتركيز ، مثل عنوان أو فقرة ، أضف tabindex="-1" مما يسمح للعنصر أن يصبح قابلاً للتركيز برمجيًا مع JS ولكن لا يضيفه إلى ترتيب علامة تبويب DOM .

راجع العرض التوضيحي النموذجي لـ WAI-ARIA للحصول على مزيد من المعلومات حول المتطلبات الأخرى لإعداد ARIA وتفاصيل إضافية حول كيفية تحديد العنصر المراد إضافة التركيز إليه. يتضمن العرض التوضيحي أيضًا JavaScript لتوضيح كيفية إدارة التركيز.

للحصول على حل جاهز للعمل ، أنشأت Kitty Giraudel مربع حوار 11y يتضمن متطلبات الميزات التي ناقشناها. أجرى Adrian Roselli أيضًا أبحاثًا حول إدارة تركيز الحوارات المشروطة وأنشأ عرضًا توضيحيًا وجمع معلومات حول كيفية توصيل مجموعات مختلفة من المستعرض وقارئ الشاشة للعنصر المركّز.

نوافذ التبويب

تتضمن الواجهات المبوبة سلسلة من المشغلات التي تعرض لوحات المحتوى المقابلة واحدة تلو الأخرى. تتضمن "الاختراقات" في CSS التي قد تجدها لهذه الأزرار استخدام أزرار اختيار نمطية ، أو :target ، وكلاهما يسمح بالكشف عن لوحة واحدة فقط في كل مرة.

فيما يلي ميزات علامة التبويب التي تتطلب JavaScript:

1. تبديل السمة aria-selected إلى true لعلامة التبويب الحالية و false لعلامات التبويب غير المحددة
2. إنشاء tabindex متجول لتمييز اختيار علامة التبويب من التركيز
3. نقل التركيز بين علامات التبويب من خلال الاستجابة لأحداث مفتاح السهم (واختياريا Home End )

اختياريًا ، يمكنك جعل تحديد علامة التبويب يتبع التركيز - بمعنى عندما يتم التركيز على علامة تبويب ، يتم تحديدها أيضًا ثم يتم تحديدها وتعرض لوحة علامة التبويب المرتبطة بها. تقدم ممارسات التأليف WAI-ARIA هذا الدليل لتحديد ما إذا كان يجب أن يتبع التحديد التركيز أم لا.

سواء اخترت أن يكون لديك تحديد يتبع التركيز أم لا ، ستستخدم أيضًا JavaScript للاستماع إلى أحداث مفاتيح الأسهم لنقل التركيز بين عناصر علامة التبويب. هذا نمط بديل للسماح بالتنقل في خيارات علامة التبويب نظرًا لأن استخدام فهرس علامات التبويب المتجول (الموصوف أدناه) يغير ترتيب تركيز علامة التبويب الطبيعي للوحة المفاتيح.

حول متنقل tabindex

يتمثل مفهوم tabindex المتجول في أنه يتم التحكم في قيمة قيمة tabindex برمجيًا لإدارة ترتيب تركيز العناصر. فيما يتعلق بعلامات التبويب ، هذا يعني أن علامة التبويب المحددة فقط هي جزء من ترتيب التركيز عن طريق تعيين tabindex="0" ، ويتم تعيين علامات التبويب غير المحددة على tabindex="-1" التي تزيلها من ترتيب التركيز الطبيعي للوحة المفاتيح.

والسبب في ذلك هو أنه عند تحديد علامة تبويب ، فإن علامة التبويب التالية ستوجه تركيز المستخدم داخل لوحة علامة التبويب المرتبطة. يمكنك اختيار جعل العنصر الذي يمثل لوحة علامة التبويب قابلاً للتركيز من خلال تعيينه tabindex="0" ، أو قد لا يكون ذلك ضروريًا إذا كان هناك ضمان لعنصر قابل للتركيز داخل لوحة علامة التبويب . إذا كان محتوى لوحة علامة التبويب الخاصة بك أكثر تنوعًا أو تعقيدًا ، فيمكنك التفكير في إدارة التركيز وفقًا لشجرة القرار التي راجعناها من أجل النماذج.

مثال على أنماط علامة التبويب

فيما يلي بعض الأنماط المرجعية لإنشاء علامات التبويب:

• عرض Tabpanel من جامعة Deque
• اختبارات أداة Tab من Scott O'Hara (تختبر عدة أنماط وظيفية)
• واجهات مبوبة من المكونات الشاملة لـ Heydon Pickering ، والتي توضح كيف يمكن أن تكون علامات التبويب تحسينًا تدريجيًا لجدول المحتويات

دائري

تسمى أيضًا عروض الشرائح أو المنزلقات ، وتتضمن الدوارات سلسلة من لوحات المحتوى الدوارة (وتعرف أيضًا باسم "الشرائح") التي تتضمن آليات التحكم. ستجد هذه في العديد من التكوينات مع مجموعة واسعة من المحتوى. من المعروف أنها تعتبر نمط تصميم سيئًا إلى حد ما.

يتمثل الجزء الصعب في الدوارات الدوارة لـ CSS فقط في أنها قد لا توفر عناصر تحكم ، أو قد تستخدم عناصر تحكم غير متوقعة للتلاعب بحركة الرف الدائري. على سبيل المثال ، يمكنك مرة أخرى استخدام "اختراق مربع الاختيار" للتسبب في انتقال الرف الدائري ، ولكن مربعات الاختيار تنقل نوعًا خاطئًا من المعلومات حول التفاعل لمستخدمي التكنولوجيا المساعدة. بالإضافة إلى ذلك ، إذا قمت بتصميم تسميات مربعات الاختيار لتظهر بشكل مرئي كسهمين للأمام وللخلف ، فمن المحتمل أن تمنح مستخدمي برنامج التعرف على الكلام انطباعًا خاطئًا عما يجب أن يقولوه للتحكم في الرف الدائري.

في الآونة الأخيرة ، تم دعم CSS الأصلي لالتقاط التمرير المفاجئ. في البداية ، يبدو أن هذا هو الحل الأمثل لـ CSS فقط. ولكن ، حتى التحقق الآلي من إمكانية الوصول سيضع علامة على أنها غير قابلة للتنقل من قبل مستخدمي لوحة المفاتيح في حالة عدم وجود طريقة للتنقل بينها عبر العناصر التفاعلية. هناك مخاوف أخرى تتعلق بإمكانية الوصول وتجربة المستخدم مع السلوك الافتراضي لهذه الميزة ، والتي قمت بتضمين بعضها في العرض التوضيحي المفاجئ للتمرير على SmolCSS.

على الرغم من النطاق الواسع لشكل الدوارات ، إلا أن هناك بعض السمات المشتركة. يتمثل أحد الخيارات في إنشاء دائرة باستخدام علامات الجدولة نظرًا لأنها فعالة نفس الواجهة الأساسية مع عرض تقديمي مرئي تم تغييره. مقارنةً بعلامات التبويب ، قد تقدم الدوارات عناصر تحكم إضافية للسابق والتالي ، وتتوقف أيضًا مؤقتًا إذا كانت الرف الدائري قيد التشغيل التلقائي.

فيما يلي اعتبارات JavaScript اعتمادًا على ميزات الرف الدائري لديك:

• استخدام عناصر التحكم المرقمة
  عند اختيار عنصر مرقم ، ركز برمجيًا على شريحة الرف الدائري المرتبطة. سيتضمن ذلك إعداد حاويات الشرائح باستخدام tabindex المتجولة بحيث يمكنك تركيز الشريحة الحالية ، ولكن مع منع الوصول إلى الشرائح خارج الشاشة.
• باستخدام التشغيل التلقائي
  قم بتضمين عنصر تحكم في الإيقاف المؤقت ، وقم أيضًا بتمكين الإيقاف المؤقت عند تحريك الشريحة أو تركيز عنصر تفاعلي بداخلها. بالإضافة إلى ذلك ، يمكنك التحقق prefers-reduced-motion مفضلة داخل JavaScript لتحميل عرض الشرائح في حالة الإيقاف المؤقت لاحترام تفضيلات المستخدم.
• استخدام ضوابط السابق / التالي
  قم بتضمين عنصر مخفي مرئيًا تم تمييزه على أنه aria-live="polite" وعند تنشيط عناصر التحكم هذه ، قم بتعبئة المنطقة الحية بإشارة إلى الموضع الحالي ، مثل "الشريحة 2 من 4".

موارد لبناء الدوارات التي يمكن الوصول إليها

• تفاصيل واعتبارات تنفيذية شاملة بالإضافة إلى مثال رمز كامل من البرنامج التعليمي W3C Web Accessibility على الرف الدائري
• مثال جامعة Deque على تحسين واجهة علامة التبويب في دائرة
• مثال ممارسات تأليف WAI-ARIA لدائرة الصور بالتدوير التلقائي
• مجموعة مختارة من موارد المكتبة في تقرير Smashing للمكونات التي يمكن الوصول إليها

القوائم المنسدلة

يشير هذا إلى أحد المكونات حيث يقوم الزر بفتح قائمة بالارتباطات ، وعادة ما تستخدم لقوائم التنقل. تطبيقات CSS التي تتوقف عند إظهار القائمة على :hover أو :focus تفوت فقط بعض التفاصيل المهمة.

أعترف ، حتى أنني اعتقدت أنه باستخدام أحدث خاصية :focus-within يمكننا تنفيذ حل CSS فقط بأمان. سترى أن مقالتي حول قوائم CSS المنسدلة قد تم تعديلها لتضمين الملاحظات والموارد حول JavaScript الضرورية (احتفظت بالعنوان حتى يتمكن الآخرون الذين يبحثون عن هذا الحل من إكمال تنفيذ JS أيضًا). على وجه التحديد ، فإن الاعتماد على CSS فقط يعني انتهاك معيار نجاح WCAG 1.4.13: المحتوى عند التمرير أو التركيز الذي تعلمناه من خلال تلميحات الأدوات.

نحتاج إلى إضافة JavaScript لبعض التقنيات التي يجب أن تبدو مألوفة في هذه المرحلة:

• التبديل aria-expanded على زر القائمة بين true false من خلال الاستماع إلى click الأحداث
• إغلاق قائمة مفتوحة عند استخدام مفتاح Esc ، وإعادة التركيز إلى زر تبديل القائمة
• ويفضل إغلاق القوائم المفتوحة عند نقل التركيز خارج القائمة
• اختياري : تنفيذ مفاتيح الأسهم بالإضافة إلى مفتاحي Home End للتنقل بلوحة المفاتيح بين أزرار تبديل القائمة والروابط داخل القوائم المنسدلة

نصيحة سريعة : " من التنفيذ true ] + .dropdown المنسدلة " طريق ربط عرض القائمة .dropdown-toggle[aria-expanded= إضافة فئة مثل active . هذا يزيل بعض التعقيد من حل JS الخاص بك أيضًا!

يشار إلى هذا أيضًا باسم "نمط الإفصاح" ويمكنك العثور على مزيد من التفاصيل في قائمة التنقل في أمثلة ممارسات التأليف في WAI-ARIA.

موارد إضافية حول إنشاء مكونات يمكن الوصول إليها

• دليل Smashing الكامل لمكونات الواجهة الأمامية التي يمكن الوصول إليها
• مقال كاري فيشر جيد ، أفضل ، أفضل: فك تشابك العالم المعقد للأنماط التي يمكن الوصول إليها
• عروض توضيحية ومعلومات عن أنماط التصميم الشائعة وعناصر واجهة المستخدم المتاحة من ممارسات التأليف WAI-ARIA 1.2
• مكتبة كود جامعة ديكوي
• المكونات التي يمكن الوصول إليها لسكوت أوهارا
• مكونات هايدون بيكرينغ الشاملة