WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Inactive controls, focus behaviour

for

From: Jonathan Avila
Date: Feb 24, 2019 4:53PM

Hi Detlev, 3.2.3 only applies when the navigation mechanism is repeated across multiple web pages in a set of pages and also allows for same relative order which I think would likely mean that this would not fail 3.2.3. However, just because the content is available in the virtual cursor doesn't mean the user will be able to easily find it. So there could be some cases where placing it in the focus order could be helpful to some users unless there is some mechanism to help the user understand why they can't access something.

Jonathan


-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of Detlev Fischer
Sent: Sunday, February 24, 2019 1:22 PM
To: webaim Discussion List < <EMAIL REMOVED> >
Subject: [WebAIM] Inactive controls, focus behaviour

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.


Hi,
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?

Best,
Detlev