Feature Requests

• The search window lacks a proper heading hierarchy. Various headings are implemented as <h6> elements, which complicates comprehension and navigation for screen reader users. Potential Improvement Considerations Could the heading "Results Found..." be implemented as an <h2> heading? Could the heading "AI has responded" be implemented as an <h2> heading? Could each individual search result be marked as an <h3> heading instead of <h6>? Could the heading "Ask AI" be converted to standard text (<p>), as it does not represent a section heading?

When a search query is sent to the AI, screen readers do not announce that processing has started. After the AI responds, users are not informed that a response is available. Potential Improvement Considerations: Add an off-screen live region (e.g., aria-live="polite") for screen reader notifications. Announce when the AI starts processing (e.g., “Swifty AI is composing a response”). Update the notification when the response is ready (e.g., “Swifty AI has responded”), optionally including the full response.

• When new messages appear in the chat, they are not automatically announced by the screen reader, so users cannot tell whether a response has been received. • Information that the AI has started composing a response is also not announced, leaving users uncertain about the current state of the conversation. Potential Improvement Considerations Is it possible to add role="log" and aria-live="polite" to the container holding new chat messages so that they are automatically announced by screen readers? When a user sends a message, could a status message such as "The assistant is composing a response" be announced to the screen reader so the user knows to wait for the reply?

• The button for closing the chat and the button for activating the voice assistant are implemented as plain images rather than interactive elements. • Because of this, users with motor impairments cannot move focus to these controls, making it impossible to activate them with the keyboard. • This also complicates navigation for blind users, as screen readers do not treat these images as actionable elements. Potential Improvement Considerations Is it possible to implement these controls using the <button> element? If replacing the elements is not feasible, could the existing images be enhanced by adding role="button" and tabindex="0" to ensure they are accessible and focusable?

Buttons for closing the chat and switching to voice chat do not receive focus and cannot be operated via keyboard. Potential Improvement Consideration: Add role="button" and tabindex="0" or use native button elements to ensure proper keyboard accessibility.

Currently, the same Swifty AI customization is applied to all languages. For example: If we wanted to customize the Welcome Header text in German for the German KB, it will also be applied to the English KB. We should be able to add language-specific settings.

The chat window has a disrupted heading hierarchy, making navigation difficult. Some elements that should be headings are not marked as such. Potential Improvement Considerations: Implement "🙌 Hi! I'm a chatbot - ask or search for what you need" as a <h3> heading. Mark "Popular Articles" as <h4> and translate into Ukrainian. Use <h5> for items in the popular articles list or present them as regular links instead of headings. Structure chat messages with each user message as <h3> and AI responses as standard text to reduce complexity. Add aria-label="Next Suggestions" to the list of suggested questions so screen reader users understand their purpose.

• The animation in the AI Chat voice interface runs continuously without any mechanism for users to stop, pause, or hide it. • This may cause difficulties or distractions for users who are sensitive to motion or have cognitive or visual impairments. Potential Improvement Considerations Is it possible to provide a control (e.g., a button) next to the animation that allows users to stop or pause it according to their preference?

• The chat window is exposed to screen readers even when it is closed, which may cause confusion for users who rely on assistive technologies. • When the chat window is opened, it appears at the very end of the reading order because the screen reader follows the DOM structure rather than the visual layout. As a result, users may need to navigate through the entire page before reaching the newly opened chat interface. Potential Improvement Considerations Is it possible to hide the chat window from assistive technologies while it is closed by applying display: none and only making it visible when the user opens it? When the chat window is opened, could the focus be automatically moved to the chat’s input field to ensure that users immediately understand its location and can begin interacting without additional navigation?

• The button intended to scroll the chat to the bottom does not include any label that could be announced by a screen reader. • As a result, users relying on assistive technologies may not understand the purpose of this control. Potential Improvement Considerations Add an accessible label, e.g., aria-label="Прокрутити чат в кінець", so screen readers can convey its function.