Zoom, Accessibility and Usability
Our team found the following:
When access issues exist in a product or service, it is necessary to determine an accessible equivalent
method of access and to ensure that support staff for the product or service are aware of the issues and
There are issues in the Zoom dashboard that can prevent access for users who are blind. Ensure that
support staff are aware of the following:
• Users who are blind do not have the ability to perceive the visual structure of a web page.
Screen reader software limits users to “viewing” one element of a page at a time. As such, if
programmatic information structure is missing, these users will have a very difficult time
discerning the meaning and purpose of a page.
If a user who is blind is having difficulty configuring a setting in the dashboard, it will often be
necessary to describe additional information for dashboard screens that were found to be missing
grouping information or headings. Do not make assumptions about why the user is confused, as
screen reader users vary widely in their ability to discern information structure and compensate
for poor markup. Rather, explain to the user that you are aware that the information structure of
the page is somewhat lacking and ask them how they would like you to describe what they are
looking for. Some will want you to describe nearby focusable items; others will want to be made
aware of headings, etc.
An additional helpful practice will be describing which number item of a list of items or tabs is
the desired item. For example, when guiding a user to configure a meeting, let the user know that
the “Meeting Settings” link is the second one in the dashboard navigation and that the Meeting
tab is active by default.
• Users who are blind will able unable to determine which tab of some dashboard pages is active
without exploring the page. Further, they tabs are implemented in such away that there are extra
tab stops when navigating them via the keyboard. When guiding users to configure a particular
setting, it will be important to let them know to expect that there are extra tab stops in the tabs,
that the first tab is active by default, and describe any additional identifying information for the
desired tab that will aid the user in knowing that they are in the correct place.
When describing additional information, remember that screen reader users view a page linearly.
This means that you must indicate if any elements are in a tab prior to the distinguishing information.
For example, the Upcoming Meetings and Previous Meetings tabs (of the Meetings dashboard page) are identical until the user gets to the list of meetings.
Point outthat there are four links prior to the table of meetings, and then direct the user to look at the Start
Time column of the table to determine which tab is active.
Disclaimer: Accessibility assessment is iterative in nature. While every attempt has been made to be thorough, it is not
possible to conduct an exhaustive review. Further, it is possible that new problems may be introduced during attempts to
correct the reported issues. Follow-up assessment is recommended as corrections to the application are implemented.
• Some form controls, such as in the Recordings dashboard page, lack programmatic labels. This
has the effect to cause some fields to be unidentified. Screen reader users tend to navigate forms
by selecting the desired field out of a list or by jumping from field to field. Since the fields are not
labelled, neither of these navigation methods will be available to the user. When working with
a user to fill out these forms, it will be important to identify the purpose of each form field and
what order the fields come in.
Windows Zoom Client
There are issues in the Windows Zoom Client that will prevent access to some features for users who are
blind and those who must use a keyboard to interact. For the general purpose of joining a meeting and
interacting via voice, the client does not have significant accessibility issues.
• The issue with the meeting controls toolbar in the Windows Zoom Client will affect sighted
users who can only use the keyboard. For users that do not know the shortcut to navigate to the
toolbar, this will be an issue that will prevent them from successfully managing a screen share
presentation. It will be important to make support staff aware of the shortcut (Ctrl+Alt+Shift)
and to socialize it generally so that users are aware that it may be used to navigate to the toolbar
and to cause the toolbar to display again if it has collapsed.
• The additional issues documented in the VPAT for the Windows Zoom Client will prevent access
to some features, such as the inability to scroll or selectively read chats via the keyboard in the
in-meeting chat log. It is important to inform support staff of these limitations. Further, these
inaccessible features may not be required in the classroom or in a unit work environment without
a plan for providing meaningful alternative access. Ensure that those conducting meetings are
aware of which features are inaccessible and to plan accordingly for their intended use.
• For the inaccessible chat features, avoid using chat as a primary means of communication,
especially for large meetings. For webinars, where chat will be a necessary mode, ensure that
there is an individual who will read chat message aloud, so that all participants are aware of what
messages were posted.
MacOS Zoom Client
The MacOS Zoom Client has similar issues to the Windows client. These are well documented in the
VPAT for the MacOS Zoom Client. The documented issues will prevent access to some features for users
who are blind and those who must use only a keyboard. The in-meeting chat feature is more accessible to
VoiceOver users than is the chat in the Windows client; however, it is still not possible to scroll the chat
log for users who are not using VoiceOver. As with the Windows Zoom Client, do not require use of the
inaccessible features without an appropriate plan for alternative access.