Digital accessibility FAQs - answers by topic, role and access need

Common questions about digital accessibility, WCAG compliance, disability types, our services, accessibility maturity, and choosing a provider. Filter by role or access need for answers tailored to who you are.

All questions

About Digital Accessibility

Digital accessibility refers to the practice of designing and developing websites, applications, documents, and other digital content so that people with disabilities can use them effectively. This includes ensuring content is perceivable, operable, understandable, and robust for users who may have visual, auditory, motor, cognitive, or other disabilities.

Accessibility benefits everyone, not just people with permanent disabilities. It also helps people with temporary impairments, situational limitations (like using a device in bright sunlight), and older users.

Read our blog post Why Does Web Accessibility Matter? for a broader introduction to the topic.

WCAG stands for Web Content Accessibility Guidelines. These are internationally recognised guidelines developed by the World Wide Web Consortium (W3C) that explain how to make web content more accessible to people with disabilities.

WCAG is organised around four principles (Perceivable, Operable, Understandable, Robust) and has three conformance levels:

  • Level A: The minimum level of accessibility
  • Level AA: The standard most organisations aim for, and what most legislation requires
  • Level AAA: The highest level, which may not be achievable for all content

The current version is WCAG 2.2, which supersedes WCAG 2.1. WCAG 3.0 is in development. You can search and filter every WCAG 2.2 criterion using our WCAG Compliance Criteria Search tool.

Each version of WCAG builds on the previous one and is fully backwards compatible:

  • WCAG 2.0 (2008): The original 61 success criteria across four principles. Still the baseline referenced by many older policies.
  • WCAG 2.1 (2018): Added 17 new criteria (total 78), focused on mobile accessibility, low vision, and cognitive disabilities.
  • WCAG 2.2 (2023): Added 9 new criteria and removed 1 (4.1.1 Parsing, now obsolete), for 86 active criteria. New criteria address authentication, focus appearance, drag movements, and help mechanisms.

WCAG 2.2 Level AA is the current benchmark for Australian government, European (EN 301 549), and US (Section 508) compliance. Filter criteria by version, level, and disability group using our WCAG Criteria Search tool. For a fuller comparison, see our blog post Understanding Global Accessibility Standards.

Digital accessibility is important for several reasons:

  • Inclusion: 5.5 million Australians (21.4%) have a disability. Accessible digital content ensures they can participate fully in society.
  • Legal compliance: The Disability Discrimination Act 1992 and government digital policies require accessible digital services.
  • Better user experience: Accessibility improvements often benefit all users, not just those with disabilities.
  • Business benefits: Accessible websites reach more customers, have better SEO, and reduce the $14.8 billion in online spending at risk from inaccessibility.

See our blog post Boost Your Business with Web Accessibility for a breakdown of the commercial case.

Accessibility done right is a quality standard, not a compliance checkbox. When accessibility is designed in from the start, meeting standards is the natural outcome of building well. Treating it as a box to tick leads to remediation culture: fixing things after they break, which is expensive and never as effective as getting it right the first time.

Accessibility testing shines a light on shortcuts: standards that weren't followed, diverse user needs that weren't understood, and decisions that prioritised speed over inclusivity. Those gaps reveal quality debt, not just compliance failures.

Our Consulting and Strategy and Organisational Uplift services help organisations move from a compliance mindset to a quality-first approach. Read our blog post Accessibility Isn't a Button or an Add-On for a full exploration of this idea, and The Chocolate Cake Accessibility Analogy for an intuitive illustration of why baking it in beats adding it on.

The SPA Framework is a concept developed by ExceedAbility that positions accessibility as the essential third pillar of digital compliance alongside security and privacy. The framework argues that security and privacy protections are meaningless to a user who cannot access them in the first place.

For example, a privacy consent form that a screen reader cannot navigate, or a secure login that requires a mouse, effectively excludes people with disabilities from the protections those features are designed to provide.

The Accessibility Continuum is a structured improvement framework that guides organisations from inaccessible to fully conformant, grounded in WCAG 2.2. It provides a phased roadmap for accessibility maturity, helping organisations understand where they are today and what steps to take next.

For a broader view of how organisations develop and sustain accessibility capability over time, see our new section on Accessibility Strategy and Maturity below.

Understanding Disabilities

Digital accessibility addresses barriers for people across five main disability categories. We have detailed guides for each:

  • Visual disabilities: Blindness, low vision, colour blindness. Users rely on screen readers, magnifiers, and high contrast.
  • Auditory disabilities: Deafness, hard of hearing, auditory processing disorder. Users need captions, transcripts, and visual alternatives.
  • Cognitive and learning disabilities: Dyslexia, ADHD, autism, dementia. Users benefit from clear language, consistent layouts, and generous time limits.
  • Physical disabilities: Paralysis, tremors, arthritis, RSI. Users rely on keyboards, switches, eye-tracking, and voice control.
  • Speech disabilities: Stuttering, aphasia, dysarthria. Users need text-based alternatives to voice-only interfaces.

For a broader overview across all three major groups, see our blog post Understanding Digital Accessibility for Disabilities.

According to the Australian Bureau of Statistics Survey of Disability, Ageing and Carers (SDAC) 2022, 5.5 million Australians (21.4%) have a disability. This is an increase from 4.4 million (17.7%) in 2018.

Among older Australians (aged 65+), 52.3% have a disability. Disability types that commonly affect digital access include vision impairment, hearing loss, motor and mobility conditions, and cognitive or psychosocial disabilities.

For a full breakdown, see our Cost of Inaccessible Digital Experiences page and our article on how Paralympians inspire us to think differently about ability and achievement.

Yes, this is a real consideration. For example:

The solution is user-configurable preferences and multi-modal interfaces rather than a one-size-fits-all approach. Each of our disability guides includes a dedicated section on these tensions.

No. Accessibility improvements benefit everyone. This is sometimes called the "curb-cut effect": kerb ramps were designed for wheelchair users but are used by everyone with prams, trolleys, and bicycles. Digital examples include:

  • Captions help in noisy environments, for non-native speakers, and in quiet offices
  • Good contrast helps everyone in bright sunlight or on cheaper monitors
  • Keyboard navigation helps power users, people with temporary injuries, and TV remote users
  • Plain language helps people in a hurry, non-native speakers, and experts scanning for key info
  • Large touch targets help everyone on mobile, especially one-handed use

Read more in our blog post Why Does Web Accessibility Matter?

Legal and Compliance

Yes. The Disability Discrimination Act 1992 (DDA) makes it unlawful for organisations to discriminate against people with disabilities. This has been interpreted to include inaccessible websites and digital content.

The Australian Human Rights Commission references WCAG 2.2 Level AA as the benchmark. Additionally, Australian Government agencies must comply with the Digital Experience Policy, which required all new digital services to be accessible from 1 January 2025 and all existing services by 1 January 2026.

See our compliance deadlines page and our blog post Web Accessibility Legal Risks in Australia for more detail on your exposure.

Section 508 is a US law that requires federal agencies to make their electronic and information technology accessible. It applies to federal agencies and organisations receiving federal funding.

Section 508 was refreshed in 2017 to align with WCAG 2.0 Level AA. If your organisation does business with US federal agencies, you may need to demonstrate Section 508 compliance. Our Audit and Compliance service covers Section 508 assessments and VPAT/ACR documentation.

EN 301 549 is the European standard for accessibility requirements for ICT products and services. It covers websites, software, hardware, and documents.

EN 301 549 incorporates WCAG 2.2 Level AA requirements for web content and adds additional requirements for other types of ICT. It is particularly relevant for organisations doing business in the European Union or selling software to European public sector buyers.

Read more about how these global standards relate in our blog post Understanding Global Accessibility Standards.

A VPAT (Voluntary Product Accessibility Template) is a document that explains how a product conforms to accessibility standards, typically Section 508 or WCAG. VPATs are commonly requested during procurement processes.

The completed document is called an Accessibility Conformance Report (ACR). Our Audit and Compliance team can help you create accurate VPATs and ACRs for your products, based on rigorous manual and automated testing.

Yes. Exceed Ability Online Pty Ltd is a registered NSW iBuy supplier, enabling direct procurement without extended tender processes. Our supplier profile is available at buy.nsw.gov.au.

We currently support a number of NSW and Victorian government organisations. Learn more on our About Us page.

Under the Australian Government Digital Service Standard, all existing digital services were required to meet WCAG 2.2 Level AA from 1 January 2026, following the new-services deadline of 1 January 2025. Both deadlines have now passed. Compliance is required, not upcoming, and is reported through Digital Service Standard processes and investment oversight reviews.

Agencies still working through remediation are expected to publish a credible accessibility statement covering known issues and dated remediation plans. See our government accessibility consulting page for the current expectations and engagement structure.

No. Overlay widgets such as UserWay, accessiBe and AudioEye do not, on their own, satisfy the Disability Discrimination Act 1992 or the Australian Government Digital Service Standard. An overlay does not tag a PDF, fix reading order, supply meaningful alt text or correct semantic structure.

In 2025 the US Federal Trade Commission fined accessiBe one million dollars for marketing claims that an automated widget could deliver WCAG compliance. See why accessibility overlays will not make your website compliant.

Our Services

We offer a comprehensive range of accessibility and digital delivery services:

View all services and free tools on our Services and Tools page.

Document remediation pricing is based on the volume and complexity of documents in scope. Complexity is assessed across four categories:

  • Simple: Text-only pages, simple lists, minimal images, basic layouts (e.g. standard letters, memos)
  • Medium: Multi-column layouts, simple tables, multiple images, headers and footers (e.g. reports, brochures, fact sheets)
  • Rebrand: Combined remediation and rebranding to a new template (e.g. applying updated brand guidelines across existing documents)
  • Complex: Merged-cell tables, interactive forms, infographics, multi-layer layouts (e.g. annual reports, financial documents, technical manuals)

Pricing is confirmed after we review a sample of your documents. Contact us to discuss your document estate and receive a fixed-price proposal, or learn more about our document remediation service.

Yes. Our Project Management service provides experienced project managers who understand WCAG, assistive technology, and the nuances of accessibility delivery. We work across Agile, Waterfall, PRINCE2, Kanban, SAFe, and hybrid methodologies.

Our Product Management service embeds within your product teams to shape accessibility roadmaps, define WCAG-informed acceptance criteria, prioritise backlogs, and integrate accessibility into sprint ceremonies and design reviews.

Yes. Our Intranet, Microsoft 365 and SharePoint service covers accessible SharePoint Online site design, Microsoft 365 optimisation (Teams, Outlook, Power Platform), accessible page templates, document library governance, and content migration with accessibility remediation.

Internal platforms are often the most overlooked accessibility gap. Employees with disability need accessible intranets just as much as external customers need accessible websites.

Yes. Our Web Design, Production and Management service delivers accessible websites from wireframe to launch. We work with HTML/CSS/JavaScript, WordPress, React, Vue, Angular, headless CMS platforms, and e-commerce solutions.

Every component is built to WCAG 2.2 AA from day one, with semantic HTML, ARIA, keyboard navigation, and responsive design tested across devices and assistive technologies.

Yes. Interactive UI patterns like modal dialogs, popups, and onboarding product tours are among the most common sources of accessibility barriers: focus management, keyboard traps, screen reader announcements, and close behaviour all need careful implementation.

We provide guidance, pattern libraries, audits, and training on implementing these patterns accessibly. See our reference guides on accessible modals and dialog boxes and accessible product tours for implementation guidance.

Yes. Our Graphic Design service handles creative design for accessible infographics, brand identity, and marketing collateral. Our separate Desktop Publishing service handles professional layout and production of accessible publications, reports, and templates using InDesign, Word, and PowerPoint.

The duration depends on the size and complexity of your website or application, the number of unique templates and components, and the depth of testing required. A typical website audit can take from one to several weeks.

Our Audit and Compliance service combines automated scanning with thorough manual testing. For a deeper assessment we also offer user testing with people with disabilities, which uncovers real-world barriers that technical audits alone cannot surface. Contact us for a detailed timeline based on your specific needs.

Yes, document remediation is one of our core services. We remediate PDFs and other documents to meet WCAG and PDF/UA standards, including proper structure and tags, alternative text, correct reading order, accessible tables, and form remediation.

See the question above for document complexity categories and how remediation is scoped.

Yes, we offer all our services remotely. We are based in Sydney but work with clients across Australia and internationally. For training, we offer both in-person workshops and live online sessions with interactive exercises.

We offer flexible engagement models calibrated to the nature and scope of your work:

  • Fixed-scope packages: Defined deliverables, timelines and cost - suitable for straightforward audit, remediation or training requirements
  • Structured programmes: Multi-phase engagements covering assessment, remediation, training, validation and reporting over a defined timeline
  • Time and materials: Flexible resourcing for ongoing accessibility work or embedded delivery support
  • Retainer: Sustained delivery support with dedicated hours for organisations managing ongoing accessibility workloads

All resources are Australian-based and on-shore. Pricing is provided based on scope and delivery requirements. Contact us to discuss the best model for your organisation, or view our engagement packages.

ExceedAbility holds current professional indemnity and broadform public and products liability cover, with workers compensation maintained as required under NSW law. Cover is held through CGU Professional Risks (Insurance Australia Limited) via Aon Risk Services Australia Limited (AFSL 241141). Specific cover levels and the current certificate of currency are provided to procurement teams during scoping or on request.

See how we work for the full operations and procurement detail.

For new clients and new engagements, our standard terms are a 50% deposit on signing of the engagement and 50% on delivery. For continuing client relationships, 30-day terms from valid tax invoice apply, or as otherwise agreed in the engagement contract. Milestone billing is available for engagements over 8 weeks.

See how we work for the wider commercial framework.

For direct engagements under your procurement threshold, scope to kick-off is typically 2-4 weeks. Panel-procured engagements depend on the panel cycle and any security clearance requirements; we work backwards from the date that matters to you and plan the upstream tasks against it.

A 20-minute scoping call returns a written scope and effort estimate within 48 hours. Start a conversation or book a discovery call.

Accessibility Statistics and Impact

According to the Australian Communications and Media Authority (ACMA), 92% of Australian adults use mobile internet daily (2025 data), and 99% rely on the internet for day-to-day activities.

With a population of approximately 27.6 million (ABS, June 2025), this translates to roughly 20.2 million adults using the internet each day. Of those, an estimated 4.3 million have a disability or accessibility need.

Our Australian digital accessibility impact page shows how these daily users are affected when digital experiences are not accessible.

The WebAIM Million report (2026) found that 95.9% of the top one million website homepages had at least one detectable WCAG 2 failure, with an average of 56.1 errors per page.

The six most common failures: low-contrast text (83.9%), missing alt text (53.1%), missing form labels (51%), empty links (46.3%), empty buttons (30.6%), and missing document language (13.5%).

Our live accessibility gap counter visualises this in real time.

Australians spent $69 billion online in 2024 (Australia Post). With 21.4% of the population having a disability, an estimated $14.8 billion in annual online spending is at risk when digital experiences are not accessible.

69% of disabled consumers click away from inaccessible websites, and 86% would pay more at an accessible competitor (Click-Away Pound study, 2019).

See our full methodology and assumptions.

The ADII is an annual measure of digital inclusion. The 2025 ADII found that people with disability score 9.5 points below the national average, and 47% report inaccessible online content as a barrier (vs 21% of the general population).

Our accessibility statistics page provides additional context and sourced data.

Approximately 252,000 new websites are created every day worldwide (Siteefy / Netcraft, 2025). Based on WebAIM data, the vast majority launch with accessibility barriers already built in.

Our web accessibility gap counter visualises this in real time using a conservative 90% estimate.

We have compiled statistics across several resources:

All data sourced from ABS, ACMA, AIHW, ADII, WebAIM, and the Click-Away Pound study.

Tools and Assistive Technology

Accessibility tools fall into several categories:

  • Screen readers: JAWS, NVDA, VoiceOver: read screen content aloud for blind or low vision users
  • Magnification: ZoomText, Windows Magnifier: enlarge screen content
  • Voice control: Dragon NaturallySpeaking, Voice Access: hands-free computer operation
  • Automated testing: axe, WAVE, Lighthouse: scan websites for WCAG violations
  • Contrast checkers: Verify colour contrast ratios meet WCAG requirements

See our top 40 accessibility software tools for a comprehensive guide, or visit our blog post on helpful accessibility tools.

No. Automated testing tools can typically detect only 30-40% of WCAG issues. The remaining issues require manual testing, expert review, and testing with real users of assistive technologies.

Common issues tools miss: whether alt text is meaningful, whether reading order is logical, whether keyboard navigation is intuitive, and whether content is genuinely understandable.

Our accessibility tools guide explains what each tool can and cannot do.

We offer several free tools and resources:

All tools are available on our Tools and Resources page.

The WCAG Criteria Search tool lets you explore and filter all 87 WCAG 2.2 success criteria in one place. You can narrow results by:

  • Keyword search: search criterion numbers, titles, and descriptions
  • Conformance level: A, AA, or AAA
  • WCAG version: filter to criteria introduced in WCAG 2.0, 2.1, or 2.2
  • Year published: 2008, 2018, or 2023
  • Principle: Perceivable, Operable, Understandable, or Robust
  • Primary focus: e.g. Text Alternatives, Keyboard Access, Colour and Contrast
  • Disability group: e.g. blindness, low vision, motor, cognitive, deaf/HoH

Each result includes the criterion description, which disability groups it affects, and a Learn more link directly to the W3C Understanding document for that criterion.

An accessibility statement is a public declaration that communicates your organisation's commitment to digital accessibility. It typically describes:

  • The accessibility standards you follow (e.g. WCAG 2.2 Level AA)
  • Any known limitations or areas still being improved
  • How users can request assistance or report accessibility barriers
  • Contact details for accessibility feedback

Who legally requires one?

  • Australian Government: Agencies covered by the Digital Experience Policy are expected to publish an accessibility statement.
  • European Union: The European Accessibility Act and EN 301 549 mandate an accessibility statement for public sector websites and apps.
  • United States: Best practice for Section 508-covered organisations; increasingly expected by procurement teams.

Even where not legally required, a published statement builds trust with users and demonstrates good faith. Use our free Accessibility Statement Generator to create one in minutes.

The Accessibility Statement Generator is a free, no-sign-up tool that produces a professionally worded, standards-aligned accessibility statement in minutes. The process has four steps:

  1. Enter your organisation details: name, website URL, and accessibility contact information
  2. Select your standards: choose WCAG version (2.0, 2.1, or 2.2) and conformance level (A, AA, or AAA), with optional references to EN 301 549 or Section 508
  3. Describe known limitations: optionally note any areas where you are still working toward full conformance
  4. Generate and copy: receive a ready-to-publish statement you can copy, customise, and add to your website

The output is a starting point. You can edit it to match your organisation's specific language. If you need help accurately assessing your conformance level before publishing, our accessibility audit service can provide the evidence base.

The ExceedAbility Blog covers accessibility strategy, WCAG compliance, global standards, legal risk, inclusive design, disability awareness, and practical guidance for teams. Recent articles include:

All 11 articles are available on our Blog page, filterable by category.

All free tools, self-service resources, a provider comparison directory, and a curated guide to the top 40 accessibility software tools used by professionals are available on our Tools and Resources page.

The page is organised into sections:

  • ExceedAbility Free Tools: WCAG Criteria Search, Accessibility Statement Generator, Maturity Self-Assessment, Document Accessibility Guide
  • Frameworks and Concepts: the SPA Framework, Accessibility Continuum, and other structured improvement approaches
  • Market Intelligence: Digital Accessibility Providers Directory: compare 50+ providers across Australia
  • Top 40 Accessibility Software Tools: screen readers, automated testers, contrast checkers, voice control, and more

Accessibility overlays are third-party JavaScript widgets, sold by vendors such as UserWay, accessiBe and AudioEye, that add a floating toolbar to a website (text size, contrast, fonts) and claim to automatically detect and fix accessibility issues. They do not make a site WCAG-conformant.

Automated tooling catches only a fraction of WCAG criteria and cannot reliably repair semantic structure, meaningful alt text, keyboard operation or complex components. Many assistive-technology users actively prefer that overlays not be installed. See why accessibility overlays will not make your website compliant.

In January 2025 the US Federal Trade Commission filed a complaint against accessiBe and in April 2025 approved a final order requiring the company to pay one million dollars. The company had claimed its accessWidget product made a website compliant with 30% of WCAG requirements immediately and reached full compliance with the remaining 70% within 48 hours via automation. The FTC found these claims false, misleading or unsubstantiated.

The order bars accessiBe from representing that its automated product can make any website WCAG-compliant unless it has evidence to support the claim. The ruling is widely cited as the strongest regulatory statement to date that an overlay cannot, on its own, deliver compliance. Full coverage in why overlays will not make your website compliant.

Yes. Overlays from vendors such as UserWay and accessiBe are deployed on a range of Australian corporate and government websites, including across the New South Wales government sector. Their presence does not, by itself, satisfy the Disability Discrimination Act, the Digital Service Standard or state accessibility policies.

If your agency is relying on an overlay, the underlying accessibility position still needs to be audited and remediated. See audit and compliance and the Australian Government Accessibility Index.

For Designers and Developers

The resistance is consistent and well-documented. The most common reasons graphic designers, UI specialists, and service designers deprioritise accessibility fall into four categories:

  • Creative control: The belief that WCAG constraints will make designs look generic, removing colour choices, layout freedom, and typographic personality. In practice, contrast ratios apply to text-on-background combinations only and do not restrict the vast majority of visual design decisions.
  • Diffused responsibility: Alt text is "a content problem", focus indicators are "a developer problem", and accessibility documentation is "too technical for design". In reality, the designer has the best context for every one of these decisions.
  • Audience assumptions: The belief that "our users don't have disabilities",statistically false for any product with more than a few dozen users, given that 21.4% of Australians have a disability.
  • Process deferral: "We'll fix it in the next major version",which never arrives, because accessibility retrofits are expensive and design systems accumulate technical debt with every inaccessible component that ships.

Our training programs address designer barriers directly, with role-specific workshops that build practical confidence rather than theoretical awareness.

Developers skip CMS accessibility fields (alt text, heading levels, link labels, table captions) because in the moment, they do not feel blocking. The consequence is invisible to the developer: the page looks fine, the build passes, the tests are green. The barrier only becomes real to a screen reader user encountering it.

At the framework level, the most common assumptions are:

  • "The component library handles it": frameworks are accessibility-neutral; they output what you author, not what you intended.
  • "Automated testing said we passed": automated tools catch 30-40% of WCAG failures; the rest require human testing.
  • "ARIA will fix it": misapplied ARIA creates barriers; the first rule is to use native HTML elements before reaching for ARIA.
  • "SPAs are different": WCAG applies to all web content; single-page apps introduce specific failure patterns (focus management on route change, live region announcements) that native HTML pages do not have.

Our developer training programs cover all of these patterns with hands-on technical exercises in your actual tech stack.

Design decisions directly cause the following WCAG failures, which consistently appear in the WebAIM Million annual report:

  • Low-contrast text (83.9% of pages): Brand colour palettes chosen without checking 4.5:1 text contrast ratios (WCAG 1.4.3)
  • Missing focus indicators: outline: none applied globally in CSS to "clean up" the design (WCAG 2.4.7, 2.4.11)
  • Insufficient touch target size: Small buttons and links unusable for motor-impaired users (WCAG 2.5.5, 2.5.8)
  • Colour-only information: Using colour alone to distinguish interactive states (error, selected, disabled) (WCAG 1.4.1)
  • Missing alt text decisions: Handing off images without documenting whether they are decorative or informational (WCAG 1.1.1)

Use our WCAG Criteria Search to look up any of these criteria in detail, or contact us to discuss a designer-focused training program.

The WebAIM Million 2026 report identifies the six most prevalent WCAG failures on the web, all of them implementation failures:

  • Low-contrast text (83.9%): Contrast issues in CSS that survive from design through to production (WCAG 1.4.3)
  • Missing image alt text (53.1%): Empty or absent alt attributes (WCAG 1.1.1)
  • Missing form labels (51%): Form inputs without associated <label> elements (WCAG 3.3.2, 1.3.1)
  • Empty links (46.3%): Anchor tags with no text content and no aria-label (WCAG 2.4.4)
  • Empty buttons (30.6%): Icon-only buttons without accessible names (WCAG 4.1.2)
  • Missing document language (13.5%): No lang attribute on the <html> element (WCAG 3.1.1)

None of these require ARIA expertise. All are fixable with basic HTML. Use our WCAG Criteria Search to explore any of these criteria further.

The design-to-development handoff is one of the highest-risk points in the accessibility delivery chain. Accessibility decisions that should be made in design (alt text intent, heading hierarchy, reading order, focus management) often fall through the gap because:

  • Designers assume developers will apply sensible defaults
  • Developers assume designers have specified everything they need
  • Neither is true

The solution is shared ownership at the handoff: designers document accessibility decisions in the design file (using annotation tools like A11y Annotation Kit for Figma), and developers treat those annotations as acceptance criteria. Our training programs include a combined designer-developer accessibility workshop specifically designed to close this gap.

Yes. Our accessibility training is customised by role and includes dedicated programs for:

  • Graphic and UI designers: Colour and contrast, focus indicators, annotation in Figma, accessible typography, and handing off accessibility decisions
  • Front-end and full-stack developers: Semantic HTML, keyboard navigation patterns, ARIA applied correctly, screen reader testing, SPA accessibility, and CMS field discipline
  • Combined teams: Shared workshops that address the handoff gap and build a common language across design and development
  • Content teams and CMS authors: Alt text, heading discipline, link labelling, table accessibility, and accessible document authoring

Contact us to discuss a training program tailored to your team's tools, tech stack, and current capability level.

Use built-in heading styles (one H1, then H2 and H3 in order), add alt text via right-click then View Alt Text on every image, mark table header rows (Table Design then Header Row), set the document language under Review then Language, write descriptive link text, and run Review then Check Accessibility before publishing.

Save as PDF with the Document structure tags for accessibility option enabled. Our format-specific quick reference has the full step-by-step for Word, PowerPoint, InDesign, Excel and Google Docs.

PowerPoint: use built-in slide layouts (do not draw text in floating boxes), give every slide a unique title via the title placeholder, set reading order per slide through Home then Arrange then Selection Pane, add alt text on every image and chart, and run Review then Check Accessibility before export.

InDesign: map paragraph styles to PDF tags through Paragraph Styles then Export Tagging, use the Articles panel to define reading order across spreads, add alt text per object through Object Export Options, and expect to finish reading-order work in Adobe Acrobat Pro after export. Full detail in the document accessibility format quick reference.

Accessibility Strategy and Maturity

Accessibility maturity describes how embedded, systematic, and sustainable an organisation's approach to accessibility is. Organisations at low maturity treat accessibility reactively: they fix issues when complaints arrive, run one-off audits, and rely on individual champions. Organisations at high maturity design accessibility in from the start, maintain it through governance and procurement standards, build it into team capability, and measure it consistently.

Maturity matters because:

  • Reactive organisations spend far more per issue fixed than proactive ones
  • Accessibility debt compounds. Every inaccessible component makes the next remediation harder
  • Legal and regulatory exposure increases as accessibility obligations tighten across government and enterprise
  • High-maturity teams deliver accessible products faster, with fewer defects

Read our blog post From Reactive to Resilient: Building Accessibility Maturity in Your Organisation for a full exploration of the maturity spectrum and how to progress. You can also take our free 90-second maturity self-assessment to understand where your organisation sits today.

This phrase describes the journey most organisations need to make with accessibility:

  • Reactive: Accessibility is addressed when it breaks: a complaint, an audit finding, or a legal threat triggers action. Fixes are localised and temporary. The same issues recur in new content and features.
  • Aware: The organisation knows accessibility matters. Champions exist, occasional training happens, but it's not yet systematic.
  • Embedded: Accessibility is in the design system, development standards, and procurement requirements. Testing is regular. Teams understand their responsibilities.
  • Resilient: Accessibility is sustained regardless of team changes, vendor swaps, or technology updates. Governance, metrics, and feedback loops maintain conformance over time.

Our Organisational Uplift and Consulting and Strategy services are designed to guide organisations along this journey. Read more in our blog post From Reactive to Resilient.

The W3C Accessibility Maturity Model is a formal framework published by the W3C Web Accessibility Initiative (WAI) to help organisations evaluate and improve how they manage digital accessibility. It covers five dimensions: Planning, Processes, Roles, Tools, and Evaluation.

Each dimension is assessed across five maturity levels: from ad hoc (Level 1) through managed (Level 3) to optimised (Level 5). The model provides a structured basis for identifying capability gaps and planning improvements.

ExceedAbility's Organisational Uplift service is structured around the W3C Maturity Model. You can also take our free maturity self-assessment: a 90-second evaluation that gives you an indicative maturity level and priority recommendations across each dimension.

Retrofitting accessibility is significantly more expensive, slower, and less effective than building it in from the start. The comparison holds at every scale:

  • Design: Fixing a contrast issue in a design file takes seconds. Retrofitting it across a deployed design system touches every component that uses that colour token.
  • Development: Adding a <label> element during development is a one-minute change. Auditing and patching hundreds of forms after launch takes weeks.
  • Architecture: ARIA patterns for complex UI components (data tables, tree views, tab panels) require specific HTML structures. Retrofitting these after the component is live usually means a complete rewrite.

Accessibility testing after launch reveals quality gaps. It does not create them. Those gaps were created during design and development. The most efficient fix is to not create the barrier in the first place.

Read our blog post Accessibility Isn't a Button or an Add-On and The Chocolate Cake Accessibility Analogy for further reading on this principle.

Accessibility is an ongoing program, not a one-time fix. A one-off audit identifies issues at a point in time, but without embedding accessibility into design, development, and content processes, new barriers accumulate with every update, every new feature, and every vendor integration.

A sustainable accessibility program includes:

  • Governance: Clear ownership, accountability, and escalation paths across the organisation
  • Standards: Defined requirements in design systems, development standards, and procurement contracts
  • Capability: Trained teams who understand their accessibility responsibilities by role
  • Testing: Regular audits, automated scanning in CI/CD pipelines, and user testing with people with disabilities
  • Feedback loops: Published accessibility statements, user feedback mechanisms, and issue resolution processes

Our Organisational Uplift service builds this infrastructure. Our Consulting and Strategy service helps you define the roadmap. Contact us to discuss what a program looks like for your organisation.

A compelling accessibility business case typically draws on four pillars:

  • Legal risk: The DDA and Digital Experience Policy create real legal exposure. Documented inaccessibility has led to complaints, investigations, and settlements in Australia. See our blog post on Web Accessibility Legal Risks in Australia.
  • Commercial opportunity: $14.8 billion in annual Australian online spend is at risk from inaccessibility. Accessible experiences retain customers others lose.
  • Operational cost: Remediation costs 10-100x more than building accessibly from the start, depending on the complexity of the asset and how far into deployment it is when issues are discovered.
  • Reputational value: 86% of disabled consumers say they would pay more at a competitor with an accessible experience. Accessibility signals quality, inclusion, and trust.

Contact us for help building a business case tailored to your organisation's context, sector, and existing accessibility baseline.

Choosing an Accessibility Provider

Yes. ExceedAbility maintains a Digital Accessibility Providers in Australia directory listing over 50 providers. The directory lets you filter by:

  • Category: Consultancy, Software, Law, Training, Document Remediation, Testing, Design
  • Service type: Accessibility audits, training, document remediation, strategy and consulting, user testing, assistive technology, remediation services
  • Keyword search: find providers by name, description, or specialisation

ExceedAbility is listed as the recommended partner and appears first in all results. The directory is designed to help procurement teams, project managers, and heads of digital make informed comparisons before engaging a provider.

When evaluating an accessibility provider, look for:

  • WCAG expertise: Can they demonstrate deep knowledge across the full WCAG 2.2 criteria set, not just the six most common automated-test failures?
  • Manual testing capability: Automated tools find 30-40% of issues. Providers who rely only on automated scans are missing the majority of barriers.
  • Assistive technology testing: Do they test with real screen readers (JAWS, NVDA, VoiceOver), keyboard-only navigation, and other assistive technologies?
  • On-shore delivery: Australian-based resources understand the local regulatory environment (DDA, Digital Experience Policy) and can engage in-person with your team.
  • Breadth of services: Organisations with mature accessibility needs require more than audits,training, strategy, remediation, and governance capability are all needed at different stages.
  • Government supplier registration: For government procurement, iBuy and other panel registrations reduce time-to-contract.
  • Embedded capability: The best providers build your team's capability, not dependence. Ask whether they offer training and knowledge transfer alongside delivery.

Compare providers side-by-side using our Australian Accessibility Providers Directory.

Before signing with any provider, ask:

  • "What percentage of your testing is manual versus automated?" If the answer is mostly automated, you are not getting a real audit.
  • "Which assistive technologies do you test with, and on which OS and browser combinations?" JAWS on Windows, NVDA on Chrome, VoiceOver on iOS are the minimum bar.
  • "Can you show me a sample audit report?" A good report identifies issues by WCAG criterion, severity, component, and includes remediation guidance, not just a score.
  • "Do you include user testing with people with disabilities?" Expert review finds technical failures; user testing finds usability and real-world barriers that automated tools and checklists miss.
  • "What happens after the report?" Audit-only providers hand you a document and leave. Providers with remediation, training, and retainer services can stay with you through resolution.
  • "Are your resources on-shore?" For Australian government and regulated industries, on-shore delivery is often required or preferred.

ExceedAbility answers yes to all of the above. Contact us to discuss your specific requirements.

ExceedAbility is an end-to-end Australian accessibility partner with on-shore delivery across the full spectrum: audits, training, document remediation, strategy, user testing, project and product management, web development, design, and organisational uplift programs.

Key differentiators include:

  • Breadth: Most providers specialise in one or two service lines. We cover the full lifecycle from audit to governance.
  • On-shore: All resources are Australian-based with deep knowledge of the DDA, Digital Experience Policy, and Australian government procurement.
  • Government registered: NSW iBuy supplier (profile buy.nsw.gov.au) for streamlined procurement.
  • W3C Maturity Model: Our Organisational Uplift programs are built on the W3C's formal maturity model, not a proprietary framework.
  • Free tools: We provide free tools - WCAG Criteria Search, Statement Generator, Maturity Self-Assessment, Provider Directory - as public resources, not just client-facing products.

See how we compare to other Australian providers in our provider directory, or contact us for a direct conversation about your requirements.

Yes. ExceedAbility earns its income from your fees only. We do not resell, whitelabel or earn commission from overlay vendors (UserWay, accessiBe, AudioEye), AI-remediation products or any third-party accessibility tooling. This is deliberate: the value of an independent audit is destroyed the moment the auditor is paid by anyone except the buyer.

On request we provide a written conflict-of-interest declaration covering the specific agency or vendor relationships relevant to your engagement. See how we work for the full position.

Every engagement runs under a single named accessibility lead. For most engagements that is Simon Dakin, founder, holder of a Professional Certificate in Web Accessibility from the University of South Australia (School of Communication, International Studies and Languages), studied under Professor Clayton MacKenzie and Scott Hollier, in partnership with Media Access Australia, in 2016. The program continues today through Adelaide University following Media Access Australia's wind-down.

Beyond the formal accreditation, current expertise lives in a decade of continuous client delivery across two major WCAG releases (2.1 in 2018, 2.2 in 2023). See how we work for the full credential statement, or about the team for the wider bios.

Getting Started

We recommend starting with:

  1. Assessment: Understand your current state through an audit or our free maturity self-assessment
  2. Prioritisation: Focus on the most impactful issues and highest-traffic content first
  3. Training: Build capability in your team with customised training programs
  4. Remediation: Fix existing issues while implementing accessible practices for new work
  5. Maintenance: Establish governance and processes through organisational uplift to sustain accessibility over time

For a strategic view of this journey, read our blog post From Reactive to Resilient. Contact us for a free consultation.

Costs vary based on your needs, the size and complexity of your digital assets, and the level of support required. We provide customised quotes for all engagements.

For document remediation, per-page rates start at $45 (Simple) through to $60 (Complex), excluding GST,see the pricing question in the Our Services section above for a full breakdown.

Consider the costs of not being accessible: potential legal action under the DDA, lost customers (an estimated $14.8 billion at risk in Australia), damaged reputation, and the exclusion of 21.4% of the population.

Contact us for a free initial consultation and quote.

We have a range of free resources to help you build knowledge before engaging any provider:

When you are ready to talk, contact us for a free initial consultation.

You can reach us through several channels:

We are based in Sydney, Australia and work with clients across Australia and internationally. Learn more about our team on the About Us page.

ExceedAbility is a registered supplier on the four major Australian government procurement panels: buy.nsw (NSW), AusTender (Commonwealth), Buying for Victoria, and the Queensland Procurement Solution (VendorPanel).

We also engage through agency-specific panel arrangements and direct engagement under the threshold. See how we work for the engagement structure and full procurement detail.

Yes. ExceedAbility is based in Sydney, NSW, and all delivery resources are Australian. Project data is held on Australian-region cloud services for the duration of the engagement, with retention and deletion handled per the contract. We do not subcontract offshore without written agreement.

See how we work for security, data handling and the wider operational detail.

Find answers by role or access need

Same source, filtered by who you are. Pick a category to focus the questions below - or use the full Accessibility Navigator chooser for tailored guidance.

Showing all questions.

Plan and Manage For executives, directors, product and project managers

How do I get accessibility on the executive agenda?

Frame accessibility in the language executives already act on: legal exposure under the Disability Discrimination Act, government compliance obligations (DDA, DSP, WCAG 2.2 AA), customer reach (around 1 in 5 Australians have a disability), and operational risk. Pair the framing with a current-state audit and a costed remediation roadmap so the conversation is about a defensible plan, not abstract risk.

What is my organisation’s legal exposure from inaccessible digital services?

In Australia, inaccessible digital services may breach the Disability Discrimination Act 1992 and, for government, the Digital Service Standard. Exposure includes Australian Human Rights Commission complaints, reputational damage, and (for government) investment oversight findings. WCAG 2.2 Level AA is the benchmark referenced by the AHRC and most Australian Government policy.

How do I plan an accessibility budget?

A defensible accessibility budget covers four streams: audit and conformance documentation, remediation effort (developer time and content rework), capability uplift (training and governance), and ongoing validation. Start with an audit so the remediation cost is grounded in real findings rather than guesswork. Most organisations under-fund remediation effort relative to audit cost - plan for 3-5x audit effort in remediation.

I’m a project or product manager new to accessibility - where do I start?

Start by getting a current-state position: an audit against WCAG 2.2 AA. From there, build a prioritised backlog tied to the standard, allocate dedicated remediation capacity in your delivery cadence, add an accessibility acceptance criterion to your definition of done, and run validation testing before each release. Engage an accessibility lead early - accessibility decisions made late are expensive to reverse.

What KPIs measure accessibility programme success?

Useful KPIs include: WCAG 2.2 Level AA conformance percentage, number of open critical or high-severity findings, time-to-remediate by severity, percentage of releases with no accessibility regressions, training coverage by role, and W3C Accessibility Maturity Model band. Pair quantitative measures with qualitative user testing outcomes - a high conformance score does not always mean a usable product.

Design For UX, UI, interaction, service, content and visual designers

What accessibility do designers actually need to know?

Designers need to know enough WCAG 2.2 to make accessible decisions at design time: colour contrast (4.5:1 for normal text, 3:1 for large text and UI), 24×24 minimum target size, focus visibility, error identification, no information conveyed by colour alone, and text-spacing flexibility. Designers also own information architecture, heading hierarchy and content structure - accessibility for cognitive load.

How do I make a design system accessible?

Build accessibility into the design system by component: every component documents its keyboard model, focus appearance, ARIA pattern (where required), colour-contrast tokens, and tested behaviour with screen readers. Treat accessibility specs as first-class - alongside spacing and colour. A single accessible component scales across hundreds of screens; an inaccessible one creates hundreds of issues.

What’s the right colour contrast for WCAG 2.2 AA?

WCAG 2.2 Level AA requires a minimum contrast of 4.5:1 between text and its background for normal text, and 3:1 for large text (18pt+ or 14pt+ bold). Non-text UI components and graphics that convey information also require 3:1 contrast. Logos and decorative elements are exempt. Use a contrast checker against your final design tokens, not your wireframes.

How do I make data visualisations accessible?

Accessible data visualisations require: meaningful titles and summaries, a text alternative or data table behind every chart, colour and pattern (not colour alone) to differentiate series, sufficient contrast, keyboard-navigable interactive elements, and clear labelling of axes and legends. Screen reader users should be able to access the underlying data - the chart is decoration, the data is the message.

Develop For frontend, backend, full-stack, mobile and DevOps engineers

Where should developers start with WCAG 2.2?

Developers should start with the basics: semantic HTML (use the right elements before reaching for ARIA), keyboard accessibility (every interactive element must be reachable and operable by keyboard), visible focus, accessible names for controls, form labels and error messages, and heading structure. Most accessibility issues come from non-semantic markup, missing labels and broken keyboard support - fixing these resolves the majority of findings.

What’s the right way to use ARIA?

The first rule of ARIA is don’t use ARIA - use native HTML elements first. ARIA is for cases where HTML cannot express the pattern (custom widgets, dynamic content). When ARIA is required, follow the WAI-ARIA Authoring Practices, test with multiple screen readers, and ensure keyboard interaction matches expected patterns. Bad ARIA is worse than no ARIA - it can actively mislead assistive technology.

How do I test for accessibility in CI/CD?

Add automated accessibility testing to your CI pipeline using tools like axe-core, Pa11y or Lighthouse - they catch around 30-40% of WCAG issues. Combine with linting (eslint-plugin-jsx-a11y), component-level tests, and end-to-end keyboard tests. Automated testing is necessary but never sufficient - schedule manual expert review and assistive technology testing at meaningful release milestones.

How do I make a single-page app (SPA) accessible?

SPA accessibility requires explicit handling of: route changes (announce new content via live regions, manage focus to the new view), page titles (update on each route change), focus management (return focus after modals, manage tab order on new content), and loading states (announce to assistive technology). See the ExceedAbility SPA Framework for a documented pattern set covering React, Vue and Angular.

Content and Comms For copywriters, publishers, SEO and marketing

How do I write accessible content?

Accessible content uses plain language, descriptive headings, short paragraphs, descriptive link text (not “click here”), front-loaded key information, and meaningful alt text on informative images. Structure content with heading hierarchy (one H1, then H2/H3 in order) so assistive technology users can scan. Define jargon and acronyms on first use. Aim for a Year-9 reading level for general audiences.

What’s plain language and why does it matter?

Plain language is content written so the reader can find what they need, understand it the first time, and use it. It uses short sentences, common words, active voice and a clear structure. Plain language directly supports WCAG success criteria around readability and is critical for people with cognitive disabilities, learning differences, English as an additional language, and anyone reading under stress.

How do I write good alt text?

Good alt text describes the purpose of the image in context, not just what is in the image. If an image is decorative, use empty alt (alt=""). If it conveys information, describe that information concisely. If it is a link or button, describe the destination or action. Don’t start with “image of” - screen readers already announce that. For complex images like charts, provide a longer text alternative nearby.

How do I make a CMS or intranet accessible?

CMS and intranet accessibility depends on three layers: the platform itself (WordPress, Drupal, SharePoint - choose accessible themes and tested patterns), the authoring experience (so non-specialist content authors produce accessible content by default), and ongoing content quality (alt text, headings, link text, document accessibility). Configure the CMS to enforce structure where possible, and train content authors on the rest.

Test and Specialise For QA testers and accessibility specialists

How do I add accessibility to a QA test plan?

Add accessibility test cases at three levels: automated scans on every build (axe, Pa11y, Lighthouse), structured manual tests against WCAG 2.2 AA on key user journeys, and assistive technology spot-checks (screen reader, keyboard-only, zoom). Treat accessibility findings as defects with severity, not optional polish - block release on critical issues like missing labels or keyboard traps.

What automated tools should I use for accessibility testing?

Common tools include: axe DevTools (Deque) for in-browser checks, Pa11y and Lighthouse for CI integration, ARC Toolkit (TPGi) for deeper review, Color Contrast Analyser for design checks, and screen readers (NVDA, JAWS, VoiceOver) for manual testing. Our Top 40 tools page has a curated list with comparisons. No single tool covers more than 40% of issues - combine multiple sources.

How do I become an accessibility specialist?

Build expertise across three areas: the standards (WCAG 2.2, ARIA Authoring Practices, EN 301 549, PDF/UA), assistive technologies (real hands-on time with screen readers, magnifiers, keyboard-only, voice control), and disability lived experience (engage with disability communities and user research). Recognised credentials include CPACC, WAS and CPABE from IAAP. Specialisation grows from solving real-world remediation problems, not just from study.

Sensory Hearing and vision-related access needs

How can I make content accessible to blind and low-vision users?

For blind and low-vision users: use semantic HTML so content has structure for screen readers, provide meaningful alt text on informative images, ensure colour contrast meets WCAG 2.2 AA, do not convey information by colour alone, support text resize to 200% without loss of content, and provide accessible names for all interactive controls. Test with NVDA, JAWS and VoiceOver.

How do I make audio and video accessible to deaf and hard-of-hearing users?

Audio and video accessibility requires: synchronised captions for all pre-recorded audio with dialogue (WCAG 1.2.2), a transcript for audio-only content, and captions for live audio at WCAG AA. For sign-language users, consider Auslan interpretation for important content. Captions should include speaker identification, sound effects relevant to meaning, and music description where it carries content.

What’s the difference between captions and subtitles?

Subtitles are translations of dialogue for hearing audiences who don’t understand the original language. Captions are written for deaf and hard-of-hearing audiences and include all dialogue plus relevant non-speech audio (sound effects, speaker IDs, music). For accessibility compliance, captions - not subtitles - are required. Open captions are always visible; closed captions can be toggled.

Cognitive and Neurological Mental health, learning, ABI, intellectual and neurological needs

How do I make content accessible for people with cognitive disabilities?

Cognitive accessibility benefits from: plain language at a Year-9 reading level, clear and consistent navigation, predictable interactions, error prevention and recovery, generous time limits (or the ability to extend them), no auto-playing media, no distracting motion, the ability to pause animations, and the ability to save progress in long forms. Cognitive needs vary widely - design for flexibility, not a single profile.

How do I support users with dyslexia or learning differences?

Support users with dyslexia and learning differences by: using readable fonts (avoid all-caps and decorative typefaces), generous line height and paragraph spacing, left-aligned text (avoid full justification), short paragraphs, plain language, the ability to change colours and contrast, and giving users control over text spacing. Avoid relying solely on text - use icons and structured layout to support comprehension.

What about photosensitive seizures and animations?

Content must not flash more than three times per second (WCAG 2.3.1) - flashing content above this rate can trigger photosensitive seizures. For accessibility more broadly, respect the prefers-reduced-motion media query, avoid auto-playing animations, allow users to pause any animation longer than 5 seconds, and avoid parallax or large-area motion that can trigger vestibular disorders.

Physical and Motor Mobility, back, arthritis and dexterity-related needs

How do I make a site fully keyboard accessible?

Keyboard accessibility requires: every interactive element reachable by Tab and operable by Enter or Space, visible focus on every focused element (WCAG 2.4.7), logical tab order matching visual order, no keyboard traps (the user can always Tab away), keyboard equivalents for any mouse-only or drag interaction, and skip-to-content links on long pages. Test by unplugging your mouse and completing every key task.

How do I support voice control and switch users?

Voice control and switch users rely on accessible names matching the visible label so they can say or select “button name” and have it activate. Ensure every interactive control has a visible, accurate accessible name; use semantic HTML so controls are recognised; avoid generic labels like “click here”; and ensure target sizes meet WCAG 2.2 minimum (24×24) so switch and pointer alternatives can hit them reliably.

What is the WCAG 2.2 target size requirement?

WCAG 2.2 Success Criterion 2.5.8 (Target Size - Minimum) requires interactive targets to be at least 24×24 CSS pixels, unless the target is in a sentence (inline link), is essentially the same as the user agent’s default, or has equivalent functionality available with a larger target. The criterion benefits people with motor impairments, arthritis, tremor and anyone using a touch device.

Have more questions?

We're here to help. Contact us to discuss your accessibility needs.

Book a Discovery Call Contact Us