By implying interaction your users are likely to think that the button it faulty rather than disabled. 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. The disabled state, in this instance, indicates to the user that they have not entered all the required data. you are not able to proceed to the next step until the form contains enough data. 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. By the way, I really like that you did that.Normally, with regular form elements, it would be best to fully remove anything you can't interact with or serves no purpose. Personally, I would love to just have the now playing box, and the playlist in the tab order, and when needed all the stuff in the left panel, which I can hide and unhide as needed.

Honestly, if there are ways to play, stop, skip to next track or go back via the keyboard, for us screen readers these extra controls can become redundant, and like I said, they also make for a lot more tabbing around. In trying to tab to the playlist, I managed to accidentally toggle the repeat track button, so when I finally managed to get playback working, it kept repeating the same track for a while until I finally figured out what was going on.

This morning, I had a station id selected that the system didn't like for some reason. Also, is there any way to hide player control buttons and only toggle them via hotkey? That would also minimize the amount of tabbing we have to do to get around the interface. For the now playing box, is there a certain part of the interface that I should unhide? In the view menu, I unchecked as much as I possibly could to keep the interface as simple as possible.

Nvda screen reader disable