اختبار قارئات الشاشة

كيف تستخدم قارئات الشاشة الدلالات

يحوّل المتصفح DOM إلى شجرة إمكانية الوصول (Accessibility tree): بنية موازية يكون فيها لكل عنصر ذي معنى دور (زر، رابط، عنوان، حقل نص)، واسم، وحالات وخصائص (موسَّع، محدَّد، إلزامي، غير صالح)، وعلاقات. وتمرر واجهة إمكانية الوصول في نظام التشغيل هذه الشجرة إلى قارئ الشاشة الذي ينطقها أو يرسلها إلى شاشة برايل. والتنسيق البصري لا يغيّر دور العنصر: فعنصر div منسّق ليبدو زراً يبقى عنصراً عاماً (generic) في الشجرة. لكن CSS ليست بلا أثر على الشجرة: فالقيمتان display: none وvisibility: hidden تُخرجان المحتوى منها، والنص الذي تولّده CSS (عبر ⁦::before⁩ و⁦::after⁩) قد يصبح جزءاً من الاسم القابل للوصول.

لهذا تأتي HTML الأصلية أولاً. فالعنصر button له دور الزر، ويتلقى التركيز، ويُفعَّل بـ Enter وSpace، ويأخذ اسمه من نصه — كل ذلك دون شيفرة إضافية. والعناوين (h1 إلى h6)، والقوائم، والجداول مع th، وعناصر label، وfieldset مع legend، والمعالم مثل nav وmain تمنح مستخدمي قارئات الشاشة البنية نفسها التي يراها المبصرون. ومعظم إخفاقات WCAG التي تتناولها هذه الصفحة تقع تحت 1.3.1 Info and Relationships (يجب أن تكون البنية قابلة للتحديد برمجياً) و4.1.2 Name, Role, Value (كل مكوّن واجهة يكشف اسمه ودوره وحالاته وقيمته).

لقارئات الشاشة المكتبية على Windows طريقتا عمل رئيسيتان. في وضع التصفح (Browse mode، ويسمى أيضاً المؤشر الافتراضي) يقرأ المستخدم الصفحة بمفاتيح الأسهم ويقفز حسب نوع العنصر بحروف مفردة؛ وفي وضع التركيز (Focus mode أو وضع النماذج) تذهب ضغطات المفاتيح إلى عنصر التحكم الذي عليه التركيز، فتعمل الكتابة في الحقول وتشغّل الأسهم العناصر. وتنتقل قارئات الشاشة بين الوضعين تلقائياً مع كثير من عناصر التحكم؛ والعناصر المخصصة التي تكسر هذا الانتقال مصدر شائع للعيوب.

الأسماء والأوصاف القابلة للوصول

الاسم القابل للوصول (Accessible name) هو ما يعلنه قارئ الشاشة للعنصر، وهو ما ينطقه مستخدمو التحكم الصوتي لتفعيله. وتحسبه المتصفحات وفق مواصفة W3C لحساب الاسم والوصف القابلين للوصول (accname 1.2، وهي حالياً مسودة عمل Working Draft). وباختصار، يؤخذ الاسم من أول مصدر ينطبق مما يلي:

• aria-labelledby — نص العنصر أو العناصر المشار إليها.
• aria-label — سلسلة نصية على العنصر نفسه.
• التسمية الأصلية — العنصر label لحقول النماذج، وalt للصور، وcaption للجداول، وlegend لمجموعات الحقول.
• المحتوى — للأدوار التي تسمح بذلك، كالأزرار والروابط والعناوين، نص العنصر نفسه.
• البدائل الاحتياطية — السمة title، ونص التلميح الظاهر داخل الحقل الفارغ؛ وهي غير موثوقة ولا ينبغي أن تكون الاسم الوحيد.

فحص الأسماء والتسميات والأوصاف عملياً

استخدم لوحة إمكانية الوصول في أدوات المطوّر بالمتصفح لرؤية الاسم والدور والحالات المحسوبة للعنصر قبل أن تستمع إليه: فهي تخبرك لماذا يُعلَن الشيء بالطريقة التي يُعلَن بها. ثم افحص ثلاثة أمور. أولاً، لكل عنصر تفاعلي اسم — وأزرار الأيقونات فقط (البحث، والإغلاق، والحذف، والقائمة) هي الإخفاق الكلاسيكي. ثانياً، يحتوي الاسم على التسمية المرئية: يشترط المعيار 2.5.3 Label in Name أن يتضمن الاسم القابل للوصول لعنصر التحكم النصَّ الظاهر في تسميته، فالزر الذي يعرض «إرسال» لا يجوز أن يكون اسمه «تقديم النموذج». ثالثاً، الاسم مفيد خارج سياقه: «حذف» في قائمة من عشرين عنواناً أفضل منه «حذف العنوان: 12 شارع العليا».

يضيف الوصف (Description) معلومات ثانوية، عادةً عبر aria-describedby: قاعدة كلمة المرور، أو صيغة التاريخ، أو رسالة خطأ مرتبطة بحقل. وتُعلَن الأوصاف بعد الاسم والدور، وأحياناً بعد توقف، ويستطيع المستخدمون إيقاف بعضها، لذا فالمعلومة الحرجة مكانها الاسم أو التسمية المرئية. ويغطي دليل النماذج القابلة للوصول تسميات النماذج وتعليماتها ورسائل أخطائها بالتفصيل.

العناوين والمعالم وعناوين الصفحات

نادراً ما يقرأ مستخدمو قارئات الشاشة الصفحة من أعلاها إلى أسفلها. فهم يفتحون قائمة بالعناوين أو المعالم، أو يقفزون من عنوان إلى عنوان، ليجدوا الجزء الذي يحتاجونه. وهذا يجعل البنية قابلة للاختبار: افتح قائمة العناوين وقارنها بما تراه. يجب أن يكون كل عنوان مرئي عنصر عنوان حقيقياً، وأن تعكس المستويات التسلسل الهرمي (عنوان h1 رئيسي واحد، وh2 للأقسام، وh3 داخلها)، وأن يصف نص العنوان قسمه (2.4.6 Headings and Labels). والنص المنسّق الذي يبدو عنواناً دون أن يُرمَّز كذلك يخفق في 1.3.1.

تحدد المعالم (Landmarks) مناطق الصفحة: header (banner)، وnav (navigation)، وmain، وaside (complementary)، وfooter (contentinfo)، إضافة إلى مناطق search وform. تحقق من أن المحتوى الرئيسي داخل main، وأن التنقل المتكرر داخل nav، وأنه عند وجود عدة مناطق من النوع نفسه تحمل كل منها تسمية مثل «القائمة الرئيسية» و«روابط التذييل». وأخيراً، عنوان الصفحة هو أول ما يُعلَن: يشترط المعيار 2.4.2 Page Titled عنواناً يصف موضوع الصفحة أو غرضها، ويجب على تطبيقات الصفحة الواحدة تحديثه مع كل تغيير في المسار.

الروابط والأزرار وعناصر النماذج والصور

الروابط تنقل؛ والأزرار تنفّذ. فالرابط الذي يرسل نموذجاً، أو الزر الذي ينتقل إلى صفحة أخرى، يربك المستخدمين لأن الدور يتنبأ بالسلوك. ويجب أن يوضح نص الرابط غرضه من النص نفسه أو من سياقه (2.4.4 Link Purpose (In Context))؛ وقائمة روابط مليئة بـ «انقر هنا» و«اقرأ المزيد» تخذل من يتنقل بالروابط. ويجب أن تعلن الأزرار حالتها إن كانت لها حالة: aria-pressed لأزرار التبديل، وaria-expanded للأزرار التي تفتح القوائم والأكورديونات وعناصر الإفصاح.

تحتاج عناصر النماذج إلى اسم ودور وقيمة حالية وحالة (إلزامي، غير صالح، محدَّد، مختار)، وإلى ربط رسالة الخطأ بها لتُعلَن — ويغطي دليل النماذج القابلة للوصول ذلك بالتفصيل. وتحتاج الصور إلى بديل نصي يؤدي الغرض نفسه (1.1.1 Non-text Content): نص alt ذو معنى للصور المعلوماتية، وalt فارغ للصور الزخرفية ليتخطاها قارئ الشاشة؛ ويغطي دليل إمكانية الوصول البصرية نص alt بالتفصيل.

ARIA: الأدوار والحالات والخصائص وقواعد استخدامها

تعرّف WAI-ARIA 1.2 (توصية W3C) الأدوار (Roles: ما هو العنصر، مثل tab وdialog وmenu وalert)، والحالات (States: ظروف تتغير، مثل aria-expanded وaria-checked وaria-selected)، والخصائص (Properties: سمات أكثر ثباتاً، مثل aria-label وaria-controls وaria-required). ولا تغيّر ARIA إلا ما يُكشف في شجرة إمكانية الوصول؛ فهي لا تغيّر السلوك. ودليل ممارسات تأليف ARIA صريح في أن أدوار ARIA لا تجعل المتصفحات توفر سلوك لوحة المفاتيح أو التنسيق — فعنصر div بدور role="button" ما زال يحتاج إلى tabindex ومعالجات للمفاتيح.

قطعتان من إرشادات W3C تلخصان طريقة استخدامها. «القاعدة الأولى لاستخدام ARIA» المعروفة منذ زمن تقول إنه إذا أمكنك استخدام عنصر أو سمة HTML أصلية فيها الدلالات والسلوك المطلوبان مدمجين، فافعل ذلك بدلاً من إضافة ARIA إلى عنصر آخر. ويحذّر مبدأ APG «No ARIA is better than bad ARIA» (غياب ARIA أفضل من ARIA السيئة) من أن ARIA الخاطئة تشوّه تمثيل ما على الشاشة، مما قد يجعل التجربة أسوأ من عدم استخدامها أصلاً. وفي الاختبار، أكثر عيوب ARIA شيوعاً:

• دور بلا سلوك — role="button" أو role="tab" أو role="checkbox" على عناصر لا يمكن التركيز عليها أو تشغيلها من لوحة المفاتيح.
• حالات لا تتغير أبداً — تبقى aria-expanded على "false" بعد فتح القائمة؛ ولا تنتقل aria-selected عند اختيار تبويب آخر.
• aria-hidden="true" على محتوى يحوي عناصر قابلة للتركيز، فيقع تركيز لوحة المفاتيح على شيء لا يدركه قارئ الشاشة.
• aria-label على div أو span عادي بلا دور — إذ تحظر WAI-ARIA 1.2 تسمية الدور generic، فقد لا يُنطق الاسم.
• اسم يناقض التسمية المرئية، وهو إخفاق في 2.5.3 Label in Name.
• أدوار تطبيقات على محتوى عادي — role="menu" على قائمة تنقل الموقع، أو role="application" على منطقة من الصفحة، مما يغيّر طريقة تعامل قارئ الشاشة مع المفاتيح.

المحتوى الديناميكي والمناطق الحية ورسائل الحالة

كل ما يتغير دون تحميل صفحة يبقى غير مرئي لمستخدم قارئ الشاشة ما لم يُعلَن أو ينتقل التركيز إليه. فاختر بين الأمرين عن قصد. انقل التركيز عندما يجب على المستخدم التعامل مع المحتوى الجديد (فتح نافذة حوار، أو تحميل عرض صفحة جديد). وأعلن دون نقل التركيز عندما يكفي أن يعرف المستخدم أن شيئاً حدث: «تم الحفظ»، «3 نتائج»، «أُضيف المنتج إلى السلة»، «جارٍ الرفع 40%». والحالة الثانية هي بالضبط المعيار 4.1.3 Status Messages، الذي يشترط أن تكون رسائل الحالة قابلة للتحديد برمجياً عبر دور أو خصائص حتى تعرضها التقنيات المساعدة دون أن تتلقى التركيز.

الأدوات هنا هي المناطق الحية (Live regions). يناسب role="status" (مهذّب: يُعلَن عندما يكون المستخدم خاملاً) أعداد النتائج والتأكيدات؛ ويُخصَّص role="alert" (حازم: يقاطع) للرسائل المهمة والحساسة للوقت كالأخطاء؛ ويناسب role="log" المحادثات وسجلات النشاط. وعند الاختبار، أطلق كل تغيير واستمع. الإخفاقات المعتادة: تُدرَج المنطقة الحية في الصفحة في اللحظة نفسها مع نصها فلا يُعلَن شيء؛ أو تُخفى المنطقة بـ display: none؛ أو يعلن مؤشر التحميل «جارٍ التحميل» كل نصف ثانية؛ أو يكون كل شيء تنبيهاً فيُقاطَع المستخدم باستمرار.

ثنائيات قارئ الشاشة والمتصفح

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

• Windows — NVDA (مجاني ومفتوح المصدر) مع Firefox أو Chrome؛ وJAWS (تجاري) مع Chrome أو Edge؛ وNarrator المدمج في Windows مع Edge.
• macOS — VoiceOver المدمج، ويُختبر عادةً مع Safari.
• iOS وiPadOS — VoiceOver مع Safari ومع التطبيقات الأصلية.
• Android — TalkBack مع Chrome ومع التطبيقات الأصلية.
• سجّل إصدارات قارئ الشاشة والمتصفح ونظام التشغيل مع كل نتيجة؛ فالسلوك يتغير بين الإصدارات.

روتين عملي لاختبار قارئ الشاشة

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

• 1. حمّل الصفحة — هل يُعلَن عنوانها؟ وهل اللغة والصوت صحيحان؟
• 2. قائمة العناوين — في NVDA: NVDA+F7 (قائمة العناصر)؛ وفي JAWS: Insert+F6؛ وفي VoiceOver على macOS: VO+U (الدوّار Rotor). هل يطابق المخطط البنية المرئية؟
• 3. المعالم — في NVDA: المفتاح D؛ وفي JAWS: المفتاح R؛ وفي VoiceOver: الدوّار ثم Landmarks.
• 4. قائمة الروابط — في NVDA: NVDA+F7؛ وفي JAWS: Insert+F7. هل لكل رابط معنى مفهوم؟
• 5. القراءة بالترتيب — في NVDA وJAWS: Down Arrow؛ وفي VoiceOver على macOS: VO+Right Arrow؛ وفي VoiceOver على iOS وTalkBack: السحب إلى اليمين.
• 6. تشغيل عناصر التحكم — انتقل بـ Tab إلى كل عنصر: هل يُعلَن الاسم والدور والحالة؟ فعّله بـ Enter أو Space، وعلى iOS وAndroid بالنقر المزدوج.
• 7. النماذج — هل تُعلَن التسميات والحقول الإلزامية والأخطاء عند الإرسال؟
• 8. التغييرات الديناميكية — أطلق الإشعارات والمرشحات والتحميل: هل تُعلَن دون نقل التركيز؟
• 9. نوافذ الحوار — هل تُعلَن على أنها نافذة حوار مع اسمها؟ وهل تصمت الصفحة خلفها؟ وهل يعود التركيز عند إغلاقها؟
• 10. أكمل مهمة حقيقية — أنهِ عملية واحدة (بحثاً أو إتمام شراء) بقارئ الشاشة وحده.
• مفتاح NVDA هو Insert (ويمكن ضبط Caps Lock أيضاً)، وVO هو Control+Option؛ ويبدّل NVDA+Space بين وضعي التصفح والتركيز، ويوقف Ctrl النطق.

1. Load the page    Title announced? Language/voice correct?
2. Headings list    NVDA: NVDA+F7 (Elements list) · JAWS: Insert+F6 · VoiceOver macOS: VO+U (rotor)
                   Does the outline match the visual structure?
3. Landmarks        NVDA: D · JAWS: R · VoiceOver: rotor > Landmarks
4. Links list       NVDA: NVDA+F7 · JAWS: Insert+F7 — does each link make sense?
5. Read in order    NVDA/JAWS: Down Arrow · VoiceOver macOS: VO+Right Arrow
                   iOS VoiceOver / TalkBack: swipe right
6. Operate controls Tab to each control: name + role + state announced?
                   Activate: Enter/Space · iOS/Android: double-tap
7. Forms            Labels, required, errors announced on submit?
8. Dynamic changes  Trigger toasts, filters, loading: announced without focus move?
9. Dialogs          Announced as dialog with its name? Background silent? Focus returns on close?
10. Complete task   Finish one real process (search, checkout) with the screen reader only

NVDA key = Insert (Caps Lock can also be set) · VO = Control+Option
NVDA: NVDA+Space toggles browse/focus mode · Ctrl stops speech

جرّبها: مولّد قوائم تحقق QA بالذكاء الاصطناعي

حالات اختبار قارئ الشاشة

استخدمها نتائجَ متوقعة لكل نوع صفحة وكل عملية كاملة ضمن النطاق، مع تسجيل الثنائية المستخدمة مع كل نتيجة.

• SR-01 — يُعلَن عنوان الصفحة عند التحميل ويصف الصفحة (2.4.2).
• SR-02 — لغة الصفحة صحيحة والنص يُقرأ بالصوت الصحيح؛ والمقاطع بلغة أخرى تبدّل الصوت (3.1.1 و3.1.2).
• SR-03 — قائمة العناوين تعكس البنية المرئية بمستويات منطقية (1.3.1 و2.4.6).
• SR-04 — توجد معالم main والتنقل والترويسة والتذييل؛ والأنواع المتكررة من المعالم مسمّاة.
• SR-05 — غرض كل رابط واضح من نصه أو سياقه (2.4.4).
• SR-06 — كل زر وعنصر تحكم يعلن الاسم والدور والحالة؛ وأزرار التبديل تعلن الضغط أو التوسيع (4.1.2).
• SR-07 — للصور المعلوماتية بدائل ذات معنى؛ والصور الزخرفية صامتة (1.1.1).
• SR-08 — العناصر المخصصة تعلن الدور الصحيح وكل تغيير في الحالة (4.1.2).
• SR-09 — رسائل الحالة تُعلَن دون نقل التركيز (4.1.3).
• SR-10 — تُعلَن النافذة المشروطة كنافذة حوار باسمها، ولا تُقرأ الصفحة خلفها ما دامت مفتوحة.
• SR-11 — لا شيء مرئي مخفي عن قارئ الشاشة، ولا شيء مخفي يُقرأ.
• SR-12 — يمكن إتمام عملية كاملة واحدة على الأقل بقارئ الشاشة وحده.

أمثلة على العيوب

مصاغة كعناوين تقارير أخطاء. وفي التقرير أضف الثنائية مع الإصدارات، والخطوات، والإعلان المسموع بنصه — مثلاً: NVDA 2026.x مع Firefox، الانتقال بـ Tab إلى أيقونة البحث، سُمع «button»، والمتوقع «Search, button».

• «زر أيقونة البحث يُعلَن كـ button دون اسم» — 4.1.2 Name, Role, Value.
• «عناوين أكورديون الأسئلة الشائعة لا تعلن حالة التوسيع أو الطي» — 4.1.2 Name, Role, Value.
• «صفحة العروض فيها اثنا عشر رابطاً تُعلَن جميعها «اقرأ المزيد»» — 2.4.4 Link Purpose (In Context).
• «عناوين الأقسام عناصر div منسقة؛ وقائمة العناوين فارغة» — 1.3.1 Info and Relationships.
• «عدد النتائج بعد تطبيق المرشحات لا يُعلَن» — 4.1.3 Status Messages.
• «aria-hidden على الترويسة يخفي زر القائمة القابل للتركيز عن قارئ الشاشة» — 4.1.2 Name, Role, Value.
• «زر «إرسال» يحمل aria-label بقيمة «تقديم النموذج»؛ والأمر الصوتي «انقر إرسال» لا يفعل شيئاً» — 2.5.3 Label in Name.
• «شعار الشركة يُعلَن كـ logo-final-v2.png» — 1.1.1 Non-text Content.

جرّبها: مولّد عناوين الأخطاء بالذكاء الاصطناعي جرّبها: مولّد وصف الأخطاء بالذكاء الاصطناعي

الأسئلة الشائعة

المراجع

• Accessible Rich Internet Applications (WAI-ARIA) 1.2W3C · 2023توصية W3C التي تعرّف أدوار ARIA وحالاتها وخصائصها — أي كيف تُعلن عناصر الواجهة المخصّصة معناها للتقنيات المساعدة.
• ARIA Authoring Practices Guide (APG)W3C Web Accessibility Initiative (WAI)أنماط للعناصر الشائعة (التبويبات والقوائم ونوافذ الحوار والقوائم المنسدلة) مع تفاعل لوحة المفاتيح المتوقع واستخدام ARIA — المرجع الذي تُقارَن به المكونات المخصصة.
• Accessible Name and Description Computation 1.2W3C · 2026كيف تحسب المتصفحات الاسم والوصف الميسَّرين لعنصرٍ من التسميات وسمات ARIA والمحتوى (مسودة عمل من W3C).
• Web Content Accessibility Guidelines (WCAG) 2.2W3C · 2024توصية W3C التي تحدد معايير النجاح القابلة للاختبار لإتاحة محتوى الويب، مرتّبةً تحت أربعة مبادئ وثلاثة مستويات مطابقة (A وAA وAAA).
• Understanding WCAG 2.2W3C Web Accessibility Initiative (WAI)الشرح التوضيحي لكل إرشاد ومعيار نجاح في WCAG 2.2: الغرض، ومن يستفيد، والأمثلة والتقنيات (غير إلزامي).
• Accessibility — MDNMDN Web Docs (Mozilla)أدلة عملية لبناء صفحات ويب ميسّرة وفحصها: HTML الدلالي وARIA ودعم لوحة المفاتيح والاختبار.
• Accessibility — Human Interface GuidelinesAppleإرشادات Apple لتصميم إمكانية الوصول في iOS وغيره: VoiceOver والنص الديناميكي والتباين وأهداف اللمس والحركة.
• Test your app's accessibilityAndroid Developers (Google)كيف تُختبر إمكانية الوصول في تطبيق Android يدوياً باستخدام TalkBack وغيره، وآلياً بأدوات الاختبار في المنصة.