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

دسترس پذیری یعنی چه، و برای چه کسی؟

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

فهرست کسانی که از این کار سود می برند بلندتر از آن است که معمولا تصور می شود. کسی که با صفحه خوان کار می کند. کسی که دستش می لرزد و ماوس را دقیق نمی برد. کسی که کوررنگی دارد و قرمز و سبز برایش یک رنگ اند. کسی که ویدیوی شما را در اتوبوس بدون صدا نگاه می کند. و بعد گروهی که هیچ وقت خودشان را در این فهرست نمی بینند: شما، وقتی زیر آفتاب ظهر به صفحه نگاه می کنید، یا یک دستتان بند است و با شست همان دست دیگر کار می کنید.

استانداردش WCAG است، مجموعه ای از معیارهای قابل آزمون که کنسرسیوم وب منتشر می کند، در سه سطح A و AA و AAA. هدف عملی تقریبا همیشه AA است؛ AAA برای بعضی معیارها روی یک سایت معمولی شدنی نیست و کسی هم از شما نمی خواهد.

یک حرف بی تعارف هم بزنیم: در بازار ایران معمولا نه مشتری این را از شما می خواهد نه رقیب رعایتش می کند، و بیشتر سایت های فارسی حتی یک بار با صفحه کلید امتحان نشده اند. نتیجه اش این است که رعایت کردنش هنوز یک تمایز است و نه یک حداقل. کاری که در ادامه می آید هم بیشترش یک بعدازظهر وقت می برد، نه یک پروژه.

کنتراست رنگ: کدام عدد کافی است؟

کنتراست نسبت روشنایی متن به پس زمینه است و با یک عدد بیان می شود، از ۱ به ۱ که یعنی نامرئی تا ۲۱ به ۱ که سیاه روی سفید است. WCAG برای متن معمولی دست کم ۴.۵ به ۱ می خواهد، برای متن درشت ۳ به ۱، و برای اجزای رابط مثل مرز یک فیلد ورودی یا آیکنی که معنا دارد هم ۳ به ۱.

مهم ترین چیز این بخش یک جمله است: رنگ به تنهایی کنتراست ندارد، جفت رنگ دارد. همان آبی که روی پس زمینه تیره تمیز خوانده می شود، وقتی خودش پس زمینه یک دکمه شود و متن سفید رویش بنشیند، ممکن است رد شود.

عددهای همین سایتی که می خوانید نمونه خوبی است. اینها را در ۵ سپتامبر ۲۰۲۶ از روی مقدارهای واقعی پالت حساب کرده ایم: متن اصلی روی پس زمینه ۱۷.۶ به ۱، متن دوم ۹.۲۵ به ۱، آبی وقتی رنگ متن است ۷.۳۲ به ۱ و متن کم رنگ تر ۶.۲۱ به ۱. حالا همان آبی در نقش پس زمینه: سفید رویش فقط ۲.۷۲ به ۱ است، یعنی رد شده. برای همین پالت ما دو آبی دارد نه یکی؛ آبی دوم تیره تر است و سفید رویش ۵.۱۷ به ۱ می شود و آبی اول برای متن و آیکن دست نخورده مانده.

چک کردنش ده ثانیه است. در ابزار توسعه دهنده مرورگر روی متن کلیک کنید، مقدار رنگ را باز کنید و نسبت کنتراست همان جا کنار انتخابگر رنگ نوشته شده است.

دو جایی که بیشترین ایراد کنتراست از آنجا می آید و هیچ کدام هم متن اصلی نیست: متن روی تصویر، که چون عکس در هر نقطه روشنایی متفاوتی دارد یک عدد ثابت ندارد و راه حلش یک لایه تیره زیر متن است؛ و متن راهنمای داخل فیلد فرم، که تقریبا همیشه کم رنگ ترین متن صفحه است و در اکثر طراحی ها رد می شود.

پنج دقیقه با صفحه کلید: سریع ترین تستی که می توانید بگیرید

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

چهار چیز را نگاه کنید:

• هر چیزی که با ماوس کلیک می شود، با Tab هم به آن می رسید؟ منوی کشویی، بستن مودال، تب ها، فیلترها.
• هر لحظه معلوم است کجا ایستاده اید؟ اگر حلقه focus را نمی بینید، تست همین جا شکست خورده.
• ترتیب حرکت با ترتیب دیده شدن یکی است؟ اگر Tab از تیتر پرید به فوتر و بعد برگشت وسط صفحه، جای عنصرها در HTML با جای دیدنشان فرق دارد.
• جایی گیر می کنید؟ کلاسیک ترین حالتش مودالی است که باز می شود و Esc نمی بندد و Tab هم از داخلش بیرون نمی آید.

پرتکرارترین ایراد این تست یک خط CSS است: outline: none که در ریست ها نوشته می شود چون حلقه پیش فرض مرورگر زشت است. حذفش کردن یعنی کسی که با صفحه کلید کار می کند دیگر نمی داند کجاست. راهش عوض کردن است نه پاک کردن. روی همین سایت یک قانون سراسری هست: :focus-visible با یک حلقه دو پیکسلی آبی و سه پیکسل فاصله از خود عنصر. کلمه focus-visible مهم است، چون کاربر ماوس با کلیک کردن حلقه نمی گیرد و کاربر صفحه کلید می گیرد.

یک عنصر هم هست که تقریبا هیچ سایت فارسی ندارد و ساختنش سه خط است: لینک پرش به محتوا. اولین چیزی است که با Tab می گیرید، تا وقتی focus نگرفته دیده نمی شود، و کسی را که با صفحه کلید می آید از رد شدن از کل منو نجات می دهد. در قالب همین سایت اولین عنصر داخل body همین لینک است.

متن جایگزین تصویر را چطور بنویسیم؟

متن جایگزین توصیف ظاهر تصویر نیست، توصیف کاری است که تصویر در آن صفحه می کند. همان عکس در دو صفحه دو متن جایگزین متفاوت دارد.

یک عکس از یک صندلی در صفحه محصول: «صندلی اداری مشکی با پشتی مش، از نمای سه رخ». همان عکس در یک مقاله درباره کمردرد: «حالت درست نشستن روی صندلی اداری». تصویری که فقط تزیین است و چیزی به معنی اضافه نمی کند، متن جایگزین خالی می گیرد، یعنی alt=""، تا صفحه خوان از رویش رد شود. خالی گذاشتن ویژگی alt با نبودنش فرق دارد: وقتی نباشد، بعضی صفحه خوان ها اسم فایل را می خوانند و IMG-20260415-WA0007.jpg چیزی است که هیچ کس لازم ندارد بشنود.

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

دو حالتی که همه فراموش می کنند: دکمه ای که فقط یک آیکن است، مثل ذره بین جستجو یا ضربدر بستن، هیچ متنی ندارد که خوانده شود و باید نامش را با aria-label بدهید؛ و نمودار یا اینفوگرافیک، که خلاصه اش در alt جا نمی شود و عددهایش باید در خود متن صفحه هم باشند.

روی همین سایت این مسئله شکل دیگری پیدا کرده. شکل های بالای این صفحه و بین بخش ها تصویر نیستند: HTML و CSS اند. یعنی متنشان متن واقعی است، صفحه خوان آن را می خواند، قابل انتخاب و ترجمه است، و تکه های تزیینی مثل خط ها و پیکان ها با aria-hidden از دید صفحه خوان پنهان شده اند. این تصمیم اولش برای سرعت گرفته شد و دسترس پذیری سود جانبی اش بود. درس سئوی داخلی همین موضوع را از سمت جستجو نگاه می کند.

چرا یک div هیچ وقت دکمه نیست؟

چون <button> چهار چیز را رایگان می دهد که <div onclick> هیچ کدام را ندارد: با Tab به آن می رسید، با Enter و Space فعال می شود، صفحه خوان می گوید «دکمه» و مرورگر خودش حالت غیرفعال و focus را می شناسد. برای رساندن یک div به همان جا باید tabindex و role و شنونده صفحه کلید بنویسید و آخرش هم چیزی دارید که فقط شبیه دکمه است.

همین منطق درباره بقیه HTML هم صادق است و کل ماجرای HTML معنایی همین است. برچسب فرم را با <label for> به فیلد وصل کنید تا کلیک روی متن، فوکوس را ببرد داخل فیلد و صفحه خوان بداند این فیلد چه می خواهد؛ متن راهنمای داخل فیلد جای برچسب را نمی گیرد، چون به محض تایپ ناپدید می شود. تیترها را به ترتیب بگذارید، از h1 به h2 و بعد h3، چون کسی که با صفحه خوان کار می کند اغلب اول فهرست تیترها را می شنود و از رویش تصمیم می گیرد کجا برود. منو را داخل <nav> و متن اصلی را داخل <main> بگذارید تا همان آدم بتواند مستقیم بپرد به محتوا. و فهرست را با <ul> بنویسید، چون صفحه خوان می گوید «فهرست، شش مورد» و این یک اطلاعات واقعی است که با چند div پشت سر هم از دست می رود.

این را در موتور شکل های همین سایت هم رعایت کرده ایم: ستون های شکل مقایسه ای، فهرست واقعی اند و نه چند پاراگراف پشت هم، دقیقا برای همین که خواننده بشنود چند بند دارد. درس HTML این عنصرها را یکی یکی نشان می دهد.

یک تله ARIA هم اینجا بگوییم چون در خروجی ابزارها زیاد دیده می شود: قاعده اول خود مشخصات ARIA این است که وقتی HTML عنصری برای آن کار دارد، ARIA ننویسید. role="button" روی یک div بدتر از <button> است، نه بهتر.

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

یکی از معیارهای WCAG می گوید رنگ نباید تنها راه انتقال یک اطلاعات باشد. رایج ترین جایی که این معیار می شکند، لینک داخل پاراگراف است: آبی روی مشکی، بدون هیچ نشانه دیگر. کسی که کوررنگی دارد، یا صفحه را زیر آفتاب می بیند، یا مانیتور ارزانی دارد که رنگ ها را نزدیک هم نشان می دهد، این لینک را نمی بیند. متن است، فقط با یک آبی که برای او آبی نیست.

جواب بدیهی، آندرلاین کردن همه لینک هاست و همان جواب یک مشکل دیگر می سازد: منو، دکمه، کارت، لوگو و شماره صفحه هم لینک اند و همه شان خط دار می شوند. صفحه شلوغ می شود و معمولا کسی که این را دیده، برمی گردد و آندرلاین را کلا برمی دارد.

راهی که روی همین سایت رفتیم و می توانید در سورس ببینید، چهار تصمیم است. اول، a به طور سراسری text-decoration: none دارد و فقط لینک های داخل متن یک کلاس جدا می گیرند. دوم، آندرلاین آن کلاس یک بک گراند گرادیانی به ضخامت ۱.۵ پیکسل است که در hover و در :focus-visible به ۲ پیکسل می رسد؛ یعنی کاربر صفحه کلید دقیقا همان بازخوردی را می گیرد که کاربر ماوس می گیرد. سوم، همان کلاس box-decoration-break: clone دارد، چون بدون آن لینکی که وسطش به خط بعد می افتد فقط زیر یک تکه اش خط می گیرد و تکه دوم لخت می ماند. چهارم، یک بلاک @media (forced-colors: active) هست که در حالت کنتراست اجباری ویندوز آندرلاین واقعی را برمی گرداند، چون آن حالت بک گراند تصویری را دور می ریزد و اگر فکرش را نکرده باشید، آندرلاین گرادیانی شما دقیقا برای کسی که بیشترین نیاز را به آن دارد ناپدید می شود.

مرز این کار را هم بگوییم: این چهار خط فقط لینک های داخل پاراگراف را درست می کند. لینکی که تصویر است، لینکی که فقط یک آیکن است و کارتی که کلش کلیک می شود، هیچ کدام از این راه حل بهره ای نمی برند و هر کدام باید نام قابل خواندن خودشان را داشته باشند.

از کجا بفهمیم واقعا درست شده؟

سه ابزار دارید و ترتیبشان مهم است. اول صفحه کلید، که هیچ چیز لازم ندارد و بیشترین ایراد را می گیرد. دوم ابزار توسعه دهنده مرورگر: هم نسبت کنتراست را نشان می دهد و هم درخت دسترس پذیری را، یعنی همان چیزی که صفحه خوان می بیند؛ اگر دکمه شما در آن درخت بدون نام ظاهر شد، همان جا جواب سوالتان را گرفته اید. سوم یک صفحه خوان واقعی: روی ویندوز NVDA رایگان است، روی مک و آیفون VoiceOver داخل سیستم است و روی اندروید TalkBack. ده دقیقه کار کردن با یکی از اینها بیشتر از هر مقاله ای موضوع را جا می اندازد.

ابزارهای خودکار مثل بخش دسترس پذیری Lighthouse هم مفیدند، ولی جایگاهشان را بدانید: قاعده های مکانیکی را چک می کنند. متن جایگزینی که نوشته «تصویر» از دیدشان قبول است. ترتیب focus را نمی سنجند. اینکه دکمه ای که اسمش «بیشتر» است اصلا معلوم نیست بیشتر چه چیزی، از دستشان درمی رود. نمره صد گرفتن یعنی ایرادهای مکانیکی ندارید، نه اینکه صفحه قابل استفاده است.

یک نکته درباره افزونه های نوار دسترس پذیری، همان جعبه های شناوری که وعده می دهند سایت را با یک خط کد قابل دسترس کنند: چیزی که در HTML شما اشتباه است، با یک لایه روی صفحه درست نمی شود. دیوی که دکمه نیست، بعد از نصب آن افزونه هم دکمه نیست. ما هیچ محصول مشخصی را تست نکرده ایم و اسمی هم نمی بریم؛ فقط این را می گوییم که مسیر درست، عوض کردن خود مارک آپ است.