لماذا يعتبر الامتثال للقسم 508 في الواقع مجرد هندسة أفضل

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

لكننا ننظر إليها بشكل مختلف.

إذا لم يكن موقعك متوافقًا مع 508، فهو معطل بشكل أساسي. لن تقوم بشحن موقع لا يعمل فيه زر «إرسال» لمستخدمي Chrome، أليس كذلك؟ فلماذا من المقبول شحن موقع لا يعمل لشخص يستخدم لوحة مفاتيح أو شاشة برايل؟ القسم 508 ليس طبقة إضافية من الميزات التي من الجيد امتلاكها. إنه الأساس للبرامج الوظيفية. في Sweent LLC، قمنا ببناء الكثير من الأنظمة على مستوى المؤسسات - من أدوات تصحيح الأجهزة الطبية لـ Kaiser Permanente إلى مواقع التسويق لـ Deloitte - والدرس هو نفسه دائمًا: الكود الذي يمكن الوصول إليه هو رمز أفضل.

ما الذي نتحدث عنه بالفعل؟

القسم 508 هو جزء من قانون إعادة التأهيل لعام 1973. وتقول إن الوكالات الفيدرالية يجب أن تجعل التكنولوجيا الإلكترونية والمعلوماتية في متناول الأشخاص ذوي الإعاقة. في عالم الويب، يعني هذا عادةً اتباع إرشادات إمكانية الوصول إلى محتوى الويب (WCAG).

بالنسبة لشركة مثل شركتنا، هذا هو أكل عيشها. نحن شركة صغيرة مملوكة للمحاربين القدامى ذوي الاحتياجات الخاصة (SDVOSB) ولدينا عقد GSA MAS (47QRAA25D0024). عندما نبني للحكومة، فإن الامتثال لـ 508 ليس اقتراحًا. إنه القانون. ولكن حتى إذا كنت لا تسعى وراء العقود الفيدرالية، فإن المبادئ الكامنة وراء 508 تجعل برنامجك أفضل للجميع.

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

تلة HTML الدلالية التي سأموت عليها

واحدة من أكبر الخدمات التي يمكنك القيام بها لنفسك في المستقبل هي استخدام HTML الدلالي. إنها أسهل طريقة للحصول على 70٪ من طريقة الامتثال دون حتى المحاولة. نرى هذا طوال الوقت: يريد المطور أن يبدو الزر بطريقة معينة، لذلك يقوم بتصميم <div> وإضافة معالج النقرات.

``أتش تي أم أل

أرسل ```

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

أو يمكنك فقط استخدام علامة ``.

``أتش تي أم أل

أرسل

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

وهو أعمق من مجرد الأزرار. يؤدي استخدام <nav>`` لقوائمك و <main>`` للمحتوى الأساسي الخاص بك و <header>`` لعلامتك التجارية إلى منح المتصفح خريطة. عندما تستخدمها بشكل صحيح، فأنت لا تساعد برامج قراءة الشاشة فحسب؛ بل تسهل قراءة التعليمات البرمجية للمطورين الآخرين. يمكنني إلقاء نظرة على ملف HTML جيد التنظيم ومعرفة ما يحدث بالضبط دون فتح متصفح. هذا يوفر الوقت والمال أثناء الصيانة.

## الاختبار الخالي من الماوس

إليك تجربة سريعة. انتقل إلى مشروعك الحالي، ضع الماوس على الأرض، وحاول إكمال تدفق المستخدم الأساسي باستخدام مفتاحي «Tab» و «Enter» فقط.

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

لقد واجهنا هذا أثناء العمل في مشروع لشركة Kaiser Permanente. كنا نبني أداة لإدارة تصحيح الأجهزة الطبية لآلاف الأجهزة باستخدام IBM BigFix. في بيئة الرعاية الصحية، لا يمكنك تحمل تكلفة الحصول على واجهة مستخدم مربكة أو يصعب التنقل فيها. إذا كان الفني في عجلة من أمره ولم يتمكن من العثور على زر «التأكيد» لأن حالة التركيز غير مرئية، فهذه مشكلة حقيقية. لقد أمضينا الكثير من الوقت في ضمان إمكانية تشغيل كل إجراء من خلال لوحة المفاتيح باستخدام مؤشرات تركيز واضحة وعالية التباين. لم يكن الأمر يتعلق فقط بالامتثال؛ كان يتعلق بالسلامة.

لكن إدارة التركيز تصبح صعبة في تطبيقات React الحديثة. عندما تقوم بتغيير «الصفحات» في تطبيق أحادي الصفحة (SPA)، لا يتم إعادة تحميل المتصفح فعليًا. بالنسبة لمستخدم قارئ الشاشة، لم يحدث شيء. لا يزالون جالسين على الرابط الذي نقروا عليه للتو، ولكن المحتوى المحيط بهم قد تغير. يجب عليك نقل التركيز يدويًا إلى المحتوى الجديد أو استخدام منطقة «aria-live» للإعلان عن تغيير الصفحة. إذا لم تفعل ذلك، فإن تطبيقك «الحديث» هو لبنة لمستخدم أعمى.

## ARIA ليست عصا سحرية

تعد سمات تطبيقات الإنترنت الغنية التي يمكن الوصول إليها (ARIA) قوية، ولكن غالبًا ما يتم إساءة استخدامها. القاعدة الأولى لـ ARIA هي: إذا كان بإمكانك استخدام عنصر HTML أصلي بدلاً من ذلك، فافعل ذلك.

لقد رأيت المطورين يرشون «aria-label» و «aria-live» على كل شيء كما لو كانوا يقومون بتتبيل شريحة لحم. ينتهي الأمر بإنشاء تجربة صاخبة ومربكة لمستخدمي قارئ الشاشة. يجب استخدام ARIA لملء الفجوات التي لا يمكن لـ HTML الأصلي معالجتها، مثل لوحات علامات التبويب المعقدة أو تحديثات الحالة في الوقت الفعلي في لوحة المعلومات.

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

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

## أسطورة الموقع «القبيح» الذي يمكن الوصول إليه

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

وهذا يعني اختيار لوحات الألوان التي تلبي نسبة التباين 4.5:1 للنص العادي. هذا يعني عدم استخدام اللون كطريقة وحيدة لنقل المعلومات. إذا كانت رسالة الخطأ عبارة عن حد أحمر حول مربع، فقد يفوتها مستخدم مصاب بعمى الألوان. أضف رمزًا أو تصنيفًا نصيًا مثل «Error:» لتوضيح الأمر.

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

## الأدوات التي نستخدمها بالفعل

يعد الاختبار الآلي أمرًا رائعًا، ولكنه مجرد بداية. تعد أدوات مثل WAVE و Axe و Lighthouse رائعة لالتقاط الفاكهة المعلقة - النص البديل المفقود أو التباين السيئ أو المعرفات المكررة. نقوم بدمجها في خطوط أنابيب CI/CD الخاصة بنا باستخدام إجراءات GitHub حتى نلتقط الانحدارات مبكرًا. حتى أننا نستخدم «jest-axe» لإجراء فحوصات إمكانية الوصول أثناء اختبارات الوحدة الخاصة بنا.

لكن الأدوات الآلية لا تلتقط سوى حوالي 30٪ إلى 40٪ من مشكلات إمكانية الوصول. يمكنهم إخبارك ما إذا كانت الصورة تحتوي على نص بديل، لكن لا يمكنهم إخبارك ما إذا كان هذا النص مفيدًا بالفعل.

``أتش تي أم أل
<!-- Bad: Not helpful -->
<img src="chart.png" alt="image">

<!-- Good: Descriptive -->
<img src="chart.png" alt="Bar chart showing a 20% increase in social media engagement over Q3.">

هذا هو السبب في أن الاختبار اليدوي غير قابل للتفاوض. نحن نستخدم برامج قراءة الشاشة مثل NVDA على Windows وVoiceOver على Mac. نقوم أيضًا باختبار «عدم استخدام الماوس» واختبار الزوم. هل سبق لك أن حاولت استخدام موقعك بتكبير 400٪؟ يتطلب WCAG 2.1 أن يظل موقعك يعمل دون التمرير الأفقي على هذا المستوى. هذا يجبرك على كتابة CSS استجابة أفضل. إنه ليس فقط للأشخاص الذين يعانون من ضعف البصر؛ إنه مخصص لأي شخص يستخدم جهازًا صغيرًا أو بحجم نافذة متصفح غريب. إذا تعطل موقعك عند تكبير بنسبة 400٪، فمن المحتمل أن يكون منطق التخطيط الخاص بك هشًا للغاية على أي حال.

دراسة الجدوى (ما وراء القانون)

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

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

ثم هناك جانب الصيانة. الكود الدلالي المنظم جيدًا أسهل في القراءة ويسهل تصحيحه. عندما ينضم مطور جديد إلى الفريق ويرى <nav> و <main> و <footer>، فإنه يفهم التخطيط على الفور. إذا رأوا «div-1" و «div-2" و «div-3"، فعليهم قضاء ساعة فقط في معرفة أين ينتهي التنقل ويبدأ المحتوى. إمكانية الوصول هي شكل من أشكال الوثائق التي لا تنتهي صلاحيتها أبدًا.

لماذا نهتم في Sweent

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

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

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

كيفية البدء

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

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

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