نحوه بررسی برای دسترسی، نحوه بررسی برای دسترسی

راب دادسون

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

این پست این مسائل را به یک فرآیند منطقی و گام به گام برای بررسی یک سایت موجود برای دسترسی تجزیه می کند.

با صفحه کلید شروع کنید

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

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

  • با استفاده از تب در سایت خود شروع کنید. ترتیب تمرکز عناصر باید از ترتیب DOM پیروی کند. اگر مطمئن نیستید که کدام عناصر باید فوکوس دریافت کنند، برای تجدید نظر به Focus Fundamentals مراجعه کنید. بهترین روش این است که هر کنترلی که کاربر می تواند با آن تعامل داشته باشد یا ورودی ارائه کند، باید قابل فوکوس باشد و نشانگر فوکوس (مانند حلقه فوکوس) را نمایش دهد.

  • کنترل های تعاملی سفارشی باید قابل تمرکز باشند. اگر از جاوا اسکریپت برای تبدیل <div> به یک کشویی فانتزی استفاده می کنید، به طور خودکار در ترتیب برگه ها درج نمی شود. برای اینکه یک کنترل سفارشی قابل فوکوس کنید، یک tabindex="0" به آن بدهید. مقادیر tabindex بیشتر از 0 ترتیب برگه ها را تغییر می دهد و می تواند برای کاربران صفحه خوان گیج کننده باشد.

  • فقط محتوای تعاملی را قابل تمرکز کنید. افزودن tabindex به عناصر غیر تعاملی مانند سرفصل‌ها سرعت کاربران صفحه‌کلید را که می‌توانند صفحه را ببینند کند می‌کند و به کاربران صفحه‌خوان کمکی نمی‌کند زیرا صفحه‌خوان از قبل می‌داند که آنها را اعلام کند.

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

  • سایت خود را طوری طراحی کنید که کاربر بتواند هر زمان که می خواهد، عنصر بعدی را متمرکز کند. مراقب ویجت های تکمیل خودکار و سایر زمینه هایی باشید که می توانند تمرکز صفحه کلید را به دام بیندازند. زمانی که می‌خواهید کاربر با یک مودال و نه با بقیه صفحه تعامل داشته باشد، می‌توانید به طور موقت فوکوس را به دام بیندازید، اما همیشه باید راهی برای فرار از حالت صفحه کلید ارائه دهید. برای مثال به Modals and Keyboard Traps مراجعه کنید.

کنترل تمرکز خود را قابل استفاده کنید

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

محتوای خارج از صفحه را مدیریت کنید

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

برای راهنمایی هایی برای رسیدگی به این عناصر ، مدیریت محتوای خارج از صفحه را ببینید.

با صفحه خوان تست کنید

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

اگر با نحوه تفسیر نشانه گذاری معنایی توسط فناوری کمکی آشنا نیستید، ساختار محتوا را بخوانید.

  • همه تصاویر را برای متن alt مناسب بررسی کنید. استثنا در این عمل زمانی است که تصاویر عمدتاً برای اهداف ارائه هستند و محتوای ضروری نیستند. برای اینکه نشان دهید خوانندگان صفحه باید یک تصویر را رد کنند، مقدار را روی یک رشته خالی تنظیم کنید: alt="" .
  • همه کنترل ها را برای یک برچسب بررسی کنید. برای کنترل‌های سفارشی، این ممکن است به استفاده از aria-label یا aria-labelledby نیاز داشته باشد. برای مثال به برچسب‌ها و روابط ARIA مراجعه کنید.
  • همه کنترل‌های سفارشی را برای role مناسب و هر ویژگی ARIA مورد نیاز که وضعیت آنها را ارتباط می‌دهد، بررسی کنید. به عنوان مثال، یک چک باکس سفارشی به یک role="checkbox" و aria-checked="true|false" نیاز دارد تا وضعیت خود را به درستی منتقل کند. برای یک نمای کلی از اینکه چگونه ARIA می تواند معنای گمشده را برای کنترل های سفارشی ارائه دهد ، به مقدمه ARIA مراجعه کنید.
  • جریان اطلاعات را از طریق صفحه خود منطقی کنید. از آنجایی که صفحه‌خوان‌ها صفحه را به ترتیب DOM هدایت می‌کنند، هر عنصری را که به‌صورت بصری با استفاده از CSS تغییر مکان داده‌اید، به ترتیب غیرمعنی اعلام می‌کنند. اگر به چیزی نیاز دارید که زودتر در صفحه ظاهر شود، آن را به صورت فیزیکی زودتر در DOM منتقل کنید.
  • هدف پشتیبانی از پیمایش صفحه‌خوان برای همه محتوای صفحه است. اطمینان حاصل کنید که هیچ بخش از سایت به طور دائمی از دسترسی صفحه خوان پنهان یا مسدود نشده است.
    • اگر محتوا باید از یک صفحه‌خوان پنهان شود، برای مثال، اگر خارج از صفحه است یا فقط نمایشی است، آن محتوا را روی aria-hidden="true" تنظیم کنید. برای توضیح عمیق تر، به پنهان کردن محتوا مراجعه کنید.

با صفحه خوان ها آشنا شوید

اگرچه یادگیری یک صفحه خوان ممکن است دلهره آور به نظر برسد، اما در واقع بسیار کاربرپسند هستند. به طور کلی، اکثر توسعه دهندگان می توانند تنها با چند دستور کلیدی ساده به کار خود ادامه دهند.

اگر از Mac استفاده می‌کنید، این ویدیو را درباره VoiceOver ، صفحه‌خوانی که با Mac OS ارائه می‌شود، تماشا کنید. اگر از رایانه شخصی استفاده می‌کنید، این ویدیو را درباره NVDA ، یک صفحه‌خوان منبع باز و پشتیبانی شده برای Windows، ببینید.

aria-hidden از فوکوس صفحه کلید جلوگیری نمی کند

درک این نکته مهم است که ARIA فقط می تواند بر معنای یک عنصر تأثیر بگذارد. هیچ تاثیری بر رفتار عنصر ندارد. می‌توانید با aria-hidden="true" عنصری را برای صفحه‌خوان‌ها پنهان کنید، اما رفتار فوکوس آن عنصر را تغییر نمی‌دهد. برای محتوای تعاملی خارج از صفحه، برای محتوای تعاملی خارج از صفحه، از ویژگی inert استفاده کنید تا مطمئن شوید که واقعاً از جریان صفحه کلید حذف شده است. برای مرورگرهای قدیمی، aria-hidden="true" را با tabindex="-1" ترکیب کنید.

عناصر تعاملی باید هدف و وضعیت خود را نشان دهند

ارائه نکات بصری، یا مقرون به صرفه ، در مورد آنچه که یک کنترل انجام می دهد، به طیف گسترده ای از افراد در دستگاه های مختلف کمک می کند تا در سایت شما کار کرده و مسیریابی کنند.

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

از سرفصل ها و مکان های دیدنی استفاده کنید

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

به طور مشابه، صفحه‌خوان‌ها توانایی پرش به نشانه‌های مهم مانند <main> و <nav> را نیز ارائه می‌دهند. به این دلایل مهم است که در نظر بگیرید چگونه ساختار صفحه شما می تواند برای هدایت تجربه کاربر استفاده شود.

  • از سلسله مراتب h1-h6 استفاده کنید. به عنوان ابزاری برای ایجاد یک طرح کلی برای صفحه خود فکر کنید. به استایل داخلی سرفصل ها تکیه نکنید. در عوض، با آنها به گونه ای رفتار کنید که گویی همه آنها به یک اندازه هستند و از سطح معنایی مناسب برای محتوای اولیه، ثانویه و ثالث استفاده کنید. سپس از CSS استفاده کنید تا سرفصل ها با طراحی شما مطابقت داشته باشند.
  • از عناصر و نقش‌های شاخص استفاده کنید تا کاربران بتوانند محتوای تکراری را دور بزنند. بسیاری از فناوری‌های کمکی میانبرهایی برای پرش به بخش‌های خاصی از صفحه، مانند مواردی که توسط عناصر <main> یا <nav> تعریف شده‌اند، ارائه می‌کنند. این عناصر نقش های شاخص ضمنی دارند. همچنین می‌توانید از ویژگی role ARIA برای تعریف صریح مناطق در صفحه، مانند <div role="search"> استفاده کنید. برای مثال‌های بیشتر به Semantics و محتوای پیمایش مراجعه کنید.
  • از role="application" اجتناب کنید، مگر اینکه تجربه کار با آن را داشته باشید. نقش نقطه عطف application به فناوری کمکی می‌گوید که میانبرهای خود را غیرفعال کند و از طریق تمام فشار دادن کلیدها به صفحه ارسال کند. این بدان معناست که کلیدهایی که کاربران صفحه‌خوان معمولاً برای حرکت در صفحه استفاده می‌کنند، دیگر کار نمی‌کنند و شما باید خودتان همه کنترل‌های صفحه‌کلید را اجرا کنید.

عناوین و نشانه‌ها را با صفحه‌خوان مرور کنید

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

برای کسب اطلاعات بیشتر، به این ویدیوهای آموزشی در مورد اصول اولیه VoiceOver و NVDA مراجعه کنید.

فرآیند را خودکار کنید

آزمایش دستی یک سایت برای دسترسی ممکن است خسته کننده و مستعد خطا باشد. خودکار کردن تست تا حد امکان مفید است. می‌توانید از برنامه‌های افزودنی مرورگر و مجموعه‌های تست دسترسی خط فرمان استفاده کنید.

  • آیا صفحه تمام تست‌ها را از پسوند مرورگر ax یا WAVE پشت سر می‌گذارد؟ گزینه‌های دیگری نیز در دسترس هستند، اما این افزونه‌ها می‌توانند مکمل مفیدی برای هر فرآیند تست دستی باشند، زیرا می‌توانند مسائل ظریفی مانند نسبت‌های کنتراست ناموفق و ویژگی‌های ARIA را از دست بدهند.
    • اگر ترجیح می دهید روی خط فرمان کار کنید، ax-cli همان ویژگی های برنامه افزودنی مرورگر ax را ارائه می دهد، اما می تواند از ترمینال شما اجرا شود.
  • برای جلوگیری از رگرسیون، به ویژه در یک محیط یکپارچه سازی مداوم، کتابخانه ای مانند هسته محوری را در مجموعه آزمایشی خودکار خود بگنجانید. ax-core همان موتوری است که افزونه ax Chrome را تامین می‌کند، اما در یک ابزار خط فرمان.
  • اگر از یک چارچوب یا کتابخانه استفاده می کنید، آیا ابزارهای دسترسی خود را ارائه می دهد؟ به عنوان مثال، پلاگین نقاله-دسترسی برای Angular. در صورت امکان از ابزارهای موجود استفاده کنید.

از Lighthouse برای آزمایش PWA استفاده کنید

Lighthouse ابزاری است که عملکرد برنامه وب پیشرو (PWA) شما را اندازه گیری می کند. و از کتابخانه ax-core برای تست های دسترسی خود استفاده می کند.

اگر قبلاً از Lighthouse استفاده می‌کنید، در گزارش خود به دنبال تست‌های دسترسی ناموفق باشید. برای بهبود تجربه کاربری کلی سایت خود، خطاها را برطرف کنید.

منابع اضافی