Comprobador de accesibilidad web

Shipping a template change on Friday and hoping accessibility “just works” is how empty links and missing lang attributes reach production. Automated checks will not replace a skilled audit, but they will catch a predictable set of HTML mistakes in minutes — if you know what they measure and what they ignore. The Accessibility Checker on Scrawl fetches one URL , parses the raw HTML (up to 1.5MB), and runs a fixed rule set: image alt , link and button names, form labels, heading structure, document lang and <title> , duplicate id values, and a small set of ARIA misuse patterns. JavaScript is not executed. Results are grouped by check with error, warning, and info severities — not a percentage score or WCAG certificate. ! Three-step flow from SSRF-safe fetch through capped static checks to issues by severity Why static HTML checks are worth running first Manual accessibility testing is slow. Fully manual testing of every component state is unrealistic before each deploy. Static linters trade depth for speed: they flag markup patterns that break baseline access — unnamed controls, missing document language, images without alt — before you spend time in VoiceOver or NVDA. That matters for three practical reasons: Usability and compliance context — Unlabeled form fields and icon-only links with no accessible name block people who rely on screen readers or voice control from completing tasks. Fixing those patterns in HTML is a practical baseline before deeper testing. Crawl and parsing — Search engines and assistive technologies both lean on HTML semantics. A missing <title> or duplicate id breaking a label[for] association hurts humans and creates brittle DOM hooks for scripts. Template QA — CMS swaps, header/footer refactors, and design-system rollouts repeat the same mistakes site-wide. One URL through a linter on a staging host catches class-level…