The Hidden Work Behind Accessible Digital Learning

Accessibility can look deceptively simple in policy documents. You apply WCAG guidelines, test the content, fix defects, and close tickets.

In a large publishing or edtech environment, it is rarely tidy. When you are working across hundreds of ebook titles, hundreds of thousands of pages, and a large assessment item bank, accessibility becomes a content production discipline.

That has been one of my biggest learnings from large-scale accessibility programs. The hardest challenge is moving every title, page, item, defect, fix, retest, and sign-off through a workflow without losing traceability or quality.

I saw this clearly while working on a large accessibility engagement for a major education publisher. The scope included hundreds of ebook titles, over 100,000 pages, and approximately 1.5 million assessment items to be audited within a six-month window.

At that volume, accessibility has to be built into how content is planned, tested, remediated, reviewed, and maintained.

A few lessons stayed with me.

1. Accessibility at Scale Needs an Operating Model

A small accessibility review can often be managed with a checklist, a few testers, and a simple defect tracker. Large-scale learning programs are different.

Every title needs to be accounted for. Every chapter, page, or item needs to move through a defined workflow. Every accessibility issue needs to be reported in a way that remediation teams can understand and act on. Every fix needs to come back for regression testing before it can be closed.

Without that operating model, the risk is a loss of control: unclear ownership and limited visibility into which titles or item sets are ready.

For publishers and edtech companies, accessibility is now part of production readiness. A title is not truly ready because the file renders correctly, the platform loads, or the assessment engine works. It is ready when learners can access, navigate, interact with, and complete the experience using the tools they rely on.

That means accessibility has to be treated as part of the content lifecycle, not as a separate compliance exercise after the content is “done.”

2. Workflow Design Matters as Much as Accessibility Expertise

One of the most important parts of this project was the workflow behind the audit.

Each title had to move through a clear journey: intake, page and assessment count extraction, work packet creation, tester assignment, accessibility audit, bug logging, remediation handoff, regression testing, sign-off, and certification.

That may sound like process detail, but in publishing and edtech, this is where large programs either stay on track or lose control.

Take a title with 1,000 pages. One tester cannot simply “own” that whole title if timelines are tight. The work has to be broken into smaller packets based on page count, item count, tester capacity, and delivery schedule. Those packets then need to be assigned, tracked, reviewed, and moved through the workflow.

In this project, the team used Jira, scripts, automation, and internal tools to break large titles into manageable work packets and assign them based on volume. That made progress visible. It also helped reduce handoff gaps, duplicate effort, and schedule ambiguity.

For content production leaders, accessibility work touches many teams. Product, content operations, platform, QA, editorial, remediation vendors, project managers, and sometimes legal or compliance teams all have a role to play.

If the workflow is weak, no one has a reliable view of what is complete and what can be signed off.

3. Accessibility Automation and Workflow Automation Solve Different Problems

One of my biggest takeaways was that accessibility automation and workflow automation are not the same thing.

Accessibility automation helps detect repeatable issues. Workflow automation helps move large volumes of work through assignment, review, remediation, and regression without losing control.

Both are important.

Some accessibility checkpoints can be verified using tools, scripts, and repeatable logic. In this project, around half of the accessibility checkpoints were automated, including checks related to image alt text availability, list structures, and code-level patterns.

That kind of automation saves time and improves consistency. A script does not get tired after the 400th page. A tool does not forget to check the same rule because the deadline is getting uncomfortable.

But automation only works when its limits are clearly understood.

A tool may detect whether alt text exists, but it cannot always determine whether the description explains the image’s instructional purpose. It may flag certain lists or code issues, but validating whether a learner using a screen reader can complete a multi-step activity without confusion? Nah.

This is an important distinction for publishers and edtech companies. A tool-only approach may find some accessibility issues, but it will not validate the full learning experience.

Digital learning content is not passive. A learner may need to read, navigate, answer questions, review feedback, retry, move through sections, or complete an activity using assistive technology.

4. Assessment Content Adds an Extra Level of Complexity to Accessibility

Ebooks and assessments both need accessibility review, but differ in the production challenges they pose.

An ebook page may involve structure, headings, navigation, tables, images, links, semantic markup, and reading order. That is already a big amount of work, especially across hundreds of titles.

Assessment content adds another layer.

A single item may include a question stem, answer options, images, equations, media, hints, feedback, scoring behavior, keyboard interaction, and platform-specific functionality. The learner is being asked to complete a task.

In this case, accessibility is more interaction-heavy.

For example, an assessment item may be technically readable by a screen reader, but the instructions may not make the expected action clear. An answer option may be keyboard reachable, but inefficient to use. An image may have alt text, but it fails to explain the concept the learner needs to solve the question. Feedback may appear visually but not be announced.

At the scale of a large item bank, small patterns become big problems. If the same accessibility defect appears in a reusable interaction type or item template, it can repeat across thousands of items.

That is why assessment accessibility needs more than page-level testing. It needs pattern recognition, consistent defect logging, remediation feedback loops, and enough regression capacity to confirm that fixes actually work.

5. Human Review in Accessibility Protects Judgment

For the checkpoints that could not be automated, testers performed manual reviews. Senior reviewers added another layer of quality control to catch missed issues or invalid defects. Native testers, including assistive technology users, helped validate content behavior across real use conditions, especially when the team encountered complex or unfamiliar content types.

That review model matters helped us understand if the experience works.

The review layer was not random spot-checking. Sampling was informed by tester performance and
bug-density patterns, which helped reviewers focus on areas where missed issues or invalid defects were more likely.

For a content leader, this matters because large-scale accessibility work can produce a high volume of findings. And not every finding is useful. Some may be incomplete, duplicated, inconsistent, or not actionable enough for remediation teams.

A strong review layer protects the integrity of the audit and prevents remediation teams from wasting time on unclear or invalid issues.

6. Consistent Bug Reporting Is Not a Small Operational Detail

When hundreds of bugs are being logged every day, inconsistency becomes expensive.

If one tester describes an issue one way and another tester describes it differently, remediation teams lose time.

This is especially true in edtech, where audit and remediation are handled by different teams or vendors. The person fixing the issue may not have been part of the original audit. They depend on the bug report to understand what went wrong, where it appears, how severe it is, and what needs to change.

In this particular project, the team used a bug logging tool with templates for common accessibility issues. That helped standardize summaries, language, and reporting formats.

If the same type of alt text issue appears across multiple chapters, it should be reported consistently. If a list structure issue appears repeatedly, remediation teams should not have to decode ten different descriptions of the same problem. If a keyboard interaction fails in an assessment, the report should clearly explain the expected behavior, actual behavior, and assistive technology context where relevant.

Inconsistent bug reports do not just irritate remediation teams. They increase cost, slow turnaround, and make it harder to see whether the same issue is recurring across titles, chapters, or item types.

In large accessibility programs, clarity becomes critical to production efficiency.

7. Audit Is Only One Part of the Accessibility Timeline

Accessibility timelines depend on the whole ecosystem.

Audit teams can move quickly, but the work does not end when issues are identified. Those issues need to be remediated. Fixed builds need to come back for regression testing. Failed fixes need to go back again. Sign-off depends on the full loop being completed.

That means timelines depend on audit teams, remediation teams, platform builds, vendor capacity, QA cycles, release schedules, and evidence requirements.

In this project, the ebook work moved faster. Assessment work had more dependencies because of the sheer volume of items, the density of issues, and the need for remediated builds to come back for testing.

That is a reality many publishing and edtech teams will recognize.

Accessibility schedules rarely slip because of one isolated task, but because content, platform, vendor, QA, and release dependencies are interconnected.

This is why accessibility planning cannot stop at the audit stage.

If a publisher plans only for testing but not remediation capacity, the schedule will break. If an edtech company plans remediation but not regression cycles, issues may return too late. If product teams do not plan for build availability, testers may be ready but unable to validate fixes.

The full timeline has to include audit, remediation, regression, sign-off, and evidence.

8. Independent Accessibility Validation Matters

In many publishing and edtech environments, audit and remediation are deliberately separated.

That separation can be frustrating from a scheduling point of view, but the logic is sound. The remediation team fixes the issue. An independent audit or QA team validates whether the fix actually resolves the accessibility barrier without creating a new content or platform issue.

For publishers, this is a trust mechanism.

Accessibility evidence often supports institutional requirements, procurement conversations, market access, and internal release confidence. If the same team that fixes the content is the only team validating it, some organizations may not feel they have enough independence in the process.

This is another reason workflow design matters. When multiple suppliers or internal teams are involved, the handoffs need to be precise. The issue needs to be clear. The fix needs to be traceable. The regression result needs to be documented. The sign-off needs to be defensible.

9. Scaling an Accessibility Team Requires More than Adding People

Treat large accessibility programs as you would an operations program.

At peak, this project involved around 350 people across two to three months. The team did not start there. It ramped up gradually from around 120 people, added people in batches, and later ramped down after a large portion of the work was delivered.

This type of staffing model creates its own complexity.

People go on leave. New team members join. Some people move out of the project. Workloads shift. Titles differ in size. Assessment items may have higher defect density than expected. Remediation builds may arrive later than planned.

If task assignment is handled manually in that environment, project managers spend too much time reassigning work rather than managing delivery and quality.

That is why automation for work packet assignment, reassignment, daily task allocation, and productivity tracking became important. It helped the team absorb changes without losing control of the workflow.

For publishers and edtech companies, the lesson is simple: headcount alone does not solve scale. Scale requires people, process, tooling, and governance to move together.

The Biggest Lesson

The biggest lesson I took from this project is that accessibility maturity is tested at scale.

When hundreds of titles are moving at once, remediation depends on multiple teams, and release timelines do not politely pause for quality issues, compliance is at stake.

For publishers and edtech companies, don’t schedule accessibility for the end of the production cycle! It has to be built into how content is planned, created, tested, remediated, released, and maintained.

The right workflows, automation layers, review models, assistive technology expertise, and reporting structures make it possible to move quickly without letting consistency fall apart.

At Magic EdTech, this is the lens we bring to our digital accessibility work. We help publishers, edtech companies, higher education institutions, and workforce teams build accessibility operations that scale across platforms, content types, and large volumes of learning material.

Whether the need is an audit, remediation support, workflow design, or ongoing accessibility governance, the goal stays the same: make accessibility easier to execute, easier to maintain, and more reliable at scale.