B85%
Quality Score
7
Pages
90
Issues
7.7
Avg Confidence
7.7
Avg Priority
34 Critical37 High19 Medium
>_ Testers.AI
AI Analysis
StackBlitz was tested and 90 issues were detected across the site. The most critical finding was: Decorative image missing explicit empty alt attribute (aria-hidden recommended). Issues span A11y, Content, UX, Other categories. Persona feedback rated Visual highest (8/10) and Accessibility lowest (6/10).
Qualitative Quality
StackBlitz
Category Avg
Best in Category
Pages Tested · 7 screenshots
Homepage
stackblitz.com
stackblitz.com
stackblitz.com
stackblitz.com
stackblitz.com
stackblitz.com
Detected Issues · 90 total
1
Decorative image missing explicit empty alt attribute (aria-hidden recommended)
CRIT P9
Prompt to Fix
In the home page template, locate the image tag for the decorative 'card-' image. Ensure it has an explicit empty alt attribute (alt="") and consider adding aria-hidden="true" to hide it from screen readers. If the image is not decorative, replace with a descriptive alt text. This aligns with WCAG 1.1.1 Non-text Content and WCAG 2.1 requirements. Example: <img src=".../card-" alt="" aria-hidden="true">
Why it's a bug
An image marked as decorative is missing an explicit empty alt attribute (hasAlt is false and isDecorative is true). Without an explicit empty alt, some screen readers may read the image filename or treat it as meaningful content, causing distraction or confusion for users relying on assistive technologies.
Why it might not be a bug
Decorative images should be hidden from assistive technologies via an empty alt (alt=""). If the image is truly decorative, leaving absence of an alt could still be read by some ATs; best practice is to explicitly mark it as decorative with alt="" or aria-hidden="true".
Suggested Fix
Add an explicit empty alt attribute alt="" to this decorative image, or set aria-hidden="true" to ensure screen readers ignore it. If the image conveys information, replace with a meaningful alt text describing its purpose.
Why Fix
Ensures screen reader users are not distracted by non-informational imagery and aligns with WCAG 1.1.1 Non-text Content and 2.4 Text Alternatives guidance, improving clarity and accessibility.
Route To
Frontend Developer / Accessibility Engineer
Page
Tester
Alejandro · Accessibility SpecialistTechnical Evidence
Console:
[ERROR] Failed to load resource: the server responded with a status of 401 ()Network:
Unauthorized resource requests and DNS resolution failures observed in console may affect rendering of decorative assets.2
UI: Empty label on close button (likely placeholder)
CRIT P9
Prompt to Fix
Audit the Sign-In modal UI and locate all interactive controls. For the close button with empty label, add an accessible label or visible text. If the button is intended to be icon-only, add aria-label='Close' and ensure keyboard focus indicator is visible. Update the UI templates to replace placeholder empty text with proper copy or icons with labels.
Why it's a bug
The Page Content data shows a button with an empty text label for the close button: {"text":"","tagName":"BUTTON","type":"button","id":"","className":"_closeButton_17tua_18"}. An invisible or unlabeled control hurts accessibility and may indicate a placeholder not replaced by final UI copy.
Why it might not be a bug
If the button is icon-only (e.g., an 'X'), it might be intentional; however, no accessible label is present in the data, which still poses accessibility and usability concerns.
Suggested Fix
Ensure close button has accessible labeling (aria-label="Close"), or provide visible text alongside the icon. Validate that all interactive controls have visible or screen-reader-friendly labels.
Why Fix
Improves accessibility, usability, and prevents hidden controls from confusing users.
Route To
Frontend Engineer
Page
Tester
Jason · GenAI Code AnalyzerTechnical Evidence
Console:
[ERROR] Failed to load resource: net::ERR_NAME_NOT_RESOLVEDNetwork:
GET https://stackblitz.com/sign_in - Status: 2003
Empty anchor text lacking accessible name
CRIT P9
Prompt to Fix
In the login page, locate all anchor (<a>) elements that render as navigation items. For any anchor that has no visible text, add descriptive text that communicates its purpose or add an aria-label with a clear description. Ensure the anchors have accessible names and are keyboard focusable. If an anchor is decorative, remove it or set aria-hidden="true". Follow WCAG 2.1 2.4.4 (Link Purpose In The Context) and 1.1.1 (Non-text Content).
Why it's a bug
There are anchor elements with empty visible text (text: "" and isGeneric: true). Without accessible names, screen readers cannot identify the purpose of these links, making navigation unusable for those relying on assistive tech.
Why it might not be a bug
If the anchors are decorative or rely on icons with proper aria-labels, they might be announced; however, the provided data shows empty text and no accessible name, which fails standard practices.
Suggested Fix
Provide descriptive text for each link or add an accessible name via aria-label or aria-labelledby. If the link is purely decorative, remove it or set aria-hidden="true".
Why Fix
Ensures links are discoverable and understandable by screen readers, improving navigation for users with visual impairments.
Route To
Frontend Developer / Accessibility Engineer
Page
Tester
Alejandro · Accessibility SpecialistTechnical Evidence
Console:
[ERROR] Failed to load resource: net::ERR_NAME_NOT_RESOLVED
[ERROR] Failed to load resource: net::ERR_NAME_NOT_RESOLVEDNetwork:
net::ERR_NAME_NOT_RESOLVED (resource failed to load)