E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 9 (In chronological order)

From: Detlev Fischer
Date: Sun, Feb 24 2019 11:22AM
Subject: Inactive controls, focus behaviour
No previous message | Next message →

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

From: Jonathan Avila
Date: Sun, Feb 24 2019 4:53PM
Subject: Re: Inactive controls, focus behaviour
← Previous message | Next message →

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

From: Isabel Holdsworth
Date: Mon, Feb 25 2019 3:34AM
Subject: Re: Inactive controls, focus behaviour
← Previous message | Next message →

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 ADDRESS 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
>
>
>

From: Patrick H. Lauke
Date: Mon, Feb 25 2019 3:59AM
Subject: Re: Inactive controls, focus behaviour
← Previous message | Next message →

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

From: Birkir R. Gunnarsson
Date: Mon, Feb 25 2019 5:25AM
Subject: Re: Inactive controls, focus behaviour
← Previous message | Next message →

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 ADDRESS 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.

From: Sean Curtis
Date: Mon, Feb 25 2019 4:01PM
Subject: Re: Inactive controls, focus behaviour
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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.
> > > > >

From: Maxability A11Y
Date: Wed, Feb 27 2019 3:36AM
Subject: Re: Inactive controls, focus behaviour
← Previous message | Next message →

Hi there,
I wrote an article sometime ago on this topic, it may help
http://www.maxability.co.in/2017/03/keyboard-interaction-for-disabled-elements/

Regards - Rakesh,
M: 9948243336, E: = EMAIL ADDRESS REMOVED =
Sent from my iPhone

> On 25-Feb-2019, at 5:23 AM, Jonathan Avila < = EMAIL ADDRESS 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
>
>
>

From: Mallory
Date: Wed, Feb 27 2019 3:52AM
Subject: Re: Inactive controls, focus behaviour
← Previous message | Next message →

Re reasons for keeping disableds in the tab order in my uninformed opinion:

There are two places where we've needed to allow it:
the first one is when designers thought it was a good idea to rely on tooltips for exposing information. Something I hate, but if we cannot prevent them from using this model, then disabled items need to be focussed. One client used these tooltips (javascripted, not title attributes) to inform the user WHY the controls were disabled (an editor in a readonly mode for example). Another (Gutenberg) uses hieroglyphics to visibly label controls and so a tooltip is necessary to let users know what their names are, and designers decided users ought to be able to access the names (and usually also a keyboard shortcut) at any time, regardless of disabled/enabled state.

I think the above is an anti-pattern and it would be much much nicer if users could click a control or set a setting stating "show me textual labels at all times", but it is otherwise a reason for allowing focus on disabled elements. So long as they're properly marked up, SR users are informed that these are disabled. Windows High Contrast users though are not.

The second place was following the ARIA grid pattern, which recommends disabled gridcells be able to gain focus for the reasons Detlev and Pat mentioned above (access the information even though (in say a calendar app) the date itself is not selectable). I believe this likely makes sense in an ARIA menu pattern as well, where menuitems exist and are visible but not selectable/chooseable.

So ARIA-foo'd widgets kind of make sense: they are not typical of native webby controlsanyway and so not acting exactly like natives (where disabled controls are not focusable) could be seen as not so strange after all. (Oh and I wish we could assign these widgets actual disabled states such that Windows High Contrast recognised these as disabled! Though this may cause confusion when authors attempt to make "disabled links" since this may make them appear to be buttons in WHC.)

For disabled submit buttons: I believe since the designer is usually attempting to convey information (this form indeed has a dedicated control for submitting instead of some weird autosave BUT things are not yet ready), a sentence directly above the disabled submit is a good idea. A bestus idea. An idea that would save me hair. I like my hair.

It tells the user WHY the button cannot be clicked/form cannot be submitted. Not being able to see the button clearly or at all matters less, because now we have a clear message stating the problem. The message is removed whenever the submit control is enabled. I recently attempted to use the poor GUI in Gnome on Linux for setting up openVPN and the submit control was greyed out, but could not discover the reason why until after searching AskUbuntu (and it turned out to be because of some inline cert keys bug!). An explanatory sentence would have worked better, as having the submit control disabled told me exactly bupkiss.

cheers,
_mallory

On Wed, Feb 27, 2019, at 11:37 AM, Maxability A11Y wrote:
> Hi there,
> I wrote an article sometime ago on this topic, it may help
> http://www.maxability.co.in/2017/03/keyboard-interaction-for-disabled-elements/
>
> Regards - Rakesh,
> M: 9948243336, E: = EMAIL ADDRESS REMOVED =
> Sent from my iPhone
>
> > On 25-Feb-2019, at 5:23 AM, Jonathan Avila < = EMAIL ADDRESS 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
> >
> >
> >

From: mhysnm1964
Date: Wed, Feb 27 2019 4:30AM
Subject: Re: Inactive controls, focus behaviour
← Previous message | No next message

As a user, I don't see it as a major issue if it is a part of the tab order or not. AS long as the status is clearly identified by assistive technology and the user knows the correct state. As I have seen pages with disabled items in the tab order and you kept pressing the button thinking it was active when it was not.

My pennies worth.