WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Inactive controls, focus behaviour

for

From: Isabel Holdsworth
Date: Feb 25, 2019 3:34AM

Accessibility experts are divided on the subject of whether disabled
components should remain in the tab order. Personally, on balance, I
think that disabling a component should make it unfocusable and remove
it from the tab order. But this issue of breaking consistency is an
interesting one, and it would be great to read other people's
thoughts.

On 24/02/2019, Jonathan Avila < <EMAIL REMOVED> > wrote:
> 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
> > > http://webaim.org/discussion/archives
> > > > > >