From c9028230851e75ddf1e4a6c2a2a9a3159c5a7035 Mon Sep 17 00:00:00 2001
From: Parham Fakhari <parhamfakhary@gmail.com>
Date: Mon, 21 Sep 2026 11:37:01 +0000
Subject: [PATCH] feat(fa): translate the accessibility best practices guide

`_articles/accessibility-best-practices-for-your-project.md` exists only in
English, Russian and Simplified Chinese; 25 other languages, Persian among them,
have no file at all, so /fa/ shows 12 guides while /en/ shows 13.

This adds the Persian translation of the whole article: one new file, nothing
else touched, same shape the merged Russian PR used.

* front matter follows docs/translations.md: `lang: fa`, translated
  title/description, `class`/`order`/`image` unchanged, no `untranslated` flag.
* all 30 links and every URL are copied from the English file, so no target
  drifts; headings 41/41 and links 30/30 against the English source.
* technical names (WCAG, ARIA, VoiceOver, axe-core, CI/CD, `ACCESSIBILITY.md`,
  exit codes) are kept untranslated, as the other Persian guides do.
* `node test/prose` reports no issues for this file (the repo's markdown lint is
  green on the tree with this file added).
---
 ...ibility-best-practices-for-your-project.md | 301 ++++++++++++++++++
 1 file changed, 301 insertions(+)
 create mode 100644 _articles/fa/accessibility-best-practices-for-your-project.md

diff --git a/_articles/fa/accessibility-best-practices-for-your-project.md b/_articles/fa/accessibility-best-practices-for-your-project.md
new file mode 100644
index 00000000000..b93689709e6
--- /dev/null
+++ b/_articles/fa/accessibility-best-practices-for-your-project.md
@@ -0,0 +1,301 @@
+---
+lang: fa
+title: بهترین روال‌های تجربه‌شده‌ی دسترس‌پذیری برای پروژه‌تان
+description: گام‌های عملی و قابل‌اجرا برای اینکه پروژه‌ی متن باز شما برای همه قابل‌استفاده باشد، به‌ویژه برای افراد دارای معلولیت.
+class: accessibility-best-practices
+order: -1
+image: /assets/images/cards/accessibility-best-practices.png
+---
+
+دسترس‌پذیری (که اغلب به _a11y_ خلاصه می‌شود) یعنی افراد بتوانند صرف‌نظر از معلولیت، فناوری کمکی، محیط یا دستگاهشان از پروژه‌ی شما استفاده کنند. این شامل پشتیبانی از صفحه‌خوان‌ها، پیمایش فقط با صفحه‌کلید، زیرنویس/بازنویسی متن، کنتراست رنگی کافی و ساختار روشن محتوا است — و به این‌ها محدود نمی‌شود.
+
+## با افراد دارای معلولیت همراه شوید
+
+**«هیچ چیزی درباره‌ی ما، بدون ما»** - مهم‌ترین کاری که می‌توانید برای دسترس‌پذیری بکنید این است که افراد سرویس‌گیرنده را در مرکز قرار دهید. کاربران، مشارکت‌کنندگان و آزمایشگران دارای معلولیت، موانع را به شکلی می‌فهمند که راهنماها و ابزارهای خودکار هرگز نمی‌توانند. تجربه‌ی زیستۀ آن‌ها را زود و مدام بخواهید.
+
+### در عمل پیاده‌اش کنید
+
+تصمیم‌هایی که بدون افرادِ تحت‌تأثیر گرفته شوند، معمولاً هدف را خطا می‌روند. ساختن نرم‌افزار با افراد دارای معلولیت، نه برایشان، به نرم‌افزار بهتری برای همه می‌رسد.
+
+چند راه برای اینکه تجربه‌ی زیسته را مرکز قرار دهید:
+
+* مشارکت‌کنندگان دارای معلولیت را به بحث‌های طراحی دعوت کنید، نه فقط به اولویت‌بندی باگ.
+* هر جا می‌توانید، افراد دارای معلولیت را در آزمون کاربردپذیری و بازخورد درگیر کنید.
+* وقتی کسی توضیح می‌دهد چگونه از پروژه‌ی شما استفاده می‌کند، گوش بدهید — حتی وقتی فرض‌های شما را به چالش می‌کشد.
+* گزارش‌های دسترس‌پذیری را تخصص بدانید، نه شکایت - ممکن است نمایندۀ افراد بیشتری باشند از آنچه فکر می‌کنید.
+
+### دسترس‌پذیری به نفع همه است
+
+* **روی افراد زیادی اثر می‌گذارد.** بر اساس [سازمان جهانی بهداشت](https://www.who.int/news-room/fact-sheets/detail/disability-and-health)، حدود ۱٫۳ میلیارد نفر (۱ نفر از هر ۶ نفر) معلولیت جدی دارند.
+* **بخشی از کیفیت است.** محصولات دسترس‌پذیر معمولاً برای همه قابل‌استفاده‌ترند.
+* **بار پشتیبانی را کم می‌کند.** رابط و اسناد روشن‌تر یعنی کاربران گیج‌تر کمتر.
+* **پایۀ مشارکت‌کنندگان شما را گسترش می‌دهد.** کاربران فناوری‌های کمکی می‌توانند کامل‌تر مشارکت کنند.
+* **نوآوری را پیش می‌راند.** طراحی برای نیازهای متنوع اغلب به ویژگی‌هایی می‌رسد که به نفع همه است (زیرنویس، کنترل صوتی و حالت تیره همگی از راه‌حل‌های دسترس‌پذیری شروع شدند).
+* **اغلب الزامی است.** سازمان‌های زیاد (و بعضی دولت‌ها) دسترس‌پذیری را برای تدارکات و انطباق الزامی می‌کنند.
+* **آیندۀ ما نامعلوم است.** هیچ‌کس امروز نمی‌تواند درباره‌ی توانایی‌هایی که فردا دارد مطمئن باشد.
+
+## با یک بیانیه‌ی دسترس‌پذیری شروع کنید
+
+پیش از شیرجه رفتن در کد، زمانی بگذارید و تعهد دسترس‌پذیری پروژه‌تان را مستند کنید. یک بیانیه‌ی دسترس‌پذیری به کاربران و مشارکت‌کنندگان سیگنال می‌دهد که دسترس‌پذیری اولویت است، نه فکر بعدی. برای راهنمایی به [Developing an Accessibility Statement](https://www.w3.org/WAI/planning/statements/) کنسرسیوم W3C مراجعه کنید.
+
+بیانیه‌ی روشنی اضافه کنید که انتظارها را مشخص کند و گزارش مسئله را برای کاربران آسان کند. می‌توانید مستقیماً یک بخش دسترس‌پذیری به README اضافه کنید، یا یک فایل **ACCESSIBILITY.md** بسازید و برای دیده‌شدن از README به آن لینک بدهید. به [نمونۀ ACCESSIBILITY.md](https://github.com/open-source-accessibility/accessibility-toolkit/blob/main/ACCESSIBILITY.md) نگاه کنید.
+
+### اهداف
+
+* اهداف و راهنماهای قابل‌سنجش اعلام کنید (مثل [WCAG AA](https://www.w3.org/TR/WCAG22/#wcag-2-layers-of-guidance) هر جا شدنی باشد).
+* اولویت‌های اصلی را تعریف کنید، و اینکه چگونه آن‌ها را برآورده می‌کنید (پشتیبانی از صفحه‌کلید و صفحه‌خوان، زیرنویس و بازنویسی متن، و غیره).
+* محدودیت‌های شناخته‌شده را اعلام کنید، و راه‌حل‌های جایگزین را (اگر وجود دارد).
+
+### الزامات مشارکت‌کنندگان
+
+چارچوب روشن بگذارید تا مشارکت‌کنندگان بدانند چه چیزی انتظار آن‌هاست:
+
+* **آزمون:** هر تغییر UI باید با یک ابزار آزمون دسترس‌پذیری بررسی شود (مثل [Axe DevTools](https://www.deque.com/axe/devtools/extension/#:~:text=Try%20Axe%20DevTools%20Extension%20in%20your%20browser%20of%20choice)).
+* **مستندسازی:** برای اجزایی مثل SVG، تصویر و عناصر تعاملی، راهنماهای دسترس‌پذیری خودِ پروژه را دنبال کنید.
+* **CI/CD:** اگر pull request نقض‌هایی را وارد کند که workflow آزمون دسترس‌پذیری تشخیص می‌دهد، رد می‌شود.
+
+### محیط‌های پشتیبانی‌شده
+
+* سکوها و پلتفرم‌هایی را که پشتیبانی می‌کنید فهرست کنید (وب، وب موبایل، iOS، Android، ترمینال/CLI، اپ دسکتاپ).
+* یادداشت‌های پشتیبانی نسبی را هم فهرست کنید.
+
+### گزارش باگ‌های دسترس‌پذیری
+
+* از گزارش‌دهندگان بخواهید با استفاده از قالب issue دسترس‌پذیری، موضوع باز کنند.
+* **نکته:** انتظارها را صادقانه بگویید (مثل «رویش کار می‌کنیم - در ISSUE-123 پیگیری می‌شود»)؛ گزارش‌ها را تأیید کنید و هر جا ممکن است راه‌حل جایگزین یا پیگیری ارائه دهید.
+
+#### چرا دسترس‌پذیری را از فرایند عمومی issue جدا می‌کنیم؟
+
+کاربران عادت کرده‌اند یک بیانیه و یک مسیر گزارش اختصاصی برای دسترس‌پذیری ببینند - این یک روال جاافتاده در بخش خصوصی و در سایت‌های دولتی است، و خیلی از کاربران وقتی به مانعی می‌خورند اول دنبال همین می‌گردند. جدا نگه داشتن دسترس‌پذیری از جریان عمومی issueها مهم است، چون:
+
+* **اثرش زمانی‌حساس است.** یک باگ دسترس‌پذیری می‌تواند استفاده‌ی کاربر از پروژه را کلاً ممکن نکند، نه اینکه فقط اذیتش کند. یک مسیر اختصاصی کمک می‌کند این گزارش‌ها سریع‌تر اولویت‌بندی شوند.
+* **بافتش فرق می‌کند.** مسئله‌های گزارش‌شده‌ی دسترس‌پذیری به اطلاعات مشخص نیاز دارند (فناوری کمکی، سیستم‌عامل، مرورگر، شدت) که یک قالب عمومیِ باگ آن‌ها را درخواست نمی‌کند.
+* **تعهد را نشان می‌دهد.** یک بیانیه‌ی جدا و دیدنی به کاربران و مشارکت‌کنندگان می‌گوید دسترس‌پذیری یک نگرانی درجه‌یک است، نه چیزی که لای «باگ‌های دیگر» حل شود.
+* **خودِ گزارش‌دهنده ممکن است برای ثبت گزارش از فناوری کمکی استفاده کند.** یک فرایند روشن و قابل‌پیش‌بینی (فایل مشخص، برچسب مشخص، قالب مشخص) اصطکاک را برای افرادی که بیشترین اثر را می‌پذیرند کم می‌کند.
+
+## اسناد را به‌طور پیش‌فرض دسترس‌پذیر بسازید
+
+اسناد اغلب اولین «UI»ای است که کاربر لمس می‌کند. مطمئن شوید همه می‌توانند بخوانندش را.
+
+### ساختار و معنا
+
+* از **سلسله‌مراتب منطقی عنوان‌ها** استفاده کنید و سطوح را جا نیندازید (`#`، `##`، `###`، `####`، `#####` و `######`).
+* از **متن لینک روشن و یکتا** استفاده کنید («راهنمای مشارکت را بخوانید» به‌جای «اینجا کلیک کنید»).
+* زبان ساده به کار ببرید، از تخصص‌گرایی پرهیز کنید و هر مخفف را در اولین استفاده باز کنید.
+* [از **فهرست واقعی**](https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax#lists) استفاده کنید، نه شماره‌گذاری دستی.
+* **راهنما و پیمایش را در جای ثابت** در همه‌ی صفحه‌ها نگه دارید تا کاربران با اطمینان پیدایشان کنند.
+* معنا را فقط با جایگاه یا ظاهر منتقل نکنید («متن قرمز سمت راست را ببینید»).
+
+### تصویر، نمودار و ویدیو
+
+* برای تصاویر **متن جایگزین** معنادار بگذارید (که معمولاً به «alt text» خلاصه می‌شود؛ به [W3C's alt Decision Tree](https://www.w3.org/WAI/tutorials/images/decision-tree/) مراجعه کنید).
+* به‌جای تصویر کردن متن، تا می‌شود از خودِ متن استفاده کنید.
+* برای تصاویر پیچیده (مثل نمودار معماری)، یک **جایگزین متنی** اضافه در کنارش بگذارید (فهرست نشانه‌دار یا یک توضیح کوتاه).
+* اگر دمو، آموزش، سخنرانی یا ویدیوی انتشار منتشر می‌کنید:
+  * **زیرنویس** بگذارید (ویرایش انسانی را ترجیح دهید).
+  * **بازنویسی متن** بگذارید.
+  * از پخش خودکار صدا و تصویر پرهیز کنید.
+  * کنش‌های مهم روی صفحه را با صدا توضیح دهید.
+
+### جدول‌ها
+
+* جدول را فقط برای داده‌های جدولی به کار ببرید، نه برای چیدمان.
+* **سلول‌های سرستون** بگذارید تا سرستون‌ها و سرصفحه‌ی سطرها به داده‌ها وصل شوند.
+* یک **عنوان یا خلاصه** برای توضیح هدف جدول بگذارید.
+
+### بلوک‌های کد
+
+* خط‌ها را معقول کوتاه نگه دارید (خط‌شکستن خوانایی را بالا می‌برد).
+* فقط به رنگ‌آمیزی برای انتقال معنا تکیه نکنید.
+* درجا توضیح دهید کد چه کار می‌کند و موفقیت چه شکلی است.
+
+## رابط‌های دسترس‌پذیر طراحی کنید
+
+اگر پروژه‌ی شما UI وب دارد، این پیش‌فرض‌های پر اثر به نفع همه‌ی کاربران است.
+
+### پشتیبانی از صفحه‌کلید
+
+* هر چیز تعاملی باید فقط با **صفحه‌کلید** قابل‌دسترسی و قابل‌استفاده باشد.
+* یک **نشانگر فوکوس دیدنی** داشته باشید (حاشیۀ فوکوس را حذف نکنید، مگر اینکه جایگزینش کنید).
+* **ترتیب tab** منطقی و هم‌خوان با چیدمان دیداری را حفظ کنید.
+* فوکوس را داخل اجزا حبس نکنید، مگر اینکه عمداً آن را مدیریت کنید (مثل دیالوگ‌های modal) و راه خروج بگذارید.
+
+### اول معنا، بعد ظاهر
+
+* وقتی ممکن است از عناصر **HTML بومی** استفاده کنید (`<h1>`، `<button>`، `<a>`، `<input>`، `<label>`).
+* **ARIA** را فقط وقتی به کار ببرید که HTML بومی کافی نیست. بدون ARIA بهتر از ARIA غلط است. هر وقت از آن استفاده کردید، از [مستندات Accessible Rich Internet Applications (ARIA)](https://www.w3.org/TR/wai-aria/) پیروی کنید و مطمئن شوید همه‌ی کنترل‌های تعاملی ARIA با صفحه‌کلید قابل‌دسترسی‌اند.
+* **زبان** سندتان را اعلام کنید (مثل `lang="en"` در HTML) و هر بخشی را که زبانش فرق دارد علامت‌گذاری کنید.
+
+### نام، برچسب و راهنما
+
+* هر کنترل فرم به یک **برچسب** مرتبط نیاز دارد.
+* **پیام خطای روشن** بدهید، مشخص کنید کدام فیلد خطا دارد، و پیام را برنامه‌نویسی‌پذیر به فیلد وصل کنید (مثل `aria-describedby`).
+* برای فیلدهای اجباری، الزام را در متن توضیح دهید (نه فقط یک ستاره).
+
+### رنگ و کنتراست
+
+* رنگ را تنها روش انتقال معنا قرار ندهید («خطاها قرمزند»).
+* کنتراست کافی برای متن، آیکون و کنترل‌های UI تضمین کنید (به [WebAIM's Contrast Checker](https://webaim.org/resources/contrastchecker/) مراجعه کنید).
+
+### حرکت و انیمیشن
+
+* از محتوای چشمک‌زن و انیمیشن‌های سریع پرهیز کنید.
+* از افکت‌های پارالاکس و کاروسل‌های خودرو به‌جا پرهیز کنید، یا آن‌ها را اختیاری و قابل‌کنترل کنید.
+* اگر سیستم‌عامل نشان می‌دهد کاربر حرکت کم یا صفر را خواسته است، انیمیشن بی‌مورد نگذارید.
+
+### محتوای پویا
+
+وقتی محتوا بدون بارگذاری دوبلۀ صفحه به‌روز می‌شود، مطمئن شوید کاربران فناوری کمکی هم مطلع می‌شوند:
+
+* برای اعلام‌ها با **ناحیه‌ی زنده‌ی ARIA** مناسب و به‌اندازه کار کنید.
+* هنگام باز و بسته کردن دیالوگ‌ها، منوها و کشوها فوکوس را مدیریت کنید.
+
+### وابستگی‌ها و الگوها
+
+* از کتابخانه‌ی کامپوننتی استفاده کنید که پشتیبانی دسترس‌پذیری‌اش مستند شده باشد.
+* باگ‌های دسترس‌پذیری بالادستی را پیگیری کنید و در issueهای خودتان به آن‌ها لینک بدهید.
+* با کنترل‌های UI سفارشی محتاط باشید. کنترل‌های بومی (مثل `<button>`، `<select>`، `<input type="checkbox">`، `<details>`) با پشتیبانی built-in صفحه‌کلید، مدیریت فوکوس، معنای صفحه‌خوان و یکپارچگی فرم می‌آیند که مرورگرها و فناوری‌های کمکی از قبل می‌فهمندشان. بازسازی این رفتار در اجزای سفارشی وقت‌گیر است، راحت غلط می‌شود، و با رشد پلتفرم‌ها و فناوری‌های کمکی هزینه‌ی نگهداری بلندمدت اضافه می‌کند. فقط وقتی سراغ کنترل سفارشی بروید که عنصر بومی واقعا از پس نیاز برنیاید.
+
+### ملاحظات موبایل
+
+* اهداف لمسی را دست‌کم **۲۴×۲۴ پیکسل CSS** بگیرید.
+* برای ژست‌های چندلمسی یا مسیرمحور (نزدیک‌کردن دو انگشت، کشیدن) جایگزین تک‌اشاره‌ای بدهید.
+* برای عملیات کشیدن‌ورهاکردن جایگزین بدهید (دکمه، منو).
+* محتوا را به یک جهت صفحه‌نمایش محدود نکنید، مگر اینکه خودِ محتوا به جهت مشخصی نیاز داشته باشد.
+* برای ویژگی‌هایی که با حرکت دستگاه فعال می‌شوند (مثل تکان دادن برای بازگشت عملیات) جایگزین بگذارید.
+
+## ابزارها را دسترس‌پذیر بسازید
+
+ابزارهای خط فرمان و داشبوردها می‌توانند وقتی با دقت طراحی شوند بسیار دسترس‌پذیر باشند.
+
+### ابزارهای CLI
+
+اپلیکیشن‌های خط فرمان وقتی قابل‌پیش‌بینی و قابل‌اسکریپت باشند بسیار دسترس‌پذیرند.
+
+* از `--help` با نمونه‌های استفاده‌ی روشن پشتیبانی کنید.
+* گزینه‌های **خروجی ماشین‌خوان** بگذارید (مثل `--json`) برای کاربرانی که نمی‌توانند راحت جدول را تحلیل کنند.
+* موفقیت/شکست را فقط با رنگ ANSI منتقل نکنید؛ برچسب متنی و کد خروجی هم بدهید.
+* پیام‌های خطا را این‌طور بنویسید که:
+  * توضیح دهند چه شد،
+  * نشان دهند چگونه درستش می‌کنند، و
+  * در صورت نیاز به اسناد لینک بدهند.
+* از کدهای خروجی استاندارد استفاده کنید و در شکست، مقدار غیرصفر برگردانید.
+
+### ترمینال، لاگ و داشبورد
+
+* زبان ساده را به تخصص‌گرایی ترجیح دهید.
+* بدون توضیح، مخفف به کار نبرید.
+* برای سطوح شدت (`ERROR`، `WARN`، `INFO`) قالببندی ثابت داشته باشید و هر جا مفید بود زمان هم بگذارید.
+* «وضعیت» را فقط با رنگ اعلام نکنید.
+
+## دسترس‌پذیری را در فرایندهای مشارکت بسازید
+
+دسترس‌پذیری وقتی نگهداری‌اش آسان‌تر است که بخشی از فرایند همگی‌تان باشد.
+
+### برچسب و قالب issue اضافه کنید
+
+* یک برچسب دسترس‌پذیری بسازید (مثل _"accessibility"_ یا _"a11y"_).
+* یک قالب issue دسترس‌پذیری بسازید که این‌ها را داشته باشد:
+  * برچسب _accessibility_
+  * رفتار مورد انتظار در برابر رفتار واقعی
+  * گام‌های بازتولید (شامل یک ضبط صفحه‌ی اختیاری)
+  * ابزارهای استفاده‌شده (سیستم‌عامل، مرورگر، فناوری کمکی و نسخۀ آن)
+  * یک رده‌بندی شدت برای کمک به اولویت‌بندی:
+    * **Critical:** کاربر را از انجام یک کار اصلی بازمی‌دارد (مثل «نمی‌توان checkout کرد»).
+    * **High:** سختی جدی، اما راه‌حل جایگزین وجود دارد.
+    * **Medium:** آزاردهنده یا تجربه‌ی ناهم‌خوان.
+    * **Low:** مسئله‌ی جزئی با کمترین اثر روی کاربردپذیری.
+  * در صورت مناسب بودن، راهنمای تماس یا ارتقای مسئله.
+
+به این [نمونۀ قالب issue دسترس‌پذیری](https://github.com/open-source-accessibility/accessibility-toolkit/blob/main/.github/ISSUE_TEMPLATE/accessibility.yml) مراجعه کنید.
+
+### یک چک‌لیست دسترس‌پذیری به pull requestها اضافه کنید
+
+برای پروژه‌هایی که تغییر UI دارند، پرسش‌هایی مثل این‌ها را بگنجانید:
+
+* پیمایش با صفحه‌کلید از سر تا ته کار می‌کند
+* حالت‌های فوکوس دیدنی و منطقی‌اند
+* فرم‌ها برچسب دارند و خطاها اعلام می‌شوند
+* رنگ تنها روش انتقال معنا نیست
+* حرکت کم احترام گذاشته می‌شود (اگر انیمیشن اضافه شده)
+* رفتار صفحه‌خوان بررسی شده (دست‌کم یک بار)
+
+به این [نمونۀ قالب PR](https://github.com/open-source-accessibility/accessibility-toolkit/blob/main/.github/PULL_REQUEST_TEMPLATE.md) مراجعه کنید.
+
+### «تمام» را تعریف کنید
+
+برای ویژگی‌ها و رفع باگ‌ها معیار پذیرش دسترس‌پذیری تعریف کنید، تا اختیاری یا لحظه‌ی آخر نباشد.
+
+### از GitHub Copilot بهره بگیرید
+
+* عامل‌های تخصصی Copilot بسازید که کارهای دسترس‌پذیری را در فرایند توسعه‌تان خودکار کنند، از حسابرسی صفحه‌ها با [axe-core](https://github.com/dequelabs/axe-core) تا پیگیری بهبودهای دسترس‌پذیری در طول انتشارها. به راهنمای [Getting Started with GitHub Copilot Custom Agents for Accessibility](https://accessibility.github.com/documentation/guide/getting-started-with-agents/) مراجعه کنید.
+* پیشنهاد‌های Copilot را با سبک کدنویسی، رویه‌های دسترس‌پذیری و بافت پروژه‌تان هم‌راستا کنید تا با الزامات دسترس‌پذیری شما بخوانند. به راهنمای [Optimizing GitHub Copilot for Accessibility with Custom Instructions](https://accessibility.github.com/documentation/guide/copilot-instructions/) مراجعه کنید.
+
+### مسئله‌های گزارش‌شده‌ی دسترس‌پذیری را محترمانه و موثر رسیدگی کنید
+
+مسئله‌های دسترس‌پذیری اغلب گفتنشان سخت، بازتولیدشان سخت و برای توانایی گزارش‌دهنده در استفاده از پروژه زمانی‌حساس‌اند. هنگام رسیدگی گزارش‌ها:
+
+* از گزارش‌دهنده تشکر کنید و پرسش‌های روشن‌کننده بپرسید، بدون شکاکیت.
+* مانع‌های بزرگ (نمی‌توان یک جریان اصلی را تمام کرد) را بر مسئله‌های ظاهری اولویت بدهید.
+* هر جا ممکن است راه‌حل جایگزین بدهید.
+* چرخه را ببندید: اگر گزارش‌دهنده مایل بود، رفع را با او تأیید کنید.
+
+## دسترس‌پذیری را پیوسته بیازمایید
+
+ابزارهای خودکار رگرسیون‌ها را می‌گیرند، اما آزمون دستی اطمینان واقعی می‌سازد.
+
+### بررسی خودکار (خوب در گرفتن رگرسیون‌ها)
+
+* آزمون lint دسترس‌پذیری در کد UI.
+* اسکن خودکار در CI برای نقض‌های رایج WCAG (مثل [GitHub Accessibility Scanner](https://github.com/github/accessibility-scanner)).
+* تست‌های unit/integration که [نقش/نام](https://www.w3.org/TR/accname-1.2/) اجزای اصلی را تأیید می‌کنند.
+
+### آزمون دستی (برای اطمینان واقعی لازم است)
+
+* یک دست **فقط با صفحه‌کلید**: می‌توانید جریان‌های اصلی تجربه‌تان را بدون ماوس به‌درستی کار بدهید؟
+* یک بررسی سریع با **صفحه‌خوان**:
+  * macOS: [VoiceOver](https://support.apple.com/guide/voiceover/welcome/mac)
+  * Windows: [NVDA](https://www.nvaccess.org/about-nvda/) (رایج در متن باز)، [JAWS](https://vispero.com/jaws-screen-reader-software/) (سازمانی)
+* **بزرگ‌نمایی و reflow**: در ۲۰۰٪ و در عرض‌های باریک بیازمایید.
+* حالت‌های **کنتراست زیاد / رنگ‌های تحمیلی** هر جا صدق می‌کند.
+
+**نکته:** یک بخش سبک «Accessibility [smoke test](https://en.wikipedia.org/wiki/Smoke_testing_(software))» به چک‌لیست انتشار خود اضافه کنید.
+
+## همین هفته با پیروزی‌های کوچک شروع کنید
+
+### لازم نیست همه‌چیز را یک‌جا انجام دهید؛ با چند بهبود سریع شروع کنید.
+
+چندتا را انتخاب کنید:
+
+* `ACCESSIBILITY.md` و یک برچسب دسترس‌پذیری (مثل _"accessibility"_ یا _"a11y"_) اضافه کنید
+* مطمئن شوید هر عنصر تعاملی با صفحه‌کلید قابل‌دسترسی است
+* برچسب‌های فرمِ جاافتاده را درست کنید
+* **زبان** سندتان را اعلام کنید (مثل `lang="en"` در HTML) و هر بخشی را که زبانش فرق دارد علامت‌گذاری کنید
+* به README و اسناد، متن جایگزین و ساختار عنوان اضافه کنید
+* یک مورد چک‌لیست برای صفحه‌کلید/فوکوس به قالب PR اضافه کنید
+* به محبوب‌ترین ویدیویتان زیرنویس/بازنویسی متن اضافه کنید
+* به یک دستور CLI خروجی `--json` اضافه کنید
+
+### فایل‌های پیشنهادی برای رسمی‌کردن تعهد دسترس‌پذیری‌تان
+
+افزودن این‌ها به مخزنتان را در نظر بگیرید:
+
+* `ACCESSIBILITY.md`: بیانیه‌ی دسترس‌پذیری، نحوه‌ی گزارش مسئله، و راهنمای خاصِ پروژه (قانون اجزا، الگوها، مسئله‌های شناخته‌شده) - [نمونۀ ACCESSIBILITY.md](https://github.com/open-source-accessibility/accessibility-toolkit/blob/main/ACCESSIBILITY.md)
+* `.github/ISSUE_TEMPLATE/accessibility.yml`: گزارش باگ دسترس‌پذیری - [نمونۀ قالب issue دسترس‌پذیری](https://github.com/open-source-accessibility/accessibility-toolkit/blob/main/.github/ISSUE_TEMPLATE/accessibility.yml)
+* `.github/pull_request_template.md`: یک چک‌لیست a11y بگنجانید - [نمونۀ قالب PR](https://github.com/open-source-accessibility/accessibility-toolkit/blob/main/.github/PULL_REQUEST_TEMPLATE.md)
+
+برای نمونه‌های بیشتر به این [پروژه](https://github.com/mgifford/ACCESSIBILITY.md/tree/main) مراجعه کنید.
+
+## نتیجه‌گیری: چند قدم برای شما، یک بهبود بزرگ برای کاربران شما
+
+این قدم‌ها شاید ساده به برسند، اما راه زیادی را برای دسترس‌پذیرتر شدن پروژه‌تان می‌پیمایند. هر رفعی که انجام می‌دهید — یک برچسب جاافتاده، یک تله‌ی فوکوس، یا یک زیرنویس روی ویدیو — در را برای کسی باز می‌کند که پیش از این نمی‌توانست از پروژه‌ی شما استفاده کند.
+
+دسترس‌پذیری یک رفع یک‌باره نیست، یک رویه‌ی پیوسته است، و لازم نیست همه‌چیز را یک‌جا انجام دهید. با پیمایش صفحه‌کلید و معنا شروع کنید، تغییرها را کوچک نگه دارید، و زود بازبینی بخواهید.
+
+کاری که امروز می‌کنید یعنی افراد بیشتر می‌توانند از آنچه می‌سازید بیاموزند، در آن مشارکت کنند، و به آن تکیه کنند. این بردی است که ارزش جشن دارد.
+
+## مشارکت‌کنندگان
+
+### با تشکر از همه‌ی نگهدارندگانی که تجربیات و نکته‌هایشان را برای این راهنما با ما به اشتراک گذاشتند!
+
+این راهنما توسط [@mlama007](https://github.com/mlama007) نوشته شده است با مشارکت: [@ericwbailey](https://github.com/ericwbailey)، [@andyfeller](https://github.com/andyfeller)، [@mgifford](https://github.com/mgifford)، [@smockle](https://github.com/smockle) و [@weboverhauls](https://github.com/weboverhauls)