Same principles, every format
Most accessibility problems are not caused by a lack of standards. They are caused by treating each format as a separate problem: the website team fixes the website, the comms team publishes PDFs, the learning team builds courses, and nobody owns the journey a real person takes through all of them.
This guide sets out how we think about that problem. It covers every major format an organisation publishes, the standards that apply to each, and the shared foundation that makes it possible to manage them as one program rather than a dozen disconnected fixes. It is written for the people who own those journeys: digital teams, learning and development teams, communications teams, procurement teams, accessibility leads, and the executives accountable for all of it.
1. One journey, not a collection of files
Consider a common scenario. A staff member who uses a screen reader is asked to complete mandatory training. They sign in through the intranet, open the learning management system, launch an Articulate Storyline course delivered as a SCORM package, watch an embedded video, download a PDF reference guide, and complete a timed assessment to finish.
That is one task. It crosses at least six technologies. If any single step fails, the person cannot complete the task, and it does not matter how accessible the other five steps are. The intranet, the LMS, the course, the video player, the captions, the PDF and the assessment form each have to work, and they have to work together.
The same pattern applies to a citizen applying for a rebate, a customer disputing a charge, or a student enrolling in a unit. Accessibility conformance is usually reported per website or per document. People experience it per journey.
The principle: a journey is only as accessible as its least accessible step. Audit and fix journeys, not just individual assets.
2. The end to end learning experience
Learning content is where the end to end problem shows up most sharply, because modern courses are assembled from so many parts. Our approach focuses on the complete learner experience rather than any single authoring tool or file format.
Whether content is delivered through Articulate Storyline or Rise, packaged as SCORM or xAPI, presented as HTML, video, animation, an interactive assessment or a downloadable document, the same accessibility principles and the same recognised standards apply across the entire experience, led by the W3C Web Content Accessibility Guidelines (WCAG) 2.2.
We help organisations make sure every component contributes to an accessible learning journey, regardless of the underlying technology. That means the course player supports keyboard and screen reader use, the media is captioned and described, the documents are tagged, the assessments allow extended time, and the LMS wrapped around all of it does not undo the work.
Authoring tools matter, and we work deeply in them. But a tool setting is never the goal. The goal is that a learner with a disability starts, completes and passes the course with the same independence as everyone else.
3. Websites, web applications and mobile apps
The web is where WCAG began, and it remains the reference point for everything else. The same success criteria that govern a marketing site also govern a complex enterprise application, they are just harder to meet once you add data tables, dynamic updates, modal dialogs and custom controls.
4. eLearning, assessments and learning platforms
Courses published from Articulate Storyline, Rise and similar tools are web content. The SCORM or xAPI wrapper changes how completion is tracked, not whether WCAG applies. Accessibility is decided by the design choices inside the course and by the platform that hosts it.
Tip: ask vendors for evidence of the published output meeting WCAG 2.2, not just a statement that the authoring tool "supports accessibility". The tool provides the capability. The course design determines the result.
Media is where accessibility most visibly becomes a production discipline rather than a technical checkbox. Captions, transcripts, audio description and alternative text are content. They need to be planned, written and quality checked like any other content.
6. Documents, InDesign and forms
Documents are still the backbone of government and enterprise publishing, and they are consistently the largest accessibility backlog we see. The standards are settled: WCAG 2.2 for content published online, plus PDF/UA (ISO 14289) as the technical standard for PDFs.
7. Digital accessibility maturity: making it stick
Fixing formats one by one treats symptoms. Accessibility maturity treats the cause: the governance, processes and skills that decide whether next year's content is born accessible or joins the backlog.
- Governance and policy: clear ownership, standards written into policy, and accessibility built into procurement so new systems arrive accessible. See consulting and strategy.
- Accessibility statements: an honest public statement of conformance and contact paths. Generate a starter with the Accessibility Statement Generator.
- Roadmaps: a prioritised, funded plan from current state to WCAG 2.2 AA, mapped against the Accessibility Continuum.
- Capability uplift: embedding skills, templates and checkpoints in the teams that produce content, scoped against the W3C Accessibility Maturity Model through organisational uplift.
- Training: role based accessibility training for authors, designers, developers and testers, so quality does not depend on one specialist.
- Continuous improvement: monitoring, retesting and user feedback loops that keep conformance from drifting after launch.
8. The common foundation: WCAG 2.2 and inclusive design
Everything above rests on one shared foundation. The W3C Web Accessibility Initiative (WAI) maintains WCAG, currently version 2.2, built on four principles: content must be perceivable, operable, understandable and robust. Supporting specifications extend those principles to specific technologies: ARIA for rich web applications, PDF/UA for documents, and EN 301 549 for procurement of ICT including native software and hardware. The W3C's WCAG2ICT guidance confirms that WCAG applies to documents and software beyond the browser.
Implementation differs by format. The principle does not. One example, text alternatives, looks like this across the journey:
- On a website: an
alt attribute on the image element.
- In a PDF: alternative text on a tagged Figure element.
- In a Storyline course: alt text set in the slide's accessibility properties.
- In a video: audio description of essential visual information.
- In an infographic: a structured text equivalent of the full content.
Five techniques, one principle: information cannot live in a single sense or a single format. The same mapping exists for keyboard operation, contrast, timing, error handling and every other WCAG requirement. That is why an organisation that understands the principles can apply them to any technology it adopts next, and why inclusive, user centred design pays off across every channel at once: design with the full range of human diversity in mind, involve people with disability in research and testing, and most format level fixes never need to happen.
Look up any requirement in plain English with the WCAG 2.2 Criteria Search or scan the whole standard in the WCAG 2.2 Quick Reference.
9. What an end to end engagement looks like
Because the foundation is shared, one partner can cover the whole journey instead of splitting it across a web vendor, a document vendor and a learning vendor who never compare notes. Every engagement runs through our five stage methodology: Scope, Audit, Remediate, Validate, Embed.
- Scope: map the journeys that matter and every format they touch.
- Audit: test websites, applications, courses, media and documents against WCAG 2.2 in one consistent assessment. See accessibility audits and compliance.
- Remediate: fix code, content, courses and documents by priority, from single templates to bulk document remediation.
- Validate: verify with automated checks, expert review and user testing with assistive technology users.
- Embed: templates, training and governance so the journey stays accessible, guided by consulting and strategy and organisational uplift.
Delivery is senior led and fully Australian based, with deep experience in government and enterprise environments.
10. The Australian context
For Australian organisations, the end to end view is not just good practice. It reflects how the obligations are written:
- Disability Discrimination Act 1992 (DDA): applies to digital goods and services broadly, including websites, apps and documents, not to any one format. The precedent goes back to Maguire v SOCOG in 2000, the first decided web accessibility case in the world.
- AHRC Guidelines (2025): the Australian Human Rights Commission's Guidelines on equal access to digital goods and services set WCAG 2.2 AA as the benchmark and explicitly cover apps, SaaS, kiosks and other technologies alongside websites.
- Commonwealth policy: the Digital Inclusion Standard under the Digital Experience Policy requires Commonwealth entities to meet the DDA and the latest version of WCAG (currently 2.2), with Level AA as the Style Manual baseline.
- Procurement: EN 301 549 appears in government procurement requirements and applies WCAG across software, documents and hardware, which is exactly the end to end scope described on this page.
Publishing to the Australian public?
If your organisation serves Australian users, every format on this page sits inside the same legal frame. Our guide to whether WCAG is legally required in Australia explains how the DDA, the AHRC guidelines and government policy fit together.
11. Common questions about end to end accessibility
What is end to end digital accessibility?
End to end digital accessibility means every component of a user journey works for people with disability, not just the parts that are easiest to test. A single journey might span a website, an application, a learning management system, an eLearning module, a video, a PDF and a form. Each format has its own techniques, but all of them are measured against the same recognised standard, the W3C Web Content Accessibility Guidelines (WCAG). An experience is only accessible if every link in that chain is accessible.
Does WCAG apply to eLearning courses built in Articulate Storyline or delivered as SCORM packages?
Yes. Storyline, Rise and other authoring tools publish courses as web content (HTML, JavaScript and media), so WCAG applies to the published output regardless of the tool or the SCORM or xAPI wrapper used to track it. The LMS that hosts the course must also be accessible, because learners cannot reach an accessible module through an inaccessible platform. Authoring tools provide accessibility features, but course design decisions such as focus order, alternative text, captions, timing and interaction patterns determine whether the published course actually meets WCAG 2.2.
Do PDFs, Word documents and PowerPoint files need to meet accessibility standards?
Yes. WCAG applies to documents published online, and PDFs have an additional technical standard, PDF/UA (ISO 14289). An accessible document needs tagged structure, real headings, meaningful alternative text, a logical reading order, sufficient colour contrast, correct language settings and labelled form fields. In Australia, the Disability Discrimination Act 1992 covers digital content including documents, and inaccessible PDFs are a frequent source of complaints. Start with the document accessibility guide.
What accessibility standards apply to mobile apps?
WCAG 2.2 is the benchmark for mobile apps as well as websites. The W3C publishes guidance on applying WCAG to software beyond the browser, and EN 301 549, the standard referenced in much government procurement, applies WCAG to native software directly. In practice this means supporting each platform's assistive technologies, including VoiceOver on iOS and TalkBack on Android, along with text resizing, sufficient contrast, visible focus and touch targets that meet minimum size requirements.
Should we fix one format at a time or look at the whole journey?
Audit the whole journey first, then remediate by priority. Fixing formats in isolation often leaves the journey broken: an accessible course behind an inaccessible login, or an accessible page linking to untagged PDFs. Mapping the journeys that matter most, testing every component in each journey against WCAG 2.2, and fixing the highest impact barriers first delivers usable outcomes sooner than perfecting one format while others remain closed.
Where should an organisation start with accessibility?
Start by understanding your current position. An accessibility audit establishes where your websites, applications, documents and learning content stand against WCAG 2.2, and the free maturity self assessment shows how embedded accessibility is in your governance, procurement and production processes. From there, a prioritised roadmap addresses the highest impact barriers first while capability uplift, templates and training stop new barriers being created.
The takeaway
Accessibility is not a property of a file. It is a property of an experience. Websites, applications, courses, media, documents and forms will keep changing, and new formats will keep arriving. The organisations that succeed are the ones that anchor on the principles, WCAG 2.2, inclusive design and user centred practice, and apply them to every technology they touch.
That is the work we do: one partner, one set of principles, every format, the whole journey.