تست فناوری کمکی

این ماژول بر استفاده از فناوری کمکی (AT) برای آزمایش دسترسی‌پذیری تمرکز دارد. فرد دارای معلولیت می‌تواند از AT برای کمک به افزایش، حفظ یا بهبود قابلیت‌های انجام یک کار استفاده کند.

در فضای دیجیتال، ATها می‌توانند:

• بدون فناوری یا با فناوری پایین: چوب‌های مخصوص سر و دهان، ذره‌بین‌های دستی، دستگاه‌هایی با دکمه‌های بزرگ
• فناوری پیشرفته: دستگاه‌های فعال‌شونده با صدا، دستگاه‌های ردیابی چشم، صفحه‌کلید و ماوس‌های تطبیقی
• سخت‌افزار: دکمه‌های سوئیچ، صفحه‌کلیدهای ارگونومیک، دستگاه بریل با قابلیت به‌روزرسانی خودکار
• نرم‌افزار: برنامه‌های تبدیل متن به گفتار، زیرنویس‌های زنده، صفحه‌خوان‌ها

ما شما را تشویق می‌کنیم که از انواع مختلف AT در گردش کار کلی تست خود استفاده کنید.

اصول اولیه تست صفحه خوان

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

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

سازگاری با مرورگرها

گزینه‌های مختلفی برای خواندن صفحه نمایش وجود دارد. محبوب‌ترین برنامه‌های خواندن صفحه نمایش عبارتند از JAWS، NVDA و VoiceOver برای کامپیوترهای رومیزی و VoiceOver و Talkback برای دستگاه‌های تلفن همراه.

بسته به سیستم عامل (OS)، مرورگر مورد علاقه و دستگاهی که استفاده می‌کنید، یک صفحه‌خوان ممکن است به عنوان بهترین گزینه متمایز باشد. اکثر صفحه‌خوان‌ها با در نظر گرفتن سخت‌افزار و مرورگرهای وب خاص ساخته شده‌اند. وقتی از یک صفحه‌خوان با مرورگری که برای آن کالیبره نشده است استفاده می‌کنید، ممکن است با "اشکالات" یا رفتار غیرمنتظره بیشتری مواجه شوید. صفحه‌خوان‌ها زمانی بهترین عملکرد را دارند که در ترکیب‌های زیر استفاده شوند.

دستورات صفحه خوان

پس از اینکه تنظیمات مناسب نرم‌افزار صفحه‌خوان خود را برای دسکتاپ یا دستگاه همراهتان انجام دادید، باید به مستندات صفحه‌خوان (که در جدول قبلی لینک آن آمده است) نگاهی بیندازید و برخی از دستورات ضروری صفحه‌خوان را اجرا کنید تا با این فناوری آشنا شوید. اگر قبلاً از یک صفحه‌خوان استفاده کرده‌اید، امتحان کردن یک صفحه‌خوان جدید را در نظر بگیرید!

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

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

دستورات کلیدی برای صفحه‌خوان‌های دسکتاپ

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

نسخه آزمایشی تست صفحه خوان

برای آزمایش نسخه آزمایشی خود، از مرورگر سافاری روی لپ‌تاپی با سیستم عامل macOS استفاده کردیم و صدا را ضبط کردیم. می‌توانید با استفاده از هر نرم‌افزار صفحه‌خوانی این مراحل را طی کنید، اما نحوه مواجهه شما با برخی خطاها ممکن است با نحوه توصیف آن در این ماژول متفاوت باشد.

مرحله ۱

از CodePen به‌روزرسانی‌شده دیدن کنید، که تمام به‌روزرسانی‌های دسترسی‌پذیری خودکار و دستی را اعمال کرده است.

برای ادامه آزمایش‌های بعدی، آن را در حالت اشکال‌زدایی (debug mode) مشاهده کنید. این مهم است، زیرا <iframe> که صفحه وب آزمایشی را احاطه کرده است و ممکن است با برخی از ابزارهای آزمایش تداخل داشته باشد را حذف می‌کند. درباره حالت اشکال‌زدایی CodePen بیشتر بدانید.

مرحله ۲

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

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

مسئله ۱: ساختار محتوا

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

اگر سعی کنید در نسخه آزمایشی بر اساس هر یک از عناصر پیمایش کنید، به سرعت متوجه خواهید شد که آنها وجود ندارند.

• مثال برجسته: <div class="main">...</div>
• مثال عنوان: <p class="h1">Join the Club</p>

اگر همه چیز را به درستی به‌روزرسانی کرده باشید، نباید هیچ تغییر بصری ایجاد شود، اما تجربه خواندن صفحه نمایش شما به طرز چشمگیری بهبود یافته است.

بیایید آن را درست کنیم.

برخی از عناصر غیرقابل دسترس را نمی‌توان فقط با نگاه کردن به سایت مشاهده کرد. ممکن است اهمیت سطوح عنوان و HTML معنایی را از ماژول ساختار محتوا به خاطر داشته باشید. یک قطعه محتوا ممکن است شبیه یک عنوان به نظر برسد، اما در واقع محتوا در یک <div> استایل‌بندی شده قرار گرفته است.

برای رفع مشکل مربوط به سرتیترها و لندمارک‌ها، ابتدا باید هر عنصری را که باید به این صورت علامت‌گذاری شود، شناسایی کرده و HTML مربوط به آن را به‌روزرسانی کنید. حتماً CSS مربوط به آن را نیز به‌روزرسانی کنید.

• مثال مکان دیدنی: <main>...</main>
• مثال عنوان: <h1>Join the Club</h1>

اگر همه چیز را به درستی به‌روزرسانی کرده باشید، نباید هیچ تغییر بصری ایجاد شود، اما تجربه خواندن صفحه نمایش شما به طرز چشمگیری بهبود یافته است.

مشکل ۲: زمینه پیوند

ارائه توضیحاتی در مورد هدف لینک و اینکه آیا لینک آنها را به مکان جدیدی خارج از وب‌سایت یا برنامه هدایت می‌کند یا خیر، به کاربران صفحه‌خوان (screen reader) بسیار مهم است.

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

<a href="https://rarediseases.org/rare-diseases/maple-syrup-urine-disease">
  Maple syrup urine disease (MSUD)
</a>

بیایید آن را درست کنیم.

برای رفع این مشکل برای کاربران صفحه‌خوان، ما کد را به‌روزرسانی می‌کنیم تا اطلاعات بیشتری اضافه شود، بدون اینکه روی عنصر بصری تأثیر بگذارد. یا برای کمک به افراد بیشتری مانند افراد مبتلا به اختلالات خواندن و شناختی، ممکن است به جای آن متن بصری اضافی اضافه کنیم.

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

<a href="https://rarediseases.org/rare-diseases/maple-syrup-urine-disease"
  aria-label="Learn more about Maple syrup urine disease on the Rare Diseases website.">
  Maple syrup urine disease (MSUD)
</a>

شماره ۳: تصویر تزئینی

در ماژول تست خودکار ما، Lighthouse نتوانست SVG درون‌خطی را که به عنوان تصویر اصلی در صفحه آزمایشی ما عمل می‌کند، تشخیص دهد. با این حال، صفحه‌خوان آن را پیدا می‌کند و بدون اطلاعات اضافی، آن را به عنوان "image" اعلام می‌کند. این موضوع حتی بدون اضافه کردن صریح ویژگی role="img" به SVG نیز صادق است.

<div class="section-right">
  <svg>...</svg>
</div>

بیایید آن را درست کنیم.

برای رفع این مشکل، ابتدا باید تصمیم بگیریم که آیا تصویر آموزنده است یا تزئینی . بر اساس این تصمیم، باید متن جایگزین تصویر مناسب (تصویر آموزنده) را اضافه کنیم یا تصویر را از کاربران صفحه خوان (تصویر تزئینی) پنهان کنیم.

ما مزایا و معایب بهترین روش برای دسته‌بندی تصویر را سنجیدیم و تصمیم گرفتیم که تزئینی است، به این معنی که می‌خواهیم کدی را برای پنهان کردن تصویر اضافه یا اصلاح کنیم. یک روش سریع این است که مستقیماً role="presentation" را به تصویر SVG اضافه کنیم. این کار سیگنالی را به صفحه‌خوان ارسال می‌کند تا از این تصویر صرف نظر کند و آن را در گروه تصاویر فهرست نکند.

<div class="section-right">
  <svg role="presentation">...</svg>
</div>

شماره ۴: تزیین گلوله

شاید متوجه شده باشید که صفحه‌خوان تصویر بولت CSS را در زیر بخش‌های بیماری‌های نادر می‌خواند. اگرچه این تصویر با آنچه در ماژول تصاویر بحث کردیم، یکسان نیست، اما تصویر همچنان باید اصلاح شود زیرا جریان محتوا را مختل می‌کند و می‌تواند کاربر صفحه‌خوان را منحرف یا گیج کند.

<p class="bullet">...</p>

بیایید آن را درست کنیم.

درست مانند مثال تصویر تزئینی که قبلاً مورد بحث قرار گرفت، می‌توانید با استفاده از کلاس bullet، یک role="presentation" به HTML اضافه کنید تا آن را از صفحه‌خوان پنهان کنید. به طور مشابه، role="none" نیز کار خواهد کرد. فقط مطمئن شوید که aria-hidden: true استفاده نمی‌کنید، در غیر این صورت تمام اطلاعات پاراگراف را از کاربران صفحه‌خوان پنهان خواهید کرد.

<p class="bullet" role="none">...</p>

مشکل ۵: فیلد فرم

در ماژول فرم‌ها ، یاد گرفتیم که همه فیلدهای فرم باید دارای برچسب بصری و برنامه‌نویسی نیز باشند. این برچسب باید همیشه قابل مشاهده باشد.

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

<form>
  <div class="form-group">
    <input type="email" placeholder="Enter your e-mail address" required>
    <button type="submit">Subscribe</button>
  </div>
</form>

بیایید آن را درست کنیم.

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

<form>
  <div class="form-group">
    <input type="email" required id="youremail" name="youremail" type="text">
    <label for="youremail">Enter your e-mail address</label>
    <button type="submit" aria-label="Subscribe to our newsletter">Subscribe</button>
  </div>
</form>

جمع بندی

تبریک! شما تمام آزمایش‌های این نسخه آزمایشی را انجام داده‌اید. می‌توانید تمام این تغییرات را در Codepen به‌روزرسانی‌شده برای این نسخه آزمایشی مشاهده کنید.

اکنون، می‌توانید از آموخته‌های خود برای بررسی دسترسی‌پذیری وب‌سایت‌ها و برنامه‌های خود استفاده کنید.

هدف از تمام این آزمایش‌های دسترسی‌پذیری، رسیدگی به حداکثر مشکلات احتمالی است که یک کاربر می‌تواند با آن مواجه شود. با این حال، این بدان معنا نیست که وب‌سایت یا برنامه شما پس از اتمام کار، کاملاً قابل دسترس است. با طراحی وب‌سایت یا برنامه خود با در نظر گرفتن دسترسی‌پذیری در طول فرآیند و ترکیب این آزمایش‌ها با سایر آزمایش‌های قبل از راه‌اندازی، بیشترین موفقیت را خواهید یافت.