بعضی وبسایتها در نگاه اول زیبا، سریع و مدرناند؛ اما کافی است نتوانید ماوس را حرکت دهید، دیدتان کمی تار باشد، رنگها را مثل طراح صفحه تشخیص ندهید یا بخواهید متن را با صفحهخوان بشنوید. همان سایت مرتب ناگهان به مجموعهای از دکمههای نامعلوم، فرمهای بیبرچسب و مسیرهای بنبست تبدیل میشود. دسترسپذیری وب برای جلوگیری از همین فاصله است: فاصله میان سایتی که «نمایش داده میشود» و سایتی که واقعاً میتوان از آن استفاده کرد.
دسترسپذیری فقط موضوع افراد نابینا نیست و قرار نیست ظاهر سایت را ساده یا بیهویت کند. کاربری که موقتاً دستش آسیب دیده، کسی که در نور شدید با موبایل کار میکند، فردی که شنوایی محدودی دارد، سالمندی که متن ریز را سخت میخواند، کاربری که اینترنت کند دارد یا حتی مدیری که میخواهد بدون ماوس یک فرم را سریع تکمیل کند، همگی از تصمیمهای دسترسپذیر سود میبرند. بسیاری از این تصمیمها همان چیزهایی هستند که یک تجربه کاربری خوب را میسازند: وضوح، پیشبینیپذیری، خوانایی و کنترل.
این راهنما قرار نیست معیارهای WCAG را بندبهبند ترجمه کند. هدف این است که استاندارد را به زبان پروژه تبدیل کنیم: طراح رابط چه چیزی را باید در فایل طراحی ببیند؟ نویسنده برای تصویر و لینک چه بنویسد؟ توسعهدهنده چگونه منو، فرم، مودال و فوکوس را پیاده کند؟ مدیر سایت چطور بفهمد یک امتیاز سبز واقعاً به معنای تجربه قابل استفاده هست یا نه؟ و در یک سایت فارسی و راستبهچپ، کدام خطاها بیشتر پنهان میمانند؟
پاسخ کوتاه: دسترسپذیری وب یعنی محتوا و قابلیتهای سایت برای طیف وسیعتری از کاربران، با تواناییها، ابزارها و شرایط متفاوت، قابل ادراک، قابل استفاده، قابل فهم و از نظر فنی قابل تفسیر باشد. WCAG چارچوب سنجش این کیفیت است؛ اما نتیجه واقعی فقط با ترکیب طراحی، کدنویسی درست، محتوای روشن و آزمون انسانی به دست میآید.
دسترسپذیری وب دقیقاً یعنی چه؟
وقتی میگوییم یک سایت دسترسپذیر است، منظورمان این نیست که همه کاربران دقیقاً یک تجربه یکسان دارند. کاربر صفحهخوان ممکن است منو را بهصورت صوتی مرور کند، کاربر کمبینا صفحه را بزرگ کند، کاربر دارای محدودیت حرکتی با کلید Tab میان کنترلها حرکت کند و کاربر ناشنوا محتوای ویدئو را از روی زیرنویس بفهمد. شکل تجربهها فرق دارد، اما اطلاعات اصلی، مسیر تصمیم و امکان انجام کار نباید از کسی گرفته شود.
برای یک سایت شرکتی، «انجام کار» میتواند فهمیدن خدمت، دیدن نمونهکار، رفتن به صفحه تماس و ارسال فرم باشد. در فروشگاه، پیدا کردن محصول، انتخاب ویژگی، افزودن به سبد و پرداخت است. در سایت پزشکی، خواندن توضیحات، شناخت پزشک و درخواست نوبت است. دسترسپذیری زمانی معنا دارد که روی همین وظایف واقعی تمرکز کنیم؛ نه فقط روی عبور از یک تست خودکار.
یک مثال ساده را در نظر بگیرید. طراح برای زیبایی، برچسب فیلد «شماره تماس» را داخل placeholder قرار داده است. کاربر شروع به تایپ میکند و برچسب ناپدید میشود. اگر وسط کار حواسش پرت شود، دیگر معلوم نیست آن فیلد دقیقاً چه میخواست. صفحهخوان هم ممکن است اطلاعات کافی دریافت نکند. با برگرداندن یک label واقعی، ظاهر الزاماً خراب نمیشود؛ فقط رابطه میان کنترل و معنای آن روشن میشود. این همان جنس اصلاحی است که هم به افراد دارای معلولیت کمک میکند و هم خطای همه کاربران را پایین میآورد.
دسترسپذیری ویژگی انتهای پروژه نیست
اگر دسترسپذیری را به آخر پروژه موکول کنیم، معمولاً به فهرستی از وصلهها میرسیم: کمی تغییر رنگ، چند aria-label و اضافهکردن alt به تصاویر. اما بسیاری از مشکلات از تصمیمهای اولیه میآیند؛ مثلاً انتخاب کامپوننتی که با کیبورد کار نمیکند، ساخت معماری مبهم، استفاده از رنگ بهعنوان تنها نشانه خطا، یا طراحی فرمی که بدون زمان کافی منقضی میشود. اصلاح این موارد بعد از توسعه، گرانتر و ناقصتر است.
در یک فرایند حرفهای طراحی وبسایت، معیارهای دسترسپذیری باید از بریف و وایرفریم وارد پروژه شوند، در طراحی بصری قابل مشاهده باشند، هنگام توسعه تست شوند و بعد از انتشار نیز با تغییر محتوا و کامپوننتها دوباره کنترل شوند. دسترسپذیری یک وضعیت ثابت نیست؛ کیفیتی است که باید نگهداری شود.
WCAG چیست و چرا نسخه ۲.۲ مهم است؟
WCAG مخفف Web Content Accessibility Guidelines و مجموعهای از راهنماهای کنسرسیوم جهانی وب یا W3C است. این چارچوب تلاش میکند نیازهای متنوع کاربران را به معیارهایی قابل بررسی تبدیل کند. در مرور رسمی WCAG 2، معیارها زیر چهار اصل قابل ادراک بودن، قابل استفاده بودن، قابل فهم بودن و مقاوم بودن سازماندهی شدهاند. نسخه ۲.۲ نیز سه سطح انطباق A، AA و AAA دارد.
سطح A پایهایترین موانع را هدف میگیرد. سطح AA دامنهای است که اغلب تیمها برای یک محصول عمومی و حرفهای بهعنوان هدف عملی در نظر میگیرند. سطح AAA معیارهای سختگیرانهتری دارد، اما رسیدن کامل همه صفحات و همه محتواها به AAA همیشه ممکن یا ضروری نیست. نکته مهم این است که سطحها را به برچسب بازاریابی تبدیل نکنیم. جمله «سایت ما WCAG AA است» باید دامنه، نسخه استاندارد، روش آزمون و محدودیتهای نتیجه را روشن کند.
WCAG 2.2 نسبت به 2.1 معیارهای تازهای اضافه کرده است؛ از جمله مواردی درباره ظاهر فوکوس، پنهان نشدن عنصر دارای فوکوس، روشهای ورود قابل دسترس و حداقل اندازه هدفهای لمسی. W3C در صفحه تغییرات WCAG 2.2 توضیح میدهد که این نسخه ۹ معیار موفقیت جدید نسبت به 2.1 دارد و معیار قدیمی Parsing نیز حذف شده است.
استاندارد، چکلیست و تجربه واقعی سه چیز متفاوتاند
استاندارد میگوید چه نتیجهای باید حاصل شود. چکلیست کمک میکند موارد رایج از قلم نیفتد. تجربه واقعی نشان میدهد پیادهسازی در عمل برای کاربر قابل استفاده هست یا نه. ممکن است یک دکمه از نظر اندازه حداقل معیار را رد کند، اما متنش مبهم باشد. ممکن است همه تصاویر alt داشته باشند، ولی altها فقط نام فایل یا تکرار کپشن باشند. ممکن است ترتیب Tab از نظر فنی وجود داشته باشد، اما پس از بستن مودال فوکوس گم شود. پس ممیزی خوب باید هر سه لایه را ببیند.
همچنین WCAG را نباید با نسخه مرورگر، فریمورک یا CMS یکی دانست. وردپرس، Next.js یا هر سیستم دیگری میتواند خروجی خوب یا بد تولید کند. انتخاب فناوری فقط بخشی از ماجراست؛ کیفیت معماری کامپوننتها، HTML نهایی، محتوا، تست و نگهداری تعیین میکند تجربه چقدر دسترسپذیر بماند.
چهار اصل POUR؛ ستونهای دسترسپذیری با مثال واقعی
چهار اصل دسترسپذیری وب: قابل ادراک، قابل استفاده، قابل فهم و مقاوم
نام POUR از حرف اول چهار اصل Perceivable، Operable، Understandable و Robust میآید. این چهار اصل کمک میکنند به جای حفظکردن دهها معیار، ابتدا جنس مشکل را بفهمیم. هر مانع جدی دسترسپذیری معمولاً دستکم یکی از این پایهها را تضعیف میکند.
۱. قابل ادراک: آیا کاربر میتواند اطلاعات را دریافت کند؟
اطلاعاتی که فقط با یک کانال منتقل شود، برای بخشی از کاربران ناپدید میشود. اگر نمودار فقط با تفاوت قرمز و سبز معنی پیدا کند، فرد دارای کوررنگی ممکن است نتیجه را نفهمد. اگر ویدئو گفتوگو دارد اما زیرنویس ندارد، بخشی از پیام برای کاربر ناشنوا از دست میرود. اگر تصویر محصول اطلاعات مهمی دارد اما متن جایگزین مناسب ندارد، صفحهخوان نمیتواند همان ارزش را منتقل کند.
قابل ادراک بودن یعنی برای اطلاعات مهم جایگزین مناسب داشته باشیم، متن و کنترلها کنتراست کافی بگیرند، بزرگنمایی موجب قطع محتوا نشود و ساختار دیداری در کد نیز قابل تشخیص باشد. هدف حذف تصویر، رنگ یا ویدئو نیست؛ هدف این است که معنا به یک حس یا یک روش نمایش وابسته نماند.
۲. قابل استفاده: آیا کاربر میتواند کنترل و حرکت کند؟
اگر منو فقط با hover ماوس باز شود، اگر پنجره پاپآپ فوکوس را حبس کند، اگر اسلایدر خودکار راه توقف نداشته باشد یا اگر دکمه بستن آنقدر کوچک باشد که با لمس اشتباه شود، سایت برای بخشی از کاربران قابل استفاده نیست. تعاملهای اصلی باید با کیبورد انجام شوند، ترتیب فوکوس منطقی باشد، وضعیت فوکوس دیده شود و کاربر برای خواندن یا انجام کار زمان معقول داشته باشد.
قابل استفاده بودن با «همه چیز Tab میخورد» تمام نمیشود. باید بتوان وظیفه را کامل کرد: ورود به منو، انتخاب گزینه، بازکردن و بستن مودال، تکمیل فرم، دیدن خطا و برگشتن به مسیر قبلی. تست باید سناریو داشته باشد.
۳. قابل فهم: آیا کاربر میداند چه اتفاقی میافتد؟
متن ساده، عنوان دقیق، برچسب روشن، رفتار قابل پیشبینی و پیام خطای قابل اصلاح، بخشهای این اصلاند. دکمهای با عنوان «ادامه» بدون زمینه کافی، لینکی با متن «اینجا کلیک کنید» و خطای «ورودی نامعتبر است» بار فهم را روی کاربر میاندازند. بهتر است بگوییم «مشاهده تعرفه خدمات»، «رفتن به نمونهکارهای طراحی سایت» یا «شماره موبایل باید ۱۱ رقم باشد».
قابل فهم بودن به لحن هم مربوط است. متن بیش از حد فنی یا جملههای طولانی میتوانند کاربر را خسته کنند. هدف سادهسازی افراطی نیست؛ باید پیچیدگی واقعی را مرحلهبندی کنیم. خلاصه در ابتدا، جزئیات در ادامه و توضیح اصطلاح در همان جایی که لازم است، ساختار سالمتری میسازد.
۴. مقاوم: آیا محتوا برای ابزارهای مختلف قابل تفسیر است؟
یک رابط مقاوم با HTML معنایی، نام و نقش روشن برای کنترلها، وضعیتهای قابل اعلام و رفتار قابل پیشبینی ساخته میشود. اگر یک div با کلیک بهظاهر دکمه شود اما نقش، فوکوس و رفتار کیبورد نداشته باشد، فقط برای گروهی از کاربران دکمه است. استفاده از عنصر واقعی button معمولاً مسیر مطمئنتری است.
مقاوم بودن یعنی سایت فقط در مرورگر و دستگاه طراح کار نکند. صفحهخوانها، بزرگنمایی، تنظیمات شخصی کاربر، مرورگرهای متفاوت و فناوریهای کمکی باید بتوانند ساختار را بفهمند. این اصل جایی است که طراحی، توسعه و تست ناگزیر به هم میرسند.
چرا دسترسپذیری سایت فارسی فقط ترجمه یک چکلیست انگلیسی نیست؟
اصول دسترسپذیری جهانیاند، اما پیادهسازی در زبان فارسی جزئیات خودش را دارد. راستبهچپ بودن صفحه، ترکیب واژههای فارسی و انگلیسی، اعداد، فونتهای وب، نیمفاصله، نشانهگذاری و رفتار کامپوننتها میتواند خطاهایی بسازد که در یک نمونه انگلیسی دیده نمیشوند. اگر تیم فقط یک قالب LTR را آینه کند، ترتیب دیداری شاید درست به نظر برسد اما ترتیب DOM، فوکوس یا خواندن صفحهخوان همچنان نامنظم بماند.
جهت صفحه و اجزای درون آن
قرار دادن dir="rtl" روی سند یا محدوده فارسی نقطه شروع است، نه پایان. شماره تلفن، ایمیل، کد، URL و بعضی دادههای عددی ممکن است به جهت مستقل نیاز داشته باشند. وقتی رشتهای مثل شماره سفارش، نام محصول انگلیسی و متن فارسی در یک خط قرار میگیرد، بدون مدیریت bidi ترتیب بصری میتواند گیجکننده شود. توسعهدهنده باید نمونههای واقعی محتوا را تست کند، نه فقط lorem ipsum فارسی.
ترتیب دیداری نباید ترتیب منطقی را خراب کند
CSS میتواند کارتها را بهسادگی جابهجا کند، اما صفحهخوان و کیبورد معمولاً ترتیب DOM را دنبال میکنند. اگر در نسخه RTL با order یا row-reverse اجزا را طوری بچینیم که ظاهر یک چیز و ترتیب فوکوس چیز دیگری باشد، کاربر هنگام Tab زدن میان دو منطق رفتوبرگشت میکند. راه بهتر این است که ساختار کد از ابتدا با ترتیب خواندن و انجام کار هماهنگ باشد و CSS فقط ارائه را تنظیم کند.
فونت فارسی و خوانایی
دو فونت با اندازه عددی یکسان الزاماً خوانایی یکسان ندارند. ارتفاع حروف، شکل نقطهها، فاصله داخلی و وزن واقعی در فونتهای فارسی متفاوت است. متنی که در ۱۴ پیکسل با یک فونت خواناست، ممکن است با فونت دیگر فشرده و خاکستری دیده شود. مقاله تأثیر تایپوگرافی و فونت بر سئو و تجربه کاربری این رابطه را گستردهتر بررسی میکند؛ در دسترسپذیری باید انتخاب فونت را همراه با اندازه، وزن، طول خط و فاصله خطوط آزمایش کرد.
صفحهخوان و تلفظ محتوای ترکیبی
زبان اصلی صفحه باید مشخص باشد و تغییر زبان در عبارتها یا بخشهای مهم، در صورت نیاز، با نشانهگذاری مناسب اعلام شود. صفحهخوان ممکن است واژه انگلیسی را با موتور فارسی نامفهوم تلفظ کند. لازم نیست برای هر اصطلاح کوتاه markup پیچیده بسازیم، اما در محتواهای آموزشی، نام محصول، کد یا جمله طولانی انگلیسی بهتر است زبان و ساختار روشنی داشته باشد.
نیمفاصله و جستوجو داخل سایت
کاربر ممکن است «دسترسپذیری»، «دسترس پذیری» یا حتی شکلهای متفاوت «ی» و «ک» را جستوجو کند. این موضوع فقط سئو نیست؛ قابلیت پیدا کردن محتوا بخشی از تجربه قابل استفاده است. جستوجوی داخلی باید تا حد معقول شکلهای رایج نویسهها، فاصله و نیمفاصله را نرمال کند. پیام «نتیجهای پیدا نشد» زمانی منصفانه است که سیستم تفاوتهای طبیعی تایپ فارسی را فهمیده باشد.
دسترسپذیری در طراحی UI؛ قبل از اینکه کدنویسی شروع شود
بخش بزرگی از هزینه اصلاح دسترسپذیری زمانی ایجاد میشود که فایل طراحی بدون حالتهای تعاملی، بدون قواعد کنتراست و با کامپوننتهای مبهم تحویل توسعه شود. طراح نباید فقط حالت عادی دکمه و فیلد را نشان دهد. Hover، focus، active، disabled، error، success، loading و حالتهای اندازه مختلف بخشی از تعریف کامپوننتاند.
کنتراست را از روی حس قضاوت نکنید
خاکستری روشن روی سفید ممکن است در مانیتور طراح شیک به نظر برسد، اما برای متن کوچک خوانا نباشد. معیار AA در WCAG برای متن معمولی معمولاً نسبت کنتراست حداقل ۴.۵ به ۱ و برای متن بزرگ ۳ به ۱ را در نظر میگیرد. کنترلهای رابط و اطلاعات گرافیکی ضروری نیز در بسیاری از حالتها به نسبت ۳ به ۱ در برابر رنگ مجاور نیاز دارند. جزئیات و استثناها را باید از راهنمای رسمی کنتراست حداقل WCAG بررسی کرد، نه از یک تصویر خلاصه در شبکه اجتماعی.
کنتراست فقط متن بدنه نیست. placeholder، متن دکمه، لینک، آیکون ورودی، border فیلد، حالت خطا و نشانگر فوکوس هم باید دیده شوند. همچنین رنگ نباید تنها حامل معنا باشد. اگر فیلد خطادار فقط قرمز میشود، یک آیکون، متن یا نشانه ساختاری نیز لازم است. در نمودار، رنگ را با برچسب، الگو یا شکل همراه کنید.
اندازه فونت، فاصله و طول خط
هیچ عدد جادویی برای همه فونتها وجود ندارد، اما متن بدنه باید بدون فشار خوانده شود. خط بسیار بلند باعث گمشدن ابتدای سطر بعد میشود و خط بسیار کوتاه ریتم را میشکند. در فارسی، فاصله خطوط کم میتواند نقطهها و صعود و نزول حروف را فشرده کند. سیستم طراحی باید اجازه دهد کاربر فاصله متن را افزایش دهد بدون اینکه محتوا قطع یا کنترلها روی هم بیفتند. معیار Text Spacing در WCAG دقیقاً بر نبودِ از دست رفتن محتوا یا عملکرد هنگام تغییر فاصلهها تأکید دارد.
حالت فوکوس را طراحی کنید
حذف outline برای زیباتر شدن، یکی از خطاهای قدیمی و هنوز رایج است. کاربر کیبورد باید همیشه بداند روی کدام لینک، دکمه یا فیلد قرار دارد. فوکوس خوب فقط یک خط کمرنگ نیست؛ در پسزمینه روشن و تیره دیده میشود، با حالت hover اشتباه نمیشود و در تمام کامپوننتها منطق یکسانی دارد. WCAG 2.2 برای ظاهر فوکوس جزئیات بیشتری ارائه کرده و یک حلقه واضح با ضخامت مناسب معمولاً انتخاب مطمئنتری از سایه مبهم است.
هدفهای لمسی کوچک نسازید
آیکون بستن، منوی سهنقطه، فلش اسلایدر و checkbox کوچک شاید روی دسکتاپ قابل کلیک باشند، اما در موبایل خطا میسازند. WCAG 2.2 در معیار AA برای Target Size حداقل ۲۴ در ۲۴ CSS pixel را با چند استثنا مطرح میکند و سطح AAA هدف ۴۴ در ۴۴ را پیشنهاد میدهد. در طراحی محصول بهتر است فقط به حداقل قانونیِ معیار فکر نکنیم؛ کنترل پرتکرار یا حساس باید فضای لمس راحتتری داشته باشد.
انیمیشن باید قابل کنترل باشد
حرکت میتواند رابطه و تغییر وضعیت را توضیح دهد، اما انیمیشن پیوسته، parallax شدید یا ورودهای ناگهانی ممکن است تمرکز و تعادل بعضی کاربران را بههم بزند. prefers-reduced-motion باید در طراحی و توسعه جدی گرفته شود. اسلایدر خودکار، ویدئوی پسزمینه و ticker باید امکان توقف داشته باشند. دسترسپذیری مخالف حرکت نیست؛ مخالف حرکتی است که کاربر بر آن کنترل ندارد.
محتوای دسترسپذیر؛ از متن جایگزین تا لینک و ویدئو
ممکن است قالب سایت استاندارد باشد اما محتوا هر هفته کیفیت دسترسپذیری را پایین بیاورد. نویسندهای که تیترها را فقط برای بزرگکردن متن استفاده میکند، تصویری که متن مهم داخل خودش دارد، لینکی با عنوان نامشخص یا ویدئوی بدون زیرنویس میتواند ساختار سالم را خراب کند. به همین دلیل، راهنمای تحریریه باید قواعد دسترسپذیری داشته باشد.
متن جایگزین خوب، تصویر را توصیف نمیکند؛ نقش آن را منتقل میکند
alt باید با زمینه نوشته شود. اگر تصویر صرفاً تزئینی است، alt خالی میتواند انتخاب درست باشد تا صفحهخوان بیدلیل آن را اعلام نکند. اگر تصویر محصول است، نام و ویژگی مهم را بگویید. اگر نمودار است، نتیجه اصلی و دسترسی به داده را فراهم کنید. اگر تصویر دکمه است، عملکرد مهمتر از ظاهر است. عبارتهایی مانند «عکس»، «تصویر مربوطه» یا نام طولانی فایل معمولاً کمکی نمیکنند.
فرض کنید در مقالهای نموداری نشان میدهد نرخ تکمیل فرم پس از کوتاهشدن از ۹ فیلد به ۴ فیلد افزایش یافته است. alt مناسب میتواند نتیجه را کوتاه منتقل کند، اما داده دقیق بهتر است در کپشن، جدول یا متن اطراف نیز وجود داشته باشد. متن جایگزین نباید تبدیل به پاراگرافی پنهان شود؛ اطلاعات پیچیده باید در محتوای قابل مشاهده هم قابل دسترسی باشد.
هدینگها نقشه محتوا هستند
H2 و H3 فقط سبک تایپوگرافی نیستند. کاربر صفحهخوان میتواند از آنها برای مرور سریع ساختار استفاده کند و موتور جستوجو نیز رابطه بخشها را بهتر میفهمد. از یک سطح به سطح نامنطقی نپرید فقط چون اندازه بصری مطلوب است. ابتدا سلسلهمراتب معنایی را درست کنید، سپس ظاهر را با CSS تنظیم کنید.
در یک مقاله طولانی، تیترهای دقیق بار شناختی را کم میکنند. «چند نکته مهم» تیتر ضعیفی است؛ «چطور متن جایگزین تصویر محصول را بنویسیم؟» مقصد را روشن میکند. فهرست مطالب، لینک پرش و عنوانهای توصیفی به همه کاربران کمک میکنند، بهویژه کسی که نمیخواهد پنجهزار کلمه را خطی بخواند.
متن لینک باید بیرون از جمله هم معنی داشته باشد
وقتی چند لینک با متن «اینجا»، «بیشتر» یا «ادامه» در صفحه وجود دارد، مرور فهرست لینکها بیفایده میشود. انکر تکست باید مقصد یا اقدام را توصیف کند. برای مثال، «دیدن نمونهکارهای ایران دیزاینر» از «اینجا کلیک کنید» روشنتر است. البته انکر را آنقدر طولانی و پر از کلمه کلیدی نکنید که خواندن متن مصنوعی شود.
زبان ساده، به معنای سطحینویسی نیست
جملههای کوتاهتر، تعریف اصطلاح در اولین استفاده، فهرست برای مراحل و خلاصه قبل از جزئیات، فهم را بهتر میکنند. در محتوای تخصصی میتوان دقت را حفظ کرد و همزمان مسیر خواندن را روشن ساخت. متن انسانی به جای تکرار شعار، مثال میدهد، محدودیت را میگوید و میان «قاعده»، «پیشنهاد» و «استثنا» فرق میگذارد.
ویدئو و صوت باید راه جایگزین داشته باشند
برای ویدئوی دارای گفتار، زیرنویس دقیق لازم است؛ زیرنویس خودکار باید بازبینی شود، مخصوصاً در فارسی که نام برندها و اصطلاحات تخصصی زیاد خطا میشوند. محتوای مهم تصویری ممکن است به توضیح صوتی یا متن معادل نیاز داشته باشد. فایل صوتی آموزشی نیز بهتر است رونوشت متنی داشته باشد تا کاربر ناشنوا، موتور جستوجو و حتی کاربری که در محیط شلوغ نمیتواند صدا پخش کند، به محتوا برسند.
کیبورد و فوکوس؛ سریعترین راه کشف رابطهای نمایشی
ماوس را کنار بگذارید و از ابتدای صفحه فقط با Tab، Shift+Tab، Enter، Space، کلیدهای جهت و Escape حرکت کنید. اگر بعد از چند ثانیه ندانستید کجا هستید، روی عنصری نامرئی افتادید، منو باز نشد یا از یک پنجره بیرون نیامدید، رابط برای کاربر کیبورد آماده نیست. این تست ساده همه مشکلات را پیدا نمیکند، اما کیفیت واقعی کامپوننتها را خیلی زود آشکار میکند.
ترتیب فوکوس باید از منطق کار پیروی کند
W3C در توضیح Focus Order تأکید میکند ترتیب حرکت باید معنا و کارکرد صفحه را حفظ کند. در فارسی، این نکته حساستر است؛ چون ترتیب دیداری راستبهچپ ممکن است با ترتیب DOM یا چیدمان تغییرکرده توسط CSS ناسازگار شود. کاربر نباید از منوی بالا ناگهان به فوتر و سپس به فرم وسط صفحه پرتاب شود.
منوی بازشونده فقط hover نیست
منویی که با رفتن ماوس باز میشود باید با کیبورد و لمس نیز الگوی قابل استفاده داشته باشد. وضعیت باز یا بسته برای فناوری کمکی اعلام شود، کلید Escape بتواند آن را ببندد، فوکوس بیدلیل جابهجا نشود و کاربر پس از بستن بداند کجاست. لینک والد و دکمه بازکردن زیرمنو دو کار متفاوتاند؛ ترکیب مبهم آنها معمولاً هم در موبایل و هم در صفحهخوان مشکل میسازد.
مودال باید فوکوس را مدیریت کند، نه زندانی
وقتی مودال باز میشود، فوکوس باید به محل منطقی داخل آن برود. محتوای پشت مودال نباید در دسترس تعامل باقی بماند. Tab در محدوده مودال حرکت کند، Escape در صورت مناسب بودن آن را ببندد و پس از بستهشدن، فوکوس به کنترل آغازکننده برگردد. اگر کاربر بعد از بستن به ابتدای صفحه برگردد، زمینه کار از دست میرود.
Skip Link کوچک اما اثرگذار است
کاربری که با کیبورد در دهها صفحه حرکت میکند، نباید هر بار همه لینکهای هدر را رد کند تا به محتوای اصلی برسد. لینک «رفتن به محتوای اصلی» میتواند در حالت عادی پنهان و هنگام فوکوس آشکار شود. این جزئیات ساده نشان میدهد تیم به استفاده تکرارشونده فکر کرده، نه فقط به اسکرینشات صفحه.
کامپوننت سفارشی، بدهی تعاملی میسازد
هر بار که select، checkbox، tab، accordion یا slider را از صفر میسازیم، مسئولیت نام، نقش، حالت، کلیدهای کنترلی، فوکوس و اعلام تغییر را هم میپذیریم. گاهی ظاهر سفارشی واقعاً لازم است؛ اما اگر یک عنصر بومی HTML همان کار را انجام میدهد، انتخاب بومی معمولاً پایدارتر و کمهزینهتر است.
فرم دسترسپذیر؛ جایی که UX، محتوا و کد همزمان سنجیده میشوند
فرم تماس، ثبتنام، جستوجو و پرداخت نقاطی هستند که یک مشکل کوچک میتواند مستقیماً به از دست رفتن لید یا فروش منجر شود. فرم دسترسپذیر باید قبل از ورود داده، انتظار را روشن کند؛ هنگام ورود، کنترل قابل استفاده بدهد؛ و بعد از ارسال، نتیجه یا خطا را قابل فهم اعلام کند.
هر فیلد به برچسب واقعی نیاز دارد
placeholder جای label را نمیگیرد. برچسب باید به ورودی مربوط متصل باشد تا کلیک روی آن فوکوس را به فیلد ببرد و صفحهخوان رابطه را اعلام کند. متن راهنما، نمونه فرمت و اجباری بودن فیلد نیز باید به روشی قابل تشخیص ارائه شوند. علامت ستاره بدون توضیح ممکن است برای همه روشن نباشد.
خطا را نزدیک مسئله و در خلاصه اعلام کنید
بعد از ارسال فرم طولانی، نمایش یک پیام قرمز در بالای صفحه کافی نیست. کاربر باید بداند چند خطا وجود دارد، کدام فیلد مشکل دارد و چگونه آن را اصلاح کند. فوکوس میتواند به خلاصه خطا هدایت شود و هر پیام به فیلد مرتبط وصل باشد. رنگ قرمز را با متن و نشانه همراه کنید. «فرمت اشتباه» ننویسید؛ بگویید «شماره تماس را با ۱۱ رقم و بدون فاصله وارد کنید».
اطلاعات درست را بعد از خطا پاک نکنید
اگر کاربر یک فیلد را اشتباه پر کرده، نباید پس از ارسال همه دادههای درست او از بین برود. حفظ ورودیهای معتبر، اعلام دقیق خطا و امکان برگشت، هزینه شناختی را کم میکند. در فرم چندمرحلهای نیز مرحله فعلی، تعداد مراحل و امکان بازبینی باید روشن باشد.
کپچا نباید تنها دروازه باشد
چالش تصویری مبهم، پازل حرکتی یا صوت ناخوانا میتواند کاربر واقعی را قبل از ربات متوقف کند. روشهای ضداسپم را لایهای طراحی کنید: honeypot، محدودسازی نرخ، تحلیل سمت سرور و گزینهای که وظیفه اصلی را برای انسان دشوار نکند. امنیت و دسترسپذیری رقیب نیستند؛ پیادهسازی ضعیف آنها را روبهروی هم قرار میدهد.
اندازهگیری فقط ارسال موفق نیست
اگر رویدادهای فرم را ثبت میکنید، شروع، خطا، رهاکردن مرحله و ارسال موفق را جدا ببینید. شاید یک فیلد خاص بیشترین خروج را بسازد. سرویس آنالیتیکس و ردیابی تبدیل زمانی ارزش دارد که داده را به سؤال طراحی وصل کند: کاربر کجا متوقف میشود و آیا مانع برای گروه خاصی شدیدتر است؟ داده جای تست دسترسپذیری را نمیگیرد، اما اولویت اصلاح را بهتر میکند.
HTML معنایی و ARIA؛ کمتر بنویسید، درستتر بنویسید
HTML معنایی اطلاعاتی را که در ظاهر میبینیم به ساختار قابل تفسیر تبدیل میکند. header، nav، main، article، aside و footer نواحی صفحه را روشن میکنند. button، a، input، label، table و heading رفتار و رابطههای شناختهشده دارند. وقتی همه چیز div باشد، باید بخش زیادی از معنا و تعامل را با کد اضافی بازسازی کنیم؛ و این بازسازی اغلب ناقص است.
دکمه و لینک را بر اساس کارشان انتخاب کنید
لینک کاربر را به مقصد دیگری میبرد؛ دکمه عملی را در همان زمینه انجام میدهد، مثل بازکردن منو یا ارسال فرم. این دو ممکن است از نظر بصری شبیه باشند، اما رفتار کیبورد و انتظار کاربر متفاوت است. ساختن لینک با href خالی برای بازکردن مودال یا div کلیکپذیر برای رفتن به صفحه، بدهی فنی و دسترسپذیری میسازد.
ARIA جایگزین HTML سالم نیست
ARIA میتواند نام، نقش، حالت و رابطهای را اعلام کند که عنصر بومی بهتنهایی منتقل نمیکند. اما اضافهکردن نقش اشتباه گاهی از نبود ARIA بدتر است. قاعده عملی این است: ابتدا عنصر بومی مناسب را انتخاب کنید؛ سپس فقط وقتی خلأ واقعی وجود دارد ARIA اضافه کنید؛ و بعد نتیجه را با صفحهخوان و کیبورد آزمایش کنید.
نام قابل دسترس باید با برچسب دیداری هماهنگ باشد
اگر روی دکمه نوشته «جستوجو» اما نامی که فناوری کمکی دریافت میکند «ارسال» است، کاربر فرمان صوتی یا صفحهخوان دچار تناقض میشود. aria-label نباید بیدلیل متن دیداری را بازنویسی کند. در آیکون بدون متن، نام روشن لازم است؛ در دکمهای که متن کافی دارد، همان متن اغلب بهترین نام است.
تغییر پویا باید اعلام شود
افزودن محصول به سبد، نمایش نتیجه جستوجوی زنده، خطای شبکه یا ذخیره موفق ممکن است بدون بارگذاری صفحه رخ دهد. اگر تغییر فقط دیداری باشد، کاربر صفحهخوان متوجه نمیشود. live region میتواند برای پیامهای مناسب استفاده شود، اما اعلام بیش از حد نیز مزاحم است. فقط اطلاعاتی را اعلام کنید که برای ادامه کار لازماند و لحن پیام را کوتاه نگه دارید.
کامپوننتها را در سطح سیستم اصلاح کنید
اگر ۳۰ صفحه از یک Input مشترک استفاده میکنند، اصلاح label، focus و error در همان کامپوننت اثر وسیعی دارد. این یکی از مزیتهای سیستم طراحی و توسعه کامپوننتمحور است. در مقابل، اصلاح دستی هر صفحه هم پرهزینه است و هم با انتشار بعدی دوباره خراب میشود. برای محصولات پیچیدهتر، مسیر طراحی و توسعه نرمافزار تحت وب باید دسترسپذیری را در تعریف کامپوننت، تست و معیار پذیرش وارد کند.
دسترسپذیری موبایل؛ فقط کوچککردن دسکتاپ نیست
موبایل محیطی با صفحه کوچک، لمس کمدقت، نور متغیر، حرکت و وقفههای زیاد است. بسیاری از موانعی که برای فرد دارای محدودیت دائمی جدیاند، در موبایل برای همه به شکل موقت ظاهر میشوند. دکمه کوچک در تاکسی، متن کمرنگ زیر آفتاب و فرم طولانی با یک دست، تجربه را میشکنند.
Reflow را با محتوای واقعی تست کنید
WCAG برای محتوای عمودی، ارائه بدون از دست رفتن اطلاعات یا نیاز به اسکرول دوبعدی در عرض معادل ۳۲۰ CSS pixel را مطرح میکند، بهجز بخشهایی که ماهیتاً به چیدمان دوبعدی نیاز دارند. جدول، کد و نمودار ممکن است راهحل ویژه بخواهند؛ اما متن، کارت و فرم نباید به خاطر عرض ثابت قطع شوند. بزرگنمایی مرورگر نیز باید در تست باشد، نه فقط چند breakpoint رایج.
ترتیب و فاصله کنترلها مهمتر از زیبایی فشرده است
قرار دادن چند آیکون کوچک کنار هم در هدر فضای کمتری میگیرد، اما خطای لمس را بالا میبرد. فضای کلیک میتواند از خود آیکون بزرگتر باشد بدون اینکه طراحی شلوغ شود. کنترلهای حساس مانند حذف، پرداخت یا بستن فرم بهتر است از کنترلهای مجاور فاصله کافی و امکان بازگشت داشته باشند.
کیبورد نرمافزاری را متناسب کنید
نوع ورودی مناسب برای ایمیل، تلفن، عدد و URL میتواند کیبورد موبایل را بهتر کند. autocomplete درست نیز از تایپ تکراری جلوگیری میکند. این تصمیمها برای کاربری که محدودیت حرکتی دارد ارزش بیشتری دارند، ولی نرخ تکمیل فرم همه کاربران را هم بهتر میکنند.
چرخش صفحه و زوم را بیدلیل محدود نکنید
قفلکردن orientation یا جلوگیری از zoom ممکن است طراحی را کنترلشده نگه دارد، اما کنترل را از کاربر میگیرد. کاربری که دستگاه را روی پایه نصب کرده یا برای خواندن به بزرگنمایی نیاز دارد، شاید نتواند با حالت تحمیلی کار کند. طراحی باید با تغییر اندازه سازگار شود، نه اینکه کاربر را مجبور کند با ابعاد طراح کنار بیاید.
آیا دسترسپذیری وب مستقیماً باعث رتبه بهتر سئو میشود؟
پاسخ حرفهای این است: نباید WCAG را یک «فاکتور رتبه مستقیم و تضمینی» معرفی کرد. دسترسپذیری و سئو همپوشانیهای مهمی دارند، اما هدف و معیار آنها یکی نیست. عنوانهای منطقی، HTML معنایی، لینکهای توصیفی، متن جایگزین مفید، محتوای قابل دسترسی و تجربه موبایل بهتر میتوانند فهم صفحه و استفاده کاربر را تقویت کنند. با این حال، گرفتن امتیاز accessibility بالا بهتنهایی وعده رتبه نمیدهد.
راهنمای شروع سئو گوگل تأکید میکند سایت باید برای کاربر ساخته شود و موتور جستوجو نیز یکی از مصرفکنندگان محتواست. وقتی محتوای اصلی فقط بعد از تعامل پیچیده دیده میشود، لینک واقعی ندارد یا ساختار آن برای ابزارها قابل فهم نیست، هم کاربر و هم خزنده ممکن است مسیر ضعیفتری داشته باشند. این نقطه اشتراک واقعی است، نه یک میانبر الگوریتمی.
همپوشانیهای واقعی دسترسپذیری و سئو
- ساختار هدینگ: مرور محتوا را برای کاربر و فهم رابطه بخشها را برای ماشین روشنتر میکند.
- متن جایگزین: معنای تصویر را در زمینه منتقل میکند و در جستوجوی تصویر نیز مفید است.
- انکر تکست توصیفی: مقصد لینک را برای صفحهخوان، کاربر و موتور جستوجو شفاف میکند.
- HTML معنایی: نقش محتوا و کنترلها را قابل تفسیرتر میکند.
- نسخه موبایل قابل استفاده: اصطکاک خواندن و اقدام را کم میکند.
- محتوای ویدئویی همراه متن: دسترسی و امکان کشف محتوای گفتاری را گسترش میدهد.
در یک استراتژی سئو سالم، دسترسپذیری بهعنوان بخشی از کیفیت فنی و محتوایی دیده میشود، نه ترفند رتبهگیری. اگر سایت کلمه کلیدی مناسبی ندارد، صفحه خدمات ضعیف است یا اعتبار موضوعی شکل نگرفته، اصلاح کنتراست بهتنهایی رشد ارگانیک نمیسازد. اما بیتوجهی به دسترسپذیری میتواند کیفیت تجربه و قابلیت استفاده از همان ترافیکی را که به دست آوردهاید پایین بیاورد.
چطور دسترسپذیری سایت را ممیزی کنیم؟
ممیزی خوب از ابزار شروع نمیشود؛ از دامنه و سناریو شروع میشود. ابتدا صفحات و وظایف حیاتی را مشخص کنید: صفحه اصلی، صفحه خدمت کلیدی، جستوجو، تماس، ورود، سبد و پرداخت یا رزرو. سپس کاربران و روشهای تعامل را در نظر بگیرید. در پایان، تست خودکار، بررسی دستی، آزمون با فناوری کمکی و در صورت امکان تست با کاربران واقعی را ترکیب کنید.
مرحله اول: نمونهبرداری هوشمند از صفحات
ممیزی فقط صفحه اصلی تصویر ناقصی میدهد. یک قالب مقاله، یک صفحه خدمات، یک فرم، یک صفحه دارای جدول یا ویدئو و مهمترین جریان تبدیل را انتخاب کنید. اگر سایت کامپوننتمحور است، فهرست کامپوننتها را هم بسازید. هدف این است که هم الگوهای تکرارشونده و هم صفحات پرریسک دیده شوند.
مرحله دوم: تستهای خودکار
ابزارهایی مانند Lighthouse، axe و WAVE میتوانند بخشی از خطاهای کنتراست، نامگذاری، ساختار و ARIA را سریع پیدا کنند. این ابزارها برای خط پایه و کنترل مداوم مفیدند، اما «صفر خطا» مساوی دسترسپذیری کامل نیست. ابزار نمیفهمد متن لینک واقعاً برای مخاطب روشن است، ترتیب محتوا منطقی است یا alt تصویر همان نقش لازم را منتقل میکند.
مرحله سوم: تست دستی کیبورد و بزرگنمایی
سناریوها را فقط با کیبورد کامل کنید. فوکوس را در تمام مسیر ببینید. صفحه را تا ۲۰۰ و ۴۰۰ درصد بزرگ کنید و قطع محتوا، همپوشانی و اسکرول افقی را بررسی کنید. فاصله متن را افزایش دهید. رنگ را به تنهایی حذفشده فرض کنید. پیامهای خطا و وضعیتهای loading و success را هم آزمایش کنید.
مرحله چهارم: صفحهخوان
با VoiceOver در macOS و iOS، TalkBack در Android یا NVDA در Windows میتوان نمونههای واقعی را آزمایش کرد. هدف اولیه حفظ همه میانبرها نیست؛ با عنوانها حرکت کنید، فهرست لینکها را بشنوید، فرم را تکمیل کنید، منو و مودال را کنترل کنید و تغییرهای پویا را بررسی کنید. تست در یک صفحهخوان کافی نیست، اما دید بسیار بهتری از ساختار میدهد.
مرحله پنجم: اولویتبندی بر اساس شدت، فراوانی و اهمیت تجاری
همه خطاها وزن یکسان ندارند. دکمه خریدی که نام قابل دسترس ندارد با یک alt نهچندان کامل در تصویر تزئینی همسطح نیست. برای هر مسئله سه سؤال بپرسید: آیا وظیفه را متوقف میکند؟ چند صفحه یا کاربر را درگیر میکند؟ آیا در مسیر درآمد، اعتماد یا اطلاعات حیاتی است؟ این نگاه کمک میکند تیم ابتدا مانعهای واقعی را بردارد.
اسکورکارت ۱۰۰ امتیازی دسترسپذیری سایت
این اسکورکارت جای انطباق رسمی WCAG را نمیگیرد؛ یک ابزار مدیریتی برای مقایسه وضعیت قبل و بعد و اولویتبندی است. هر بخش را بر اساس شواهد تست امتیاز بدهید، نه برداشت بصری.
| حوزه ارزیابی | امتیاز | سؤال کلیدی |
|---|
| ساختار معنایی و هدینگها | ۱۰ | آیا نواحی، عنوانها، فهرستها و روابط در کد قابل تشخیصاند؟ |
| کیبورد و مدیریت فوکوس | ۱۵ | آیا وظایف اصلی بدون ماوس، با ترتیب و فوکوس قابل مشاهده کامل میشوند؟ |
| کنتراست و انتقال معنا | ۱۰ | آیا متن و کنترلها خوانا هستند و معنا فقط به رنگ وابسته نیست؟ |
| فرم، برچسب و مدیریت خطا | ۱۵ | آیا کاربر انتظار، خطا و راه اصلاح را میفهمد؟ |
| محتوا، تصویر، صوت و ویدئو | ۱۰ | آیا جایگزین مناسب و ساختار خواندن روشن وجود دارد؟ |
| موبایل، لمس، زوم و Reflow | ۱۰ | آیا در صفحه کوچک و بزرگنمایی، اطلاعات یا عملکرد از دست نمیرود؟ |
| منو، مودال و کامپوننتهای پویا | ۱۰ | آیا نقش، حالت، کنترل کیبورد و اعلام تغییر درست است؟ |
| خوانایی و زبان فارسی/RTL | ۱۰ | آیا جهت، فونت، متن ترکیبی و ترتیب منطقی با محتوای واقعی تست شدهاند؟ |
| فرایند، مستندات و کنترل انتشار | ۱۰ | آیا دسترسپذیری معیار پذیرش و بخشی از QA مداوم است؟ |
| مجموع | ۱۰۰ | امتیاز باید همراه فهرست شواهد و خطاهای باز گزارش شود. |
|---|
تفسیر امتیاز بدون ادعای گمراهکننده
- ۰ تا ۳۹: موانع جدی محتمل است؛ مسیرهای حیاتی باید فوری بررسی شوند.
- ۴۰ تا ۵۹: بخشی از پایهها وجود دارد، اما تجربه میان صفحات و کامپوننتها ناپایدار است.
- ۶۰ تا ۷۹: وضعیت قابل قبول اولیه با چند ریسک مهم؛ نیازمند اصلاح و تست دستی عمیقتر.
- ۸۰ تا ۹۰: فرایند نسبتاً بالغ؛ خطاهای باقیمانده باید بر اساس سناریو و فناوری کمکی سنجیده شوند.
- ۹۱ تا ۱۰۰: کیفیت اجرایی بالا در دامنه بررسیشده؛ نه تضمین دسترسی کامل برای همه شرایط و همه صفحات.
گزارش ممیزی باید تاریخ، نسخه سایت، صفحات نمونه، مرورگرها، ابزارها، فناوریهای کمکی و محدودیتها را ثبت کند. یک عدد بدون زمینه، خیلی زود به ادعایی غیرقابل دفاع تبدیل میشود.
نقشه اصلاح دسترسپذیری در سایت موجود
قرار نیست برای حل هر مشکل، سایت را از صفر بسازید. بسیاری از اصلاحها را میتوان در سطح design token، کامپوننت، قالب محتوا و فرایند انتشار انجام داد. اما اگر معماری رابط، سیستم مدیریت محتوا یا وابستگیهای فنی اجازه اصلاح پایدار نمیدهند، بازطراحی مرحلهای ممکن است منطقیتر باشد. مقاله ریدیزاین سایت چیست و چه زمانی لازم میشود کمک میکند فرق اصلاح محدود و بازطراحی راهبردی را بهتر بسنجید.
فاز صفر: توقف تولید خطای تازه
قبل از پاکسازی گذشته، جلوی تکرار را بگیرید. کامپوننتهای جدید باید معیار پذیرش داشته باشند، تیم محتوا باید alt و هدینگ را بلد باشد، حذف outline متوقف شود و الگوهای پرخطا علامتگذاری شوند. اگر هر هفته محتوای جدید همان مشکل را تکرار کند، ممیزی به تعقیب بیپایان تبدیل میشود.
فاز یک: رفع مانعهای مسیرهای حیاتی
ورود، جستوجو، خرید، تماس، رزرو و پرداخت را در اولویت قرار دهید. نام کنترلها، برچسب فرم، خطا، فوکوس، کیبورد و کنتراست را اصلاح کنید. اگر یک مشکل در کامپوننت مشترک وجود دارد، آن را در منبع حل کنید تا همه صفحات بهبود یابند.
فاز دو: اصلاح الگوها و سیستم طراحی
رنگهای قابل استفاده، حالت فوکوس، اندازه هدف لمسی، قواعد تایپوگرافی و وضعیتهای کامپوننت را مستند کنید. Storybook یا محیط مشابه میتواند تست مستقل کامپوننتها را آسان کند. نمونه RTL، متن طولانی، خطا و loading را کنار حالت عادی قرار دهید؛ کامپوننتی که فقط با متن کوتاه آزمایش شده، آماده تولید نیست.
فاز سه: پاکسازی محتوا و رسانه
تصاویر مهم، ویدئوها، PDFها، جدولها و مقالههای پرترافیک را بر اساس اولویت بازبینی کنید. altهای ماشینی و تکراری را اصلاح کنید، ساختار هدینگ را مرتب کنید و متن لینکهای مبهم را تغییر دهید. برای رسانههای مهم زیرنویس یا رونوشت بسازید. این مرحله باید با صاحب محتوا انجام شود، چون ابزار از هدف واقعی تصویر خبر ندارد.
فاز چهار: تست رگرسیون و پایش
بخشی از تستها را وارد CI کنید تا خطاهای قابل تشخیص خودکار دوباره وارد محصول نشوند. تست دستی را در انتشارهای مهم نگه دارید. بعد از تغییر افزونه، کتابخانه رابط، فونت، منو یا فرم، سناریوهای اصلی را دوباره اجرا کنید. برای سایتهایی که به توسعه مداوم نیاز دارند، پشتیبانی و توسعه مستمر وبسایت باید نگهداری دسترسپذیری را کنار امنیت، عملکرد و تغییرات محصول ببیند.
چه زمانی بازطراحی کامل منطقیتر است؟
اگر مشکلها پراکنده اما سطحیاند، اصلاح مرحلهای معمولاً بهتر است. اگر ناوبری، ترتیب محتوا، کامپوننتهای اصلی و CMS همزمان مانعاند، وصلهکاری ممکن است هزینه بیشتری بسازد. نشانههای نیاز به تصمیم بزرگتر عبارتاند از: وابستگی شدید به کتابخانه غیرقابل اصلاح، تکرار خطا در همه قالبها، ناتوانی ویرایشگر در تولید HTML سالم، نسخه موبایل جدا و ناسازگار یا مسیری که بدون بازنویسی معماری قابل استفاده نمیشود.
تصمیم نهایی باید بر اساس شدت مانع، ارزش صفحات، هزینه اصلاح، عمر فنی سیستم و برنامه توسعه گرفته شود. بازطراحی صرفاً برای گرفتن امتیاز ابزار توجیه ندارد؛ باید تجربه واقعی و نگهداری آینده را بهتر کند.
خطاهای رایج در پروژههای دسترسپذیری
اشتباه اول: نصب یک ویجت و اعلام حل کامل مسئله
ابزارهای overlay ممکن است چند امکان مانند تغییر کنتراست یا اندازه متن اضافه کنند، اما نمیتوانند بهصورت قابل اعتماد معماری نامناسب، برچسب گمشده، ترتیب فوکوس، متن جایگزین بیمعنی یا فرایند ناقص را اصلاح کنند. قابلیت شخصیسازی میتواند مفید باشد، ولی جای کد و محتوای درست را نمیگیرد.
اشتباه دوم: اعتماد کامل به امتیاز Lighthouse
امتیاز ابزار برای مقایسه و یافتن بخشی از خطاها مفید است. اما اگر یک alt وجود داشته باشد، ابزار لزوماً کیفیت معنای آن را نمیفهمد. اگر ترتیب Tab از نظر فنی ممکن باشد، منطقی بودن مسیر را تضمین نمیکند. گزارش حرفهای باید صریح بگوید چه چیزهایی خودکار و چه چیزهایی دستی بررسی شدهاند.
اشتباه سوم: افزودن ARIA به همه چیز
ARIA زیاد نشانه بلوغ نیست. نقش متناقض، نام تکراری و live region پرحرف میتواند تجربه صفحهخوان را بدتر کند. HTML بومی را در اولویت بگذارید و ARIA را برای مسئله مشخص به کار ببرید.
اشتباه چهارم: دسترسپذیری فقط برای صفحه اصلی
کاربر ممکن است از گوگل مستقیم وارد مقاله، محصول یا صفحه خدمت شود. فرم تماس، نتایج جستوجو، خطای ۴۰۴، ورود و پرداخت گاهی مهمتر از صفحه اصلیاند. نمونهبرداری باید بر اساس الگو و وظیفه باشد.
اشتباه پنجم: تست با محتوای تمیز و کوتاه
نام بلند، قیمت بزرگ، متن فارسی و انگلیسی، تصویر بدون نسبت ثابت، خطای چندخطی و ترجمه واقعی کامپوننت را تحت فشار میگذارند. طراحیای که فقط با داده نمونه زیباست، هنوز آزموده نشده است.
اشتباه ششم: اعلام انطباق مطلق
سایت زنده تغییر میکند. محتوا، افزونه، اسکریپت ثالث و مرورگر میتوانند نتیجه را عوض کنند. بهتر است دامنه ممیزی، معیار هدف، تاریخ و خطاهای باقیمانده روشن باشند. زبان دقیق اعتماد بیشتری از نشان سبزی میسازد که توضیحی پشت آن نیست.
چکلیست انتشار یک صفحه دسترسپذیر
این فهرست کوتاه برای کنترل نهایی یک صفحه است و جای ممیزی کامل را نمیگیرد:
- صفحه یک عنوان توصیفی و ساختار H1، H2 و H3 منطقی دارد.
- زبان و جهت اصلی صفحه درست تعریف شده است.
- محتوای اصلی در landmark مناسب قرار دارد و Skip Link کار میکند.
- همه عملکردها با کیبورد قابل انجاماند.
- فوکوس در تمام مسیر دیده میشود و ترتیب آن منطقی است.
- هیچ منو، مودال یا کامپوننتی تله کیبورد نمیسازد.
- متن و کنترلها کنتراست مناسب دارند.
- رنگ تنها راه انتقال خطا، انتخاب یا وضعیت نیست.
- تصاویر معنادار alt متناسب با نقش دارند و تصاویر تزئینی نادیده گرفته میشوند.
- ویدئو و صوت مهم زیرنویس، رونوشت یا جایگزین لازم دارند.
- متن لینک مقصد یا اقدام را روشن میکند.
- فیلدهای فرم label واقعی، راهنما و پیام خطای قابل اصلاح دارند.
- اعلانهای پویا در صورت نیاز برای فناوری کمکی اعلام میشوند.
- در زوم و عرض کم، محتوا قطع و روی هم افتاده نمیشود.
- هدفهای لمسی مهم اندازه و فاصله مناسب دارند.
- حرکت خودکار قابل توقف است و reduced motion رعایت میشود.
- متن فارسی، انگلیسی، عدد و URL در کنار هم درست نمایش و خوانده میشوند.
- صفحه با دستکم یک ابزار خودکار و یک تست دستی بررسی شده است.
- سناریوی اصلی صفحه، نه فقط اجزای جدا، تا انتها انجام شده است.
- نتیجه، محدودیتها و خطاهای باز در گزارش انتشار ثبت شدهاند.
پرسشهای متداول درباره دسترسپذیری وب
آیا دسترسپذیری فقط برای افراد نابینا است؟
خیر. دسترسپذیری نیازهای دیداری، شنیداری، حرکتی و شناختی را پوشش میدهد و برای محدودیتهای موقت یا شرایط محیطی هم مفید است. زیرنویس در محیط شلوغ، کنتراست زیر نور شدید و دکمه بزرگ هنگام استفاده یکدستی نمونههاییاند که به طیف وسیعی از کاربران کمک میکنند.
WCAG 2.2 چیست؟
WCAG 2.2 نسخهای از راهنماهای دسترسپذیری محتوای وب است که معیارهای قابل آزمون را زیر چهار اصل قابل ادراک، قابل استفاده، قابل فهم و مقاوم سازمان میدهد. معیارها در سطحهای A، AA و AAA قرار میگیرند و نسخه ۲.۲ نسبت به ۲.۱ موارد تازهای مانند جزئیات بیشتر فوکوس و اندازه هدف را افزوده است.
برای یک سایت معمولی سطح AA کافی است؟
AA معمولاً هدف عملی رایجی است، اما «کافی بودن» به نوع محصول، کاربران، تعهدات و دامنه پروژه وابسته است. بعضی معیارهای AAA نیز میتوانند برای یک سناریوی خاص ارزشمند باشند. بهتر است به جای برچسب کلی، وظایف اصلی و نیاز کاربران را مبنای تصمیم قرار دهید.
آیا وردپرس ذاتاً دسترسپذیر است؟
خود CMS نتیجه نهایی را تضمین نمیکند. قالب، افزونه، صفحهساز، محتوای واردشده و سفارشیسازی میتوانند تجربه را بهتر یا بدتر کنند. وردپرس و توسعه اختصاصی هر دو به انتخاب درست، تست و نگهداری نیاز دارند. برای مقایسه زمینههای انتخاب، راهنمای طراحی سایت با وردپرس مفید است.
آیا با نصب افزونه دسترسپذیری مشکل حل میشود؟
خیر. افزونه ممکن است چند قابلیت کمکی اضافه کند یا بخشی از خطاها را تشخیص دهد، اما معماری، محتوای مبهم، ترتیب فوکوس و تعامل ناقص را بهطور کامل اصلاح نمیکند. مسئله باید در منبع طراحی، محتوا و کد حل شود.
آیا امتیاز ۱۰۰ Lighthouse یعنی سایت کاملاً دسترسپذیر است؟
خیر. تست خودکار فقط بخشی از معیارها و الگوهای قابل تشخیص را پوشش میدهد. کیفیت alt، منطق هدینگها، فهمپذیری متن، مدیریت واقعی فوکوس و امکان تکمیل وظیفه به بررسی دستی و گاهی تست کاربر نیاز دارد.
متن جایگزین تصویر باید چند کلمه باشد؟
عدد ثابتی وجود ندارد. alt باید نقش تصویر را در همان زمینه، کوتاه و کافی منتقل کند. تصویر تزئینی معمولاً alt خالی میگیرد؛ تصویر محصول به نام و ویژگی مهم نیاز دارد؛ نمودار پیچیده نیز بهتر است توضیح و داده قابل مشاهده در متن یا جدول داشته باشد.
آیا دسترسپذیری ظاهر سایت را زشت میکند؟
خیر. کنتراست مناسب، ساختار روشن، فضای لمس کافی و فوکوس قابل مشاهده محدودیت خلاقیت نیستند؛ مسئله طراحیاند. هویت بصری قوی میتواند درون این معیارها شکل بگیرد. سایت شلوغ و کمخوان الزاماً خلاق نیست و سایت دسترسپذیر نیز الزاماً ساده و بیرنگ نیست.
دسترسپذیری چه ارتباطی با سئو دارد؟
برخی روشها مانند HTML معنایی، هدینگ منطقی، متن جایگزین، لینک توصیفی و تجربه موبایل بهتر به هر دو حوزه کمک میکنند. اما انطباق WCAG فاکتور تضمینی رتبه نیست و سئو نیز جای تست دسترسپذیری را نمیگیرد.
از کدام صفحههای سایت ممیزی را شروع کنیم؟
از مسیرهای حیاتی و الگوهای پرتکرار شروع کنید: صفحه اصلی، مهمترین خدمت یا دسته، فرم تماس، ورود، جستوجو، سبد، پرداخت و قالب مقاله. صفحاتی را انتخاب کنید که هم ارزش تجاری دارند و هم کامپوننتهای مختلف را نمایندگی میکنند.
هر چند وقت یک بار باید دسترسپذیری را تست کرد؟
پس از هر تغییر مهم در قالب، ناوبری، فرم، کتابخانه رابط یا CMS و همچنین در بازههای دورهای. تست خودکار میتواند مداوم باشد؛ تست دستی باید در انتشارهای مهم و مسیرهای حیاتی تکرار شود. سایت زنده با محتوای جدید تغییر میکند، پس ممیزی یکباره کافی نیست.
برای شروع اصلاح سایت به بازطراحی کامل نیاز داریم؟
نه همیشه. ابتدا موانع مسیرهای اصلی و مشکلات کامپوننتهای مشترک را اصلاح کنید. اگر معماری، سیستم طراحی و زیرساخت مدیریت محتوا اجازه اصلاح پایدار نمیدهند، آنوقت بازطراحی مرحلهای یا کامل را بررسی کنید.
جمعبندی؛ سایت دسترسپذیر یعنی سایت قابل استفادهتر
دسترسپذیری یک امتیاز تزئینی در گزارش فنی نیست. کیفیتی است که تعیین میکند چه کسی میتواند پیام شما را دریافت کند، مسیر را بفهمد و کارش را کامل کند. WCAG 2.2 زبان مشترک و معیارهای قابل آزمون میدهد، اما نتیجه از همکاری محتوا، طراحی، توسعه و کنترل کیفیت به دست میآید.
برای شروع لازم نیست همه ۸۶ معیار موفقیت را حفظ کنید. مسیرهای حیاتی را مشخص کنید، ماوس را کنار بگذارید، صفحه را بزرگ کنید، فرم را با خطا آزمایش کنید، ساختار را با صفحهخوان بشنوید و از ابزار خودکار برای پیدا کردن الگوهای تکراری کمک بگیرید. سپس مسئلهها را بر اساس شدت و گستره اصلاح کنید. این فرایند از یک دکمه و یک فرم شروع میشود، اما در نهایت به سیستم طراحی، راهنمای محتوا و روش انتشار میرسد.
اگر سایت موجود دارید و نمیدانید مشکل اصلی در رابط، محتوا، کد یا مسیر تبدیل است، پیش از تصمیم به بازطراحی کامل، یک ارزیابی محدود روی صفحات کلیدی انجام دهید. برای بررسی ساختار و دامنه پروژه میتوانید از صفحه تماس ایران دیزاینر مسیر مناسب را انتخاب کنید. خروجی خوب باید فقط یک نمره نباشد؛ باید بگوید کدام مانع، در کدام مسیر، برای کدام کاربر و با چه اولویتی اصلاح شود.