1912309 - The Select Chat and Delete Chat buttons from the Anthropic Claude Chat History are not displayed when the user reaches them using keyboard navigation

Status: NEW

(Core :: Machine Learning, defect)

Description

[Rares Doghi, Desktop QA]

Attachment: Invisibleitems.mp4

Found in

• Beta 130.0b2

Affected versions

• 131.0a1 (2024-08-08)
• Beta 130.0b2

Affected platforms

• all

Steps to reproduce

1. Reach about:preferences > Firefox labs and Enable the AI chatbot.
2. Select the Anthropic Claude from the Ai provider dropdown and Sign in.
3. Select to View all chats from the Anthropic sidebar.
4. Use the Tab key in order to reach the older chats.
5. Use the tab key to reach the Select Chat or Delete Chat buttons.

Expected result

• The Select chat or Delete Chat buttons should be displayed when the user is focused on them using Keyboard Navigation

Actual result

• The Select Chat or the Delete Chat buttons only show a Tooltip when focused.
  Please note that if we hover the mouse cursor on top of the chats both buttons will be displayed.

Regression range
Not a regression.

Comment 1

[Anna Yeddi [:ayeddi]]

Invisible on focus icons is an access-S2 issue that makes this part of the UI inaccessible for users of assistive technologies and likely makes these two features not discoverable/actionable by users with low vision. While the current implementation is not fully blocking most of a11y customers from using the feature, these controls do create barriers for many groups of users, they prevent these controls from being discoverable by users, and require users of many assistive technology to rely on a workarounds which less experienced users may not be aware of.

In general...

when controls are only visible while hovered with a mouse or focused with a keyboard, it is a dark pattern for accessibility and for general discoverability of these controls.

Expected Behavior:

The screen does not change / does not add or remove a content unexpectedly. It is equally predictable for navigation with any alternative input device, with a keyboard, with a mouse, and with a touch. A user reviewing the page for the first time can know what is available for them, what could be the steps to achieve their goal based on the current UI.

User Impact:

A couple of examples of recent (unsolicited) feedback from few power users that have encountered similar "Schrödinger" buttons:

Some of those controls and other small or low-contrast marks that only appear in context are sometimes hard to notice.
{...} actions that only appear on hover have equal discoverability issues unless you're fully sighted, fully attentive and using a mouse (not a touch screen).

Per the WebAIM Screen Reader User Survey #10 results, Interactive elements like menus, tabs, and dialogs do not behave as expected and Screens or parts of screens that change unexpectedly are two of Top-4 most problematic issues in the overall rating of difficulty and frustration for screen reader users.

Accessibility concerns:

Besides being hard to discover by any user, hidden-until-hovered controls are:

1. not accessible for voice control users,
2. not accessible for touch screen users,
3. usually inaccessible or require a cumbersome workaround for switch control and other alternative input users, including
4. the usual switch software workaround - grid view - that sends a click on a point on the screen won't show these controls and therefore won't allow it to be activated, and
5. when giving directions to a switch to send a batch of X Tab key presses to get to the elements after these chat controls (because there are X visible controls/chats on the screen) won't be able to get to the destination, because it would require X*2 extra key presses to pass by 2 suddenly appearing controls for each chat. This would also be happening on the high speed, so a user may not even notice these Easter eggs in the focus order and would be confused.
6. keyboard-only users would get additional tab stops that they do not know about,
7. screen reader users may not be able to get to them in some modes of navigation, and
8. they won’t be able to use the screen reader-provided shortcuts and lists of controls to quickly navigate there
9. users with learning disabilities, users with cognitive disabilities, users with short attention span, ADHD, neurodivergent users, and any other user who is distracted/tired/busy are likely to lost the focus, be distracted by sudden appearance of something new on the screen
10. magnification software users may not be able to find which option the on-hover button is applied to and/or activate this button instead of the option itself and vice versa
11. mouse users are not expected to move the pointer over empty spaces in the UI in a search for hidden elements, unless they're playing a game with clear instructions.

And this list is not full. ATM, I am not aware of any workarounds making this on-hover appearance delightful for accessibility customers and beyond.

Remediation:

That's being said, there are ways how the additional options (currently hidden in the visible-on-hover-only options) may be exposed to a user without sacrificing accessibility, usability, and discoverability. For instance:

1. the controls could be always present on-screen as the Firefox View and Safari New Tab page have done, for instance. Or
2. there could be one control for the page to enter an edit mode as the iOS Mail and Messages apps have done. Or
3. we could include these extra options in the general context menu (right click menu) for each option (which are individual chats). Or
4. the settings menu of the chatbot may have an option to use minimalistic UI where items would be hidden until hovered/focused (but this option should be off by default, so a user could evaluate their expectations and abilities and preferences and explicitly opt-in to this experience as the Gmail has done).

Accessibility team will be happy to discuss any other patterns that could replace this dark, inaccessible pattern.

Note:

This appears to be an accessibility issue on the side of the chatbot service. Firefox team would need to pass this information to the provider, but until it is resolved, I'm marking this bug as stalled.