The 15th Global Accessibility Awareness Day lands at a genuinely important inflection point in the world of accessibility and the wider technology. Software teams are shipping faster than ever, and more of what you ship is being generated, scaffolded, or accelerated by AI. That shift raises the stakes in a specific way: AI doesn't make software more or less accessible by default. It amplifies whatever choices a team has already made and continues to. Teams that have accessibility embedded in their workflow will find AI makes them more productive. Teams that don't will find it makes inaccessibility scale faster, across more surfaces, and at a pace that's much harder to unwind than ever before.

This is exactly why it matters that accessibility software spans the entire software development lifecycle — starting in design, running through code and CI/CD, ticketed to track burndowns, and tying product work back to policy and governance. Not because it's all the rage now, but because it's the only way it actually works.

Stark is built to cover that full span. And to celebrate 15 years of GAAD, we're rolling out 15 features for everyone on the software team...

Smarter annotations across every platform your designers touch

Auto-annotations for iOS, Android, and ARIA
In Stark's accessibility notes, selecting a platform and the element you want to annotate now triggers automatic detection and annotation of as much as possible — so designers aren't filling things manually. For VoiceOver, Stark detects labels, values, hints, and traits. For TalkBack, it detects roles and fields. For ARIA, it detects roles and labels. 

The things that used to require a designer to manually mark every heading, link, and interactive element are handled automatically, with the platform's own annotation logic applied. And soon, we're taking this further with cross-platform annotation intelligence, so the knowledge Stark builds up about one platform and your system starts informing the others.

Auto-annotate focus order and landmarks
Stark now suggests focus order and landmark annotations automatically, so designers aren't starting from a blank canvas when documenting keyboard navigation and page structure. The suggestions are based on the design’s actual layout, context, and component hierarchy, giving teams a starting point to review and refine rather than build from scratch. And while the teams are the final judges (as you hold the most context) teams new to accessibility, this is also one of the fastest ways to build intuition for what it looks like to set in place focus order and landmark structure.

Text variables support in the Figma plugin
When designs use text variables across components, Stark now resolves those values by ensuring they adhere to standards and stay within the typographical system created by the design system, instead of making a base level suggestion for a type fix.

Accessibility checks embedded where designers and developers actually work

Color suggestions restricted to your design system (if you prefer)
When Stark suggests a fix for a contrast failure, teams now have the option to restrict those suggestions to just your design system rather than returning a valid color outside of that. Wire up your Figma file or design system tokens, and flip on the feature which can be found under “Governance” in Stark. The result: remediation that stays accessible while on-brand by default.

Filter by severity and category across Browser, Reports, and CI/CD
For teams triaging a backlog, the ability to focus on critical violations first — or batch work by category — transforms triage from overwhelming to concise and actionable. This filter is now consistent across the Browser extension, report views, and CI/CD outputs.

Browser snapshots for continuous accessibility monitoring
Stark's browser scan now creates accessibility baselines for any URL (live or authentication required) that traditional URL scanners can't reach. Once a baseline is set, Live URL monitoring tracks changes against it. When an update introduces new issues, the count goes up against the baseline and alerts go out (if you have them set up) via email, Slack, or Teams rather than waiting for the next audit cycle. Every snapshot persists, so teams have a living audit record that shows exactly how accessibility has changed across sprints, redesigns, and remediation efforts.

Stark source code scanning
Stark source code scanning gives teams a comprehensive accessibility audit via CLI and CI/CD. Run npx stark-scan-react src/ against a full codebase, wire it into a pre-commit hook or pipeline, and results sync automatically to your Stark dashboard. Supported across React, Vue, Angular, React Native, Flutter, and Svelte. For teams using agentic development workflows, source code scanning also feeds directly into AI-assisted remediation in your IDE or terminal: the violations come back with file paths, line numbers, WCAG mappings, and severity levels, so fixes can be automated with the full context they need.

Svelte support [for source code integrations]
We added Svelte to our source code integrations, completing coverage across the major component frameworks. Teams building with Svelte now get the same in-context scanning that React, Vue, and Angular teams have — violations surfaced in the editor, not discovered in production.

Storybook integration
Stark now integrates directly with Storybook, which means accessibility checks happen inside the component development environment itself. For teams building and documenting components in isolation, this is the earliest possible point to catch issues — before they ever reach the product.

Stark MCP now supports fetching violations lists
Stark's MCP now supports fetching a full violations list for any asset — WCAG mappings, severity levels, file paths, line numbers — so AI agents can act on real Stark data directly. This is what makes AI-assisted remediation actually work: the AI has the full context it needs to get to work, not an outdated spreadsheet export.

Ticketing integrations that treat accessibility issues like the quality bugs they are

Severity mapping to ticket priority
Issue severity levels now carry through automatically to ticket priority, so a critical WCAG failure doesn't get filed as a "medium-priority" ticket by default. The triage judgment that used to happen manually, and inconsistently, is now built in.

Auto-labeling for Stark-origin tickets
Issues created via Stark are now auto-tagged with Stark, accessibility, a11y, bugs, and more (if those are already labels in your ticket management system). Over time, teams can see exactly what percentage of their bug backlog is accessibility-related work detected by Stark, roadmap further burndowns, and report on it with confidence.

Bulk ticket creation
An entire category of issues can now be filed at once rather than one by one. For a project with a meaningful backlog, this is the difference between an afternoon of ticket creation and a few seconds.

Mapping Stark projects to default ticketing projects
Ticketing projects can now be mapped to Stark projects directly, so issues route to the right team automatically. The right work lands in the right place without anyone having to manually redirect it.

Reports that are useful beyond the tool

VPAT automation with inline guidance
VPATs Are a procurement standard that's notoriously and historically opaque. Stark's automated VPAT draft generation now includes inline guidance on each criterion: plain-language explanations of what it means, what evidence satisfies it, and where teams commonly make mistakes. The goal is for the person filling it out to take it from draft to final, by understanding the standard, not just check a box — ensuring Stark upskills the team and satiates a requirement, not just producing a document.

Redesigned HTML report
The HTML report got a full redesign — cleaner layout, better information hierarchy, all accordions expanded by default so it prints and saves to PDF correctly without requiring manual interaction. It's also the first step in a broader redesign coming to asset reporting across Stark, so teams using it now are getting an early look at the direction the whole reporting experience is heading.

Fifteen years in

GAAD has always been a prompt for the makers who build software to think more carefully about the people who use it. That prompt is more urgent now than it was in 2012. Not only are people more aware and engaged, but the pace of software production keeps accelerating, and accessibility can slip through the gaps if it isn't embedded in the process itself.

The teams that will get this right are the ones who make accessibility part of how they work every day — in Figma, LLMs, IDEs or terminal, sprint boards, or legal compliance reviews. Stark is built to support all of it. Here's to 15 more years of shipping it forward into the future...and doing it well.

---

💬 Want to give these all a spin? Kick off a free two-week trial (no credit card required!) straight away. Individual blog posts for each to follow.

Feel free to share your thoughts and feedback at support@getstark.co, or join the conversations in our Stark Slack Community, on LinkedIn, and on Twitter.