accessibility

Name: accessibility
Author: krzysztofsurdy

37installs1forks

How to install accessibility?

krzysztofsurdy/code-virtuoso/accessibility

$npx -y skills add krzysztofsurdy/code-virtuoso --skill accessibility

Installs into the current project.

Summary

Web accessibility patterns and WCAG 2.1/2.2 compliance for inclusive user interfaces. Use when the user asks to build accessible components, audit a UI for a11y issues, fix screen reader problems, implement keyboard navigation, check color contrast ratios, add ARIA attributes, cr

Files · 1

View on GitHub

SKILL.md

1	# Web Accessibility
2
3	Accessibility is not a feature you bolt on at the end - it is a quality attribute that must be considered from the first line of markup. Building accessible interfaces means that people with visual, motor, auditory, or cognitive disabilities can perceive, navigate, and interact with your application. It also means better usability for everyone: keyboard power users, people on slow connections, users with temporary injuries, and those in constrained environments.
4
5	## Why Accessibility Matters
6
7	\| Dimension \| Impact \|
8	\|---\|---\|
9	\| Legal \| Legislation in most jurisdictions (ADA, EAA, Section 508, EN 301 549) requires digital products to be accessible. Non-compliance carries litigation risk and financial penalties. \|
10	\| Ethical \| Roughly 16% of the global population lives with some form of disability. Excluding them from digital services is a choice, not an inevitability. \|
11	\| Business \| Accessible products reach a wider audience, improve SEO (structured content helps crawlers), reduce support costs, and correlate with higher overall usability scores. \|
12	\| Technical quality \| Accessibility constraints force clean markup, proper semantics, and separation of concerns - all of which improve maintainability. \|
13
14	---
15
16	## WCAG Principles: POUR
17
18	The Web Content Accessibility Guidelines organize all success criteria under four principles. Every accessibility requirement maps to at least one.
19
20	\| Principle \| Question It Answers \| Examples \|
21	\|---\|---\|---\|
22	\| Perceivable \| Can users sense the content? \| Text alternatives for images, captions for video, sufficient color contrast, resizable text \|
23	\| Operable \| Can users interact with every control? \| Keyboard operability, enough time to complete tasks, no seizure-triggering animations, clear navigation \|
24	\| Understandable \| Can users comprehend the content and UI behavior? \| Readable language, predictable navigation, input assistance and error messages \|
25	\| Robust \| Does it work across assistive technologies? \| Valid markup, proper use of ARIA, compatibility with screen readers and other tools \|
26
27	---
28
29	## Conformance Levels
30
31	WCAG defines three levels. Each higher level includes all criteria from the levels below it.
32
33	\| Level \| Target Audience \| Typical Requirement \|
34	\|---\|---\|---\|
35	\| A \| Bare minimum - removes the most severe barriers \| Most legal and procurement requirements start here \|
36	\| AA \| Industry standard - addresses the majority of barriers for most users \| Required by ADA, EAA, Section 508, and most organizational policies \|
37	\| AAA \| Highest standard - not always achievable for all content types \| Aspirational goal; apply selectively where feasible \|
38
39	For most projects, target Level AA. It covers the vast majority of real-world accessibility needs without imposing requirements that conflict with certain content types.
40
41	---
42
43	## Semantic HTML Fundamentals
44
45	Native HTML elements carry built-in semantics, keyboard behavior, and screen reader announcements. Using the right element is the single most effective accessibility technique.
46
47	\| Instead Of \| Use \| Why \|
48	\|---\|---\|---\|
49	\| `<div onclick="...">` \| `<button>` \| Buttons are focusable, announce their role, and respond to Enter and Space \|
50	\| `<span class="link">` \| `<a href="...">` \| Links announce as "link," support middle-click, and appear in link lists \|
51	\| `<div class="header">` \| `<header>`, `<nav>`, `<main>`, `<footer>` \| Landmark elements let screen reader users jump between page regions \|
52	\| `<div class="list">` \| `<ul>` / `<ol>` with `<li>` \| Lists announce item count and position ("item 3 of 7") \|
53	\| `<div class="table">` \| `<table>` with `<th>` \| Table headers associate data cells with their labels for screen readers \|
54	\| Styled `<div>` for input \| `<input>`, `<select>`, `<textarea>` \| Native form controls have label association, validation, and assistive tech support built in \|
55
56	### Heading Hierarchy
57
58	Headings create an outline that screen reader users navigate like a table of contents. Follow these rules:
59
60	- One `<h1>` per page that describes the page purpose
61	- Never skip levels (do not jump from `<h2>` to `<h4>`)
62	- Use headings for structure, not for visual styling - CSS handles appearance
63
64	---
65
66	## Common Accessibility Issues
67
68	\| Issue \| Impact \| Fix \|
69	\|---\|---\|---\|
70	\| Missing alt text on images \| Screen readers announce the filename or nothing \| Add descriptive `a

People who liked this also viewed

6 picks

Type

accessibility

37installs1forks

View on GitHub

How to install accessibility?

krzysztofsurdy/code-virtuoso/accessibility

$npx -y skills add krzysztofsurdy/code-virtuoso --skill accessibility

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Web Accessibility
2
3	Accessibility is not a feature you bolt on at the end - it is a quality attribute that must be considered from the first line of markup. Building accessible interfaces means that people with visual, motor, auditory, or cognitive disabilities can perceive, navigate, and interact with your application. It also means better usability for everyone: keyboard power users, people on slow connections, users with temporary injuries, and those in constrained environments.
4
5	## Why Accessibility Matters
6
7	\| Dimension \| Impact \|
8	\|---\|---\|
9	\| Legal \| Legislation in most jurisdictions (ADA, EAA, Section 508, EN 301 549) requires digital products to be accessible. Non-compliance carries litigation risk and financial penalties. \|
10	\| Ethical \| Roughly 16% of the global population lives with some form of disability. Excluding them from digital services is a choice, not an inevitability. \|
11	\| Business \| Accessible products reach a wider audience, improve SEO (structured content helps crawlers), reduce support costs, and correlate with higher overall usability scores. \|
12	\| Technical quality \| Accessibility constraints force clean markup, proper semantics, and separation of concerns - all of which improve maintainability. \|
13
14	---
15
16	## WCAG Principles: POUR
17
18	The Web Content Accessibility Guidelines organize all success criteria under four principles. Every accessibility requirement maps to at least one.
19
20	\| Principle \| Question It Answers \| Examples \|
21	\|---\|---\|---\|
22	\| Perceivable \| Can users sense the content? \| Text alternatives for images, captions for video, sufficient color contrast, resizable text \|
23	\| Operable \| Can users interact with every control? \| Keyboard operability, enough time to complete tasks, no seizure-triggering animations, clear navigation \|
24	\| Understandable \| Can users comprehend the content and UI behavior? \| Readable language, predictable navigation, input assistance and error messages \|
25	\| Robust \| Does it work across assistive technologies? \| Valid markup, proper use of ARIA, compatibility with screen readers and other tools \|
26
27	---
28
29	## Conformance Levels
30
31	WCAG defines three levels. Each higher level includes all criteria from the levels below it.
32
33	\| Level \| Target Audience \| Typical Requirement \|
34	\|---\|---\|---\|
35	\| A \| Bare minimum - removes the most severe barriers \| Most legal and procurement requirements start here \|
36	\| AA \| Industry standard - addresses the majority of barriers for most users \| Required by ADA, EAA, Section 508, and most organizational policies \|
37	\| AAA \| Highest standard - not always achievable for all content types \| Aspirational goal; apply selectively where feasible \|
38
39	For most projects, target Level AA. It covers the vast majority of real-world accessibility needs without imposing requirements that conflict with certain content types.
40
41	---
42
43	## Semantic HTML Fundamentals
44
45	Native HTML elements carry built-in semantics, keyboard behavior, and screen reader announcements. Using the right element is the single most effective accessibility technique.
46
47	\| Instead Of \| Use \| Why \|
48	\|---\|---\|---\|
49	\| `<div onclick="...">` \| `<button>` \| Buttons are focusable, announce their role, and respond to Enter and Space \|
50	\| `<span class="link">` \| `<a href="...">` \| Links announce as "link," support middle-click, and appear in link lists \|
51	\| `<div class="header">` \| `<header>`, `<nav>`, `<main>`, `<footer>` \| Landmark elements let screen reader users jump between page regions \|
52	\| `<div class="list">` \| `<ul>` / `<ol>` with `<li>` \| Lists announce item count and position ("item 3 of 7") \|
53	\| `<div class="table">` \| `<table>` with `<th>` \| Table headers associate data cells with their labels for screen readers \|
54	\| Styled `<div>` for input \| `<input>`, `<select>`, `<textarea>` \| Native form controls have label association, validation, and assistive tech support built in \|
55
56	### Heading Hierarchy
57
58	Headings create an outline that screen reader users navigate like a table of contents. Follow these rules:
59
60	- One `<h1>` per page that describes the page purpose
61	- Never skip levels (do not jump from `<h2>` to `<h4>`)
62	- Use headings for structure, not for visual styling - CSS handles appearance
63
64	---
65
66	## Common Accessibility Issues
67
68	\| Issue \| Impact \| Fix \|
69	\|---\|---\|---\|
70	\| Missing alt text on images \| Screen readers announce the filename or nothing \| Add descriptive `a

People who liked this also viewed

6 picks

Type