بودجه دسترسی‌پذیری وب؛ WCAG ۲.۲، هزینه و ROI

یک فروشگاه گزارش سبز ابزار خودکار دارد، اما کاربر کیبوردی نمی‌تواند Modal انتخاب آدرس را ببندد و مشتری Screen reader مبلغ نهایی را نمی‌شنود. سازمان برای «اسکن دسترسی‌پذیری» پول داده، نه برای دسترسی‌پذیرشدن Journey خرید. بودجه درست باید مانع، فرایند، مالک و نتیجه را پوشش دهد؛ نه تعداد Errorهای یک Dashboard را.

هزینه دسترسی‌پذیری وب عدد ثابت به‌ازای صفحه نیست. به تنوع Template و Component، پیچیدگی State، حجم Media/Document، فناوری و Vendor، بدهی قدیمی، مهارت تیم و سطح شواهد موردنیاز بستگی دارد. این راهنما روش ساخت Budget و Program را از Scope تا Audit، Remediation، Training، Procurement و Monitoring توضیح می‌دهد.

WCAG ۲.۲ چیست و بودجه باید به چه هدفی وصل شود؟

WCAG ۲.۲ استاندارد فنی W3C برای دسترسی‌پذیری محتوای وب است. اصول آن Perceivable، Operable، Understandable و Robust هستند و Success Criterionهای آزمون‌پذیر در سطوح A، AA و AAA دارد. W3C استفاده از تازه‌ترین نسخه WCAG ۲ را تشویق می‌کند.

هدف را دقیق بنویسید:

Standard/version: WCAG 2.2
Target: Level AA + selected AAA criteria where useful
Scope: public web + checkout + account + help + documents
Platforms: responsive web/PWA; supported browsers/AT
Deadline/milestones: critical journeys first
Evidence: automated + expert manual + user evaluation
Exceptions: owner, reason, equivalent path, expiry
Legal review: jurisdiction/service/contract specific
Reporting: baseline, barriers fixed, residual risk, statement

Level AA یعنی همه معیارهای A و AA قابل‌اعمال باید برآورده شوند؛ مجموعه دلخواهی از چند معیار «AA» نیست. W3C نیز AAA را سیاست عمومی برای کل سایت توصیه نمی‌کند، چون برای برخی محتوا برآورده‌کردن همه معیارهای AAA ممکن نیست.

WCAG استاندارد فنی است، نه پاسخ حقوقی جهانی

قانون، دامنه خدمات، قراردادهای دولتی/سازمانی و استاندارد مرجع در کشورها متفاوت است و تغییر می‌کند. W3C مرجع حقوقی کشور شما نیست. بنابراین:

• نسخه و سطح WCAG را با الزام قانونی/قراردادی واقعی تطبیق دهید؛
• برای ایران، بازار خارجی، بخش عمومی، آموزش، سلامت یا مالی Review حقوقی جدا بگیرید؛
• «هیچ شکایتی نداریم» را اثبات دسترسی یا انطباق ندانید؛
• Accessibility statement را صادقانه و Scopeدار بنویسید، نه Claim مطلق؛
• Exception و Third-party barrier را ثبت، کاهش و زمان‌بندی کنید.

این مقاله مشاوره حقوقی نیست؛ Budget باید یک ردیف برای پایش استاندارد/قانون/تعهد قرارداد داشته باشد.

چرا Page count برای برآورد هزینه کافی نیست؟

هزار صفحه مبتنی بر پنج Template ممکن است ارزان‌تر از یک Web app با ۳۰ Component پیچیده باشد. واحدهای واقعی کار:

Inventory را با Usage و Risk وزن دهید. Checkout پرتکرار با مانع کامل، پیش از صفحه آرشیوی کم‌ترافیک اصلاح می‌شود؛ ولی Scope conformance و تعهد قانونی را بی‌دلیل کوچک نکنید.

فرمول برآورد: WBS به‌جای قیمت حدسی

قیمت دلاری ثابت برای بازار، نرخ تخصص، Scope و کیفیت شواهد مختلف بی‌معنی است. Work Breakdown Structure بسازید:

Total budget =
  discovery/inventory
  + audit(sample × methods × states × platforms)
  + design/content/code remediation
  + component-system fixes
  + document/media remediation
  + user evaluation and participant support
  + training/process/procurement
  + tooling/AT/device lab
  + independent verification
  + monitoring/feedback response
  + contingency and program management

Workstream cost = estimated hours × loaded role rate
                  + vendor/tool/participant/direct costs

Loaded rate فقط حقوق نیست؛ مدیریت، QA، جلسه، تجهیزات، مالیات/قرارداد و سربار را طبق مدل مالی سازمان وارد کنید. برای روش ساخت Estimate و Quote هم‌سطح، راهنمای برآورد هزینه طراحی سایت مفید است.

ده سبد اصلی بودجه دسترسی‌پذیری

بودجه‌ای که فقط Audit دارد، Findings تولید می‌کند؛ بودجه‌ای که فقط Remediation دارد، ممکن است Barrier جدید بسازد. Program به هر دو و سازوکار جلوگیری نیاز دارد.

Baseline را با نمونه نماینده بسازید

برای سایت بزرگ، ابتدا Sample نماینده براساس WCAG-EM و Risk انتخاب می‌شود: صفحه‌های مشترک، Templateها، Journeyهای کامل، فناوری‌های متفاوت و نمونه تصادفی. صفحه Home به‌تنهایی نماینده Checkout یا Editor نیست.

Baseline report باید داشته باشد:

• Scope، نسخه، تاریخ، Environment و Method؛
• URL/Component/State/Success Criterion؛
• Steps to reproduce و شواهد؛
• اثر بر User/Task و Workaround؛
• Severity، Frequency، Ownership و Dependency؛
• پیشنهاد اصلاح و Acceptance test؛
• محدودیت نمونه و چیزی که آزموده نشده است.

روش اجرایی Audit، Keyboard، Screen reader و Remediation در راهنمای ممیزی و تست WCAG مالک Intent تخصصی است.

ابزار خودکار لازم است، اما Conformance صادر نمی‌کند

W3C صریح می‌گوید هیچ ابزار واحدی نمی‌تواند تعیین کند سایت استاندارد را برآورده کرده است؛ ارزیابی انسانی آگاه لازم است. درصد ثابت «ابزار ۲۰ یا ۳۰٪ مشکلات را می‌یابد» نیز بدون Benchmark، Scope و Rule set معتبر نیست.

Overlay یا Widget ممکن است قابلیت محدودی اضافه کند، اما جای اصلاح Source، ارزیابی انسانی و مسئولیت سازمان را نمی‌گیرد. خرید ابزار را با کاهش Barrier و Coverage QA بسنجید، نه تعداد Badge.

کاربران دارای معلولیت را با روش درست درگیر کنید

W3C توصیه می‌کند User evaluation با ارزیابی استاندارد ترکیب شود. یک کاربر نابینا نماینده همه نابینایان یا افراد با سایر معلولیت‌ها نیست. Budget شامل جذب منصفانه، جبران زمان، دسترسی جلسه، فناوری کمکی و تحلیل باشد.

Study scope: checkout + refund request
Participants: varied vision/motor/cognitive/hearing needs
Technology/context: participant-preferred AT/device
Tasks: realistic, no coaching
Measures: completion, critical error, recovery, confidence
Safeguards: consent, privacy, accessible materials
Report: sample limits + barriers + WCAG mapping + priority

Research با افراد، Audit را جایگزین نمی‌کند؛ به Finding معنا و اولویت می‌دهد.

اولویت‌بندی: Severity را از Count جدا کنید

هزار هشدار Alt روی تصاویر تزئینی ممکن است از یک Focus trap در پرداخت کم‌خطرتر باشد. Score پیشنهادی:

Severity، Effort و Dependency را جدا نگه دارید. «اصلاح سخت است» شدت Barrier را کم نمی‌کند؛ فقط Sequencing را تغییر می‌دهد.

Design System بزرگ‌ترین اهرم هزینه است

اگر Button، Input، Dialog، Tabs و Error summary در Library درست شوند، ده‌ها Product از آن بهره می‌برند. اما Component «دسترس‌پذیر» بدون Usage contract کافی نیست.

• Token: contrast، focus، spacing، target size، motion؛
• Semantic contract: element، name، role، state، description؛
• Keyboard: keys، order، escape، focus return؛
• States: error/loading/disabled/success/empty؛
• Content: label، instruction، alternative و localization؛
• Test: unit/DOM/automated/manual/story/user evidence؛
• Version/migration: breaking change، adoption و deprecation.

برای معماری Token/Component/Governance، راهنمای سیستم طراحی را در Workstream لحاظ کنید.

محتوا، Media و Document بدهی جدا دارند

کد سالم، PDF اسکن‌شده یا ویدئوی بدون Caption را دسترس‌پذیر نمی‌کند. Inventory محتوا باید Owner، حجم، Usage، عمر، Risk و گزینه Fix/Replace/Retire داشته باشد.

برای Image/Podcast/Infographic و جایگزین‌ها، راهنمای محتوای غیرمتنی مکمل است. همپوشانی با SEO ممکن است وجود داشته باشد، اما دسترسی‌پذیری را تاکتیک رتبه‌گیری تقلیل ندهید.

CMS و Authoring tool باید مانع ایجاد Barrier شوند

ویراستار اگر Heading level را فقط با ظاهر، Alt را با Filename یا Link را با «اینجا کلیک کنید» تولید کند، بدهی بازمی‌گردد. ATAG دو موضوع را پوشش می‌دهد: خود ابزار برای Author دارای معلولیت قابل‌استفاده باشد و ابزار تولید محتوای دسترس‌پذیر را پشتیبانی/ترویج کند.

برای Procurement یا توسعه CMS بررسی کنید:

• Template accessible و Semantic block؛
• Prompt و Validation بدون Auto-alt بی‌معنا؛
• Caption/transcript/document fields؛
• Preview با keyboard/AT و RTL؛
• Lint و گزارش قابل‌اقدام برای Author؛
• حفظ Metadata هنگام تبدیل/مهاجرت؛
• دسترسی خود پنل مدیریت.

آموزش را Role-based و مبتنی بر خروجی بودجه‌بندی کنید

یک Webinar عمومی رفتار Delivery را تغییر نمی‌دهد. مسیرها متفاوت‌اند:

هزینه طراحی Portfolio آموزشی و Transfer را با راهنمای بودجه آموزش تیم وب هم‌تراز کنید.

Vendor و Third-party را از Scope حذف نکنید

درگاه، CAPTCHA، Chat، Calendar یا Video player بخشی از تجربه کاربر است. قرارداد خرید باید Current evidence، Scope/version/date، Known gaps، Remediation SLA، Change notice، Support و Exit/fallback داشته باشد.

Procurement gate:
- critical user journey demonstrated with keyboard and supported AT
- current conformance/evaluation evidence reviewed
- roadmap is not accepted as current capability
- defects have owner, severity and SLA
- updates cannot bypass acceptance regression
- equivalent fallback and exit are tested

یک PDF بازاریابی Vendor یا VPAT/ACR بدون Review محصول و نسخه، Acceptance نیست.

Regression را در Definition of Done قرار دهید

Shift-left یعنی جلوگیری، نه حذف Manual test. سه لایه:

1. PR/Component: semantic assertions، automated rules، keyboard unit و Story؛
2. Preview/Release: Journey دستی، zoom/reflow، Screen reader نمونه و Content check؛
3. Production: synthetic/monitoring، feedback، sampled expert review و periodic user evaluation.

False positive/negative، Rule coverage و Exception expiry ثبت شوند. Dashboard باید Regression escape را کم کند، نه اینکه تیم را با Count خام تنبیه کند.

بیانیه دسترسی و کانال بازخورد بخشی از محصول‌اند

Accessibility statement صادقانه شامل هدف استاندارد، Scope، روش ارزیابی، محدودیت شناخته‌شده، تاریخ، Contact قابل‌دسترسی و مسیر جایگزین است. Feedback workflow نیز:

• چند کانال قابل‌استفاده و بدون CAPTCHA مانع؛
• Acknowledgement و SLA پاسخ؛
• ثبت URL، Task، Technology با کمینه‌سازی داده؛
• Triage Severity و Owner؛
• Workaround فوری و اصلاح ریشه‌ای؛
• اطلاع نتیجه به گزارش‌دهنده؛
• ورود Incident به Regression suite.

مدل بودجه برای سه وضعیت

محصول جدید

بودجه در Discovery، Design system، Prototype review، Component acceptance، Content workflow، user evaluation و Release gate پخش می‌شود. Remediation انبوه کمتر است، اما Training و Governance از روز اول لازم‌اند. «از ابتدا» به معنی بدون هزینه نیست؛ هزینه به جلوگیری منتقل می‌شود.

سایت Legacy

ابتدا Inventory و Baseline، سپس Critical journey و Shared component. Fix-by-template، Design-system migration و Retire/replace محتوا از اصلاح تک‌صفحه‌ای مقرون‌به‌صرفه‌تر است. Contingency برای Regression و Third-party بالاتر در نظر بگیرید.

چندمحصول/Enterprise

مرکز توانمندی کوچک، Federated owners، Procurement gate، Design system، Shared lab/tooling و independent assurance. بودجه مرکزی Capability مشترک و بودجه Product Remediation/operation را پوشش می‌دهد؛ تیم مرکزی نباید گلوگاه همه Releaseها شود.

ایران و فارسی: Matrix بومی لازم است

WCAG بین‌المللی است، اما Test context باید واقعی باشد:

• RTL، ترتیب Focus بصری/DOM، Bidi در شماره کارت/کد/قیمت؛
• ی/ک، نیم‌فاصله، اعداد فارسی/لاتین و تلفظ Screen reader؛
• فونت فارسی در Zoom/Reflow و فاصله خطوط؛
• تقویم شمسی، Date picker، OTP، کپچا و درگاه پرداخت؛
• NVDA/VoiceOver/TalkBack و Browser/Android رایج، با توجه به Scope پشتیبانی؛
• اینترنت کم‌کیفیت، Timeout و Error recovery؛
• PDF/فرم دولتی، پشتیبانی تلفنی و مسیر جایگزین واقعی؛
• جذب و جبران منصفانه کاربران دارای معلولیت فارسی‌زبان.

برای نیازهای Cognitive و Neurodiversity، راهنمای طراحی برای نورودایورسیتی عمق بیشتری دارد؛ برای اصول فراگیر کلی نیز راهنمای طراحی فراگیر مکمل است.

سنجش ارزش بدون تضمین ROI

W3C می‌گوید Business case باید برای محیط سازمان سفارشی باشد و ROI مستقیم گاهی دشوار است. پس مزایا را تضمین نکنید؛ Baseline و Counterfactual بسازید.

Cost of inaction شامل مانع کاربران، پشتیبانی، Rework، فرصت ازدست‌رفته و ریسک قراردادی/حقوقی است؛ مقدار آن با Evidence سازمان تعیین می‌شود. در Redesign بزرگ، Workstream را با بودجه‌بندی بازطراحی سایت یکپارچه کنید.

برنامه ۹۰ روزه

سؤال‌های متداول

هزینه ممیزی دسترسی‌پذیری وب چقدر است؟

عدد عمومی معتبر نیست. هزینه از تعداد Journey، Template، Component، State، محتوا، Integration، Platform/AT و عمق شواهد ساخته می‌شود. Inventory و Sample را مشخص، ساعات نقش‌ها و هزینه مستقیم را برآورد و Remediation/verification را جدا کنید.

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

خیر. W3C می‌گوید هیچ ابزار واحدی Conformance را تعیین نمی‌کند؛ Expert manual evaluation لازم است. Automated rules برای Regression عالی‌اند، اما معنا، Keyboard flow، announcement و Task واقعی به بررسی انسانی و گاهی User evaluation نیاز دارند.

آیا باید کل سایت WCAG ۲.۲ AAA باشد؟

W3C توصیه نمی‌کند AAA سیاست عمومی کل سایت باشد، چون برخی محتوا نمی‌تواند همه معیارهای AAA را پاس کند. هدف دقیق بر مبنای الزام/کاربر/ریسک تعیین کنید؛ Level AA شامل همه A و AA قابل‌اعمال است و معیارهای AAA مفید را می‌توان افزوده هدف گرفت.

آیا Overlay یا Plugin سایت را دسترس‌پذیر می‌کند؟

هیچ Widget یا اسکنری به‌تنهایی Conformance را ثابت نمی‌کند. ممکن است قابلیت محدودی بدهد، اما Barrierهای Source، Component، Content، Keyboard، Screen reader و Workflow را باید اصلاح و آزمون کرد.

چگونه هزینه بلندمدت را کم کنیم؟

Shared accessible components، Design/CMS guardrails، Role-based training، Procurement gate، تست در PR/Release، user feedback و Fix-by-template هزینه بازکاری را کاهش می‌دهند. صرف حذف Audit دوره‌ای، فقط بدهی را نامرئی می‌کند.

جمع‌بندی

بودجه دسترسی‌پذیری، هزینه یک Audit یا Badge نیست؛ سرمایه‌گذاری در توان تکرارشونده سازمان برای یافتن، رفع و پیشگیری از Barrier است. WCAG ۲.۲ و Scope را دقیق کنید، Inventory را بر Journey/Template/Component/Content بسازید، ارزیابی خودکار/دستی/کاربر را ترکیب کنید و بودجه Remediation، سیستم طراحی، CMS، Training، Vendor و Monitoring را کامل ببینید. ارزش را با Task و Outcome بسنجید، نه وعده ROI.

منابع فنی منتخب

• W3C — Web Content Accessibility Guidelines (WCAG) 2.2
• W3C WAI — Evaluating Web Accessibility
• W3C WAI — Involving Users in Evaluation
• W3C WAI — Planning and Managing Accessibility
• W3C WAI — Authoring Tool Accessibility Guidelines
• W3C WAI — Business Case for Digital Accessibility
• WHO — Global report on health equity for persons with disabilities