Context
A large Australian bank needed a more consistent way to build accessibility into how digital products are designed, built and delivered. Accessibility was being considered — but not consistently documented, tested, or tracked.
I helped turn a broad standard into a working system: clear minimum requirements, role-based checklists teams could use in day-to-day work, a testing approach across channels, and a way to track and prioritise issues over time.
Why this work matters?
Accessibility isn't a design preference in banking. It sits inside a chain of obligations, and every channel is expected to meet them.
| Layer | What sits here |
|---|---|
| Obligations | Banking Code of Practice, Disability Discrimination Act 1992 |
| Risk areas | Financial, reputational, regulatory |
| Industry commitments | ABA Accessibility Principles, WCAG 2.2 |
| Internal standards | Customer accessibility standard, governance and control testing |
| Roles | Role-based accessibility checklists for all digital channels |
| Channels | Websites, apps, online applications, internet banking |
Challenge
Accessibility was being considered, but not consistently embedded, delivered or evidenced.
| Gap | Impact | |
|---|---|---|
| 1 | No shared checklist for design, dev and delivery | Requirements interpreted differently by each team |
| 2 | Testing coverage narrow and event-driven | Issues surfaced late, after builds |
| 3 | No tracking or reporting method | Hard to see scale, trends or priorities |
| 4 | Documentation scattered and dated | Teams unsure which source to trust |
Goal
To pass the control testing, make accessibility something teams can apply, evidence, and monitor — not something they interpret.
| Goal | What success looks like | |
|---|---|---|
| 1 | Define what "met" means | Minimum requirements with measurable thresholds, not principles |
| 2 | Make it usable per role | Every role knows their part without reading the whole standard |
| 3 | Widen and regularise testing | Coverage across channels, on a rhythm rather than after major builds |
| 4 | Make issues visible | Tracking, escalation and prioritisation that supports decisions |
| 5 | Embed, don't publish | Guidance sits inside existing process, training and ways of working |
Results
Established standards and documentation
| # | Artefact | Count | Detail |
|---|---|---|---|
| 1 | Digital Accessibility Standard | 1 | Minimum requirements with measurable thresholds |
| 2 | Role-based checklists | 10 | One per delivery role — UX, PO, content, engineering, BA, QA and others |
| 3 | Accessibility Hub | 1 | Single entry point for all accessibility content |
| 4 | Delivery process | 2 | Web and app — where accessibility sits in the existing flow |
| 5 | Defect management process | 2 | Web and app — raise, categorise, prioritise, close |
| 6 | Reporting process | 2 | Web and app — tracking, escalation, prioritisation |
| 7 | Monitoring process | 1 | All channels — regular coverage rather than post-build checks |
| 8 | Review process | 1 | All channels |
| 9 | Audit process | 1 | All channels |
Training and capability
| # | Measure | Before | After |
|---|---|---|---|
| 1 | Self-paced courses available | 0 | [x] |
| 2 | Expert-led sessions delivered (external facilitator) | 0 | [x] |
| 3 | People trained on the standard | [x] | [x] |
| 4 | Team coverage | [x]% | [x]% |
| 5 | Course completion rate | [x]% | [x]% |
| 6 | Champions embedded across teams | 0 | [x] across [x] roles |
| 7 | People influenced across delivery teams | [x] | [x] |
Delivery and process
| # | Measure | Before | After |
|---|---|---|---|
| 1 | Time from issue captured → raised | [x] | [x] |
| 2 | Time from issue raised → triaged | [x] days | [x] days |
| 3 | Time from triage → resolved | [x] days | [x] days |
| 4 | Issues resolved | [x] | [x] |
| 5 | Testing coverage across channels | [x]% | [x]% |
| 6 | Testing frequency | After major builds | [x] |
| 7 | Issues caught before build | [x]% | [x]% |
Approach
We approached it in four stages.
| Stage | Focus | Output |
|---|---|---|
| 1 | Analyse and plan | Current-state map, action plans, owners and timeline |
| 2 | Define the standard | Minimum requirements with measurable thresholds |
| 3 | Build role-based checklists | 8 checklists, one per delivery role |
| 4 | Define the process | Delivery, defect, review, audit, reporting, monitoring |
1. Analyse and plan
- Who was involved: design, engineering, delivery leads, content, customer advocacy, risk and governance.
- How we approached it:
Step What we did Analyse Read every existing accessibility document. Compared what it said against what teams actually did. Listed the gaps. Inform the team Shared the findings early with each group, before anything was agreed. No surprises later. Timeline Broke the work into stages with dates, so people could see what depended on what. Role allocation Gave every action a named owner. Area leads owned the role-specific work. Advocacy owned the standard. People commit to work they helped shape. Informing before deciding cost a few weeks and saved months of pushback.
2. Define the standard
- Who was involved: customer advocacy owned the standard. I worked with them on structure and wording. Engineering and design pressure-tested whether each requirement was testable.
- How we approached it: we took each principle and asked one question — how would someone prove they'd met this? If we couldn't answer, the requirement wasn't finished.
| From | To |
|---|---|
| Principles and intent | Minimum requirements with tolerance levels |
| Open to interpretation | Defined thresholds teams can test against |
| Not evidenceable | Written so completion is observable |
