WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Inactive controls, focus behaviour

for

From: mhysnm1964@gmail.com
Date: Feb 27, 2019 4:30AM

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.

-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of Mallory
Sent: Wednesday, February 27, 2019 9:52 PM
To: Maxability A11Y < <EMAIL REMOVED> >; WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] Inactive controls, focus behaviour

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 REMOVED> Sent from my iPhone
>
> > On 25-Feb-2019, at 5:23 AM, 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-disable
> > d-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
> > > > > > archives at http://webaim.org/discussion/archives
> > > > > > > > archives at http://webaim.org/discussion/archives
> > > > > archives at http://webaim.org/discussion/archives
> >