قائمة إمكانية الوصول لنماذج الاتصال

تأكد من أن نماذج الاتصال قابلة للاستخدام من الجميع، بما في ذلك من يستخدمون التقنيات المساعدة.

لماذا إمكانية الوصول مهمة

المتطلبات القانونية

كثير من الجهات القضائية تفرض أن تكون المواقع متاحة:

• ADA (قانون الأمريكيين ذوي الإعاقة)
• الامتثال لمستوى AA من WCAG 2.1
• القسم 508 (الوكالات الفيدرالية الأمريكية)
• القانون الأوروبي لإمكانية الوصول

الالتزام الأخلاقي

15% من سكان العالم لديهم شكل من أشكال الإعاقة. جعل نموذج الاتصال غير متاح يعني:

• فقدان فرص عمل
• استبعاد عملاء محتملين
• تقليل الوصول
• تجربة مستخدم سيئة لكثيرين

فوائد الأعمال

النماذج المتاحة توفر تجربة مستخدم أفضل للجميع:

• تسميات أوضح تساعد كل المستخدمين
• رسائل خطأ أفضل تقلل الإحباط
• التنقل بلوحة المفاتيح يساعد المستخدمين المتقدمين
• ملاءمة الجوال تفيد كل الأجهزة

متطلبات إمكانية الوصول الأساسية

1. التسميات وحقول النموذج

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

جيد:

<label for="name">أنتr الاسم:</label>
<input type="text" id="name" name="name" required>

سيء:

<!-- No label -->
<input type="text" name="name" placeholder="أنتr الاسم">

<!-- التسمية not associated -->
<label>أنتr الاسم:</label>
<input type="text" name="name">

لماذا يهم:

• قارئات الشاشة تعلن التسمية
• المستخدمون يعرفون ماذا يدخلون
• النقر على التسمية يركز الحقل
• غرض واضح لكل حقل

كيف يتعامل SupportRetriever مع هذا:

• كل الحقول لها تسميات مناسبة
• التسميات مرئية (غير مخفية)
• سمات ID/for مرتبطة بشكل صحيح
• لا حقول تعتمد على placeholder فقط

2. مؤشرات الحقول الإلزامية

المتطلب: وسم الحقول الإلزامية مقابل الاختيارية بوضوح.

جيد:

<label for="email">
  عنوان البريد الإلكتروني <span aria-label="required">*</span>
</label>
<input type="email" id="email" name="email" required aria-required="true">

<label for="phone">
  Phone Number <span>(optional)</span>
</label>
<input type="tel" id="phone" name="phone">

سيء:

<!-- No indication if required -->
<label for="email">البريد الإلكتروني</label>
<input type="email" id="email" name="email" required>

لماذا يهم:

• المستخدمون يعرفون ما الإلزامي
• يقلل التخلي عن النموذج
• قارئات الشاشة تعلن المتطلبات
• يمنع أخطاء الإرسال

كيف يتعامل SupportRetriever مع هذا:

• الحقول الإلزامية موسومة بنجمة
• السمة aria-required="true"
• الحقول الاختيارية موسومة صراحة
• تنسيق متسق للحقول الإلزامية

3. رسائل الخطأ

المتطلب: أن تكون الأخطاء واضحة ومحددة ومرتبطة برمجياً بالحقول.

جيد:

<label for="email">عنوان البريد الإلكتروني</label>
<input 
  type="email" 
  id="email" 
  name="email" 
  aria-invalid="true"
  aria-describedby="email-error"
>
<span id="email-error" role="alert">
  Please enter a valid email address (e.g., name@example.com)
</span>

سيء:

<!-- Generic error at top of form -->
<div>يرجى تصحيح الأخطاء</div>

<!-- Field turns red but no explanation -->
<input type="email" style="border-color: red;">

لماذا يهم:

• المستخدمون يعرفون بالضبط ما الخطأ
• قارئات الشاشة تعلن أخطاء محددة
• يقلل الإحباط
• استعادة أسرع من الخطأ

كيف يتعامل SupportRetriever مع هذا:

• الأخطاء تظهر بجانب الحقول
• رسائل خطأ محددة
• aria-invalid و aria-describedby
• إشارة بصرية وبرمجية للخطأ

4. ملخص الأخطاء

المتطلب: تقديم ملخص لجميع الأخطاء عند إرسال النموذج.

جيد:

<div role="alert" class="error-summary" tabindex="-1">
  <h2>Please fix the following errors:</h2>
  <ul>
    <li><a href="#name">الاسم is required</a></li>
    <li><a href="#email">البريد الإلكتروني address is invalid</a></li>
  </ul>
</div>

لماذا يهم:

• نظرة عامة على كل المشكلات
• قارئات الشاشة تعلن الملخص
• الروابط تقفز للحقول المشكلة
• يقلل الحمل المعرفي

5. إدارة التركيز

المتطلب: ترتيب تركيز منطقي ومؤشرات تركيز مرئية.

جيد:

/* Visible focus indicator */
input:focus,
textarea:focus,
button:focus {
  outline: 2px solid #0066cc;
  outline-offset: 2px;
}

سيء:

/* Removing focus indicators */
*:focus {
  outline: none; /* Never do this */
}

لماذا يهم:

• مستخدمو لوحة المفاتيح يرون أين هم
• ترتيب Tab منطقي
• لا مصائد تركيز
• ردود فعل بصرية واضحة

كيف يتعامل SupportRetriever مع هذا:

• مؤشرات تركيز واضحة على كل العناصر التفاعلية
• ترتيب Tab منطقي
• التركيز ينتقل لملخص الأخطاء عند فشل الإرسال
• لا عناصر تركيز غير مرئية

6. التنقل بلوحة المفاتيح

المتطلب: كل وظائف النموذج قابلة للوصول بلوحة المفاتيح فقط.

قائمة اختبار:

• الوصول لكل الحقول بمفتاح Tab
• الإرسال بمفتاح Enter
• تفعيل الأزرار بـ Space/Enter
• الخروج من كل الحقول بـ Tab/Shift+Tab
• ترتيب Tab يطابق الترتيب البصري
• لا مصائد لوحة مفاتيح

كيف يتعامل SupportRetriever مع هذا:

• كل العناصر التفاعلية قابلة للوصول بلوحة المفاتيح
• سلوك لوحة مفاتيح قياسي
• لا تحكم مخصص يكسر التوقعات
• ترتيب Tab يتبع التخطيط البصري

7. تباين الألوان

المتطلب: تباين كافٍ بين النص والخلفية.

متطلبات WCAG 2.1 مستوى AA:

• النص العادي: نسبة تباين 4.5:1
• النص الكبير (18pt+): نسبة تباين 3:1
• عناصر الواجهة: نسبة تباين 3:1

جيد:

/* Sufficient contrast */
label { color: #333333; background: #ffffff; } /* 12.6:1 */
button { color: #ffffff; background: #0066cc; } /* 7.5:1 */

سيء:

/* Insufficient contrast */
label { color: #cccccc; background: #ffffff; } /* 1.6:1 - fails */
button { color: var(--color-border-secondary)ddd; background: #ffffff; } /* 1.2:1 - fails */

كيف يتعامل SupportRetriever مع هذا:

• كل النص يلبي متطلبات تباين AA
• حقول النموذج لها حدود واضحة
• رسائل الخطأ تستخدم تبايناً كافياً
• مؤشرات التركيز واضحة

8. أنواع الإدخال

المتطلب: استخدام أنواع إدخال مناسبة لإمكانية وصول أفضل.

جيد:

<input type="email" autocomplete="email">
<input type="tel" autocomplete="tel">
<input type="url">
<input type="number">

لماذا يهم:

• لوحات المفاتيح الجوالية تتكيف مع نوع الإدخال
• التحقق من المتصفح
• الإكمال التلقائي يعمل أفضل
• قارئات الشاشة توفر سياقاً

كيف يتعامل SupportRetriever مع هذا:

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

مكافحة البريد العشوائي التي لا تحجب البشر

ما لا يجب فعله

أساليب سيئة:

• ✗ CAPTCHA صعبة (اختيار صور، مسائل رياضية)
• ✗ CAPTCHA صوتية (غالباً غير مفهومة)
• ✗ حدود زمنية (تعاقب المستخدمين البطيئين)
• ✗ تتبع حركة الفأرة (يستبعد مستخدمي لوحة المفاتيح)
• ✗ حقول إلزامية غير ضرورية

تقنيات مكافحة البريد العشوائي المتاحة

أساليب جيدة:

1. Cloudflare Turnstile

• عادة غير مرئي
• لا حاجة لتفاعل المستخدم
• يحترم إمكانية الوصول
• متوافق مع WCAG

2. حقول Honeypot

<!-- Hidden field bots fill but humans don't see -->
<input 
  type="text" 
  name="الموقع" 
  tabindex="-1" 
  autocomplete="off"
  aria-hidden="true"
  style="position: absolute; left: -9999px;"
>

• غير مرئي للبشر
• مُزال من ترتيب Tab
• لا تأثير على المستخدمين الشرعيين

3. تحديد المعدل

• تخفيف من جانب الخادم
• لا تأثير واجهة للمستخدم
• يمنع الفيضانات الآلية

4. التحقق من البريد

• فحص التنسيق
• التحقق من النطاق
• رسائل خطأ مفيدة

كيف يتعامل SupportRetriever مع هذا:

• Cloudflare Turnstile (متاح)
• تحديد معدل من جانب الخادم
• التحقق من البريد مع أخطاء واضحة
• لا CAPTCHA معادية للمستخدم

الاختبار السريع

اختبار لوحة المفاتيح فقط (5 دقائق)

افصل الفأرة و:

1. انتقل بالنموذج كاملاً بـ Tab
2. املأ كل الحقول بلوحة المفاتيح فقط
3. أرسل النموذج بمفتاح Enter
4. انتقل لرسائل الخطأ إن وُجدت
5. أكمل إرسالاً ناجحاً

إن استطعت كل هذا، إمكانية الوصول بلوحة المفاتيح جيدة.

أساسيات قارئ الشاشة (10 دقائق)

macOS (VoiceOver):

1. اضغط Cmd+F5 لتفعيل VoiceOver
2. انتقل بالنموذج بمفتاح Tab
3. استمع لما يُعلن
4. جرّب الإرسال مع أخطاء
5. استمع لرسائل الخطأ

Windows (NVDA - مجاني):

1. حمّل NVDA من nvaccess.org
2. شغّل NVDA
3. انتقل بالنموذج بمفتاح Tab
4. استمع للإعلانات
5. اختبر معالجة الأخطاء

ما يجب أن تسمعه:

• تسميات الحقول
• أنواع الحقول ("edit text", "button")
• حالة الإلزام
• رسائل الخطأ
• تأكيدات النجاح

اختبار تباين الألوان (دقيقتان)

أدوات:

• WebAIM Contrast Checker
• Chrome DevTools (Lighthouse)
• إضافات المتصفح (WCAG Color Contrast Checker)

فحص سريع:

• افحص عناصر النص
• تحقق من نسب التباين
• تأكد من 4.5:1 كحد أدنى للنص
• تأكد من 3:1 كحد أدنى لعناصر الواجهة

الاختبار الآلي (5 دقائق)

أدوات تطوير المتصفح:

1. افتح Chrome DevTools
2. اذهب لتبويب Lighthouse
3. حدد "Accessibility"
4. شغّل التدقيق
5. راجع المشكلات

أدوات:

• WAVE Browser Extension
• axe DevTools
• Lighthouse (مدمج في Chrome)

ملاحظة: الأدوات الآلية تكتشف نحو 30–40% من المشكلات. الاختبار اليدوي ضروري.

كيف يساعد SupportRetriever

إمكانية الوصول المدمجة

نماذج SupportRetriever تتضمن:

✓ HTML دلالي صحيح

• تسلسل عناوين صحيح
• معالم النموذج
• عناصر نموذج دلالية

✓ تسميات ARIA

• كل الحقول موسومة بشكل صحيح
• الحقول الإلزامية مُعلنة
• حالات الخطأ مُبلّغ عنها

✓ متاح بلوحة المفاتيح

• ترتيب Tab منطقي
• مؤشرات تركيز مرئية
• لا مصائد لوحة مفاتيح

✓ متوافق مع قارئات الشاشة

• تسميات ذات معنى
• إعلانات الأخطاء
• تحديثات الحالة

✓ تباين الألوان

• متوافق مع WCAG AA
• حدود بصرية واضحة
• حالات الخطأ واضحة

✓ متجاوب وجوال

• أهداف لمس مناسبة
• دعم تكبير صحيح
• أنواع لوحة مفاتيح جوالية

✓ مكافحة البريد العشوائي المتاحة

• Cloudflare Turnstile (متوافق مع WCAG)
• لا CAPTCHA معادية
• لا حدود زمنية
• لا أنماط معادية للمستخدم

ما لا تحتاج القلق عنه

عند استخدام SupportRetriever:

• ✓ ترميز النموذج صحيح
• ✓ سمات ARIA مناسبة
• ✓ إدارة التركيز تعمل
• ✓ معالجة الأخطاء متاحة
• ✓ التنقل بلوحة المفاتيح يعمل
• ✓ قارئات الشاشة تعمل بشكل صحيح

ما تحتاج فعله فقط:

• تضمين النموذج
• الاختبار في سياقك
• التأكد من أن المحتوى المحيط متاح

قائمة إمكانية الوصول السريعة

قبل الإطلاق

• كل حقول النموذج لها تسميات مرئية
• الحقول الإلزامية موسومة
• مؤشرات التركيز مرئية
• النموذج قابل للتنقل بلوحة المفاتيح
• تباين الألوان يلبي WCAG AA
• أنواع الإدخال مناسبة
• رسائل الخطأ محددة وواضحة
• ملخص الأخطاء يظهر عند فشل الإرسال
• رسالة النجاح مُعلنة لقارئات الشاشة
• اختُبر بلوحة المفاتيح فقط
• اختُبر بقارئ شاشة
• فحص إمكانية الوصول الآلي نجح

مستمر

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

أخطاء شائعة يجب تجنبها

تسميات placeholder فقط

سيء:

<input type="text" placeholder="Enter your name">

لماذا: الـ placeholder يختفي عند الكتابة، ولا يُقرأ بشكل متسق من قارئات الشاشة.

جيد:

<label for="name">الاسم:</label>
<input type="text" id="name" placeholder="e.g., John Smith">

تسميات مخفية

سيء:

<label style="display:none;">الاسم</label>
<input type="text">

لماذا: غير مرئية للمستخدمين المبصرين، تخلق التباساً.

رسائل خطأ عامة

سيء:

<div>النموذج يحتوي على أخطاء</div>

جيد:

<div role="alert">
  <h2>Please fix the following:</h2>
  <ul>
    <li><a href="#email">البريد الإلكتروني address is required</a></li>
  </ul>
</div>

إزالة مؤشرات التركيز

لا تفعل هذا أبداً:

*:focus { outline: none; }

بديل:

*:focus {
  outline: 2px solid #0066cc;
  outline-offset: 2px;
}

الموارد

أدوات الاختبار

• WAVE: أداة تقييم إمكانية الوصول على الويب
• axe DevTools: اختبار إمكانية الوصول الآلي
• Lighthouse: مدمج في Chrome
• NVDA: قارئ شاشة مجاني (Windows)
• VoiceOver: مدمج في macOS/iOS

المبادئ التوجيهية

• WCAG 2.1: مبادئ توجيهية لمحتوى الويب لإمكانية الوصول
• ARIA: تطبيقات الإنترنت الغنية المتاحة
• WebAIM: إمكانية الوصول على الويب في الذهن

التعلم

• WebAIM Articles
• A11y Project
• MDN Accessibility

مواضيع ذات صلة

• فهم حماية البوتات
• تقليل البريد العشوائي في نماذج الاتصال بدون CAPTCHA
• تجربة الجوال مقابل سطح المكتب
• أفضل الممارسات لدعم العملاء