JAWS Accessibility Skill
Provide practical, implementation-first support for accessible web interfaces and accessibility audits.
Use progressive disclosure. Load only the reference file needed for the current task.
Reference Routing
| Situation |
File to load |
| Legal scope, obligations, timelines, exemptions |
references/spanish-eu-legislation.md |
| Priority WCAG 2.2 patterns and links to the complete normative matrix |
references/wcag-22-criteria.md |
| JAWS/NVDA behavior differences, ARIA compatibility, anti-patterns |
references/jaws-nvda-compatibility.md |
| End-to-end audit execution and reporting |
references/jaws-audit-methodology.md |
| WCAG 3.0 monitoring and future planning |
references/future-standards.md |
PDF accessibility is outside this skill's testing scope. If a web audit includes published PDFs, route those files to a dedicated PDF-accessibility methodology or specialist. Keep them in the product inventory and record NOT TESTED until that separate evaluation is complete; never infer PDF/UA or WCAG conformance from a browser or screen-reader spot check.
Operating Rules
- Prioritize native HTML semantics before ARIA.
- Treat WCAG 3.0 as non-normative draft guidance, not a compliance baseline.
- If legal/compliance is requested, state exact dates and legal scope explicitly.
- Distinguish mandatory requirements from recommended best practices.
- Validate with at least:
- JAWS + Chrome
- NVDA + Firefox
For a formal or full audit, record the complete environment described in
references/jaws-audit-methodology.md. If either reader is unavailable, continue with code, keyboard, accessibility-tree, and automated checks, but label the screen-reader result as NOT TESTED; never infer a pass.
- For SPA flows, always verify:
- focus placement after route changes
- meaningful page title updates
- announcement behavior for status changes
- When uncertain about AT/browser behavior, request or document the exact JAWS/NVDA/browser versions.
Delivery Format
For implementation tasks:
- explain user impact
- identify the root cause
- provide a minimal fix
- add a quick manual test script for keyboard + JAWS + NVDA
For audit tasks:
- use the 8-phase flow in
references/jaws-audit-methodology.md
- group findings by severity: Critical, High, Medium, Low
- map each finding to WCAG SC, technical evidence, reproduction steps, and remediation
- use only
PASS, FAIL, NOT TESTED, or NOT APPLICABLE for evaluation results; do not turn missing evidence into a pass
For legal/compliance scope questions:
- start with
references/spanish-eu-legislation.md
- clarify whether the case is private-sector or public-sector
- mark legal interpretation as operational guidance, not legal advice
Known Compatibility Risks
Screen readers regress often. Unless you have verified a specific JAWS/browser/version combination yourself, do not present version-specific quirks as guaranteed facts.
High-risk patterns:
- grids and complex tables where meaning depends only on ARIA state
aria-current, aria-description, or aria-roledescription used as the only carrier of critical information- live-region announcements injected too late
- SPA navigation without explicit focus management
Mitigation:
- do not rely on one ARIA attribute alone for critical meaning
- provide visible and textual redundancy
- resolve standards questions against HTML, WAI-ARIA, WCAG, and platform accessibility mappings; no screen reader is a conformance oracle
- document exact AT/browser versions when behavior differs
Most Frequent Critical Errors
| Error |
Impact |
Solution |
aria-hidden="true" on a container with focusable descendants |
Silent focusable "ghost" elements |
Use display:none, visibility:hidden, or remove focusability |
| Nested interactive elements |
Repeated or confusing announcements |
Use one interactive control with the correct semantic role |
| Data table or grid with weak semantics |
Headers and state may not be exposed reliably |
Use correct table/grid semantics and test in JAWS and NVDA |
| Live region created and populated at the same time |
Announcement may be skipped |
Render the live region container first, then update its contents |
| SPA route changes without focus management |
Focus stays behind or becomes unclear |
Move focus to the new page heading or landmark |
| Removed visible focus styles |
Keyboard users lose orientation |
Keep visible focus indicators |
| Competing announcement mechanisms |
Double or inconsistent speech output |
Separate live-region and descriptive text responsibilities |
Quick Checklist
Before delivering any web component:
- Is all functionality operable with keyboard only?
- Do interactive elements have clear accessible names?
- Is text contrast >= 4.5:1 and UI element contrast >= 3:1, subject to the applicable WCAG exceptions?
- Do pointer targets satisfy WCAG 2.5.8 (24x24 CSS px or an allowed spacing/exception), with 44x44 as a usability target where practical?
- Do images have correct
alt behavior?
- Does the page have
<html lang> and logical headings?
- Do forms have labels, errors, and appropriate
autocomplete?
- Do modals trap focus and return it to the trigger on close?
- Do live regions exist in initial HTML?
- Has it been tested with JAWS + Chrome and NVDA + Firefox, or explicitly marked NOT TESTED with those readers?
Common Implementation Priorities
- Keyboard operability and visible focus
- Name/Role/Value integrity
- Robust form labels, errors, and instructions
- Focus management in dialogs, menus, and SPAs
- Accessible tables, status messages, and live regions
- Touch target size and alternative input methods
Escalation Points
Escalate risk when:
- a component works in one reader but fails in the other
- compliance claims rely only on automated tools
- focus is lost, trapped, or visually hidden
- live-region behavior is not deterministic
- a legal answer depends on sector-specific enforcement details
Maintaining This Skill
When changing this skill, keep SKILL.md as the router and put detailed procedures in the routed references. Validate the canonical directory before installing it:
python C:\Users\Tecnología\.codex\skills\.system\skill-creator\scripts\quick_validate.py .
python scripts\validate_skill_content.py .
python -m unittest discover -s tests -p "test_*.py"
The semantic validator covers critical command mappings, standards status, legal definitions, audit evidence, official-source links, and synchronization. Structural validation alone is not evidence that the guidance is correct.
1---2name: jaws-accessibility3description: Accessibility engineering for web products with JAWS/NVDA testing and Spain/EU compliance scoping. Use for WCAG 2.2 implementation, ARIA and keyboard/focus behavior, screen-reader regressions, audits, remediation plans, or web-accessibility scope checks under Ley 11/2023, RD 1112/2018, RD 193/2023, the EAA, and EN 301 549. Do NOT use for native mobile apps, PDF accessibility, or non-web content.4---56# JAWS Accessibility Skill78Provide practical, implementation-first support for accessible web interfaces and accessibility audits.910Use progressive disclosure. Load only the reference file needed for the current task.1112## Reference Routing1314| Situation | File to load |15|---|---|16| Legal scope, obligations, timelines, exemptions | `references/spanish-eu-legislation.md` |17| Priority WCAG 2.2 patterns and links to the complete normative matrix | `references/wcag-22-criteria.md` |18| JAWS/NVDA behavior differences, ARIA compatibility, anti-patterns | `references/jaws-nvda-compatibility.md` |19| End-to-end audit execution and reporting | `references/jaws-audit-methodology.md` |20| WCAG 3.0 monitoring and future planning | `references/future-standards.md` |2122PDF accessibility is outside this skill's testing scope. If a web audit includes published PDFs, route those files to a dedicated PDF-accessibility methodology or specialist. Keep them in the product inventory and record **NOT TESTED** until that separate evaluation is complete; never infer PDF/UA or WCAG conformance from a browser or screen-reader spot check.2324## Operating Rules25261. Prioritize native HTML semantics before ARIA.272. Treat WCAG 3.0 as non-normative draft guidance, not a compliance baseline.283. If legal/compliance is requested, state exact dates and legal scope explicitly.294. Distinguish mandatory requirements from recommended best practices.305. Validate with at least:31 - JAWS + Chrome32 - NVDA + Firefox33 For a formal or full audit, record the complete environment described in `references/jaws-audit-methodology.md`. If either reader is unavailable, continue with code, keyboard, accessibility-tree, and automated checks, but label the screen-reader result as **NOT TESTED**; never infer a pass.346. For SPA flows, always verify:35 - focus placement after route changes36 - meaningful page title updates37 - announcement behavior for status changes387. When uncertain about AT/browser behavior, request or document the exact JAWS/NVDA/browser versions.3940## Delivery Format4142For implementation tasks:43- explain user impact44- identify the root cause45- provide a minimal fix46- add a quick manual test script for keyboard + JAWS + NVDA4748For audit tasks:49- use the 8-phase flow in `references/jaws-audit-methodology.md`50- group findings by severity: Critical, High, Medium, Low51- map each finding to WCAG SC, technical evidence, reproduction steps, and remediation52- use only `PASS`, `FAIL`, `NOT TESTED`, or `NOT APPLICABLE` for evaluation results; do not turn missing evidence into a pass5354For legal/compliance scope questions:55- start with `references/spanish-eu-legislation.md`56- clarify whether the case is private-sector or public-sector57- mark legal interpretation as operational guidance, not legal advice5859## Known Compatibility Risks6061Screen readers regress often. Unless you have verified a specific JAWS/browser/version combination yourself, do not present version-specific quirks as guaranteed facts.6263High-risk patterns:64- grids and complex tables where meaning depends only on ARIA state65- `aria-current`, `aria-description`, or `aria-roledescription` used as the only carrier of critical information66- live-region announcements injected too late67- SPA navigation without explicit focus management6869Mitigation:70- do not rely on one ARIA attribute alone for critical meaning71- provide visible and textual redundancy72- resolve standards questions against HTML, WAI-ARIA, WCAG, and platform accessibility mappings; no screen reader is a conformance oracle73- document exact AT/browser versions when behavior differs7475## Most Frequent Critical Errors7677| Error | Impact | Solution |78|---|---|---|79| `aria-hidden="true"` on a container with focusable descendants | Silent focusable "ghost" elements | Use `display:none`, `visibility:hidden`, or remove focusability |80| Nested interactive elements | Repeated or confusing announcements | Use one interactive control with the correct semantic role |81| Data table or grid with weak semantics | Headers and state may not be exposed reliably | Use correct table/grid semantics and test in JAWS and NVDA |82| Live region created and populated at the same time | Announcement may be skipped | Render the live region container first, then update its contents |83| SPA route changes without focus management | Focus stays behind or becomes unclear | Move focus to the new page heading or landmark |84| Removed visible focus styles | Keyboard users lose orientation | Keep visible focus indicators |85| Competing announcement mechanisms | Double or inconsistent speech output | Separate live-region and descriptive text responsibilities |8687## Quick Checklist8889Before delivering any web component:90911. Is all functionality operable with keyboard only?922. Do interactive elements have clear accessible names?933. Is text contrast >= 4.5:1 and UI element contrast >= 3:1, subject to the applicable WCAG exceptions?944. Do pointer targets satisfy WCAG 2.5.8 (24x24 CSS px or an allowed spacing/exception), with 44x44 as a usability target where practical?955. Do images have correct `alt` behavior?966. Does the page have `<html lang>` and logical headings?977. Do forms have labels, errors, and appropriate `autocomplete`?988. Do modals trap focus and return it to the trigger on close?999. Do live regions exist in initial HTML?10010. Has it been tested with JAWS + Chrome and NVDA + Firefox, or explicitly marked **NOT TESTED** with those readers?101102## Common Implementation Priorities1031041. Keyboard operability and visible focus1052. Name/Role/Value integrity1063. Robust form labels, errors, and instructions1074. Focus management in dialogs, menus, and SPAs1085. Accessible tables, status messages, and live regions1096. Touch target size and alternative input methods110111## Escalation Points112113Escalate risk when:114- a component works in one reader but fails in the other115- compliance claims rely only on automated tools116- focus is lost, trapped, or visually hidden117- live-region behavior is not deterministic118- a legal answer depends on sector-specific enforcement details119120## Maintaining This Skill121122When changing this skill, keep `SKILL.md` as the router and put detailed procedures in the routed references. Validate the canonical directory before installing it:123124```powershell125python C:\Users\Tecnología\.codex\skills\.system\skill-creator\scripts\quick_validate.py .126python scripts\validate_skill_content.py .127python -m unittest discover -s tests -p "test_*.py"128```129130The semantic validator covers critical command mappings, standards status, legal definitions, audit evidence, official-source links, and synchronization. Structural validation alone is not evidence that the guidance is correct.
Ambitos-1995