آموزش دسترس‌پذیری در Gutenberg و Site Editor وردپرس؛ راهنمای عملی WCAG

دسترس‌پذیری در Gutenberg و Site Editor یعنی محتوای سایت برای کاربران بیشتری قابل درک، پیمایش و استفاده باشد؛ از جمله افرادی که با صفحه‌کلید، Screen Reader، بزرگ‌نمایی، فرمان صوتی، نمایشگر کم‌نور یا دستگاه‌های ورودی جایگزین کار می‌کنند. دسترس‌پذیری فقط یک قابلیت فنی یا گزینه اختیاری نیست؛ بخشی از کیفیت طراحی، تجربه کاربر، نگهداری حرفه‌ای و مسئولیت انتشار محتواست.

در وردپرس، قالب و بلوک‌های هسته می‌توانند پایه مناسبی فراهم کنند، اما فعال‌کردن Gutenberg یا Block Theme به‌تنهایی سایت را دسترس‌پذیر نمی‌کند. نویسنده باید ساختار Heading را درست بسازد، برای تصاویر متن جایگزین مناسب بنویسد، لینک و دکمه را از هم تشخیص دهد، کنتراست رنگ و Focus را حفظ کند و فرم، منو، جدول، ویدئو و محتوای پویا را آزمایش کند.

این راهنما بر WordPress 7.0.2، استاندارد WCAG 2.2 سطح AA و ابزارهای Gutenberg و Site Editor تمرکز دارد. ساختار معنایی، Alt تصاویر، صفحه‌کلید، Navigation، Landmark، Skip Link، رنگ، تایپوگرافی، فرم‌ها، Media، Query Loop، Pattern، Template، آزمایش Screen Reader و مسیر متفاوت WoodMart را مرحله‌به‌مرحله بررسی می‌کنیم.

دسترس‌پذیری وب چیست؟

Web Accessibility یا A11y مجموعه‌ای از اصول طراحی، محتوا و توسعه است که موانع استفاده از وب را کاهش می‌دهد. این موضوع فقط مربوط به نابینایی نیست و گروه‌های متنوعی را شامل می‌شود:

• کاربران نابینا یا کم‌بینا
• کاربران دارای محدودیت حرکتی
• کاربران ناشنوا یا کم‌شنوا
• کاربران دارای اختلال شناختی یا یادگیری
• افرادی که موقتاً آسیب دیده‌اند
• کاربران سالمند
• افرادی که در نور شدید، صدای زیاد یا اینترنت ضعیف کار می‌کنند
• کاربرانی که فقط صفحه‌کلید یا فرمان صوتی در اختیار دارند

طراحی دسترس‌پذیر اغلب برای همه مفید است. Caption ویدئو در محیط شلوغ، کنتراست مناسب در نور روز، ساختار Heading برای اسکن سریع و دکمه بزرگ برای موبایل نمونه‌هایی از این اثر عمومی هستند.

WCAG 2.2 چیست؟

WCAG مخفف Web Content Accessibility Guidelines است. این استاندارد چهار اصل اصلی دارد:

• Perceivable: اطلاعات باید به شکل قابل دریافت ارائه شوند؛ مانند Alt برای تصویر و Caption برای ویدئو.
• Operable: رابط باید با روش‌هایی مانند صفحه‌کلید قابل استفاده باشد.
• Understandable: متن، Label، Navigation و خطاها باید قابل فهم باشند.
• Robust: ساختار باید توسط مرورگرها و فناوری‌های کمکی قابل تفسیر باشد.

سطح A حداقل موانع گسترده را هدف می‌گیرد، سطح AA نیازهای رایج‌تر و حرفه‌ای‌تر را پوشش می‌دهد و سطح AAA معیارهای پیشرفته‌تر و سخت‌گیرانه‌تری دارد. هدف عملی رایج برای سایت‌های حرفه‌ای، WCAG 2.2 سطح AA است.

بهبودهای دسترس‌پذیری WordPress 7.0

WordPress 7.0 مجموعه‌ای از اصلاحات دسترس‌پذیری در Core و Gutenberg ارائه کرده است. تغییرات مهم شامل بهبود استفاده از Media Library با فناوری فرمان صوتی، اصلاح Contrast در بخش‌هایی از رابط مدیریت و بهبود Semantics کنترل‌هاست.

در این نسخه، اگر اطلاعات Alt استاندارد داخل Metadata تصویر موجود باشد، وردپرس می‌تواند آن را هنگام ورود رسانه به‌عنوان متن جایگزین وارد کند. این قابلیت مسئولیت بررسی انسانی را حذف نمی‌کند؛ Alt واردشده باید با کاربرد واقعی تصویر در صفحه هماهنگ باشد.

قالب یا بلوک دسترس‌پذیر کافی نیست

حتی بهترین Block Theme نیز می‌تواند با محتوای نادرست، صفحه‌ای غیرقابل استفاده تولید کند. مثال‌ها:

• قرار دادن متن مهم داخل تصویر بدون متن جایگزین
• حذف Focus Outline با CSS
• ساخت Heading براساس اندازه ظاهری، نه ساختار
• استفاده از رنگ به‌عنوان تنها نشانه خطا
• لینک‌های متعدد با متن «اینجا کلیک کنید»
• ساخت فرم بدون Label
• Navigation Overlay که با Escape بسته نمی‌شود
• ویدئوی بدون Caption

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

مرحله اول: ساختار Heading را درست کنید

Headingها نقشه محتوای صفحه هستند. Screen Reader می‌تواند فهرست Headingها را برای حرکت سریع ارائه دهد و کاربر بینا نیز با آن‌ها صفحه را اسکن می‌کند.

قواعد عملی Heading

• یک H1 اصلی برای موضوع صفحه داشته باشید.
• بخش‌های اصلی را با H2 مشخص کنید.
• زیرموضوع H2 را با H3 بسازید.
• فقط برای ظاهر بزرگ‌تر از Heading استفاده نکنید.
• سطح‌ها را بدون دلیل از H2 به H4 نپرید.
• Heading خالی نسازید.
• Heading را با Paragraph Bold جایگزین نکنید.

بررسی Outline در Gutenberg

در Block Editor از Document Overview یا Outline استفاده کنید. این بخش فهرست Headingهای نوشته یا برگه را نمایش می‌دهد و پرش‌های غیرمنطقی را مشخص می‌کند.

قالب ممکن است Post Title را به‌صورت H1 نمایش دهد. قبل از افزودن H1 داخل محتوا، خروجی Template را بررسی کنید. در بیشتر نوشته‌ها، عنوان نوشته H1 است و محتوای داخلی از H2 شروع می‌شود.

مرحله دوم: Alt تصاویر را درست بنویسید

Alternative Text محتوای یا کارکرد تصویر را برای کسی که آن را نمی‌بیند توضیح می‌دهد. Alt باید براساس نقش تصویر در همان صفحه نوشته شود.

تصویر محتوایی

اطلاعات ضروری تصویر را کوتاه و روشن توضیح دهید. برای Screenshot آموزشی، فقط «تصویر وردپرس» کافی نیست؛ عمل یا بخش مهم را توضیح دهید.

تصویر تزئینی

اگر تصویر فقط تزئینی است و حذف آن اطلاعاتی را از بین نمی‌برد، Alt خالی مناسب است. Screen Reader از آن عبور می‌کند.

تصویر لینک‌شده

Alt باید مقصد یا کارکرد لینک را توضیح دهد. تکرار عبارت «لینک به» معمولاً لازم نیست.

لوگو

نام برند برای Alt لوگو کافی است. عبارت «تصویر لوگوی» اغلب اضافه است.

اشتباهات رایج Alt

• تکرار نام فایل
• Keyword Stuffing برای سئو
• شروع همه Altها با «تصویر»
• نوشتن توضیح بسیار طولانی برای تصویر ساده
• خالی‌گذاشتن Alt تصویر آموزشی مهم
• نوشتن Caption داخل Alt بدون نیاز
• استفاده از یک Alt ثابت برای تصاویر متفاوت

Alt برای SEO نوشته نمی‌شود؛ هدف اصلی انتقال معنی و عملکرد تصویر است. متن طبیعی و دقیق معمولاً برای موتور جست‌وجو نیز بهتر است.

Caption و Description چه تفاوتی با Alt دارند؟

• Alt: جایگزین تصویر برای زمانی که تصویر دیده نمی‌شود.
• Caption: متنی که معمولاً زیر تصویر برای همه نمایش داده می‌شود.
• Description: اطلاعات طولانی‌تر در کتابخانه رسانه یا Attachment Page.

Caption جای Alt را نمی‌گیرد، مگر ساختار فنی به‌درستی ارتباط آن‌ها را برقرار کرده باشد.

مرحله سوم: لینک و دکمه را اشتباه نگیرید

لینک کاربر را به مقصد دیگری می‌برد. دکمه عملی را اجرا می‌کند؛ مانند بازکردن Dialog، ارسال فرم یا تغییر وضعیت.

• «مشاهده مقاله» باید Link باشد.
• «ارسال فرم» باید Button باشد.
• «بازکردن فیلتر» باید Button باشد.
• «رفتن به صفحه تماس» باید Link باشد.

ظاهر یکسان دلیل نمی‌شود عنصر معنایی اشتباه انتخاب شود. Screen Reader نوع کنترل را اعلام می‌کند و رفتار صفحه‌کلید نیز متفاوت است.

متن لینک قابل فهم بنویسید

کاربر باید بدون خواندن جمله اطراف نیز مقصد لینک را بفهمد. عبارت‌های «اینجا»، «بیشتر» و «کلیک کنید» در فهرست لینک‌های Screen Reader مبهم‌اند.

به‌جای «برای آموزش بیشتر اینجا کلیک کنید»، بنویسید «آموزش کامل Gutenberg را مطالعه کنید».

لینک بازشونده در تب جدید

بازشدن ناگهانی تب جدید می‌تواند کاربر را سردرگم کند. فقط در موارد منطقی از آن استفاده کنید و رفتار را در متن یا Label روشن کنید. لینک‌های داخلی معمولاً بهتر است در همان تب باز شوند.

مرحله چهارم: کنتراست رنگ را بررسی کنید

برای متن عادی، WCAG 2.2 سطح AA معمولاً حداقل نسبت ۴٫۵ به ۱ را تعیین می‌کند. برای متن بزرگ، حداقل ۳ به ۱ کافی است. اجزای غیرمتنی مهم مانند Border فیلد، Icon کنترلی و Focus نیز باید در برابر رنگ مجاور کنتراست کافی داشته باشند.

موارد حساس

• متن خاکستری روی سفید
• دکمه زرد با متن سفید
• لینک کم‌رنگ داخل Paragraph
• Placeholder فرم
• متن روی Cover Image
• فوتر تیره
• دکمه Outline
• Focus Ring

رنگ نباید تنها روش انتقال وضعیت باشد. برای خطا از Icon، متن یا Border همراه رنگ استفاده کنید.

هشدار Contrast در ویرایشگر

Gutenberg در برخی ترکیب‌های رنگ می‌تواند درباره خوانایی ضعیف هشدار دهد. این هشدار مفید است، اما همه حالت‌های واقعی، تصاویر پس‌زمینه، Gradient و CSS سفارشی را پوشش نمی‌دهد. نتیجه را با ابزار Contrast و در Front-end بررسی کنید.

Focus را حذف نکنید

وقتی کاربر با Tab حرکت می‌کند، باید بداند کدام لینک، دکمه یا فیلد فعال است. CSSهایی مانند outline: none بدون جایگزین قابل مشاهده، مانع جدی ایجاد می‌کنند.

:focus-visible {
  outline: 3px solid currentColor;
  outline-offset: 3px;
}

رنگ Focus باید روی پس‌زمینه‌های مختلف قابل تشخیص باشد. Sticky Header، Cookie Banner یا Overlay نباید عنصر Focusشده را بپوشانند.

مرحله پنجم: سایت را فقط با صفحه‌کلید آزمایش کنید

ماوس را کنار بگذارید و از کلیدهای زیر استفاده کنید:

• Tab برای حرکت جلو
• Shift + Tab برای حرکت عقب
• Enter برای لینک و بعضی دکمه‌ها
• Space برای Button و Checkbox
• Arrow Keys برای بعضی منوها و کنترل‌ها
• Escape برای بستن Dialog و Overlay

سؤال‌های تست

• آیا همه کنترل‌ها قابل دسترسی هستند؟
• آیا ترتیب Focus منطقی است؟
• آیا Focus دیده می‌شود؟
• آیا منوی موبایل بدون ماوس باز و بسته می‌شود؟
• آیا کاربر داخل Dialog گیر می‌کند؟
• آیا Dropdown فقط با Hover کار می‌کند؟

میانبرهای صفحه‌کلید Gutenberg

Block Editor میانبرهای متعددی دارد. برای مشاهده فهرست آن‌ها، منوی سه‌نقطه و Keyboard Shortcuts را باز کنید. نمونه‌های رایج شامل Ctrl یا Command به‌همراه K برای Link، B برای Bold و I برای Italic هستند.

میانبرها سرعت نویسنده را افزایش می‌دهند، اما محتوای Front-end نیز باید بدون Shortcut اختصاصی با صفحه‌کلید استاندارد قابل استفاده باشد.

مرحله ششم: Navigation را آزمایش کنید

Navigation Block به‌صورت پایه ساختار nav، برخی ARIA Attributeها، Keyboard Navigation و Responsive View را فراهم می‌کند. با این حال، منوی واقعی سایت باید آزمایش شود.

چک‌لیست Navigation

• Label منو روشن است.
• ترتیب آیتم‌ها منطقی است.
• زیرمنو با صفحه‌کلید باز می‌شود.
• Focus از دست نمی‌رود.
• Overlay با Escape یا دکمه Close بسته می‌شود.
• دکمه همبرگری نام قابل فهم دارد.
• لینک صفحه جاری قابل تشخیص است.
• Touch Targetها اندازه مناسب دارند.

برای ساخت هدر و Navigation، مقاله آموزش ساخت هدر و فوتر با Site Editor را مطالعه کنید.

مرحله هفتم: Landmarkهای Template را تنظیم کنید

Landmarkها مناطق اصلی صفحه را برای فناوری کمکی مشخص می‌کنند. در Block Theme، Group، Template Part و Query Block می‌توانند عنصر HTML معنایی داشته باشند:

• header
• nav
• main
• article
• aside
• footer

در پنل Advanced بعضی بلوک‌ها، HTML Element را انتخاب کنید. هر صفحه باید معمولاً یک ناحیه اصلی main داشته باشد.

Skip to Content

Skip Link به کاربر صفحه‌کلید اجازه می‌دهد منو و هدر تکراری را رد کند و مستقیم به محتوای اصلی برسد. در Block Theme، تعیین یک Group یا Template Part به‌عنوان main می‌تواند زمینه تولید Skip to Content را فراهم کند.

پس از ساخت Template، با Tab از ابتدای صفحه بررسی کنید Skip Link ظاهر و درست عمل کند.

استفاده صحیح از Group، Section و Article

هر Group نباید به‌صورت خودکار section شود. Section معمولاً باید موضوع مشخص و Heading داشته باشد. برای کارت مستقل مقاله یا محصول، article می‌تواند مناسب باشد. Sidebar مکمل را می‌توان aside در نظر گرفت.

استفاده زیاد و بی‌هدف از Landmarkها نیز Navigation را شلوغ می‌کند.

مرحله هشتم: فرم دسترس‌پذیر بسازید

وردپرس هسته فرم کامل تماس یا Lead ارائه نمی‌کند و معمولاً افزونه فرم استفاده می‌شود. افزونه معتبر انتخاب کنید و خروجی آن را آزمایش کنید.

اصول فرم

• هر فیلد Label قابل مشاهده داشته باشد.
• Placeholder جای Label نباشد.
• فیلد اجباری به‌صورت متنی مشخص شود.
• خطا نزدیک فیلد و قابل فهم نمایش داده شود.
• خطا فقط با رنگ مشخص نشود.
• Focus پس از خطا منطقی مدیریت شود.
• پیام موفقیت برای Screen Reader اعلام شود.
• دکمه ارسال نام روشن داشته باشد.
• ترتیب Tab با ترتیب بصری هماهنگ باشد.

Autocomplete و نوع فیلد

فیلد ایمیل، تلفن، نام و آدرس باید Type و Autocomplete مناسب داشته باشند. این کار برای کاربران موبایل، فناوری کمکی و تکمیل خودکار مفید است.

CAPTCHA

CAPTCHA تصویری می‌تواند مانع ایجاد کند. راهکارهای ضداسپم کم‌اصطکاک، Honeypot یا سرویس‌هایی که مسیر دسترس‌پذیر ارائه می‌دهند را بررسی کنید. هر روش باید از نظر حریم خصوصی و عملکرد نیز ارزیابی شود.

مرحله نهم: ویدئو و صوت را قابل استفاده کنید

• ویدئو Caption دقیق داشته باشد.
• برای محتوای صوتی Transcript ارائه شود.
• Autoplay همراه صدا استفاده نشود.
• کنترل Play، Pause و Volume قابل استفاده باشد.
• محتوای بصری مهم در توضیح صوتی یا متن منتقل شود.
• انیمیشن چشمک‌زن یا شدید محدود شود.

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

مرحله دهم: جدول را درست استفاده کنید

Table برای داده جدولی است، نه ساخت Layout. Heading ردیف و ستون باید مشخص باشند. Caption جدول می‌تواند موضوع آن را توضیح دهد.

در موبایل، جدول عریض باید Scroll کنترل‌شده داشته باشد یا اطلاعات به قالب کارت تبدیل شوند. ترتیب منطقی سلول‌ها برای Screen Reader حفظ شود.

List و Quote معنایی

برای مجموعه موارد از List Block استفاده کنید، نه چند Paragraph با علامت دستی. برای نقل‌قول واقعی از Quote استفاده کنید. ساختار معنایی باعث می‌شود فناوری کمکی نوع محتوا را تشخیص دهد.

زبان، متن و خوانایی

• زبان سایت و صفحه درست تنظیم باشد.
• عبارت‌های انگلیسی در متن فارسی با ساختار خوانا نوشته شوند.
• جمله‌ها بیش از حد پیچیده نباشند.
• مخفف در اولین استفاده توضیح داده شود.
• متن روی تصویر جایگزین HTML واقعی نشود.
• Justify کامل برای متن طولانی با احتیاط استفاده شود.
• Line Height و عرض متن خوانا باشند.

Zoom و بزرگ‌نمایی

صفحه باید با بزرگ‌نمایی ۲۰۰ درصد بدون از دست رفتن محتوا یا عملکرد قابل استفاده بماند. منو، Dialog، فرم و Sticky Elements را در Zoom آزمایش کنید.

محدودکردن Zoom در Viewport Meta اقدام مناسبی نیست.

دسترس‌پذیری Global Styles

پالت رنگ، تایپوگرافی، دکمه و Focus باید به‌صورت مرکزی مدیریت شوند. Global Styles کمک می‌کند خطاهای رنگ و فونت در کل سایت یکجا اصلاح شوند.

راهنمای کامل در مقاله آموزش Global Styles و تنظیم رنگ و فونت ارائه شده است.

Pattern و دسترس‌پذیری

Pattern غیرقابل دسترس خطا را در چندین صفحه تکثیر می‌کند. قبل از ذخیره Pattern موارد زیر را بررسی کنید:

• Headingها منطقی‌اند.
• Alt تصاویر نمونه مشخص است.
• لینک آزمایشی وجود ندارد.
• Focus و Keyboard کار می‌کنند.
• رنگ‌ها از Global Styles می‌آیند.
• CTA نام روشن دارد.
• نسخه موبایل قابل استفاده است.

برای Synced Pattern، تغییر دسترس‌پذیری نسخه اصلی می‌تواند همه نمونه‌ها را اصلاح کند؛ اما ویرایش اشتباه نیز اثر گسترده دارد.

Template و دسترس‌پذیری

Single، Page، Archive، Search و 404 را جداگانه آزمایش کنید. Template عمومی روی ده‌ها صفحه اثر می‌گذارد.

موارد مهم Template

• یک Main Landmark
• Skip Link سالم
• Post Title با Heading مناسب
• Navigation قابل استفاده
• ترتیب منطقی Header، Main و Footer
• Search Label روشن
• پیام No Results
• 404 دارای مسیر بازگشت

Query Loop و کارت نوشته‌ها

در Query Loop، عنوان هر کارت باید Heading منطقی و Link واضح باشد. تکرار چند Link یکسان برای تصویر، عنوان و دکمه ممکن است تجربه Screen Reader را شلوغ کند؛ ساختار را روی خروجی واقعی ارزیابی کنید.

• Featured Image Alt درست داشته باشد.
• عنوان Link باشد.
• Read More متن اختصاصی داشته باشد.
• Pagination قابل استفاده با صفحه‌کلید باشد.
• No Results پیام روشن داشته باشد.
• Query Title سطح Heading مناسب داشته باشد.

راهنمای کامل در مقاله آموزش Query Loop در وردپرس موجود است.

دسترس‌پذیری طراحی ریسپانسیو

مخفی‌کردن بلوک در موبایل نباید اطلاعات ضروری را حذف کند. تغییر Order بصری با CSS ممکن است با ترتیب Focus یا Screen Reader متفاوت شود. ترتیب HTML را براساس مسیر منطقی محتوا طراحی کنید.

مقاله آموزش طراحی ریسپانسیو در Gutenberg این موضوع را کامل‌تر توضیح می‌دهد.

Animation و Motion

انیمیشن زیاد، Parallax و حرکت خودکار می‌توانند برای بعضی کاربران مشکل ایجاد کنند. ترجیح سیستم کاربر برای Reduced Motion را رعایت کنید:

@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    scroll-behavior: auto !important;
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
  }
}

این نمونه باید با پروژه واقعی تطبیق داده شود و نباید رفتار ضروری رابط را از کار بیندازد.

اعلان، Modal و Popup

• Focus هنگام بازشدن به Dialog منتقل شود.
• Focus داخل Modal کنترل شود.
• Escape آن را ببندد.
• دکمه Close نام قابل فهم داشته باشد.
• پس از بستن، Focus به Trigger برگردد.
• محتوای پشت Dialog برای تعامل غیرفعال شود.
• Popup خودکار مزاحم نباشد.

افزونه Popup باید با صفحه‌کلید و Screen Reader آزمایش شود؛ ظاهر زیبا کافی نیست.

آزمون با Screen Reader

آزمون تخصصی Screen Reader نیاز به تجربه دارد، اما یک بررسی مقدماتی مفید است. ابزارهای رایج شامل NVDA در ویندوز و VoiceOver در macOS و iOS هستند.

چه چیزهایی را بررسی کنیم؟

• عنوان صفحه اعلام می‌شود.
• Headingها فهرست منطقی دارند.
• Landmarkها قابل شناسایی‌اند.
• Alt تصاویر معنی‌دار است.
• Linkها بدون متن اطراف قابل فهم‌اند.
• فرم Label و خطای روشن دارد.
• Navigation و Dialog قابل استفاده‌اند.

استفاده از Screen Reader بدون شناخت کامل می‌تواند نتیجه ناقص بدهد، اما مشکلات واضح را آشکار می‌کند.

آزمون خودکار و محدودیت آن

ابزارهای خودکار می‌توانند خطاهایی مانند Alt خالی، Contrast، Label و Heading را شناسایی کنند؛ اما همه مشکلات را نمی‌بینند. ابزار نمی‌تواند همیشه تشخیص دهد Alt تصویر واقعاً مناسب است، ترتیب Focus منطقی است یا متن لینک مفهوم دارد.

بهترین روش ترکیب موارد زیر است:

• آزمون خودکار
• آزمون صفحه‌کلید
• آزمون Screen Reader
• Zoom و Mobile
• بازبینی انسانی محتوا
• در پروژه مهم، تست با کاربران دارای معلولیت

Accessibility Ready Theme یعنی چه؟

برچسب Accessibility Ready در مخزن رسمی نشان می‌دهد قالب برای مجموعه‌ای از الزامات بررسی شده است. این برچسب تضمین نمی‌کند سایت نهایی دسترس‌پذیر است؛ محتوای کاربر، افزونه‌ها و تنظیمات می‌توانند مشکل ایجاد کنند.

دسترس‌پذیری در WoodMart

قالب فعال dev-source.ir یعنی WoodMart 8.3.7 یک قالب کلاسیک تجاری با Builderهای اختصاصی است. بررسی باید هم Gutenberg و هم خروجی WoodMart را پوشش دهد:

• Header Builder و منوی موبایل
• Search، Mini Cart و Account Popup
• Product Gallery و Variationها
• Filterهای فروشگاه
• Modal و Quick View
• فرم Checkout و حساب کاربری
• HTML Blocks و Mega Menu

وجود بلوک‌های هسته در محتوا به معنی دسترس‌پذیری خودکار اجزای اختصاصی WoodMart نیست.

دسترس‌پذیری ووکامرس

در فروشگاه، مسیر کامل خرید را فقط با صفحه‌کلید بررسی کنید:

• انتخاب Variation
• افزودن به سبد
• بازکردن Mini Cart
• ویرایش تعداد
• فرم Checkout
• خطاهای پرداخت
• قبول قوانین
• پیام موفقیت سفارش

رنگ تنها نباید وضعیت موجودی، تخفیف یا خطا را منتقل کند.

سئو و دسترس‌پذیری

سئو و دسترس‌پذیری یکسان نیستند، اما در چند حوزه هم‌پوشانی دارند:

• Heading منطقی
• Alt تصویر
• Link Text واضح
• ساختار HTML معنایی
• Navigation قابل استفاده
• Mobile و سرعت
• محتوای قابل فهم

نباید Accessibility را فقط برای رتبه گوگل اجرا کرد. هدف اصلی، دسترسی واقعی انسان‌هاست.

اشتباهات رایج

• فرض اینکه وردپرس خودکار همه چیز را حل می‌کند
• حذف Focus Outline
• استفاده از H1 برای بزرگ‌کردن متن
• نوشتن Alt برای موتور جست‌وجو
• قرار دادن متن داخل تصویر
• استفاده از Placeholder به‌جای Label
• لینک‌های «اینجا» و «بیشتر»
• استفاده از رنگ به‌عنوان تنها نشانه
• ساخت منوی فقط Hover
• اعتماد کامل به ابزار خودکار
• تست نکردن صفحه‌کلید و Zoom
• نادیده گرفتن Popup و افزونه‌های تجاری

چک‌لیست نهایی دسترس‌پذیری

• یک H1 اصلی وجود دارد.
• Headingها ترتیب منطقی دارند.
• تصاویر محتوایی Alt مناسب دارند.
• تصاویر تزئینی Alt خالی دارند.
• Link Textها قابل فهم‌اند.
• دکمه و لینک معنای درست دارند.
• کنتراست متن و کنترل‌ها کافی است.
• Focus قابل مشاهده است.
• کل صفحه با صفحه‌کلید کار می‌کند.
• Navigation و Overlay قابل بستن‌اند.
• Main Landmark و Skip Link وجود دارند.
• فرم Label، خطا و پیام موفقیت مناسب دارد.
• ویدئو Caption و صوت Transcript دارد.
• Zoom ۲۰۰ درصد تست شده است.
• موبایل و Orientation بررسی شده‌اند.
• Pattern و Templateهای عمومی آزمایش شده‌اند.
• آزمون خودکار و انسانی هر دو انجام شده‌اند.

📌 همچنین بخوانید: ساخت لندینگ پیج با Gutenberg در وردپرس، ساخت صفحه اصلی با Gutenberg و Site Editor در وردپرس و تفاوت قالب بلوکی و قالب کلاسیک وردپرس

پرسش‌های متداول

آیا Gutenberg دسترس‌پذیر است؟

هسته وردپرس و Gutenberg به‌طور مستمر برای دسترس‌پذیری توسعه می‌یابند، اما خروجی سایت به قالب، افزونه و محتوای شما نیز وابسته است.

Alt تصویر را چه بنویسیم؟

اطلاعات یا کارکرد تصویر در همان صفحه را کوتاه و دقیق توضیح دهید. برای تصویر تزئینی Alt خالی مناسب است.

چند H1 در صفحه مجاز است؟

HTML می‌تواند ساختارهای مختلف داشته باشد، اما برای سادگی، فهم و نگهداری معمولاً یک H1 اصلی توصیه می‌شود.

آیا Placeholder جای Label است؟

خیر. Placeholder با تایپ ناپدید می‌شود و همیشه نام قابل اتکایی برای فیلد ایجاد نمی‌کند.

چگونه Navigation را تست کنیم؟

فقط با Tab، Shift+Tab، Enter، Space، Arrow و Escape منو و زیرمنو را باز، پیمایش و بسته کنید.

آیا ابزار خودکار کافی است؟

خیر. ابزار خودکار فقط بخشی از خطاها را پیدا می‌کند. تست صفحه‌کلید، Screen Reader و بازبینی انسانی ضروری‌اند.

در WoodMart چه بخش‌هایی مهم‌ترند؟

Header، Mega Menu، Mini Cart، Quick View، Product Variation، Filter و Checkout باید جداگانه آزمایش شوند.

جمع‌بندی

دسترس‌پذیری در Gutenberg و Site Editor با ساختار معنایی و محتوای درست آغاز می‌شود. Heading، Alt، Link، Button، Label، Landmark و Focus باید هدف واقعی خود را حفظ کنند. سپس رنگ، Navigation، Media، Template، Pattern و رفتار موبایل بررسی می‌شوند.

WordPress 7.0 اصلاحات مهمی در Media Library، Voice Control، Alt Metadata، Contrast و تعامل ویرایشگر ارائه کرده است، اما مسئولیت نهایی خروجی سایت همچنان بر عهده تیم طراحی و محتواست. هدف حرفه‌ای، نزدیک‌شدن به WCAG 2.2 سطح AA همراه آزمون انسانی است.

در dev-source.ir با WoodMart 8.3.7 باید علاوه بر بلوک‌های Gutenberg، اجزای اختصاصی قالب و WooCommerce نیز آزمایش شوند. تغییرات گسترده را ابتدا روی Staging اجرا و مسیرهای اصلی سایت را فقط با صفحه‌کلید و سپس با ابزارهای کمکی بررسی کنید.

منابع رسمی

• Accessibility Coding Standards وردپرس
• بهبودهای دسترس‌پذیری WordPress 7.0
• دسترس‌پذیری Block Theme
• میانبرهای صفحه‌کلید Block Editor
• استاندارد WCAG 2.2
• تیم Make WordPress Accessible