WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Inactive controls, focus behaviour

for

From: Mallory
Date: Feb 27, 2019 3:52AM

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