After doing extensive research on NVDA, and how it works; I began testing to get an idea of how the screen reader currently works with the BBB HTML5 client. The following were the bugs I have identified:
- NVDA does not enter browse mode, all shortcut focus keys are disabled.
- The join audio modal is causing issues with NVDA. When the client loads and the modal is rendered, the screen reader can no longer find any elements on the page in browse mode.
- Toggle user list button does not indicate to the user the current state of the toggle.
- Public / Private chat link does not inform user if the chat section has opened, when selected.
- When a user is selected from the user list, a menu pops up, the name of the user and the option are voiced. To get to that menu, pressing tab, the name of the user is voiced (“username, 1 of 1”). The screen reader never informs the user about the option below in the menu.
- The hamburger menu button pops up a menu with 4 options. Make full screen, settings, about and logout. When that menu is rendered to the screen, the screen reader does not inform the user of the logout option. If any of the top 3 options are focused the screen reader says “item, n of 3”.
- A few components have not followed the WAI-aria practices ARIA best practices. Based on the practices defined, work needs to be done on the semantics of the components. There is also a general checklist to follow: accessibility checklist.
- Settings modal does not trap focus, as a result, a user can tab to options in the background behind the modal while it is open.
- Selecting the hamburger menu button when the client first loads will cause a drop down to pop up and the first option is focused so the screen reader reads out the option. If any of the options in the menu are selected; the next time the hamburger menu is pressed, no options in the menu are auto focused. As a result of this, the screen reader says nothing, and the user never knows if the button selection was successful in opening the menu.
After finding these bugs related to users (non moderator/ presenter), I began going through the list in a attempt to correct the issues. There was one issue that appeared to be a bug, however, with more testing, i realized it was the intended behavior. When selecting certain elements on the page the screen reader will make a small beep. this beep is easily missed by someone not accustom to using NVDA. The beep signals to the user that the mode of NVDA has switched from browse to application. When this happens it is up to the user to be aware of this switch and to then press “Esc” which will cause another beep signaling the switch of modes.
First on the list was to find out why NVDA’s browse mode is disabled when the client loads. The reason for this was because of the current implementation of the ‘role=”application”‘ on the app’s most outer div. Using this role signals to NVDA that the developers are going to handle all keyboard functionality and to turn off the browse mode that is built into NVDA.
To enable NVDA’s native browse mode we simply change the role to “document”.
Next up on the list is to find out why the audio modal seems to break NVDA’s browse functionality and the settings modal does not since they are both modals, the behavior is unexpected.