WCAG 1.3.4: الاتجاه

ماذا يعني هذا المعيار

المعيار WCAG 1.3.4 Orientation هو معيار من مستوى AA تم تقديمه في WCAG 2.1 واستمر في WCAG 2.2. ينص هذا المعيار على أن المحتوى يجب ألا يقيّد نفسه باتجاه عرض واحد فقط — إما عمودي (رأسي) أو أفقي (أفقي) — ما لم يكن هذا الاتجاه المحدد أساسياً لوظيفة المحتوى. عملياً، يعني هذا أن صفحات الويب والتطبيقات المعتمدة على الويب يجب أن تستجيب بشكل صحيح وتظل قابلة للتشغيل بالكامل بغض النظر عما إذا كان جهاز المستخدم ممسوكاً عمودياً أو أفقياً، أو ما إذا كان التحكم في الاتجاه يتم بواسطة نظام تشغيل الجهاز أو تفضيلات المستخدم نفسه.

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

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

ما الذي يُعد إخفاقاً: المحتوى الذي يخفي أو يعطل أو يمنع التفاعل في أحد الاتجاهين؛ الرسائل التي تطلب من المستخدمين تدوير أجهزتهم دون توفير بديل يعمل؛ شيفرات JavaScript التي تستمع إلى DeviceOrientationEvent أو screen.orientation ثم تقوم بقفل أجزاء من واجهة المستخدم أو تعطيلها؛ أو CSS التي تستخدم @media (orientation: portrait) لعرض طبقة حجب أو display: none على محتوى حرج.

الاستثناء المتعلق بالأساسية (essential): يقر WCAG بأن بعض المحتوى له غرض يعتمد بطبيعته على اتجاه معين. قد يتطلب تطبيق لوحة مفاتيح البيانو بشكل مشروع الوضع الأفقي لأن التخطيط العمودي لا يمكنه عرض عدد كافٍ من المفاتيح ليكون مفيداً موسيقياً. قد تتطلب ميزة إيداع الشيكات البنكية التي تعتمد على التقاط الكاميرا لشيك أفقي الوضع الأفقي. قد تتطلب واجهة نظارة الواقع الافتراضي اتجاهاً ثابتاً لتعمل. ومع ذلك، فإن معيار "الأساسي" مرتفع — فمجرد راحة المطور أو التفضيل الجمالي لا يفيان بالشرط. يجب أن يكون الاستثناء مبرراً بمتطلب جوهري في المحتوى نفسه، وليس خياراً تصميمياً.

لماذا يهم هذا المعيار

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

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

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

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

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

قواعد Axe-core ذات الصلة

يتطلب المعيار WCAG 1.3.4 Orientation إجراء اختبار يدوي. لا توجد قاعدة آلية في axe-core تكتشف قيود الاتجاه بشكل موثوق، لأن المخالفة تعتمد على سلوك وقت التشغيل ومنطق العرض الشرطي والحالة الفيزيائية للجهاز — وهي أمور لا يمكن لتحليل DOM الثابت أو فحص الصفحات الآلي تقييمها. يوضح ما يلي سبب قصور الأتمتة وما الذي يجب على المختبرين اليدويين البحث عنه:

• لا توجد قاعدة axe-core آلية (يتطلب اختباراً يدوياً): تقوم أدوات الفحص الآلي لإمكانية الوصول مثل axe-core أو Lighthouse أو IBM Equal Access Checker بتحليل DOM وCSSOM في نقطة زمنية واحدة. لا يمكنها محاكاة تدوير الجهاز أو تقييم ما يحدث للتخطيط عند تغيّر screen.orientation أو تحديد ما إذا كان جزء CSS @media (orientation: landscape) يخفي محتوى حرجاً. قد يرى الفاحص أن جميع العناصر موجودة ومرئية تقنياً في الاتجاه الذي تم اختباره، دون أن يعرف أن نصفها يختفي في الاتجاه الآخر. لهذا السبب يُصنَّف المعيار WCAG 1.3.4 على أنه يتطلب اختباراً يدوياً — فلا يمكن لأي أداة أن تحل محل تدوير جهاز حقيقي فعلياً أو محاكاة التدوير في أدوات المطور في المتصفح.
• اكتشاف قفل الاتجاه في JavaScript: لا يمكن لتحليل ثابت اكتشاف السكربتات التي تستدعي screen.orientation.lock() أو تستمع إلى window.addEventListener('orientationchange', ...) من أجل إعادة التوجيه أو تعطيل المحتوى. يمكن لأداة فحص الشيفرة أن تشير إلى استخدام هذه الواجهات في الشيفرة المصدرية، لكنها لا تستطيع تحديد ما إذا كان السلوك الناتج يشكل مخالفة لـ WCAG دون حكم بشري حول ما إذا كان الاستثناء المتعلق بالأساسية ينطبق.
• طبقات الحجب المعتمدة على CSS: قد تستخدم ورقة الأنماط @media (orientation: portrait) { .orientation-warning { display: block; } } لعرض رسالة حجب بملء الشاشة في الوضع العمودي. لن يصادف axe-core، الذي يفحص الصفحة في الوضع الأفقي، هذا العنصر في حالة مرئية ولن يبلغ عن مشكلة. لا يكشف المخالفة إلا الاختبار في الوضع العمودي — أو فحص CSS بحثاً عن أنماط حجب مشروطة بالاتجاه.

كيفية الاختبار

1. تشغيل فحص آلي كنقطة أساس: افتح الصفحة في Chrome أو Firefox أو Edge. استخدم إضافة المتصفح axe DevTools أو شغّل تدقيق إمكانية الوصول في Lighthouse لتأسيس خط أساس. على الرغم من أن هذه الأدوات لن تكتشف مخالفات الاتجاه مباشرة، إلا أنها قد تشير إلى مشكلات ذات صلة بالتصميم المتجاوب أو مشكلات وسم viewport أو ARIA مفقودة تزيد من تعقيد إخفاقات إمكانية الوصول المتعلقة بالاتجاه. لاحظ أن تقريراً آلياً خالياً من الأخطاء لا يؤكد الامتثال للمعيار 1.3.4.
2. استخدام محاكاة الأجهزة في أدوات المطور بالمتصفح: في Chrome أو Edge، افتح DevTools (F12)، انقر على أيقونة شريط أدوات الجهاز (Ctrl+Shift+M / Cmd+Shift+M)، واختر جهازاً محمولاً مثل iPhone 14 أو Galaxy S21. بدّل بين الاتجاهين العمودي والأفقي باستخدام أيقونة التدوير في شريط أدوات الجهاز. تحقق بشكل منهجي من أن كل المحتوى — التنقل والعناوين والنص الأساسي والنماذج والأزرار والصور والوسائط — يظل مرئياً وقابلاً للتشغيل في كلا الاتجاهين. ابحث عن طبقات حجب أو أقسام مخفية أو عناصر تفاعلية معطلة تظهر في أحد الاتجاهين دون الآخر.
3. الاختبار على أجهزة حقيقية: صِل جهاز Android أو iOS وافتح الصفحة في متصفح الهاتف المحمول. قم بتدوير الجهاز جسدياً بين الوضعين العمودي والأفقي. تأكد من أن قفل الاتجاه في نظام التشغيل (عند تفعيله) لا يتسبب في تعطل المحتوى أو عرض مطالبة بالتدوير. اختبر مع قفل الاتجاه في حالتي التشغيل والإيقاف.
4. اختبار قارئ الشاشة مع محاكاة الاتجاه: على iOS مع تفعيل VoiceOver (النقر الثلاثي على زر الجانب)، تنقل في الصفحة في الوضع العمودي باستخدام إيماءات السحب. ثم قم بالتدوير إلى الوضع الأفقي وتحقق من أن ترتيب القراءة والأسماء المتاحة في VoiceOver تظل صحيحة. على Android مع TalkBack، نفّذ الاختبار نفسه. استخدم NVDA مع Firefox على سطح المكتب وحاكِ الاتجاه عبر DevTools للتحقق من أن شجرة إمكانية الوصول متسقة عبر الاتجاهات.
5. فحص CSS وJavaScript بحثاً عن قيود الاتجاه: في DevTools، افتح لوحة Sources أو Elements وابحث في ورقة الأنماط عن استعلامات الوسائط orientation: portrait وorientation: landscape. راجع ما يفعله كل جزء: هل يخفي المحتوى باستخدام display: none أو يطبق طبقة حجب، أم أنه يضبط التخطيط فقط؟ ابحث في ملفات JavaScript عن screen.orientation وorientationchange وscreen.orientation.lock. قيّم ما إذا كانت الأنماط الموجودة تقفل واجهة المستخدم أو تحجب المحتوى.
6. التحقق من الاستثناء المتعلق بالأساسية: إذا كان الموقع يقيّد الاتجاه عمداً، فتحقق من وجود حالة استخدام أساسية موثقة ومبررة. يجب أن يكون الاستثناء مدفوعاً بالمحتوى، لا تجميلياً. وثّق نتيجتك بلقطة شاشة والتبرير المحدد.

كيفية الإصلاح

طبقة حجب CSS في الوضع العمودي — غير صحيح

<!-- A full-screen overlay shown only in portrait that blocks all content -->
<style>
  .rotate-prompt {
    display: none;
    position: fixed;
    inset: 0;
    background: #fff;
    z-index: 9999;
    text-align: center;
    padding: 2rem;
  }
  @media (orientation: portrait) {
    .rotate-prompt {
      display: flex; /* blocks all underlying content */
    }
  }
</style>
<div class='rotate-prompt'>
  <p>Please rotate your device to landscape mode.</p>
</div>
<main id='app-content'>
  <!-- All application content here -->
</main>

طبقة حجب CSS في الوضع العمودي — صحيح

<!-- Remove the blocking overlay entirely. Use responsive CSS to adapt the layout instead. -->
<style>
  /* Portrait layout: stack elements vertically */
  @media (orientation: portrait) {
    .dashboard-grid {
      grid-template-columns: 1fr;
    }
  }
  /* Landscape layout: side-by-side columns */
  @media (orientation: landscape) {
    .dashboard-grid {
      grid-template-columns: 1fr 1fr;
    }
  }
</style>
<main id='app-content'>
  <div class='dashboard-grid'>
    <!-- Content adapts layout but is always accessible -->
  </div>
</main>

قفل الاتجاه في JavaScript — غير صحيح

<script>
  // Locks screen to landscape and shows an error if it fails (e.g. on iOS)
  screen.orientation.lock('landscape').catch(function() {
    document.getElementById('orientation-error').style.display = 'block';
    document.getElementById('main-content').style.display = 'none';
  });
</script>
<div id='orientation-error' style='display:none'>
  This application only works in landscape mode.
</div>
<div id='main-content'>
  <!-- Application content -->
</div>

قفل الاتجاه في JavaScript — صحيح

<script>
  /*
    Do not lock orientation via JavaScript.
    Instead, listen for orientation changes and adapt the UI
    without hiding or disabling content.
  */
  window.addEventListener('orientationchange', function() {
    var isPortrait = window.matchMedia('(orientation: portrait)').matches;
    // Adjust layout class for styling only — never hide content
    document.body.classList.toggle('portrait-layout', isPortrait);
    document.body.classList.toggle('landscape-layout', !isPortrait);
  });
</script>
<div id='main-content'>
  <!-- All content remains visible and operable in both orientations -->
</div>

وسم viewport الذي يمنع تغيير الاتجاه — غير صحيح

<!-- Some older implementations tried to fix orientation via viewport -->
<meta name='viewport' content='width=device-width, initial-scale=1, user-scalable=no'>
<!--
  While 'user-scalable=no' does not directly lock orientation,
  combining it with CSS transforms that rotate the viewport
  is a known anti-pattern that creates orientation accessibility failures.
-->
<style>
  /* Anti-pattern: rotating the entire body to simulate landscape on a portrait device */
  @media (orientation: portrait) {
    body {
      transform: rotate(90deg);
      transform-origin: left top;
      width: 100vh;
      overflow-x: hidden;
    }
  }
</style>

وسم viewport الذي يمنع تغيير الاتجاه — صحيح

<!-- Use a standard responsive viewport tag. Never rotate the body via CSS transforms. -->
<meta name='viewport' content='width=device-width, initial-scale=1'>
<!--
  Let the browser and operating system handle orientation naturally.
  Design responsively so the content works at all viewport aspect ratios.
  Use CSS Grid and Flexbox to reflow content, not transforms.
-->

الأخطاء الشائعة

• استخدام @media (orientation: portrait) لتطبيق display: none على قوائم التنقل أو الأشرطة الجانبية أو مناطق المحتوى الرئيسية. أي استعلام وسائط في CSS يعتمد على الاتجاه ويزيل المحتوى من العرض — بدلاً من إعادة تموضعه فقط — هو مخالفة محتملة. راجع كل استعلام وسائط يعتمد على الاتجاه في ورقة الأنماط للتأكد من أنه يغيّر التخطيط فقط، لا توفر المحتوى.
• استدعاء screen.orientation.lock() في التطبيقات غير الأساسية. تم تصميم واجهة الويب هذه للألعاب وحالات استخدام وسائط محددة. استخدامها في تطبيق ويب عادي أو موقع تجارة إلكترونية لـ "تحسين الجمالية" في الوضع الأفقي لا يفي بشروط الاستثناء المتعلق بالأساسية ويخلق مخالفة مباشرة للمعيار WCAG 1.3.4.
• عرض شاشة ترحيبية "قم بتدوير جهازك" دون بديل قابل للوصول. حتى إذا تم عرض تلميح اتجاه لفترة وجيزة، يجب ألا يحجب الوصول إلى المحتوى أبداً. إذا تم عرضه على الإطلاق، فيجب أن يكون قابلاً للإغلاق، وألا يغطي المحتوى الرئيسي، وأن يُقدَّم كتوصية لا كشرط.
• افتراض أن مستخدمي الأجهزة المحمولة يفضلون دائماً الوضع الأفقي لمحتوى الفيديو. تضمين مشغل فيديو يعطل عناصر التحكم في التشغيل أو زر التشغيل في الوضع العمودي — مما يجبر المستخدمين على التدوير قبل أن يتمكنوا من التفاعل — يخالف المعيار 1.3.4 ما لم يكن من المستحيل فعلياً عرض تنسيق الفيديو في الوضع العمودي (وهو أمر نادر جداً بالنسبة للفيديو على الويب القياسي).
• تطبيق CSS transform: rotate(90deg) على عنصر <body> أو حاوية جذرية في أحد الاتجاهين. هذا يحاكي تغيير الاتجاه في CSS بدلاً من السماح للجهاز بالتعامل معه بشكل طبيعي، مما يخلق تخطيطات مكسورة ومحتوى خارج الشاشة وتشويشاً شديداً في شجرة إمكانية الوصول لقارئات الشاشة.
• الفشل في اختبار سلوك الاتجاه أثناء ضمان الجودة لأن الفرق تختبر فقط على متصفحات سطح المكتب. لا يتم دائماً استخدام محاكاة الاتجاه في DevTools بمتصفح سطح المكتب أثناء دورات ضمان الجودة القياسية. يجب أن يكون الاتجاه بنداً صريحاً في خطط الاختبار على الأجهزة المحمولة، يتم التحقق منه على أجهزة حقيقية تعمل بنظامي iOS وAndroid.
• تجاوز سلوك الاتجاه داخل iframes دون مراعاة حالة اتجاه الصفحة الأم. قد تقوم الودجات الخارجية والخرائط المضمّنة وiframes الدفع بقفل الاتجاه بشكل مستقل. حتى إذا كانت صفحتك متوافقة، فإن استضافة iframe مقفول الاتجاه تجعل صفحتك غير متوافقة ما لم يكن الاستثناء المتعلق بالأساسية في iframe موثقاً.
• استخدام كشف وكيل المستخدم على الخادم لتقديم نسخة "أفقية فقط" من الصفحة لمستخدمي الأجهزة المحمولة. إعادة توجيه مستخدمي الأجهزة المحمولة إلى عنوان URL منفصل يعمل فقط في الوضع الأفقي، دون توفير بديل متوافق مع الوضع العمودي، هي مخالفة منهجية تخلق أيضاً مشكلة في تحسين محركات البحث وتوحيد عناوين URL (canonicalization).
• تطبيق قيود الاتجاه فقط في إصدارات الإنتاج، مما يجعلها غير مرئية أثناء اختبار التطوير. تقوم أطر عمل الأعلام الوظيفية أو اختبارات A/B أحياناً بتفعيل شيفرة قفل الاتجاه فقط في بيئات محددة أو لشرائح مستخدمين معينة، مما يؤدي إلى عدم اكتشاف المخالفة أثناء عمليات تدقيق إمكانية الوصول قبل الإطلاق.
• افتراض أن الاستثناء المتعلق بالأساسية ينطبق لأن المصمم يفضل التخطيط الأفقي. الاستثناء المتعلق بالأساسية هو معيار قانوني وأخلاقي مرتفع. يتطلب أن تكون الوظيفة الأساسية للمحتوى مستحيلة جوهرياً في الاتجاه الآخر — لا أن تبدو أفضل فحسب أو أن الفريق لم يكن لديه الوقت لتنفيذ تخطيط متجاوب للوضع العمودي.

العلاقة مع لوائح إمكانية الوصول في تركيا

تضع التعميم الرئاسي رقم 2025/10 في تركيا، المنشور في الجريدة الرسمية (Resmî Gazete) رقم 32933 بتاريخ 21 يونيو 2025، إطاراً وطنياً شاملاً لإمكانية الوصول الرقمي. يفرض التعميم على الكيانات المشمولة الامتثال لـ WCAG 2.2 مستوى AA، والذي يتضمن صراحة المعيار WCAG 1.3.4 Orientation. هذا يعني أن أي خدمة رقمية أو موقع إلكتروني تديره جهة مشمولة يجب ألا يقيّد المحتوى باتجاه واحد فقط، بما يعكس هدف التعميم في ضمان أن جميع المواطنين — بما في ذلك الأشخاص ذوو الإعاقة — يمكنهم الوصول إلى الخدمات الرقمية بغض النظر عن كيفية تفاعلهم جسدياً مع أجهزتهم.

تشمل الكيانات المشمولة بالتعميم والمطلوب منها تحقيق مطابقة مستوى AA: المؤسسات والهيئات العامة (جميع الهيئات الحكومية التي تدير مواقع إلكترونية وخدمات رقمية)، والبنوك والمؤسسات المالية، والمستشفيات ومقدمو الرعاية الصحية، وشركات الاتصالات التي لديها 200,000 مشترك أو أكثر، ومنصات التجارة الإلكترونية، ووكالات السفر، وشركات النقل الخاصة، والمدارس الخاصة المرخصة من قبل وزارة التربية الوطنية (MoNE). بالنسبة لهذه الكيانات، تشكل قيود الاتجاه التي تنتهك المعيار 1.3.4 — مثل البوابات الحكومية التي تطلب الوصول في الوضع الأفقي فقط أو تطبيقات البنوك التي تُقفل على الوضع العمودي لأسباب غير أساسية — حالات عدم امتثال مباشر للوائح الوطنية الملزمة.

يُعد شعار إمكانية الوصول (Erişilebilirlik Logosu)، الصادر عن وزارة الأسرة والخدمات الاجتماعية (Aile ve Sosyal Hizmetler Bakanlığı)، علامة اعتماد تشير إلى المطابقة للمعيار الوطني لإمكانية الوصول. يُعد تحقيق مطابقة مستوى AA شرطاً مسبقاً للحصول على هذا الشعار. يجب على المنظمات التي تسعى للحصول على Erişilebilirlik Logosu أن تُثبت أن ممتلكاتها الرقمية تجتاز جميع معايير المستوى A والمستوى AA، بما في ذلك 1.3.4. يمكن أن يؤدي إخفاق في قيود الاتجاه — حتى في قسم ثانوي من الموقع — إلى تعريض شهادة الاعتماد بأكملها للخطر.

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