RTA Accessibility Audit: A Technical Checklist

A page inventory is a useful starting point for a Registrar to an Issue and Share Transfer Agent (RTA). It is not a sufficient description of the application. The same URL can show an empty form, a validation failure, an upload in progress, or a completed request.

If the assessment captures only the first render, important behavior remains outside the evidence. A more useful approach is to map the state changes within selected investor tasks.

Define the test context before the component list

Choose an offered service, identify the account role, and record the relevant issuer or fund configuration. Arrange authorized access and test data that will not trigger real investor instructions.

Then describe a small set of meaningful paths. For a document-submission flow, those might be a valid file, a rejected file, and replacement of the rejected file. These are suggested scenarios, not universal requirements for every RTA portal.

Store the release identifier alongside the scenario. Without that context, a screenshot from staging can be mistaken for evidence about a different production build.

Examine feedback separately from focus

When a file is rejected, record what the user sees, where focus remains, and what the screen reader announces. Those observations expose different failure modes.

WCAG's explanation of status messages covers qualifying updates that can be presented through assistive technology without taking focus. It does not prescribe moving focus to every notification or announcing every minor change.

For the selected flow, investigate:

• Whether the upload control has an understandable name.
• Whether instructions are available before an error occurs.
• Whether rejection feedback identifies the problem.
• Whether the user can replace the file and continue.
• Whether successful completion is distinguishable from an unfinished request.

Automated tooling can support this work, but it cannot establish the entire interaction outcome by itself.

Include exported content in the dependency map

An acknowledgement PDF is produced by another part of the system, yet it belongs to the investor's task. Identify the template, generator, and document version rather than assigning every PDF defect to the frontend team.

Review the file's structure and usable reading order. After changing the template, generate another representative output and examine it. A manually repaired sample does not demonstrate that future exports are repaired.

The same ownership principle applies to embedded services. Identify the supplier and integration boundary, then make the affected step explicit in the audit scope.

Link shared fixes to configuration coverage

Suppose an upload component appears across multiple issuer areas. One component-level ticket may be appropriate, but the evidence should identify the affected instances and any behavior differences.

Retest the original failure first. Then select additional configurations based on differences in rules, content, or integration. Record that selection rather than describing the change as universal without support.

Each ticket should retain its user impact, reproduction steps, requirement mapping, implementation reference, and retest outcome. Redact investor data while preserving enough detail to reproduce the issue.

Hand over conclusions that another team can use

Separate technical status from reporting status. Engineering can say a change was deployed; the evaluator supplies evidence about the repaired behavior; compliance reviews the resulting submission.

C3 and C4 are SEBI submission tables, with separate report attachments under the September guidelines. Keep the underlying evidence navigable instead of compressing the assessment into a status label.

The goal is a traceable path from investor task to defect, change, and verified result. Use the full RTA guide to plan that handover:

Read the original guide on IAAP Audit: https://iaapaudit.com/blog/sebi-accessibility-audit-checklist-rtas