In order to accommodate all users, Zulip strives to implement accessibility best practices in its user interface. There are many aspects to accessibility; here are some of the more important ones to keep in mind.
- All images should have alternative text attributes for the benefit of users who cannot see them (this includes users who are utilizing a voice interface to free up their eyes to look at something else instead).
- The entire application should be usable via a keyboard (many users are unable to use a mouse, and many accessibility aids emulate a keyboard).
- Text should have good enough contrast against the background to enable even users with moderate visual impairment to be able to read it.
- ARIA (Accessible Rich Internet Application) attributes should be used appropriately to enable screen readers and other alternative interfaces to navigate the application effectively.
There are many different standards for accessibility, but the most relevant one for Zulip is the W3C’s WCAG (Web Content Accessibility Guidelines), currently at version 2.0. Whenever practical, we should strive for compliance with the AA level of this specification. (The W3C itself recommends not trying to comply with the highest AAA level for an entire web site or application, as it is not possible for some content.)
There are tools available to automatically audit a web page for compliance with many of the WCAG guidelines. Here are some of the more useful ones:
- aXe An open source Chrome and Firefox extension which runs a somewhat different set of checks than Google’s Chrome extension.
- Wave This web application takes a URL and loads it in a frame, reporting on all the issues it finds with links to more information. Has the advantage of not requiring installation, but requires a URL which can be directly accessed by an external site.
- Web Developer This browser extension has many useful features, including a convenient link for opening the current URL in Wave to get an accessibility report.
Note that these tools cannot catch all possible accessibility problems, and sometimes report false positives as well. They are a useful aid in quickly identifying potential problems and checking for regressions, but their recommendations should not be blindly obeyed.
Problems with Zulip’s accessibility should be reported as GitHub issues with the “accessibility” label. This label can be added by entering the following text in a separate comment on the issue:
@zulipbot label "accessibility"
If you want to help make Zulip more accessible, here is a list of the currently open accessibility issues.
For more information about making Zulip accessible to as many users as possible, the following resources may be useful.