top of page

Beyond compliance: making Digital Accessibility real (and auditable)

Updated: Oct 14



Is it enough for your website to claim "we meet WCAG" or are you truly building for everyone?


As global digital access expands and regulations tighten, the education and software sectors can no longer treat web accessibility as a check-box obligation. In fact, with the latest WCAG 2.2 guidelines, launched by the W3C in October 2023, digital accessibility is not just a matter of legal compliance or reputation management. For EdTechs and digital product teams, it’s central to usable, inclusive design and future-proof digital growth.


What does it actually take to meet (and prove) accessibility? And what does a meaningful website or app audit really involve in 2024?


Understanding the Accessibility imperative


Consider these realities:

  • 1 in 6 people globally live with some form of disability. The web is their school, public square, marketplace, and social forum.


  • Many universities and public EdTech platforms face legal action due to inaccessible content, as seen in numerous widely-publicized lawsuits.


  • Forward-thinking organizations (including many leading EdTechs and universities) have begun seeing accessibility not as a burden, but as an innovation driver. Accessible products have broader reach, better SEO, and significantly reduced reputational risk.


As WCAG 2.2 now forms the basis for most European and American accessibility standards, understanding their requirements and then actively auditing against them is as much a digital literacy as learning UX design or robust QA.


The new landscape - WCAG 2.2 and what has changed


Released on October 5, 2023, WCAG 2.2 brings new success criteria aiming to address gaps (particularly around mobile usability and cognitive disabilities) from earlier versions. It defines three levels of conformance:


  • A: Basic web accessibility features required for minimal access


  • AA: Addresses most significant and common barriers for users

  • AAA: Highest tier, covering more nuanced scenarios, not always achievable for all content


What’s new in WCAG 2.2?


  • Focus appearance standards for keyboard navigation and visible focus indicators

  • Increased requirements for accessible authentication (minimizing cognitive load and avoiding timeouts)

  • Enhanced touch target sizing for mobile usability

  • Updates to requirements around draggable content, error prevention, and more

In Europe, WCAG 2.1 AA is currently legally mandated under the European Accessibility Act for many businesses (with 2.2 rapidly becoming the new standard). In the US and Canada, accessibility broadly hinges on WCAG, and lawsuits commonly cite these guidelines.


For EdTech platforms, learning management systems, online libraries, admissions and recruitment webpages, this isn’t just best practice. It’s a must.


Core insights and strategies


1. Accessibility is a Process, Not a Project


True accessibility is not "done" when your product launches or a VP checks the "meets WCAG" box. It’s a continuous process requiring design-to-development commitment and recurring audit.

  • It starts at UX research: conducting persona studies and task analysis with users with disabilities.

  • Accessible design systems (with color contrast, type, and interaction patterns) make implementation repeatable.

  • Accessible code shouldn’t (and can’t) be bolted on at the end; it needs to be coded, tested, and reviewed at every stage.


2. Make Accessibility visible (for teams and auditors)


How do you prove digital accessibility? Documentation. For every release, meaningful issues, code documentation, and audit logs should show that accessibility isn’t "nice-to-have"; it’s considered in every bug fix, feature, and content update.


  • Create an accessibility statement: a clear, public document of scope and ongoing efforts.

  • Maintain audit logs: what was checked, which users participated, dates, and methods.

  • Build accessibility into your CI/CD pipeline—automated tests and manual QA sign-offs are key evidence.

3. Know (and use) the tools


Automated Scanners: Tools like Axe, Lighthouse, and WAVE can catch 30–50% of accessibility barriers: e.g., missing alt text, insufficient color contrast, missing headings, keyboard-trap issues, and ARIA misuse. They also offer repeatable metrics for audits.


Manual/Expert Review: Automated audits don’t catch everything. Manual testing, especially navigational scenarios, focus management, or ARIA labeling, is vital. This means:

  • Keyboard-only navigation

  • Screen reader compatibility (NVDA, JAWS, VoiceOver)

  • Assistive tech on mobile

  • Testing timed actions, error messages, and dynamic/interrupted workflows


User Testing: Involve real users—students, applicants, or staff with disabilities. Feedback surfaces subtle/invisible obstacles: confusing error messages, drag-and-drop difficulties, or even overloaded dashboards.



4. Accessibility in Education: Unique Challenges


Unlike ecommerce or news sites, EdTech and university sites often involve:

  • Complex forms and application flows

  • Embedded PDFs, multimedia, and SCORM content

  • Diverse user audiences (students, faculty, parents) with different assistive tech and task requirements


This means you must test more broadly, e.g., simulate assignment upload/download with a screen reader, caption all video content, and check both auto-saving and error validation for forms.


5. Make it a habit - Training and Culture


Accessibility is a shared team discipline, not just the responsibility of the developers. Ongoing training (e.g., for QA testers, designers, and content creators) helps catch potential gaps sooner. Simple checklists, lunch-and-learns, and sharing audit results across teams help foster cultural buy-in.


So What?


If you lead a software, UX, or content team in EdTech/digital education, ask today:

  • Would a student relying only on keyboard or mobile assistive tech be able to complete your core scenarios without confusion or error?

  • Do you have documented evidence, statements, audits, and issue logs showing you meet WCAG 2.2 requirements?

  • Is accessibility testing part of your regular release QA or just a last-minute rush?


Digital accessibility is a non-negotiable: for legal risk, for future contracts with schools and governments (often now requiring proof of compliance), and above all, for true user equity. In a world where learning, collaboration, and work are digital-first, accessibility literally enables participation in modern life.


The Future of Accessible Digital Products


Meeting WCAG 2.2 is not the endgame. It’s the baseline. As AI, AR/VR, and new immersive tech enter education, the need for accessible, adaptable digital experiences will only grow. Teams that embed accessibility at every level of design, code, audit, and culture will build not just good products, but fair and lasting ones.


What accessibility challenge are you tackling next? Join the discussion or audit your own product today.

bottom of page