When working on https://bugzilla.mozilla.org/show_bug.cgi?id=1766318 it became apparent that we have a pattern of adding an ID to a link or text-link element just so we can access it in JS code, read app.support.baseURL from prefs, and set the href attr so the link points to the correct support site.

For example, some variation of this code is repeated throughout the codebase:

<a id="helpButton" data-l10n-id="help-button-label"></a>

let helpButton = document.getElementById("helpButton");
let helpUrl =
      Services.urlFormatter.formatURLPref("app.support.baseURL") +
      "preferences";
helpButton.setAttribute("href", helpUrl);

This seems like an opportunity to create a simple reusable element to encapsulate this logic, which in turn should enable a bit of cleanup, since the code above could be reduced to:

<a is=”support-link” support-page=”preferences”>

A version of this already exists in the aboutaddons code [1], so this task is just a matter of extracting that into toolkit/widgets

[1] https://searchfox.org/mozilla-central/source/toolkit/mozapps/extensions/content/aboutaddons.js#610-633

Copying/paraphrasing some text out of Slack to help provide context on the accessibility concerns of the currently implemented "Learn more" links:

Our current "Learn more" links are inaccessible according to the WCAG 2.1 Level A Success Criterion 2.4.4 Link Purpose (In Context). This is because "Learn more" does not provide any context until you navigate to the link. When focused, a screen reader would announce "Learn more. Link". Users with cognitive disabilities could also become confused by these links since they all appear the same if navigating via something like VoiceOver's Rotor. One potential solution is to use the localized context and add that to the "Learn more" link via aria-describedby. However this only works if the localized context is set up in such a way that "Learn more about <localized context>" creates a valid sentence. For example, there is "Enable Container Tabs" on the general page of about:preferences. If we added this as context to the learn more link, screen readers would announce "Learn more. Link. Enable Container Tabs" which might be better but is definitely more clunky compared to something like "Learn more about container tabs. Link". Additionally, the original problem still occurs for sighted users and people using tools like VoiceOver's Rotor. The visible context still says "Learn more" in this case.

Because of the previous, a solution may be to use Fluent and create specific labels for each of these "Learn more" links. Since we can't used the previously localized content to create clear and concise sentences, we could create link text in Fluent for these cases. The issue with this is the amount of screen real estate we have to work with. about:preferences is already a bit constrained and link text doesn't like to wrap (but may be fixed due to Emilio's recent changes with xul flexbox, something to confirm either way). This would be more of a Fluent/Content sign-off decision as it would be a (relatively) straightforward task of adding the new Fluent strings to the various "Learn more" links...but I think these links might already have Fluent IDs, so I think we would need to replace them with new ones IIRC my Fluent development correctly.

The Context/UX and Accessibility teams are aware of this issue and I'm working with them to resolve it.

The issues described in Comment #2 will be handled over in Bug 1803606. This bug should be for creating the reusable "support-link" and getting those changes in-tree. Iterate and improve and all that.

This adds the <moz-support-link> custom element as well as stories and
tests for this reusable component. The purpose of this component is to
replace individual implementations of the "Learn more" links present
in Firefox, specifically in about:preferences and about:addons.

See Bug 1801927 for an instance of using this component to refactor
the "Learn more" links in about:preferences#general.

Pulling out some of the discussion so far on this patch. One issue is the current name of the component moz-support-link. Since this component should be replacing the existing "Learn more" links (and specifically the implementation that is in aboutaddons.js), it may make more sense to call this reusable component support-link instead. However, that can't be done at the moment without ripping out the aboutaddons implementation and markup, which is something that will be handed in Bug 1804695. Because of this, my recommendation is that we keep the current name of moz-support-link and revisit the name when Bug 1804695 is prioritized/worked on.

We need some way of distinguishing these new reusable components from the existing custom elements that live in toolkit/content/widgets and the current approach has been to use the moz- prefix...but then there's the case of the existing moz-input-box widget. We initially thought maybe we could rename and move this somewhere more relevant, since it seems to only be used in navigator-toolbox...but it is also being used downstream in Thunderbird in messengerCompose.xhtml. I guess we can just call the moz-input-box an outlier for now.

https://hg.mozilla.org/mozilla-central/rev/29c832430820