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.
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.
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.
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.
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).
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.
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".