I'm wondering if you have any updates re: your work on accessibility with the chatbot. Our team is running into a few different issues, listed below. To what extent can we address these with code on our end, versus things that are hardcoded by HubSpot/not available for customers to change? We're professional subscription.
The live chat control lacks coherent identification to screen reader users, announcing as “chat widget frame open live button." Recommendation: Like the other user controls, provide a meaningful tooltip (e.g., “Live Support Chat”), perhaps with a shortcut key.
The contrast between the foreground and background text colors is insufficient (1.6:1); falling short of the 4.5:1 required for small text. (this is the case with the text field - grey on grey). Recommendation: Change all problematic foreground/background pairings to higher contrast ratios that meet or exceed the required minimum.
The live chat text choices that are presented lack any visible focus indicators. Recommendation: Ensure each control, when in focus, gains a visible focus indicator.
When the live chat window is presented, it is announced only as “Choose an option” and is placed at the end of the content. Recommendation: When presented, place the user on the first actionable element within the modal, in this case likely the first option. Given the options are a series of associated controls, the content region should likely be coded as a <fieldset> where the <legend> represents the common topic “What best describes how I can assist you?”.
When the live chat is in “after hours” mode, screen reader users and, to some extent, sighted keyboard-only users, will have difficulty discerning that the live support is not currently available and that the “Write a message” input is currently disabled. This is because the input field does not receive keyboard focus and the “Cancel” symbol only shows up on mouse-over; when the live support is initially launched by the user, it announces as “Write a message” (even though that is not actually available). Furthermore, the button doesn’t announce the current state change (even though it accurately announces the action that will happen). Recommendation: Announce the state change of the live support module in real-time (i.e., when the user opens the chat it must announce “Open” and when the user closes it then it must announce “Closed” - or “Expanded/collapsed”). In “after hours mode” immediately announce on open something like “We’ll be back at 9am Eastern Time”. Also improve the “We’ll return...” message to explicitly indicate to all users that they cannot write a message at this time (for example, something to the effect of, “The live support is currently offline, we’ll return at 9am ET, at which time you can write a message.”). Also, either entirely disable the focus of the “Write a message” input field (if you also implement all of the previous recommendations) ... or semantically indicate, when the “Write a message” field received focus, that it is disabled. (Also, no matter what, add the time zone to the time.)
Some chat options result in a “To start a new chat, click here” anchor being presented that cannot be actioned using keyboard only (due to the lack of a valid href attribute). Recommendation: Ensure each <a> contains a valid href attribute or the browser will remove it from the keyboard focus order.
Functional accessibility issue: The message history thread “MessageHistory__ReflowElement-bvewip-0” may benefit from a role="log" to provide feedback automatically to screen reader users. Recommendation: Add role="log".
Does anyone have solution to how we can make chatbot icon accessible?
When accessing the page through the keyboard it is not possible to visually identify the current location on "Open Live Chat" button . No focus indicator is visually available as the user tabs through the button using a keyboard.
Hi all, I am the technical lead on the team that handles the chat widget. Hoping that a reply to some of these issues will help!
The live chat control lacks coherent identification to screen reader users, announcing as “chat widget frame open live button." Recommendation: Like the other user controls, provide a meaningful tooltip (e.g., “Live Support Chat”), perhaps with a shortcut key.
this now has the label "open live chat" which we feel is clear
The contrast between the foreground and background text colors is insufficient (1.6:1); falling short of the 4.5:1 required for small text. (this is the case with the text field - grey on grey). Recommendation: Change all problematic foreground/background pairings to higher contrast ratios that meet or exceed the required minimum.
this is due to the custom color chosen for the inbox. We could do something to guarantee that all colors have enough contrast, in the meantime I would advise you to choose a color that is either dark or light and not a midtone so that contrast is high enough
The live chat text choices that are presented lack any visible focus indicators. Recommendation: Ensure each control, when in focus, gains a visible focus indicator.
unsure what you mean by "live chat text choices"
When the live chat window is presented, it is announced only as “Choose an option” and is placed at the end of the content.
this should be fixed now, the widget will auto focus on the text input once opened.
When the live chat is in “after hours” mode, screen reader users and, to some extent, sighted keyboard-only users, will have difficulty discerning that the live support is not currently available and that the “Write a message” input is currently disabled.
the text input is now disabled and selectable when the chat is in after hours
Some chat options result in a “To start a new chat, click here” anchor being presented that cannot be actioned using keyboard only (due to the lack of a valid href attribute). Recommendation: Ensure each <a> contains a valid href attribute or the browser will remove it from the keyboard focus order.
this is true and we can attempt to fix this as soon as possible!
Functional accessibility issue: The message history thread “MessageHistory__ReflowElement-bvewip-0” may benefit from a role="log" to provide feedback automatically to screen reader users. Recommendation: Add role="log".
We are in the same spot and would like to leverage HubSpot's ability to do this but cannot if the chat widget is not supported for accessibility. Any updates?
we are about to choose and implement a chat on our website and have the same concerns as Emmy. Do you have any update regarding the different points they raised? This might be a dealbreaker for us.
