YouTube
App Quality Report
Powered by Testers.AI
B+88%
Quality Score
6
Pages
38
Issues
8.1
Avg Confidence
7.9
Avg Priority
19 Critical11 High8 Medium
Testers.AI
>_ Testers.AI AI Analysis

YouTube was tested and 38 issues were detected across the site. The most critical finding was: Homepage feed content not loading; only empty screen with a guidance banner. Issues span Legal, A11y, Content, UX categories. Persona feedback rated Visual highest (7/10) and Accessibility lowest (5/10).

Qualitative Quality
YouTube
Category Avg
Best in Category
Issue Count by Type
Content
22
A11y
12
UX
6
Legal
1
Pages Tested · 6 screenshots
Detected Issues · 38 total
1
Homepage feed content not loading; only empty screen with a guidance banner
CRIT P9
Conf 9/10 ContentUX
Prompt to Fix
The homepage feed area is completely empty and only shows a centered 'Try searching to get started' banner. Fix by ensuring the main feed renders content (video thumbnails and metadata) or provide a robust skeleton/empty-state with a clear action. Investigate and resolve resource loading errors (e.g., net::ERR_NAME_NOT_RESOLVED) that block feed data. Ensure essential scripts and API calls load correctly, and implement graceful fallbacks if the network is slow or unavailable.
Why it's a bug
The primary goal of the YouTube homepage is to surface personalized video recommendations. In the screenshot, the main feed area is completely empty except for a centered banner, preventing users from discovering content and completing tasks (watching videos, exploring channels). This is a high-friction state that erodes trust and increases task abandonment.
Why it might not be a bug
If this is a deliberate offline/empty-state scenario, it should still present a meaningful, actionable empty state. However, the screenshot shows DNS/resource loading errors that indicate a failure to fetch core content, making this a true usability regression rather than an intentional edge case.
Suggested Fix
Diagnose and restore loading of the main feed content (thumbnails, metadata). If network/resource issues persist, implement robust skeletons or a clear empty-state with actionable steps (e.g., a prominent search button and recommended categories). Resolve DNS/resource loading errors that prevent thumbnails and feed data from rendering.
Why Fix
Restoring content or providing a meaningful empty state ensures users can accomplish the primary goal of discovering videos, reducing frustration, and maintaining trust in the product.
Route To
Frontend Engineer
Page
Tester
Mia · Usability Tester
Technical Evidence
Elements: Main feed area (empty), centered 'Try searching to get started' banner, left navigation, top search bar
Console: [error] Failed to load resource: net::ERR_NAME_NOT_RESOLVED
Network: DNS resolution failures preventing resource loading (thumbnails, feed data).
Page Text: Try searching to get started
2
Icon-only interactive controls lack accessible names
CRIT P9
Conf 9/10 A11y
Prompt to Fix
Review all interactive elements in the header and left navigation that render as icons without text. For each, add an accessible label either by adding a visible text label or by applying an appropriate aria-label/aria-labelledby. Ensure all buttons/links have meaningful names read by screen readers, and verify focus outlines are visible. Example patch: <button aria-label="Home" ...> <svg ...> </svg> </button> or <button><span class="sr-only">Home</span> <svg ...></svg></button> with corresponding CSS to visually hide the label but keep it accessible to assistive tech. Validate with a screen reader and keyboard navigation against WCAG 2.1 AA criteria 4.1.2 and 2.4.6.
Why it's a bug
The UI contains multiple interactive controls rendered as icon-only buttons with empty accessible names (hasAccessibleName is false). Screen readers cannot announce their purpose, making them unusable for users relying on assistive tech and keyboard navigation. This violates WCAG 2.1 4.1.2 (Name, Role, Value) and 2.4.6 (Headings/Labels) in practice for interactive controls.
Why it might not be a bug
If any of these icon-only elements are strictly decorative and non-interactive, they would not require a label. However, the presence of interactive navigation/icons suggests they should be accessible, and lack of names is a usability barrier.
Suggested Fix
Add accessible names to all icon-only buttons. Provide visible or screen-reader-only labels using aria-label or aria-labelledby, or replace icons with text labels. Example: <button aria-label="Home"> <svg>...</svg> </button> or associate with a hidden <span id="home-label">Home</span> and use aria-labelledby="home-label".
Why Fix
Ensures screen reader users can identify and activate navigation controls, improving task completion and trust for all users.
Route To
Frontend Developer / Accessibility Engineer
Page
Tester
Alejandro · Accessibility Specialist
3
Header search input missing accessible label
CRIT P9
Conf 9/10 OtherA11y
Prompt to Fix
Inspect the header search input and ensure it has an accessible label. If there is no visible label, add a screen-reader-only label or aria-label describing its purpose (for example, aria-label="Search YouTube" or a visible <label for='site-search'>Search</label> connected to the input with id='site-search'). Update ARIA attributes if necessary and verify with a screen reader and keyboard navigation. Ensure the label is programmatically associated and that focus outlines remain visible for keyboard users, aligning with WCAG 2.1 AA.
Why it's a bug
The search input in the header shows a placeholder but there is no associated visible label or aria-label. Screen readers rely on labels to describe form fields; without a label, the control's purpose is unclear, violating WCAG 2.1 3.3.2 Labels or Instructions and 4.1.2 Name, Role, Value.
Why it might not be a bug
If the input already has an explicit aria-label or is associated with a visible label elsewhere in the DOM, this issue would not exist. Based on the screenshot, there is no visible or labeled association present.
Suggested Fix
Associate a label with the input by id, or add an aria-label describing the control. Example: <label for="site-search" class="sr-only">Search the YouTube</label> <input id="site-search" aria-label="Search YouTube" ...> or <input aria-label="Search YouTube" ...> to ensure screen readers can announce the control.
Why Fix
Providing a clear label helps screen reader users understand the purpose of the search field, improving usability and task performance for users with visual or cognitive impairments.
Route To
Frontend Developer / Accessibility Engineer
Page
Tester
Alejandro · Accessibility Specialist
+35
35 more issues detected  View all →
Icon-only interactive controls lack accessible names
History action controls visible when no history exists (not ...
Left navigation icons lack accessible names (unlabeled inter...
and 32 more...
Unlock All 38 Issues
You're viewing the top 3 issues for YouTube.
Sign up at Testers.AI to access the full report with all 38 detected issues, detailed fixes, and continuous monitoring.
Sign Up at Testers.AI or let us run the tests for you