I reviewed the Mozilla Hubs interface with our CEO, Thomas Logan using my JAWS screen reading application. I have added additional details on how to join the Accessibility VR meetup that is hosted on Mozilla Hubs through Meetup into this article. Also please note that we have raised the issues discussed in this article as well as additional items to the Mozilla Hubs team. We are very thrilled that they have been so gracious to log those issues in their GitHub Repository labeled as “Accessibility” and will encourage you to review the existing list of issues before logging new ones.
Joining the meeting room
Thomas provided me with a link to the conference he is conducting on March 19, 2020 titled “Considerations for Inclusive Social VR”. This is where I can review the event details, and this is where to join the meeting room.
To view the details, I did a quick high-level viewing of what the page contains by using the H key to navigate to the headings. You should read through the contents below the “Upcoming Events” heading. In this section, I found the title of the event, the date and time and the location of the event.
Upon activating the URL for the location, I was instantly focused to the “Enter Room” button in the new page that loaded. Before entering the room, I did a quick tour to check what else is in the page and there I saw whether attendees are already present or not. There are also several different control such as “Enter on standalone VR Wireless VR headsets” and “favorite” buttons. Upon activating the “enter room” button, a new page loaded and by default, the focus landed in the “Enter on Screen” button and then I press the “Enter Now” button. A sound then notified that I am already in the room.
It is important to note though that there’s a slight difference in the process of entering a room when you are the only present participant. You will be asked to input your name first before you can proceed, whereas, when someone, or Thomas in my case is already in the room, I didn’t need to provide my name.
In all fairness, this process of joining a meeting room is very accessible so far. This crucial feature can be accessed even by totally blind users like me.
The interesting part came in when I was already inside the meeting room.
Inside the meeting room
Just like any other page that I am testing, what I initially did was to browse the page from top to bottom. The very first thing I noticed is the very first button on top which happened to be unlabeled. JAWS announced it as “unlabeled 0 button”. I was completely clueless what this button is up until Thomas told me that it was in fact the button for the menu of options. I failed to read this because anytime aria-hidden = “true” is set in an element, a screen reader won’t be able to find it. Oddly, when I tried to activate it even when I didn’t know yet what it is, the focus moved to the “Send to Room” section and that confused me even more. I was not convinced at that point that I was in the menu options as what Thomas told me regarding the function of the unlabeled button. You can find the issue we have logged with Mozilla Hubs at Menu of Options and Toolbar not available to screen reader.
Since I’m already in the “Send to Room” section, and it was the next section anyway, I went on checking it out. There is an edit field right after it. so, my question at this point is if the “send to room” is the label for this edit field.
I went on exploring and saw that after the edit field are two buttons – create and submit. For me, since the edit field is inadequately described, I was at a loss and couldn’t immediately match the connection of a create and submit button; although the create button somehow gave me a clue that it creates a new room since the above label is “Send to Room”, but for the submit button, it was initially a mystery to me.
The “Send to Room” label is vague because at this point, I thought I was already inside a room. This left me guessing – will I be transferred to another room and the current room will be closed? Those are my trail of thoughts when I first encountered this section. I wondered because the information is insufficient for me to understand what is happening.
We logged this issue Text chat entry field is not adequately described for screen readers with the Mozilla Hubs team on GitHub.
Since I’m unsure, the first thing I did was to just type something in the edit field. After typing, I tried to use the tab key to access the next available elements like buttons or links, but I’m apparently stuck inside the edit field. In order to move out from it, I had to press the escape key first and use the arrow keys to check the succeeding elements.
Again, I’m unsure what to do, so, I simply pressed the enter key and there was my aha-moment and I realized that I am inside a chat window. A popping sound hinted me of incoming and outgoing chat messages.
The downside is since I’m not initially informed that this is a chat window and the popping sound is the only audible sound, the actual message is not announced, chances are, I might miss out the chat messages. Add up the fact that these chat messages disappears after a few seconds. This hinders me from back tracking my chat history and chances are, I missed out some chat messages. Note the Mozilla Hubs team has created a feature request Implement Chat Scrollback that could be interesting for this issue.
Now that I know that this is a chat window, the next thing that got me curious is on what the “create” button would actually do. Will it create a room just like what I initially assumed? I typed a random word and pressed the create button. A bubbling sound came off, so I assumed that a new action took place. My dilemma here is I’m unsure what the new action is. First, there’s no obvious cue that the page refreshed and second, I didn’t notice any new changes in the current interface. The only thing that gave me a clue that changes happened is because of the new instruction above – “press and hold space bar to show object menus”. Beyond that, I’m pretty much unsure what to do next.
After the “create” button, I was curious with what the “submit” button is – what does it submit. I found out that this is in fact the chat trigger. This is probably designed for people using switch controls or people who relies from clickers.
Personally, I think it would be better to rearrange the layout of this section. Currently, there’s only one edit field for creating a room and for submitting a chat message. There should be a clearer distinction between the purpose of each button to avoid misleading the user especially that there is only one edit box available.
I continued to browse the rest of the page content. After the submit button are different numbers that didn’t make sense. I activated the first number and I am again unsure what happened. There’s no hint that new actions took place. Eventually, through Thomas’ help when I shared my screen, only then that I found out that the first number actually displays the number of available rooms. Oddly, the list of rooms again didn’t make sense to me because they are all labeled as “reticulum”. I randomly activated one item in the list, and it appears like new elements appeared in the page. However, these new elements are buttons that are not labeled. In short, it still unclear to me what to do with the controls that appeared. Only when Thomas told me that the first unlabeled button is a “close” button did I get that there was actually a modal that popped-up.
The next number is for the number of users present in the room. At first glance, like the first number, I wasn’t able to identify the purpose of this number until Thomas told me what it is.
This issue Labels for Object List and People List dropdowns are insufficient for a screen reader has been logged with the Mozilla Hubs team.
Another feature we tried is for me to interact with the speaker or the lecturer during a presentation. The way to do this is to press the space bar. I tried to perform this with my screen reader turned on but apparently it is not working. I wasn’t able to access the list of reactions. I believe this is one important feature, most especially the raising of hands. If this is not fixed, screen reader users are deprived of the opportunity to discreetly interrupt the speaker.
Lastly, for the voice shifting, I was able to distinguish the voice shift from the person in the other line, however, I can’t do the voice shifting when a screen reader is turned on. Initially, I tried JAWS but didn’t work so I tried NVDA. The results are the same. In order for the voice shifting to work using my arrow keys, screen readers must be turned off first.
Conclusion
All in all, I can say that the accessibility of this platform is not so bad. It needs improvement but I believe it is fixable and that the team is committed to making Mozilla Hubs accessible.
If you encounter any new issues, consider logging them in the Mozilla Hubs GitHub repository.
I am very excited to see what the Mozilla Hubs team will have next for screen reader users.
Hello, I’ve been trying to understand how to offer people with low vision a really immersive VR experience and this text helped a lot to understand these issues with the hubs, which is what I’m interested in now. Thanks! 🙂