تجربه بصری و غیر بصری
ما باید تجربه مشترک صفحات خود را در نظر بگیریم: تجربه بصری و غیر بصری. می‌توانیم تجربه غیر بصری را با استفاده از ساختار معنایی و محتوای مناسب شکل دهیم. همچنین می‌توانیم تجربه بصری را با استفاده از کنتراست واضح، فونت‌های خوانا، صفحات قابل بزرگ‌نمایی و موارد دیگر ارتقا دهیم.
همچنین باید به نقاط تلاقی این دو تجربه توجه کنیم: جاهایی که آنچه روی صفحه است را با متن جایگزین، labelهای screen reader و موارد مشابه توصیف می‌کنیم.
در بخش قبلی درباره accessible name computation به نام‌گذاری قابل دسترس اشاره شد. یکی از مشکلات استفاده از ویژگی aria-label این است که ممکن است محتوای آن با آنچه واقعاً روی صفحه دیده می‌شود همخوانی نداشته باشد. استفاده از aria-labelledby می‌تواند راهکاری مؤثر باشد چون اغلب به محتوای قابل مشاهده مانند headings یا سایر متن‌ها ارجاع می‌دهد و به‌روز باقی می‌ماند.
یک نکته هشداردهنده
بسیاری از توسعه‌دهندگان هنگام کار با screen reader تلاش می‌کنند که همه چیز را بی‌نقص بسازند. این مشابه همان وسواس پیکسل به پیکسل در طراحی بصری است. ولی این کار در مورد screen reader حتی سخت‌تر است، چون APIهای accessibility در پلتفرم‌های مختلف تفاوت‌هایی دارند که اجتناب‌ناپذیر هستند.
«آیا راهی وجود دارد که به screen reader بگویید عددی را به صورت "دو هزار و صد و پنجاه و چهار" بخواند؟»
توصیه این است که به مقادیر پیش‌فرض screen reader دست نزنید.
به جای صرف زمان زیاد برای تنظیم دقیق نحوه تلفظ محتوای خاص (مثل شماره تلفن یا تاریخ)، سعی کنید راهکاری ارائه دهید که به اندازه کافی خوب باشد. اگر ممکن است، آن را با کاربرانی که به AT وابسته‌اند تست کنید.
در این زمینه مقاله‌ای بسیار مفید از Adrian Roselli وجود دارد.
نتیجه نهایی: تلاش بیش از حد برای ایده‌آل‌سازی labeling برای Assistive Technology می‌تواند نتیجه معکوس بدهد و تجربه را بدتر کند.