# چک‌لیست دسترس‌پذیری برای وب‌سایت شرکت‌ها: صفحات استخدام، فایل‌های PDF، صفحات سرمایه‌گذاران و فرم‌ها

<https://www.fixreports.com/fa/blog/corporate-website-accessibility-checklist>

به‌روزرسانی: 2026-10-26

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

**نکات کلیدی**

- WebAIM در سال 2026 در 95.9% از صفحات اصلی یک میلیون وب‌سایت برتر خطاهای قابل تشخیص WCAG پیدا کرد؛ متن کم‌کنتراست (83.9%) و نبود متن جایگزین (53.1%) رایج‌ترین آن‌ها بودند ([WebAIM](https://webaim.org/projects/million/)).
- WCAG علاوه بر صفحات وب، برای اسنادی که در یک سایت منتشر می‌شوند، مانند فایل‌های PDF، هم اعمال می‌شود؛ W3C تکنیک‌هایی برای دسترس‌پذیر کردن PDF منتشر می‌کند ([W3C](https://www.w3.org/WAI/WCAG22/Techniques/#pdf)).
- ویدیوی ازپیش‌ضبط‌شده به زیرنویس (1.2.2، سطح A) و، جایی که تصویر اطلاعاتی دارد که در صدا نیست، به توصیف صوتی (1.2.5، AA) نیاز دارد ([W3C](https://www.w3.org/WAI/WCAG22/Understanding/captions-prerecorded)).
- وزارت دادگستری آمریکا در راهنمایی‌ای در سال 2022 گفت ADA شامل خدمات آنلاین کسب‌وکارهایی می‌شود که به روی عموم باز هستند، بدون اینکه استاندارد فنی مشخصی تعیین کند ([ADA.gov](https://www.ada.gov/resources/web-guidance/)).
- W3C راهنما و یک ابزار رایگان برای نوشتن بیانیه دسترس‌پذیری ارائه می‌دهد ([W3C](https://www.w3.org/WAI/planning/statements/)).

## چرا دسترس‌پذیری در وب‌سایت شرکت اهمیت دارد؟

چون بازدیدکنندگانی که به آن وابسته‌اند اغلب همان کسانی هستند که بیش از همه می‌خواهید به آن‌ها برسید: متقاضیان شغل، مشتریان، شرکا و سرمایه‌گذاران. سازمان جهانی بهداشت تخمین می‌زند 1.3 میلیارد نفر، یعنی حدود یک نفر از هر شش نفر، معلولیت قابل‌توجهی دارند ([WHO](https://www.who.int/news-room/fact-sheets/detail/disability-and-health)). افراد بسیار بیشتری به‌جای ماوس از صفحه‌کلید استفاده می‌کنند، متن را بزرگ می‌کنند یا در نور شدید با گوشی می‌خوانند.

جنبه انطباق با قوانین هم مطرح است که بسته به کشور و مخاطبان سایت متفاوت است. نهادهای بخش عمومی در اتحادیه اروپا باید دستورالعمل دسترس‌پذیری وب (Web Accessibility Directive) را رعایت کنند؛ کسب‌وکارهایی که به مصرف‌کنندگان اتحادیه اروپا می‌فروشند ممکن است مشمول قانون دسترس‌پذیری اروپا باشند؛ و در ایالات متحده، وزارت دادگستری گفته است ADA شامل خدمات آنلاین کسب‌وکارهای باز به روی عموم می‌شود ([ADA.gov](https://www.ada.gov/resources/web-guidance/)). یک سایت صرفاً B2B ممکن است خارج از دامنه برخی از این قوانین باشد، اما مشتریان بزرگ‌تر بیش از پیش درباره دسترس‌پذیری از تأمین‌کنندگان سؤال می‌کنند. راهنماهای ما درباره [قانون دسترس‌پذیری اروپا](/fa/blog/european-accessibility-act-online-stores) و [اخطارنامه‌های ADA](/fa/blog/ada-website-demand-letter) زمینه را توضیح می‌دهند؛ این مشاوره حقوقی نیست.

## در هر صفحه چه چیزی را باید بررسی کنید؟

این مشکلات از قالب‌های مشترک می‌آیند، بنابراین یک بار اصلاحشان کل سایت را اصلاح می‌کند:

- **کنتراست**: متن اصلی دست‌کم 4.5:1 در برابر پس‌زمینه‌اش، و متن بزرگ 3:1 (1.4.3). متن خاکستری روشن و متن سفید روی رنگ‌های برند خطاهای معمول‌اند. [ابزار بررسی کنتراست رنگ](/fa/color-contrast-checker) هر جفت‌رنگی را تست می‌کند.
- **صفحه‌کلید**: همه لینک‌ها، منوها و دکمه‌ها با Tab قابل دسترسی و با Enter یا Space قابل استفاده باشند، همراه با نشانگر فوکوس قابل مشاهده (2.1.1، 2.4.7). مگامنوها و اسلایدرها (carousel) مشکلات رایج‌اند.
- **لینک پرش و نشانه‌های ساختاری**: راهی برای رد شدن از هدر و رفتن به محتوای اصلی (2.4.1)، و نشانه‌های ساختاری `header`، `nav`، `main` و `footer`.
- **سرتیترها**: یک H1 در هر صفحه و ساختار منطقی سرتیترها (1.3.1)، تا کاربران صفحه‌خوان بتوانند صفحه را مرور کنند.
- **متن لینک‌ها**: لینک‌هایی که خارج از بافت هم معنا داشته باشند، نه «بیشتر بخوانید» که ده بار تکرار شده است (2.4.4).
- **زبان**: ویژگی `lang` در هر صفحه و در بخش‌هایی که به زبان دیگری هستند (3.1.1، 3.1.2)، تا صفحه‌خوان‌ها آن‌ها را درست تلفظ کنند.
- **بزرگ‌نمایی و reflow**: محتوا در بزرگ‌نمایی 200% و در عرض 320 پیکسل بدون پیمایش افقی قابل استفاده باشد (1.4.4، 1.4.10).

## صفحات استخدام و درخواست شغل را چگونه دسترس‌پذیر کنیم؟

بخش استخدام جایی است که موانع روشن‌ترین پیامد را دارند: متقاضی‌ای که نتواند درخواست را تکمیل کند، نمی‌تواند بررسی شود.

- **فهرست مشاغل**: فیلترها و جست‌وجو باید با صفحه‌کلید کار کنند و تعداد نتایج را به صفحه‌خوان‌ها اعلام کنند (4.1.3).
- **فرم‌های درخواست**: هر فیلد به برچسب قابل مشاهده نیاز دارد (3.3.2)، خطاها باید با متن توصیف شوند (3.3.1)، و دکمه‌های آپلود فایل باید نام قابل‌دسترس داشته باشند.
- **محدودیت زمانی**: اگر فرم مهلت زمانی دارد، به افراد هشدار دهید و اجازه دهید زمان را تمدید کنند (2.2.1).
- **سیستم‌های ردیابی متقاضی شخص ثالث**: بسیاری از شرکت‌ها برای درخواست‌ها از یک سیستم خارجی استفاده می‌کنند. گزارش انطباق دسترس‌پذیری (ACR) آن را از فروشنده بخواهید، فرایند درخواست را خودتان با صفحه‌کلید تست کنید، و یک راه جایگزین برای درخواست، مانند ایمیل، در صفحه استخدام ارائه دهید.
- **آزمون‌ها و مصاحبه‌های ویدیویی**: بررسی کنید که هر آزمون آنلاین یا ابزار مصاحبه ویدیویی از صفحه‌خوان، زیرنویس و زمان اضافه در صورت درخواست پشتیبانی کند.

## فایل‌های PDF و گزارش‌های سالانه دسترس‌پذیر را چگونه منتشر کنیم؟

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

- **HTML را ترجیح دهید** برای محتوای مهم. دسترس‌پذیر کردن یک صفحه وب آسان‌تر است، روی گوشی بهتر کار می‌کند و جست‌وجو در آن آسان‌تر است.
- **اگر PDF منتشر می‌کنید، آن را تگ‌گذاری کنید.** از سند اصلی (Word، InDesign) با تگ‌های فعال خروجی بگیرید تا سرتیترها، فهرست‌ها، جدول‌ها و ترتیب خواندن حفظ شوند. استاندارد PDF/UA (ISO 14289) فایل‌های PDF دسترس‌پذیر را تعریف می‌کند.
- **موارد ضروری را بررسی کنید**: عنوان سند، زبان سند، متن جایگزین برای نمودارها و تصاویر، سرستون‌های واقعی جدول و ترتیب منطقی خواندن. Adobe Acrobat Pro یک ابزار داخلی بررسی دسترس‌پذیری دارد؛ PAC یک ابزار رایگان برای Windows است.
- **اسناد اسکن‌شده** تصویری از متن هستند و به OCR و تگ‌گذاری، یا یک نسخه HTML، نیاز دارند.
- **جدول‌های مالی**: ردیف‌ها و ستون‌های سرعنوان را نشانه‌گذاری کنید؛ در HTML از `<th>` همراه با `scope` استفاده کنید.

## ویدیو، وب‌کست و پادکست چه؟

- **زیرنویس** برای همه ویدیوهای ازپیش‌ضبط‌شده دارای گفتار (1.2.2، A) و برای وب‌کست‌های زنده (1.2.4، AA). زیرنویس‌های خودکار نیاز به بررسی دارند: نام‌ها، اعداد و اصطلاحات فنی اغلب اشتباه درمی‌آیند.
- **توصیف صوتی** جایی که اطلاعات مهم فقط تصویری است، مانند متنی روی اسلایدها که سخنران نمی‌خواند (1.2.5، AA). اغلب ساده‌ترین راه این است که سخنران اسلاید را توصیف کند.
- **متن پیاده‌شده (transcript)** برای پادکست‌ها و محتوای فقط صوتی (1.2.1، A).
- **کنترل‌های پخش‌کننده**: پخش‌کننده جاسازی‌شده باید با صفحه‌کلید قابل کار باشد، و صدایی که بیش از سه ثانیه خودکار پخش می‌شود به راهی برای مکث یا توقف نیاز دارد (1.4.2).

راهنمای W3C برای دسترس‌پذیر کردن صوت و ویدیو، برنامه‌ریزی، زیرنویس و توصیف صوتی را پوشش می‌دهد ([W3C](https://www.w3.org/WAI/media/av/)).

## فرم‌های تماس، نقشه‌ها و نشانی دفاتر را چگونه دسترس‌پذیر کنیم؟

- **فرم‌ها**: برچسب‌ها، پیام‌های خطای روشن، و بدون CAPTCHA‌ای که فقط به خواندن متن مخدوش یا حل معما متکی باشد؛ یک جایگزین ارائه دهید ([W3C](https://www.w3.org/TR/turingtest/)).
- **اطلاعات تماس به‌صورت متن**: شماره تلفن‌ها، نشانی‌های ایمیل و نشانی دفاتر در خود صفحه نوشته شوند، نه فقط در یک تصویر یا نقشه.
- **نقشه‌ها**: استفاده از نقشه جاسازی‌شده با صفحه‌خوان دشوار است؛ نشانی و مسیر به‌صورت متن، جایگزین دسترس‌پذیر است.
- **ابزارک‌های چت**: بررسی کنید که بتوان آن‌ها را با صفحه‌کلید باز کرد، استفاده کرد و بست، و اینکه محتوای دارای فوکوس را نپوشانند (2.4.11).

## آیا بنرهای کوکی مشکل دسترس‌پذیری ایجاد می‌کنند؟

اغلب، چون اول ظاهر می‌شوند و روی همه چیز قرار می‌گیرند.

- بنر باید با صفحه‌کلید قابل دسترسی و استفاده باشد، و Tab باید بتواند از آن خارج شود (2.1.2، No Keyboard Trap) ([W3C](https://www.w3.org/WAI/WCAG22/Understanding/no-keyboard-trap)).
- دکمه‌های آن به نام‌های روشن و کنتراست کافی نیاز دارند؛ پیدا کردن «رد کردن» باید به همان آسانی «پذیرفتن» باشد.
- نباید عنصر دارای فوکوس در صفحه را پشت خود پنهان کند (2.4.11).

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

## آیا به بیانیه دسترس‌پذیری نیاز دارید؟

نهادهای بخش عمومی در اتحادیه اروپا باید آن را منتشر کنند. برای شرکت‌ها معمولاً داوطلبانه است، هرچند قانون دسترس‌پذیری اروپا خدمات مشمول را ملزم می‌کند اطلاعاتی درباره نحوه رعایت الزامات آن ارائه دهند. یک بیانیه خوب می‌گوید چه استانداردی را هدف گرفته‌اید، محدودیت‌های شناخته‌شده چیست، افراد چگونه می‌توانند مشکلی را گزارش دهند یا محتوا را در قالب دیگری بخواهند، و آخرین بار چه زمانی بازبینی شده است. W3C راهنما و یک ابزار رایگان منتشر می‌کند ([W3C](https://www.w3.org/WAI/planning/statements/)).

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

## وب‌سایت یک شرکت را چگونه تست کنیم؟

1. **یک اسکن خودکار اجرا کنید** روی صفحه اصلی، یک صفحه استخدام، یک خبر، صفحه تماس و هر فرم. [ابزار رایگان بررسی دسترس‌پذیری](/fa/website-accessibility-checker) ما صفحات کلیدی را در یک مرورگر واقعی بر اساس WCAG 2.2 سطح A و AA تست می‌کند، و [ابزار بررسی متن جایگزین](/fa/image-alt-text-checker) همه تصاویر یک صفحه را فهرست می‌کند.
2. **با صفحه‌کلید تست کنید**: فقط با صفحه‌کلید در منو حرکت کنید، برای یک شغل درخواست دهید و فرم تماس را ارسال کنید.
3. **اسناد را بررسی کنید**: مهم‌ترین فایل‌های PDF خود را با یک صفحه‌خوان یا یک ابزار بررسی دسترس‌پذیری PDF باز کنید.
4. **ویدیوهای خود را با زیرنویس روشن** و صدای خاموش تماشا کنید.
5. **از افراد دارای معلولیت بخواهید** کارهای اصلی را امتحان کنند؛ این کار مشکلاتی را آشکار می‌کند که هیچ چک‌لیستی پیش‌بینی نمی‌کند.

## پرسش‌های متداول

### آیا WCAG برای فایل‌های PDF هم اعمال می‌شود؟

بله. WCAG برای محتوای وب، از جمله اسنادی که در یک سایت منتشر می‌شوند، اعمال می‌شود. W3C تکنیک‌های مشخصی برای رعایت WCAG در فایل‌های PDF منتشر می‌کند.

### سایت استخدام ما را یک شرکت ثالث اداره می‌کند. آیا مسئولیت با ماست؟

از دید متقاضی، این فرایند استخدام شماست. از فروشنده گزارش انطباق دسترس‌پذیری بخواهید، فرایند را تست کنید و یک راه جایگزین برای درخواست ارائه دهید. اینکه مسئولیت حقوقی دارید یا نه به حوزه قضایی شما بستگی دارد.

### آیا زیرنویس‌های خودکار WCAG را رعایت می‌کنند؟

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

### آیا یک ابزار اورلی دسترس‌پذیری برای یک سایت شرکتی کافی است؟

خیر. اورلی‌ها کد زیربنایی، اسناد یا ویدیوها را اصلاح نمی‌کنند. راهنمای ما درباره [ابزارهای اورلی دسترس‌پذیری و حکم FTC](/fa/blog/accessibility-overlays-ftc-order) را ببینید.

### وب‌سایت یک شرکت باید کدام استاندارد را هدف بگیرد؟

WCAG 2.2 سطح AA نسخه فعلی و هدف معمول است؛ بسیاری از قوانین و سیاست‌ها هنوز به WCAG 2.1 AA ارجاع می‌دهند، و سایتی که 2.2 AA را رعایت کند آن را هم رعایت می‌کند.

## منابع

- WebAIM: [The WebAIM Million (2026)](https://webaim.org/projects/million/)
- W3C: [رهنمودهای دسترس‌پذیری محتوای وب (WCAG) 2.2](https://www.w3.org/TR/WCAG22/)
- W3C: [تکنیک‌های WCAG 2.2: تکنیک‌های PDF](https://www.w3.org/WAI/WCAG22/Techniques/#pdf)
- W3C: [توضیح معیار 1.2.2 Captions (Prerecorded)](https://www.w3.org/WAI/WCAG22/Understanding/captions-prerecorded)
- W3C: [توضیح معیار 1.2.5 Audio Description (Prerecorded)](https://www.w3.org/WAI/WCAG22/Understanding/audio-description-prerecorded)
- W3C: [دسترس‌پذیر کردن رسانه‌های صوتی و تصویری](https://www.w3.org/WAI/media/av/)
- W3C: [توضیح معیار 2.1.2 No Keyboard Trap](https://www.w3.org/WAI/WCAG22/Understanding/no-keyboard-trap)
- W3C: [دسترس‌ناپذیری CAPTCHA (Inaccessibility of CAPTCHA)](https://www.w3.org/TR/turingtest/)
- W3C: [تهیه بیانیه دسترس‌پذیری](https://www.w3.org/WAI/planning/statements/)
- وزارت دادگستری آمریکا: [راهنمای دسترس‌پذیری وب و ADA](https://www.ada.gov/resources/web-guidance/)
- سازمان جهانی بهداشت: [برگه اطلاعات معلولیت و سلامت](https://www.who.int/news-room/fact-sheets/detail/disability-and-health)