AccessTool: Web3 Accessibility for the Polkadot Ecosystem

[ADACompliance]

Project Abstract

The vision of AccessTool is to become a Web3-native accessibility and compliance solution for Polkadot developers, Web3 projects, and dApps. With over 96.8% of websites failing WCAG compliance, Web3 platforms face even greater challenges due to dynamic content, blockchain interactions, and custom interfaces.

Designed to be powered by AI and blockchain, AccessTool will automate accessibility compliance, helping teams efficiently meet WCAG and ADA standards while reducing legal and reputational risks. AI-powered scans, one-click fixes, and on-chain verification will ensure transparency, security, and compliance across Polkadot parachains via XCM.

By bridging the gap between Web2 and Web3, AccessTool aims to deliver decentralized, verifiable accessibility audits that enhance inclusivity without disrupting development workflows. Streamline compliance, mitigate risk, and help build a more accessible Web3 with AccessTool.

Grant level

• Level 1: Up to $10,000, 2 approvals
• Level 2: Up to $30,000, 3 approvals
• Level 3: Unlimited, 5 approvals (for >$100k: Web3 Foundation Council approval)

Application Checklist

• The application template has been copied and aptly renamed (project_name.md).
• I have read the application guidelines.
• Payment details have been provided (Polkadot AssetHub (USDC & DOT) address in the application and bank details via email, if applicable).
• I understand that an agreed upon percentage of each milestone will be paid in vested DOT, to the Polkadot address listed in the application.
• I am aware that, in order to receive a grant, I (and the entity I represent) have to successfully complete a KYC/KYB check.
• The software delivered for this grant will be released under an open-source license specified in the application.
• The initial PR contains only one commit (squash and force-push if needed).
• The grant will only be announced once the first milestone has been accepted (see the announcement guidelines).
• I prefer the discussion of this application to take place in a private Element/Matrix channel. My username is: @_______:matrix.org (change the homeserver if you use a different one)

[github-actions]

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

[ADACompliance]

I have read and hereby sign the Contributor License Agreement.

[keeganquigley]

Thanks for the application @ADACompliance in the delivery tables, could you specify which license you would be using? Would all the code be open-source?

[ADACompliance]

Thanks for your feedback! I’ve updated the delivery tables to specify that the license is Apache 2.0. Let me know if anything else needs adjustment

[keeganquigley]

Thanks @ADACompliance I have marked the application as ready for review and will ping the rest of the committee for comment. In the meantime, I have a few more questions:

• Regarding M3, what language would the smart contracts be written in? If Solidity, are you aiming to deploy these on the Asset Hub?
• I don't see any Polkadot/substrate specific tech in the deliverables. What makes you want to integrate with Polkadot?
• Seeing as the Polkadot relay chain doesn't run smart contracts, how would you integrate this tool for parachains?

[semuelle]

Thank you for the application, @ADACompliance. Two questions:

• Have you done any tests or do you have previous work (reports, academic publications, etc.) to show that a neural network produces any useful output on accessibility of dapps?
• If there is so little interest in compliance, even in web2, why do you think you should target dapp developers with this? I understand using the blockchain as a reference to the report, but requiring devs to interact with the blockchain also creates additional hurdles.

[ADACompliance]

Thanks again @keeganquigley

• The smart contracts will be written in ink!, not Solidity. We plan to deploy on a Substrate-based parachain that supports ink! (Astar or Phala), would Asset hub be better I was told that it doesn’t support smart contracts?

• Polkadot offers cross-chain interoperability via XCM, allowing compliance data to be shared between parachains — a unique feature compared to other ecosystems. We're aiming to use Substrate for its modularity, low transaction costs, and ink! support, enabling efficient and decentralized compliance logging. Perhaps I misunderstood. We mentioned ink!, Substrate-based deployment, and XCM integration for data sharing. Or did you mean something beyond these?

• Correct, smart contracts will not be deployed on the relay chain, but on parachains that support contracts for example Astar The AccessTool platform will interact with these parachains to log and verify compliance data on-chain, and use XCM to make this data accessible across the Polkadot ecosystem.

[ADACompliance]

@semuelle Thank you for the questions.

• We’re currently in the prototyping phase. While we haven’t published academic work yet, our early experiments with Computer Vision (e.g., contrast detection, form label matching) and NLP for alt text generation on dynamic interfaces show promising results.

In Web2, tools like Accessibility Insights and Lighthouse are beginning to apply machine learning to detect issues such as low contrast or missing ARIA tags. In UI analysis, CNNs and Transformers have been used to assess accessibility from HTML or screenshots, identifying problems like small tap targets or poor contrast.

In Web3, accessibility is still a new and underexplored area. Most research focuses on security and usability, but with emerging legislation, there’s growing interest in how dApps exclude users with disabilities — for example, through screen reader incompatibility or non-accessible wallets. Web3 also presents unique challenges: there are no large labeled datasets, and interfaces often rely on non-standard components. We will be pioneering in this space by adapting WCAG-focused AI models (like IBM’s) to the Web3 environment. Findings and development will be open-sourced.

• Exactly why we’re starting now — regulatory pressure is catching up to digital accessibility. The EU Accessibility Act (2025) and the rising number of lawsuits in the U.S. are pushing compliance from a “nice-to-have” to a legal and financial must. Businesses are already getting sued — here’s a real-world example and discussion:

🔗 Reddit: PSA – Make Sure Your Website Is ADA Compliant

Note: this was from last year, even stricter laws have passed in 2025.

• Agreed — that’s why interacting with the blockchain is optional for basic use. Developers can use AccessTool off-chain for scans and fixes. Only if they want verifiable audit trails or need to meet regulatory standards would they push compliance records on-chain, our modular approach balances usability and decentralization (1) Off-chain for ease of use (2) On-chain for proof, compliance, and interoperability

[PieWol]

Hey @ADACompliance ,
I don't understand why traditional tools are useless for web3 applications. I agree that dApps work differently, as they fetch data from public sources like nodes or indexers instead of an company database, but why does this matter to the UI / UX? The way that new data is incorporated into the state of a dApp doesn't really make a difference as I see it.

I also don't agree on the idea to let a potentially faulty and hallucinating AI handle the audit for me if disobedience is so costly.

Despite the noble nature of your efforts, I personally don't see the need for this tool and I most likely won't approve it.

[ADACompliance]

@PieWol Thanks for the feedback
You're right that the data-fetching mechanics (e.g., from nodes or indexers) don’t inherently affect UI/UX. The issue we’re targeting isn't about where the data comes from, but how Web3 dApps typically break standard accessibility patterns — things like:

• Custom modals or interactions that don’t support keyboard navigation
• Lack of proper focus management in SPAs or wallet popups
• Canvas-based rendering or Shadow DOM use, which makes ARIA labeling more complex
• Dynamically injected content from smart contracts that lacks semantic markup

Traditional tools like WAVE or Axe often fail to pick these up properly, or don’t handle frameworks like Svelte, Web3Modal, or MetaMask popups well, especially outside the DOM.

As for AI yes it's not perfect, none at this stage is, however the whole industry is trending towards this because it’s the most reasonable approach.

Can you please clarify what you mean here “ I also don't agree on the idea to let a potentially faulty and hallucinating AI handle the audit for me if disobedience is so costly.”? what exact scenario do you imagine?

That said, I hear you if this doesn’t align with your current priorities, I completely understand. However, this isn’t just about the noble mission of inclusion. It’s also about meeting growing legal requirements that are already impacting digital products the EU Accessibility Act, for instance, is not optional.

Our goal with AccessTool isn’t to replace developers it’s to save them from the hours they’ll end up spending anyway on manual audits or after-the-fact fixes. We are making compliance faster, cheaper, and less painful, not riskier.

[ADACompliance]

@PieWol Also, out of curiosity, in cases like dynamic interfaces or custom wallet flows, is there a particular Web2 accessibility tool you’ve found reliable? I’d love to see what you’d recommend, especially if it’s something we could learn from or potentially integrate.