Feature Requests

Problem / Use case Our Knowledgebase contains a large number of technically detailed articles that users often need to share with colleagues, review offline, or store for internal reference. Currently, there is no way to export an article directly from the frontend, which forces users to create manual requests for exports in the cases of longer or more technically demanding articles. Proposed solution Introduce a frontend “Export article” option (PDF-printer friendly) that can be enabled only for selected articles. -Key requirements: * Export button visible on the frontend article view * Ability to toggle export availability per Article or Category (backend / admin setting) * No global enablement — must be opt‑in per article to avoid misuse or IP concerns

The coding that is used within interactive features, such as accordions, decision trees, etc is not accessible for those utilizing screen readers or are unable to utilize their mouse to scroll through information. Users should be able to use Tab to go through accordions, etc. None of HelpJuice's interactive features are ADA compliant and that's a massive negative for users.

When replacing an image in the files manager, you would need to then replace it manually in the articles, this increases the workload x10000. This tool would be much useful if it replaces the image everywhere.

When generating a translation, the translation should, by default, display the equivalents of the related articles indicated in the original article and not the ones selected by AI. In case there is no translation of the article, I´d suggest the article is left out.

When republishing an article after making edits, it would be helpful to include an internal change log that allows authors and collaborators to document what was changed and why. Users should be able to change the authors and collaborators of each article to ensure that the correct person receives notifications related to edits and updates. For example: “Updated screenshot for accuracy” “Added new section related to XYZ feature (Jira #1234)” This feature would help writers, editors, and collaborators easily understand the purpose of each revision when viewing version history, especially when reverting to a previous version.

We currently have a chatbot embedded in our application, and in our Helpjuice configuration, we have integrated JWT SSO with our application. It would be great if, when a user from our application wants to access information, simply clicking on the chatbot or helpbar would automatically trigger the login action configured with JWT SSO.

• 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?

• When a screen-reader user types a query into the search field, the screen reader does not automatically announce how many results were found. The user must manually navigate away from the search field to the results area to check whether anything was found, and may need to move back again to adjust the query. • The heading that displays the number of search results is written in English, while the main language of the site is Ukrainian. Potential Improvement Considerations Could it be possible to add aria-live="polite" to the heading that displays the number of search results, so that screen readers automatically announce any updates to its content? Could the heading level be updated from <h6> to <h2> to improve semantic structure and accessibility for assistive technologies?

• 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?

• 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?