Direct answers to the questions organisations actually ask us about digital accessibility: what the Web Content Accessibility Guidelines require, what Australian law obliges you to do, how auditing and testing work, and what design, development, content and document teams each need to get right.
129 answers across 15 topics. Every answer stands on its own, so you can link straight to the one you need.
Browse by role or access need
Narrow this page to the questions that match your role, or the access needs you are designing for. The answers are the same, only the selection changes.
Showing all 129 questions.
Getting started with digital accessibility
What digital accessibility is, why it matters commercially and legally, and the first moves that give an organisation a defensible position.
What is 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.
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 $20 (Simple) through to $60 (Complex), excluding GST. See how document remediation is priced for the full breakdown of complexity tiers.
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.
Is accessibility a compliance checkbox or something more?
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.
Does fixing accessibility only help people with disabilities?
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
Provider Directory: compare 50+ providers across Australia before reaching out to any
When you are ready to talk, contact us for a free initial consultation.
I am 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.
The Web Content Accessibility Guidelines and the other standards Australian and international organisations are measured against, including Section 508, EN 301 549 and conformance reporting.
What is WCAG?
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.
What are the differences between WCAG 2.0, 2.1, and 2.2?
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.
What is a VPAT?
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.
What is Section 508?
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.
What is EN 301 549?
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.
United Kingdom and Europe:EN 301 549 and the public sector accessibility regulations.
New Zealand: the New Zealand Government Web Accessibility Standard.
A single audit can be mapped to several standards at once where a product serves multiple markets. For how these frameworks relate, see Understanding Global Accessibility Standards.
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.
Where accessibility obligations come from in Australia, what the Disability Discrimination Act 1992 and Australian Government policy require, and what evidence buyers and regulators expect.
Is digital accessibility required by law in Australia?
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.
What does the 1 January 2026 compliance deadline passing mean for my agency?
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.
We supply software to government. What accessibility evidence will we be asked for?
Expect three things. A statement of conformance to WCAG 2.2 Level AA, usually as a VPAT or Accessibility Conformance Report completed against the version of the standard named in the tender. Evidence behind that statement, meaning a current independent audit rather than a self-assessment or an automated scan report. And a remediation plan with dates for anything that does not yet conform, because partial conformance disclosed honestly is treated far better than a claim that does not survive testing.
What is an accessibility statement and does my organisation need one?
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.
Do accessibility overlays satisfy the Disability Discrimination Act or Digital Service Standard?
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.
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 accessibility is assessed: what automated tools find, what only a person can judge, and what an audit involves.
How long does an accessibility audit take?
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.
Which screen reader should we test with?
More than one, because they do not behave the same way. As a practical minimum, test with NVDA on Windows and VoiceOver on macOS and iOS, since between them they cover the largest share of desktop and mobile use. Add JAWS where your audience is corporate or government, because it remains dominant in workplaces, and TalkBack if Android matters to your product.
The differences are not cosmetic. Live region announcements, table navigation, custom component support and form mode behaviour all vary between them, so a component that works in one can be silent in another. Our screen readers compared guide sets out the behavioural differences, and assistive technology user testing puts the product in front of people who use these tools daily rather than an auditor imitating them.
Do accessibility tools alone make a website accessible?
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.
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 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.
If you need a rated, evidence based picture of where your service stands, that is what an audit produces.
Questions leadership teams ask: accountability, budget, maturity, and how accessibility survives past a single remediation project.
How does a board know how accessible our digital services are today?
Most organisations cannot answer this with confidence. The way to know is an independent audit of your highest priority services against WCAG 2.2, which gives a rated, evidence based picture rather than an assumption. If there is no current audit, that is the first gap to close.
Accessibility drifts when it belongs to everyone and no one. Name an owner, give them authority, and write it into a position description and governance, with regular reporting to leadership so it stays honest. We help organisations set up that ownership through organisational uplift.
What is accessibility maturity and why does it matter?
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
Why is accessibility better built in than retrofitted after launch?
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.
Is accessibility a one off fix or an ongoing program?
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
How do I build a business case for an accessibility program?
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.
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.
What accessibility evidence should we be able to produce for buyers or regulators?
You should be able to hand over a current independent audit and a VPAT or Accessibility Conformance Report for your key services. Without them you are exposed in procurement and under the Disability Discrimination Act. Maintained, independent evidence is the protection.
Should accessibility be a condition in procurement and supplier contracts?
Yes. Buyers increasingly require it, and your own suppliers can introduce the very risk you are trying to avoid. Add accessibility clauses and conformance requirements to procurement and supplier contracts. We can review your procurement language and supplier obligations.
How should we prioritise accessibility investment?
Prioritise by risk and reach. Fix the fastest, highest value items first, then sequence the rest with effort estimates. An audit becomes a roadmap so budget goes where it reduces the most risk. If you are not sure where you stand, a short discovery call will clarify it.
What is the Security, Privacy and Accessibility (SPA) Framework?
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.
What is the Accessibility Continuum?
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.
What does "from reactive to resilient" mean in accessibility terms?
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.
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.
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.
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.
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.
Moving from one off fixes to an embedded practice is the work we deliver as organisational uplift.
What designers need to know, the failures that recur in design files, and how to build accessibility into a design system rather than fixing it later.
What are the most common WCAG failures caused by designers?
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.
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.
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.
Why do designers resist accessibility even when they know it matters?
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.
How does the design to development handoff affect accessibility?
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.
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.
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.
Semantic HTML, ARIA, keyboard operation and the patterns that keep a codebase accessible through refactors.
What are the most common WCAG failures caused by developers?
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.
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.
Why do developers skip accessibility even when their CMS or framework prompts them?
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.
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.
Plain language, alternative text, heading structure and publishing practices for content, communications and marketing teams.
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.
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.
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 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.
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.
What if tagging a document is not enough for our audience?
Then you need an alternative format. A correctly tagged PDF or Word file serves screen reader users well, but it does nothing for someone who needs plain language and images to follow a process, someone who reads Braille, or someone who cannot read the screen at all. Alternative formats cover Easy Read, large print, audio and Braille, and they are a separate discipline from tagging rather than a harder version of it.
Easy Read in particular is not a simplified rewrite. It is a structured format pairing short, plain sentences with supporting images, and it is frequently the right answer for public information, health and disability services content. If you are unsure which formats your audience needs, we work that out as part of consulting and strategy, and produce them through document remediation.
Do you have free tools to check my own PDF, Word or PowerPoint files?
Yes. We provide free, instant accessibility checkers for the three document types organisations struggle with most:
Each one gives you a score, a clear overview of the issues that matter, and practical pointers on what to do next. No account is needed.
How do I make a Microsoft Word document accessible?
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.
Can you help with PDF accessibility?
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.
How does the free document accessibility checker work?
Upload your file and it is checked automatically against WCAG-based document accessibility rules. Within seconds you get a score, an overview of the issues that matter most, and pointers on how to address them.
Automated checks reliably catch only around 30 to 40 per cent of accessibility issues, so the checker is an excellent first step and triage tool, not a replacement for a full manual audit and assistive-technology testing. For step-by-step fixes, see our guides for Word, PowerPoint and Acrobat (PDF).
Is my uploaded file kept or shared?
No. Your file is deleted after checking and is never shared. The checkers need no account, run over a secure SSL connection, sit behind Cloudflare, and are operated by an Australian-owned business under the Australian Privacy Principles.
How do I make a PowerPoint or InDesign export accessible?
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.
For a document backlog, remediation is priced per page once we have reviewed a sample.
Who accessibility serves and what each group needs, including sensory, cognitive, neurological, physical and motor access needs.
What types of disabilities does digital accessibility address?
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.
How can I make content accessible to blind users and users with low vision?
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 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 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 many Australians have a disability?
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.
Captions that help deaf users can be distracting for users with attention disorders
Large, spread-out touch targets that help motor-impaired users increase scrolling for everyone
Voice control (for physical disabilities) is the exact modality that speech-disabled users cannot use
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.
How do I make audio and video accessible to deaf users and users with hearing loss?
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.
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.
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.
How WCAG applies to AI assistants and chat interfaces, why streaming responses fail for screen reader users, what AI can and cannot remediate, and what to require when buying AI products.
Are AI chatbots, copilots and assistants covered by WCAG?
Yes. WCAG applies to the interface, not to the technology behind it. A chat widget embedded in your site is part of your site, and every criterion that applies to a form, a dialog or a dynamically updating region applies to it.
In practice that means streaming responses engage 4.1.3 Status Messages, keyboard operation engages 2.1.1 Keyboard and 2.1.2 No Keyboard Trap, focus behaviour engages 2.4.3 Focus Order, 2.4.7 Focus Visible and WCAG 2.2's 2.4.11 Focus Not Obscured, and unlabelled prompt fields and icon-only controls engage 4.1.2 Name, Role, Value and 3.3.2 Labels or Instructions. We set out the full picture in It Answered. You Just Couldn't Hear It: The Accessibility of AI Tools.
Why do screen reader users hear nothing when an AI response streams in?
Because progressively rendered text is a status change, and status changes are only announced if the interface declares them. Without a correctly configured ARIA live region the content simply appears in the DOM with no notification, so the user hears silence, assumes the system has failed, and often sends the question again.
The opposite failure is just as common. An unbuffered live region announces every token, producing fragmented, stuttering speech that users switch off. The fix is to announce the state rather than the stream: progress when generation starts, content buffered to sentence or paragraph boundaries, and an explicit announcement when the answer is complete.
Who is responsible when a third party AI widget fails accessibility?
The organisation publishing the page. A conforming website with an inaccessible assistant bolted onto it is an inaccessible website, and a complaint under the Disability Discrimination Act is made against the service provider, not the software vendor.
Treat the assistant as a component under audit rather than a vendor feature. Put accessibility requirements in the evaluation criteria before you buy, ask for a VPAT or Accessibility Conformance Report, and verify it rather than file it. If the vendor cannot produce evidence, that is itself the answer.
Do AI answer engines and browsing agents depend on accessibility?
Yes, and this is the part that tends to unlock budget. Answer engines extract and cite text, so heading hierarchy, plain language, defined terms and structured data decide whether your page can be quoted. Browsing and computer use agents operate on the DOM and the accessibility tree, the same machine readable representation a screen reader consumes.
That means the failures that stop a screen reader user stop an agent, one for one: unlabelled controls, form fields whose labels are only visually adjacent, custom components with no roles or states. If an agent cannot complete your checkout, that is a customer who bought elsewhere. The full argument is in What Else Can't See?.
What should we put in an AI procurement requirement for accessibility?
Ask for the same evidence you would ask of any other component, plus the things unique to a generative interface:
Conformance evidence: WCAG 2.2 Level AA, stated in a VPAT or ACR, backed by an independent audit rather than a scan report.
Announcement behaviour: how streaming output is buffered and announced, and how completion is signalled to assistive technology.
Keyboard and focus: focus moves into the widget on open, returns on close, Escape works, and every control is reachable and labelled.
Generated output: how model output is sanitised into real headings, lists and tables, and how alternative text is handled for generated images.
Output standards: consistent structure, plain language and predictable length, written into the system prompt and tested like any other requirement.
If you are drafting this into a tender or a supplier obligation, talk to us and we will review the wording.
Our AI assistant passed an automated accessibility scan. Is that enough?
No. Automated tools evaluate a static snapshot and cover roughly a third of WCAG criteria. The failures specific to AI interfaces live in the transitions a scanner never reaches: whether focus moves into the widget when it opens, whether the response is announced while it streams, whether Escape returns focus to the launcher, whether an error after a timeout is conveyed to assistive technology at all.
An AI chat panel can pass every automated check on your dashboard and remain completely unusable with a screen reader. Testing has to walk the states, not the page: closed, opening, empty, typing, streaming, complete, stopped, errored, retried. See manual versus automated testing for what each method actually finds.
Can AI write our alternative text or remediate our documents?
It can draft, and a human still has to decide. A model can detect that an alt attribute is missing and produce a plausible sentence, but it cannot reliably know what an image means in the context of your page. Auto-generated descriptions of charts, infographics and editorial photography are routinely vague, wrong or actively misleading, and a confident wrong description is worse than none.
The same limit applies to documents. AI tooling accelerates the mechanical parts of remediation and produces useful first passes, but reading order, table structure, meaningful alt text and the judgement about what a reader actually needs remain human work. We set out where the line falls in Anyone Can Buy an Ice Chisel, and we are independent of every AI remediation vendor.
Are AI coding assistants and developer tools accessible?
Frequently not. The chat panels, diff viewers and streaming status indicators inside modern developer tooling are often unusable with a screen reader or a magnifier, and they lean heavily on colour alone to convey meaning in diffs, which excludes developers with colour vision deficiency.
It matters more than it first appears. If the tools used to build software are inaccessible, disabled developers are pushed out of the profession, and the number of people in the room who would have noticed the problems in your product goes down. If you are choosing tooling for a team, include it in the evaluation.
How do I make an AI chat or streaming response accessible?
Treat progressive output as a status change, not as content that speaks for itself. Announce “generating response” when it starts, buffer the output to sentence or paragraph boundaries rather than firing a live region on every token, and announce explicitly when the answer is complete. Use aria-live="polite" with role="status" for progress and role="log" for the running conversation, never assertive for content. Then handle the widget itself: move focus in on open, return it on close, make Escape work, label the prompt field and every icon-only control, and sanitise generated markdown into real headings, lists and tables. Full detail in the accessibility of AI tools.
Australian and global data on disability, digital inclusion, conformance rates and the revenue at stake when digital services exclude people.
What percentage of websites fail accessibility standards?
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%).
How much revenue do Australian businesses lose due to inaccessible websites?
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).
All data sourced from ABS, ACMA, AIHW, ADII, WebAIM, and the Click-Away Pound study.
How many Australians use the internet every day?
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.
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).
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.
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.
What are the most common types of accessibility software tools?
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
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.
How does the Accessibility Statement Generator work?
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:
Enter your organisation details: name, website URL, and accessibility contact information
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
Describe known limitations: optionally note any areas where you are still working toward full conformance
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.
Where can I find accessibility articles and insights from ExceedAbility?
The ExceedAbility Blog covers accessibility strategy, WCAG compliance, global standards, legal risk, inclusive design, disability awareness, and practical guidance for teams. Recent articles include:
Every article is on our Blog page, filterable by category, and the full library of free material sits on the Resources page.
Where can I find all of ExceedAbility's tools and resources in one place?
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.
Top 40 Accessibility Software Tools: screen readers, automated testers, contrast checkers, voice control, and more
Why did the US Federal Trade Commission fine accessiBe in 2025?
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.
Are accessibility overlays used on Australian government websites?
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.
Accessibility Nutrition Labels are a section on an app's App Store product page that tells people which accessibility features the app supports - VoiceOver, Voice Control, Larger Text, Captions, Audio Descriptions and more - before they download it. Apple introduced them at WWDC25.
The labels are self-declared against Apple's criteria and are not a substitute for a WCAG audit. We explain what they cover, how developers earn them, and why a label is a public claim you must be able to back up in Apple's Accessibility Nutrition Labels: What They Mean for Your App.
How to evaluate an accessibility supplier, the questions worth asking before you engage, and how to read the evidence they offer.
What should I look for when choosing a digital accessibility 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.
What questions should I ask an accessibility provider before engaging?
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.
Why doesn't ExceedAbility publish client testimonials or case studies?
Most of our work is confidential, business-to-business quality control. A public, named testimonial would require a client to state on the record that their digital services once fell short of a standard - something few organisations want to do, and we would not ask them to.
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.
How does ExceedAbility compare to other accessibility providers?
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.
See how we compare to other Australian providers in our provider directory, or contact us for a direct conversation about your requirements.
Is ExceedAbility independent from overlay and AI remediation vendors?
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.
What qualifications does ExceedAbility's named accessibility lead hold?
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.
Comparing providers, or ready to test us against them?
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.
How quickly can ExceedAbility start a new engagement?
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.
We are based in Sydney, Australia and work with clients across Australia and internationally. Learn more about our team on the About Us page.
Is ExceedAbility a registered government supplier?
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.
How does the time zone difference work in our favour?
For US and UK clients, the time-zone gap is an advantage rather than an obstacle. We audit, remediate and validate while your teams sleep, so progress is waiting each morning. New Zealand sits just two hours ahead, allowing near real-time collaboration.
Delivery still runs under a single named accessibility lead and the same five-stage methodology we use for Australian engagements.
Do you offer project management and product management?
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.
Can you help with SharePoint and intranet accessibility?
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.
Do you build 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.
Can you help with accessible modals, dialogs, and product tours?
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.
Can you help with accessible graphic design and publications?
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.
Do you offer remote services?
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.
What insurance does ExceedAbility hold?
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.
What are ExceedAbility's payment terms?
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.
Do ExceedAbility's training programs cover designers and developers separately?
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.
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.
Is ExceedAbility's delivery 100% onshore in Australia?
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.