در سال ۲۰۲۵، شاکیان ۳،۱۱۷ شکایت مربوط به دسترسپذیری وبسایت را بر اساس عنوان سوم قانون ADA در دادگاههای فدرال ثبت کردند — که افزایشی ۲۷ درصدی نسبت به سال ۲۰۲۴ و بالاترین آمار سالانه از سال ۲۰۲۲ تاکنون محسوب میشود. با احتساب پروندههای دادگاههای ایالتی، این رقم به بیش از ۵،۰۰۰ مورد میرسد. حتی این رقمهای تیتروار هم تمام فشار موجود را نشان نمیدهند: وکلای مدافع تخمین میزنند که سال گذشته بین ۳۵،۰۰۰ تا ۵۰،۰۰۰ نامه اخطار دسترسپذیری برای کسبوکارهای آمریکایی ارسال شده است که اکثر آنها به صورت خصوصی با مبالغی بین ۱،۰۰۰ تا ۲۵،۰۰۰ دلار تسویه شدهاند، بدون اینکه هرگز در پروندههای قضایی ثبت شوند.
اگر کسبوکار شما دارای وبسایت، اپلیکیشن موبایل، فروشگاه آنلاین، ویجت رزرو یا پورتال مشتریان است، اکنون یک هدف بالقوه محسوب میشوید. و شاکیان زنجیرهای دیگر محدود به گروه کوچکی از ثبتکنندگان مکرر نیستند — حدود ۴۰ درصد از شکایات عنوان سوم ADA فدرال در سال ۲۰۲۵ توسط افرادی مطرح شده که خودشان نمایندگی حقوقیشان را بر عهده داشتند و بسیاری از آنها از اسکنرهای مبتنی بر هوش مصنوعی برای شناسایی متهمان احتمالی و تنظیم دادخواست در عرض چند دقیقه استفاده میکنند.
این راهنما به بررسی آنچه عنوان سوم ADA واقعاً برای تجربههای دیجیتال الزامی میکند، چرایی تبدیل شدن سطح AA استاندارد WCAG 2.1 به معیار عملی، نقشه راه اصلاحات چگونه است، و چگونگی ایجاد یک سابقه قابل دفاع قبل از رسیدن نامه اخطار میپردازد.
چرا وبسایت شما اکنون در محدوده عنوان سوم ADA قرار میگیرد
عنوان سوم «قانون آمریکاییهای دارای ناتوانی» (ADA) تبعیض بر اساس ناتوانی را در اماکن خدمات عمومی ممنوع میکند. این قانون در سال ۱۹۹۰ نوشته شد و هرگز به صراحت به وبسایتها یا اپلیکیشنهای موبایل اشاره نکرد — اما دادگاهها دهه گذشته را صرف رفع این ابهام کردهاند و تقریباً همیشه به نفع شاکیان رای دادهاند.
میراث پرونده Robles v. Domino's Pizza
مهمترین پرونده واحد، Robles v. Domino's Pizza است. گیلرمو روبلز، یک شاکی نابینا در کالیفرنیا، در سال ۲۰۱۶ از دومینوز شکایت کرد، پس از آنکه متوجه شد نمیتواند از وبسایت یا اپلیکیشن موبایل این زنجیره پیتزا با صفحهخوان استفاده کند. دادگاه منطقهای ابتدا پرونده را به دلیل رعایت تشریفات قانونی رد کرد، با این استدلال که بدون مقررات منتشر شده دسترسپذیری وب، دومینوز اطلاع درستی از الزامات انطباق نداشته است.
دادگاه تجدیدنظر حوزه نهم این حکم را در سال ۲۰۱۹ نقض کرد. دادگاه اعلام کرد که عنوان سوم شامل وبسایت و اپلیکیشن دومینوز میشود زیرا آنها با یک مکان فیزیکی خدمات عمومی (رستورانهای پیتزا) پیوند داشتند و اعمال مسئولیت حقوقی، حتی بدون استانداردهای فنی منتشر شده، نقض تشریفات قانونی نیست. دیوان عالی در اواخر همان سال از بررسی حکم حوزه نهم خودداری کرد و این قاعده را پابرجا گذاشت. دومینوز در نهایت در ژوئن ۲۰۲۲ پس از شش سال دعوای حقوقی، مصالحه کرد.
اثر عملی این است که هر کسبوکاری با مکان فیزیکی — و در بسیاری از حوزههای قضایی، حتی کسبوکارهای صرفاً آنلاین — اکنون با ریسک واقعی برای یک وبسایت غیرقابل دسترس روبرو است.
قانون عنوان دوم سال ۲۰۲۴ وزارت دادگستری (DOJ) و تأثیرات جانبی آن بر عنوان سوم
در آوریل ۲۰۲۴، وزارت دادگستری قانون نهایی را تحت عنوان دوم ADA صادر کرد که وبسایتها و اپلیکیشنهای موبایل دولتهای ایالتی و محلی را ملزم به انطباق با سطح AA استاندارد WCAG 2.1 میکند. اگرچه این قانون رسماً تنها نهادهای دولتی را متعهد میکند، شاکیان و دادگاهها بلافاصله شروع به استناد به آن به عنوان معتبرترین بیان فدرال از معنای «دسترسپذیر» کردند.
برای یک کسبوکار خصوصی، محاسبات قانونی یکشبه تغییر کرد. حتی اگر عنوان سوم هنوز استاندارد فنی منتشر شدهای نداشته باشد، یک شاکی اکنون میتواند به یک مقررات فدرال الزامآور اشاره کند که WCAG 2.1 Level AA را به عنوان استاندارد برای نهادهای مشابه در عنوان دوم نام میبرد. اکثر وکلای مدافع اکنون به موکلان خود در حوزه عنوان سوم توصیه میکنند که سطح AA استاندارد WCAG 2.1 را به عنوان حداقل کف در نظر بگیرند.
سطح AA استاندارد WCAG 2.1 واقعاً چه الزاماتی دارد
استاندارد WCAG — دستورالعملهای دسترسپذیری محتوای وب که توسط کنسرسیوم وب جهانی نگهداری میشود — حول چهار اصل سازماندهی شده است که به اختصار POUR نامیده میشوند: قابل درک (Perceivable)، قابل اجرا (Operable)، قابل فهم (Understandable) و استوار (Robust). سطح AA شامل تمام معیارهای موفقیت سطح A به علاوه معیارهای اختصاصی AA است. در مجموع ۵۰ معیار موفقیت در سطح AA وجود دارد، اما تعداد کمی از آنها عامل اکثریت قاطع نامههای اخطار هستند.
تضاد رنگ (۱.۴.۳ و ۱.۴.۱۱)
متن بدنه باید نسبت تضاد حداقل ۴.۵:۱ نسبت به پسزمینه خود داشته باشد. متنهای بزرگ (۱۸ پوینت یا ۱۴ پوینت ضخیم) به حداقل ۳:۱ نیاز دارند. دکمهها، حاشیههای فیلد فرم، نشانگرهای فوکوس و سایر عناصر گرافیکی تعاملی باید نسبت ۳:۱ را در برابر رنگهای مجاور رعایت کنند. بسیاری از نامههای اخطار از اینجا ناشی میشوند زیرا اسکنرهای خودکار خرابیهای تضاد رنگ را در چند ثانیه شناسایی میکنند.
جایگزینهای متنی برای محتوای غیرمتنی (۱.۱.۱)
هر تصویر، آیکون، نمودار، عکس و گرافیکی که حامل معناست، به یک صفت alt (متن جایگزین) نیاز دارد که همان اطلاعات را منتقل کند. تصاویر تزئینی صفت alt خالی (alt="") دریافت میکنند تا صفحهخوانها از آنها عبور کنند. لوگوها باید برند را توصیف کنند. نمودارها و اینفوگرافیکها به معادل متنی طولانیتری در نزدیکی یا به صورت لینک شده نیاز دارند. آیکونهای ورودی فرم به برچسب نیاز دارند. کپچاها به یک جایگزین صوتی نیاز دارند.
قابلیت عملیاتی با صفحهکلید (۲.۱.۱، ۲.۱.۲، ۲.۴.۳، ۲.۴.۷)
هر عنصر تعاملی — منوها، مودالها، کاروسلها، آکاردئونها، تبها، لیستهای کشویی سفارشی — باید تنها با استفاده از صفحهکلید قابل دسترسی و اجرا باشد. کاربران هرگز نباید در یک ویجت بدون راه خروجی گرفتار شوند (خطای کلاسیک «مودالی که بدون ماوس بسته نمیشود»). ترتیب فوکوس باید منطقی باشد و یک نشانگر فوکوس مرئی باید همیشه نشان دهد که کاربر در کجای صفحه قرار دارد.
برچسبهای فرم، خطاها و دستورالعملها (۱.۳.۱، ۳.۳.۱، ۳.۳.۲، ۳.۳.۳، ۳.۳.۴)
هر فیلد ورودی فرم به یک برچسب مرتبط از طریق برنامهنویسی (یک عنصر <label for=""> یا aria-label) نیاز دارد. پیامهای خطا باید مشخص کنند که کدام فیلد با خطا مواجه شده و برای رفع آن چه باید کرد. برای فرمهای حساس (تسویهحساب، ایجاد حساب کاربری، تاییدیه حقوقی)، کاربران به فرصتی برای بررسی و اصلاح قبل از ارسال نهایی نیاز دارند.
زیرنویسها و توضیحات صوتی (۱.۲.۲، ۱.۲.۵)
ویدیوهای ضبطشده به زیرنویسهای همگامسازی شده نیاز دارند. اگر اطلاعات ضروری به صورت بصری منتقل میشود و در مسیر صوتی وجود ندارد، به توضیحات صوتی نیز نیاز دارید. ویدیوهای زنده در سطح AA به زیرنویس زنده نیاز دارند.
ساختار سرفصلها و لندمارکها (۱.۳.۱، ۲.۴.۶)
سرفصلها (Headings) باید از یک سلسلهمراتب منطقی پیروی کنند (h1 ← h2 ← h3؛ بدون پرشهای خودسرانه از سطوح). از عناصر معنایی HTML — مانند <nav>، <main>، <header>، <footer> — یا لندمارکهای ARIA استفاده کنید تا کاربران صفحهخوان بتوانند به بخش مورد نظر خود بپرند. از استایلدهی به یک <div> برای شبیهسازی سرفصل بدون دادن نقش معنایی درست به آن خودداری کنید.
تغییر اندازه و بازآرایی (۱.۴.۴، ۱.۴.۱۰)
متن باید در زوم ۲۰۰ درصد بدون نیاز به اسکرول افقی خوانا بماند. چیدمانها باید در درگاه نمایش ۳۲۰ پیکسل CSS، بدون اسکرول دوبعدی بازآرایی (Reflow) شوند.
تمرکز دعاوی حقوقی در کجاست
بخش عمدهای از پروندههای مربوط به دسترسیپذیری وبسایتها در سه حوزه قضایی فدرال متمرکز شده است: حوزه قضایی جنوبی نیویورک، حوزه قضایی مرکزی کالیفرنیا و حوزه قضایی جنوبی فلوریدا. نیویورک با فاصله زیادی پیشتاز است، بخشی به این دلیل که قانون حقوق بشر ایالت نیویورک و قانون حقوق بشر شهر نیویورک، ابزارهای قانونی ایالتی اضافی و شرایط اثبات آسانتری را نسبت به شکایات فدرال ADA فراهم میکنند.
کالیفرنیا قانون حقوق مدنی آنرو (Unruh) را به این مجموعه اضافه میکند که به ازای هر تخلف برای هر شاکی، ۴,۰۰۰ دلار خسارت قانونی در نظر میگیرد. این موضوع محاسبات مربوط به مصالحه را به طرز چشمگیری تغییر میدهد — یک ادعای کوچک در صورت تأیید به عنوان دعوای گروهی (Class Action)، میتواند به سرعت به یک خسارت ششرقمی تبدیل شود.
فلوریدا از سال ۲۰۲۰ به عنوان سومین قطب ظاهر شده است و تعدادی از شرکتهای حقوقی شاکی، رویههای پرحجمی را علیه رستورانهای زنجیرهای، برندهای مهماننوازی و فروشگاههای تجارت الکترونیک مستقیم به مصرفکننده ایجاد کردهاند.
تدوین نقشه راه اصلاح و بازسازی
اگر اخطاریه قانونی دریافت کردید — یا بهتر از آن، اگر قبل از رسیدن اخطاریه اقدام کردید — کار به حدوداً پنج فاز تقسیم میشود. با این کار به عنوان یک پروژه با بودجه و ضربالاجل مشخص برخورد کنید، نه یک ممیزی یکباره.
فاز ۱: ممیزی خودکار و دستی
با یک اسکن خودکار با استفاده از ابزارهایی مانند axe DevTools، WAVE یا Google Lighthouse شروع کنید. ابزارهای خودکار چیزی بین ۳۰ تا ۵۰ درصد از نقصهای WCAG را شناسایی میکنند — بقیه موارد مستلزم تست دستی با صفحهخوان (NVDA در ویندوز، VoiceOver در macOS و iOS، TalkBack در اندروید)، ناوبری فقط با صفحهکلید، و تستهای تغییر اندازه و بازآرایی هستند.
هر نقص را با ذکر معیار WCAG نقض شده، صفحه یا قالب آسیبدیده، شدت آن و تخمین تلاش لازم برای اصلاح مستند کنید. این گزارش ممیزی به ستون فقرات هر فاز بعدی تبدیل میشود.
فاز ۲: اصلاحات سیستم طراحی و کامپوننتها
بسیاری از پرتکرارترین نقصها در سیستم طراحی شما قرار دارند: تضاد رنگ دکمهها، نشانگرهای فوکوس، ورودیهای فرم، الگوهای مودال، کنترلهای کاروسل و منوهای ناوبری. یکبار اصلاح کامپوننت، تمامی نمونههای آن را در کل سایت اصلاح میکند. کامپوننتهایی را که در بیشترین صفحات ظاهر میشوند در اولویت قرار دهید.
فاز ۳: پاکسازی محتوا
متن جایگزین تصاویر (Alt text)، زیرنویس ویدیوها، ساختار سرفصلها و برچسبهای فرم معمولاً اصلاحاتی در سطح محتوا هستند که اکثر قالبها و صفحات را تحت تأثیر قرار میدهند. یک چکلیست محتوا ایجاد کنید که نویسندگان باید برای هر صفحه جدید رعایت کنند و یک لیست از کارهای عقبمانده برای اصلاح بازگشتی صفحات موجود تنظیم کنید.
فاز ۴: هماهنگی با تامینکنندگان شخص ثالث
اکثر وبسایتهای مدرن از ویجتهای شخص ثالث استفاده میکنند: فرمهای پرداخت، چت زنده، تقویمهای رزرو، پخشکنندههای ویدیو، اورلیهای تحلیلی، ویجتهای نظرات و پاپآپهای دریافت ایمیل. هر یک از اینها میتواند نقصهای دسترسیپذیری خاص خود را داشته باشد و دادگاههای مربوط به Title III عموماً کسبوکار را مسئول دسترسیپذیری کدهای تامینکنندهای میدانند که در سایت خود جایگذاری کرده است.
از هر تامینکننده، نسخه فعلی VPAT (الگوی داوطلبانه دسترسیپذیری محصول) یا گزارش انطباق دسترسیپذیری را درخواست کنید. بررسی کنید که نسخه ارائهشده با سطح AA استاندارد WCAG 2.1 مطابقت داشته باشد. تامینکنندگانی که ضعیف عمل میکنند را برای اصلاح تحت فشار بگذارید یا آنها را جایگزین کنید.
فاز ۵: بیانیه دسترسیپذیری و کانال بازخورد
یک بیانیه دسترسیپذیری با لینک واضح منتشر کنید که استانداردی را که هدف گرفتهاید (معمولاً WCAG 2.1 Level AA)، محدودیتهای شناخته شده و یک کانال تماس (ایمیل و تلفن) برای کاربران جهت گزارش مشکلات دسترسیپذیری نام ببرد. این بیانیه مصونیت قانونی ایجاد نمیکند، اما حسن نیت شما را مستند کرده و به پاسخدهندگان به اخطاریههای قانونی، مورد ملموسی برای ارائه میدهد.
سخنی درباره افزونههای دسترسیپذیری (Accessibility Overlays)
صنعت رو به رشد ابزارهای «افزونه دسترسیپذیری» — ویجتهای جاوااسکریپتی که وعده انطباق فوری با استاندارد WCAG را تنها با یک خط کد میدهند — مدعی است که دسترسیپذیری را سریع و ارزان حل میکند. واقعیت پیچیدهتر است. از این افزونهها در دهها پرونده قضایی به عنوان عاملی یاد شده که خود باعث ایجاد مشکلات دسترسیپذیری میشوند، چرا که در فناوریهای کمکی کاربران اختلال ایجاد میکنند. چندین دادگاه این استدلال را که یک افزونه به تنهایی برای رد ادعای مربوط به «فصل سوم» (Title III) کافی است، رد کردهاند.
افزونهها ممکن است به عنوان مکمل اصلاحات زیربنایی — برای کاربرانی که نیاز دارند تنظیمات شخصی خود را روی سایتی که از قبل دسترسیپذیر است اعمال کنند — نقشی داشته باشند، اما جایگزینی برای اصلاح کدهای زیرساختی نیستند. موسسات حقوقیِ شاکی، اکنون بهطور خاص سایتهایی را هدف قرار میدهند که از محصولات افزونه خاصی استفاده میکنند.
مستندسازی همهچیز برای دفاع حقوقی
زمانی که یک اظهارنامه حقوقی (demand letter) به دستتان میرسد، استراتژی دفاعی شما تقریباً بهطور کامل به آنچه میتوانید درباره برنامه دسترسیپذیری خود در زمان وقوع تخلف ادعایی اثبات کنید، بستگی دارد. مجموعهای از مستندات ایجاد کنید که شامل موارد زیر باشد:
- گزارشهای ارزیابی تاریخدار که محدوده و یافتهها را نشان میدهد
- تیکتهای اصلاحی همراه با تاریخ بسته شدن
- گزارشهای VPAT و گزارشهای انطباق با دسترسیپذیریِ فروشندگان
- سوابق آموزشی برای طراحان و توسعهدهندگان
- چکلیستهای داخلی بررسی دسترسیپذیری که به عرضه محصولات مرتبط است
- گزارش تغییرات (change log) برای بیانیه دسترسیپذیری
- بازخوردهای کاربران که از طریق کانال ارتباطی دسترسیپذیری شما دریافت شده و پاسخهای شما به آنها
این سوابق مانع از شکایت نمیشوند، اما مذاکرات برای تسویه را بهطور قابل توجهی تغییر میدهند. شاکیای که به امید یک تسویه ۱۰,۰۰۰ دلاری سریع برای رفع مزاحمت است، وقتی ببیند مدعیعلیه میتواند یک ارزیابی بهروز، لیست کارهای اصلاحی مستند شده و یک VPAT برای هر ویجت جانبی ارائه دهد، تمایل بسیار کمتری نشان خواهد داد.
جنبه حسابداریِ انطباق با دسترسیپذیری
اصلاح دسترسیپذیری بهندرت یک هزینه یکباره است. این موضوع معمولاً در دفاتر مالی شما به عنوان هزینههای مکرر ظاهر میشود — صورتحسابهای آژانسها یا پیمانکاران برای ارزیابی، لایسنس نرمافزارهای ابزارهای تست و خدمات نظارتی، هزینههای بازسازی سیستم طراحی، هزینههای تغییر فروشنده و مبالغ اجتنابناپذیر تسویه اظهارنامهها که علیرغم بهترین تلاشهای شما به وقوع میپیوندند.
رهگیری این هزینهها بهصورت مجزا از هزینههای عمومی بازاریابی یا مهندسی، چند کار را آسانتر میکند. شما دید شفافی از هزینه واقعی انطباق در طول زمان به دست میآورید که به بودجهبندی برنامه سال آینده کمک میکند. همچنین اگر بعداً نیاز داشته باشید هزینهای را کسر کنید یا استهلاکِ بهبود سرمایهای وبسایت را محاسبه کنید، مخارج را مستند کردهاید. و اگر زمانی با یک دعوای حقوقی گروهی (class action) مواجه شدید، میتوانید به سرعت سابقه مالی سرمایهگذاری با حسن نیت خود را در زمینه دسترسیپذیری ارائه دهید؛ این کار هم در مذاکرات تسویه و هم در دفاعیه «اصلاح معقول» مفید است.
ایجاد یک بخش ساده در فهرست حسابها (chart of accounts) برای «انطباق با دسترسیپذیری» با زیرمجموعههایی برای ارزیابیها، نیروی کار اصلاحی، ابزارهای تست، بررسی فروشندگان و ذخایر تسویه، کمک شایانی میکند. این کار را با بررسیهای فصلی همراه کنید تا برنامه دسترسیپذیری به آرامی از بودجه خارج نشود.
اشتباهات رایجی که باید از آنها اجتناب کرد
الگوهای معدودی وجود دارند که تقریباً در تمام اظهارنامههای حقوقی که صاحبان کسبوکار دریافت میکنند، دیده میشوند.
تلقی دسترسیپذیری به عنوان یک پروژه یکباره. سایتها مدام تغییر میکنند. یک صفحه محصول جدید، بازطراحی صفحه پرداخت یا یک چتبات جانبی؛ هر یک از اینها میتواند مشکلات جدیدی ایجاد کند. دسترسیپذیری را در چرخه حیات توسعه خود بگنجانید تا هر تغییر قبل از انتشار بررسی شود.
اتکای کامل به اسکنهای خودکار. ابزارهای خودکار تنها بخش کوچکی از خطاهای WCAG را شناسایی میکنند. تست دستی با فناوریهای کمکی تنها راه برای یافتن مشکلاتی مانند ترتیب فوکوس غیرمنطقی، متن جایگزین (alt text) گمراهکننده یا ویجتهای سفارشی غیرقابل استفاده است.
نادیده گرفتن اپلیکیشنهای موبایل. شاکیان فصل سوم بهطور فزایندهای شکایتهای دوگانهای را مطرح میکنند که هم وبسایت و هم اپلیکیشن موبایل را شامل میشود. iOS و Android هر کدام APIهای دسترسیپذیری خود را دارند (UIAccessibility و TalkBack/AccessibilityService) و همان اصول WCAG در آنجا نیز صدق میکند اما نیاز به تستهای پلتفرممحور دارد.
فراموش کردن فایلهای PDF. فرمهای مالیاتی، مقالات سفید، منوها و منابع قابل دانلودی که در سایت شما میزبانی میشوند، همگی در محدوده بررسی هستند. فایلهای PDF درست مانند صفحات HTML به ترتیب خواندن صحیح، تگها، متن جایگزین و برچسب فیلدهای فرم نیاز دارند.
فرض اینکه پلتفرمهای شخص ثالث کار را برای شما انجام میدهند. Shopify، WordPress، Wix، Squarespace و پلتفرمهای مشابه، برخی زیرساختهای دسترسیپذیری را فراهم میکنند، اما انتخاب قالب، کدهای سفارشی، ویجتهای جانبی و محتوایی که منتشر میکنید همچنان بر عهده شماست. در اظهارنامه حقوقی اهمیتی ندارد که یک قالب از پیش ساخته شده بوده است یا خیر.
نادیده گرفتن بیانیه دسترسیپذیری. انتشار آن هزینهای ندارد و شواهدی عینی از حسن نیت شما ارائه میدهد. نبود این بیانیه گاهی بهطور خاص در شکایتها ذکر میشود.
امور مالیِ انطباق خود را از روز اول سازماندهی کنید
همانطور که برنامه دسترسیپذیری خود را میسازید، سوابق مالی پشتیبان — صورتحسابهای ارزیابی، قراردادهای فروشندگان، نیروی کار اصلاحی، هزینههای آموزش و ذخایر تسویه — باید در جایی باشند که سالها بعد، اگر یک شاکی سریالی نام کسبوکار شما را برد، بتوانید آنها را پیدا کنید. Beancount.io حسابداری متنسادهای را ارائه میدهد که به شما شفافیت کامل و تاریخچهای کنترلشده با نسخه (version-controlled) از هر ردیف بودجه میدهد، بدون هیچ جعبه سیاه یا وابستگی به فروشنده. بهطور رایگان شروع کنید و ببینید چرا توسعهدهندگان، تیمهای مالی و مدیران آگاه به مسائل انطباق، حسابداری متنساده را برای نگهداری سوابق قابل دفاع در حسابرسی انتخاب میکنند.