Implementing aria-label Accessibility in Links

[sivasadobe]

Hi Team,
I'm working on adding a11y to all links.
JIRA: MWPW-157350

Context: When using Chrome on Windows with an NVDA screen reader, users navigate to the "Buy Now" and "Learn More" links on the pages. Links currently lack descriptive and distinctive text, which affects their clarity and usability for screen reader users.

Proposed Solution:

We need to improve the accessibility of our links (a11y) by creating a method to dynamically add the aria-label attribute. The proposed solution includes the following steps:

1. URL Parameter Addition: Authors should include a label_text parameter in the URL for any links where they want to enable accessibility features. For example:

https://www.adobe.com/photoshop.html?label_text=Buy Now about photoshop

2. Processing Links in decorateLinks: The milo utils will be responsible for processing all links within the decorateLinks function. It will check for the presence of the label_text parameter in the URL.

3. Setting the aria-label: If the label_text parameter exists, the function will:

   • Retrieve its value and set it as the aria-label for the respective anchor tag.
   • Remove the label_text parameter from the URL to avoid clutter and ensure clean URLs.
   • Update the anchor tag’s href to reflect the new URL structure without the label_text parameter.

Implementation Example:

Here's a code snippet for clarity:

const labelText = url.searchParams.get('label_text');
if (labelText) {
    a.setAttribute('aria-label', labelText);
    url.searchParams.delete('label_text');
    a.href = url.href;
}

Compare: stage...sivasaadobe/milo

+++ libs/utils/utils.js
export function decorateLinks(el) {
...
 const links = [...anchors].reduce((rdx, a) => {
    appendHtmlToLink(a);
    a.href = localizeLink(a.href);
    const url = new URL(a.href);
    console.log('url.href', url.href);
    decorateSVG(a);
+   const labelText = url.searchParams.get('label_text');
+   if (labelText) {
+     a.setAttribute('aria-label', labelText);
+     url.searchParams.delete('label_text');
+     a.href = url.href;
+   }
    if (a.href.includes('#_blank')) {
      a.setAttribute('target', '_blank');
      a.href = a.href.replace('#_blank', '');
    }
    ...
});
 ...
}

Benefits:

• Improved Accessibility: This implementation allows authors to provide meaningful descriptions for screen readers, improving the user experience for those relying on assistive technologies.

We'd like to gather feedback on potential concerns about this proposed solution, specifically the implementation approach and how it might be integrated into our existing code base.

cc @salonijain3 @narcis-radu @dstrong23 @aishwaryamathuria @mokimo @suhjainadobe @Ruchika4

[chrischrischris]

Worth checking with authors if label or aria_label would be preferred. Having _text seems redundant.

[overmyheadandbody]

I'm a bit surprised to see this already in the making, as it's part of a larger conversation we're having to address all accessibility compliance issues. This story has been marked as a sort of parent for all aria-label issues.

While I don't completely disagree with the approach, I'd like to get a bit more time to think through the use-cases:

• Firstly, I agree with @chrischrischris that the parameter naming might not be ideal. I'd like for us to establish a pattern, just as we have one with #_ to toggle different functionality;
• Secondly, this approach doesn't take localization into account. The link text will be localized, its URL receives a locale prefix from the logic, but the path remains untranslated. So in the US you'll have a <a href="/" aria-label="Buy now">Buy now</a> link, whereas in Germany the same link will be <a href="/de" aria-label="Buy now">Jetzt kaufen</a>. @janaki-r-bhagwath, @chrischrischris ,is my understanding correct?

For alt text, we already have a source | alt text pattern. I'm not certain we should re-use that, as it may be possible that certain links actually do contain the pipe character. But a similar approach might be better suited.

Lastly, although this would be a great step forward, it would be a mammoth task for GWP to go back and re-author all links to contain this label. We've discussed that we might try to isolate some use-cases where we could infer the label from headings/eyebrow texts in the block.

All in all, I'd suggest we don't rush into this and first ensure we're taking the E2E flow into account.

CC: @narcis-radu

[rgclayton]

On top of what @overmyheadandbody mentioned, I would not recommend the query parameter approach. This would be a bit of a new authoring pattern. Currently we add features to links via #_ pattern. This also would be adding more things on to the link URL.

I think something similar to how we handle alt text for SVG's, similar to what @overmyheadandbody mentioned would be a better approach.

This is also net new, meaning lots of reauthoring to get existing pages updated. We probably need GWP's input. This could be a large ask.

Another approach could be to associate the link aria label with a preceding heading tag (closest). That does present some obsticals as some blocks use a tag for the eyebrow text and the heading. This would help solve for the need to reauthor pages though.

[overmyheadandbody]

I've set up a showcase page with a few alternatives that would be a bit more authoring/localization-friendly. I've reached out to GWP to get some input on what would best work for them, as they will have to deal with making all of the updates.

[salonijain3]

@overmyheadandbody Keep us posted on the update from GWP, after looking at the page, | operator seems like a good option.