Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: request: accessibility for blind users (Read 9321 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

request: accessibility for blind users

Hi all,
I have recently switched from Winamp to Foobar2000. For the most part, FB2k is more accessible "out of the box" than Winamp and its use of mostly standard controls (such as scroll bars for the equaliser, real menus, standard context menus, etc.) makes it very nice to use with a screen reader for a blind user. However, there are two major issues I can think of that need to be addressed before the player is fully accessible:
* Preferences dialogue tabbing: At present, one can tab between the tree view and the close and reset all buttons in the preferences dialogue, but one cannot, at least as far as I have been able to determine, access the actual controls for the item selected in the tree view. This makes using the preferences dialogue somewhat difficult. It would be great if these controls were always accessible with the tab key, or perhaps the f6 key or similar could be used to switch between 'panes'; the tree view/reset all/close controls in one pane, and the controls for the item selected in the tree view in the other.
* Jump to time component: Currently, the jump to time component makes use of a scroll bar to set the time to which one wishes to jump. While this is useable, it would be much easier, particularly for a blind user, to be able to type a time (in the form min:sec) into an edit field. (Obviously, this couldn't really work for jump instantly; perhaps the edit field could be disabled if jump instantly was checked.)

Thanks for such a great program. It is great overall, but I was impressed with just how accessible it is right out of the box. It shows that a program can be accessible if it uses standard controls without necessarily having to go to great lengths to ensure its accessibility.
Keep up the great work!

Jamie

request: accessibility for blind users

Reply #1 –
Quote
* Preferences dialogue tabbing: At present, one can tab between the tree view and the close and reset all buttons in the preferences dialogue, but one cannot, at least as far as I have been able to determine, access the actual controls for the item selected in the tree view. This makes using the preferences dialogue somewhat difficult. It would be great if these controls were always accessible with the tab key, or perhaps the f6 key or similar could be used to switch between 'panes'; the tree view/reset all/close controls in one pane, and the controls for the item selected in the tree view in the other.

Thanks for the hint, I'll enable that for future releases of my plugins.

Hint for other plugin developers: Set the WS_EX_CONTROLPARENT extended style for your config dialogs (can be done in MSVC's dialog editor). Perhaps foobar should enforce this style to be set.

request: accessibility for blind users

Reply #2 –
Hi all,
The proper preferences dialogue tab navigation introduced in version 0.7.6 is great and exactly what I was looking for. On a different note, why does Foobar use a custom control for its playlist view rather than a standard list view or the like? (There may be visual differences I am not aware of, not having actually seen the playlist as it appears on screen.) Screen readers can read the playlist window without problems generally speaking, although selection does not speak as well as it could (selecting multiple items). It just struck me as odd that everything else uses standard controls (which is great for accessibility), right down to the status bar, but not the playlist window.

I have also been in contact with several blind users using one of the most prevalent Windows screen readers called "JAWS for Windows" (which I use myself) who cannot read the playlist window at all. A friend was able to read the playlist for some time, until one day it suddenly stopped reading. He cannot think of anything that has changed, which unfortunately is incredibly unhelpful. One user emailed me after seeing my initial message on this forum about accessibility saying that a friend of his was having this problem, and recently, another friend reported the same (he was actually completely unaware of the playlist window's existence until he saw it on my computer, which is a shame since it is perhaps one of Foobar's nicest interface features). Where this occurs, the playlist window works and appears normally on screen, but the screen reader cannot seem to detect it at all, even when reviewing the screen which usually detects all text. In a large list, the scroll up and scroll down symbols are detected, but nothing in between; JAWS just reports the area as blank. We tried a demonstration copy of Window Eyes, another prevalent screen reader for Windows, which seemed to detect the window with no trouble. I know this information is incredibly unhelpful and sketchy in terms of determining the problem. The only reason I post here is that the forum user who contacted me noted that older versions of Foobar (0.58? I am new to Foobar as of 0.70) read with no problems on the same system. I have tried both the new and old interfaces on a set up which exhibits this problem with no change. Has anything major changed in terms of the actual playlist window structure since 0.58 or there abouts?

My apologies for the lack of detail; I realise that it is almost impossible to render any assistance with this little information, but thus far, I have been unable to determine, despite my best efforts, even a hint as to what might be causing this problem. We have tried different screen resolutions, colour settings, etc. with no effect.

Any information would be greatly appreciated.

Jamie

request: accessibility for blind users

Reply #3 –
A further accessibility request: I seem to remember that the 'key' field in the keyboard shortcuts dialogue was once tabbable (once you had managed to enter the sub-dialogue for that page, thus making it tabbable, something which is no longer an issue in 0.7.6). In any case, I can no longer tab to the 'key' field to press the shortcut key I want to use. The problem with making this field tabbable is of course that one can't assign tab and shift+tab if one wishes. Even clicking on this field using the mouse cursor, one can't assign tab and shift+tab anyway, so this is probably not new. (As a point of curiosity, is assigning tab or shift+tab possible? I have no idea why someone would want to do this, but it is interesting nevertheless.) If assigning these keystrokes is a requirement, there are a few work arounds I can think of; I will post them if they are required.

Jamie

request: accessibility for blind users

Reply #4 –
Seems like previous versions of foobar used a custom control for the playlist, while recent versions draw the playlist directly on the screen.

Just out of curiosity, have you ever tried foo_dbsearch? If so, did the resultlist work with your screen reader (it is a custom control as well)?

request: accessibility for blind users

Reply #5 –
I suspect you were right about the playlist being drawn directly to the screen; that probably would cause issues with a screen reader, while generally, custom list and edit controls are not a huge problem assuming that the window can somehow be identified (preferably by class name). Custom check boxes and radio buttons can be a bit of a problem, but that isn't an issue here. I am not sure why the issues occurred on some configurations and not others (mine always seemed to work), but in any case, the screen reader compatibility option in 0.7.7 is just the fix we needed, at least as far as one person was concerned. Thank you very much to the developers! Out of curiosity, I assume that this either draws the text differently or reverts to the old method?

The only real issues now are making the 'key' field in the shortcut keys dialogue tabbable or otherwise accessible via the keyboard and adding an edit field to the jump to time component into which a value can be entered, both of which I have mentioned previously. I would take a look at the source to the jump to time component myself, but my C++ programming is pretty pathetic, as is my programming for a GUI.

Thanks once again; response to accessibility requests by Foobar developers thus far is just about the best I have ever seen, and that's saying a lot. :-)

Jamie

request: accessibility for blind users

Reply #6 –
It is great to see someone putting so much effort into accessibility features. Thanks.

One thing that could be improved in the configuration dialog box for 0.7.7b is adding the F6 (and shift F6 shortcut) to navigate between panes.

request: accessibility for blind users

Reply #7 –
Hrm... I don't know that I understand why you would want this. I guess it would save a couple of presses of the tab key, but remember that one shift+tab back from the tree view takes you to the last option in the dialogue, so if you want a shorter way of getting to some options, you can do that.

Jamie

request: accessibility for blind users

Reply #8 –
Just standard practice: it is there in all of microsoft applications. For example you can try it in explorer, a help window, or any mmc console.

I think it should also make it easier to navigate for blind users since you know you can use that key to change section, and do not need to go through multiple presses of the tab keys paying attention to where you end up everytime.

request: accessibility for blind users

Reply #9 –
Point taken. Actually, I was playing with the preferences dialogue last night and I noticed it probably would be a tad easier if this were implemented. I am not sure how easy it would be to implement, though; depends how the individual component dialogues work and whether you can simply set focus to the first item in the dialogue, etc. I'm happy with the tabbing for now, though, but if it isn't hard to implement, it would be nice.

Jamie

request: accessibility for blind users

Reply #10 –
It would be cool if foobar became so usable to blind people that it became a sort of standard for blind computer users. 
 

request: accessibility for blind users

Reply #11 –
Hi again,

Sorry to keep on about this issue, but Foobar2000 is so close to being fully accessible that I would hate to see a few little issues cloud the fact.

In the Foobar2000 0.8betas, in the Main menu items preferences, one cannot enter the context menu by pressing either the applications key or shift+f10; as far as i can tell, only right clicking will bring up this dialogue. Screen readers have the ability to click the mouse anyway, even if it requires a few more keystrokes, so this is more a keyboard support request than a specifically 'blind users' accessibility request. Also, the inability to access the 'key' field in the Keyboard shortcuts preferences with the keyboard (i.e. cannot tab to the field or set focus to it using a keystroke) is still an issue.

Jamie

request: accessibility for blind users

Reply #12 –
Hello

First of all, thank you all for foobar. I have been using it for months now and I love this software.

I have been testing fb 0.7.7b with a blind friend who uses Jaws. The most important problem we found was with the focus in the playlists.  I think the problem is that foobar doesn't tell Windows where the focus is when moving from track to track. Foobar just changes the color of the track the user just left and the color of the track he arrives on.

Why is it important? Because for a blind user, finding which line is a different color from the others is not an instantaneous operation as for normally sighted people. A blind user must browse the lines until finding the one he is looking for. Some screen readers may offer commands to do this, but this still not as immediate as for normally sighted people and it could do mistakes (what if two different controls have the same color ?). If foobar gave Windows proper focus information, screen readers would be able to tell the user where the focus line is. They would also be able to perform "focus tracking", that is when the user moves around using the direction keys, the screen reader can say the contents of the new line automatically (or a braille display will show automatically the new line).

We have discovered that the Playlist search uses the focus perfectly: when moving in the results list a Braille display follows the line automatically.

Frederic
Frederic Da Vitoria

request: accessibility for blind users

Reply #13 –
It is interesting that you have this problem. Foobar focuses correctly for me with three exceptions:
  • If I press enter on a track to play it, the focus seems to move wherever it pleases in the playlist. However, moving up or down through the playlist or pressing space to select and deselect the current item moves the cursor back where it should be.
  • When files are first loaded into Foobar2000 using the open dialogue (always reproduceable as far as I can tell), sometimes when opening from elsewhere (e.g. Explorer), and sometimes when starting Foobar2000 (these last two seem to occur frequently but intermittantly) the focus will move to somewhere below the playlist which simply reads as blank. The cursor can be refocused as above, although if you only have one file in the playlist, obviously only the second option is available.
  • If an item is deselected usign the space bar (so that no item is highlighted), the cursor loses focus. Pressing space to select again or moving the cursor will refocus.
Note also that JAWS (on my system at least) reports that the current item is 'highlighted', not just a colour change. Later versions of JAWS allow colours to be set which will signify highlighting, though I suspect this should not be necessary. This means that even if the cursor did not track, the name of the current item would probably still be read, since JAWS speaks new highlighted text by default.

I am using Foobar2000 0.8beta10 at present, but I am almost certain that all of this applies to 0.7.7b on my system.

Jamie

request: accessibility for blind users

Reply #14 –
I sent foobar 0.8 beta 10 to my friend and he just phoned me back. Same symptoms. We must be missing something here but I can't see what. My friend is using Jaws 4.02 on a Windows 98 SE desktop. He tested Foobar2000 0.7.7 and 0.8 beta 10 with the same results. He didn't tell if if he checked the Playlist search window again, but I am not sure it matters.

What focus tracking trick could Jaws be using that works with you and not with my friend?

And what kind of focus is Foobar using in the general Playlist that is different from the focus used in the Playlist search window? Of course, only foobar developers would be able to answer to this last question.

The only workaround I could find was reducing foobar's window until only one playlist line appears.
Frederic Da Vitoria

request: accessibility for blind users

Reply #15 –
Quote
And what kind of focus is Foobar using in the general Playlist that is different from the focus used in the Playlist search window? Of course, only foobar developers would be able to answer to this last question.

The list in the Playlist search window is a standard Windows control, while the playlist itself is a custom control. This should be the reason for the differences in focus tracking that you experience.

request: accessibility for blind users

Reply #16 –
Thanks for your answer.

Quote
The list in the Playlist search window is a standard Windows control, while the playlist itself is a custom control. This should be the reason for the differences in focus tracking that you experience.

Probably. And since Jamie doesn't experience any problems, either he is using a different (smarter) version of Jaws, or he is using another Windows version.

Is there any chance that in a future version the playlist could use a standard control (at least in screen reader compatibility mode)? Maybe this could be implemented as a special UI.

Frederic
Frederic Da Vitoria

request: accessibility for blind users

Reply #17 –
Quote
Is there any chance that in a future version the playlist could use a standard control (at least in screen reader compatibility mode)?

I'll leave that question for Peter and the authors of alternative user interfaces.
Quote
Maybe this could be implemented as a special UI.

There was a simply user interface that used only standard controls called foo_ui_notepad, though I don't know, if it is still maintained. (Just checked this, the old link seems to be broken.)

edit: Seems like I found the wrong link using the forum search. Thanks to witt for pointing at the correct link.

request: accessibility for blind users

Reply #19 –
Quote
Is there any chance that in a future version the playlist could use a standard control (at least in screen reader compatibility mode)? Maybe this could be implemented as a special UI.

In the preferences under "Display - Default user Interface" I noticed an option I didn't see before: "Screen reader compatibility mode (playlist may flicker)"
Maybe this will help you.

request: accessibility for blind users

Reply #20 –
My friend tested the foo_ui_notepad.dll, and the results were actually worse than with foo_ui_std.dll: he can't see anything in the playlist. I just checked with Windows Inspector (foobar2000 v0.8), if I correctly guessed the controls, the control used by foo_ui_notepad.dll (playlist_view_class) is different from the one used by foo_ui_std.dll (???) and from the one used by the Playlist search (ListBox).
Frederic Da Vitoria

request: accessibility for blind users

Reply #21 –
Quote
Jump to time component: Currently, the jump to time component makes use of a scroll bar to set the time to which one wishes to jump. While this is useable, it would be much easier, particularly for a blind user, to be able to type a time (in the form min:sec) into an edit field.

Few people would use the former jump to time component (with scroll bar) now that there is a seek bar in the main window, which seems to be incredibly convenient and fast for sighted users. However, the ability to jump to a time entered via the keyboard is still much more convenient for blind users. So, I was on #foobar2000 IRC a few days ago discussing such a plugin, and Everwicked modified the foo_stfu plugin (the old jump to time plugin) to do just that. (Thanks, Everwicked! :-) ) If anyone else wants this, I have made the binary and source available for download.

Jamie

request: accessibility for blind users

Reply #22 –
The following features/fixes are, in my view, the most critical as far as accessibility is concerned
  • (noted previously) The ability to tab to the 'key' field in the 'Keyboard Shortcuts' section of preferences. I am told the inability to do this is due to a missing WS_TABSTOP window style.
  • The ability to tab to the tab control in the 'Title formatting' section of preferences which allows one to select the formatting string in question ('Status bar', 'Main window title', etc.). Could this also be a simple missing WS_TABSTOP style?
  • (noted previously) The ability to activate the context menu for an item in the 'Main menu items' section of preferences by pressing the applications key. Currently, one can only activate this menu by using the right mouse button.
These would be nice, but are certainly less important:
  • Automatic enabling of the standard menu when screen reader compatibility mode is enabled. The toolbar menus do not read well at all with my screen reader (JAWS), and I suspect this will be the case for other screen readers also. (Thanks to ssamadhi97 on IRC for helping me figure this one out - it had been bugging me for months. For any blind users having menu bar issues in later versions of Foobar2000, move to anywhere on the toolbar with the mouse cursor (the fake menu bar or the 'Order' text below the title bar, for example) and right click. If 'Menu' is checked, uncheck it to disable the toolbar menus and enable the standard ones.)
  • The ability to set focus to the playlist tab control using the keyboard. Currently, one can ctrl+tab or ctrl+shift+tab between playlists, but cannot actually focus on the tab control. This would also require that the applications key access the context menu for the playlist when focused on the tab control. One way of implementing this keyboard focus would be to allow tab and shift+tab to switch focus between the playlist window and the playlist tab control while in the main window. Note that this is extremely low priority, as all of these functions can be performed with keyboard shortcuts. Also, ctrl+f4 and ctrl+w have now been assigned to remove the active playlist by default, which makes a hell of a lot of sense.
Thanks once again for such a great audio player and, on top of that, one of the most accessible applications 'out of the box' I have ever had the privellege to use.

Jamie

[edit]Added another feature to the 'most critical' list, changed some wording.

request: accessibility for blind users

Reply #23 –
Hi, I've edited the exe and added 2 WS_TABSTOP, which should fix the first 2 points of your post.
[link removed] (backup and replace your program files\foobar2000\foobar2000.exe with the one in the above archive.)
Be assured they're strictly the only alterations I made to the original executable. Hope that helps

I'm afraid the other points you raised may not be fixed using this method though. Note that you could "tabstop" on playlist tabs if you used foo_ui_columns, but then again not everything in the component's preferences dialog can be given focus with the keyboard.

Edit: Here is an altered foo_ui_columns.dll that should make possible to tab to the tab controls in the Column UI section of Preferences. BTW I do hope that Peter and musicmusic allow me to post slightly altered versions like those, if not I'd remove them ASAP

[Edit: Redistribution of modified binaries without express written permission is a violation of the license agreement.]

request: accessibility for blind users

Reply #24 –
I have been using fb2k 0.9 betas for a few months now, and am loving them!

In terms of accessibility, a few long-standing issues have been fixed:
  • The 'key' field is now tabbable in Keyboard Shortcuts.
  • The applications key can now be pressed on the current item in {Context,Main} Menu Items preferences.
  • MSAA in the playlist (discussed in another thread). This is potentially great!
Two issues remain from 0.8:
  • The tab control in Title Formatting preferences is not tabbable.
  • There is no way to focus on the playlist tab control in the main window or to activate the context menu for a playlist (see prior post). By no means essential, though; one can get around this using shortcut keys.

Unfortunately, 0.9 introduces one new issue, perhaps the largest so far. The standard menus are gone!  I mentioned this in one of the beta discussion threads. In 0.8, these could be enabled/disabled via the toolbar context menu, but this is no longer an option. This is not insurmountable; menus can be accessed by pressing alt plus the menu's shortcut key (alt+f for Foobar2000, for example) or pressing f10 to access the menu bar. However, one cannot press the alt key alone to access the menu bar, and even when pressing f10, the menu bar does not read as a standard menu bar should. It does read the items on the bar as you move left and right, but does not announce that it is a menu bar or read shortcut keys. Having said all of this, this is a relatively minor complaint (the application is still incredibly accessible). If the standard menu bar could be re-implemented, that would be great. If this really isn't possible or is too much work for whatever reason, having the alt key activate the fake menu bar would be nice. If none of the above can be worked, well, such is life. :-)

I don't want to come across as ungrateful; as I've said countless times (waits for countless groans), I'm very appreciative of the accessibility fb2k offers.

Jamie