For example, if we have a set up wizard with 3 steps, and the user is on step 1, should the user be able to focus on the control to continue to the next step, regardless of whether or not that control is disabled or not? The control's state (enabled or disabled) depends on whether the user has completed the requirements in the current step (in this case, step 1). I think disabled elements should be focusable, just to make things less complicated and confusing.
asked Jan 4, 2017 at 15:04
-
4From the question title, I had expected a concrete benefit for accessibility (possibly even for the kind of accessibility for disabled people, such as screenreaders that provide information on the focused element). As it stands, no real point is made in favour of making disabled elements focusable, as the claim that making them non-focusable is "complicated and confusing" is extremely vague.– O. R. MapperJan 4, 2017 at 15:30
Add a comment
|
6 Answers
I do work on a professional webapp for visually impaired, screen reader users.
We do user testing regularly, and this has been raised many times during user test sessions that disabled elements that are required for completing a step/ flow (or are just generally too important to be missed) should be focusable with TAB key.
If disabled buttons are not focusable with TAB, our user would occasionally miss that the button ever exists, and they will never find it.
This is a blocking issue
Additionally, as @Andrew Martin said, if you write the reason of disability in the tooltip of the button (which may not be a good practice, but still it could happen to be), then it may never be read by screen readers like JAWS because the descriptions / tooltips only read description on TAB focus.
So I would definitely say that in your use case you may totally go for it.
-
7Very interesting. How would you communicate the user that although the button is being focused it is disabled?– AlvaroJan 4, 2017 at 15:55
-
6@Alvaro IMHO it shouldn't be really disabled. It should look differently from buttons working normally, it should show a tooltip and when clicked, it should explain why it can't do what it's supposed to do (with a possibly long text, unsuitable for a tooltip). Obviously, there should be other ways to find out how the application works, but someone may miss it and a then there's nothing more frustrating than a button disabled for no obvious reason. For visually impaired people it's probably even worse. Jan 5, 2017 at 1:50
-
2Very good answer, I think too many people here answered without even TRYING to place themselves in the situation of a visually impaired person Jan 5, 2017 at 9:22
-
2@Alvaro , This isn't standard by any mean, but a way of doing it correctly is to create a button with aria-disabled="true" and a class that makes it look disabled, but do not use disabled="true". This way the button will look disabled and still be focusable. And the SR will read "Button disabled" and also read the descriptions– LethsJan 5, 2017 at 9:46
-
2@Leths, thanks, that is a way to implement it but it I think it is breaking the standards, kind of a hack. It is interesting because following the rules goes against some users. I wonder if the way the disabled button is used is incorrect or there is a correct way of handling this following the standards.– AlvaroJan 5, 2017 at 9:50
This is a bit of a tricky one.
Normally, with regular form elements, it would be best to fully remove anything you can't interact with or serves no purpose.
However, that particular button you're talking about (the "next step" button) can also act as a guide to the level of completion - i.e. you are not able to proceed to the next step until the form contains enough data.
The disabled state, in this instance, indicates to the user that they have not entered all the required data.
Regarding the focus issue, generally it is not a good idea to allow visible disabled elements to gain focus - focus implies the possibility of interaction. By implying interaction your users are likely to think that the button it faulty rather than disabled. The only situation where you might want to add focus is if the button contained a message stating why it was disabled - but this in itself is bad design as that message should be handled elsewhere in a more visible and understandable manner.
CORRECTION
Thanks to SteveD for pointing out the error here:
Preventing focus on a disabled element that is also used as a progress indicator (as in the case presented by the OP) also prevents it from being read by screenreader software. However, this can be fixed in the HTML:
As long as the HTML uses the disabled attribute, this will communicate to the user agent that the field is disabled, but only if the field can take keyboard focus
See the comments below for more details.
answered Jan 4, 2017 at 15:37
-
2Not sure I agree with the statement "it's not a good idea to allow visible disabled elements to gain focus". How else is a blind person going to know the field is disabled if they cannot place the disabled field into the keyboard focus?– SteveDJan 5, 2017 at 9:45
-
1@SteveD You make a good point and one that I'm not sure how to answer - this is definitely a tricky issue and I'm not convinced that mine was the best answer here. Jan 5, 2017 at 9:51
-
3As long as the HTML uses the disabled attribute, this will communicate to the user agent that the field is disabled, but only if the field can take keyboard focus. Everything else in your post makes sense, e.g. disabled implies the button can be enabled only if they meet some criteria, for example completing all required fields.– SteveDJan 5, 2017 at 10:06
As a marginal counterpoint to @Leths, a screenreader lets you get to every object on the page, whether disabled or not, unless they're specifically hidden from the screen reader using aria-hidden=true. I didn't want to add this as a comment to @Leths' posting because this is an important point related to the main question. That is, even if you decide not to allow focus to go to disabled objects, the screenreader user can still get to those objects. With JAWS (the most popular screenreader for the PC), you can use the virtual pc cursor or one of the JAWS accessory dialogs (such as Ctrl+Ins+B to get a list of buttons, with the disabled buttons having the text 'unavailable' appended to the button name).
Now, with that being said, a screenreader user will often TAB through the page to get a mental image of what's there, and tabbing will skip disabled buttons by default. If the user was so inclined, they could navigate the entire DOM using the virtual pc cursor, or they could bring up dialogs of all the buttons or checkboxes or radio buttons or whatever, but that's a bit tedious just to build your mental model of the page. Ideally, for the screenreader user, they should be able to tab to disabled objects. It might not be ideal for the sighted keyboard user, but it's not a terrible detriment to them either.
Edit: The logic is that only if an element responds to events it can be focused. However as @Leths comments from his experience this can be detrimental in some cases. So I guess the best thing to do is follow what your users would expect and what it would be most beneficial for them.
No, if the user can't interact with the element don't give the (focus) hint that it is possible.
The :focus pseudo-class applies while an element has the focus (accepts keyboard or mouse events, or other forms of input).
Source: W3
With a mouse a change of cursor indicates that the user can interact with the element. A Pointer, for example, tells the user that the element can be interacted.
With a keyboard the focus property indicates that the user can interact with the element.
The element in the state you have it doesn't allow any interaction from the user, so I wouldn't give the hint that there is some interaction available.
Here is an example from W3 of a disabled input which can't be focused.
-
3In this W3 example, they allow focus on the disabled buttons: w3.org/TR/wai-aria-practices-1.1/examples/listbox/listbox.html What do you make of this? Jan 4, 2017 at 15:27
-
@RalphDavidAbernathy, thanks very interesting, I could be wrong but I would say that example is kind of broken because the enabled buttons can't be focused, only if the button is the last one clicked.– AlvaroJan 4, 2017 at 15:32
-
2@RalphDavidAbernathy in this other W3 example the disabled input is not focusable.– AlvaroJan 4, 2017 at 15:36
Here is an example of the behavior I would expect from a wizard. In this case it is an uninstall dialog (the first program I could find to try it on). This is how it has been for as long as I can remember. Close and show details are the only available options, and tab swaps between the two.
So to answer the question, I would follow the convention that I am used to and fully disable non interactable buttons in the same way windows does. However, others (and maybe non windows users) may disagree.
Yes. Disabled buttons should be focusable. Not only because accessibility, but also to explain in alerts why it is disabled.
My rule of thumb is the relevancy of the command. Some buttons I hide when they are out of phase or context. Some I show and explain why is disabled when clicked.
For example: a view details of the process is only enabled to managers. The employee sees the command disabled. When clicked the alert explain what the function is and that he must ask his manager if needed. This avoids the employee fill a suggestion "would be nice to have an option to view the process details" to get an answer "ask your manager".
