Bugzilla

### Current:
1. The `...` Open Menu buttons that are provided for each of the tiles and cards on the `about:newtab` page is only visible while hovered with a mouse or focused with a keyboard. 

A few examples of recent (unsolicited) feedback from few power users working on Firefox:
> Some of those ... and other small or low-contrast marks that only appear in context are sometimes hard to notice.
> I find it also surprising that the left click context menu shows the typical options for a link, but not the pinned tab-specific options
> {...} 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).
> The other problem is that as I move the mouse around I need to hover for about 1s before the ... appears.  So if I'm just mousing around it'll never appear and never be discovered {...} IME the delay causes my mind to disconnect my action (hover) from making the ... appear.  To connect it to my action and teach me that it'd need to be more immediate. 

### Expected:
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.

### Accessibility concerns:
Besides being hard to discover by any user, hidden-until-hovered controls are:
1. not accessible for *voice control users*,
1. not accessible for *touch screen users*,
1. usually inaccessible or require a cumbersome workaround for *switch control and other alternative input users*, including
1. 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
1. when giving directions to a switch to send a batch of 11 `tab` key presses to get to the story cards (because there are 11 visible controls on the screen) won't be able to get to the destination, because it would require 9 extra key presses to pass by 9 suddenly appearing controls. 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.
1. *keyboard-only users* would get additional tab stops that they do not know about,
1. *screen reader users* may not be able to get to them in some modes of navigation, and
1. they won’t be able to use the screen reader-provided shortcuts and lists of controls to quickly navigate there
1. *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
1. *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
1. *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 these menus) 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. Or
1. there could be one control for the page to enter an edit mode as the iOS Mail and Messages apps have done. Or 
1. we could include these extra options in the general context menu (right click menu) for each hyperlink (which are tiles and cards). Or 
1. the settings dialog 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: while the current implementation is not fully blocking most of a11y customers from using the feature, the issue is marked as `access-S2` because it does create barriers for many groups of users, it prevents the controls from being discoverable by users, and requires users of many assistive technology to rely on a workarounds which less experienced users may not be aware of.

### Current:
1. The `...` Open Menu buttons that are provided for each of the tiles and cards on the `about:newtab` page is only visible while hovered with a mouse or focused with a keyboard. 

A few examples of recent (unsolicited) feedback from few power users working on Firefox:
> Some of those ... and other small or low-contrast marks that only appear in context are sometimes hard to notice.
> I find it also surprising that the left click context menu shows the typical options for a link, but not the pinned tab-specific options
> {...} 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).
> The other problem is that as I move the mouse around I need to hover for about 1s before the ... appears.  So if I'm just mousing around it'll never appear and never be discovered {...} IME the delay causes my mind to disconnect my action (hover) from making the ... appear.  To connect it to my action and teach me that it'd need to be more immediate. 

Per [the WebAIM Screen Reader User Survey #10 results](https://webaim.org/projects/screenreadersurvey10/#problematic), `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.

### Expected:
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.

### Accessibility concerns:
Besides being hard to discover by any user, hidden-until-hovered controls are:
1. not accessible for *voice control users*,
1. not accessible for *touch screen users*,
1. usually inaccessible or require a cumbersome workaround for *switch control and other alternative input users*, including
1. 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
1. when giving directions to a switch to send a batch of 11 `tab` key presses to get to the story cards (because there are 11 visible controls on the screen) won't be able to get to the destination, because it would require 9 extra key presses to pass by 9 suddenly appearing controls. 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.
1. *keyboard-only users* would get additional tab stops that they do not know about,
1. *screen reader users* may not be able to get to them in some modes of navigation, and
1. they won’t be able to use the screen reader-provided shortcuts and lists of controls to quickly navigate there
1. *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
1. *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
1. *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 these menus) 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. Or
1. there could be one control for the page to enter an edit mode as the iOS Mail and Messages apps have done. Or 
1. we could include these extra options in the general context menu (right click menu) for each hyperlink (which are tiles and cards). Or 
1. the settings dialog 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: while the current implementation is not fully blocking most of a11y customers from using the feature, the issue is marked as `access-S2` because it does create barriers for many groups of users, it prevents the controls from being discoverable by users, and requires users of many assistive technology to rely on a workarounds which less experienced users may not be aware of.