تحطيم بودكاست الحلقة 4 مع Heydon Pickering: ما هي المكونات الشاملة؟

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

وتظهر الملاحظات

• كتاب مكونات شاملة من مجلة Smashing
• مشروع Heydon Every Layout مع Andy Bell
• موقع Heydon على الويب Heydonworks
• هايدون على تويتر

نسخة طبق الأصل

درو ماكليلان: هو مستشار مستقل لإمكانية الوصول إلى الويب ومصمم واجهات وكاتب. يركز عمله على تصميم تجربة المستخدم التي يمكن الوصول إليها ، بالإضافة إلى الكتابة والتحرير لمجلة Smashing Magazine. إنه مؤلف الكتاب المشهود حول تصميم تطبيقات الويب التي يمكن الوصول إليها ، Apps For All ، وقد أصدر للتو كتابًا جديدًا ، Inclusive Components ، كل شيء عن كيفية إنشاء واجهات ويب يمكن الوصول إليها ، مرة أخرى ، مع Smashing Magazine. من الواضح أنه خبير في موضوع التصميم الذي يمكن الوصول إليه ، لكن هل تعلم أنه كان أول رجل يقفز على جسر ميناء سيدني في قارب سريع؟ أصدقائي المحطمون ، من فضلكم رحبوا بهيدون بيكرينغ. مرحبًا يا هيدون. كيف حالك؟

هايدون بيكرينغ: أنا محطمة. أنا على العلامة التجارية.

درو: أردت أن أتحدث إليكم اليوم عن موضوع كتابك الجديد ، المكونات الشاملة.

هايدون: نعم.

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

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

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

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

هايدون: إذن كانت الفكرة هي توفير إمكانية الوصول إلى أنظمة التصميم ، ولكن على نفس المنوال ، فكر بشكل منهجي عندما يتعلق الأمر بمحاولة معالجة إمكانية الوصول. فكر في حل مشكلة واحدة في مكان واحد فيما يتعلق بإمكانية الوصول والتأكد من أنه ينتشر ببساطة حول النمط [غير مسموع 00:03:16] نظام التصميم ككل.

درو: بمعنى عملي ، كيف يبدو العمل بطريقة قائمة على المكون؟ ماذا يمكن أن يكون مثال للمكون؟

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

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

درو: أعني ، من الناحية العملية الفعلية ، أننا نتحدث عن مكون قد يكون شيئًا مثل حقل النموذج؟

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

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

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

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

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

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

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

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

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

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

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

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

درو: هل من الممكن اتباع نهج حسابي أو آلي بالكامل للتصميم من أجل إمكانية الوصول؟

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

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

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

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

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

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

هايدون: نعم.

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

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

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

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

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

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

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

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

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

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

درو: هل يمكن أن يكون المكون شاملاً بشكل كامل أم أنه طيف تعمل فيه أكثر من أي وقت مضى نحو الشمولية؟

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

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

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

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

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

درو: صحيح.

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

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

درو: إذن الكتاب نفسه ، كيف قررت كيفية تنظيمه؟ يبدو عمليًا للغاية ، وهو ما أحبه في كتاب ما ، لكن كيف بنيته؟

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

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

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

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

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

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

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

هايدون: أوه ، عظيم. كان هذا ما كنت أسعى إليه. لذلك هذا جيد. لكن نعم ، يبدو أن هذا هو الشيء الخاص بي. I mean, I've been working with the BBC for some months and we've kind of made a thing a bit like Inclusive Components but for the BBC, so we've done this sort of technical implementation with a through the lens of accessibility version of their design language called GEL. And yeah, it explains the why as well as the how and it's not a pattern, really. The idea is that the individual departments at the BBC, because there's so many of them, because it's such a large organization, so there'll be BBC Sport, BBC Weather, BBC News, they're the ones who would be taking care of the kind of technical stack and making their pattern library. And what we've really provided is just, we've just tried to exemplify the best practices. So it was really much more of a learning resource than a simple plug and play pattern library. نعم.

Drew: Was it difficult deciding what patterns to include in the book? Was there anything that you left out?

Heydon: The only ones I really had problems with or second thoughts about were the ones where, the tab interface, for instance, I wasn't going to include, because I really hate tab interfaces, but then I had folks saying, “Could you please do a tab interface? Could you include a chapter of that?” Because I get asked to put them in my interface all the time by clients or whoever. So, I ended up doing one. But it's full of caveats. And the main caveat is, probably don't use a tab interface. Use maybe an accordion, it's a simpler interaction paradigm. It's easier to make responsive, it's easier to make compatible with screen readers, et cetera, et cetera.

Heydon: So I put all those caveats in. But yeah, and some of them were ones where I just thought, “Oh, I haven't written about this before and I could do with having sort of thought about it so that I could actually use it in my design work.” And others were people requesting, saying, “I know this is a gnarly one, I just don't know how to go about it. Could you give it a go?” And so I gave it a go as best as I could. That is going to be the last time I write a book about accessibility because I've done three now.

Heydon: So if anyone wants to know any more and if they think of any other components that they might want doing, just DM me on Twitter or something and I'll try and deal with it in that way rather than writing a whole article, because those articles are quite long and they take up quite a lot of time and I'm kind of doing other things at the moment. But I'm always happy to chat with anyone who has any questions about this stuff. They might be working on something similar to what I've covered and there was just something that they were unsure about or which I, for whatever reason, I hadn't made as clear as they'd liked it. Yeah, then just contact me because I'm always happy to talk about the stuff because it helps me to sort of ruminate over things and try to, it might challenge my assumptions and help me to do a better job as well.

Drew: So, the book, Inclusive Components, is available right now from Smashing Magazine, smashingmagazine.com/books, and I'd recommend everybody check it out.

Heydon: Thank you.

Drew: So I always like to ask people, I mean, Smashing is all about learning, right, with the books, the conferences, the magazine, we're all about learning. What is it that you've been learning lately?

Heydon: So, recently, well, a couple of years ago I made something, I made a drum machine using the web audio API called Beads and it's still available as a PWA, it's a progressive web app. If you Google search Beads GitHub or something like that, you should get the GitHub page which has it on there. But that was a alpha version and I'm now working on doing a much more advanced version of this. And it's a different kind of drum machine because it's polymetric, it has different, you can have different tracks of different lengths. So you can have a track which has seven beats and a track which has nine beats, a track which has four beats. And then, the rhythm evolves over time because of the changing syncopation. You've got these, it's multi-threaded.

Heydon: That was the main reason that I wanted to build it, because, as someone who's interested in kind of experimental music, that's something I wanted to play with. Obviously, I'm trying to make this drum machine as accessible as possible. And that's been interesting from the point of view now that I'm working with, I'm turning it into an Electron app. So, for those of you that know Electron allows you to kind of wrap a sandbox version of Chromium browser and create a desktop application but using web technology, which was really great because it makes things, for this projects anyways, because it gets around a lot of performance problems.

Heydon: But also, although I've been doing cross browser testing for 12 years now, it's really nice to have a break and just to design stuff for one browser. And it's got some, so there's a flag in Chromium. It's a, what's it called, an experimental web platform feature for focus visible. So I've been able to make this drum machine completely keyboard accessible with these really nice, big focus outlines without those appearing for mouse users, because focus visible uses this heuristic where it detects whether or not you're using a keyboard. So that's been nice, to be able to incorporate that.

Heydon: But the thing recently that I've been learning about, just I've, I guess, been learning about some of the more advanced things you can do with the web audio API itself. So I had this problem where I have, you can put multiple sounds on one track so you can load in an array of audio files and it places them one after the other, and by default they overlap, so they'll always play out out, the audio buffer will play until it finishes. So if the next sounds comes before the end of that, it just overlaps, which is fine. It's kind of like a reverb or something. But sometimes if you're doing an arpeggio, like a baseline or something, you don't want them to open up. That's not how a bass guitar works, right? If you're on the same string, you press the next note, the first one has to finish.

Heydon: So, I was stopping a note as the next one started and there was always an audible popping sound and it's not the web audio API having a problem or anything like that. It's just the human ear will hear a kind of a nasty popping sound where you kind of sever away from. You just cut it, stop it dead, it's going to sound nasty. And then, so I found that there's a function as part of the web audio API, which allows you to choose a point where you can taper off the sound. And so I was able to detect where the sounds should end because the other sound is beginning, then taper it off very quickly, but it is a taper, like a fade out, rather than a hard cut off thing.

Heydon: So I solved that problem after it annoying me for ages. So it's basically been web audio API stuff and messing around with sounds because I've always been into, as I say, into experimental music and messing about with that sort of stuff. And I'm trying to write a talk about this. And in the talk, I'm using Billy Jean by Michael Jackson because it's a very straight, fall to the floor rhythm and I'm going to kind of warp it in various different ways. So I've actually had to learn the parts for Billy Jean to kind of sequence that and stuff. So, weirdly enough, that was what I was doing before doing this podcast.

Drew: That sounds like a lot of fun. So if you, dear listener, would like to learn more about Heydon or hire him to consult on your projects, you can follow him on Twitter, where he's @heydonworks, or visit his website at heydonworks.com. Thanks for joining us, Heydon. Do you have any parting words?

Heydon: Goodbye.