E-mail List Archives

Search E-mail List Archives for

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

From: Jeff Gutsell
Date: Tue, Jan 22 2019 2:30PM
Subject: Managing disabled state of buttons
No previous message | Next message →

Hi All,

When disabling standard buttons, I know that we are encouraged to use the
standard html attribute instead of "aria-disabled." However, I am puzzled
about the best approach for making a disabled button discoverable by a
screen reader. This button is not in the page's tab sequence, and perhaps
sometimes that does not matter.

I am working on a page where the users will wonder what to do if they do not
know that certain buttons exist. Among other things, they may be unaware of
navigating over such buttons.

Jeff

From: glen walker
Date: Tue, Jan 22 2019 5:58PM
Subject: Re: Managing disabled state of buttons
← Previous message | Next message →

This is a common subject discussed here on WebAIM, IAAP/Communications, and
the accessibility slack channel (web-a11y.slack.com).

The gist of most of the discussions is to try to avoid disabled buttons and
just handle a button selection with proper error checking. That is, rather
than disable a button until all form elements are filled in (or whatever
causes the button to be enabled), let the user select the button and then
tell them what has to be filled in before the info can be submitted.
Providing that information as instructions elsewhere on the page is a good
idea too.

If a button has to be disabled, screen reader users still have several ways
to discover the button even if it's not in the tab sequence. Using the
up/down arrow keys, you can walk the accessibility tree and discover every
element on the page. Using the 'B' quicknav key, you can access every
button, whether disabled or not. Related to that, using ins+shift+b with
jaws will give you a list of buttons on the page. You can navigate by form
elements, again whether disabled or not. On iOS you can set your rotor to
"buttons" then swipe up/down to navigate among all the buttons. So there
are lots of ways to discover a disabled button besides tab order.

So the first choice is to try to avoid disabled buttons. Secondly, if it
has to be disabled, don't fret over it. It's still discoverable.

Glen


On Tue, Jan 22, 2019 at 2:30 PM Jeff Gutsell < = EMAIL ADDRESS REMOVED = > wrote:

> Hi All,
>
> When disabling standard buttons, I know that we are encouraged to use the
> standard html attribute instead of "aria-disabled." However, I am puzzled
> about the best approach for making a disabled button discoverable by a
> screen reader. This button is not in the page's tab sequence, and perhaps
> sometimes that does not matter.
>
> I am working on a page where the users will wonder what to do if they do
> not
> know that certain buttons exist. Among other things, they may be unaware of
> navigating over such buttons.
>
> Jeff
>
> > > > >

From: Birkir R. Gunnarsson
Date: Wed, Jan 23 2019 4:01AM
Subject: Re: Managing disabled state of buttons
← Previous message | Next message →

Well answered.
Sure, you can add event.preventDefault() and aria-disabled="true" to
the button, along with cSS styling to gray it out, but it seems like
excessive custom coding just to keep a disabled button discoverable
with the tab key.
But it is an option, and perhaps easier than accessible error handling
for invalid values detected after form submit.



On 1/22/19, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
> This is a common subject discussed here on WebAIM, IAAP/Communications, and
> the accessibility slack channel (web-a11y.slack.com).
>
> The gist of most of the discussions is to try to avoid disabled buttons and
> just handle a button selection with proper error checking. That is, rather
> than disable a button until all form elements are filled in (or whatever
> causes the button to be enabled), let the user select the button and then
> tell them what has to be filled in before the info can be submitted.
> Providing that information as instructions elsewhere on the page is a good
> idea too.
>
> If a button has to be disabled, screen reader users still have several ways
> to discover the button even if it's not in the tab sequence. Using the
> up/down arrow keys, you can walk the accessibility tree and discover every
> element on the page. Using the 'B' quicknav key, you can access every
> button, whether disabled or not. Related to that, using ins+shift+b with
> jaws will give you a list of buttons on the page. You can navigate by form
> elements, again whether disabled or not. On iOS you can set your rotor to
> "buttons" then swipe up/down to navigate among all the buttons. So there
> are lots of ways to discover a disabled button besides tab order.
>
> So the first choice is to try to avoid disabled buttons. Secondly, if it
> has to be disabled, don't fret over it. It's still discoverable.
>
> Glen
>
>
> On Tue, Jan 22, 2019 at 2:30 PM Jeff Gutsell < = EMAIL ADDRESS REMOVED = > wrote:
>
>> Hi All,
>>
>> When disabling standard buttons, I know that we are encouraged to use the
>> standard html attribute instead of "aria-disabled." However, I am puzzled
>> about the best approach for making a disabled button discoverable by a
>> screen reader. This button is not in the page's tab sequence, and
>> perhaps
>> sometimes that does not matter.
>>
>> I am working on a page where the users will wonder what to do if they do
>> not
>> know that certain buttons exist. Among other things, they may be unaware
>> of
>> navigating over such buttons.
>>
>> Jeff
>>
>> >> >> >> >>
> > > > >


--
Work hard. Have fun. Make history.

From: Jared Smith
Date: Wed, Jan 23 2019 5:55AM
Subject: Re: Managing disabled state of buttons
← Previous message | No next message

While Birkir's recommendation makes the button navigable, it
introduces a separate problem. Something that is navigable with the
keyboard inherently means that it is functional. In this case the
button would not be functional, but would be disabled (which is why
the browser removed it from the navigation flow to begin with). So
then the user may confused by interacting with something that doesn't
do anything.

A much more comprehensive analysis of the difficulties of disabled
buttons can be found at https://axesslab.com/disabled-buttons-suck/
I'd stick with Glen's recommendation to not disable the button, and if
you do, know that it's likely to pose difficulties for lots of users.

Jared Smith
WebAIM.org