Accessible chatbot design
These principles when followed will make the web-based user interface of a bot accessible up to Web Content Accessibility Guidelines 2.0 (WCAG2) AA.
They include optional collapsed background information explaining why the information is relevant, and can be read online, downloaded and printed.
Principles of accessible bots
To make a bot accessible:
Choose a customisable platform
Creating an accessible interface means getting as close as possible to building in HTML and CSS.
Products which don’t allow much control of the HTML will affect the overall accessibility of the bot. It can also be difficult to make an accurate decision when buying a bot and understanding accessibility support, and especially important don’t accept the vendors words alone without independent testing.
When trialling bots request a test account to be created which will allow you to conduct proper evaluation with a range of accessibility testing tools. Use CANAXESS as your external web accessibility provider to independently test any content being displayed.
Conversation history can be navigated
All conversation history must be findable when navigating from the keyboard.
The entire conversation must be navigable via the keyboard with and without assistive technology running.
Note. Scrollable DIV elements may have problems in certain browsers and this technique is still being evaluated.
Update. Following feedback from the web accessibility community the tabindex technique is no longer recommended. It is recommended avoid adding attributes to induce unexpected behaviour in elements which are not focusable by default.
The previous technique remains for background information only and is recommended not be followed.
The tabindex attribute with a value of zero means each question and answer reply will receive keyboard focus in the correctly displayed order and is reached as part of the normal keyboard tab sequence.<div tabindex="0" aria-label="The bot said">What can I help you with?</div>
Provide conversation identification
Screen reader users may not have access to visual clues and rely on text cues instead.
Screen reader specific text can be used to identify each conversation block, is it spoken by the bot or user.
The identifier text remains hidden from the screen but will be announced by screen readers. The text is announced when navigating to each conversation block and when chat messages appear, this technique should be combined with the 'Conversation history can be navigated' technique.
Note. Testing with NVDA has identified the announced text is 'clipped', resulting in inconsistent reading of the conversation identifiers..sr-hidden
<span class="sr-hidden">The Bot said</span> What can I help you with?
<span class="sr-hidden">You said</span> I'd like more information on my home loan
Update. The previous aria-label technique has now been replaced with screen reader specific text. During testing it was discovered aria-label was no longer working. This may have been due to a browser/screen reader update or its use was incorrect.
The previous technique remains for background information only and should not be followed.<div aria-label="The bot said">What can I help you with?</div>
<div aria-label="You said">I'd like more information on my home loan</div>
Add support for dynamic content
Content which updates regularly must have accessibility attributes added.
Each conversation block should be enclosed within one parent container, and have the aria-live attribute with the value polite. When each question and reply is appended to the container, the aria-live attribute will announce the change to the assistive technology.
This method of announcing onscreen changes means only the most recent change is being announced, not the full conversation history.<div class="conversationbody" aria-live="polite">
<div tabindex="0" aria-label="You said">What can I help you with?</div>
Only announce the updated content when the user is idle, you don’t want the updating display notification to become a distraction, hence we use the polite value. Polite causes the screen reader to pause announcing the text until other audible notifications have ended before announcing new content.
Understand the range of bot responses
Some bot frameworks can send a variety of message formats and these must also be accessible.
The Microsoft Bot framework allows rich media cards to be sent as replies. These cards mix text, buttons and images. The principles of accessible design should be followed and applied to these elements to ensure accessibility is maintained over every response from the bot.
Refer to our Accessible Forms information card for making HTML form elements accessible.
Provide a skip link
Provide a way to bypass all page links easily and navigate direct to the chatbot.
Bots are generally located in the lower right of the screen and this can be difficult for keyboard users. When the bot is further down in the page markup, there may be several links to tab through before focus reaches the chatbot. If the page has many links this repeated tabbing can become frustrating.
A skip link is an in-page anchor which is displayed as the first page link, when the link is activated it takes user focus to the chatbot bypassing other page links. The href value of the link uses the ID of the HTML element containing the bot.<a href="#chatbot">Skip to Chatbot</a>
Consider other factors
Follow accessibility principles for other aspects of bot design to ensure what is being created has the best accessibility support.
- Choose a relative font size which allows the text size to shrink and grow
- Use an accessible colour contrast
- Ensure the bot is displayed using responsive techniques
- Use language that is appropriate for your audience
This work is licensed under a Creative Commons Attribution-NonCommerical-ShareAlike 3.0 Unported License.
Designed by CANAXESS www.canaxess.com.au