WebAIM - Web Accessibility In Mind

E-mail List Archives

Inactive controls, focus behaviour


From: Detlev Fischer
Date: Feb 24, 2019 11:22AM

I was searching the webaim mailing list for this but haven't found a thread that quite fits so I ask here.

When web apps have a range of controls, some may not always be applicable in certain circumstances so they are then temporarily disabled via the disable attribute or aria-disabled on custom controls. You know that from the „send" button that is inactive until you tick the checkbox that you agree to terms and conditions.

According to a thread on stack overflow, https://stackoverflow.com/questions/38059140/when-to-use-the-disabled-attribute-vs-the-aria-disabled-attribute-for-html-eleme
... W3C says that "Disabled elements might not receive focus from the tab order. […]"
Or they might, and the thread ends in recommending the use of aria-disabled instead of the HTML disabled attribute so that these elements are read (with the correct state) by the screen reader.

I am still uncertain what the appropriate focussing behavior would be in such cases. My hunch it that disabled elements should not receive tab focus (get a tabindex=-1) but be traversable via arrowing and then announce their state (disabled). The downside is that when tabbing through a group of navigation options (or rather, group of app functions), there is then no clear repeated pattern since the disabled state would take some elements out of focus order depending on app state / situation, so this may verge on violating 3.2.3 Consistent Navigation.

Am I correct in assuming that it will depend on the context of the app, i.e. that it will be down to the app designer / developer to think hard whether controls stay focusable (but announce their disabled state) or are skipped by tab focus?