لقد استخدمت الويب لمدة يوم واحد باستخدام لوحة مفاتيح فقط

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

من يستخدم لوحة المفاتيح للتنقل؟

بشكل عام ، هناك ثلاثة أنواع من مستخدمي لوحة المفاتيح:

• المستخدمون الذين يعانون من إعاقة حركية ويكافحون من أجل استخدام الماوس ،
• المستخدمون ضعاف البصر غير القادرين على رؤية العناصر القابلة للنقر في الصفحة ،
• المستخدمون المتمرسون القادرين على استخدام الماوس ولكنهم يجدون استخدام لوحة المفاتيح أسرع.

كم عدد المستخدمين الذين نتحدث؟

لقد بحثت في الويب بحثًا عن إحصائيات حول استخدام لوحة المفاتيح ، ولم أجد شيئًا. عنجد. ليست دراسة واحدة .

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

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

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

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

"يحتاج الأشخاص المكفوفون إلى الوصول الكامل إلى لوحة المفاتيح. فترة."

- ديفيد ماكدونالد ، محرر مشارك في استخدام WAI ARIA في HTML5

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

2.3٪ من الأمريكيين (من جميع الأعمار) يعانون من إعاقة بصرية ، وليس كلهم ​​بالضرورة يستدعي استخدام قارئ الشاشة. في عام 2016 ، قدرت Addy Osmani الاستخدام الفعلي لقارئ الشاشة بحوالي 1 إلى 2٪. إذا أخذنا هؤلاء المستخدمين في الاعتبار مع مستخدمينا الذين يعانون من إعاقة حركية ومستخدمينا المتميزين ، فإن استخدام لوحة المفاتيح يضيف نسبة كبيرة من الجمهور العالمي. لذلك ، فإن الاهتمام بإمكانية الوصول إلى لوحة المفاتيح لا يقتصر فقط على فعل الشيء الصحيح أخلاقياً (ومن الناحية القانونية - تتطلب العديد من البلدان إمكانية الوصول إلى مواقع الويب بموجب القانون) ، ولكنه أيضًا منطقي من الناحية التجارية.

مع وضع كل ذلك في الاعتبار ، ما هي حالة الويب اليوم؟ حان الوقت لمعرفة ذلك!

التجربة

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

سمة autofocus

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

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

أنماط التركيز الافتراضية

لقد بحثت عن خط لمن هو على أي حال؟ الخير ، ولا يمكن أن تساعد في ملاحظة أن YouTube لم يحدد أيًا مخصصًا :focus ، بدلاً من الاعتماد على التصميم الأصلي للمتصفح للإشارة بصريًا إلى العناصر التي كنت أتصفحها.

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

حتى أنني عدت إلى الوراء بعيدًا في الوقت المناسب:

إذا كنت ترغب في رؤية المزيد ، فهناك مجموعة شاملة من لقطات الشاشة لعناصر مختلفة في حالات المتصفح الأصلية.

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

من الممكن تعطيل أنماط تركيز المتصفح الافتراضية - عن طريق تعيين outline: none على العنصر الخاص بك - ولكن يجب عليك القيام بذلك فقط إذا قمت بتنفيذ البديل المصمم الخاص بك . يوصي Heydon Pickering بهذا الأسلوب ، مشيرًا إلى الافتراضات غير الواضحة أو القبيحة التي تستخدمها بعض المتصفحات. إذا قررت طرح الأنماط الخاصة بك ، فتأكد من استخدام أكثر من مجرد اللون كمعدِّل: أضف مخططًا تفصيليًا أو تسطيرًا أو بعض المؤشرات المرئية الأخرى لدعم المستخدمين الذين يعانون من عمى الألوان.

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

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

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

محدد CSS :focus-visible

إذا كنت تريد أفضل ما في العالمين ، فقد ترغب في استكشاف CSS4 :focus-visible ، والتي ستتيح لك توفير نمط تركيز مختلف وفقًا للسياق. :focus-visible يستهدف فقط العناصر التي تم التركيز عليها باستخدام لوحة المفاتيح ، وليس بالنقر بالماوس. هذا رائع للغاية ، على الرغم من أنه مدعوم حاليًا فقط في Firefox. يمكن تمكينه في Chrome عن طريق تشغيل علامة "ميزات النظام الأساسي للويب التجريبية".

مقاطع فيديو YouTube وإمكانية الوصول إلى لوحة المفاتيح

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

ما لم يعجبني هو أن التسميات المفيدة ، مثل نص "كتم الصوت" الذي يظهر عند التمرير فوق رمز كتم الصوت ، لا تظهر عند التركيز.

هناك مجال آخر يجعل YouTube ينخفض ​​وهو أنه يمنع بعض التركيز على التصميم. كنت هنا أحاول الانتقال إلى الزر "إظهار المزيد".

لقد قمت بالتبويب عن طريق الخطأ بعد زر "إظهار المزيد" لأنني لم أتمكن من رؤية أي شيء :focus ، سواء كان مخصصًا أو أصليًا. اكتشفت أنه تم تجاوز التصميم الأصلي outline-width :

إمكانية الوصول إلى لوحة مفاتيح GitHub

حسنًا ، وقت العمل. أين أفضل من العمل في منزل Code ، github.com؟

لقد لاحظت ثلاثة أشياء بخصوص GitHub: أحدهما عظيم والآخر معقول والآخر سيئ.

أولا الخير.

رابط "تخطي إلى المحتوى"

يقدم GitHub رابط Skip to content ، والذي يتخطى القائمة الرئيسية.

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

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

اضغط لمشاهدة المحتوى

كانت إحدى الميزات التي لاحظتها تعمل بشكل مختلف عن الإصدار "بدون لوحة المفاتيح" هي مؤشر تقسيم الكود.

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

لا يبدو هذا ضروريًا حقًا - سأكون سعيدًا بالانتقال إلى الشريط الملون والضغط على ENTER على ذلك - لكن هذا السلوك المختلف لا يسبب أي ضرر أيضًا.

روابط غير مرئية

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

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

يُضاف رابط تسجيل الخروج هذا إلى رابط تسجيل الخروج في القائمة المنسدلة لملفك الشخصي:

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

كيفية عمل اختصار "تخطي إلى المحتوى"

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

يُطلق على "رابط التخطي" اسم "تخطي التنقل" أو "تخطي التنقل الرئيسي" أو "تخطي ارتباطات التنقل" أو "تخطي إلى المحتوى الرئيسي". ربما يكون "التخطي إلى المحتوى الرئيسي" هو الأوضح حيث يخبرك بالمكان الذي تنتقل إليه ، بدلاً من ما تتخطاه.

يجب أن يظهر ارتباط الاختصار بشكل مثالي بعد علامة الفتح <body> . يمكن أن يظهر لاحقًا في DOM ، حتى بعد التذييل ، بشرط أن يكون لديك سمة tabindex="1" لإجبارها على أن تصبح العنصر التفاعلي الأول في ترتيب علامة التبويب. ومع ذلك ، فإن استخدام tabindex برقم أكبر من الصفر يعد ممارسة سيئة بشكل عام وسيؤدي غالبًا إلى تحذير عند استخدام أدوات التحقق من الصحة مثل Lighthouse.

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

 <a class="screen-reader-shortcut" href="#main-content"> Skip to main content </a>

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

 .screen-reader-shortcut { position: absolute; top: -1000em; } .screen-reader-shortcut:focus { position: fixed; top: 0; left: 0; z-index: 999; /* ...and now any nice styling you want to apply... */ padding: 1em; background-color: rgb(114, 105, 105); color: white; text-decoration: none; }

إذن ، ما الذي نتخطاه بالفعل؟ ما هو #main-content ؟ يمكن أن يكون أي شيء حقًا:

1. محتوى مضمّن
   على سبيل المثال ، معرّف علامة h1 : <h1 id="main-content"> .
2. حاوية
   على سبيل المثال ، معرّف الحاوية حول المحتوى الرئيسي الخاص بك مثل <main id="main-content"> .
3. مرساة الأخوة
   يمكنك الارتباط بعلامة مسماة أعلى المحتوى الرئيسي مباشرةً ، على سبيل المثال <a name="main-content"></a> . عادة ما يتم وصف هذا النهج في البرامج التعليمية القديمة - لا أوصي به هذه الأيام.

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

يجب أن يحتوي #main-content الخاص بك أيضًا على علامة tabindex -1 ، للتأكد من أنه قابل للتركيز برمجيًا. قد لا تتبع بعض برامج قراءة الشاشة رابط التخطي بطريقة أخرى.

 <h1 tabindex="-1">This is the title of the page</h1>

اعتبار أخير: دعم المستعرض القديم. إذا كان لديك عدد كافٍ من المستخدمين على IE9 أو ما دونه ، فقد تحتاج إلى تطبيق إصلاح JavaScript صغير على روابط التخطي للتأكد من أن التركيز يتحول بالفعل كما هو متوقع ويتخطى المستخدمون التنقل بنجاح.

لماذا نعيد اختراع العجلة؟

يبدو أنه من الجنون أننا كمطورين للويب يتعين علينا تنفيذ اختراق "تخطي التنقل" هذا على جميع مواقعنا كقاعدة. قد تعتقد أنه يمكننا ترك المعايير تقوم بالعمل.

منذ HTML5 ، لدينا عناصر دلالية مثل <main> و <nav> و <header> . قبل ذلك ، كان لدينا معالم ARIA مثل role="main" و role="navigation" و role="banner" على التوالي. في المشهد الحالي للويب ، تملي أفضل الممارسات أنك بحاجة إلى كليهما ، أي <main role="main"> ، وهو انتهاك فظيع لمبدأ DRY ، ولكن ها نحن ذا.

مع كل هذا الثراء الدلالي ، كنت تأمل أن تبدأ المتصفحات في دعم التنقل بشكل أصلي عبر مناطق المعالم هذه ، على سبيل المثال عن طريق كشف اختصار لوحة المفاتيح للمستخدمين للانتقال مباشرة إلى قسم <main> من صفحة الويب. لا يوجد مثل هذا الحظ - لا يوجد دعم محلي في الوقت الحالي. أفضل رهان هو استخدام Landmark Navigation عبر امتداد لوحة المفاتيح لمتصفح Chrome أو Opera أو Firefox.

ومع ذلك ، يمكن لمستخدمي برامج قراءة الشاشة البدء في التنقل مباشرة إلى هذه المناطق المميزة. على سبيل المثال ، في VoiceOver على نظام Mac ، يمكنك الضغط على CTRL + ALT + U لإظهار قائمة المعالم والانتقال إلى المعلم "الرئيسي" ، وهو اختصار سريع ومتسق للوصول إلى المحتوى الرئيسي. بالطبع ، هذا يعتمد على المواقع التي تقوم بترميز مستنداتها بشكل صحيح.

فيما يلي نقطة انطلاق جيدة لموقعك إذا كنت ترغب في أن يكون قابلاً للتنقل عبر مناطق المعالم:

 <body> <header role="banner"> <!-- Logo and things can go here --> <nav role="navigation"> <!-- Site navigation links go here --> </nav> </header> <main role="main"> <!-- Main content lives here - including our h1 --> </main> <footer role="contentinfo"> <!-- Copyright statement, etc --> </footer> </body>

كل هذا الترميز هو عمل عطشان. حان وقت القهوة.

قهوة ميثاق

أتذكر أنني رأيت نشرة إعلانية لموقع pactcoffee.com ... دعنا نذهب ونلقي نظرة!

لافتة ملفات تعريف الارتباط

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

لقد استخدمت امتداد إمكانية الوصول ChromeLens لتتبع ترتيب علامة تبويب الصفحة:

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

المزيد من الروابط غير المرئية

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

هذا لأن المنطقة "المخفية" ليست مخفية حقًا ، لقد تم تدويرها 180 درجة فقط ، باستخدام:

 transform: rotateY(180deg);

... مما يعني أن الزر "رؤية أقل ..." لا يزال جزءًا من ترتيب علامات التبويب. يمكن إصلاح ذلك عن طريق تطبيق display: none حتى يصبح التطبيق جاهزًا لتشغيل الدوران:

أمرت القهوة. حان الوقت الآن لمواصلة بحثي.

عالم تكنولوجيا المعلومات

كنت أقوم ببعض البحث من أجل هذا المقال ووجدت تجربة مماثلة لتجربتي ؛ تصفح كيفن بوردي الويب لمدة سبعة أيام باستخدام لوحة المفاتيح فقط. أجد أنه من المفارقات أنني لم أتمكن من قراءة مقالته في ظل نفس القيود!

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

لقد حفرت في شفرة المصدر لمعرفة ما كان يجري. للحظة ، اعتقدت أنه قد يكون عدونا اللدود ، خاصية CSS outline .

عند فحص رابط "تحديث إعدادات الخصوصية" ، يمكنني رؤية outline: 0 كما كنت أظن. لذا ربما أركز على الأزرار ، لكن لا توجد ملاحظات مرئية عندما يحدث ذلك؟

حاولت تعيين الحالة على :hover لمعرفة ما إذا كنت قد فقدت أي تصميم كمستخدم لوحة مفاتيح:

من المؤكد أن الرابط تحول إلى لون برتقالي جميل وواضح عند التمرير - وهو شيء لم أره مطلقًا في التركيز:

الحورة! تصدع ذلك! لم أشاهد مطلقًا :focus لأن التصميم المخصص كان يتم تطبيقه فقط على :hover . لابد أنني تجاوزت الأزرار دون أن ألاحظ ، أليس كذلك؟

خاطئ - ظلم - يظلم. حتى عندما أخترق CSS محليًا ، لم أتمكن من رؤية أي نمط تركيز ، مما يعني أنني لم أحصل على ما يصل إلى الجدولة في شكل ملف تعريف الارتباط. ثم أدركت ... الرابط يفتقد سمة href :

كان هذا هو الجاني الحقيقي. outline: 0 لم تكن المشكلة - لم يكن المتصفح ينقل إلى الرابط أبدًا لأنه لم يكن رابطًا صالحًا!

من مواصفات HTML 5.2:

يتم تحديد وجهة الرابط (الروابط) بواسطة سمة href ، والتي يجب أن تكون موجودة ويجب أن تحتوي على عنوان URL صالح غير فارغ يحتمل أن تكون محاطة بمسافات. إذا كانت السمة href غير موجودة ، فلن يقوم العنصر بتعريف الارتباط.

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

من المضحك أنه في وقت لاحق من ذلك اليوم ، تلقيت مقالًا على PC World لقراءته وواجهت نفس المشكلة تمامًا .

يبدو أن كلا الموقعين كانا يستخدمان نفس منصة إدارة الموافقة (CMP). لقد أجريت القليل من البحث واستنتجت أنه يؤثر على عدد من المواقع التي تمتلكها نفس الشركة ، ومنذ ذلك الحين اتصلت بهم مباشرة مع إصلاح مقترح.

كينيتيكو

صنبور المطبخ الخاص بي يتسرب وكنت أنوي استبداله. رأيت إعلانًا في الجريدة المحلية لموقع kinetico.co.uk ، لذلك اعتقدت أنني سألقي نظرة.

لم أتمكن من الانتقال إلى قسم "Kitchen Taps" ، حيث تم إخفاء الرابط بعيدًا خلف الرابط الرئيسي "Salt & Cartridges" والذي يظهر فقط الروابط الفرعية الخاصة به عند التمرير. من المثير للاهتمام أن الموقع يتطلع إلى الأمام بما يكفي لتوفير رابط "تخطي إلى المحتوى" (يُرى باختصار في gif أعلاه) ولكن لم يتمكن من إنشاء قائمة يمكن الوصول إليها!

هذا هو المكان الذي تظهر فيه القائمة بشكل خاطئ - فهي تعرض القائمة الفرعية فقط عندما يتم تحريك عنصر القائمة الرئيسي فوقها:

إصلاحه أسهل قولاً من فعله. في معظم الحالات ، يمكنك فقط "مضاعفة" المحدد لتطبيقه على التركيز أيضًا:

 li:hover .nav_sub_menu, li:focus .nav_sub_menu { }

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

 li:hover .nav_sub_menu, a:focus + .nav_sub_menu { }

يعني هذا التعديل أنه يمكننا رؤية قائمتنا الفرعية عندما ننتقل إلى عنصر القائمة الأصلي على لوحة المفاتيح. ولكن ماذا يحدث عندما تحاول التنقل في القائمة الفرعية؟

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

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

 li:hover .nav_sub_menu, /* hover over parent menu item, show child menu */ a:focus + .nav_sub_menu, /* focus onto parent menu item, show child menu */ .nav_sub_menu:focus-within { /* focus onto child menu item, keep showing child menu */ }

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

في الواقع ، قد تكون القائمة التي تعتمد على JS أفضل صيحة في هذه الحالة ، لأن دعم المتصفح لهذا الحل لا يزال ضعيفًا للغاية. :focus-within حاليًا في Chrome و Firefox و Safari فقط. حتى في Chrome ، وجدت أنه غير متوافق مع display: none منطق لإظهار / إخفاء القائمة الفرعية ؛ اضطررت إلى إخفاء عناصر القائمة الخاصة بي عن طريق تعيين opacity: 0 بدلاً من ذلك.

حسنًا ، لقد انتهيت من هذا اليوم. حان الوقت الآن للاسترخاء مع القليل من وسائل التواصل الاجتماعي.

فيسبوك

يقوم Facebook بعمل لا يُصدق هنا ، حيث يوفر درسًا رئيسيًا في إمكانية الوصول إلى لوحة المفاتيح.

في أول ضغط على مفتاح TAB ، تفتح قائمة مخفية توفر اختصارات للأقسام الأكثر شيوعًا في الصفحة الحالية وروابط لصفحات شائعة أخرى.

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

الميزة الأكثر فائدة هي أن Facebook يوفر اختصار OPT + / (أو ALT + / ) للرجوع إلى القائمة في أي وقت ، مع الاستفادة من سمة aria-keyshortcuts.

 <div class="a11y-help"> Press opt + / to open this menu </div> <div aria-label="Navigation Assistant" aria-keyshortcuts="Alt+/" role="menubar"> <a class="screen-reader-shortcut" tabindex="1" href="#main-content"> Skip to main content </a> </div>

بخلاف رابط "التخطي إلى المحتوى الرئيسي" ، المبني على تقنية التثبيت الأصلية و "يعمل فقط" ، تتطلب سمة aria-keyshortcuts من المؤلف تنفيذ كل سلوك لوحة المفاتيح ، لذلك عليك كتابة بعض جافا سكريبت مخصص إذا كنت تريد استخدام هذا.

إليك بعض JS الذي يخفي ويظهر منطقة menubar ، وهي نقطة بداية مفيدة:

 const a11yArea = document.querySelector('*[role="menubar"]'); document.addEventListener('keydown', (e) => { if (e.altKey && e.code === 'Slash') { a11yArea.style.display = a11yArea.style.display === 'block' ? 'none' : 'block'; } });

ملخص

كانت هذه التجربة عبارة عن مجموعة مختلطة من تجارب لوحة المفاتيح الرائعة والتجارب السيئة. لدي ثلاث وجبات رئيسية.

اجعلها أنيقة

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

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

الدلالات هي المفتاح

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

لنلقِ نظرة على هذا الرمز هنا:

 <span>Click here</span>

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

مستخدمو لوحة المفاتيح هم مستخدمون يعتمدون على المعايير ، في حين أن الديموغرافية القادرة والمبصرة تتمتع بامتيازات كافية لتكون قادرة على التفاعل مع العنصر على الرغم من عدم توافقه.

استخدم الميزات الأصلية للنظام الأساسي. اكتب HTML جيدًا ونظيفًا واستخدم أدوات التحقق مثل https://validator.w3.org لالتقاط أشياء مثل سمات href المفقودة على نقاط الارتساء الخاصة بك.

المحتوى هو المفتاح

قد يُطلب منك عرض إشعارات ملفات تعريف الارتباط أو نماذج الاشتراك أو الإعلانات أو إشعارات حظر الإعلانات.

افعل ما بوسعك لجعل هذه التجارب غير مزعجة. إذا لم تتمكن من جعلها غير مزعجة ، على الأقل اجعلها قابلة للرفض.

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

أخيرًا ، ادعم المستخدمين في الوصول إلى المحتوى الخاص بك بأسرع ما يمكن ، من خلال تطبيق الكأس المقدسة المتمثلة في روابط "تخطي إلى المحتوى الرئيسي".

ترقبوا المقالة التالية في السلسلة ، حيث سأبني على بعض هذه الأساليب عندما أستخدم قارئ الشاشة ليوم واحد.