أدوات تسهيل الاستخدام لمطوّري البرامج على الويب

يؤدي تحسين إمكانية الوصول إلى جعل موقعك الإلكتروني أكثر فائدة للجميع.

Addy Osmani
Addy Osmani

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

يعيش أكثر من مليار شخص لديهم أحد أشكال الإعاقة.

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

فيما يلي بعض الإعاقات التي قد يواجهها المستخدمون لديك:

الرؤية أدوات سمعية التنقّل
  • ضعف في النظر
  • فقدان البصر
  • عمى الألوان
  • شلالات
  • لمعان الشمس
  • ضعيف السمع
  • الصَمَم
  • الضوضاء
  • التهاب الأذن
  • إصابة في الحبل الشوكي
  • المهارات اليدوية المحدودة
  • يدان ممتلئة
الإدراك الكلام عصبي
  • تطبيقات صعوبة التعلّم
  • النوم أو الإلهاء
  • صداع نصفي
  • مرض التوحّد
  • نوبة مرضية
  • الضوضاء المحيطة
  • احتقان الحلق
  • إعاقة الكلام
  • عدم القدرة على التحدّث
  • اكتئاب
  • اضطراب الكرب التالي للصدمة (PTSD)
  • اضطراب ثنائي القطب
  • القلق

تتراوح المشاكل المرئية بين عدم القدرة على تمييز الألوان أو انعدام الرؤية على الإطلاق.

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

لقطة شاشة لتلميح بشأن عنصر فحص "أدوات مطوري البرامج في Chrome"

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

تعني مشاكل السمع أنّ المستخدم قد يواجه مشاكل في سماع الصوت المنبعث من صفحة معيّنة.

  • قدِّم بدائل نصية لكل المحتوى الذي لا يكون نصًا حصرًا.
  • تحقق من أن مكونات واجهة المستخدم لا تزال تعمل بدون صوت.

لقطة شاشة لقارئ الشاشة ChromeVox وهو يقرأ صفحة ويب

قد تشمل مشاكل الحركة عدم القدرة على تشغيل الماوس أو لوحة المفاتيح أو الشاشة التي تعمل باللمس.

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

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

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

    prefers-reduced-motion يتيح لك الاستعلام عن وسائط CSS الحدّ من الصور المتحركة والفيديوهات التي يتم تشغيلها تلقائيًا للمستخدمين الذين يفضّلون الحركة المنخفضة:

    /*
    If the user expresses a preference for reduced motion, don't use animations on buttons.
    */
    @media (prefers-reduced-motion: reduce) {
      button {
        animation: none;
      }
    }
    
  • تجنَّب التفاعلات التي تستند إلى التوقيت.

قد يبدو هذا مثل الكثير من القواعد التي يجب تناولها، لكننا سنستعرض عملية تقييم ثم تحسين إمكانية الوصول إلى مكونات واجهة المستخدم الخاصة بك.

للحصول على مزيد من الدعم المرئي، أنشأ فريق تسهيل الاستخدام GOV.UK سلسلة من الملصقات الرقمية المسموح بها وغير المسموح بها بشأن تسهيل الاستخدام، التي يمكنك استخدامها لمشاركة أفضل الممارسات مع فريقك.

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

قياس إمكانية الوصول إلى مكوّنات واجهة المستخدم

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

  • هل يمكنك استخدام مكوّن واجهة المستخدم مع لوحة المفاتيح فقط؟

    هل يدير المكون التركيز ويتجنب فخ التركيز؟ هل يمكنها الاستجابة لأحداث لوحة المفاتيح المناسبة؟

  • هل يمكنك استخدام مكوِّن واجهة المستخدم مع قارئ شاشة؟

    هل قدمت بدائل نصية لأي معلومات مقدمة بشكل مرئي؟ هل أضفت معلومات دلالية باستخدام ARIA؟

  • هل يمكن أن يعمل مكوّن واجهة المستخدم بدون صوت؟

    أوقِف تشغيل مكبّرات الصوت واطّلِع على حالات الاستخدام

  • هل يمكن أن يعمل مكوّن واجهة المستخدم بدون لون؟

    تأكد من إمكانية استخدام مكون واجهة المستخدم من قبل شخص لا يمكنه رؤية الألوان. إحدى الأدوات المفيدة لمحاكاة عمى الألوان هي إحدى إضافات Chrome التي تسمى عمى الألوان. (جرب جميع الأشكال الأربعة لمحاكاة عمى الألوان المتاحة). قد تكون مهتمًا أيضًا بالإضافة Daltonize والتي لها فائدة أيضًا.

  • هل يمكن لمكوِّن واجهة المستخدم العمل مع تفعيل وضع التباين العالي؟

    تدعم جميع أنظمة التشغيل الحديثة وضع التباين العالي. التباين العالي هو إحدى إضافات Chrome التي يمكن أن تساعدك في ذلك.

تحتوي عناصر التحكّم الموحّدة (مثل <button> و<select>) على إمكانية الوصول مضمّنة في المتصفّح. ويمكن التركيز عليها باستخدام مفتاح Tab، وتستجيب لأحداث لوحة المفاتيح (مثل Enter وSpace ومفاتيح الأسهم)، ولديها أدوار وحالات وخصائص دلالية تستخدمها أدوات تسهيل الاستخدام. ويجب أن يستوفي التصميم التلقائي أيضًا متطلبات تسهيل الاستخدام المذكورة.

لا تحتوي مكونات واجهة المستخدم المخصّصة (باستثناء المكوّنات التي تضيف العناصر العادية مثل <button>) على أي إمكانات مدمجة، بما في ذلك إمكانية الوصول، لذا عليك توفيرها. أفضل مكان للبدء عند تنفيذ إمكانية الوصول هو مقارنة المكوِّن بعنصر قياسي مماثل (أو مزيج من عدة عناصر قياسية، اعتمادًا على مدى تعقيد مكونك).

توفِّر معظم أدوات المطوّرين في المتصفّح إمكانية فحص شجرة تسهيل الاستخدام لإحدى الصفحات. في "أدوات مطوري البرامج في Chrome"، يتوفّر هذا في علامة تبويب تسهيل الاستخدام في لوحة العناصر.

لقطة شاشة لعرض شجرة تسهيل الاستخدام في &quot;أدوات مطوري البرامج في Chrome&quot;.

يتضمّن Firefox أيضًا لوحة تسهيل الاستخدام.

لقطة شاشة لطريقة عرض شجرة تسهيل الاستخدام في FireFox DevTools

يعرض Safari معلومات تسهيل الاستخدام في علامة التبويب Node في لوحة Elements.

فيما يلي قائمة بالأسئلة التي يمكنك طرحها على نفسك عند محاولة تسهيل الوصول إلى مكونات واجهة المستخدم.

تحسين تركيز لوحة المفاتيح

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

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

لقطة شاشة لقائمة وقائمة فرعية تتطلّب إدارة التركيز
إدارة التركيز داخل العنصر المعقد.

استخدام فهرس Tab

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

العناصر التفاعلية المضمّنة (مثل <button>) يمكن التركيز عليها بشكل ضمني، لذلك لا تحتاج إلى السمة tabindex، ما لم تحتاج إلى تغيير موضعها بترتيب التنقل بـ Tab.

هناك ثلاثة أنواع من قيم tabindex:

  • tabindex="0" هو الأكثر شيوعًا ويضع العنصر في ترتيب علامة التبويب الطبيعي (الذي يحدده ترتيب DOM).
  • تؤدي القيمة tabindex الأكبر من 0 إلى وضع العنصر بترتيب يدوي في علامة التبويب. تتم زيارة جميع العناصر في الصفحة ذات القيمة tabindex الموجبة بترتيب رقمي، قبل العناصر بترتيب التنقل الطبيعي.
  • إذا كانت قيمة tabindex تساوي -1، يصبح العنصر قابلاً للتركيز آليًا، ولكن ليس حسب ترتيب التنقّل باستخدام مفتاح التبويب (Tab).

في ما يتعلّق بمكوّنات واجهة المستخدم المخصّصة، يجب دائمًا استخدام قيم tabindex المسماة 0 أو -1 لأنّك لن تتمكّن مسبقًا من تحديد ترتيب العناصر في صفحة معيّنة. وتكون قيمة tabindex التي تبلغ -1 مفيدة بشكلٍ خاص لإدارة التركيز داخل المكوّنات المعقّدة.

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

استخدام ميزة "التركيز التلقائي"

تتيح سمة التركيز التلقائي في HTML للمؤلف تحديد التركيز التلقائي لعنصر معين عند تحميل الصفحة. تتوفّر ميزة "autofocus" حاليًا في جميع عناصر التحكّم في نماذج الويب، بما في ذلك الأزرار. لضبط التركيز التلقائي على العناصر في مكونات واجهة المستخدم المخصصة، استدع طريقة focus()، المتوافقة مع جميع عناصر HTML التي يمكن التركيز عليها (على سبيل المثال، document.querySelector('myButton').focus()).

إضافة تفاعل باستخدام لوحة المفاتيح

بمجرد أن يكون التركيز على مكون واجهة المستخدم، قدم قصة تفاعل جيدة باستخدام لوحة المفاتيح عندما يتم تركيز أحد المكونات من خلال التعامل مع أحداث لوحة المفاتيح المناسبة. على سبيل المثال، اسمح للمستخدم باستخدام مفاتيح الأسهم لتحديد خيارات القائمة، وSpace أو Enter لتفعيل الأزرار. يقدّم دليل أنماط التصميم ARIA بعض الإرشادات هنا.

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

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

اختبار زر إيقاف/تفعيل حالة WalkMe.
// Example for expanding and collapsing a category with the Space key
const category = await page.$(`.category`);

// verify tabIndex, role and focus
expect(await page.evaluate(elem => elem.getAttribute(`role`), category)).toEqual(`button`);
expect(await page.evaluate(elem => elem.getAttribute(`tabindex`), category)).toEqual(`0`);
expect(await page.evaluate(elem => window.document.activeElement === elem, category)).toEqual(true);

// verify aria-expanded = false
expect(await page.evaluate(elem => elem.getAttribute(`aria-expanded`), category)).toEqual(`false`);

// toggle category by pressing Space
await page.keyboard.press('Space');

// verify aria-expanded = true
expect(await page.evaluate(elem => elem.getAttribute(`aria-expanded`), category)).toEqual(`true`);

التأكّد من نجاح استخدام قارئ الشاشة

حوالي 1% إلى 2% من الأشخاص يستخدمون قارئ الشاشة. هل يمكنك فهم جميع المعلومات المهمة والتفاعل مع المكون باستخدام قارئ الشاشة ولوحة المفاتيح فقط؟

من المفترض أن تساعدك الأسئلة التالية في التعامل مع إمكانية الوصول إلى قارئ الشاشة.

هل تحتوي جميع المكونات والصور على بدائل نصية ذات مغزى؟

أينما يتم نقل المعلومات حول الاسم أو الغرض من المكوِّن التفاعلي بشكل مرئي، يمكنك توفير بديل نصي يمكن الوصول إليه.

على سبيل المثال، إذا كان مكوّن واجهة المستخدم في <fancy-menu> يعرض رمز ترس فقط للإشارة إلى أنّه قائمة إعدادات، سيحتاج إلى نص بديل يمكن الوصول إليه، مثل "الإعدادات"، الذي ينقل المعلومات نفسها. واستنادًا إلى السياق، يمكنك تقديم بديل للنص باستخدام سمة alt أو السمة aria-label أو السمة aria-labelledby أو نص عادي في Shadow DOM. يمكنك العثور على نصائح فنية عامة في مرجع WebAIM السريع.

يجب أن يوفّر أي مكوّن في واجهة المستخدم يعرض صورة ما آلية لتوفير نص بديل لتلك الصورة، على غرار السمة alt.

هل توفر مكوناتك معلومات دلالية؟

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

بشكل عام، يجب أن يتضمّن أي مكوّن يستمع إلى حدث النقر بالماوس أو التمرير نوعًا من أداة معالجة أحداث لوحة المفاتيح ودور ARIA، وربما حالات وسمات ARIA أيضًا.

على سبيل المثال، قد يؤدّي المكوِّن المخصّص لواجهة المستخدم في <fancy-slider> دور ARIA في شريط التمرير، ويشمل ذلك بعض سمات ARIA ذات الصلة، وهي aria-valuenow وaria-valuemin وaria-valuemax. من خلال ربط هذه السمات بالخصائص ذات الصلة في المكون المخصص، يمكنك السماح لمستخدمي التكنولوجيا المساعدة بالتفاعل مع العنصر وتغيير قيمته وحتى تغيير العرض التقديمي المرئي للعنصر وفقًا لذلك.

لقطة شاشة لشريط التمرير.
مكوِّن شريط تمرير النطاق:
<fancy-slider role="slider" aria-valuemin="1" aria-valuemax="5" aria-valuenow="2.5">
</fancy-slider>

هل يمكن للمستخدمين فهم كل شيء دون الاعتماد على الألوان؟

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

مخطط دائري يحتوي على تسميات وقيم لضمان إمكانية الوصول.
رسم بياني دائري يمكن الوصول إليه. (من مبادرة W3C Web Accessibility Initiative)

هل هناك تباين كافٍ؟

يجب أن يستوفي أي محتوى نصي معروض في المكوِّن الحد الأدنى للتباين على مستوى WCAG AA. ننصحك بتوفير مظهر عالي التباين يفي بحد أدنى أعلى AAA، والتأكّد من إمكانية تطبيق أوراق أنماط وكيل المستخدم إذا كان المستخدمون بحاجة إلى تباين مخصّص أو ألوان مختلفة. يمكنك استخدام أداة التحقق من تباين الألوان كأداة مساعدة عند تصميم المكون.

هل يمكن إيقاف المحتوى المتحرّك أو الوامض بأمان؟

يجب أن يتمكن المستخدمون من إيقاف المحتوى الذي يتحرك أو ينتقل أو وامض لمدة تزيد عن خمس ثوانٍ أو إيقافه مؤقتًا أو إخفاؤه. بوجه عام، تجنَّب عرض محتوى وامض.

وعند ضرورة وميض فلاش ما، احرِص على عدم وميضه أكثر من ثلاث مرات في الثانية.

أدوات واختبارات لتسهيل الاستخدام

تتوفّر أكثر من 100 أداة لتقييم مدى سهولة استخدام موقعك الإلكتروني ومكوّناته. يتم تنفيذ بعض الأدوات آليًا بينما يتطلب البعض الآخر اختبارًا يدويًا.

فيما يلي بعض الأشياء التي يجب مراعاتها:

  • يوفر Axe اختبار إمكانية الوصول التلقائي لإطار العمل أو المتصفح الذي تختاره. ويمكن استخدام Axe Puppeteer لكتابة اختبارات إمكانية الوصول الآلية.
  • يوفّر تدقيق تسهيل الاستخدام في Lighthouse إحصاءات مفيدة لاكتشاف المشاكل الشائعة المتعلّقة بتسهيل الاستخدام. درجة تسهيل الاستخدام هي المتوسّط المرجّح لجميع عمليات تدقيق تسهيل الاستخدام استنادًا إلى تقييمات تأثير مستخدم Axe. ولمراقبة تسهيل الاستخدام من خلال الدمج المستمر، يُرجى الاطّلاع على Lighthouse CI.

    لقطة شاشة لتدقيق إعدادات تسهيل الاستخدام في Lighthouse

  • يُعد Tenon.io مفيدًا لاختبار مشاكل تسهيل الاستخدام الشائعة. توفّر منصة Tenon إمكانية دمج قوي على أدوات الإنشاء والمتصفحات (من خلال الإضافات) وحتى أدوات تحرير النصوص.

  • هناك العديد من الأدوات الخاصة بالمكتبة وإطار العمل لإبراز مشكلات إمكانية الوصول بشأن المكونات. على سبيل المثال، يمكنك استخدام eslint-plugin-jsx-a11y لتسليط الضوء على مشاكل إمكانية الوصول لمكوّنات React في المحرر.

    لقطة شاشة لمحرِّر رموز يواجه مشكلة في تسهيل الاستخدام تم الإبلاغ عنها من خلال eslint-extension-jsx-a11y.

    إذا كنت تستخدم Angular، يوفّر codelyzer أداة تدقيق إمكانية الوصول داخل المحرر أيضًا:

    لقطة شاشة لمحرِّر رموز يواجه مشكلة في تسهيل الاستخدام تم الإبلاغ عنها من خلال أداة تعديل الرموز

العمل باستخدام التكنولوجيات المساعدة

  • يمكنك فحص الطريقة التي ترى بها التقنيات المساعدة محتوى الويب باستخدام Accessibility Inspector (أداة فحص إمكانية الوصول) (Mac) أو Windows Automation API Testing Tools وAccProbe (نظام التشغيل Windows). يمكنك أيضًا الاطّلاع على شجرة تسهيل الاستخدام الكاملة التي ينشئها Chrome من خلال الانتقال إلى about://accessibility.
  • تتمثل أفضل طريقة لاختبار دعم قارئ الشاشة على نظام التشغيل Mac في استخدام الأداة VoiceOver. استخدِم ⌘F5 لتفعيلها أو إيقافها، وCtrl+Option ←→ للتنقُّل في الصفحة، وCtrl+Shift+Option + ↑↓ للانتقال للأعلى أو للأسفل في شجرة تسهيل الاستخدام. للحصول على تعليمات أكثر تفصيلاً، راجِع القائمة الكاملة لأوامر VoiceOver وقائمة أوامر VoiceOver على الويب.
  • على نظام التشغيل Windows، يُعد NVDA قارئ شاشة مجانيًا ومفتوح المصدر. ومع ذلك، فهي تحتوي على منحنى تعليمي كبير للمستخدمين المبصرين.

    لقطة شاشة لـ ChromeLens

  • يتضمّن نظام التشغيل ChromeOS قارئ شاشة مدمَجًا.

لا يزال أمامنا طريق طويل نقطعه لتحسين إمكانية الوصول على الويب. وفقًا لتقويم الويب:

  • 4 من كل 5 مواقع إلكترونية تحتوي على نص ممزوج بالخلفية، ما يجعلها غير مقروءة.
  • لا تزال% 49.91 من الصفحات لا توفّر سمات alt لبعض الصور.
  • تتضمن نسبة 24% فقط من الصفحات التي تستخدم أزرارًا أو روابط تصنيفات.
  • توفر 22.33% فقط من الصفحات تصنيفات لجميع إدخالات النماذج.

هناك الكثير الذي يمكننا القيام به لبناء تجارب يسهل الوصول إليها للجميع.