Live Chat is the buzz word in the modern communication system. It may be a retail business that want to reach their customers or government department that want to solve its citizens problems. Any business or an organization that reaches the customers through phone and email goes a step further. The live chat is an instant and more convenient way to answer the customer queries.
The modern live chat services are not only the instant chatting systems but can also be majorly automated using predetermining the content + machine learning + artificial Intelligence. The human intervention can be largely minimized.
The wide platforms these live chats can be deployed is another opportunity to reach as many customers as possible. Apart from websites and mobile apps, the live chat data can also deployed on applications such as Google assistant, facebook messenger etc . While the businesses consider reaching wider customers, it is also important to meet the customer’s requirements in using the live chat.
In this article we want to highlight the needs of commonly ignored customer base i.e. customers with disabilities. In other words, this article will highlight the best practices to make a live chat accessible to keyboard only, screen reader, low vision and various other users with disabilities.
Best practices to make a live chat accessible
Though not exhaustive list but here are few best practices to make a live chat accessible.
Choosing the platform
The high-level objective is to allow the content authors to customize the UI. Not all platforms allow to make customizing the UI of the chat widget. In case the platform supplied UI is not accessible, content authors should be able to tweak the code. May it be adding a proper heading structure or labeling the buttons. So, ensure that the platform you choose for the live chat allows the content developers to make relevant accessibility changes in the user-interphase.
Keyboard access
All the user interphase elements must be keyboard accessible. Users who depend only with a keyboard must be able to move between all actionable elements. These include the UI elements on the widget as well as the buttons or links that are part of the conversation. An automated chat bot may ask the user
“Bot says The next flight to LA from SFO is in an hour, do you want to know the details?
In the above message Yes and No are buttons and user should be able to move focus to those buttons with the keyboard and access them.
The other UI elements on the live chat widget may include “Send button”, email transcript, upload/ share, emojis etc. Of course the message text box also need to be operable with keyboard alone.
Proper labels
Users with assistive technologies such as screen readers need proper labels for all user-interface elements. If the platform does not provide accessible labels or labels themselves, content authors should provide them. The labels for the buttons convey the action associated with them. Having visible labels are useful for everyone, however if the usage of the element is conveyed in any other visual means to a sighted user, aria-label can be served as a substitute.
Proper labels or alternate text is required for other features such as emoticons. The images shared by the bots also need proper alternate text. Providing a provision to add captions to the documents, images or videos uploaded by the user will be an added advantage.
Navigation
Majorly the user interacts in the chat history pane and the message text box. A screen reader user should be given an opportunity to switch between these two panes easily and quickly. It can be a simple tab and shift+ tab or by using access keys. Few chat bot developers also provide access keys to read recent messages for a screen reader user. Providing such access keys may not be harm or may not add much value as user should remember few more commands but can read the recent messages as many times as he need without navigating away from the message text box.
Screen reader users must be able to navigate as they need in the history pane. The text navigation commands such as left arrow, right arrow, control left arrow, control right arrow, up arrow, down arrow etc should work as usual in the history pane.
Reading the alerts and recent messages
Many dynamic changes happen from the time user initiates the live chat until the conversations is end. If the human agent is responding from the other side, user may have to wait in the queue for the agent. The status of the queue will be dynamic, the agent may be typing or may stop typing, user would have received a message from the agent or automated bot. All these are the dynamic messages that are displayed on the screen. No matter where the screen reader users current focus is these dynamic changes and updates need to be informed to the user. Some of these changes may also be only visual changes but convey important information to the user.
Aria-live property can be added to the dynamic updates for the user to understand the changes in the live chat. The specific aria-live properties such as aria-live=”assertive” or aria-live=”polite” can specifically address many of these problems. The aria-label property can address labeling the visual changes that happen on the screen and convey the message to the user at the right time with aria-live.
Other considerations
- Usually the agent name or the word bot will be appended before the message from the agent side and user name will be appended for the message from the user side separating with a : (Collen). It can be made more conversational with the words Agent name says, user name says (replace agent name and user name with the actual names).
- Allow the user to switch off the time stamp. Many times the time stamp is not much important in the conversation but it adds lot of verbiage disturbance when the screen reader reads each message. If the user be able to switch off the time stamp , users who are not comfortable with that verbiage can benefit.
- Visually differentiating the normal text and buttons or links in the chat history. In modern chat bots agents or users can share links or the bot can do a conversation with simple questions such as yes , no. These actionable elements should be easily differentiated with its surrounding text in addition to the keyboard access to them.
- Adhere all other applicable W3C WCAG guidelines and chat bot best practices.