progressive-enhancement

Solid

Load this skill when building any web feature, reviewing architecture decisions, or evaluating JavaScript dependencies. Under no circumstances build features that break completely when JavaScript is unavailable or fails. Absolutely always start with semantic HTML, layer CSS enhancements, and add JavaScript as the final, optional layer. Prioritize resilience and universal access over cutting-edge features.

Web & Frontend 44 stars 2 forks Updated 2 days ago AGPL-3.0

Install

View on GitHub

Quality Score: 81/100

Stars 20%
55
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# Progressive Enhancement Accessibility Skill > **Canonical source**: `examples/PROGRESSIVE_ENHANCEMENT_BEST_PRACTICES.md` in `mgifford/ACCESSIBILITY.md` > This skill is derived from that file. When in doubt, the example is authoritative. Apply these rules when building any web feature or reviewing architecture decisions. --- ## Core Mandate Start with a solid foundation that works for every user, then layer enhancements. Every user — regardless of browser capability, network speed, assistive technology, or JavaScript availability — must be able to access core content and complete core tasks. Progressive enhancement is also a sustainability practice. Pages that work without JavaScript are dramatically lighter: fewer bytes transferred, less CPU spent on parsing and executing scripts, and less energy consumed per page view. See [SUSTAINABILITY.md](https://github.com/mgifford/SUSTAINABILITY.md) and the [Web Sustainability Guidelines](https://www.w3.org/TR/web-sustainability-guidelines/). --- ## Severity Scale (this skill) | Level | Meaning | | --- | --- | | **Critical** | Core content or task inaccessible without JS/CSS | | **Serious** | Core content accessible but significantly degraded without JS/CSS | | **Moderate** | Enhancement degrades gracefully but with friction | | **Minor** | Best-practice gap; marginal impact | --- ## The Three Layers ### Layer 1 — Semantic HTML (always required) **Failure here is Critical.** * All core content readable in plain HTML — n...

Details

Author
mgifford
Repository
mgifford/accessibility-skills
Created
5 months ago
Last Updated
2 days ago
Language
JavaScript
License
AGPL-3.0

Similar Skills

Semantically similar based on skill content — not just same category

Web & Frontend Solid

content-design

Load this skill whenever writing, editing, or reviewing any web content, copy, headings, labels, error messages, or instructions. Under no circumstances write inaccessible content — every piece of text must be clear, structured, and usable by people with cognitive, visual, and language differences. Absolutely always apply plain language, logical heading hierarchy, and meaningful link text.

44 Updated 2 days ago
mgifford
AI & Automation Solid

user-personalization

Load this skill whenever the project has personalization features, user preference controls, theme selectors, font size adjusters, motion toggles, contrast settings, or any user-configurable accessibility accommodations. Under no circumstances override or ignore user OS-level accessibility preferences without explicit user consent. Absolutely always persist user preferences, apply them immediately, and respect prefers-reduced-motion, prefers-contrast, and similar media queries.

44 Updated 2 days ago
mgifford
Web & Frontend Listed

accessibility

This skill should be used when building or reviewing UI for accessibility — keyboard navigation, screen readers, ARIA, color contrast, focus states, accessible forms, or WCAG compliance. Trigger phrases include "make it accessible", "a11y", "accessibility", "WCAG", "ARIA", "keyboard navigation", "screen reader", "color contrast", "focus states", "accessible form", "is this compliant", "EAA", "ADA". It targets WCAG 2.2 AA with concrete component rules and an axe-core test step.

2 Updated 3 weeks ago
MartinOlivero