Long-term solution for an accessible RelativeTime component

[lindseywild]

TL;DR

We need to come up with a long-term solution for an accessible RelativeTime component that is not using the title attribute. This spawns from conversation on a PR that adds a noTitle option to RelativeTime component.

Background

Primer has received accessibility audit issues related to the RelativeTime component which mention the use of the title attribute (that displays the longer date/time) is inaccessible to keyboard, screen reader, and mobile users. This component utilizes the relative-time-element web component under the hood.

The ideal solution would be to remove the title attribute entirely, however, that may impact users since this component is used all over GitHub. So, we'd like to explore finding an alternative way to display the information that currently lives in the title attribute.

Documentation is being added with alternative solutions, however, we still don't have a great alternative for non-interactive static text implementations of <RelativeTime>.

We've hosted an accessibility engineering office hour around potential uses of aria for these static implementations, but we still need to user test implementations and see if there is something we can come up with. The alternative is to run user testing with removing the title attribute to see if that is a viable option since that is the easiest change to make.

Some ideas floated in a Slack thread:

<p tabindex="0" role="none" aria-role-description="Relative time" aria-describedby="time">Comment posted one week ago</p>

<p id="time">on 24 May 2024 at 04:00</p>

<p tabindex="0" role="paragraph" aria-roledescription="Relative time info">Comment posted one week ago <span>TOOLTIP/VISUALLY HIDDEN CONTENT</span></p>

Future thinking

Since we already have a solution for interactive elements (associating them with an accessible tooltip), we can bake that into Primer once we also have a solution for non-interactive elements.

For removing the current, temporary implementation, we can:

• Continue accepting noTitle, but make it do nothing under-the-hood
• Remove all no-title/no_title/noTitle` references, then fix type errors
  (courtesy of @smockle)

[siddharthkp]

Hi!

Thinking about this a little and I have some random thoughts for you:

1. If RelativeTime react component has a Tooltip parent, we can automatically set noTitle without needing our developers to remember to pass it.
2. (also mentioned in the accessibility hours) Can we make all RelativeTime "interactive"? In the cases where it is not a linked, can we make it a button that only opens a tooltip and does nothing else?
3. Have we explored using a toggletip? What are the tradeoffs we need to consider with that? https://inclusive-components.design/tooltips-toggletips/#inclusivetoggletips

[lindseywild]

1. If RelativeTime react component has a Tooltip parent, we can automatically set noTitle without needing our developers to remember to pass it.

Love this idea! Would you envision this being a separate component from the RelativeTime element? Or how were you thinking we'd detect when the RelativeTime component has a parent element that's interactive?

2. (also mentioned in the accessibility hours) Can we make all RelativeTime "interactive"? In the cases where it is not a linked, can we make it a button that only opens a tooltip and does nothing else?

I think that would be more of a product question :) If we could, then that would solve our issue of interactive vs. non-interactive instances. I know of some use-cases that the time is currently not interactive (i.e. in the edit history menu of a comment), so we'd need to think about what that would do if it were interactive. I am sure there are use cases all over the site we'd need to look into.

3. Have we explored using a toggletip? What are the tradeoffs we need to consider with that? https://inclusive-components.design/tooltips-toggletips/#inclusivetoggletips

For this, no, but it did come up in office hours that toggletips are a "can of worms" and that it'd be hard to make a good experience with. However, we could always look into it!

Thank you for the discussion ✨