بيانات إمكانية الوصول تجد مكاناً لها على GitHub

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

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

كيف تسهل GitHub العثور على بيانات إمكانية الوصول؟

تتعرف GitHub الآن على ملف ACCESSIBILITY.md في جذر المستودع، أو دليل .github/، أو دليل docs/. يمكن للمستودع أيضاً أن يرث بياناً من مستودع .github/ الخاص بمنظمته.

تساعد ملفات صحة المجتمع في GitHub الأشخاص على فهم كيفية عمل المشروع:

• تشرح إرشادات المساهمة كيفية اقتراح التغييرات.
• تحدد مدونات السلوك توقعات المشاركة.
• تشرح سياسات الأمان كيفية الإبلاغ عن الثغرات الأمنية.

يمنح التعرف على ACCESSIBILITY.md معلومات إمكانية الوصول مكاناً مخصصاً إلى جانب هذه الإرشادات.

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

ما الذي تكشفه بيانات إمكانية الوصول عن ممارسات المشروع؟

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

يوثق بيان إمكانية الوصول الخاص بأداة GitHub Annotation Toolkit قيداً في مكتبة Figma الخاصة بها: تستخدم التعليقات التوضيحية موضع اللوحة، وخطوط الربط، والأرقام المتطابقة لنقل العلاقات بصرياً. لا يوصل الوصول إلى كائنات اللوحة الفردية بالضرورة ماهية تلك العلاقات.

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

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

ما الذي يجب أن يوثقه المشروع؟

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

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

ضع في اعتبارك أن المشروع يمكن أن يسمي إصداراً ومستوى من إرشادات الوصول إلى محتوى الويب (Web Content Accessibility Guidelines) كهدف. لا يؤسس الهدف مطابقة مؤكدة. يتطلب ادعاء المطابقة تقييماً ويجب أن يحدد النطاق الذي تم تقييمه، والتاريخ، والطريقة، والمقيّم.

ما الذي تحتويه ملفات ACCESSIBILITY.md الأكثر فائدة؟

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

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

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

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

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