wcag
1.0.0
يرجى استخدام هذا الفرع كهدف لطلبات السحب حتى 10 يوليو 2016.
يتم استخدام هذا المستودع لتطوير محتوى لـ WCAG 2 ، بالإضافة إلى فهم المستندات والتقنيات المرتبطة بها.
لإكمال
انظر أيضًا: دليل نمط WCAG 2
تم الحفاظ على WCAG 2.0 في بنية ملفات مختلفة عن الإصدارات اللاحقة من WCAG. توجد ملفات المصدر لـ WCAG 2.0 في مجلد WCAG20 وتقع في المقام الأول لأغراض الأرشيف. لا تقم بتحرير المحتوى في هذا المجلد.
يتم تنظيم محتوى WCAG 2.1 ثم يتم تنظيمه وفقًا لهيكل الملف أدناه. يحتوي مستودع WCAG على الملفات المصدر والمساعد لـ WCAG 2 ، وفهم WCAG 2 ، وفي النهاية التقنيات. كما أنه يحتوي على ملفات مساعدة تدعم التنسيق الآلي للوثيقة. لتسهيل التحرير متعدد الأحزاب ، يكون كل معيار نجاح في ملف منفصل ، يتكون من جزء HTML الذي يمكن تضمينه في الإرشادات الرئيسية. تتضمن الملفات الرئيسية:
guidelines/index.html - ملف الإرشادات الرئيسيةguidelines/sc/{version}/*.html - ملفات لكل معيار نجاحguidelines/terms/{version}/*.html - ملفات لكل تعريفunderstanding/{version}/*.html - فهم الملفات لكل معيار نجاح حيث {version} هو "20" ، جاء المحتوى من WCAG 2.0. يستخدم "21" للمحتوى الذي تم تقديمه في WCAG 2.1 ، "22" لـ WCAG 2.2 ، إلخ.
سيقوم مديرو معايير النجاح بإعداد معايير النجاح المرشح ، جاهزين للإدراج في وثيقة الإرشادات. لإعداد معايير النجاح ، اتبع هذه الخطوات:
#1 .تستخدم معايير النجاح بنية بسيطة لعناصر HTML ، مع قيم سمة فئة قليلة ، لضمان الاتساق. البرامج النصية تحسين ونمط المفتاح قبالة هذا الهيكل. يشار إلى المحتوى الذي تقدمه في الأقواس. العناصر بعد التعليقات اختيارية.
< section class =" sc " >
< h4 > {SC Handle} </ h4 >
< p class =" conformance-level " > {Level} </ p >
< p class =" change " > {Change} </ p >
< p > {Main SC Text} </ p >
<!-- if SC has sub-points -->
< dl >
< dt > {Point Handle} </ dt >
< dd > {Point Text} </ dd >
</ dl >
<!-- if SC has notes -->
< p class =" note " > {Note} </ p >
</ section >لاحظ أنك لا تقدم رقم SC. سيتم تعيين الأرقام ، وعلى الأرجح إنشاء تلقائيًا ، لاحقًا.
تم وصف القيم التي تقدمها أدناه. ارجع إلى معيار النجاح 2.2.1 للحصول على مثال لكل قطعة من هذه المحتوى.
يمكن توفير العناصر.
إذا كنت تقدم تعريفات مصطلحات إلى جانب SC ، قم بتضمينها في guidelines/terms/{version} ، دليل واحد لكل ملف ، باستخدام التنسيق التالي:
< dt > < dfn id =" dfn-{shortname} " > {Term} </ dfn > </ dt >
< dd > {Definition} </ dd > يروي عنصر dfn البرنامج النصي أن هذا مصطلح ويسبب ميزات التصميم والربط الخاصة. للربط بمصطلح ، استخدم عنصر <a> بدون سمة href ؛ إذا كان نص الارتباط هو نفسه المصطلح ، فسيتم إنشاء الرابط بشكل صحيح. على سبيل المثال ، إذا كان هناك مصطلح <dfn>web page</dfn> على الصفحة ، فإن ارتباطًا في شكل <a>web page</a> سيؤدي إلى ارتباط مناسب.
إذا كان نص الارتباط يحتوي على نموذج مختلف عن المصطلح الكنسي ، على سبيل المثال ، "صفحات الويب" (لاحظ الجمع) ، فيمكنك تقديم تلميح على تعريف المصطلح مع سمة data-lt . في هذا المثال ، قم بتعديل المصطلح ليكون <dfn data-lt="web pages">web page</dfn> . يمكن فصل أسماء بديلة متعددة للمصطلح بأحرف الأنابيب ، مع عدم وجود مساحة رائدة أو زائدة ، على سبيل المثال ، <dfn data-lt="web pages|page|pages">web page</dfn> .
هناك ملف تفاهم واحد لكل معيار نجاح ، بالإضافة إلى فهرس:
understanding/index.html - صفحة الفهرس ، تحتاج إلى عدم الإلغاء أو إضافة إشارة إلى صفحات الفهم الفردية عند إتاحتهاunderstanding/{version}/*.htmlيتم ملء الملفات بقالب يوفر الهيكل المتوقع. اترك بنية القالب في مكانها ، وأضف المحتوى حسب الاقتضاء في الأقسام. توفر العناصر التي تحتوي على فئة = "تعليمات" إرشادات حول المحتوى الذي يجب تضمينه في هذا القسم ؛ يمكنك إزالة هذه العناصر إذا كنت تريد ولكن ليس عليك ذلك. يقترح قالب الأمثلة إما قائمة رصاصة أو سلسلة من الأقسام الفرعية ، واختر أحد هذه الأساليب وإزالة الآخر من القالب. يتضمن قالب التقنيات أقسامًا فرعية لـ "المواقف" ، قم بإزالة قسم التفاف هذا إذا لم يكن الحاجة.
تتم الإشارة إلى فهم الملفات من معيار النجاح ذي الصلة في مواصفات WCAG ؛ يتم وضع هذه الروابط بواسطة البرنامج النصي.
موقع النشر الرسمي لفهم الصفحات هو حاليًا https://www.w3.org/wai/wcag21/understanding/. يتم تحديث هذا المحتوى حسب الحاجة ؛ وقد تكون آلية.
تقع التقنيات في مجلد Techniques ، وتم تجميعها بواسطة التكنولوجيا في المراكز الفرعية. كل تقنية عبارة عن ملف مستقل ، وهو بتنسيق HTML بهيكل منتظم من العناصر والفئات والمعرفات.
يوضح قالب التقنية هيكل التقنيات. توجد الأقسام الرئيسية في العناصر ذات المستوى الأعلى <section> مع معرفات محددة: التعريف ، قابلية التطبيق ، الوصف ، الأمثلة ، الاختبارات ، ذات الصلة ، الموارد. الوصف واختبارات أقسام مطلوبة ؛ يوصى بتطبيق الأقسام والأمثلة ؛ أقسام الموارد ذات الصلة والموارد اختيارية. يوفر قسم META سياق التقنية أثناء التأليف ولكن تتم إزالته للنشر. عنوان التقنية في عنصر <h1> . توفر العناصر مع class="instructions" معلومات حول ملء القالب. يجب إزالتها عند تطوير التقنية ولكن إذا لم تتم إزالتها ، فسيتم تجاهلها من قبل المولد. لا تقم بنسخ class="instructions" على محتوى حقيقي.
يمكن أن تستخدم التقنيات ورقة أنماط مؤقتة لتسهيل مراجعة المسودات. يتم استبدال ورقة الأنماط هذه بأوراق أنماط أخرى وهيكل للنشر الرسمي. لاستخدام ورقة النمط هذه ، أضف <link rel="stylesheet" type="text/css" href="../../css/editors.css"/> إلى رأس التقنية.
يمكن أن تشمل التقنيات الصور. ضع ملف الصورة في مجلد img للتكنولوجيا ذات الصلة - مما يعني أن جميع التقنيات للتكنولوجيا تشترك في مجموعة مشتركة من الصور. استخدم رابطًا نسبيًا لتحميل الصورة. يجب تحميل معظم الصور بعنصر <figure> ووصفه بـ <figcaption> الموضوعة في الجزء السفلي من الشكل. <figure> يجب أن يكون للعناصر سمة id . قد يتم تحميل الصور الصغيرة المضمنة بعنصر <img> مع نص alt مناسب.
يجب أن تتضمن التقنيات أمثلة مختصرة لتوضيح كيفية تأليف محتوى المؤلف الذي يتبع التقنية. يجب أن تكون أمثلة الكود سهلة القراءة ، وعادة ما لا تكمل المحتوى في حد ذاتها. يمكن توفير أمثلة أكثر اكتمالا كأمثلة عمل (انظر أدناه). رابط لأمثلة العمل في أسفل كل مثال ، في عنصر <p class="working-example"> ، يحتوي على رابط نسبي إلى ../../working-examples/{example-name}/ {example-name )/.
يمكن توفير إشارات متقاطعة إلى التقنيات الأخرى حيثما تكون مفيدة. بشكل عام ، يجب توفيرها في قسم "التقنيات ذات الصلة" ولكن يمكن توفيرها في مكان آخر. استخدم رابطًا نسبيًا للإشارة إلى التقنية ، {Technique ID} إذا كانت نفس التكنولوجيا ، أو ../{Technology}/{Technique ID} خلاف ذلك. إذا كانت هذه التقنية لا تزال قيد التطوير وليس لديها معرف رسمي ، فأرجع المسار إلى ملف التطوير. إذا كانت هذه التقنية قيد التطوير في فرع مختلف ، فاستخدم URI المطلق إلى إصدار Rawgit من هذه التقنية.
يجب أن تستخدم الإشارات المتقاطعة إلى الإرشادات ومعايير النجاح URI نسبيًا إلى صفحة التفاهم لهذا العنصر. يجب أن تستخدم الإشارات المتقاطعة إلى أجزاء أخرى من الإرشادات URI المطلقة إلى الإرشادات كما تم نشرها على صفحة W3C TR ، وهي URI تبدأ بـ https://www.w3.org/TR/WCAG21/# . لاحظ أن الإشارات إلى الإرشادات أو معايير النجاح التي تتعلق بالتقنيات التي تتم إضافتها من قبل المولد عند النشر بناءً على المعلومات في مستندات التفاهم ، لذلك لا يلزم عادة روابط زائدة عن الحاجة إلى تلك التي لا يلزمها ذلك.
يتم الحفاظ على الأولويات العامة والعملية للعمل على التقنيات في الويكي.
يجب أن تستخدم التقنيات الجديدة اسم ملف مشتق من نسخة مختصرة من عنوان التقنية. سيقوم المحررين بتعيين التقنية معرف وإعادة تسمية الملف عند قبوله من قبل مجموعة العمل. على سبيل المثال ، قد تستخدم تقنية "استخدام السمة ALT على عنصر IMG لتوفير بدائل نصية قصيرة" "img-alt-short-text-alternities.html" كاسم ملف. سيقوم المحررين بتعيين معرف رسمي ، وإعادة تسمية الملف ، عندما يتم قبوله من قبل مجموعة العمل.
يجب إنشاء كل تقنية جديدة في فرع جديد. يتم تشغيل إعداد الفرع والملف عبر البرنامج النصي create-techniques.sh ، والذي يمكن تشغيله باستخدام Bash. سطر الأوامر هو:
bash create-techniques.sh < technology > < filename > < type > " <title> "<technology> هو دليل التكنولوجيا لهذه التقنية<filename> هو اسم الملف المؤقت (بدون تمديد) للتقنية<type> هو "تقنية" أو "فشل"<title> هو عنوان التقنية ، مغلق في عروض الأسعار والهروب من الشخصيات الخاصة مع هذا أتمتة الخطوات التالية:
بمجرد إعداد فرع التقنية والملف ، قم بملء المحتوى وطلب المراجعة:
التقنيات في المستودع هي ملفات HTML عادي مع الحد الأدنى من التنسيق. للنشر على مسودة المحررين وموقع W3C ، يتم تنسيق التقنيات من خلال عملية بناء تستند إلى مرور عشرة لالتقدير والتشجيع للتحولات. يمكن الاطلاع على مزيد من التفاصيل ، بما في ذلك إرشادات المعاينة محليًا ، في عملية الإنشاء README.
يقوم المولد بتجميع التقنيات معًا كجناح مع التنسيق والتنقل. يفرض هياكل معينة ، مثل طلب الأقسام ذات المستوى الأعلى الموضحة أعلاه وتوحيد العناوين. يحاول معالجة الروابط المرجعية المتقاطعة للتأكد من أن URIs تعمل عند النشر. أحد الأدوار الأكثر جوهرية هو ملء قسم قابلية التطبيق مع الإشارات إلى الإرشادات أو معايير النجاح التي ترتبط بها التقنية. المعلومات الخاصة بهذا تأتي من مستندات التفاهم. يعد الاستخدام السليم لقالب التقنية أمرًا مهمًا لتمكين هذه الوظيفة ، وقد يتسبب التقنيات التي يتم تشكيلها في الفشل في فشل المولد.
لا ينبغي إزالة التقنيات القديمة من المستودع. بدلاً من ذلك ، يمكن تمييزها باستخدام YAML الأمامي. على سبيل المثال:
---
obsoleteSince : 22
obsoleteMessage : |
This failure relates to 4.1.1: Parsing, which was removed as of WCAG 2.2.
---obsoleteSince إلى النسخة الأقدم من WCAG 2 عندما تصبح هذه التقنية عفا عليها الزمن (قد يتم ضبط هذا على 20 إذا كان ينبغي أن يكون عفا عليها الزمن بشكل فعال لجميع الإصدارات ، على سبيل المثال بالنسبة للتقنيات التي تنطوي على عناصر HTML المنهكة)obsoleteMessage إلى رسالة يتم عرضها ضمن قسم التقنية حول هذا في الحالات التي تكون فيها التقنيات بأكملها عفا عليها الزمن (مثل الفلاش والفضة) ، يمكن أيضًا تحديد هذه الخصائص على مستوى التقنية الفرعية ، على سبيل المثال عبر techniques/flash/flash.11tydata.json . لاحظ أن هذه الحالة تتطلب تنسيق JSON على وجه التحديد ، حيث يتم استهلاكها بواسطة كل من رمز إضافي وعملي في عملية الإنشاء المستخدمة لتجميع بيانات التقنيات.
يتم إنشاء المستندات المفيدة من نفس الملفات المصدر لكل من WCAG 2.2 و 2.1 ، لأن معظم محتواها متسقة بينهما. (لا تزال المبادئ التوجيهية نفسها يتم الحفاظ عليها على فروع منفصلة على سبيل المثال WCAG-2.1 ، لأغراض الحفاظ على مسودات المحررين المنفصلة.)
عند بناء مستندات مفيدة للإصدارات القديمة ، فإن معايير نجاح نظام الإنشاء تخص الإصدارات الأحدث ، وبدورها أي تقنيات ترتبط حصريًا بتلك المعايير.
هناك بعض الحالات التي قد يحتاج فيها المحتوى إلى تلبية إصدار معين ، كما أوضح في هذا القسم.
ملاحظة: هذا ينطبق فقط ضمن techniques ومجلدات understanding ( وليس guidelines ).
في الحالات التي يجب فيها عرض رقم الإصدار الدقيق ضمن مستندات مفيدة ، أدخل {{ versionDecimal }} . سيتم استبدال هذا برقم الإصدار العشري المحدد ، على سبيل المثال 2.1 أو 2.2.
في الحالات التي يستدعي فيها المستند المتعلق بإصدارات متعددة إجراء استدعاء محدد حول تحديث في إصدار أحدث ، يمكن تطبيق class="wcagXY" على عنصر يحيط بالنثر المعني (على سبيل المثال class="wcag22" لـ WCAG 2.2) . سيؤدي ذلك إلى حذف النثر من الإصدارات السابقة ، وعرضه ببادئة "جديدة في WCAG XY:" في الإصدارات المعمول بها.
يمكن أيضًا تطبيق هذه الفئة جنبًا إلى جنب مع فئة note ، وفي هذه الحالة "(جديد في WCAG XY)" سيتم إلحاقها بعنوان "الملاحظة" في الإصدارات المعمول بها ، وسيتم إخفاء الملاحظة في الإصدارات السابقة.
في وقت كتابة هذا التقرير (نوفمبر 2024) ، يكون تسجيل الدخول في مؤشر التقنيات متطابقًا بين WCAG 2.1 و 2.2. تم تقسيمها إلى الإصدار المنفصل الذي يتضمنه إصدارًا منفصلاً تحت _includes/techniques/changelog/*.html
يجب أن تكون الأمثلة في التقنيات مختصرة من عينات رمز سهلة الاستخدام لكيفية استخدام التقنية في المحتوى. لذلك يجب أن تركز الأمثلة على الميزات المحددة التي تصفها التقنية ، ولا تتضمن المحتوى ذي الصلة مثل النمط والبرنامج النصي ومحتوى الويب المحيط به ، إلخ.
غالبًا ما يكون من المستحسن توفير أمثلة أكثر شمولاً ، والتي تُظهر التقنية في العمل مع عدم التدخل في وثيقة التقنية الرئيسية. تُظهر هذه الأمثلة أيضًا الرمز الكامل المطلوب لجعل التقنية تعمل ، بما في ذلك ملفات النمط الكامل والبرنامج النصي ، والصور ، ورمز الصفحة ، وما إلى ذلك عادةً ، يتم الرجوع إلى "أمثلة العمل" في أسفل مثال elided الذي يتم تضمينه في MAIN تقنية.
يتم تخزين أمثلة العمل في دليل working-examples في المستودع. كل مثال في الدليل الفرعي الخاص به ، لاحتواء الملفات المتعددة التي قد تكون ضرورية لجعل المثال يعمل. في بعض الحالات ، ستشارك أمثلة عمل متعددة الموارد المشتركة ؛ يتم تخزينها في الدليل الفرعي المناسب لدليل أمثلة العمل ، على سبيل المثال ، working-examples/css ، working-examples/img ، working-examples/script . الرجوع إلى هذه الموارد المشتركة عند توفرها ؛ خلاف ذلك ضع الموارد في دليل مثال العمل ، باستخدام الدلائل الفرعية للتنظيم عند الاقتضاء.
لإنشاء مثال عمل:
example- على سبيل المثال ، على سبيل المثال example-alt-attribute .working-examples/alt-attribute/ .index.html . خلاف ذلك ، قم بإنشاء اسم ملف مناسب.../css/example.css . ضع موارد أخرى في نفس الدليل مثل المثال الرئيسي ، على سبيل المثال working-examples/alt-attribute/css/alt.css .https://rawgit.com/w3c/wcag/main/working-examples/alt-attribute/ . سيقوم المحررين بتحديث الروابط عند الموافقة على الأمثلة.WCAG 2.2 جاهز للترجمة. لترجمة WCAG 2.2 ، اتبع التعليمات في كيفية ترجمة WCAG 2.
