Quick answer
Demat 2.0 is a pilot involving tokenised corporate bonds, central-bank digital currency settlement and automated asset servicing. As new investor interfaces and workflows are designed, participating institutions must incorporate accessibility. Technology partners should consider accessibility from requirements through pilot validation. Accessibility is especially important for authentication, disclosure, transaction review, confirmation, records and error recovery.
Why accessibility belongs in infrastructure design
SEBI and RBI launched the pilot in September 2026. Participation was reported from CDSL, NSDL, BSE, NSE, HDFC Bank, ICICI Bank, and NPCI. The pilot began with institutional transactions and may inform broader future services.
This development is not itself an accessibility standard. The commercial and inclusion signal comes from the convergence of new digital infrastructure with existing duties affecting regulated digital platforms. If accessibility is postponed until large-scale adoption, barriers can become embedded across interfaces, APIs, documents and vendor components.
High-risk investor interactions
- Identity verification and account linking
- Authentication, OTP and consent
- Understanding bond details and risks
- Reviewing price, quantity, settlement and charges
- Confirming or cancelling a transaction
- Receiving status and failure notifications
- Accessing interest and redemption information
- Reading statements, contracts and disclosures
- Recovering from timeouts or errors
- Contacting support or raising complaints
Real-user consequences of inaccessible investment tools
A blind investor may receive an unlabeled transaction action or a data table without headers. A person using magnification may lose the relationship between quantity, price and fees. A keyboard user may be unable to select a settlement date. A customer with a cognitive disability may not understand the consequence of tokenisation or an irreversible action.
If the user needs another person to complete the transaction, financial privacy and control are reduced. In investment services, accessibility must protect informed decision-making as well as technical operation.
Data tables and changing market information must be understandable without relying only on visual position or colour. Time-sensitive actions need appropriate warnings and extensions where applicable. Confirmations should prevent accidental high-impact decisions.
Accessibility-by-design controls
Include disabled-user needs in pilot acceptance criteria. Require accessible design-system components. Test prototypes before coding. Validate APIs and third-party interfaces at integration points. Provide accessible HTML or properly tagged documents. Test with keyboard, screen readers, magnification and mobile assistive technologies. Preserve evidence so defects can be traced across institutions and vendors.
Security and accessibility should be designed together. An alternative authentication method must maintain appropriate security. It should avoid unnecessary dependence on memory, vision, or precise movement. It must also not rely on speech or a particular sensory ability.
Documents, disclosures and records
Tokenised instruments still depend on understandable information. Term sheets, risk disclosures, confirmations, statements, interest notices and redemption records should be available in accessible formats. Scanned or visually tagged PDFs can prevent screen-reader access and text reflow.
Source documents should use meaningful headings, table structure, lists, alternative text and logical reading order. Complex information may be easier to use in accessible HTML, supported by a properly tagged downloadable document.
Multi-party governance
Because the ecosystem involves regulators, depositories, exchanges, banks, issuers and technology providers, accessibility defects may cross organisational boundaries. The pilot should define ownership for shared components, APIs, documents, error messages and customer support.
Common acceptance criteria and an evidence repository can prevent duplicated effort. Each defect should identify the responsible component, affected institution, user impact and retest status.
Accessibility and operational resilience
Accessible design can improve resilience because it encourages clear status, multiple interaction methods, predictable errors and recoverable tasks. These qualities help users during poor connectivity, device limitations or temporary impairments as well as permanent disability.
Pilot teams should test interrupted transactions, delayed confirmations, failed identity checks and unavailable dependencies. Users need to know whether an order was submitted, whether money moved and what action is safe next. Ambiguous status can create financial loss.
Employee and support interfaces
Back-office reconciliation, exception handling and customer-support tools should also be accessible. Disabled employees may use these systems, and inaccessible internal tools can delay resolution for customers. Include operational dashboards, case queues, reports and administrative dialogs in representative testing.
Evidence before scaling
Before expansion, document the tested release, participating components, journeys, assistive technologies, unresolved defects and approved workarounds. Repeat testing after architectural or interface changes. This evidence can support governance decisions without overstating compliance.
Accessibility reviews should also cover onboarding instructions, help content, privacy notices and complaint procedures. These supporting experiences are essential when customers need to understand an unfamiliar investment model or recover from a failed action. Pilot feedback should be analysed by disability and interaction method. Participant privacy must be protected. This helps identify systemic barriers before wider adoption.
Pilot accessibility checklist
- Include disabled users and accessibility specialists in requirements.
- Map every end-to-end transaction and failure state.
- Define accessible authentication and consent alternatives.
- Validate complex data tables and market information.
- Provide review and cancellation before commitment.
- Announce real-time status changes programmatically.
- Create accessible disclosures and transaction records.
- Test integrated third-party components.
- Assign remediation ownership across participants.
- Complete independent retesting before expansion.
How Enabled.in helps
Enabled.in can support banks, exchanges, depositories, fintech providers and implementation partners. They can assist with accessibility requirements and prototype review. Journey testing and document evaluation are also supported. Additionally, they offer independent pilot validation.
Our work can cover WCAG 2.2 AA. It includes applicable IS 17802 and procurement requirements. We conduct manual and automated testing. Tools like NVDA, JAWS, VoiceOver, and TalkBack are used. We also conduct remediation workshops and retesting. Structured evidence is provided through ten10.in.
Frequently asked questions
Is Demat 2.0 already a public retail platform?
The September 2026 announcement describes a pilot beginning with corporate-bond issuances and institutional participants. Scope may evolve.
When should accessibility testing begin?
During requirements and prototype design, followed by testing at component, integration and end-to-end stages.
Can security justify an inaccessible journey?
Security is essential, but teams should seek secure alternatives that do not unnecessarily exclude people with disabilities.
Should institutional-only pilots include accessibility?
Yes. Employees and institutional users can have disabilities, and design patterns established during a pilot often continue into wider deployment.
Who should validate accessibility before expansion?
Independent specialists should work with participating product teams and users with disabilities to validate complete integrated journeys.
Conclusion
Demat 2.0 offers an opportunity to build inclusive investment infrastructure before patterns become fixed. Accessibility-by-design can strengthen independence, trust and operational quality.
Email: sathasivam@enabled.in