منبع: بنیاد طراحی تعامل (IxDF) · بازنویسی آزاد: سپنتا پویا · مرداد ۱۴۰۵ · زمان مطالعه: حدود ۱۱ دقیقه

حسابرسی دسترس‌پذیری (Accessibility Audits) چیست؟

💡 این متن «بازنویسی آزاد» است: ایده‌ها و مفاهیم مطلب اصلی با نگارش کاملاً مستقل فارسی و مثال‌های تازه بازگو شده‌اند و ترجمهٔ کلمه‌به‌کلمه نیست. بخش‌های افزودهٔ مترجم در جعبهٔ منبع مشخص شده‌اند.

سه مقالهٔ قبلی این مجموعه — دسترس‌پذیری، طراحی فراگیر و فناوری کمکی — دربارهٔ چه چیزی بودند. این یکی دربارهٔ چطور بفهمیم کجای کاریم است.

و خبر خوبش این است که برای شروع، نه به بودجه نیاز دارید و نه به متخصص. بخش سوم این مقاله یک حسابرسی یک‌ساعته است که هر طراحی می‌تواند همین امروز انجامش بدهد.

حسابرسی دسترس‌پذیری چیست؟

حسابرسی دسترس‌پذیری یعنی ارزیابی نظام‌مند اینکه محصول دیجیتال شما تا چه اندازه برای افراد دارای معلولیت قابل استفاده است — و معمولاً در برابر یک استاندارد رسمی سنجیده می‌شود.

استاندارد مرجع، WCAG است که سه سطح انطباق دارد:

• - سطح A: حداقل مطلق. اگر اینجا هم نیستید، بخشی از کاربران اصلاً نمی‌توانند از محصول استفاده کنند.
• - سطح AA: هدف متعارف برای بیشتر سازمان‌ها، و مبنای بیشتر الزام‌های قانونی در کشورهایی که چنین الزامی دارند.
• - سطح AAA: بالاترین سطح، که معمولاً برای کل یک محصول عملی نیست و بیشتر برای بخش‌های خاص هدف‌گذاری می‌شود.

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

خودکار، دستی، یا هر دو

سه شکل حسابرسی وجود دارد: خودکار (با ابزار)، دستی (با ارزیاب انسانی)، و ترکیبی. ابزارهای رایگان و کارآمدی هم هست — WAVE، axe DevTools، Accessibility Insights و ابزارهای سنجش کنتراست.

اما نکتهٔ اصلی این بخش این است: ابزار خودکار فقط بخشی از مسائل را می‌گیرد. پژوهش Vigo و Brown و Conway در ۲۰۱۳ دقیقاً همین را سنجید و عنوانش هم گویاست: «سنجش زیانِ تکیهٔ صرف بر آزمون‌های خودکار». یافته‌شان این بود که ابزارها بخش محدودی از معیارها را پوشش می‌دهند و اتکای انحصاری به آن‌ها، تصویر خوش‌بینانه‌ای می‌سازد.

پس تقسیم کار درست این است:

• - ابزار خودکار را برای چیزهایی به‌کار ببرید که ماشین بهتر از شما می‌بیند و خسته نمی‌شود: کنتراست، نبود متن جایگزین، برچسب گمشدهٔ فیلد، خطای ساختاری. این‌ها را در خط لولهٔ ساخت بگذارید تا هر بار خودکار بررسی شوند.
• - ارزیابی انسانی را برای چیزهایی نگه دارید که قضاوت می‌خواهند. بخش بعدی دربارهٔ همین است.

آنچه هیچ ابزاری نمی‌بیند

این بخش افزودهٔ مترجم است. منبع می‌گوید ابزارها «مسائل ظریف» را از دست می‌دهند اما نمونه نمی‌آورد؛ و بدون نمونه، این جمله بی‌فایده است. پرتکرارترین مواردی که ابزار سبز نشان می‌دهد و در واقعیت خراب‌اند:

• - متن جایگزینِ بی‌معنا. ابزار فقط وجودش را می‌بیند. alt="image" یا alt="chart-final-v3.png" از نظر ابزار قبول است و برای کاربر هیچ اطلاعاتی ندارد.
• - ترتیب عنوان‌های فنی‌درست و منطقی‌غلط. صفحه‌ای می‌تواند سلسله‌مراتب عنوان بی‌ایراد داشته باشد و همچنان عنوان‌هایش محتوای زیرشان را توصیف نکنند.
• - ترتیب فوکوس گیج‌کننده. اینکه همهٔ عناصر قابل فوکوس باشند را ابزار می‌سنجد؛ اینکه ترتیبشان معنا داشته باشد را نه.
• - برچسب حاضر و بی‌فایده. فیلدی با برچسب «فیلد ۲» از نظر ابزار برچسب‌دار است.
• - پیام خطایی که فقط با رنگ خطا بودنش را می‌گوید — و کنتراستش هم قبول شده.
• - محتوای پویا که اعلام نمی‌شود. وقتی چیزی بدون بارگذاری صفحه تغییر می‌کند و صفحه‌خوان خبردار نمی‌شود، ابزار ایرادی نمی‌بیند چون در لحظهٔ اسکن، همه‌چیز درست بوده.

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

یک حسابرسی یک‌ساعته که خودتان می‌توانید انجام دهید

این بخش هم افزودهٔ مترجم است و به‌نظرم کاربردی‌ترین قسمت این مقاله. حسابرسی کامل هفته‌ها طول می‌کشد و متخصص می‌خواهد؛ اما بیشترِ مشکلات جدی با پنج بررسی ساده پیدا می‌شوند که هیچ ابزار و مهارت ویژه‌ای لازم ندارند. یک مسیر اصلی محصول را انتخاب کنید — مثلاً ثبت‌نام یا خرید — و این پنج کار را روی همان انجام دهید:

• - ۱. موس را کنار بگذارید. کل مسیر را فقط با Tab و Enter و کلیدهای جهت طی کنید. سه چیز را ببینید: آیا به همه‌جا می‌رسید؟ آیا همیشه می‌دانید کجا هستید (حلقهٔ فوکوس دیده می‌شود)؟ و آیا در پنجرهٔ بازشو گیر می‌افتید یا بیرون پرت می‌شوید؟
• - ۲. صفحه را ۲۰۰ درصد بزرگ کنید. چیزی بیرون می‌زند؟ متنی روی متن دیگر می‌افتد؟ دکمه‌ای ناپدید می‌شود؟ این یکی بیشترین ایراد را در کمترین زمان پیدا می‌کند.
• - ۳. صفحه‌خوان سیستم‌عامل را روشن کنید و چشمانتان را ببندید. لازم نیست حرفه‌ای باشید؛ همان تلاش برای طی‌کردن یک فرم با چشم بسته، فهرست بلندی از مشکلات می‌دهد.
• - ۴. یک بار همه‌چیز را خاکستری ببینید. اگر رنگ را حذف کنید، آیا هنوز می‌شود فهمید کدام فیلد خطا دارد و کدام دکمه اصلی است؟
• - ۵. فهرست عنوان‌های صفحه را بگیرید. با یک افزونهٔ ساده یا امکان خود صفحه‌خوان. اگر این فهرست به‌تنهایی ساختار صفحه را نمی‌گوید، ساختار شما مشکل دارد — بحثش در فناوری کمکی آمد.

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

بعد از حسابرسی: جایی که کار معمولاً می‌خوابد

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

راه‌حلش اولویت‌بندی روی دو محور است، نه یکی:

• - شدت: این مورد مانع است یا اصطکاک؟ مانع یعنی کاربر اصلاً نمی‌تواند کار را تمام کند — فیلدی که با صفحه‌کلید قابل رسیدن نیست، دکمه‌ای که برچسب ندارد. اصطکاک یعنی سخت‌تر می‌شود ولی ممکن است.
• - بسامد: این مورد در کدام مسیر است؟ ایرادی در ثبت‌نام یا پرداخت، هزاران برابر ایرادی در صفحهٔ «دربارهٔ ما» اهمیت دارد.

ضرب این دو، ترتیب کار را می‌دهد — و تقریباً همیشه نتیجه‌اش این است که چند مورد در مسیرهای اصلی، ارزش کل بقیهٔ فهرست را دارند. با آن‌ها شروع کنید و بگذارید بقیه در فهرست بماند.

و یک نکتهٔ فرایندی که از تکرار همین چرخه جلوگیری می‌کند: هر موردی که رفع می‌کنید، اگر می‌شود به یک قاعده در سیستم طراحی یا به یک بند در تعریف «کار تمام‌شده» تبدیلش کنید. وگرنه حسابرسی بعدی همان فهرست را دوباره تولید می‌کند — همان بحث بدهی که در طراحی چابک داشتیم.

بندهای ویژهٔ محصول فارسی

این بخش هم افزودهٔ مترجم است. سیاههٔ استاندارد حسابرسی برای محتوای انگلیسی نوشته شده. چهار بند که برای محصول فارسی باید اضافه شوند و در هیچ سیاههٔ متعارفی نیستند:

• - زبان و جهت صفحه درست اعلام شده باشد. این ساده‌ترین و پرتکرارترین ایراد است: صفحه‌ای که زبانش را فارسی اعلام نکرده، به صفحه‌خوان می‌گوید متن را با قواعد زبان دیگری بخواند — و نتیجه‌اش خواندن نامفهوم است. همین یک بند، در بسیاری از سایت‌های فارسی غلط است و اصلاحش چند دقیقه طول می‌کشد.
• - ترتیب فوکوس در چیدمان آینه‌شده. اگر چیدمان را با ویژگی‌های منطقی آینه کرده باشید، ترتیب Tab درست می‌ماند؛ اگر با جابه‌جایی دستی، نه. این را باید جداگانه آزمود، چون ابزارها فقط وجود ترتیب را می‌بینند نه معنایش.
• - محتوای دوجهته. شمارهٔ کارت، قیمت، تاریخ و نام لاتین در دل متن فارسی. این‌ها را با داده‌های واقعی آزمایش کنید، نه با متن نمونه — چون خطا فقط با ترکیب واقعی بیرون می‌آید.
• - یکدستی نویسه‌ها. «ی» و «ک» فارسی در برابر عربی، و نیم‌فاصله. این‌ها هم بر جست‌وجوی داخلی اثر می‌گذارند و هم بر خواندن صفحه‌خوان.

و نکته‌ای که در بحث بلوغ هم گفتیم و اینجا مصداق مشخصی پیدا می‌کند: کف بازار آن‌قدر پایین است که همین چند بند، شما را از بیشتر رقبا جلوتر می‌برد. اعلام درست زبان و جهت، برچسب واقعی برای هر فیلد، و ترتیب فوکوس آزموده‌شده — سه کاری که در یک روز انجام می‌شوند و بیشتر از هر پروژهٔ بزرگی اثر دارند.

جمع‌بندی

• - حسابرسی دسترس‌پذیری یعنی سنجش نظام‌مند محصول در برابر استانداردی مثل WCAG، که سه سطح A و AA و AAA دارد؛ AA هدف متعارف است.
• - ابزار خودکار فقط بخشی از مسائل را می‌گیرد — پژوهش Vigo و همکاران (۲۰۱۳) دقیقاً زیانِ اتکای صرف به آن را سنجید.
• - تقسیم کار: ابزار برای چیزهایی که ماشین خسته‌نشدنی بهتر می‌بیند، انسان برای چیزهایی که قضاوت می‌خواهند.
• - ابزار وجود را می‌سنجد و انسان معنا را: متن جایگزین بی‌معنا، برچسب «فیلد ۲»، و ترتیب فوکوس گیج‌کننده همه از نظر ابزار قبول‌اند.
• - «صفر خطا در ابزار» نقطهٔ شروع است، نه نتیجه.
• - حسابرسی یک‌ساعته: بدون موس، بزرگ‌نمایی ۲۰۰٪، صفحه‌خوان با چشم بسته، حذف رنگ، و فهرست عنوان‌ها. هرچه پیدا شد را تیکت کنید نه سند.
• - یافته‌ها را روی دو محور شدت و بسامد اولویت‌بندی کنید؛ چند مورد در مسیرهای اصلی معمولاً ارزش کل بقیهٔ فهرست را دارند.
• - برای فارسی چهار بند اضافه کنید: اعلام درست زبان و جهت، ترتیب فوکوس در چیدمان آینه‌شده، محتوای دوجهته با دادهٔ واقعی، و یکدستی نویسه‌ها.