تصميم حقل البحث (Search Box): أفضل ممارسات تجربة المستخدم وإمكانية الوصول

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

والخطأ الأخير منها منتشر حتى في مواقع كبيرة. ففي قياس نشره Baymard Institute عام 2021 على مواقع التجارة الإلكترونية، كانت 33% من المواقع تمسح الاستعلام بعد إرساله في نسخها للحاسوب، و42% منها في نسخها للهاتف، مع أن المشاركين في اختبارات المعهد عدلوا استعلاماتهم 2.2 مرة في المتوسط أثناء البحث.

أين يوضع حقل البحث: حقل ظاهر لا أيقونة وحدها

أول ما يحتاجه المستخدم أن يجد الحقل. ويصف Jakob Nielsen، أحد مؤسسي Nielsen Norman Group (وتختصر NN/g)، سلوك من يريد البحث بأنه يتفحص الصفحة بعينه ليجد «المربع الصغير الذي يكتب فيه». ولهذا توصي NN/g بأن يكون البحث حقلا نصيا مفتوحا، لا رابطا ينقل إلى صفحة بحث مستقلة. وفي تجربة رواها عام 2001، غير Nielsen موقعه useit.com من رابط بحث إلى حقل بحث، فارتفع استعمال البحث فيه بنسبة 91%.

وتوصي NN/g كذلك بأن يوضع الحقل في رأس الصفحة، وأن يظهر في كل صفحة من الموقع لا في الصفحة الرئيسية وحدها. والموضع الذي يتوقعه المستخدم في المواقع الإنجليزية هو الزاوية العليا اليمنى، مع أن NN/g وجدت أن الجهة اليسرى تنجح أيضا. أما الواجهات العربية فتكتب من اليمين إلى اليسار (RTL)، وتنص إرشادات Mozilla لهذه الواجهات على أن ترتيب عناصرها يعكس ترتيب الواجهات الإنجليزية، وأن الأيقونة داخل الحقل تنتقل إلى جهته الأخرى. ولذلك يصبح الموضع المتوقع فيها هو الزاوية العليا اليسرى. والثابت في الحالتين أن يبقى الحقل في رأس الصفحة، لأنه أول موضع ينظر إليه المستخدم حين يريد البحث.

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

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

وإن استعملت الأيقونة وحدها، فاجعل النقر عليها يفتح الحقل بجوارها مباشرة وينقل المؤشر إليه في الخطوة نفسها، فتظهر لوحة المفاتيح دون نقرة إضافية. وبين الحلين حل وسط هو الحقل القابل للتمدد (expandable search): حقل ظاهر لكنه قصير، يتسع حين ينقر عليه المستخدم، فيوفر المساحة دون أن يختفي البحث عن النظر.

والعدسة المكبرة رمز يعرفه أغلب المستخدمين. ولكي يلاحظوها بسرعة، توصي NN/g بأن تكون مبسطة الرسم لا مفصلة، وكبيرة وحولها مساحة نقر مريحة، وبتباين واضح مع ما حولها.

عرض حقل البحث: 27 حرفا على الأقل

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

وأسهل طريقة لتطبيق هذه التوصية في CSS هي وحدة ch، وتساوي عرض الرقم «0» في الخط المستعمل. فالقاعدة width: 27ch تجعل الحقل يتسع لنحو 27 حرفا من خطه، وإضافة max-width: 100% تمنعه من تجاوز عرض الشاشة على الهاتف. والنتيجة تقريبية، لأن عرض الحروف في أغلب الخطوط، والعربية منها خاصة، يتفاوت من حرف إلى آخر، لكنها تبقى نقطة بداية أدق من عرض ثابت بالبكسل لا علاقة له بحجم الخط.

التسمية والنص المؤقت (Placeholder)

النص المؤقت (placeholder) هو التلميح الرمادي الذي يظهر داخل الحقل الفارغ ويختفي حين يبدأ المستخدم الكتابة. وقد وجدت NN/g أنه يضر النماذج (forms) حين يحل محل التسمية (label)، لأسباب منها أن التعليمات تختفي في اللحظة التي يحتاجها المستخدم، وأن لونه الباهت يضعف قراءته، وأن قارئات الشاشة (screen readers) لا تنطقه في كل الحالات.

وحقل البحث مستثنى جزئيا من هذا الحكم، لأنه حقل واحد مألوف لا يحتاج المستخدم أن يتذكر تعليماته. لكن الاستثناء يخص عبء الذاكرة فقط، ولا يعفي الحقل من اسم يسمعه مستخدم قارئ الشاشة. فإن لم يكن للحقل تسمية ظاهرة، فزر «بحث» المجاور له يؤدي وظيفة التسمية بصريا، وهذه الممارسة تقنية معتمدة في إرشادات WCAG تحمل الرمز G167. لكن الحقل يبقى محتاجا مع ذلك إلى اسم برمجي (accessible name) يقرؤه قارئ الشاشة، ويعطى له عبر الخاصية aria-label. وإن كان الزر أيقونة بلا نص، فهو أيضا يحتاج اسما برمجيا عبر aria-label يقول «بحث».

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

إرسال الاستعلام ومسحه

يتوقع المستخدم أن يرسل استعلامه بطريقتين: بضغط Enter، أو بالنقر على زر البحث. وتوصي NN/g بدعم الطريقتين معا، لأن بعض المستخدمين يكمل بلوحة المفاتيح وبعضهم ينتقل إلى الفأرة. والطريقتان تعملان تلقائيا حين يكون الحقل داخل عنصر <form> وفيه زر من نوع submit، دون سطر JavaScript واحد.

وزر البحث هدف للنقر، فيجب أن يكون بحجم يصيبه الإصبع بسهولة. والحد الأدنى في WCAG 2.2 (المعيار 2.5.8) هو 24×24 بكسل CSS، وهو حد أدنى للقبول لا مقاس موصى به؛ فعلى شاشات اللمس يحسن أن يكون الزر أكبر من ذلك بوضوح.

أما مسح الاستعلام فيوفره الحقل من نوع type="search" جزئيا: فبعض المتصفحات تعرض داخله علامة × تمسح النص بنقرة واحدة، وفي Chrome يمسحه مفتاح Esc أيضا. وإن صممت زر مسح خاصا بك، فأبق المؤشر داخل الحقل بعد المسح، لأن من يمسح استعلامه يريد في الغالب أن يكتب غيره فورا.

الاقتراحات التلقائية (Autocomplete)

الاقتراحات التلقائية هي القائمة التي تظهر تحت الحقل أثناء الكتابة، وتعرض استعلامات مكتملة يستطيع المستخدم اختيار أحدها. وهي منتشرة في 80% من مواقع التجارة الإلكترونية التي قاستها Baymard، لكن 19% فقط من المواقع طبقت كل الممارسات الجيدة في تصميمها.

وظيفتها الحقيقية: استعلام أفضل

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

وتؤكد NN/g هذا من زاوية أخرى. ففي دراستها لم يختر المستخدمون اقتراحا إلا في 23% من المرات التي عرضت فيها الاقتراحات عليهم، لكنهم قرؤوها ليتأكدوا من الإملاء، وليعرفوا ما الذي يقدمه الموقع. فجودة القائمة لا تقاس بعدد النقرات عليها وحده.

عدد الاقتراحات وطول القائمة

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

ماذا تبرز بالخط العريض

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

• تصميم قواعد البيانات
• تصميم واجهات المستخدم
• تصميم الشعارات

وحين يضيف الاقتراح كلمات قبل ما كتبه المستخدم أيضا، لا بعده فقط، توصي NN/g بالعكس: أن يبرز ما كتبه المستخدم، ليعرف أين وقع التطابق داخل الاقتراح.

الأخطاء الإملائية

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

والعلاج أن يربط الموقع الكلمات المكتوبة خطأ بصيغتها الصحيحة، فيقترح الصحيحة حين تكتب الخاطئة. ولهذا الربط طريقان: أداة تدقيق إملائي في محرك البحث، أو مراجعة سجلات البحث (search logs) لمعرفة الأخطاء التي يكررها المستخدمون فعلا وربطها يدويا.

وفي المواقع العربية نوع آخر من الاختلاف لا يعد خطأ أصلا: صيغ متعددة للكلمة الواحدة يكتبها الناس كلها. فمن يكتب «اسلام» ومن يكتب «إسلام» يقصدان الشيء نفسه، وكذلك «مكتبة» و«مكتبه»، و«مستشفى» و«مستشفي»، والكلمة بتشكيلها وبغيره. ومكان حل هذه الحالة محرك البحث لا الواجهة: فمكتبة Lucene، التي تقوم عليها محركات مثل Elasticsearch وSolr، تقدم أداة لتوحيد الكتابة العربية (ArabicNormalizer) تحول صور الهمزة على الألف إلى ألف مجردة، والتاء المربوطة إلى هاء، والألف المقصورة إلى ياء، وتحذف الحركات والتطويل. وحين يمر النص المخزن والاستعلام بهذا التوحيد نفسه قبل المقارنة، يجد المستخدم ما يريد أيا كانت الصيغة التي كتب بها.

كل اقتراح يقود إلى نتائج

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

اقتراحات النطاق

في المواقع ذات الأقسام الكثيرة، قد يقترح الموقع الاستعلام نفسه داخل قسم محدد، مثل «حقيبة ظهر في قسم السفر». وتوصي Baymard وNN/g بتمييز هذه الاقتراحات بصريا عن الاقتراحات العامة، بلون أفتح أو خط مائل أو إزاحة إلى الداخل، حتى يعرف المستخدم أن اختيارها سيحصر البحث في قسم واحد، مع إبقاء خيار البحث في الموقع كله أمامه.

الاقتراحات الغنية بالصور والمنتجات

بعض المواقع تعرض داخل القائمة صورا ومنتجات وأسعارا إلى جانب الاستعلامات النصية. ووجدت NN/g في دراسة نشرتها عام 2022 أن المستخدمين لم يستعملوا هذه الاقتراحات الغنية إلا 7 مرات من أصل 60 مرة ظهرت فيها. ومن الأسباب التي فسرت بها ذلك أن الصور تتأخر في التحميل، فيرسل المستخدم استعلامه قبل ظهورها. ومنها أن تركيز المستخدم يبقى على الحقل، فيتجاهل ما يشبه الإعلانات، وهي الظاهرة المعروفة بعمى الإعلانات (banner blindness). ومنها أنه قد يفهم هذه الاقتراحات على أنها ترويج لمنتجات لا نتائج لبحثه. ولهذا تبقى الاقتراحات النصية البسيطة هي الأساس، وعلى الهاتف تختصر الاقتراحات الغنية إلى نص فقط.

عمليات البحث السابقة

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

التنقل بلوحة المفاتيح

يجب أن تعمل القائمة بلوحة المفاتيح كما تعمل بالفأرة: فالسهمان للأعلى والأسفل ينقلان بين الاقتراحات، وEnter يرسل الاقتراح المحدد، وEsc يغلق القائمة. وتضيف Baymard تفصيلين: أن تدور القائمة، فينتقل السهم من آخرها إلى أولها؛ وأن ينسخ الاقتراح المحدد إلى الحقل عند الوصول إليه بالأسهم، فيستطيع المستخدم تعديله قبل الإرسال بدل أن يقبله كما هو.

بعد إرسال الاستعلام

احتفظ بالاستعلام في الحقل

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

وإلى جانب الحقل، توصي Baymard بعرض الاستعلام في رأس صفحة النتائج، في عنوان أو ضمن مسار التنقل (breadcrumbs)، ليعرف المستخدم بوضوح مصدر النتائج التي أمامه.

ابحث في الموقع كله افتراضيا

البحث المحصور (scoped search) بحث يقتصر على جزء من الموقع، كقسم الأخبار وحده أو فئة منتجات واحدة. وهو يسرع الوصول إلى النتيجة حين يعرف المستخدم أين يبحث، لكن NN/g تعده خطرا حين لا ينتبه المستخدم إلى أن بحثه محصور: فهو لا يجد ما يريد، فيستنتج أنه غير موجود في الموقع أصلا.

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

أعلن عدد النتائج لقارئ الشاشة

حين تتجدد النتائج في الصفحة نفسها دون تحميل صفحة جديدة، يرى المستخدم المبصر عبارة مثل «12 نتيجة» فورا. أما مستخدم قارئ الشاشة فلا يعلم بها، لأن التركيز لم ينتقل إليها. ويعالج معيار WCAG رقم 4.1.3 (رسائل الحالة) هذه الحالة تحديدا، ويضرب بنتائج البحث مثلا عليها: توضع العبارة داخل عنصر يحمل role="status"، فيعلنها قارئ الشاشة دون أن يقطع ما يفعله المستخدم، ودون أن ينقل تركيزه من مكانه.

صفحة «لا توجد نتائج»

أصعب لحظة في رحلة البحث هي الصفحة الفارغة. فقد لاحظ Jakob Nielsen منذ دراساته المبكرة أن أغلب المستخدمين إذا لم يجدوا نتائج استنتجوا أن المعلومة غير موجودة في الموقع، لا أن استعلامهم يحتاج تعديلا. ووجدت Baymard أن 68% من مواقع التجارة الإلكترونية تجعل هذه الصفحة طريقا مسدودا لا تقدم فيه أكثر من نصائح عامة للبحث، وأن بعض المشاركين في اختباراتها غادروا الموقع عندها.

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

البحث أثناء الكتابة: التوقيت وتضارب الردود

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

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

وتبقى بعد ذلك مشكلة أقل وضوحا هي تضارب الردود (race condition). فالطلبات لا تعود بالضرورة بترتيب إرسالها: قد يرسل طلب للنص «تص» ثم طلب للنص «تصميم»، فيعود الثاني أولا، ثم يصل الأول متأخرا ويستبدل الاقتراحات الصحيحة باقتراحات لنص لم يعد في الحقل. والعلاج أن يلغى الطلب السابق قبل إرسال الجديد، وهذا ما توفره واجهة AbortController في المتصفح.

ويجمع الكود التالي الأمرين: ينتظر 200 ملي ثانية بعد آخر ضغطة، ثم يلغي أي طلب سابق لم يكتمل قبل أن يرسل الطلب الجديد.

const input = document.querySelector('#site-search');
let timer;
let controller;

input.addEventListener('input', () => {
  clearTimeout(timer);
  timer = setTimeout(async () => {
    const query = input.value.trim();
    controller?.abort(); // cancel the previous, now stale request
    if (!query) return;

    controller = new AbortController();
    try {
      const res = await fetch(`/api/suggest?q=${encodeURIComponent(query)}`, {
        signal: controller.signal,
      });
      if (!res.ok) return;
      renderSuggestions(await res.json());
    } catch (err) {
      if (err.name !== 'AbortError') throw err;
    }
  }, 200);
});

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

حقل البحث على الهاتف

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

• مفتاح البحث في لوحة المفاتيح. الخاصية enterkeyhint="search" تطلب من لوحة المفاتيح الافتراضية أن تعرض كلمة «بحث» أو أيقونة عدسة على مفتاح الإدخال، فيعرف المستخدم أن الضغط عليه سيرسل الاستعلام. والخاصية مدعومة في المتصفحات الرئيسية منذ نوفمبر 2021.
• حجم خط لا يقل عن 16 بكسل. يكبر متصفح Safari على iOS الصفحة تلقائيا حين ينقر المستخدم على حقل حجم خطه أقل من 16 بكسل، فتنزاح الواجهة ويحتاج المستخدم إلى تصغيرها بيده. والعلاج أن يكون خط الحقل 16 بكسل أو أكثر، لا منع التكبير عبر user-scalable=no، لأن منعه يحرم ضعاف البصر من تكبير الصفحة حين يحتاجون إليه.
• مسافات أوسع في القائمة. توصي Baymard على الهاتف بخط كبير في الاقتراحات، ومسافات واضحة بين أسطرها، ومساحة نقر كافية لكل سطر، حتى لا يصيب الإصبع الاقتراح المجاور.

بنية حقل البحث في HTML وإمكانية الوصول

الهيكل الأساسي

جزء كبير مما سبق توفره عناصر HTML نفسها إذا استعملت في موضعها الصحيح. وهذا هيكل حقل بحث في ترويسة موقع:

<header>
  <search>
    <form action="/search" method="get">
      <input type="search" id="site-search" name="q"
             aria-label="Search articles and lessons"
             placeholder="Search articles and lessons"
             enterkeyhint="search">
      <button type="submit" aria-label="Search">
        <svg aria-hidden="true" focusable="false"><!-- magnifying-glass icon --></svg>
      </button>
    </form>
  </search>
</header>

ولكل جزء في هذا الهيكل وظيفة من القواعد السابقة:

• العنصر <search> يجعل منطقة البحث معلما (landmark) في شجرة إمكانية الوصول (accessibility tree)، فيستطيع مستخدم قارئ الشاشة القفز إليها مباشرة من قائمة معالم الصفحة. وهو يغني عن كتابة role="search" على النموذج، ومدعوم في المتصفحات الرئيسية منذ أواخر 2023. وإن كان في الصفحة أكثر من منطقة بحث، كبحث الموقع في الترويسة وبحث داخل قائمة منتجات، فأعط كل منطقة اسما وصفيا عبر aria-label يميزها عن الأخرى.
• الحقل من نوع type="search" يأخذ عند قارئات الشاشة دور حقل البحث (searchbox)، ويعرض في بعض المتصفحات زر المسح ويستجيب لمفتاح Esc.
• الخاصية aria-label تعطي الحقل اسما يسمعه مستخدم قارئ الشاشة، لأن الحقل هنا بلا تسمية ظاهرة، والنص المؤقت لا يعتمد عليه اسما.
• الزر من نوع submit يرسل النموذج بالنقر، وضغط Enter داخل الحقل يرسله كذلك. والأيقونة مخفية عن قارئ الشاشة بالخاصية aria-hidden="true"، لأن اسم الزر يأتي من aria-label الخاص به.

وتحفظ المتصفحات ما يكتبه المستخدم في حقول البحث، ثم تعرضه في قائمة خاصة بها عند البحث التالي في الموقع نفسه. فإن بنيت قائمة اقتراحات خاصة بك، فأضف autocomplete="off" إلى الحقل، حتى لا تتراكب القائمتان.

نمط combobox حين تضيف قائمة اقتراحات

الحقل الذي تظهر تحته قائمة اقتراحات لم يعد حقلا نصيا بسيطا في نظر قارئ الشاشة. إنه ما تسميه إرشادات ARIA «combobox»، أي حقل نصي مرتبط بقائمة منبثقة من الخيارات. وأهم ما في هذا النمط أن التركيز الفعلي يبقى داخل الحقل طوال الوقت، لأن المستخدم يحتاج أن يواصل الكتابة وهو يتنقل بين الاقتراحات. فالسهم لا ينقل التركيز إلى الاقتراح نفسه، بل ينقل تركيزا افتراضيا تشير إليه الخاصية aria-activedescendant، فيقرأ قارئ الشاشة الاقتراح المحدد بينما يبقى المؤشر في الحقل.

وهذه هي الخصائص التي يضيفها النمط إلى الحقل والقائمة، مع بقاء خصائص الحقل الأخرى من المثال السابق:

<input type="search" id="site-search" name="q"
       role="combobox"
       aria-autocomplete="list"
       aria-expanded="true"
       aria-controls="search-suggestions"
       aria-activedescendant="suggestion-2">

<ul id="search-suggestions" role="listbox" aria-label="Search suggestions">
  <li id="suggestion-1" role="option">design patterns</li>
  <li id="suggestion-2" role="option" aria-selected="true">design systems</li>
</ul>

• role="combobox" يعلن أن الحقل مرتبط بقائمة خيارات.
• aria-expanded يخبر بحالة القائمة: true حين تكون مفتوحة وfalse حين تكون مغلقة، ويجب أن تتغير قيمته مع كل فتح وإغلاق.
• aria-controls يربط الحقل بالقائمة عبر معرفها.
• aria-autocomplete="list" يوضح أن الاقتراحات تظهر في قائمة منفصلة، ولا تكمل النص داخل الحقل نفسه.
• aria-activedescendant يحمل معرف الاقتراح المحدد حاليا، ويتغير مع كل ضغطة سهم، ويفرغ حين لا يكون أي اقتراح محددا.
• وعلى القائمة role="listbox"، وعلى كل اقتراح role="option"، ويحمل الاقتراح المحدد aria-selected="true".

وأقرب نقطة بداية موثوقة لبناء هذا النمط هي المثال العملي الذي تنشره W3C باسم «Editable Combobox With List Autocomplete»، لأنه يطبق الخصائص والتفاعل الكامل بلوحة المفاتيح معا.

[صورة مقترحة: رسم يوضح الحقل والقائمة المنبثقة تحته، والمؤشر باق داخل الحقل، وسهم من الخاصية aria-activedescendant يشير إلى الاقتراح المحدد في القائمة]

اختصار لوحة المفاتيح

تتيح بعض المواقع مفتاحا واحدا ينقل التركيز إلى حقل البحث من أي مكان في الصفحة، ومنها GitHub الذي يستعمل المفتاحين S و/ لهذا الغرض. والاختصار مفيد لمن يعمل بلوحة المفاتيح، لكن الاختصار المكون من حرف واحد له كلفة على فئتين. فمستخدمو الإدخال الصوتي (speech input) يتحدثون إلى الجهاز فيحول كلامهم إلى ضغطات مفاتيح، فإذا لم يكن التركيز في حقل نصي، أطلقت الحروف التي في كلامهم الاختصار دون قصد. ومن يصعب عليه التحكم في حركة يده قد يضغط مفتاح الاختصار خطأ.

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

لماذا تستحق المحاولة الأولى هذا الاهتمام

في بيانات نشرها Jakob Nielsen عام 2001، نجح المستخدمون في 51% من استعلاماتهم الأولى، ثم انخفضت نسبة النجاح إلى 32% في الاستعلام الثاني، وإلى 18% في الثالث. والأرقام قديمة، ومحركات البحث تحسنت كثيرا منذ ذلك الحين، لكن الاتجاه الذي تكشفه يتفق مع ملاحظة أقدم لـNielsen نفسه: أغلب المستخدمين لم يتعلموا تشخيص سبب فشل الاستعلام، ولذلك يضعف أداؤهم في إعادة صياغته، فتقل فرصة كل محاولة جديدة عن التي قبلها.

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