Video loading state not announced #6198

New issue

Open

opened 2026-02-22 12:35:35 -05:00 by deekerman · 1 comment

deekerman commented

2026-02-22 12:35:35 -05:00

Owner

Originally created by @Woebin on GitHub (Jul 2, 2025).

Describe the current behavior

This is a violation of the Web Content Accessibility Guidelines (WCAG) SC 4.1.3 (AA) Status Messages

It's good to show that a page or process is loading, but if you can't see the screen, or are very zoomed in on a certain part, you can miss visual "loading" indicators and "spinners" that aren't set up for screen reader announcement.

The video loading indicator is visible, but screen readers don't announce anything. Screen reader users will get no information about the loading state, and may think that nothing is happening (or that the page is broken).

Suggestion

Specify with the help of role="status" or aria-live where important messages may occur, so that assistive technologies are aware of them and can present them to the user at an appropriate time.

There are many examples on the internet of available loading indicators, see this thread.

Steps to reproduce

Get a video into a loading state and see that it's not announced by assistive technologies.

Describe the expected behavior

(From WCAG 2.2)
In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus.

Additional information

PeerTube instance:
- URL: https://peertube-eu.howlround.com/
- Version: 7.2.1
- NodeJS version: Unknown
- Ffmpeg version: Unknown
Browser name, version and platforms on which you could reproduce the bug: MacOS 15.5, Google Chrome Version 137.0.7151.120 (Official Build) (arm64)

Additional context
This issue was recorded as part of an accessibility audit carried out by Axess Lab, contracted by HowlRound Theatre Commons.

Originally created by @Woebin on GitHub (Jul 2, 2025). ### Describe the current behavior This is a violation of the [Web Content Accessibility Guidelines (WCAG)](https://www.w3.org/TR/WCAG22) [SC 4.1.3 (AA) Status Messages](https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html) It's good to show that a page or process is loading, but if you can't see the screen, or are very zoomed in on a certain part, you can miss visual "loading" indicators and "spinners" that aren't set up for screen reader announcement. The video loading indicator is visible, but screen readers don't announce anything. Screen reader users will get no information about the loading state, and may think that nothing is happening (or that the page is broken). ### Suggestion Specify with the help of `role="status"` or [aria-live](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Live_Regions) where important messages may occur, so that assistive technologies are aware of them and can present them to the user at an appropriate time. There are many examples on the internet of available loading indicators, see [this thread](https://stackoverflow.com/questions/38518164/accessibility-page-loader-indicator-using-aria-live). ### Steps to reproduce Get a video into a loading state and see that it's not announced by assistive technologies. ### Describe the expected behavior (From WCAG 2.2) In content implemented using markup languages, [status messages](https://www.w3.org/TR/WCAG22/#dfn-status-messages) can be [programmatically determined](https://www.w3.org/TR/WCAG22/#dfn-programmatically-determinable) through [role](https://www.w3.org/TR/WCAG22/#dfn-role) or properties such that they can be presented to the user by [assistive technologies](https://www.w3.org/TR/WCAG22/#dfn-assistive-technologies) without receiving focus. ### Additional information * PeerTube instance: * URL: https://peertube-eu.howlround.com/ * Version: 7.2.1 * NodeJS version: Unknown * Ffmpeg version: Unknown * Browser name, version and platforms on which you could reproduce the bug: MacOS 15.5, Google Chrome Version 137.0.7151.120 (Official Build) (arm64) **Additional context** This issue was recorded as part of an accessibility audit carried out by [Axess Lab](https://axesslab.com/), contracted by [HowlRound Theatre Commons](https://howlround.com/).