وقتی فرم پرداخت طراحی می‌شود، باید مشخص باشد کاربر بدون ماوس چگونه فیلدها را پیدا می‌کند، خطا را می‌فهمد و دوباره ارسال می‌کند. اگر این تصمیم‌ها به روز آخر موکول شوند، اصلاح فقط تغییر چند رنگ نیست؛ ساختار component و مدیریت Focus هم ممکن است نیاز به بازنویسی داشته باشد. دسترسی‌پذیری از روز اول یعنی همین رفتارها در تعریف کار و طراحی اولیه حضور داشته باشند.
a11y را با یک فهرست کوتاه از رنگ و alt تمام‌شده فرض نکنید. کاربر باید محتوای صفحه را درک کند و وظیفه‌اش را انجام دهد. شرایط متفاوت‌اند: استفاده از Keyboard، Screen Reader، بزرگ‌نمایی متن یا استفاده بدون صدا، نیازهای مختلفی ایجاد می‌کنند. یک کنترل ممکن است در screenshot واضح باشد اما نام برنامه‌ای نداشته باشد یا هنگام باز شدن Dialog کاربر را در جای نامعلوم رها کند.
وظیفه قابل انجام را در تعریف پذیرش بنویسید
برای فرم ثبت‌نام، تعریف پذیرش می‌تواند شامل یافتن هر فیلد با نام روشن، دریافت توضیح خطا و ارسال دوباره بدون از دست رفتن داده معتبر باشد. چنین تعریفی قابل بررسی است. عبارت «فرم دسترس‌پذیر باشد» به تنهایی جزئیات کافی ندارد. معیار استاندارد مرتبط را در کنار وظیفه ثبت کنید تا تیم بداند کدام رفتار باید در طراحی و پیاده‌سازی حفظ شود.
نسخه و سطح هدف WCAG را در قرارداد پروژه روشن کنید. انطباق کامل با مجموعه معیارهای مربوط با قبولی در چند بررسی منتخب یکسان نیست. اگر فقط صفحه‌ای یا جریان محدودی ارزیابی شده، همان محدوده را گزارش کنید. امتیاز یک ابزار نباید به ادعای دسترس‌پذیری کل محصول تبدیل شود؛ صفحه‌های دیگر، حالت خطا و ترکیب‌های تعاملی ممکن است هنوز بررسی نشده باشند.
الزام قانونی به کشور، نوع سازمان و قرارداد بستگی دارد. جمله عمومی «برای همه سایت‌ها همین قانون اجباری است» دقیق نیست. تیم باید تعهد مربوط به پروژه را از منبع حقوقی مناسب همان حوزه مشخص کند. حتی وقتی درباره الزام قراردادی بحثی نیست، نیاز کاربران و هزینه اصلاح دیرهنگام دلیل عملی برای تعریف زودهنگام رفتار هستند.
از ساختار معنایی محتوا شروع کنید
عنوان‌ها باید ساختار موضوع را نشان دهند، نه فقط اندازه فونت را. برای بزرگ‌تر کردن یک جمله، مرتبه heading را بی‌دلیل تغییر ندهید. کاربر Screen Reader ممکن است از فهرست عنوان‌ها برای رسیدن به بخش لازم استفاده کند. عنوان‌هایی مانند «بیشتر» یا چند عنوان یکسان، این مسیر را مبهم می‌کنند؛ عنوان باید بخش مربوط را از دیگر بخش‌ها جدا کند.
ناحیه اصلی، navigation و بخش‌های مرتبط را با عناصر HTML مناسب تعریف کنید. ترتیب DOM را با ترتیب منطقی کار هماهنگ نگه دارید. تغییر ظاهری ترتیب با CSS اگر مسیر Keyboard متفاوت بسازد، ممکن است رابط را گیج‌کننده کند. در RTL هم زبان صفحه و جهت نوشتار را درست تعیین کنید؛ این تصمیم جای ترجمه نام کنترل یا توضیح رفتار را نمی‌گیرد.
برای navigation تکرارشونده، مسیر رسیدن مستقیم به محتوای اصلی مفید است. لینک پرش باید هنگام Focus قابل مشاهده شود و مقصد واقعی داشته باشد. در صفحه طولانی، کاربر نباید هر بار از تمام لینک‌های header عبور کند. اگر برنامه هنگام تغییر route محتوا را عوض می‌کند، عنوان صفحه و محل شروع کار جدید هم باید با آن تغییر هماهنگ باشند.
کنترل بومی را به رفتار اختصاصی ترجیح دهید
برای عمل، button و برای رفتن به مقصد، link مناسب است. یک div کلیک‌پذیر رفتار Keyboard، نام و حالت button را خودکار به دست نمی‌آورد. اضافه کردن role هم همه رفتارهای لازم را پیاده نمی‌کند. اگر کنترل بومی پاسخ نیاز را می‌دهد، از همان استفاده کنید. هزینه کنترل اختصاصی فقط نوشتن ظاهر نیست؛ قرارداد Focus و کلیدها نیز باید نگهداری شود.
نام قابل دسترس باید با متن دیداری کنترل هماهنگ باشد. اگر دکمه فقط آیکون دارد، کاربر باید بفهمد چه کاری می‌کند. برای چند دکمه حذف در یک فهرست، نام‌ها باید زمینه رکورد را روشن کنند. توضیح طولانی را داخل نام همه کنترل‌ها تکرار نکنید؛ Screen Reader باید اطلاعات لازم را بدون شنیدن چندباره متن نامرتبط دریافت کند.
حالت disabled، expanded و selected هر کدام معنای متفاوتی دارند. رنگ خاکستری به تنهایی disabled را برنامه‌ای نمی‌کند و انتخاب یک گزینه با باز بودن یک پنل فرق دارد. حالت واقعی را در attribute یا عنصر مناسب ثبت کنید. مستند component باید بگوید چه کسی مقدار حالت را تغییر می‌دهد و نتیجه آن در محتوا و Focus چیست.
Focus را به عنوان مسیر کار طراحی کنید
نشانه Focus را حذف نکنید، مگر جایگزین قابل تشخیص دارید. کاربر باید بداند کدام کنترل فعال است و حرکت بعدی او به کجا می‌رود. ترتیب Tab را با کار صفحه هماهنگ کنید و از tabindex مثبت برای ساختن مسیر پیچیده دور بمانید. افزودن یک کنترل تازه در چنین مسیری می‌تواند ترتیب کل صفحه را تغییر دهد و نگهداری را دشوار کند.
Focus Not Obscured در WCAG 2.2 در سطح AA می‌خواهد کنترل دارای Focus به‌طور کامل زیر محتوای ساخته‌شده توسط سایت پنهان نشود. header یا banner ثابت می‌تواند این مسئله را ایجاد کند. قابل مشاهده بودن حداقلی با بهترین نمایش یکسان نیست؛ برای استفاده راحت‌تر، از پوشاندن بخش‌های کنترل و نشانه آن تا حد ممکن جلوگیری کنید.
در Dialog، محل Focus اولیه، محدوده حرکت و بازگشت پس از بسته شدن را مشخص کنید. اگر کنترل آغازکننده حذف شده، مقصد بازگشت باید منطقی باشد. انتقال Focus برای هر پیام کوچک لازم نیست و می‌تواند کار را قطع کند. در طراحی، فرق تغییر زمینه با یک پیام وضعیت را روشن کنید تا توسعه‌دهنده مجبور نباشد این تصمیم را در انتهای کار حدس بزند.
فرم باید توضیح و راه اصلاح داشته باشد
Forms Tutorial از WAI به label، گروه‌بندی، دستور و بازخورد فرم می‌پردازد. Placeholder جای label پایدار نیست؛ با ورود داده ناپدید می‌شود و ممکن است Contrast کافی نداشته باشد. نام فیلد و راهنمای قالب ورودی را در محل مناسب نگه دارید. موارد ضروری را قبل از ارسال قابل تشخیص کنید، نه فقط پس از شکست.
در خطا، فیلد و روش اصلاح را معرفی کنید. «ورودی نامعتبر است» برای شماره تماس، تاریخ و رمز عبور اطلاعات یکسان و ناکافی می‌دهد. پیام باید با قانون واقعی اعتبارسنجی هماهنگ باشد. داده معتبر را پاک نکنید؛ کاربر نباید برای اصلاح یک مورد تمام فرم را دوباره پر کند. اگر خطا سمت سرور رخ داده، آن را به اشتباه ورودی کاربر نسبت ندهید.
خلاصه خطا برای فرم طولانی می‌تواند مسیر رسیدن به فیلدهای مشکل‌دار را فراهم کند. ارتباط پیام با input باید برنامه‌ای هم ثبت شود. رنگ قرمز تنها نشانه نباشد؛ متن و ساختار لازم‌اند. پس از اصلاح، وضعیت خطا به‌روز شود، ولی اعلان هر ضربه کلید ممکن است بیش از حد مزاحم باشد. زمان بازخورد را بر اساس نوع ورودی و کار مشخص کنید.
Contrast و اندازه را با حالت واقعی بررسی کنید
Contrast Minimum برای متن معمولی در سطح AA حداقل 4.5:1 و برای متن بزرگ 3:1 تعیین می‌کند. استثناها و تعریف متن بزرگ در همان معیار آمده‌اند. رنگ روی سطح واقعی، از جمله ترکیب شفافیت، مهم است. بررسی یک نمونه در حالت روشن، رفتار Dark Mode یا حالت hover را تأیید نمی‌کند.
Target Size Minimum در WCAG 2.2 سطح AA اندازه 24 در 24 CSS pixel یا شرایط فاصله‌گذاری و استثناهای مشخص را بیان می‌کند. آن را با الزام یک اندازه ثابت برای هر لینک داخل متن اشتباه نگیرید. در طراحی کنترل‌های فشرده، فاصله و امکان انتخاب را همراه اندازه ببینید؛ بزرگ بودن آیکون هم الزاماً ناحیه کلیک را بزرگ نمی‌کند.
کاربر باید بتواند متن را بزرگ کند و محتوا همچنان قابل استفاده بماند. ارتفاع ثابت روی بخش‌های متن‌دار می‌تواند متن ترجمه‌شده یا بزرگ‌شده را قطع کند. برای کارت، دکمه و پیام خطا از محتوای طولانی واقعی استفاده کنید. تغییر زبان و اندازه متن را به نسخه موبایل محدود نکنید؛ هر عرضی ممکن است تحت بزرگ‌نمایی فضای قابل استفاده کم‌تری داشته باشد.
دارایی و رسانه را با نقششان توصیف کنید
alt باید اطلاعات لازم همان تصویر در همان زمینه را منتقل کند. نام فایل یا عبارت کلی «تصویر زیبا» معمولاً کمکی نمی‌کند. تصویر تزئینی با تصویر حامل اطلاعات قرارداد متفاوتی دارد. اگر نمودار محتوای مهم دارد، یک alt کوتاه ممکن است برای تمام داده کافی نباشد؛ توضیح متنی یا جدول مرتبط هم لازم می‌شود. تصمیم از هدف تصویر می‌آید.
برای محتوای صوتی و ویدیویی، caption و جایگزین مرتبط را از برنامه تولید محتوا جدا نکنید. افزودن آن‌ها در انتهای انتشار ممکن است اطلاعات و زمان لازم را در دسترس نداشته باشد. کنترل پخش با Keyboard و نام قابل فهم هم اهمیت دارد. ویدیویی با caption درست ولی کنترل غیرقابل استفاده، تمام نیاز کاربر را پاسخ نمی‌دهد.
حرکت و به‌روزرسانی خودکار باید با اختیار کاربر هماهنگ باشند. اگر یک animation صرفاً تزئینی است، در حالت کاهش حرکت می‌توان آن را محدود کرد. اعلان‌های پی‌درپی نیز نباید مسیر شنیدن محتوا را اشغال کنند. نقش status یا alert را برای معنای مناسب انتخاب کنید؛ افزودن alert به تمام پیام‌ها، دسترسی‌پذیری را بهتر نمی‌کند.
ابزار خودکار را کنار ارزیابی انسانی قرار دهید
راهنمای انتخاب ابزار ارزیابی WAI تأکید می‌کند ابزار به تنهایی نمی‌تواند تمام جنبه‌های دسترسی‌پذیری را تعیین کند. ابزارهایی مانند axe، WAVE یا Lighthouse می‌توانند بعضی خطاها را پیدا کنند؛ مناسب بودن نام، ترتیب کار و کیفیت توضیح همچنان نیاز به قضاوت دارد. گزارش بدون خطا به معنی نبود مشکل در تمام جریان نیست.
برای تیم، کارهای اصلی را با Keyboard و فناوری کمکی مناسب بررسی کنید و در صورت امکان کاربران دارای نیاز مرتبط را در پژوهش مشارکت دهید. نتیجه را با محیط و محدوده ثبت کنید. مقاله Dark Mode برای رنگ‌ها و داشبورد مدیریتی برای جدول و پیام وضعیت ادامه‌های مرتبط‌اند. مستند هر component باید رفتار دسترسی‌پذیری را همراه ظاهرش حفظ کند تا نسخه بعدی دوباره همان تصمیم‌ها را از دست ندهد.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!