patternfly-react icon indicating copy to clipboard operation
patternfly-react copied to clipboard

Spike: Revisit Timestamp accessibility

Open thatblindgeye opened this issue 1 year ago • 4 comments

Describe the enhancement or change Per a discussion including @jgiardino and @jessiehuff there are some issues related to accessibility with our current Timestamp implementation:

  • There's no clear visual indication that the timestamp text can be interacted with when there's a tooltip
  • The tooltip content does not get announced by AT when triggered

Some ideas that have been brought up to help resolve this include:

  • Render screen reader text in the timestamp wrapper element of the UTC (or whatever other) time, and render the full timestamp info in the tooltip. Essentially treating the timestamp as truncated content when there's a tooltip. This would require rendering the UTC/additional time in a time element and passing it a valid datetime attribute (we're already handling this in a way if no dateTime prop is passed to Timestamp, so we could just expose a new "tooltipDateTime" prop or something if a user wants/needs to pass their own datetime attribute). See the following video for an example (note that VO is not announcing the tooltip content, it is announcing the visible text + screen reader text that is also wrapped in the main timestamp span wrapper).

    https://github.com/patternfly/patternfly-react/assets/70952936/629a9b1a-fbd3-4d80-ae9a-483067a39eab

  • Rendering an icon button next to the main timestamp visual text, and apply a popover (instead of a tooltip) to that button. This would require rendering a time element inside the popover as well if users can navigate into the popover.

For both points above, we already handle creating a datetime attribute internally if a consumer doesn't pass their own dateTime prop:

https://github.com/patternfly/patternfly-react/blob/62810f14601fdd4133d74e737c28c2e37dd3da6f/packages/react-core/src/components/Timestamp/Timestamp.tsx#L147

Which just creates a string of the UTC time already which should be valid.

Is this request originating from a Red Hat product team? If so, which ones and is there any sort of deadline for this enhancement?

Any other information?

thatblindgeye avatar Apr 09 '24 19:04 thatblindgeye

@thatblindgeye Is there something we can do from the RHOAI team to push this forward? Until we get this fixed we're using UTC time most places (we're a little inconsistent, but that's the recommendation) but personally I find that generally undesirable since its very hard for me to convert UTC time into my local time. It would be far better if it was just converted for me by default and there was an accessible way to see the UTC time if relevant.

kywalker-rh avatar Nov 19 '24 16:11 kywalker-rh

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

github-actions[bot] avatar Jan 26 '25 11:01 github-actions[bot]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

github-actions[bot] avatar Apr 03 '25 11:04 github-actions[bot]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

github-actions[bot] avatar Jun 05 '25 11:06 github-actions[bot]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

github-actions[bot] avatar Aug 05 '25 11:08 github-actions[bot]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

github-actions[bot] avatar Oct 07 '25 11:10 github-actions[bot]