Theming done
This commit is contained in:
@@ -0,0 +1,47 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Render-blocking resources are minimized
|
||||
The site MUST minimize render-blocking resources on the critical path.
|
||||
|
||||
Font delivery MUST NOT rely on a render-blocking third-party stylesheet.
|
||||
|
||||
#### Scenario: Homepage avoids render-blocking font CSS
|
||||
- **WHEN** Lighthouse audits the homepage
|
||||
- **THEN** the Google Fonts stylesheet request is not present as a render-blocking resource (fonts are self-hosted or otherwise delivered without a blocking CSS request)
|
||||
|
||||
### Requirement: First-party CSS and JS are optimized for Lighthouse
|
||||
First-party CSS and JS delivered to the browser MUST be minified in production builds.
|
||||
|
||||
The site MUST minimize unused CSS and unused JavaScript on the homepage.
|
||||
|
||||
#### Scenario: CSS is minified
|
||||
- **WHEN** a production build is served
|
||||
- **THEN** `styles/global.css` (or its replacement) is minified
|
||||
|
||||
#### Scenario: Homepage avoids unused JS penalties
|
||||
- **WHEN** Lighthouse audits the homepage
|
||||
- **THEN** the amount of unused JavaScript on initial load is below Lighthouse's failing threshold
|
||||
|
||||
### Requirement: Images are delivered efficiently
|
||||
Images used on listing surfaces MUST be delivered in a size appropriate to their rendered dimensions.
|
||||
|
||||
For thumbnail-like images, the site SHOULD prefer image sources that support resizing or multiple resolutions when feasible.
|
||||
|
||||
#### Scenario: Podcast cover image is not oversized
|
||||
- **WHEN** the homepage renders a podcast episode card
|
||||
- **THEN** the fetched cover image size is reasonably close to the displayed size (no large wasted bytes flagged by Lighthouse)
|
||||
|
||||
### Requirement: Cache lifetimes are efficient for first-party assets
|
||||
First-party static assets (CSS/JS/fonts/images served from the site origin) MUST be served with cache headers that enable efficient repeat visits.
|
||||
|
||||
Non-fingerprinted assets MUST be served with revalidation (e.g., `no-cache` or `max-age=0,must-revalidate`) to avoid staleness.
|
||||
|
||||
Fingerprinted assets (build outputs) MUST be served with a long-lived immutable cache policy.
|
||||
|
||||
#### Scenario: First-party CSS has efficient caching
|
||||
- **WHEN** Lighthouse audits the homepage
|
||||
- **THEN** first-party CSS cache lifetimes are not flagged as inefficient
|
||||
|
||||
#### Scenario: Service worker script is revalidated
|
||||
- **WHEN** the browser checks `/sw.js` for updates
|
||||
- **THEN** the HTTP cache is bypassed or revalidated so an updated service worker can be fetched promptly
|
||||
@@ -0,0 +1,25 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Content Security Policy baseline
|
||||
The deployed site MUST include a Content Security Policy (CSP) that is compatible with the site's runtime behavior and third-party integrations.
|
||||
|
||||
The CSP MUST be strict enough to avoid DevTools Issues panel findings related to CSP and MUST NOT rely on a permissive `*` wildcard for script sources.
|
||||
|
||||
The CSP MUST allow:
|
||||
- the site's own scripts and styles
|
||||
- the configured analytics script origin (Umami)
|
||||
- required image origins (e.g., YouTube thumbnail host and podcast image CDN)
|
||||
- required frame origins (e.g., YouTube and Spotify embeds)
|
||||
|
||||
#### Scenario: No CSP issues logged
|
||||
- **WHEN** a user loads the homepage in Chrome
|
||||
- **THEN** no CSP-related issues are reported in the DevTools Issues panel
|
||||
|
||||
### Requirement: Avoid inline-script CSP violations
|
||||
The site SHOULD minimize the use of inline scripts to avoid requiring `unsafe-inline` in CSP.
|
||||
|
||||
If inline scripts are necessary, the CSP MUST use a nonce-based or hash-based approach.
|
||||
|
||||
#### Scenario: Inline scripts do not require unsafe-inline
|
||||
- **WHEN** the site is served with CSP enabled
|
||||
- **THEN** the policy does not require `script-src 'unsafe-inline'` to function
|
||||
@@ -0,0 +1,39 @@
|
||||
## MODIFIED Requirements
|
||||
|
||||
### Requirement: Sitemap and robots
|
||||
The site MUST provide:
|
||||
- `sitemap.xml` enumerating indexable pages
|
||||
- `robots.txt` that allows indexing of indexable pages
|
||||
|
||||
The sitemap MUST include the blog surface routes:
|
||||
- `/blog`
|
||||
- blog post detail routes
|
||||
- blog page detail routes
|
||||
- blog category listing routes
|
||||
|
||||
`robots.txt` MUST include a `Sitemap:` directive with an absolute URL to the sitemap (or sitemap index) and MUST NOT use a relative sitemap URL.
|
||||
|
||||
#### Scenario: Sitemap is available
|
||||
- **WHEN** a crawler requests `/sitemap.xml`
|
||||
- **THEN** the server returns an XML sitemap listing `/`, `/videos`, `/podcast`, `/about`, and `/blog`
|
||||
|
||||
#### Scenario: Blog URLs appear in sitemap
|
||||
- **WHEN** WordPress content is available in the cache at build time
|
||||
- **THEN** the generated sitemap includes the blog detail URLs for those items
|
||||
|
||||
#### Scenario: robots.txt includes absolute sitemap URL
|
||||
- **WHEN** a crawler requests `/robots.txt`
|
||||
- **THEN** the response includes a `Sitemap:` directive with an absolute URL (e.g., `https://<domain>/sitemap-index.xml`) that Lighthouse and crawlers can parse
|
||||
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Crawlable link markup
|
||||
The site MUST NOT render anchor elements (`<a>`) without an `href` attribute.
|
||||
|
||||
Interactive UI that does not navigate MUST use a `<button>` element (or equivalent role) instead of a placeholder anchor.
|
||||
|
||||
If an anchor is used for navigation, it MUST include a valid `href` in the initial HTML (not only populated later by client-side JavaScript).
|
||||
|
||||
#### Scenario: Modal CTAs are crawlable
|
||||
- **WHEN** the homepage is loaded and the media modal markup exists in the DOM
|
||||
- **THEN** any CTA anchors within the modal have valid `href` values, or are not rendered as anchors until an `href` is available
|
||||
@@ -0,0 +1,18 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Color contrast for secondary UI text and chips
|
||||
The site MUST meet WCAG 2.2 AA contrast requirements for non-decorative text, including secondary/muted metadata text and pill/chip labels.
|
||||
|
||||
This includes (but is not limited to):
|
||||
- card footer date and view-count text
|
||||
- pill/chip labels (e.g., source labels)
|
||||
|
||||
The contrast ratio MUST be at least 4.5:1 for normal text.
|
||||
|
||||
#### Scenario: Card metadata contrast passes
|
||||
- **WHEN** a content card is rendered with date and view-count metadata
|
||||
- **THEN** the metadata text has a contrast ratio of at least 4.5:1 against its background
|
||||
|
||||
#### Scenario: Pill label contrast passes
|
||||
- **WHEN** a pill/chip label is rendered (e.g., a source label)
|
||||
- **THEN** the pill label text has a contrast ratio of at least 4.5:1 against the pill background
|
||||
Reference in New Issue
Block a user