موجهات إمكانية الوصول لمراجعات واجهات React وFlutter

ما الذي يغفل عنه الناس عند محاولتهم جعل واجهة قابلة للوصول

معظم مشكلات إمكانية الوصول ليست قضايا «إعادة تصميم كبيرة». هي تفاصيل صغيرة تقرر ما إذا كان شخص ما يستطيع استخدام واجهتك على الإطلاق.

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

إليك الأماكن الأولى التي تفشل فيها الواجهات عادةً:

• وصول لوحة المفاتيح: لا يمكنك الوصول إلى عناصر تحكم رئيسية، أو يتم حبسك داخل نافذة منبثقة
• ترتيب التركيز وحالات التركيز: الحدود تقفز، أو لا يمكنك رؤية مكانك
• التسميات والأسماء: المدخلات والأزرار لها أسماء وصول غير واضحة أو مفقودة
• الإعلانات: تحدث تحديثات ديناميكية لكن قارئات الشاشة لا تُعلَم بها
• التباين والوضوح: النصوص، الأيقونات، وحالات الخطأ صعبة الرؤية

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

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

هذا المنشور يمنحك شيئين: موجهات قابلة للنسخ يمكنك استخدامها مع كود الواجهة (React وFlutter)، وتدفق مراجعة قابل للتكرار يمكنك تشغيله في دقائق. الهدف ليس الكمال من اليوم الأول، بل رصد المشكلات التي تمنع المستخدمين الحقيقيين.

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

خمسة فحوصات تكتشف معظم المشكلات بسرعة

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

1) هل يمكنك استخدامها بلوحة مفاتيح فقط؟

جرّب التنقل عبر الصفحة بدون ماوس. استخدم Tab وShift+Tab للتنقل، Enter وSpace للتفعيل، ومفاتيح الأسهم حيث يبدو ويدجت كقائمة أو تبويبات أو قائمة.

علامة سريعة: إذا حُبست داخل مربع حوار، أو لم تستطع الوصول إلى عنصر تحكم رئيسي (مثل «إغلاق»)، فهناك خلل.

2) هل ترتيب التركيز منطقي وهل التركيز مرئي؟

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

3) هل للعناصر أسماء واضحة؟

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

4) هل التباين وحجم النص مناسبان؟

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

5) هل التغييرات معلنة بوضوح؟

عندما يتغير شيء (خطأ، تحميل، نجاح)، لا ينبغي للمستخدمين التخمين. استخدم نص خطأ داخل الحقل بجانبه، أعلن أخطاء النموذج، واجعل حالات التحميل واضحة.

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

حدّد نطاق المراجعة قبل أن تبدأ بتغيير الواجهة

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

اختر الرحلات التي تهم

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

بالنسبة لمعظم التطبيقات، يكون ذلك مثل تسجيل الدخول، وتدفق «إنشاء أو شراء» أساسي (خروج، حجز، إرسال)، ومنطقة حساب مثل الإعدادات أو الملف الشخصي.

ثم دوّن الشاشات الدقيقة في كل رحلة (حتى لو كانت 5 إلى 8 شاشات فقط). ضمن الحالات «الوسيطية» أيضًا: رسائل الخطأ، الحالات الفارغة، حالات التحميل، ومربعات التأكيد. تلك هي الأماكن التي غالبًا ما ينكسر فيها التركيز وإخراج قارئ الشاشة.

مثال ملموس: إذا كنت تبني شاشة CRM صغيرة في Koder.ai، حدّد النطاق إلى «تسجيل الدخول -> فتح جهات الاتصال -> إضافة جهة اتصال -> حفظ -> رؤية رسالة نجاح». هذه الرحلة الواحدة تتضمن نماذج، تحقق، حوارات، وإعلانات.

قرر ماذا يعني «نجاح»

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

استخدم صيغة ملاحظة نجاح/فشل بسيطة حتى لا تضيع وقتًا في الجدال. لكل شاشة، سجّل:

• الفحص: (لوحة المفاتيح، ترتيب التركيز، التسميات، التباين، الإعلانات)
• النتيجة: نجاح أو فشل
• الدليل: جملة واحدة تصف ما حدث
• تخمين الإصلاح: ما الذي يحتاج تغييره (مكوّن، خاصية، تنسيق)
• إعادة الاختبار: ماذا تجرب بعد الإصلاح

هذا يحافظ على اتساق المراجعات عبر React وFlutter، ويسهل تسليم المشكلات لغيرك دون إعادة شرح المشكلة.

موجهات قابلة للنسخ لمكونات React (لوحة المفاتيح، التسميات، الأدوار)

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

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

Review this React component for keyboard navigation issues. 
- Can every interactive element be reached with Tab and activated with Enter/Space?
- List the exact problems you see in the code.
- Propose fixes with small code edits.

Check focus order and focus visibility.
- Describe the expected focus order for a keyboard-only user.
- Point out where focus could get lost (modals, menus, drawers).
- Tell me exactly where to add :focus-visible styles (which elements, which CSS).

Find missing accessible names.
- Identify inputs, buttons, and icons without clear labels.
- Suggest label + htmlFor, aria-label, aria-labelledby, or visible text.
- If there is helper/error text, connect it with aria-describedby.

Identify interactive elements that are not buttons/links.
- Find div/span with onClick, custom dropdowns, and clickable cards.
- Suggest correct semantics (button/a) or add role, tabIndex, and keyboard handlers.

List screen reader announcements that will be confusing.
- Predict what a screen reader will announce for key controls.
- Rewrite UI text to be shorter and clearer.
- Suggest aria-live usage for status changes (loading, errors, saved).

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

• ما هو المكوّن (مثال: «نموذج تسجيل»، «مفتاح تسعير»، «نافذة إعدادات»).
• مسار لوحة المفاتيح الذي يجب أن يتبعه المستخدم (نقطة البداية ونقطة النهاية).
• أي مكتبة واجهة مستخدم مستخدمة (MUI, Chakra, Radix, مكوّنات مخصصة).
• الحالات التي يجب اختبارها (تحميل، خطأ، معطّل، نتائج فارغة).
• هدف مستخدم واحد محدد (مثال: «تغيير الخطة والتأكيد»).

موجهات قابلة للنسخ لويدجتات Flutter (Semantics, التركيز، الإيماءات)

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

موجهات يمكنك لصقها في المراجعة

Review this Flutter widget tree for keyboard navigation and focus traversal.
Call out focus traps, missing focus order, and places where Tab/Shift+Tab will feel confusing.
Suggest exact widget changes (Focus, FocusTraversalGroup, Shortcuts, Actions).

Check this screen for missing Semantics labels, hints, and tap targets.
Point to the exact widgets that need Semantics(label/hint), tooltip, or exclusion.
Also flag controls under 48x48 logical pixels and suggest fixes.

Find custom gestures that break accessibility (GestureDetector/Listener).
Replace them with accessible widgets or add keyboard + semantics support.
If a gesture is required, describe how a keyboard user triggers the same action.

Audit error messages and validation on this form.
What should be announced to a screen reader, and when?
Suggest how to expose errors via Semantics and focus movement after submit.

Propose a consistent focus highlight style across screens.
It should be obvious on dark/light themes and work with keyboard navigation.
Show a small code example using FocusTheme/ThemeData.

إصلاحات سريعة يجب أن يقترحها المساعد

توقّع إجابات تذكر بضعة أنماط ملموسة:

• لفّ المحتوى الرئيسي في FocusTraversalGroup واضبط FocusTraversalOrder فقط عند الحاجة.
• استخدم Semantics (أو MergeSemantics) للتحكمات المركّبة، وتجنب التسميات المكررة.
• فضّل InkWell, IconButton, ListTile, SwitchListTile بدل GestureDetector الخام عندما أمكن.
• أضف Shortcuts + Actions للمداخل غير النصية (مثال: Enter للتفعيل، Escape للإغلاق).

مثال أدنى لجعل بطاقة مخصصة تتصرف كزر:

Semantics(
  button: true,
  label: 'Add payment method',
  hint: 'Opens the add card screen',
  child: Focus(
    child: InkWell(
      onTap: onPressed,
      child: Card(child: child),
    ),
  ),
)

خطوة بخطوة: تدفق مراجعة بسيط للوحة المفاتيح والتركيز

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

تدفق الخمس خطوات

ابدأ باختيار «مسار سعيد» واحد يتخذه المستخدم عادة، مثل تسجيل الدخول، فتح شاشة الإعدادات، والحفظ.

1. قم بالمسار كاملًا بلوحة المفاتيح فقط. ضع الماوس جانبًا. استخدم Tab وShift+Tab للتنقل، Enter وSpace للتفعيل، ومفاتيح الأسهم حيث يكون ذلك منطقيًا. إذا احتاج شيء لنقرة أو سحب، علّمه.
2. تأكد أن التركيز دائمًا واضح. في كل مرة يتحرك فيها التركيز، يجب أن ترى فورًا مكانه. راقب الحدود الرفيعة التي تختفي على الخلفيات الداكنة، حلقات التركيز المحذوفة عبر CSS، أو ويدجتات Flutter التي تبدو «نشطة» لكنها لا تظهر التركيز.
3. افحص أن الترتيب يطابق ما تراه. يجب أن يتبع التركيز التخطيط البصري وترتيب القراءة. علامات التحذير الشائعة: القفز إلى تذييل، الحبس في شريط جانبي، أو تخطي حقل لأنه غير قابل للتركيز.
4. اختبر التراكبات. افتح القوائم، الحوارات، والدرّوج. يجب أن ينتقل التركيز داخل التراكب، يبقى داخله أثناء الفتح، ويعود إلى مكان منطقي عند الإغلاق. يجب أن يغلق Escape التراكب عندما يكون مناسبًا.
5. أعد الاختبار بعد كل تغيير. أصلح مشكلة واحدة، ثم أعد تشغيل المسار نفسه. سجّل ما تحسّن وما تدهور، خصوصًا تغيّرات ترتيب التركيز ونقاط النهاية الجديدة.

ماذا تسجّل أثناء العمل

اجعله بسيطًا: اسم الصفحة، ما ضغطت، ماذا حدث، وما توقعت. هذه السجلّات الصغيرة تُسهّل التأكد من أن إعادة تركيب React أو استبدال ويدجت Flutter لم يكسر وصول لوحة المفاتيح بصمت.

أسماء يسهل على قارئ الشاشة التعامل معها، التسميات، والإعلانات

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

ابدأ بحقول النماذج. كل مدخل يحتاج تسمية حقيقية تبقى صحيحة حتى عندما يملأ الحقل. العناصر النائبة (placeholders) هي تلميحات، ليست تسميات، وغالبًا ما تختفي بمجرد أن يكتب المستخدم.

الإجراءات ذات الأيقونات فقط تُغفل كثيرًا. أيقونة سلة المهملات، قلم، أو قائمة ثلاث نقاط تحتاج اسمًا ذا معنى يطابق النتيجة، لا شكلها. «حذف المشروع» أفضل من «زر» أو «سلة».

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

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

موجهات مراجعة قابلة للنسخ (React وFlutter)

استخدم هذه الموجهات عند مراجعة شاشة أو عند طلب تحديث من أداة مثل Koder.ai:

• «مرّر هذه الشاشة وتأكد أن كل حقل نصي له تسمية مرئية، وأن اسم الوصول يطابقها (React: label + htmlFor, aria-labelledby; Flutter: InputDecoration.labelText).»
• «اعثر على الأزرار التي بها أيقونات فقط وأعطِ كل واحد اسم وصول يشرح الإجراء (React: aria-label; Flutter: Tooltip أو Semantics(label: ...)).»
• «تحقق من العناوين: استخدم مستويات عنوان صحيحة في React، وعناوين أقسام واضحة في Flutter حتى تُقرأ البنية بشكل صحيح.»
• «أعد كتابة أخطاء التحقق بحيث تشرح ما حدث وكيف تصلحه، وتأكد أن الخطأ يُعلن عند ظهوره.»

الإعلانات للتحديثات الديناميكية

تتغير العديد من الشاشات دون إعادة تحميل: حفظ ملف تعريفي، إضافة عنصر، تحميل نتائج. تأكد من أن هذه التحديثات معلنة.

بالنسبة لـReact، فضّل منطقة aria-live (polite لرسائل مثل «تم الحفظ»، assertive للأخطاء الحرجة). بالنسبة لـFlutter، استخدم Semantics واجعل رسائل الحالة مرئية (مثال: شريط تنبيهات أو SnackBar) حتى تُقرأ، لا تُعرض فقط. فحص سريع: نفّذ «حفظ»، وتأكد أنك تسمع رسالة قصيرة مثل «تم حفظ التغييرات» دون أن يختفي التركيز من الزر.

فحوصات التباين والوضوح البصري التي لا تستغرق وقتًا طويلاً

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

جولة تباين في 10 دقائق

ابدأ بمسح شاشة واحدة عند تكبير 100% ثم 200%. إذا أصبح شيء صعب القراءة، فغالبًا ما تكون المشكلة تباينًا أو وزنًا أو تباعدًا، ليس «خطأ المستخدم».

تحقق من هذه الخمس نقاط أولًا:

• نص الجسم، التسميات التوضيحية، ونص المساعدة (خصوصًا الرمادي الفاتح على الأبيض)
• حالات المعطّل (يجب أن تبدو معطّلة، لكن لا تزال مقروءة)
• الأيقونات بدون تسميات (الأيقونة الخافتة شبه غير مرئية لكثير من المستخدمين)
• مؤشرات التركيز (الحلقة/الحد يجب أن تبرز عن الخلفية)
• رسائل الخطأ والنجاح (نص وأيقونة، لا تعتمد على اللون فقط)

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

غالبًا ما يُغفل وضوح التركيز. تأكد أن حلقة التركيز سميكة بما يكفي للانتباه، وليست نفس لون الخلفية. إذا كان لديك حالة «محددة» في قائمة، يجب أن تبدو مختلفة حتى بالدرج الرمادي، مثل إضافة أيقونة أو خط سفلي أو حد واضح.

وضوح على الجوال: نقاط اللمس والسمات

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

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

إذا كنت تولّد واجهات بسرعة في أداة مثل Koder.ai، أضف خطوة مراجعة إضافية: اطلب «فحص التباين وحلقة التركيز» بعد التخطيط الأولي قبل تلميع المرئيات.

أخطاء شائعة تتكرر دائمًا

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

النص النائب ليس تسمية. العنصر النائب يختفي عند الكتابة، والعديد من قارئات الشاشة لا تعاملها كاسم الحقل. استخدم تسمية مرئية حقيقية (أو اسم وصول صريح) حتى يكون الحقل مفهومًا وهو فارغ ومعبأ وعند ظهور الأخطاء.

تُزال أنماط التركيز لأنها «قبيحة». هذا يفقد مستخدمي لوحة المفاتيح. إذا غيرت حد المتصفح الافتراضي، استبدله بشيء واضح بالمثل: حلقة قوية، تغيير خلفية، وتباين كافٍ ضد الصفحة.

مخادع الأزرار شائع آخر. في React من المغري استخدام div مع onClick، وفي Flutter استخدام Container مع GestureDetector. بدون دلالات مناسبة، يفقد دعم لوحة المفاتيح وقارئات الشاشة. عناصر التحكم الأصلية (button, a, TextButton, ElevatedButton) تعطيك التركيز والدور وحالة التعطيل وسلوك التفعيل مجانًا.

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

الإفراط في استخدام ARIA أو Semantics يمكن أن يكسر أيضًا. إضافة أدوار وتسميات في كل مكان قد تتعارض مع ما يوفره العنصر الأصلي، مما يؤدي إلى إعلانات مزدوجة أو أسماء خاطئة.

فحص سريع لقضايا متكررة يمكنك طلبه عند مراجعة شاشة:

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

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

مثال عملي: شاشة واحدة، من البداية إلى النهاية

تخيل شاشة إعدادات بسيطة: نموذج ملف شخصي (الاسم، البريد)، مفتاحا تبديل (إشعارات البريد، الوضع الداكن)، زر «حفظ التغييرات»، وتنبيه يظهر بعد الحفظ.

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

فحص سريع يصلح لمعظم موجهات المراجعة:

• اضغط Tab من الأعلى: يهبط التركيز على الاسم، ثم البريد، ثم مفتاح إشعارات البريد، ثم مفتاح الوضع الداكن، ثم حفظ التغييرات.
• استخدم Shift+Tab للعودة وتأكد أنها تعكس الترتيب نظيفًا.
• في المفاتيح، يجب أن يغيّر Space الحالة. لا يجب أن تحبس مفاتيح الأسهم التركيز.
• على حفظ التغييرات، يجب أن يرسل Enter الإجراء، ولا يجب أن يختفي التركيز بعد الإرسال.
• عند ظهور التنبيه (toast)، يجب أن يبقى التركيز حيث كان ما لم يكن للتنبيه فعل مثل «تراجع».

الآن افحص ما يعلنه قارئ الشاشة. كل عنصر يحتاج اسمًا واضحًا، دورًا، وحالة. مثال: «الاسم، حقل نص، مطلوب» و«إشعارات البريد، تبديل، تشغيل». إذا كان حقل البريد به خطأ، يجب أن يُعلن عند دخول التركيز للحقل وعند ظهور الخطأ (مثال: «البريد، حقل نص، غير صالح، أدخل بريدًا صالحًا»). يجب أن يقرأ زر الحفظ كـ «حفظ التغييرات، زر» ويُعطّل فقط مع شرح سبب التعطيل.

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

حوّل ما تجده إلى قائمة إصلاحات قصيرة:

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

إذا كنت تبني في Koder.ai، ألصق وصف الشاشة ونتائجك في الدردشة واطلب تحديث React أو Flutter ليتطابق مع سلوك لوحة المفاتيح وقارئ الشاشة المتوقع.

الخطوات التالية: أعد استخدام هذه القائمة واجعلها جزءًا من سير عملك

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

احتفظ بـ«تعريف إنجاز» واحد لتغييرات الواجهة. قبل أي شحن، قم بمرور سريع يغطي لوحة المفاتيح، التركيز، الأسماء، والتباين. يستغرق بضع دقائق عندما تفعله غالبًا.

إليك قائمة فحص سريعة يمكنك تشغيلها على أي واجهة تقريبًا:

• لوحة المفاتيح: هل يمكنك الوصول إلى كل عنصر تفاعلي واستخدامه بدون ماوس؟
• التركيز: هل التركيز مرئي وهل يتحرك بترتيب منطقي؟
• التسميات: هل لكل حقل وزر اسم واضح (بما في ذلك الأيقونات)؟
• الإعلانات: هل تُعلن تغييرات الحالة (أخطاء، تحميل، نجاح)؟
• التباين: هل النص مقروء وهل حالات المعطّل مفهومة؟

احفظ أفضل موجهاتك كقوالب. طريقة بسيطة هي الاحتفاظ بموجه «مراجعة React» و«مراجعة Flutter» تلصقهما في نهاية كل طلب تغيير. ثم أضف سطرًا قصيرًا يصف المكوّن الجديد وأي سلوك خاص (مودال، خطوات، قائمة بتمرير لا نهائي).

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

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

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