Suggestions for Improving BIAB Accessibility and GUI - 06/20/08 02:40 AM
Several aspects of the BIAB GUI make many of the BIAB utilities difficult to negotiate by those using screen readers such as JAWS. Although some of these difficulties can be overcome by developing custom scripts for JAWS and BIAB (which I've done to make parts of the program more useable), some of the problems are extremely difficult (if not impossible) to work around. I would like to see the BIAB developers peck away at modifying the GUI over time so that BIAB works better with screen readers and/or those who navigate via the keyboard.
I believe that many of the access issues are related to the fact that the BIAB GUI does not conform to Windows GUI conventions. Thus, fixing these issues would not only benefit those using screen readers but also might improve the customer experience of all users.
Here are several specific examples of how BIAB works differently than standard" Windows programs:
Note: Users of screen readers use keyboard navigation such as the tab and arrow keys to navigate through dialogs, etc. So, many of these (but not all) relate to how the focus of BIAB moves via keyboard navigation.
1. Order of tabbing in dialog boxes -
There should be a logical (and hopefully sequential) ordering of elements within a dialog so that hitting the tab key brings one to the next logical element within the dialog (or shift+tab moves to the previous element). Generally, the "OK / Cancel" buttons should be the last elements in the cycle and hitting tab once more should start the user at the beginning of the list again. In BIAB, this is not always the case.
As an example, go to the Opt / Midi and Audio Settings menu item.
Currently, the user must tab 10 times to get to the "OK" button. At this point, the user of a screen reader would assume that they are at the end of all options in the dialog. However, in this BIAB dialog, hitting tab several more times brings one to another sequence of options (starting with "Audio Settings"), and further tabbing brings one back to the beginning again. Thus, the tab order seems to start in the middle of the options (unlike standard Windows programs).
Another example of where tabbing does not seem to navigate the user in a logical or sequential order is in the Print Dialog (brought up with control+P). As I tab through this dialog I am told by a sighted user that they have a hard time following the focus since tabbing does not seem to move me in a sequential/logical manner through the dialog.
2. Tab pages and dialogs -
Many of the BIAB dialogs have lots and lots of options (which is great) that the user must tab through. It would be helpful if such dialogs were broken down into logical tab pages which could be navigated like other Windows tab pages.
A simple example of how this might be organized a bit better is the Opt / Preferences / Display dialog. Here, hit tab 13 times to get to the "OK" button. Thus far, all of the options which one navigated through apply to the "chord sheet". Tabbing several more times through the "OK / Cancel / Help" buttons brings the user to another set of options which apply to the Toolbar. Here is how this would be organized if a "standard" Windows GUI was used:
a. All of the "chord sheet options" would be in one tab page and all of the "toolbar" options would be in a separate tab page.
b. Hitting tab (or shift+tab) within one of the tab sheets would cycle the user through only the elements within that tab sheet. Thus, if within the "chord sheet" tab, hitting tab would only cycle around through the chord sheet" options.
c. Moving from within one tab sheet to another is accomplished by hitting control+tab (or shift+control+tab to move the other way). Thus, the user doesn't need to tab through many, many items just to get to another logical sequence of options.
d. The other way of getting to another tab sheet in standard Windows programs is to tab within a particular sheet until one lands on the title/name of that particular tab sheet. Then, hitting the right or left arrow key should bring the user to the element containing the title of the next or previous tab sheet. Then, subsequent hitting of the tab key should cycle the user through the elements of that sheet.
Abiding by these standards makes it much more efficient for the user to navigate through dialogs with lots of options. Thus, they should be grouped into logical sub-groups of associated elements within tab sheets that can be navigated by using the tab, arrow, and Control+tab key conbinations.
3. Radio boxes -
These are a particular problem with BIAB since the standard Windows conventions aren't used by BIAB. There are many examples of this in BIAB.
Here is the way radio boxes are supposed to work:
a. The user uses tab (or shift+tab) to navigate through a dialog box until they come to a set of radio buttons. At this point, they should land on the selected button within the group.
b. The user selects a radio button by arrowing up or down the list of radio buttons until they find the desired setting.
c. Hitting tab (or shift+tab) again should move the user out of the set of radio buttons (preserving the desired selection) and onto the next (or previous) element/option within the dialog.
Currently in BIAB, hitting tab (or shift+tab) continues to move the user through the set of radio buttons, selecting each as the user tabs, until finally the user is moved outside of the group of radio buttons and onto the next element/option in the dialog. Thus, with BIAB, the user has no way of selecting a particular radio button and having the choice "stick".
Such radio button combinations are spattered through many dialogs in BIAB. Examples include the Solist dialog, print dialog, etc. and the radio buttons contained within them.
In summary, the radio buttons should be grouped into a separate element which has a "tab stop" for that element (but not for each radio button within the grouping.
4. Combo boxes -
In standard Windows apps, Combo Boxes work the following way:
.a The user tabs to the Combo Box.
b. The user arrows up and down the list until they find the desired selection.
c. The desired selection can also be quickly found by using first letter navigation" to move through the list.
d. As with the case for radio buttons, hitting tab should move the user from the Combo Box onto the next element and preserve the selection.
The frustration now in BIAB is that, often, arrowing down a list brings up a pop-up window which the user has to dismiss. Thus, if one is looking for something far down the list, it takes a long time and many keystrokes.
Examples include the Opt / Preferences / Notation / Transpose Combo Box (for transposing to a particular instrument), the Opt / Midi and Audio Options / DXI / Synth Selection Combo box (here one can't even arrow through a synth which, for some reason, may not be a valid synth or plug-in).
Also, all such Combo boxes should allow "first letter navigation". For example, although one can arrow through the combo box which comes up when selecting an instrument for a particular track (Alt+Shift+p), first letter navigation doesn't work and one has to arrow many times to select an insturment far down the list.
5. The Ear Traning Window -
This is an example of a dialog which could be made greatly more accessible if it were organized better by using some of the concepts above such as organizing like elements into tab sheets, being able to tab to different elements in a logical sequence, etc. Right now this dialog seems to be haphazardly organized into windows and sub-windows with no logical connection and/or hierarchy. One cannot use the tab or control+tab keys to get from the "Chord Tutor" to "Interval Tutor" windows, etc. Using the arrow keys to navigate through buttons and other selections also does not work.
Another issue which makes this window difficult (if not impossible) to script with JAWS is that the title of the window seems to change. Sometimes when this window pops up the real name of the window is "Ear Training Window". Other times when the window pops up, it's reall name is "Guess Interval". In JAWS, one has the ability to look for specific windows with control IDs, real names, handles, etc. If these elements are not consistent, JAWS can't grapple with them.
6. Windows popping up over other windows -
Sometimes a new window will pop up in BIAB and that window obscures info from the window which has focus. For example, the "Big Lyrics" window may pop up unbeknown to the blind user) and obscure info that JAWS is looking for (like the beat an measure).
7. JAWS seeks PC cursor or "edit" cursor --
JAWS (and other screen readers) have several ways of providing feedback to the user. For example, JAWS can be set to speak newly highlighted text which appears on the screen. Thus, as a song plays in BIAB, JAWS can be made to speak the chords as each is highlighted (in fact, the scripts I wrote will make JAWS speak the chords in a "natural" way such as "C major 7" for "CMaj7", or "C flat over A bass" for "Cb/a").
Another way which JAWS attempts to provide feedback and help navigate is by following either the PC (or "edit") cursor (as opposed to the "mouse" pointer If, for example, the PC or edit cursor tracked the chords/beats as a user arrowed through a tune with the left and right arrow keys, the user could have better feedback on what currently has the focus. In many Windows programs, the PC cursor is controlled by the arrow and tab keys.
8. The DXI Settings dialog --
This dialog (accessed by going to Opt / Midi and Audio Settings / DXI Settings is almost impossible to navigate with JAWS. Tab and arrow keys do not navigate from one combo box to another. Also, it is difficult to move between tab sheets. Although this has been partially made accessible by the JAWS scripts which have been developed, this is less than optimal.
Anyway, I am hoping that some of these suggestions can be passed along to the BIAB developers and that this wonderful program can be made more accessible in future releases. Hopefully such modifications can be slowly made over time before the next release cycle and much of the code and feature set become frozen.
-- Pete
I believe that many of the access issues are related to the fact that the BIAB GUI does not conform to Windows GUI conventions. Thus, fixing these issues would not only benefit those using screen readers but also might improve the customer experience of all users.
Here are several specific examples of how BIAB works differently than standard" Windows programs:
Note: Users of screen readers use keyboard navigation such as the tab and arrow keys to navigate through dialogs, etc. So, many of these (but not all) relate to how the focus of BIAB moves via keyboard navigation.
1. Order of tabbing in dialog boxes -
There should be a logical (and hopefully sequential) ordering of elements within a dialog so that hitting the tab key brings one to the next logical element within the dialog (or shift+tab moves to the previous element). Generally, the "OK / Cancel" buttons should be the last elements in the cycle and hitting tab once more should start the user at the beginning of the list again. In BIAB, this is not always the case.
As an example, go to the Opt / Midi and Audio Settings menu item.
Currently, the user must tab 10 times to get to the "OK" button. At this point, the user of a screen reader would assume that they are at the end of all options in the dialog. However, in this BIAB dialog, hitting tab several more times brings one to another sequence of options (starting with "Audio Settings"), and further tabbing brings one back to the beginning again. Thus, the tab order seems to start in the middle of the options (unlike standard Windows programs).
Another example of where tabbing does not seem to navigate the user in a logical or sequential order is in the Print Dialog (brought up with control+P). As I tab through this dialog I am told by a sighted user that they have a hard time following the focus since tabbing does not seem to move me in a sequential/logical manner through the dialog.
2. Tab pages and dialogs -
Many of the BIAB dialogs have lots and lots of options (which is great) that the user must tab through. It would be helpful if such dialogs were broken down into logical tab pages which could be navigated like other Windows tab pages.
A simple example of how this might be organized a bit better is the Opt / Preferences / Display dialog. Here, hit tab 13 times to get to the "OK" button. Thus far, all of the options which one navigated through apply to the "chord sheet". Tabbing several more times through the "OK / Cancel / Help" buttons brings the user to another set of options which apply to the Toolbar. Here is how this would be organized if a "standard" Windows GUI was used:
a. All of the "chord sheet options" would be in one tab page and all of the "toolbar" options would be in a separate tab page.
b. Hitting tab (or shift+tab) within one of the tab sheets would cycle the user through only the elements within that tab sheet. Thus, if within the "chord sheet" tab, hitting tab would only cycle around through the chord sheet" options.
c. Moving from within one tab sheet to another is accomplished by hitting control+tab (or shift+control+tab to move the other way). Thus, the user doesn't need to tab through many, many items just to get to another logical sequence of options.
d. The other way of getting to another tab sheet in standard Windows programs is to tab within a particular sheet until one lands on the title/name of that particular tab sheet. Then, hitting the right or left arrow key should bring the user to the element containing the title of the next or previous tab sheet. Then, subsequent hitting of the tab key should cycle the user through the elements of that sheet.
Abiding by these standards makes it much more efficient for the user to navigate through dialogs with lots of options. Thus, they should be grouped into logical sub-groups of associated elements within tab sheets that can be navigated by using the tab, arrow, and Control+tab key conbinations.
3. Radio boxes -
These are a particular problem with BIAB since the standard Windows conventions aren't used by BIAB. There are many examples of this in BIAB.
Here is the way radio boxes are supposed to work:
a. The user uses tab (or shift+tab) to navigate through a dialog box until they come to a set of radio buttons. At this point, they should land on the selected button within the group.
b. The user selects a radio button by arrowing up or down the list of radio buttons until they find the desired setting.
c. Hitting tab (or shift+tab) again should move the user out of the set of radio buttons (preserving the desired selection) and onto the next (or previous) element/option within the dialog.
Currently in BIAB, hitting tab (or shift+tab) continues to move the user through the set of radio buttons, selecting each as the user tabs, until finally the user is moved outside of the group of radio buttons and onto the next element/option in the dialog. Thus, with BIAB, the user has no way of selecting a particular radio button and having the choice "stick".
Such radio button combinations are spattered through many dialogs in BIAB. Examples include the Solist dialog, print dialog, etc. and the radio buttons contained within them.
In summary, the radio buttons should be grouped into a separate element which has a "tab stop" for that element (but not for each radio button within the grouping.
4. Combo boxes -
In standard Windows apps, Combo Boxes work the following way:
.a The user tabs to the Combo Box.
b. The user arrows up and down the list until they find the desired selection.
c. The desired selection can also be quickly found by using first letter navigation" to move through the list.
d. As with the case for radio buttons, hitting tab should move the user from the Combo Box onto the next element and preserve the selection.
The frustration now in BIAB is that, often, arrowing down a list brings up a pop-up window which the user has to dismiss. Thus, if one is looking for something far down the list, it takes a long time and many keystrokes.
Examples include the Opt / Preferences / Notation / Transpose Combo Box (for transposing to a particular instrument), the Opt / Midi and Audio Options / DXI / Synth Selection Combo box (here one can't even arrow through a synth which, for some reason, may not be a valid synth or plug-in).
Also, all such Combo boxes should allow "first letter navigation". For example, although one can arrow through the combo box which comes up when selecting an instrument for a particular track (Alt+Shift+p), first letter navigation doesn't work and one has to arrow many times to select an insturment far down the list.
5. The Ear Traning Window -
This is an example of a dialog which could be made greatly more accessible if it were organized better by using some of the concepts above such as organizing like elements into tab sheets, being able to tab to different elements in a logical sequence, etc. Right now this dialog seems to be haphazardly organized into windows and sub-windows with no logical connection and/or hierarchy. One cannot use the tab or control+tab keys to get from the "Chord Tutor" to "Interval Tutor" windows, etc. Using the arrow keys to navigate through buttons and other selections also does not work.
Another issue which makes this window difficult (if not impossible) to script with JAWS is that the title of the window seems to change. Sometimes when this window pops up the real name of the window is "Ear Training Window". Other times when the window pops up, it's reall name is "Guess Interval". In JAWS, one has the ability to look for specific windows with control IDs, real names, handles, etc. If these elements are not consistent, JAWS can't grapple with them.
6. Windows popping up over other windows -
Sometimes a new window will pop up in BIAB and that window obscures info from the window which has focus. For example, the "Big Lyrics" window may pop up unbeknown to the blind user) and obscure info that JAWS is looking for (like the beat an measure).
7. JAWS seeks PC cursor or "edit" cursor --
JAWS (and other screen readers) have several ways of providing feedback to the user. For example, JAWS can be set to speak newly highlighted text which appears on the screen. Thus, as a song plays in BIAB, JAWS can be made to speak the chords as each is highlighted (in fact, the scripts I wrote will make JAWS speak the chords in a "natural" way such as "C major 7" for "CMaj7", or "C flat over A bass" for "Cb/a").
Another way which JAWS attempts to provide feedback and help navigate is by following either the PC (or "edit") cursor (as opposed to the "mouse" pointer If, for example, the PC or edit cursor tracked the chords/beats as a user arrowed through a tune with the left and right arrow keys, the user could have better feedback on what currently has the focus. In many Windows programs, the PC cursor is controlled by the arrow and tab keys.
8. The DXI Settings dialog --
This dialog (accessed by going to Opt / Midi and Audio Settings / DXI Settings is almost impossible to navigate with JAWS. Tab and arrow keys do not navigate from one combo box to another. Also, it is difficult to move between tab sheets. Although this has been partially made accessible by the JAWS scripts which have been developed, this is less than optimal.
Anyway, I am hoping that some of these suggestions can be passed along to the BIAB developers and that this wonderful program can be made more accessible in future releases. Hopefully such modifications can be slowly made over time before the next release cycle and much of the code and feature set become frozen.
-- Pete