بررسی کنید که همه کنترل‌های سفارشی role مناسبی داشته باشند و ویژگی‌های ARIA مورد نیاز که ویژگی‌ها و حالت‌های آن‌ها را ارائه می‌دهند، داشته باشند. به عنوان مثال، یک چک باکس سفارشی به یک role="checkbox" و aria-checked="true|false" نیاز دارد تا وضعیت خود را به درستی منتقل کند. برای یک نمای کلی از اینکه چگونه ARIA می تواند معنای گمشده را برای کنترل های سفارشی ارائه دهد ، به مقدمه ARIA مراجعه کنید.
نحوه تست دستی
برای بررسی اینکه آیا همه کنترل‌های تعاملی سفارشی دارای نقش‌های ARIA مناسب هستند، صفحه را با استفاده از صفحه دسترس‌پذیری Chrome DevTools یا یک صفحه‌خوان آزمایش کنید. JAWS و NVDA دو مورد از محبوب‌ترین صفحه‌خوان‌های ویندوز هستند. VoiceOver صفحه‌خوانی است که در MacOS تعبیه شده است.
با استفاده از CSS، امکان استایل دادن به عناصر <div> و <button> وجود دارد تا بصری یکسانی را منتقل کنند، اما این دو تجربه در هنگام استفاده از صفحه‌خوان بسیار متفاوت هستند. <div> فقط یک عنصر گروه بندی عمومی است، بنابراین یک صفحه خوان فقط محتوای متن <div> را اعلام می کند. <button> به عنوان یک "دکمه" اعلام می شود، سیگنالی بسیار قوی تر به کاربر مبنی بر اینکه چیزی است که می تواند با آن تعامل داشته باشد. همچنین به Semantics and screen readers مراجعه کنید.
چگونه رفع کنیم
ساده ترین و اغلب بهترین راه حل برای این مشکل اجتناب از کنترل های تعاملی سفارشی به طور کامل است. به عنوان مثال، یک <div> که مانند یک دکمه عمل می کند را با یک <button> واقعی جایگزین کنید.
اگر باید <div> را نگه دارید، سپس role="button" و aria-pressed="false" را به <div> اضافه کنید.
اکنون صفحه خوان ها نقش و وضعیت تعاملی <div> را اعلام می کنند.
چرا این مهم است
تنها راه برای درک واقعی اینکه کاربران فناوری کمکی چگونه محتوای شما را تجربه می کنند این است که خودتان آن محتوا را با استفاده از صفحه خوان بررسی کنید. استفاده از صفحه‌خوان دست اول به شما درک روشنی از نحوه برچسب‌گذاری محتوای شما و وجود موانعی در مسیریابی فناوری کمکی می‌دهد. اگر با نحوه تفسیر نشانه‌گذاری معنایی توسط فناوری کمکی آشنا نیستید، برای تازه‌سازی به مقدمه معناشناسی مراجعه کنید.
نحوه انجام بررسی قابلیت دسترسی را نیز ببینید.