جيد ، أفضل ، أفضل: فك تشابك العالم المعقد للأنماط التي يمكن الوصول إليها

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

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

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

ما تشابك نحن نسج

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

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

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

كيف لى أن أعرف ذلك؟ حسنًا ، لقد أمضيت السنوات الخمس الماضية في البحث وبناء واختبار أنواع مختلفة من الأنماط التي يمكن الوصول إليها أثناء العمل على دليل نمط A11y ومكتبة Deque's ARIA Pattern Library وتقييم أنماط SVG الشائعة. لكنني قمت أيضًا بمراجعة العديد من أنماط العميل والمكتبات على كل إطار عمل / نظام أساسي يمكن تخيله. في هذه المرحلة من الوقت ، يمكنني القول دون قلق أن هناك تسلسلًا هرميًا فطريًا لإمكانية الوصول إلى النمط يبدأ في التطور عندما تبدو طويلاً بما يكفي. وبينما توجد أحيانًا أنماط يجب تجنبها بأي ثمن ، فهي ليست دائمًا واضحة تمامًا. عندما يتعلق الأمر بإمكانية الوصول ، سأجادل بأن معظم الأنماط تقع في تدرجات جيدة ، وأفضل ، وأفضل. الجزء الصعب هو معرفة النمط الذي ينتمي إلى أي فئة.

التفكير النقدي في الأنماط

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

• هل يوجد بالفعل نمط ثابت يمكن الوصول إليه يمكننا استخدامه؟
• ما المتصفحات وأجهزة التكنولوجيا المساعدة (AT) التي ندعمها؟
• هل هناك أي قيود إطار عمل أو تكاملات / عوامل أخرى يجب مراعاتها؟

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

هل يوجد بالفعل نمط ثابت يمكن الوصول إليه؟

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

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

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

ملاحظة : تتضمن بعض المصادر الرائعة ذات السمعة الطيبة المكونات الشاملة ، والمكونات التي يمكن الوصول إليها ، ونظام تصميم Gov.UK ، بالإضافة إلى قائمة الأنماط التي يمكن الوصول إليها والتي تم نشرها مؤخرًا من Smashing Magazine (بالإضافة إلى قائمة أكثر تفصيلاً للأنماط والمكتبات في نهاية المقالة) .

ما المتصفحات وأجهزة التكنولوجيا المساعدة (AT) التي ندعمها؟

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

لكنها ليست كلها أخبار سيئة. هناك بعض الموارد الرائعة مثل HTML5 Accessibility and Accessibility Support التي تساعدنا في بناء فهم أكبر للمتصفح الحالي ودعم جهاز AT. تحدد مواقع الويب هذه العناصر الفرعية المختلفة لنمط HTML و ARIA المتاحة ، وتشمل اختبارات مجتمع المصدر المفتوح ، وتوفر بعض الأمثلة على الأنماط - لكل من متصفحات سطح المكتب والأجهزة المحمولة / أجهزة AT.

هل هناك أي قيود على الإطار أو تكاملات / عوامل أخرى يجب مراعاتها؟

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

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

تقييم الأنماط من أجل الوصول

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

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

أنماط زر يمكن الوصول إليها

المجموعة الأولى من الأنماط التي سنراجعها لإمكانية الوصول موجودة في كل مكان تقريبًا في كل موقع ويب أو تطبيق: الأزرار. يستخدم نمط الزر الأول دور زر ARIA لتقليد الزر ، بينما يستخدم نمطا الزر الثاني والثالث عنصر <button> HTML. يضيف النمط الثالث أيضًا aria-describedby و CSS لإخفاء الأشياء بصريًا.

جيد: role="button"

 <a role="button" href="[link]">Sign up</a>

أفضل: <button>

 <button type="button">Sign up</button>

الأفضل: <button> + visually hidden + aria-describedby

 <button type="button">Sign up</button> <span class="visually-hidden"> for our monthly newsletter</span>

بينما تبدو الأنماط الأولى بسيطة للوهلة الأولى ، إلا أنها تثير بعض الأسئلة المتعلقة بإمكانية الوصول. على سبيل المثال ، في نمط الزر الأول ، نرى role="button" يُستخدم في النمط "good" بدلاً من عنصر <button> HTML. بالنظر إلى إمكانية الوصول ، نظرًا لأننا نعلم أن عنصر <button> في HTML قد تم إدخاله في HTML4 ، يمكننا التكهن بشكل معقول بأنه مدعوم بالكامل بأحدث الإصدارات من جميع المتصفحات الرئيسية وسيلعب بشكل جيد مع معظم أجهزة AT. ولكن إذا بحثنا بشكل أعمق ونظرنا إلى دعم إمكانية الوصول لدور ARIA = "button" ، فإننا نرى ميزة طفيفة من منظور التكنولوجيا المساعدة ، بينما يفتقد عنصر <button> HTML بعض مناطق تغطية المتصفح + AT ، خاصة عندما نفكر في دعم التحكم الصوتي.

إذن لماذا لا يكون نمط ARIA في فئة "أفضل"؟ ألا تجعل ARIA أكثر سهولة في الوصول إليها؟ لا. في الواقع ، في مثل هذه الحالات ، غالبًا ما يسرد متخصصو إمكانية الوصول القاعدة الأولى لـ ARIA - لا تستخدم ARIA. هذه طريقة لسان الخد لقول استخدام عناصر HTML كلما أمكن ذلك. ARIA قوي حقًا ، لكن في الأيدي الخطأ ، يمكن أن يضر أكثر مما ينفع. في الواقع ، يشير تقرير WebAIM Million إلى أن "الصفحات التي تحتوي على ARIA بلغ متوسطها 60٪ أخطاء أكثر من الصفحات التي لا تحتوي على". على هذا النحو ، يجب أن تعرف ما الذي تفعله عند استخدام ARIA.

ضربة أخرى ضد استخدام ARIA في هذه الحالة هي أن وظيفة الزر التي نحتاجها يجب أن تُبنى لنمط role="button" ، في حين أن هذه الوظيفة مخبوزة مسبقًا في عنصر <button> . بالنظر إلى أن عنصر <button> يحتوي أيضًا على دعم متصفح بنسبة 100٪ وهو نمط سهل التنفيذ ، فإنه يتقدم قليلاً في التسلسل الهرمي عند تقييم النمطين الأولين. نأمل أن تساعد هذه المقارنة في تحطيم الأسطورة القائلة بأن إضافة ARIA تجعل الوصول إلى النمط أكثر سهولة - في كثير من الأحيان يكون العكس هو الصحيح.

يُظهر نمط الزر الثالث عنصر <button> في HTML مقترنًا بأسلوب aria-describedby مرتبطًا بعنصر معرف مخفي بصريًا باستخدام CSS. في حين أن هذا النمط أكثر تعقيدًا إلى حد ما ، إلا أنه يضيف الكثير من حيث السياق من خلال إنشاء علاقة بين الزر والغرض. عندما تكون في شك ، في أي وقت يمكننا إضافة المزيد من السياق إلى الموقف ، كان ذلك أفضل ، لذلك يمكننا أن نفترض أنه إذا تم ترميزه بشكل صحيح ، فهو أفضل نمط عند مقارنة أنماط الأزرار المحددة هذه فقط.

أنماط الارتباط السياقية التي يمكن الوصول إليها

المجموعة الثانية من الأنماط التي سنراجعها هي روابط سياقية. تساعد هذه الأنماط في توفير معلومات لمستخدمي AT أكثر مما هو مرئي على الشاشة. يستخدم نمط الارتباط الأول CSS لإخفاء المعلومات السياقية الإضافية بشكل مرئي. بينما يضيف نمطا الارتباط الثاني والثالث سمات ARIA إلى المزيج: aria-labelledby و aria-label ، على التوالي.

جيد: visually-hidden

 <p>“My mother always used to say: The older you get, the better you get, unless you're a banana.” — Rose (Betty White)<a href="[link]">Read More<span class="visually-hidden"> Golden Girl quotes</span></a></p>

أفضل: visually-hidden + aria-labelledby

 <p>“I'm either going to get ice cream or commit a felony...I'll decide in the car.” — Blanche (Rue McClanahan)<a href="[link]" aria-labelledby="quote">Read More</a><span class="visually-hidden">Read more Golden Girl quotes</span></p>

الأفضل: aria-label

 <p>“People waste their time pondering whether a glass is half empty or half full. Me, I just drink whatever's in the glass.” — Sophia (Estelle Getty)<a href="[link]" aria-label="Read more Golden Girls quotes">Read More</a></p>

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

يعد تقييم نمطي الارتباط التاليين أكثر صعوبة بعض الشيء. وفقًا لمواصفات ARIA من W3C "الغرض من aria-label هو نفس الغرض من تسمية aria-labelledby . يوفر للمستخدم اسمًا يمكن التعرف عليه للكائن ". لذلك ، من الناحية النظرية ، يجب أن يكون لكل من السمتين نفس الوظيفة الأساسية.

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

حسنًا ، ليس بهذه السرعة. تستمر مواصفات ARIA نفسها لتقول "إذا كانت الواجهة بحيث لا يمكن أن يكون لها ملصق مرئي على الشاشة (أو إذا كانت التسمية المرئية ليست تجربة المستخدم المرغوبة) ، يجب على المؤلفين استخدام aria-label ويجب عدم استخدام aria-labelledby . " تحدث عن الالتباس - فما النمط الذي يجب أن نختاره؟

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

استنادًا إلى توصيات ARIA 1.1 الحالية (مع الوعد بترجمة تسمية aria في ARIA 1.2) بالإضافة إلى حقيقة أن aria-label أسهل قليلاً بالنسبة للمطورين في التنفيذ مقابل aria-labelledby ، يمكننا أن نقرر ترجيح aria-label على aria-labelledby في تقييم النمط لدينا. هذا مثال واضح عندما يكون للسياق أهمية كبيرة في اختيار النمط الذي يمكننا الوصول إليه.

أنماط يمكن الوصول إليها <svg>

أخيرًا وليس آخرًا ، دعنا نتحرى عن مجموعة من أنماط صور SVG لإمكانية الوصول. SVGs هي تمثيل مرئي للكود ، لكنها مع ذلك رمز. هذا يعني أن جهاز AT قد يتخطى صورة SVG غير زخرفية إلا إذا تمت إضافة role="img" إلى النمط.

بافتراض أن أنماط SVG التالية معلوماتية بطبيعتها ، فقد تم تضمين role="img" في كل منها. يستخدم نمط SVG الأول <title> و <text> جنبًا إلى جنب مع CSS لإخفاء المحتوى بصريًا عن المستخدمين المبصرين. يشتمل نمطا SVG التاليان على عنصري <title> و <desc> ، ولكن مع إضافة سمة aria-labelledby إلى النمط الأخير.

جيد: role="img" + <title> + <text>

 <svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" x="0px" y="0px" viewBox="0 0 511.997 511.997" xml:space="preserve"> <title>The first little pig built a house out of straw.</title> <text class="visually-hidden">Sadly, he was eaten by the wolf.</text>... </svg>

الأفضل: role="img" + <title> + <desc>

 <svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" x="0px" y="0px" viewBox="0 0 511.997 511.997" xml:space="preserve"> <title>The second little pig built a house out of sticks.</title> <desc>Sadly, he too was eaten by the big, bad wolf.</desc>... </svg>

الأفضل: role="img" + <title> + <desc> + aria-labelledby="[id]"

 <svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" aria-labelledby="pig3house pig3wolf" x="0px" y="0px" viewBox="0 0 511.997 511.997" xml:space="preserve"> <title>The third little pig built a house out of bricks.</title> <desc>Thankfully he wasn't eaten by the wolf.</desc>... </svg>

دعنا أولاً نلقي نظرة على النمط الأول باستخدام <title> و <text> والمخفي بصريًا CSS. على عكس النص المخفي المرئي السابق في الأنماط ، هناك علاقة متأصلة بين عنصري <title> و <text> حيث تم تجميعهما تحت مظلة عنصر SVG نفسه. ومع ذلك ، فإن هذه العلاقة ليست قوية للغاية. في الواقع ، إذا نظرت إلى بحثي حول أنماط SVG ، فسنلاحظ أن 3 فقط من أصل 8 مجموعات من المستعرضات / AT قد سمعت الرسالة الكاملة. (ملاحظة: نمط الخنزير رقم 1 مكافئ لنمط المصباح الكهربائي رقم 7.)

هذا صحيح على الرغم من أن مواصفات W3C SVG العاملة تحدد عنصر <text> على أنه "عنصر رسومي يتكون من نص ... يتم التعبير عن الأحرف المراد رسمها كبيانات شخصية. نتيجة لذلك ، يمكن الوصول إلى البيانات النصية في محتوى SVG بسهولة للمكفوفين ". هذا النمط الأول جيد ، لكن يمكننا أن نفعل ما هو أفضل.

يزيل النمط الثاني عنصر <text> ويستبدله بعنصر <desc> . حالة مواصفات W3C SVG:

"يمثل العنصر <title> بديلًا نصيًا قصيرًا للعنصر ... ويمثل العنصر <desc> معلومات نصية أكثر تفصيلاً للعنصر مثل الوصف."

بمعنى أنه يمكن استخدام عنصري <title> و <desc> في SVGs بشكل مشابه للنص البديل للصورة وخيارات الوصف الطويلة الموجودة تقليديًا في عناصر <img> . بعد إضافة عنصر <desc> إلى SVG الثاني ، نرى دعمًا مشابهًا للمتصفح / AT مع سماع 3 مجموعات من 8 للرسالة كاملة. (ملاحظة: نموذج الخنزير رقم 2 يكافئ نمط المصباح رقم 10.) بينما تبدو نتائج الاختبار هذه تعكس النمط الأول ، فإن السبب في حصول هذا النمط على نتوء في فئة "أفضل" هو أنه من الأسهل قليلاً تنفيذ التعليمات البرمجية- من الحكمة ويؤثر على المزيد من مستخدمي AT ، حيث عمل على JAWS و VoiceOver لسطح المكتب و VoiceOver mobile ، بينما دعم النمط الأول مجموعات المستعرض / AT الأقل شيوعًا.

يستخدم النمط الثالث مرة أخرى عنصري <title> و <desc> ولكنه يحتوي الآن على aria-labelledby plus ID المضافة إلى المزيج. وفقًا لاختبارات SVG نفسها ، فإن إضافة هذا الجزء الإضافي من الكود يعني أنه يمكننا دعم 7 مجموعات من المستعرض / AT بشكل كامل. (ملاحظة: نموذج الخنزير رقم 3 يعادل نمط المصباح رقم 11.) من بين أنماط SVG الثلاثة ، هذا النموذج الثالث هو "الأفضل" لأنه يدعم معظم أجهزة AT. لكن هذا النمط له تراجع في استخدام بعض مجموعات المستعرض / AT ؛ سوف تسمع محتوى عنوان / وصف صورة مكررًا لهذا النمط. في حين أنه من المحتمل أن يكون مزعجًا للمستخدمين ، إلا أنني أجادل أنه من الأفضل بشكل عام سماع محتوى مكرر بدلاً من عدم سماع أي محتوى على الإطلاق.

خواطر ختامية

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

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

"الدمج لا يجلب الناس إلى ما هو موجود بالفعل - إنه يصنع مساحة جديدة ، مساحة أفضل للجميع."

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

موارد ذات الصلة

أدوات

• دعم إمكانية الوصول ، مايكل فيرتشايلد ، a11ysupport.io
• إمكانية الوصول إلى HTML5 ، ستيف فولكنر

مكتبات الأنماط

• مشروع الوصول
• دليل أسلوب الوصول
• المكونات التي يمكن الوصول إليها ، سكوت أوهارا
• قائمة drag-and-drop يمكن الوصول إليها لإعادة ترتيب البرنامج المساعد ، هاريس شنايدرمان
• مكتبة أنماط ARIA الخاصة بـ Deque
• مكتبة رد الفعل التي يمكن الوصول إليها في Deque
• نظام التصميم GOV.UK
• المكونات الشاملة ، هايدون بيكرينغ
• نظام تصميم الويب الأمريكي (USWDS)
• دروس الوصول إلى الويب