الإجابة باختصار: النص الأساسي للمتاجر الإلكترونية في قانون إمكانية الوصول إلى الويب (Web Accessibility) في تركيا هو تعميم إمكانية الوصول إلى الويب (التعميم الرئاسي رقم 2025/10). ويُلزم هذا التعميم مقدّمي الخدمات الذين يزاولون التجارة الإلكترونية بموجب القانون رقم 6563، وهو قانون التجارة الإلكترونية التركي، بجعل مواقعهم الإلكترونية وتطبيقات الجوال التابعة لهم متوافقة مع «قائمة التحقق – المستوى A» الصادرة عن وزارة الأسرة والخدمات الاجتماعية ومع معيار WCAG 2.2 بحلول يونيو 2027. وتحوّل قائمة التحقق معايير المستوى A البالغ عددها 31 معيارًا في WCAG 2.2 إلى 126 سؤالًا، ويجري تقييم كل صفحة ويب وكل شاشة تطبيق على حدة. ويقضي التوجيه التنفيذي (Yönerge) بتشكيل لجنة مراجعة لا يقل عدد أعضائها عن ثلاثة، وبإجراء مراجعة على ثلاث مراحل: اختبارات آلية، واختبارات يدوية، واختبارات مع مستخدمين من ذوي الإعاقة. ولا يفرض التعميم غرامة مباشرة، غير أن نتائج الرصد ستُعلن للجمهور، وقد تصبح الخدمة الرقمية التي لا تحقق إمكانية الوصول موضوع شكوى تمييز أمام الهيئة الوطنية لحقوق الإنسان والمساواة في تركيا (TİHEK).
أعددنا هذا الدليل لأصحاب متاجر التجزئة الإلكترونية ومديري التجارة الإلكترونية ومسؤولي تقنية المعلومات أو المنتجات فيها، ممن لديهم متجر إلكتروني أو تطبيق iOS/Android خاص بهم. وهو موجَّه أيضًا إلى العلامات التجارية الدولية التي تبيع في تركيا أو تتعاون مع شركاء تجارة إلكترونية أتراك. ويمكن لمؤسسات الموجة الأولى، مثل البنوك والمستشفيات الخاصة، التي انتهت مهلتها في يونيو 2026، اتباع الخطوات نفسها. لم نعتمد على الملخصات الإخبارية، بل قرأنا التعميم، وقائمة التحقق، ودليل الشعار، والتوجيه التنفيذي، والقوانين ذات الصلة، ومصادر TİHEK وW3C من نصوصها الأصلية مباشرةً. ولا يُعدّ ما ورد هنا استشارة قانونية. هذا المقال محدّث حتى 31 أكتوبر 2026.
ماذا ينظّم قانون إمكانية الوصول إلى الويب في تركيا؟ أربع وثائق رسمية في جدول واحد
الأساس القانوني هو القانون رقم 5378 بشأن الأشخاص ذوي الإعاقة:
«يُكفل أن تكون خدمات المعلومات وتكنولوجيا المعلومات والاتصالات متاحة للأشخاص ذوي الإعاقة.» (القانون رقم 5378، المادة 7؛ ترجمتنا)
وتحدّد أربع وثائق التفاصيل:
| الوثيقة | ماذا تنظّم؟ | ما تعنيه للتجارة الإلكترونية |
|---|---|---|
| التعميم رقم 2025/10 (الجريدة الرسمية التركية، 21 يونيو 2025) | النطاق والمهل؛ ولجان الرصد والاستشارة والمراجعة؛ وحق استخدام الشعار لمدة عامين | مهلة عامين: يونيو 2027 |
| التوجيه الخاص بإجراءات التنفيذ ومبادئه (لم يُذكر تاريخ الاعتماد) | اللجان، وأسلوب المراجعة، والاستثناءات، وإجراءات الشعار | لجنة من 3 أشخاص على الأقل، واختبار على ثلاث مراحل |
| قائمة التحقق – المستوى A (الإصدار V2.2.30.01 الصادر في أنقرة عام 2026) | معايير المستوى A في WCAG 2.2 وعددها 31 معيارًا، في صورة 126 سؤالًا | تُقيَّم كل صفحة وكل شاشة تطبيق على حدة |
| دليل استخدام شعار إمكانية الوصول (عُدّل في 14 أبريل 2026) | كيفية استخدام الشعار في المواقع الإلكترونية وتطبيقات الجوال | يُستخدم فقط في المواقع والتطبيقات التي مُنحت هذا الحق |
نقطتان يكثر الخلط فيهما:
- التعميم رقم 2026/1 ليس خطة للويب. تقتصر خطة الرصد والتفتيش الواردة في هذا التعميم، المؤرخ في 21 يناير 2026، على المباني والأماكن المفتوحة ومركبات النقل العام. وحتى 31 أكتوبر 2026، لم نعثر على خطة الرصد المرتقبة للويب والجوال في صفحات إمكانية الوصول والتشريعات لدى المديرية العامة لخدمات ذوي الإعاقة وكبار السن (EYHGM) التابعة للوزارة. ولذلك من السابق لأوانه القول إن «عمليات تدقيق التجارة الإلكترونية قد بدأت».
- لا يبدو أن دليل WCAG 2.2 باللغة التركية قد صدر بعد. فالدليل الذي أعلن عنه التعميم غير موجود في صفحة إمكانية الوصول لدى الوزارة، كما تدرج W3C الترجمة التركية المعتمدة بوصفها «مخططًا لها» (إشعار النية: 5 مايو 2026). لذا اعتمد النص الإنجليزي لمعيار WCAG 2.2 الصادر عن W3C مرجعًا لك.
ملاحظة بشأن التوجيه التنفيذي: تُدرج الوزارة التوجيه التنفيذي في صفحة التوجيهات الخاصة بمديرية EYHGM (Yönergeler). وفي 31 أكتوبر 2026 كان رابط الوثيقة هناك فارغًا، لكن نص ملف PDF متاح على موقع الوزارة. ولا يحمل النص تاريخ اعتماد، وبموجب المادة 19 يدخل حيز النفاذ في تاريخ اعتماده. وتستند المعلومات الواردة أدناه عن التوجيه التنفيذي إلى هذا النص، لذا تابع أي تحديثات تصدر عن الوزارة.
من يشمل التعميم في قطاع التجارة الإلكترونية، وهل توجد غرامة على عدم الامتثال؟
النطاق: كل من لديه موقع أو تطبيق خاص به
يذكر التعميم مقدّمي الخدمات الذين يزاولون التجارة الإلكترونية بموجب القانون رقم 6563. ولا يحدد أي حد أدنى للحجم، ولا يستثني الشركات متناهية الصغر. وبموجب القانون رقم 6563، فإن مقدّم الخدمة هو شخص طبيعي أو اعتباري يزاول التجارة الإلكترونية، وبيئة التجارة الإلكترونية هي الموقع الإلكتروني أو موقع الجوال أو تطبيق الجوال. وتدخل العلامة التجارية التي تملك متجرًا أو تطبيقًا خاصًا بها في النطاق بوضوح. أما الحالتان التاليتان فغير واضحتين:
- البائعون الذين يقتصر بيعهم على الأسواق الإلكترونية (Marketplace): يعدّ القانون رقم 6563 من يبيعون في السوق الإلكتروني أيضًا «مقدّمي خدمات تجارة إلكترونية». غير أن بيئة البيع تعود إلى السوق الإلكتروني، ولا توجد قاعدة تبيّن كيفية انطباق الالتزام على البائع.
- المؤسسات الفردية: يعرّف التوجيه التنفيذي اللجنة بعبارتي «المؤسسات والهيئات والأشخاص الاعتباريون» و«ثلاثة موظفين على الأقل»، لذا لا يتضح كيف تنطبق القاعدة عليها.
اطلب رأي الوزارة أو مستشارك القانوني بشأن هاتين النقطتين. أما مؤسسات الموجة الأولى، مثل البنوك والمستشفيات الخاصة ومؤسسات التعليم الخاصة وشركات نقل الركاب، فقد انتهت مهلتها البالغة عامًا واحدًا في يونيو 2026.
العقوبات: لا غرامة في التعميم، لكن المخاطر في مواضع أخرى
- لا يفرض التعميم ولا التوجيه التنفيذي غرامات إدارية. غير أن الوزير سيعلن نتائج الرصد للجمهور.
- الغرامات الواردة في القانون رقم 5378 لا تتعلق بالمواقع الإلكترونية. فالغرامات الواردة في مادته المؤقتة 3 تتعلق بالمباني والأماكن المفتوحة والنقل العام. أما مبلغ «من 5,000 إلى 25,000 ليرة تركية عن كل مخالفة مرصودة» الذي تذكره بعض الأدلة، فهو النطاق الذي يحدده هذا الحكم للبلديات والجهات العامة. وبالنسبة إلى الأشخاص الطبيعيين والأشخاص الاعتباريين الخاضعين للقانون الخاص، يبلغ المبلغ الاسمي في نص القانون من 1,000 إلى 5,000 ليرة تركية عن كل مخالفة مرصودة.
- مسار TİHEK خطر حقيقي. يحظر القانون رقم 6701 المنشئ لهيئة TİHEK التمييز على أساس الإعاقة، ويعدّ عدم توفير الترتيبات التيسيرية المعقولة تمييزًا. كما يشمل الأشخاص الطبيعيين والأشخاص الاعتباريين الخاضعين للقانون الخاص الذين يقدّمون «خدمات مماثلة». وتبلغ الغرامة الإدارية بموجب الفقرة 1 من المادة 25 من 17,052 إلى 256,357 ليرة تركية في عام 2026، ويجوز لمجلس الهيئة تحويل الغرامة إلى إنذار مرة واحدة. وفي القرار رقم 2024/403، خلصت الهيئة إلى وقوع انتهاك لأن أجزاءً من الخدمات المصرفية عبر الإنترنت والجوال لدى أحد البنوك لم تكن قابلة للقراءة بقارئ الشاشة.
- إذا كنت تبيع للمستهلكين في ألمانيا، فانتبه إلى قانون BFSG الألماني. وهو القانون الذي ينقل القانون الأوروبي لإمكانية الوصول (التوجيه (EU) 2019/882) إلى التشريع الألماني. ويشمل خدمات التجارة الإلكترونية المقدَّمة للمستهلكين بعد 28 يونيو 2025، وقد تصل غرامة تقديم خدمة غير مطابقة إلى 100,000 يورو. وتُستثنى الشركات متناهية الصغر التي تقدّم خدمات، وهي الشركات التي يقل عدد موظفيها عن 10 ولا يتجاوز رقم أعمالها السنوي أو إجمالي ميزانيتها العمومية مليوني يورو.
كيف تقرأ قائمة التحقق الخاصة بإمكانية الوصول (المستوى A)؟
تحوّل قائمة التحقق الصادرة عن الوزارة لعام 2026 (V2.2.30.01) معايير النجاح البالغ عددها 31 معيارًا ضمن المبادئ الأربعة في WCAG 2.2 إلى 126 سؤالًا مرقّمًا. ونشير إليها بالرموز من س1 إلى س126. وهناك ثلاثة أنواع من الأسئلة:
- ★ (64 سؤالًا): شرط إلزامي. الإجابة «لا» تعني الحاجة إلى إصلاح.
- ★★ (3 أسئلة): شرط يجب ألا يتحقق. الإجابة «نعم» تعني الحاجة إلى إصلاح: معلومات تُقدَّم بالاعتماد على اللون وحده (س52)، ووميض يتجاوز العتبات المحددة (س81)، وتغيّر في السياق لمجرد تلقي عنصر ما التركيز (س106).
- بلا نجمة (59 سؤالًا): تحديد المسار. فعلى سبيل المثال، يسأل أحد الأسئلة عمّا إذا كانت الصفحة تتضمن اختبار CAPTCHA أم لا، وتحدد الإجابة القسم الذي تنتقل إليه بعد ذلك.
القاعدة الحاسمة: تُجاب الأسئلة بصورة منفصلة لكل صفحة ويب وكل شاشة تطبيق. وفي متجر يضم آلاف صفحات المنتجات، يعني ذلك العمل قالبًا تلو الآخر: الصفحة الرئيسية، والفئة، وتفاصيل المنتج، وسلة المشتريات، وخطوات إتمام الشراء، والحساب، وصفحات الحملات. فالإصلاح في قالب واحد ينتقل إلى كل صفحة تستخدمه. وبموجب التوجيه التنفيذي، ستحدد لجنة الرصد طريقة اختيار عينات الصفحات أثناء الرصد.
تغطي قائمة التحقق المستوى A فقط. أما تباين الألوان (1.4.3)، ووضوح التركيز (2.4.7)، وحجم الهدف (2.5.8) فهي من معايير المستوى AA ولذلك تقع خارج الحد الأدنى القانوني. ومع ذلك نوصي بدمجها في نظام التصميم لديك منذ البداية: ففي تحليل WebAIM لعام 2026، يُعدّ التباين المنخفض الخطأ الأكثر شيوعًا، إذ ظهر في 83.9% من الصفحات الرئيسية. ولا يجوز نسخ قائمة التحقق لأغراض تجارية، ولذلك نشرح منطقها بدلًا من نقل أسئلتها. نزّل النسخة الحالية من موقع الوزارة.
ماذا يشترط التوجيه التنفيذي لإمكانية الوصول؟ اللجنة والاختبارات والاستثناءات والشعار
لجنة المراجعة: ثلاثة أشخاص على الأقل من موظفيك
بموجب المادة 13 من التوجيه التنفيذي، تشكّل كل مؤسسة وكل شخص اعتباري خاضع للرصد لجنة مراجعة (İnceleme Komisyonu) تضم ثلاثة موظفين على الأقل، يعمل واحد منهم على الأقل في وحدة الويب/الجوال. وتتعارض النصيحة الواردة في بعض الأدلة بأن «فريقًا أساسيًا من شخصين يكفي» مع المادة 13. وفي السنة التي تُدرج فيها ضمن خطة الرصد (İzleme Planı)، تُعدّ اللجنة تقرير مراجعة وفق صيغة تلك الخطة وترسله إلى الأمانة في المديرية العامة (EYHGM). كما تتابع الإصلاحات وتُعدّ تقريرًا محدَّثًا لتجديد الشعار.
كيف يُجرى اختبار إمكانية الوصول؟ ثلاث مراحل
- الاختبار الآلي: باستخدام أدوات من القائمة المنشورة على موقع W3C الإلكتروني. وحتى 31 أكتوبر 2026، تضم قائمة W3C 119 أداة، وفيها عوامل تصفية لنظامي التشغيل Android وiOS ضمن خياراتها، وتشمل القائمة WAVE وaxe DevTools (ولا تزكّي W3C منتجات بعينها).
- الاختبار اليدوي: النماذج، وعناصر التحكم في الواجهة، ومربعات الحوار، وتأكيدات إدخال البيانات، ورسائل الخطأ، والتغذية الراجعة، ولوحة المفاتيح، والمحتوى غير النصي مثل الصور والفيديو وCAPTCHA والصوت.
- الاختبار مع مستخدمين من ذوي الإعاقة: بمشاركة مستخدمين من ذوي الإعاقة البصرية (مستخدمو قارئات الشاشة وضعاف البصر)، والإعاقة السمعية (الصم وضعاف السمع)، والإعاقة الحركية (ذوو القدرة المحدودة على استخدام الفأرة ولوحة المفاتيح). ويوصى أيضًا بالاختبار مع مستخدمين من ذوي الإعاقات الإدراكية، والمصابين باضطراب طيف التوحد، ومن لديهم صعوبات تعلم محددة، والمصابين بعمى الألوان.
لماذا لا تكفي إضافة إمكانية الوصول (Overlay)؟
تشترط قائمة التحقق تعريف العلاقة بين التسميات وحقول النماذج، والتسلسل الهرمي للعناوين، «برمجيًا» في الكود، كما تشترط ضبط إدارة التركيز على نحو صحيح. أما الأداة المصغرة (Widget) التي تُضاف لاحقًا فتحاول ترقيع ذلك في المتصفح بالتخمين، وقد تتعطل عند تغيّر القوالب، ولا تصل إطلاقًا إلى شاشات iOS أو Android الأصلية (Native). ولا تتضمن أي من الوثائق الأربع حكمًا يعدّ الإضافة دليلًا على الامتثال. وبموجب التوجيه التنفيذي، تُشترط الاختبارات اليدوية والاختبارات مع المستخدمين من ذوي الإعاقة في جميع الحالات.
واعرف حدود الاختبار الآلي أيضًا. فبحسب تحليل WebAIM Million 2026 تحتوي 95.9% من الصفحات الرئيسية لأكبر مليون موقع إلكتروني على أخطاء WCAG مكتشفة آليًا. ويبلغ المتوسط 56.1 خطأ في الصفحة، مقابل 66.2 خطأ في الصفحات باللغة التركية و71.0 خطأ في فئة التسوق. أما مصيدة لوحة المفاتيح أو النص البديل عديم المعنى فلا يظهران عادةً إلا عندما يختبر الأشخاص الموقع. ويساعد دمج الفحوص الآلية في خط CI/CD لديك على منع عودة الأخطاء التي أُصلحت في الإصدارات الجديدة.
الاستثناءات: ما الذي يقع خارج النطاق؟
- المحتوى المضاف ديناميكيًا وتلقائيًا من مصادر أخرى: يذكر التوجيه التنفيذي الإعلانات الديناميكية وتقييمات التسوق مثالين على ذلك. والمستثنى هو المحتوى نفسه، لا نموذج التقييم أو مكوّن التصنيف في موقعك.
- الخرائط الإلكترونية، شريطة توفير المعلومات الأساسية اللازمة للتنقل في صورة قابلة للوصول.
- البث المباشر؛ غير أن تسجيل البث المحتفظ به في الموقع يجب أن يصبح قابلًا للوصول خلال 14 يومًا.
- مقاطع الفيديو والصوت المسجلة قبل التعميم، والمحتوى المؤرشف الذي لا يُحدَّث خلال عام واحد من دخول التعميم حيز النفاذ ولا تحتاج إليه العمليات الإدارية. أما مقاطع الفيديو الجديدة للمنتجات فتسري عليها الأسئلة المتعلقة بالترجمة النصية (Captions) والنصوص المفرغة والوصف الصوتي (س17-25).
ولا تُعدّ الترجمة بلغة الإشارة التركية (TİD) إلزامية لمحتوى الفيديو والصوت. وإذا وفّرتها، فيجب أن يكون المترجم قد حصل على 70 نقطة على الأقل في اختبار الكفاءة في لغة الإشارة التركية.
كيف تحصل على شعار إمكانية الوصول؟
لا يمكنك إضافة الشعار بنفسك، لكن يمكنك التقدم بطلب حق استخدامه إلى المديرية العامة (EYHGM). وتمنح لجنة الرصد هذا الحق لمدة عامين، على حدة للمواقع الإلكترونية التي تحقق إمكانية الوصول، وللتطبيقات التي تحققها على كل نظام تشغيل للجوال. ويتطلب التجديد تقرير مراجعة محدَّثًا يتبع خطة الرصد السارية. وبموجب دليل الشعار، بصيغته المحدَّثة في 14 أبريل 2026، لا يجوز استخدام الشعار إلا في الموقع أو التطبيق الذي مُنح الحق. ويجب أن يقود النقر عليه إلى صفحة التحقق في موقع EYHGM الرسمي، ولا يجوز استخدامه لتحقيق مكسب تجاري.
من واجهة المتجر إلى إتمام الشراء: أكثر المشكلات شيوعًا في مواقع التجارة الإلكترونية
مكوّنات المتجر المعتادة وأسئلة قائمة التحقق المرتبطة بها (بالترقيم الوارد في الإصدار V2.2.30.01):
| المكوّن | الأسئلة | ما يجب فعله |
|---|---|---|
| القائمة والكتل المتكررة | س36-37، س65-66، س82-83 | استخدم العنصر <nav> في التنقل. ويجب أن تُفتح القائمة الفرعية التي تُفتح بالفأرة بلوحة المفاتيح أيضًا. وأضف رابط «تخطَّ إلى المحتوى الرئيسي». |
| شريط العرض المتحرك (Slider) وشريط العروض الترويجية المتحرك | س75-78 | زر إيقاف مؤقت للحركة التلقائية التي تستمر أكثر من 5 ثوانٍ. |
| صور المنتجات | س1-5 | نص alt معبّر للصور التي تحمل معلومات؛ وalt="" للصور الزخرفية. |
| محدِّد اللون والمقاس | س16، س51-53 | أظهر حالة الاختيار أو نفاد المخزون نصًا إلى جانب اللون. وامنح كل عينة لون اسمًا قابلًا للوصول («أزرق كحلي»). |
| عوامل التصفية | س40-41، س107-108 | جمّع الخيارات باستخدام العنصرين <fieldset> و<legend> معًا. وإذا كان التحديد يعيد تحميل الصفحة تلقائيًا، فنبّه إلى ذلك مسبقًا أو أضف زر «تطبيق». |
| أزرار +/− في سلة المشتريات والأزرار الأيقونية | س15-16، س124-126 | أسماء قابلة للوصول مثل «زيادة الكمية» و«إضافة إلى سلة المشتريات»؛ وحدّث قيمة الكمية برمجيًا باستمرار. |
| العرض السريع، وإشعار ملفات تعريف الارتباط، والنافذة المنبثقة | س61-64، س69-70 | استخدم role="dialog" في النافذة المشروطة (Modal). وينبغي أن ينتقل التركيز إلى داخل النافذة، وأن تُغلق عند الضغط على Escape في لوحة المفاتيح، وأن يعود التركيز عند الإغلاق إلى الزر الذي فتحها أو إلى نقطة منطقية أخرى. |
| المهل الزمنية للجلسة وسلة المشتريات | س73-74 | اسمح للمستخدمين بإيقاف المهلة أو تمديدها إلى 10 أضعاف مدتها على الأقل، أو نبّههم قبل انتهائها بما لا يقل عن 20 ثانية واسمح لهم بتمديدها بإجراء واحد، 10 مرات على الأقل. |
| النماذج | س38-39، س111-120 | لا يحل النص التوضيحي (Placeholder) محل التسمية. اربط نص الخطأ بالحقل الخاص به. ولا تكفي علامة النجمة دون شرح، ولا الحد الأحمر وحده. |
| عنوان التسليم وعنوان الفوترة | س121-122 | خيار «عنوان الفوترة مطابق لعنوان التسليم» وسمات autocomplete للحقول. |
| CAPTCHA | س10-12 | نص يوضح الغرض منها وبديل لا يعتمد على حاسة واحدة. ولا يكفي اختبار CAPTCHA المرئي فقط أو الصوتي فقط. |
| الدعم المباشر، والأسئلة الشائعة، وروبوت الدردشة | س109-110 | رابط المساعدة في المكان نفسه المتوقع في كل صفحة. |
إعلان رسالة «أُضيف إلى سلة المشتريات» لقارئات الشاشة (WCAG 4.1.3) معيار من المستوى AA وليس ضمن قائمة التحقق. ومع ذلك نوصي به ممارسةً معتادة.
خطوة الدفع وبروتوكول 3D Secure
عادةً ما تكون شاشة 3D Secure صفحة تابعة للبنك أو لمزوّد خدمة الدفع، ولا يمكنك تغيير محتواها. ولا نوصي بالاعتماد على استثناء التوجيه التنفيذي الخاص بالمحتوى المضاف تلقائيًا. فالتوجيه يضرب لهذا الاستثناء أمثلة مثل الإعلانات وتقييمات التسوق، ونرى أن مسار الشراء لا ينطبق عليه هذا الوصف. لذا عزّز الجزء الخاضع لسيطرتك:
- امنح عنصر iframe الذي يحتوي على حقول الدفع أو شاشة 3DS قيمة
titleذات معنى. وانقل التركيز إليه عند فتحه، وإلى رسالة النتيجة عند إغلاقه. - اختبر صفحتي النجاح والخطأ بعد العودة من 3DS باستخدام قارئ الشاشة. وفي حال حدوث خطأ، احتفظ بالمعلومات التي أدخلها المستخدم.
- اطلب من مزوّد خدمة الدفع معلومات مكتوبة عن إمكانية الوصول في شاشة 3DS ونموذج الدفع، واجعلها معيارًا عند تجديد العقد.
لمعرفة تفاصيل التكامل، راجع دليلنا إلى تكامل 3DS ونقاط البيع الافتراضية (الدفع الإلكتروني بالبطاقة).
إمكانية الوصول في تطبيقات الجوال: المكافئات في iOS وAndroid وReact Native
تذكر قائمة التحقق واجهات API الخاصة بالمنصات في أمثلتها، ويُقيَّم تطبيقاك على iOS وAndroid بالأسئلة نفسها، شاشةً بشاشة. وفيما يلي المكافئات الأكثر شيوعًا:
| الحاجة (السؤال) | Android | iOS | React Native |
|---|---|---|---|
| الاسم القابل للوصول (س3، س16) | contentDescription | accessibilityLabel | accessibilityLabel |
| إخفاء عنصر زخرفي (س5) | importantForAccessibility="no" | isAccessibilityElement = false | aria-hidden={true} |
| العنوان (س28) | accessibilityHeading="true" | accessibilityTraits = .header | accessibilityRole="header" |
| معلومات القائمة (س30) | CollectionInfo | accessibilityContainerType | role="list" |
| النافذة المشروطة والتركيز (س62، س70) | accessibilityPaneTitle | accessibilityViewIsModal | accessibilityViewIsModal (iOS فقط) |
| إجراء بديل عن التمرير السريع أو السحب (س68، س96) | AccessibilityAction | accessibilityCustomActions | accessibilityActions |
| الملء التلقائي (س122) | autofillHints | textContentType | autoComplete |
خالفنا في موضعين من عمود React Native أمثلة قائمة التحقق. فالقيمة «list» لا تدخل ضمن قيم accessibilityRole ولذا يُستخدم role="list" لضبط دور القائمة. ولا يفعل accessible={false} على Android سوى إيقاف إمكانية التركيز؛ ولإخفاء عنصر زخرفي عن قارئات الشاشة، استخدم aria-hidden على المنصتين. أما Flutter فلا تتطرق إليه قائمة التحقق، ويوفّر فيه عنصر الواجهة Semantics المعلومات نفسها عبر الخصائص label وheader وexcludeSemantics وcustomSemanticsActions التابعة له. وأضف كذلك زرًا بديلًا للإجراءات التي لا تعمل إلا بالتمرير السريع، مثل إزالة منتج من سلة المشتريات (س95-96)، وبديلًا ومفتاح إيقاف للميزات المعتمدة على الحركة، مثل «الهز للتراجع» (س101-103). واربط رسائل الخطأ بالحقل المعني (setError على Android). ولأن حق استخدام الشعار يُمنح لكل نظام تشغيل للجوال على حدة، خطّط لتطبيقي iOS وAndroid بوصفهما منتجين منفصلين. ولا تصف تطبيقًا بأنه «يحقق إمكانية الوصول» قبل إخضاعه لاختبارات VoiceOver وTalkBack الفعلية. ونوضح نهجنا في الجانب الأصلي (Native) في صفحة تطوير تطبيقات الجوال.
خارطة طريق من 7 أشهر حتى يونيو 2027، خطوة بخطوة
تسلسل واقعي لفريق يبدأ في نوفمبر 2026:
- نوفمبر 2026، التنظيم والجرد: شكّل لجنة المراجعة (3 أشخاص على الأقل، أحدهم من وحدة الويب/الجوال). وضع قائمة بقوالب الويب وشاشات التطبيقات، وميّز على حدة المكوّنات التابعة لجهات خارجية، مثل أدوات الدفع وملفات تعريف الارتباط والدعم المباشر.
- ديسمبر 2026، القياس الأولي: أجرِ فحصًا آليًا بأدوات من قائمة W3C ثم راجع قائمة التحقق قالبًا تلو الآخر. وحوّل النتائج إلى قائمة عمل، تبدأ ببنود ★★ ومسار الدفع.
- من يناير إلى مارس 2027، إصلاح المكوّنات: أصلح الأزرار وحقول النماذج والنوافذ المشروطة والقوائم وأشرطة العرض المتحركة وعوامل التصفية في نظام التصميم، واربط الاختبارات الآلية بخط CI لديك.
- من مارس إلى أبريل 2027، الدفع والتطبيقات: الدفع ومسار العودة من 3DS إلى المتجر، وإشعار ملفات تعريف الارتباط، والأدوات المصغرة التابعة لجهات خارجية؛ وإدخال إصلاحات iOS وAndroid على التطبيقات.
- من أبريل إلى مايو 2027، الاختبارات اليدوية والاختبار مع مستخدمين من ذوي الإعاقة: اختبارات VoiceOver وTalkBack ولوحة المفاتيح؛ وجلسات مع مستخدمين من فئات الإعاقة المذكورة في التوجيه التنفيذي؛ ومسودة تقرير المراجعة.
- يونيو 2027 وما بعده: عند نشر خطة الرصد الخاصة بالويب/الجوال، كيّف التقرير مع صيغتها، وادرس التقدم بطلب الشعار، وأجرِ اختبارات الانحدار مع كل إصدار.
نقطة القرار: إذا كنت تستخدم قالبًا جاهزًا (Theme)، فإن بعض الإصلاحات يعتمد على مورّدي القالب والإضافات. احصل من المورّد على جدول زمني مكتوب لإمكانية الوصول. وإن تعذّر ذلك، فادرس تغيير القالب أو الانتقال إلى موقع إلكتروني بتصميم مخصص قبل مارس 2027. فمع التصميم المخصص، تُنفَّذ الإصلاحات في مكوّنات مشتركة وتنتقل إلى كل صفحة تستخدمها.
كيف تساعدك Partnerfy
نعالج إمكانية الوصول من مصدرها، لا عبر إضافة. نبدأ بجرد قوالبك وشاشات تطبيقاتك وفحصها بأدوات من قائمة W3C ثم نختبرها يدويًا عبر VoiceOver وTalkBack ولوحة المفاتيح. ونصلح النتائج في مكوّنات نظام التصميم لديك وفي كود React Native أو كود iOS أو Android الأصلي، ونربط الفحوص الآلية بخط CI لديك. وللاختبار مع مستخدمين من ذوي الإعاقة، نُعدّ السيناريوهات، ونساعدك على التخطيط لهذه الاختبارات مع الجمعيات والمنظمات العاملة في هذا المجال، ونُعدّ الوثائق التقنية لتقرير لجنة المراجعة لديك. أما عضوية اللجنة والتقييم القانوني فيبقيان من مسؤوليتك. وإذا كنت ترغب في تقييم أولي لمنصة التجارة الإلكترونية لديك، تواصل معنا.
المصادر
- الجريدة الرسمية التركية (Resmî Gazete): التعميم رقم 2025/10 (21 يونيو 2025، العدد 32933)، باللغة التركية
- وزارة الأسرة والخدمات الاجتماعية: قائمة التحقق – المستوى A (V2.2.30.01)، باللغة التركية
- EYHGM: صفحة التوجيهات والتوجيه الخاص بإجراءات التنفيذ ومبادئه (PDF)، باللغة التركية
- EYHGM: دليل استخدام الشعار، والتعميم رقم 2026/1، وصفحة إمكانية الوصول، باللغة التركية
- التشريعات: القوانين رقم 5378 و6701 و6563، باللغة التركية
- TİHEK: الغرامات الإدارية لعام 2026 والبيان الصحفي بشأن التعميم رقم 2025/10، باللغة التركية
- W3C: WCAG 2.2 وترجمات WCAG
- W3C: قائمة أدوات تقييم إمكانية الوصول إلى الويب
- WebAIM: The WebAIM Million (2026)
- BFSG: § 1، و§ 2، و§ 3، و§ 37، باللغة الألمانية
- React Native: Accessibility وFlutter: Semantics class