Accessibility of Chatbots
In general, the same requirements apply to chatbots as to the entire application. This article only covers chatbot-specific challenges.
Chatbots are usually not developed in-house. Rather, they are taken over by third-party providers and integrated via frames, iFrames or other technologies. Frames need a title that describes their purpose. The keyboard focus should be able to be moved in and out. Care should be taken to ensure that they are correctly integrated into the website hierarchy, for example via HTML Aside or ARIA Complementary. This also applies if other technologies are used for integration.
Chatbots are often located as sticky elements in the bottom right corner of a website. These elements are often inconspicuous for blind people. To draw attention to their existence, you can, for example, work with internal jump links at the beginning of the website. BTW, sticky elements should be integrated in such a way that they do not overlay the content when zooming.
An important aspect is usability via keyboard. Are all elements accessible and operable via keyboard?
The answers should be issued via Aria live atomic or ARIA Alert as soon as they are complete. With LLMS it is usual for the answers to be issued with a time delay. The focus should not be shifted to the answer, since you are in a chat and may want to ask a further question.
Questions and answers should be structured using P tags. I do not think other structures such as headings or quotation blocks are useful for this purpose. While a paragraph is usually sufficient for questions, longer answers can themselves be structured in individual paragraphs.
It should be clear what the question and what the answer are; a purely visual distinction using colors or indentation is not sufficient. At this point it makes sense to work with visual text instead of ARIA labels, so that the information is visible to everyone. Example:
Question: Where do I apply for a severely disabled person's ID card? Answer: The severely disabled person's ID card is applied for at the social security offices.
When different persons are in the conversation, the Name or nick Name of the individual should be at the start of the message.
In the desktop age, it was common for questions to be sent via Return. This has advantages and disadvantages. Sometimes you press Return to create a line break. On smartphones or tablets with an on-screen keyboard, you don't necessarily think of making a line break to send the question. I think both are fine, sending via Return or offering a Send button. Both correspond to known patterns.
Another important topic is the thinking pauses: So far, I don't know of any chatbots that require really long waiting times. With ChatGPT, you can at most think that you can watch the LLMS think while it formulates the answers. However, it is useful to inform the user that their question has been sent, for example via ARIA Alert. This is clear to sighted people because the text input field is emptied and the question is displayed as normal text.
If a waiting time is required, an indicator should be included that is appropriately accessible. Moving elements such as the typical spinning spinners should be avoided in order to meet criterion 2.2.2 Pause, Stop, Hide. This can be a non-moving spinner or a message saying "Response is being generated" or similar.
A distinction must be made between real chatbots, where messages are sent explicitly, and real-time communication (RTC), where messages are displayed to the recipient while they are being written. In the latter case, the use of appropriate protocols ensures that they can also be read by users of assistive technologies.