معايير نجاح WCAG · Level AA
WCAG 3.2.3: تنقل متسق
تتطلب WCAG 3.2.3 أن تظهر آليات التنقل الموجودة في صفحات متعددة ضمن مجموعة من صفحات الويب بالترتيب النسبي نفسه في كل مرة، ما لم يقم المستخدم ببدء تغيير ما. تساعد هذه القدرة على التنبؤ المستخدمين ذوي الإعاقات الإدراكية والبصرية والحركية على بناء نماذج ذهنية للموقع والتنقل فيه بكفاءة.
ماذا يعني هذا المعيار
ينص معيار النجاح 3.2.3 من WCAG — التنقل المتسق (المستوى AA) على أن مكوّنات التنقل التي تتكرر عبر صفحات متعددة من موقع ويب يجب أن تظهر في نفس الترتيب النسبي في كل مرة يتم الوصول إليها، ما لم يكن المستخدم نفسه قد تسبب في تغيير ذلك الترتيب. ينطبق هذا المعيار على أي مجموعة من صفحات الويب التي تشترك في غرض مشترك أو تشكل جزءًا من نفس الموقع أو التطبيق.
عبارة "نفس الترتيب النسبي" مهمة: لا يتطلب WCAG أن يحتوي التنقل دائمًا على نفس عدد العناصر، ولا يمنع ظهور عناصر أخرى بين عناصر التنقل. ما يتطلبه هو أن يبقى تسلسل روابط التنقل، كما يظهر للمستخدم أثناء تحركه عبر الواجهة، متسقًا من صفحة إلى أخرى. على سبيل المثال، إذا كانت قائمة التنقل الأساسية لديك تعرض "Home" و"Products" و"About" و"Contact" بهذا الترتيب في الصفحة الرئيسية، فيجب أن تظهر نفس العناصر بنفس التسلسل في كل صفحة أخرى يوجد فيها نفس بلوك التنقل.
يشمل المعيار جميع آليات التنقل المتكررة: قوائم التنقل الأساسية للموقع، مسارات التنقل (breadcrumb trails)، مجموعات الروابط في التذييل، قوائم الشريط الجانبي، روابط تخطي التنقل، أشرطة البحث، وأي مكوّن تفاعلي آخر يساعد المستخدم على التنقل داخل الموقع. ينطبق ذلك بغض النظر عما إذا كانت هذه المكوّنات مُنفَّذة كعناصر <nav>، أو قوائم روابط <ul>، أو قوائم مخصّصة معززة بـ ARIA، أو أي نمط ترميز آخر.
ما الذي يُعد اجتيازًا: تظهر كتل التنقل بنفس الترتيب النسبي في كل صفحة تتكرر فيها. يمكن إضافة عناصر أو تمييزها أو وضع علامة عليها كعناصر نشطة (مثل تمييز رابط الصفحة الحالية بصريًا)، طالما أن التسلسل العام لا يتغير. كما يُعد إعادة الترتيب بمبادرة من المستخدم — مثل لوحة تحكم قابلة للتخصيص حيث يسحب المستخدم اللوحات إلى مواضع جديدة — اجتيازًا أيضًا، لأن التغيير نشأ من المستخدم.
ما الذي يُعد إخفاقًا: قائمة تنقل رئيسية تعرض "Home → Products → Contact → About" في الصفحة الرئيسية لكنها تعرض "Home → About → Products → Contact" في صفحة تفاصيل منتج تُعد إخفاقًا في 3.2.3. وبالمثل، فإن موقعًا يُدرج روابط إضافية بشكل شرطي في مواضع عشوائية داخل التنقل بناءً على منطق داخلي (دون إجراء من المستخدم) سيُعد إخفاقًا.
الاستثناء الرسمي: تنص المواصفة صراحةً على أن هذا المتطلب لا ينطبق عندما يكون المستخدم هو من بادر بتغيير الترتيب. هذا هو الاستثناء المعياري الوحيد. التغييرات التي يقودها النظام أو منطق الخادم أو خوارزميات التخصيص — والتي لا يطلقها المستخدم مباشرة — لا تندرج تحت هذا الاستثناء.
لماذا يهم هذا المعيار
يُعد التنقل المتسق أساسًا لإتاحة الوصول المعرفية. المستخدمون الذين يعتمدون على الذاكرة المكانية والأنماط المتوقعة لتحديد موقعهم — بما في ذلك الأشخاص ذوو الإعاقات المعرفية، واضطرابات الانتباه، وإصابات الدماغ الرضحية، أو التدهور المعرفي المرتبط بالعمر — يعتمدون بشكل كبير على افتراض أن تنقل الموقع سيكون في نفس المكان وبنفس الترتيب في كل مرة يواجهونه فيها. عندما يتحرك التنقل بشكل غير متوقع، يضطر هؤلاء المستخدمون إلى إعادة تعلّم التخطيط في كل صفحة، مما يزيد بشكل كبير العبء المعرفي واحتمال الأخطاء أو التخلي عن المهمة.
بالنسبة إلى المستخدمين المكفوفين وضعاف البصر الذين يتنقلون باستخدام قارئات الشاشة (NVDA, JAWS, VoiceOver)، يقلل التنقل المتسق من الوقت الذي يقضونه في البحث عن المعالم المعروفة. يمكن لمستخدم قارئ الشاشة الذي حفظ أن رابط "Contact" هو العنصر الرابع في التنقل الرئيسي أن يضغط على مفتاح Tab أربع مرات في أي صفحة للوصول إليه — ولكن فقط إذا كان الترتيب مضمونًا أن يبقى كما هو. يؤدي عدم الاتساق في الترتيب إلى تدمير هذه الكفاءة ويجبر المستخدم على الاستماع إلى التنقل بالكامل في كل مرة يتم فيها تحميل الصفحة.
بالنسبة إلى المستخدمين ذوي الإعاقات الحركية الذين يعتمدون على التنقل باستخدام لوحة المفاتيح فقط، أو أجهزة التبديل، أو تتبع العين، فإن كل ضغطة مفتاح إضافية أو حركة رأس لها تكلفة حقيقية. يقلل التنقل المتوقع من عدد التفاعلات المطلوبة للوصول إلى الوجهات التي تتم زيارتها بشكل متكرر. ووفقًا لمنظمة الصحة العالمية، يعيش أكثر من 1.3 مليار شخص حول العالم مع شكل من أشكال الإعاقة، وكثير منهم يعتمدون على تقنيات مساعدة تستفيد مباشرة من الواجهات المتسقة والمتوقعة.
بالنسبة إلى المستخدمين ذوي صعوبات القراءة مثل عسر القراءة، فإن مسح شريط التنقل يمثل جهدًا في حد ذاته. يعني التمركز والترتيب المتسق أنهم يمكنهم الاعتماد على نقاط ارتكاز بصرية — مثل الموضع، والشكل، واللون — بدلًا من إعادة قراءة التسميات في كل مرة.
سيناريو واقعي ملموس: تخيل مريضًا يستخدم موقع مستشفى لحجز مواعيد متابعة. يعرض التنقل في الصفحة الرئيسية "Services" و"Appointments" و"Doctors" و"Contact" بهذا الترتيب. ينتقل المريض إلى صفحة ملف طبيب ويبحث عن "Appointments" في الموضع الثاني — لكن في تلك الصفحة، أُعيد تنظيم التنقل ليبدأ بـ "Doctors" متبوعًا بـ "Appointments". يضطر المريض، وهو بالفعل تحت ضغط، إلى إعادة مسح القائمة بالكامل. بالنسبة لمستخدم لديه إعاقة معرفية أو معرفة محدودة بالقراءة والكتابة، يمكن أن يكون هذا الاحتكاك هو الفارق بين إكمال المهمة والتخلي عنها تمامًا.
إضافة إلى الإتاحة، للتنقل المتسق فوائد ملموسة في تحسين محركات البحث وقابلية الاستخدام. تزحف عناكب محركات البحث عبر روابط التنقل لاكتشاف المحتوى وفهرسته؛ يحسن هيكل الروابط المستقر من كفاءة الزحف وتوزيع قوة الروابط الداخلية. تُظهر اختبارات قابلية الاستخدام باستمرار أن التنقل المتوقع يقلل من وقت إكمال المهام ومعدلات الأخطاء لجميع المستخدمين، وليس فقط ذوي الإعاقة.
قواعد axe-core ذات الصلة
يتطلب WCAG 3.2.3 اختبارًا يدويًا. لا توجد قاعدة آلية في axe-core يمكنها الإشارة إلى عدم اتساق ترتيب التنقل، لأن الأدوات الآلية تفتقر إلى سياق متعدد الصفحات اللازم لمقارنة تسلسلات التنقل. يقوم الماسح الآلي بتقييم صفحة واحدة بمعزل عن غيرها ولا يمكنه ملاحظة ما إذا كان التنقل في تلك الصفحة يختلف عن التنقل في عشرين صفحة أخرى في نفس الموقع.
- مقارنة يدوية عبر الصفحات (لا يوجد معرّف قاعدة في axe): يجب على المختبرين زيارة صفحات متعددة ضمن نفس الموقع وتسجيل ترتيب عناصر التنقل يدويًا في كل صفحة، ثم مقارنة هذه السجلات. لا يمكن للأدوات الآلية إجراء هذا الفحص لأنها ستحتاج إلى تحليل عدة صفحات في الوقت نفسه، والحفاظ على الحالة عبر تحميلات الصفحات، وتطبيق حكم دلالي حول أي العناصر تشكل نفس مكوّن التنقل — وهي جميعها مهام تتطلب استدلالًا سياقيًا بشريًا.
- لماذا تعجز الأتمتة: حتى الأدوات الاستدلالية التي تشير إلى مشكلات متعلقة بالتنقل تتحقق عادةً من وجود معالم التنقل (مثل قاعدة axe
landmark-one-mainأوregion)، وليس من اتساق الترتيب عبر الصفحات. تتطلب مقارنة الترتيب منهجية تدقيق على مستوى الموقع بالكامل، وليس فحص صفحة واحدة. لهذا السبب يُصنَّف 3.2.3 على أنه يتطلب مراجعة يدوية في جميع أطر اختبار الإتاحة الرئيسية، بما في ذلك axe-core وLighthouse وIBM Equal Access Checker.
كيفية الاختبار
- تشغيل فحص آلي للحصول على سياق أساسي: استخدم axe DevTools أو Lighthouse أو إضافة متصفح على صفحات تمثيلية للتأكد من أن عناصر التنقل مُعلَّمة بشكل صحيح كعناصر
<nav>أو باستخدامrole='navigation'. على الرغم من أن هذه الأدوات لن تشير إلى عدم اتساق في الترتيب، إلا أنها تساعدك على تحديد ما يُعامَل كتنقل عبر الصفحات. وثّق أي مشكلات في بنية المعالم قبل الانتقال إلى الفحوص اليدوية. - اختيار عينة صفحات تمثيلية: اختر ما لا يقل عن خمس إلى عشر صفحات من أقسام مختلفة من الموقع — الصفحة الرئيسية، صفحة فئة، صفحة تفاصيل منتج أو مقالة، صفحة نموذج، وصفحة الاتصال. إذا كان الموقع يحتوي على آلاف الصفحات، فاستخدم عينة طبقية تغطي جميع القوالب الرئيسية. سجّل عنوان URL ونوع الصفحة لكل منها.
- رسم خريطة ترتيب التنقل يدويًا: في كل صفحة من العينة، افتح شجرة الإتاحة في المتصفح (Chrome DevTools → لوحة Accessibility، أو Firefox Accessibility Inspector) وسجّل كل رابط داخل التنقل الأساسي بالترتيب الذي يظهر به في DOM. لاحظ أيضًا الترتيب كما يظهر بصريًا. إذا كانت CSS تعيد ترتيب العناصر بصريًا (مثل استخدام
flex-direction: row-reverseأو خصائصorder)، فقد يختلف الترتيب البصري عن ترتيب DOM — يجب أن يكون كلاهما متسقًا. - المقارنة عبر الصفحات: ضع قوائم ترتيب التنقل جنبًا إلى جنب. علّم أي صفحة يختلف فيها تسلسل عناصر التنقل المشتركة عن خط الأساس المحدد في الصفحة الرئيسية. لاحظ أي العناصر تحركت وفي أي اتجاه.
- اختبار التنقل باستخدام لوحة المفاتيح (NVDA + Firefox): افتح NVDA، ثم Firefox، وانتقل إلى الصفحة الرئيسية. اضغط على D للانتقال إلى منطقة المعلم التالية وحدد موقع التنقل الرئيسي. استخدم مفتاح Tab للتحرك عبر روابط التنقل وقل بصوت عالٍ أو دوّن الترتيب. ثم انتقل إلى صفحة ثانية (مثل صفحة مقالة داخلية) وكرر العملية. استمع لأي تغيير في تسلسل الإعلان عن الروابط.
- اختبار قارئ الشاشة (VoiceOver + Safari على macOS): فعّل VoiceOver (Command + F5)، وافتح Safari، واستخدم Web Rotor (Control + Option + U) لفتح قائمة الروابط أو المعالم. انتقل إلى التنقل الرئيسي ولاحظ ترتيب العناصر. كرر ذلك في ثلاثة أنواع مختلفة على الأقل من الصفحات وقارن.
- اختبار JAWS + Chrome: افتح JAWS، ثم Chrome، واضغط على R للتنقل بين المناطق حتى تصل إلى التنقل الرئيسي. تحرك عبر الروابط باستخدام Tab وسجّل الترتيب. كرر ذلك عبر أنواع الصفحات.
- التحقق من الاستثناءات التي يطلقها المستخدم: إذا كان الموقع يقدم أي ميزات تخصيص أو تخصيص للتنقل، فتحقق من أن أي إعادة ترتيب لا تحدث إلا بعد إجراء صريح من المستخدم (مثل أن ينقر المستخدم على "Customize Menu" ويسحب العناصر). تأكد من أن حالة الترتيب الجديدة تُحفظ بعد ذلك بشكل متسق — يجب أن يبقى الترتيب الجديد نفسه متسقًا عبر جميع الصفحات بعد أن يحدده المستخدم.
كيفية الإصلاح
تصيير غير متسق من جهة الخادم — غير صحيح
<!-- Homepage navigation -->
<nav aria-label='Main navigation'>
<ul>
<li><a href='/'>Home</a></li>
<li><a href='/products'>Products</a></li>
<li><a href='/about'>About</a></li>
<li><a href='/contact'>Contact</a></li>
</ul>
</nav>
<!-- Product detail page navigation — order changed by CMS template -->
<nav aria-label='Main navigation'>
<ul>
<li><a href='/'>Home</a></li>
<li><a href='/about'>About</a></li>
<li><a href='/contact'>Contact</a></li>
<li><a href='/products'>Products</a></li>
</ul>
</nav>
تصيير غير متسق من جهة الخادم — صحيح
<!-- Shared navigation partial (e.g., _nav.html or a component) used on every page -->
<!-- The active page is indicated with aria-current, not by reordering -->
<nav aria-label='Main navigation'>
<ul>
<li><a href='/' aria-current='page'>Home</a></li>
<li><a href='/products'>Products</a></li>
<li><a href='/about'>About</a></li>
<li><a href='/contact'>Contact</a></li>
</ul>
</nav>
<!-- On the Products page, only aria-current moves — the order stays identical -->
إعادة ترتيب بصرية باستخدام CSS تخلق عدم اتساق — غير صحيح
<!-- DOM order: Home, Products, About, Contact -->
<!-- CSS on interior pages uses flex order to visually move Contact first -->
<style>
/* Applied only on interior page templates */
nav ul li:last-child { order: -1; }
</style>
<nav aria-label='Main navigation'>
<ul style='display:flex'>
<li><a href='/'>Home</a></li>
<li><a href='/products'>Products</a></li>
<li><a href='/about'>About</a></li>
<li><a href='/contact'>Contact</a></li>
</ul>
</nav>
<!-- Visual order becomes Contact, Home, Products, About — inconsistent with homepage -->
إعادة ترتيب بصرية باستخدام CSS تخلق عدم اتساق — صحيح
<!-- Use consistent DOM order and consistent CSS across all templates -->
<!-- Do not use CSS 'order' property to rearrange navigation items differently per template -->
<nav aria-label='Main navigation'>
<ul style='display:flex'>
<li><a href='/'>Home</a></li>
<li><a href='/products'>Products</a></li>
<li><a href='/about'>About</a></li>
<li><a href='/contact'>Contact</a></li>
</ul>
</nav>
<!-- Same DOM order and same CSS flex order on every page template -->
تنقل ديناميكي يُعاد ترتيبه بواسطة خوارزمية — غير صحيح
<!-- JavaScript reorders nav links based on most-visited analytics without user action -->
<script>
// Anti-pattern: fetches user behaviour data and reorders nav items automatically
fetch('/api/user-nav-preferences').then(r => r.json()).then(order => {
const nav = document.querySelector('nav ul');
order.forEach(id => nav.appendChild(document.getElementById(id)));
});
</script>
<nav aria-label='Main navigation'>
<ul>
<li id='nav-home'><a href='/'>Home</a></li>
<li id='nav-products'><a href='/products'>Products</a></li>
<li id='nav-about'><a href='/about'>About</a></li>
<li id='nav-contact'><a href='/contact'>Contact</a></li>
</ul>
</nav>
تنقل ديناميكي يُعاد ترتيبه بواسطة خوارزمية — صحيح
<!-- If personalisation is desired, require an explicit user action and keep order stable otherwise -->
<nav aria-label='Main navigation'>
<ul>
<li><a href='/'>Home</a></li>
<li><a href='/products'>Products</a></li>
<li><a href='/about'>About</a></li>
<li><a href='/contact'>Contact</a></li>
</ul>
</nav>
<!-- Personalisation button lets user reorder — change only applies after they interact -->
<button type='button' aria-controls='main-nav-list' id='customize-nav'>Customize Navigation Order</button>
<!-- The user-chosen order is then persisted consistently across all pages -->
الأخطاء الشائعة
- استخدام قوالب CMS مختلفة يعرّف كل منها التنقل بشكل مستقل، مما يؤدي إلى تسلل اختلافات طفيفة في الترتيب بمرور الوقت مع تحديث القوالب بشكل منفصل بدلًا من الاعتماد على مكوّن أو جزء مشترك واحد.
- ترقية عناصر تنقل "مميزة" أو "موسمية" إلى مواضع مختلفة بناءً على حملات تسويقية دون ضمان بقاء بقية ترتيب التنقل دون تغيير — على سبيل المثال، نقل "Sale" مؤقتًا إلى الموضع الثاني في بعض الصفحات وإلى الموضع الخامس في صفحات أخرى.
- استخدام خاصية CSS
orderأوflex-direction: row-reverseأو تموضع CSS Grid لإعادة ترتيب عناصر التنقل بصريًا بشكل مختلف عبر قوالب الصفحات، مما يخلق عدم تطابق بين الترتيب البصري (الذي يراه المستخدمون المبصرون) وترتيب DOM (الذي يتبعه مستخدمو لوحة المفاتيح وقارئات الشاشة). - إدراج عناصر تنقل حساسة للسياق في مواضع عشوائية — على سبيل المثال، إضافة رابط "Back to Category" كعنصر ثانٍ في صفحات المنتجات ولكن ليس في الصفحات الأخرى، مما يدفع جميع العناصر اللاحقة إلى أسفل بمقدار موضع واحد ويكسر التسلسل المتوقع.
- السماح لمنصات الاختبار A/B أو تحليلات البيانات بإعادة ترتيب روابط التنقل كجزء من متغيرات التجارب، دون مراعاة أن إعادة الترتيب تُطبَّق بشكل غير متسق عبر الصفحات والجلسات.
- معاملة مسار التنقل (breadcrumb trail) كأنه مستثنى من هذا المعيار بينما هو في الواقع آلية تنقل متكررة — فمسارات التنقل التي تظهر في مواضع مختلفة بالنسبة لعناصر الصفحة الأخرى عبر قوالب مختلفة تنتهك أيضًا 3.2.3.
- إعادة ترتيب تنقل التذييل بشكل مختلف عن التنقل الرئيسي عندما تكرر روابط التذييل التنقل الرئيسي — إذا ظهر كلاهما في كل صفحة، فيجب على كل منهما الحفاظ على ترتيب متسق بشكل مستقل وفي علاقته بالآخر.
- تطبيق تحسينات تنقل مدفوعة بـ JavaScript تعيد ترتيب العناصر بناءً على موضع التمرير أو حجم نافذة العرض أو بيانات الجلسة دون مبادرة من المستخدم — على سبيل المثال، قائمة ضخمة (mega-menu) تُظهر ديناميكيًا فئات عليا مختلفة حسب القسم الذي يوجد فيه المستخدم من الموقع.
- الفشل في تدقيق اتساق التنقل بعد إعادة تصميم الموقع أو ترحيل CMS، مع افتراض أن المطورين سيعيدون إنتاج الترتيب الأصلي بشكل طبيعي بينما في الواقع تُبنى أنواع صفحات مختلفة من الصفر بواسطة أعضاء فرق مختلفين.
- الخلط بين "التنقل المتسق" و"نفس التنقل في كل صفحة" — أحيانًا تستنتج الفرق بشكل غير صحيح أن إضافة أو إزالة عناصر تنقل لأدوار مستخدمين معينة (مثل المستخدم المسجّل مقابل الضيف) ينتهك 3.2.3. هذا غير صحيح، طالما أن الترتيب النسبي للعناصر المشتركة يبقى دون تغيير.
العلاقة مع لوائح الإتاحة في تركيا
تُرسّخ التعميم الرئاسي رقم 2025/10 في تركيا، المنشور في الجريدة الرسمية (رقم 32933) بتاريخ 21 يونيو 2025، التزامات ملزمة تتعلق بإتاحة الوصول لمجموعة واسعة من الكيانات العامة والخاصة التي تدير خدمات رقمية في تركيا. يفرض التعميم الالتزام بالمعايير الدولية المعترف بها في مجال الإتاحة — مع اعتماد WCAG 2.2 المستوى AA كمعيار تقني أساسي — ويربط الامتثال بـ Erişilebilirlik Logosu (شعار الإتاحة)، وهو علامة اعتماد تصدرها وزارة الأسرة والخدمات الاجتماعية للكيانات التي تستوفي مستوى الإتاحة المطلوب.
يُعد معيار WCAG 3.2.3 الخاص بالتنقل المتسق معيارًا من المستوى AA، ما يعني أنه متطلب إلزامي للكيانات التي تسعى للحصول على Erişilebilirlik Logosu. لن تستوفي المؤسسات التي تفشل في توفير تنقل متسق عبر خدماتها الرقمية ملف الامتثال الكامل للمستوى AA المطلوب للحصول على الاعتماد، بغض النظر عن أدائها في المعايير الأخرى.
تشمل أنواع الكيانات التالية التي يغطيها التعميم الرئاسي 2025/10، والتي يجب عليها بالتالي التعامل مع الامتثال لـ 3.2.3 كالتزام قانوني وليس مجرد توصية لأفضل الممارسات:
- المؤسسات العامة والهيئات الحكومية على جميع المستويات، بما في ذلك الوزارات والبلديات والهيئات التابعة للدولة، والتي يجب أن تكون مواقعها الإلكترونية وبواباتها الرقمية قابلة للتنقل بشكل متسق عبر جميع الأقسام.
- منصات التجارة الإلكترونية التي تعمل في تركيا، حيث يكون اتساق التنقل بالغ الأهمية نظرًا لأن المستخدمين ينتقلون بين الصفحة الرئيسية وصفحات الفئات والمنتجات وسلة التسوق والدفع — والتي تشترك عادةً في نفس شريط التنقل.
- البنوك والمؤسسات المالية الخاضعة للتنظيم بموجب قانون البنوك التركي، والتي يجب أن توفر بواباتها المصرفية عبر الإنترنت ومواقعها المعلوماتية تنقلًا متوقعًا لخدمة جميع العملاء، بما في ذلك ذوي الإعاقات المعرفية أو الحركية.
- المستشفيات ومقدمو الرعاية الصحية، حيث يعتمد المرضى — وغالبًا ما يكونون في حالات توتر — على التنقل المتسق للعثور على حجز المواعيد ونتائج الفحوصات ومعلومات الاتصال في حالات الطوارئ دون احتكاك معرفي.
- شركات الاتصالات التي لديها 200,000 مشترك أو أكثر، والتي يجب أن تحافظ بوابات العملاء ومواقع الدعم وواجهات إدارة الحسابات لديها على اتساق التنقل عبر آلاف الصفحات والقوالب الموجهة للمستخدمين المحتملين.
- وكالات السفر وشركات النقل الخاصة، حيث يجب أن تقدم تدفقات الحجز متعددة الخطوات التي تمتد عبر صفحات البحث والاختيار وتفاصيل الركاب والدفع التنقل بنفس الترتيب المتسق طوال الرحلة.
- المدارس الخاصة المرخّصة من وزارة التربية الوطنية (MoNE)، والتي تخدم مواقعها الإلكترونية الطلاب وأولياء الأمور والموظفين — بما في ذلك الأفراد ذوي صعوبات التعلم الذين يعتمدون بشكل كبير على التنقل المتوقع للوصول إلى الموارد التعليمية.
بالنسبة للمنظمات في تركيا التي تبني أو تدقق خدمات رقمية، يجب دمج 3.2.3 في عملية ضمان الجودة في مرحلة تصميم القوالب والمكوّنات. يُعد استخدام مكوّن تنقل مشترك يُعرَض من مصدر واحد للحقيقة — سواء كان تضمينًا من جهة الخادم، أو مكوّن إطار عمل في الواجهة الأمامية، أو عنصرًا عالميًا في نظام إدارة محتوى عديم الرأس (headless CMS) — هو النهج التقني الأكثر موثوقية والموقف الأكثر دفاعًا عنه من منظور الامتثال بموجب متطلبات التعميم. يجب أن تتضمن تدقيقات الإتاحة المقدمة كجزء من عملية التقدم للحصول على Erişilebilirlik Logosu التحقق من ترتيب التنقل عبر الصفحات كخطوة اختبار موثقة.
