WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Inactive controls, focus behaviour

for

From: Sean Curtis
Date: Feb 25, 2019 4:01PM

I ran into this issue recently with submit buttons on forms. Either the
designer wanted to disable the submit button until all relevant fields had
been filled in, or for the button to disable once the form was submitted.
This second example is to stop multiple submissions and primarily for when
posting/validating the form data might take a while. The problem with
disabling the button on submit is that it is removed from the focus order,
and thus focus is often reset to the start of the document. An option we
came up with was to have something which visually looks disabled, and
ignores mouse clicks/keyboard presses until "enabled" again. This leaves
focus on the button until whatever process finishes. The
complexity/cognitive impact of needing to differentiate between looking
disabled or really disabled instead pushed us down another route. We ended
up just putting a spinner inside the button instead of disabling it.



On Mon, Feb 25, 2019 at 11:25 PM Birkir R. Gunnarsson <
<EMAIL REMOVED> > wrote:

> The way I look at it is to follow the first rule of ARIA, do not use
> ARIA when a native solution is available, i.e. use the HTmL5 required
> attribute over aria-required="true" where it can be used.
> Browsers consistently remove disabled elements from the focus order, I
> assume there is a user agent recommendation to do this somewhere in
> the HTmL spec.
> If we think this is a bad idea, we need to start by convincing those
> who wrote the standard and the browser vendors to cange this.
> Then there is the issue of consistency, if natively disabled elements
> are removed from the focus order, I assume custom elements should as
> well.
> Sometimes this gets tricky, e.g. when writing JavaScript for keybord
> navigation within composite elements such as radio buttons or
> dropdowns you'd have to consider whether an element is disabled or not
> when you code the keyboard navigation behaviors.
> I agree with Jonathan (as I usually do) that 3.2.3 does not apply to
> form controls, only to "navigational elements", i.e. links.
> I'll make a confession, I think I've never called a 3.2.3 violation in
> a decade of WCAG audits, please don't tell anyone if that was a
> mistake. ;)
>
> Cheers
> -B
>
>
> On 2/25/19, Patrick H. Lauke < <EMAIL REMOVED> > wrote:
> > On 25/02/2019 10:34, Isabel Holdsworth wrote:
> >> 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.
> >
> > As probably said previously, to me as a sighted user, seeing controls
> > that are disabled still gives me hints/information that those
> > options/controls are there and that there are situations where I may be
> > able to use them (a la "presumably, depending on other choices I make in
> > this form, I can also activate X"). However, this additional information
> > is not always very helpful/relevant.
> >
> > So it's a contextually dependent judgement call, really.
> >
> > P
> > --
> > Patrick H. Lauke
> >
> > www.splintered.co.uk | https://github.com/patrickhlauke
> > http://flickr.com/photos/redux/ | http://redux.deviantart.com
> > twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > > > > > > > >
>
>
> --
> Work hard. Have fun. Make history.
> > > > >