FutureForgeFutureForge

خدمات FutureForge

  • طراحی و ساخت محصولاز شناخت نیاز تا انتشار محصول، یک مسیر روشن پیش رو دارید.
  • توسعه فول‌استکوب‌اپلیکیشن، API و داده را هماهنگ و یکپارچه توسعه دهید.
  • ممیزی مهندسیپیش از هزینه‌ی بیشتر، از وضعیت واقعی محصول‌تان باخبر شوید.
  • مشاوره معماریپیش از یک تصمیم فنی پرهزینه، گزینه‌ها را درست بسنجید.
  • زیرساخت و استقرارمحصول را با خیال راحت منتشر کنید و پایدار نگه دارید.
  • هوش مصنوعی در محصولهوش مصنوعی را فقط جایی به کار می‌گیریم که مسئله‌ای را حل کند.
نمونه‌کارهایادداشت‌هاقیمت‌گذاریدرباره ما
شروع گفتگو
  1. خانه
  2. /یادداشت‌ها
  3. /یادداشت‌ها
FutureForge

استودیوی مهندسی محصول — طراحی، ساخت و استقرار نرم‌افزار.

خدمات

طراحی سایت با وردپرستوسعه اختصاصیمهندسی محصولزیرساخت و استقرارمشاوره معماریهوش مصنوعی در محصول

راهنمای انتخاب

یادداشت‌هاقیمت‌گذاریتخمین هزینه پروژهمقایسه روش‌هانمونه‌کارهادرباره ماتماس

ارتباط

hello@futureforge.ir

ایده‌ای برای ساخت دارید؟

نیازتان را مطرح کنید تا درباره مسیر توسعه و قدم بعدی صحبت کنیم.

شروع گفتگو

© 2026 FutureForge. همه حقوق محفوظ است.

حریم خصوصیشرایط استفاده
خانهنمونه‌کارشروعتماس
مهندسی محصول

تست دسترس‌پذیری صفحه‌کلید: پروتکل دستی بر پایهٔ WCAG 2.2

سا
سهیل ابراهیم‌پور
·۲۹ مهر ۱۴۰۵·3 دقیقه مطالعه
دسترس‌پذیریWCAG 2.2تست صفحه‌کلیدfocus visibleQA
توسعه‌دهنده با صفحه‌کلید در حال تست یک صفحهٔ وب

با Tab و Enter می‌شود بخش بزرگی از مشکلات دسترس‌پذیری را دید. پروتکل کوتاه دستی بر پایهٔ معیارهای 2.1.1، 2.1.2، 2.4.3، 2.4.7 و 4.1.2.

تست صفحه‌کلید ارزان‌ترین بررسی دسترس‌پذیری است: فقط یک صفحه و کلید Tab. این مقاله یک پروتکل کوتاه دستی را بر پایهٔ پنج معیار WCAG 2.2 می‌دهد. ابزارهای خودکار را جایگزین این بررسی نمی‌دانیم و درصدی برای «کشف مشکل توسط ابزار» ادعا نمی‌کنیم.

همه‌چیز با صفحه‌کلید قابل‌انجام است؟

معیار 2.1.1 می‌گوید همهٔ قابلیت‌های محتوا باید با صفحه‌کلید قابل‌انجام باشد و کلیدها نیازی به زمان‌بندی خاص نداشته باشند، مگر کارهایی که ذاتاً به مسیر حرکت وابسته‌اند (مثل ترسیم آزاد). تست: ماوس را کنار بگذارید و با Tab، Shift+Tab، Enter، Space و کلیدهای جهت‌دار منو، فرم، دیالوگ و کشوی صفحه را کامل کنید.

گیر افتادن فوکوس

طبق 2.1.2 اگر فوکوس به مؤلفه‌ای رسید، باید بتوان با صفحه‌کلید از آن خارج شد؛ اگر خروج به کلیدی غیر از Tab یا فلش‌ها نیاز دارد، باید به کاربر گفته شود. مودال‌ها و ویجت‌های سفارشی نخستین مظنون‌اند: Esc کار می‌کند؟ فوکوس به نقطهٔ درست برمی‌گردد؟ (جزئیات پیاده‌سازی مودال خارج از دامنهٔ این مقاله است.)

ترتیب فوکوس

معیار 2.4.3 می‌خواهد وقتی ترتیب پیمایش بر معنا یا عملکرد اثر دارد، فوکوس به ترتیبی حرکت کند که معنا حفظ شود. تست: با Tab صفحه را بخوانید؛ آیا ترتیب با ترتیب منطقی خواندن و انجام کار می‌خواند؟ در صفحات راست‌به‌چپ هم ترتیب باید برای خواننده منطقی باشد. (این جمله توصیهٔ نویسنده است.)

نمایش ترتیب فوکوس
نمودار مفهومی.

فوکوس دیده می‌شود؟

معیار 2.4.7 (سطح AA) می‌گوید باید حالتی وجود داشته باشد که نشانگر فوکوس دیده شود و نشانگر نباید زمان‌دار باشد؛ اگر نشانگر یک بار نشان داده شد، باید بماند. WCAG 2.2 معیار 2.4.13 (سطح AAA) را هم برای ظاهر نشانگر (اندازه و شکل) آورده است. اگر در CSS حاشیهٔ پیش‌فرض را حذف کرده‌اید، جایگزینی مشخص بگذارید.

نام و نقش کنترل

معیار 4.1.2 می‌گوید نام و نقش مؤلفه‌ها باید به‌صورت برنامه‌ای قابل‌تشخیص باشد. W3C یادآوری می‌کند کنترل‌های استاندارد HTML، اگر طبق مشخصات استفاده شوند، این معیار را برآورده می‌کنند؛ مشکل بیشتر در مؤلفه‌های سفارشی است. تست دستی: با یک screen reader (مثلاً NVDA یا VoiceOver) روی دکمه‌ها و فیلدها بروید و ببینید نام و نقششان شنیده می‌شود. (نام ابزارها نمونه است؛ ما مستندات‌شان را بررسی نکردیم.)

پروتکل ده‌دقیقه‌ای

  1. ماوس را کنار بگذارید و بالای صفحه را با Tab شروع کنید.
  2. ترتیب را با منطق صفحه مقایسه کنید.
  3. در هر توقف بپرسید: فوکوس دیده می‌شود؟
  4. منو، فرم، مودال و کشو را کامل کنید و خروج را تست کنید.
  5. هر مشکل را با صفحه، گام و معیار مرتبط ثبت کنید.

برای مبانی بیشتر Accessibility چیست؟ و برای دید کلی UX چیست؟ را ببینید.

منابع و مراجع

  • Understanding SC 2.1.1: Keyboard — W3C WAI، WCAG 2.2.
  • Understanding SC 2.1.2: No Keyboard Trap — W3C WAI، WCAG 2.2.
  • Understanding SC 2.4.3: Focus Order — W3C WAI، WCAG 2.2.
  • Understanding SC 2.4.7: Focus Visible — W3C WAI، WCAG 2.2.
  • Understanding SC 4.1.2: Name, Role, Value — W3C WAI، WCAG 2.2.

نویسنده

سا

سهیل ابراهیم‌پور بنیان‌گذار FutureForge است. روی طراحی محصول، معماری و استقرار نرم‌افزار سفارشی کار می‌کند.

یادداشت‌های مرتبط

یادداشت‌های مرتبط

دسته‌بندی‌ها

خدمات مرتبط

از یادداشت تا پروژه

اگر با مسئله‌ای شبیه این روبه‌رو هستید، درباره‌ی شرایط پروژه‌تان با هم صحبت کنیم.

برای انتخاب مسیر فنی پروژه‌تان کمک می‌خواهید؟

از مسئله و محدودیت‌هایتان بگویید؛ اگر بتوانیم همراهی‌تان کنیم، برای گفت‌وگو هماهنگ می‌کنیم.

سهیل ابراهیم‌پور
یادداشت‌ها
Accessibility چیست و چرا باید برای همه کاربران طراحی کنیم؟
طراحی منوی سایت فارسی و راست‌چین: ملاحظات فنی و دسترس‌پذیری
توکن‌های طراحی چیستند؟ هم‌نام‌سازی Figma و کد
سیستم طراحی کوچک برای تیم وب: چه زمانی ارزش دارد؟
نرم‌افزار قدیمی را از نو بنویسیم یا کم‌کم نوسازی کنیم؟

مهندسی محصول

Accessibility چیست و چرا باید برای همه کاربران طراحی کنیم؟

۲۹ شهریور ۱۴۰۵

مهندسی محصول

طراحی منوی سایت فارسی و راست‌چین: ملاحظات فنی و دسترس‌پذیری

۲۶ مهر ۱۴۰۵

مهندسی محصول

توکن‌های طراحی چیستند؟ هم‌نام‌سازی Figma و کد

۲۸ مهر ۱۴۰۵

مهندسی محصول

سیستم طراحی کوچک برای تیم وب: چه زمانی ارزش دارد؟

۲۸ مهر ۱۴۰۵

مهندسی محصول

نرم‌افزار قدیمی را از نو بنویسیم یا کم‌کم نوسازی کنیم؟

۲۷ مهر ۱۴۰۵
همه یادداشت‌ها249
معماری نرم‌افزار15
واژه‌نامه37
عملیات و استقرار87
مهندسی محصول98
راهنمای وب12
طراحی و ساخت محصول
توسعه فول‌استک
ممیزی مهندسی
مشاوره معماری
زیرساخت و استقرار
شروع گفتگو
ابزارهای رایگان
شروع گفتگو