PWAs Meet AI: Progressive Web App Accessibility for Voice Search and AI Assistants

It's 2:30 PM on a Tuesday. Sarah Martinez, who's blind, is trying to order coffee through her favourite café's new Progressive Web App using Siri voice commands on her iPhone.

"Hey Siri, open CaféMate and order my usual."

Siri's response: "I can't find that app."

The icon's right there on Sarah's home screen. She installed it last week. But because it's a PWA and not a native app, Siri has no idea it exists.

Sarah tries the Web Speech API built into the PWA instead. It sort of works, except Firefox doesn't support it at all, and Safari requires workarounds that the developers didn't implement. By the time she manually navigates through the app, her 15-minute break is over.

This isn't a hypothetical scenario. It's the current reality of Progressive Web Apps and voice accessibility in 2025.

Here's what Australian businesses need to know about PWAs, AI assistant integration, and WCAG 2.2 compliance before they commit to this technology.

What Progressive Web Apps Actually Are (And What They're Not)

Let's start with the basics, because there's a lot of confusion about what PWAs can and can't do.

A Progressive Web App is a browser-based website that replicates the look, feel, and features of a native mobile app. PWAs live in the browser like a traditional website and are fully connected to the web's infrastructure. At the same time, like native apps, they can be launched from a home screen icon, send push notifications, load in a split second, and be built to work offline.

Think of PWAs as websites wearing a really convincing native app costume. They're still fundamentally web applications, which gives them both advantages and limitations.

The Three Core Technical Requirements:

1. HTTPS: Secure connection protocol (non-negotiable for security)
2. Service Worker: A JavaScript file that controls network requests and caching
3. Web App Manifest: A JSON file telling the browser how to display the app

That's it. Three technical requirements that separate a PWA from a regular website.

In September 2025, Firefox finally added PWA support on Windows with version 143.0. That was a big deal because it meant PWAs now work across every major browser: Chrome, Safari, Edge, Brave, and Firefox.

The global PWA market is projected to grow from USD $5.23 billion in 2025 to USD $21.44 billion by 2033. That's an 18.98% compound annual growth rate. Companies aren't investing in PWAs because they're trendy. They're investing because PWAs deliver measurable results.

Studies show PWAs experience a 70% increase in session length compared to traditional web apps and a 20% increase in page views per session. Users are engaging more with PWAs because they load faster, work offline, and feel more responsive.

But here's the question Australian businesses aren't asking enough: are these PWAs accessible?

The Brutal Reality of PWA Voice Assistant Integration

I'm going to be blunt about this because the marketing materials aren't.

As of 2025, PWAs cannot integrate with system-level voice assistants like Siri, Google Assistant, or Alexa in any meaningful way. For voice assistant integration, native apps remain the only viable option.

Let me repeat that: PWAs cannot talk to Siri, Google Assistant, or Alexa.

iOS/Siri Limitations:

Users can't interact with PWAs using voice commands through Siri. Even if there's an icon for a PWA on your home screen, Siri is completely oblivious to it and cannot be asked to launch the app. No Siri integration is particularly disappointing in the context of iOS's Shortcuts feature. Siri simply doesn't know your PWA exists (Apple SiriKit documentation).

PWAs on iOS also have no background sync, Safari imposes a 50MB cache storage limit, and there's limited access to deep OS integrations like iMessage extensions.

Google Assistant Limitations:

Actions that can interact with web apps via voice will only be approved for games at the current time. That severely limits PWA integration with Google Assistant for most use cases. If you're not building a game, forget about Google Assistant integration.

Alexa Limitations:

No direct PWA integration with Alexa exists. Full stop.

The marketing materials for PWAs love to talk about "voice features" and "AI integration." What they don't tell you is that you're limited to the Web Speech API, which is a completely different thing from actual voice assistant integration.

What the Web Speech API Can (And Can't) Do

The Web Speech API is a W3C specification that enables developers to incorporate speech recognition and synthesis into web pages. It's been around for years, and it's what PWAs actually use for voice features.

The API has two core functions:

1. Speech Recognition: Listens to user input, processes it in real time, and outputs text for search queries, form inputs, or navigation commands.

1. Speech Synthesis (Text-to-Speech): Enables applications to "speak" text to users, reading notifications, providing instructions, or delivering content in auditory format.

That sounds pretty good, right? Here's the catch.

Browser Compatibility in 2025:

• Chrome on Android: Works great
• Firefox: The SpeechRecognition API is NOT compatible with Firefox (zero support) (MDN Web Speech API compatibility).

Let's talk about what you're actually required to do under Australian law.

WCAG 2.2 was released in October 2023 by the W3C and is now an approved ISO standard: ISO/IEC 40500:2025. WCAG 2.2 introduces nine new success criteria focusing on accessibility for web users with low vision, cognitive and learning disabilities, and motor disabilities (see the W3C WCAG 2.2 Quick Reference).

WCAG 2.2 contains 86 success criteria total: 77 from WCAG 2.1 plus 9 new ones.

Most global accessibility regulations, including Section 508 in the United States, EN 301 549 in Europe, and the Accessibility for Ontarians with Disabilities Act (AODA) in Canada, require Level AA conformance.

For Level AA conformance, your web page must satisfy all the Level A and Level AA success criteria. That's not "most of them" or "the important ones." It's all of them.

Three New Level AA Criteria in WCAG 2.2:

1. Success Criterion 2.4.11: Focus Not Obscured (Minimum) - The focus indicator must not be hidden or blocked by other elements when navigating with a keyboard. Critical for keyboard-only users.

1. Success Criterion 2.4.13: Focus Appearance (Minimum) - Ensures the keyboard focus indicator meets minimum size and contrast requirements.

1. Success Criterion 2.5.7: Dragging Movements - All functionality that requires dragging movements must have an alternative single-pointer method. Benefits users with motor disabilities who can't perform precise dragging actions.

WCAG standards are technology-agnostic. They apply to traditional websites, single-page applications, and Progressive Web Apps equally. There's no special exemption for PWAs.

Here's what that means in practice: your PWA needs ARIA attributes for screen reader compatibility, keyboard navigation that doesn't require a mouse, sufficient colour contrast (4.5:1 for regular text, 3:1 for large text), and alternatives for any functionality that requires precise motor control.

The European Accessibility Act (EAA) becomes effective on 28 June 2025, requiring businesses to ensure their digital products and services meet WCAG 2.1 AA accessibility standards. EN 301 549 currently uses WCAG 2.1, but the next version is expected to adopt WCAG 2.2 in 2025.

Australia's not waiting. Let me tell you about our legal framework.

Australia's DDA Compliance Requirements for PWAs

Australia's Disability Discrimination Act 1992 (DDA) mandates equal access to digital services for people with disabilities. Under the DDA, not making websites accessible to people with disabilities can be considered discrimination.

That "can be considered" language? Don't let it fool you. It means you're legally required to be digitally accessible.

PWAs fall squarely under the DDA's scope as digital services. Developers are implementing WCAG guidelines to guarantee app compliance with local accessibility legislation.

Non-Compliance Penalties:

• Fines up to AU$100,000
• Lawsuits through the Australian Human Rights Commission
• Reputational damage

AS EN 301 549:2024 is the Australian Standard for ICT Accessibility applicable to most ICT goods or services being procured by government. While AS EN 301 549 references WCAG 2.1, WCAG 2.2 should be used where appropriate instead.

The Australian Government's Digital Inclusion Standard (DIS) sets requirements for inclusive and accessible digital government experiences. It's effective from January 2025 for new services and July 2025 for existing services.

Australian government websites must meet WCAG 2.0 Level AA minimum, though WCAG 2.2 launched in 2023 and is the current recommended standard by W3C.

The Australian Human Rights Commission's guidance recommends conformance with Level AA of the WCAG guidelines. The Commission was working to update this guidance language to reflect the latest WCAG 2.2 version as of 2024.

And here's the kicker: the Australian Government is reviewing the Disability Discrimination Act 1992 right now, with public consultation extended to close on Friday, 14 November 2025. That means accessibility requirements might get stricter, not more relaxed.

Research indicates that PWAs are not fully accessible by default. Web developers must make an effort to conduct both machine and manual audits to achieve actual accessibility. An increasing number of websites, even government ones, are overlooking the need for equal access to new technologies among people with disabilities.

That last sentence should scare you if you're deploying PWAs without accessibility testing.

PWAs vs Native Apps: The Accessibility Comparison

Let's address the question everyone's really asking: are PWAs more or less accessible than native apps?

The answer: it depends entirely on implementation.

PWA Accessibility Advantages:

• Single codebase serves all platforms, ensuring consistent accessibility implementation
• Web accessibility tools like Google Lighthouse can test PWAs
• Easier to update accessibility features across all platforms simultaneously
• Platform-agnostic by nature, eliminating platform-specific accessibility issues

PWA Accessibility Disadvantages:

• Cannot integrate with system-level voice assistants (Siri, Google Assistant, Alexa)
• Web Speech API has inconsistent browser support
• iOS imposes severe limitations (no Siri integration, 50MB cache limit)
• Automated tools like Lighthouse can detect only a subset of accessibility issues

The theoretical accessibility advantage of PWAs is that you're building once for all platforms using web standards. The practical accessibility disadvantage is that you're locked out of native OS accessibility features that many users with disabilities rely on.

Native apps can integrate with VoiceOver, TalkBack, Switch Control, and platform-specific accessibility APIs. PWAs can't. They're limited to what browsers expose through web standards.

For many use cases, that's fine. For users who depend on deep OS integration for accessibility features, it's a dealbreaker.

Service Workers, Offline Functionality, and Screen Readers

Let's talk about service workers and how they impact accessibility.

Service workers are a core technology for PWAs, enabling offline functionality and performance improvements by operating in the background for caching and network request management.

The good news: service workers don't negatively impact screen reader functionality.

The not-so-good news: ARIA support is limited to screen readers only (JAWS, Narrator, NVDA, TalkBack, and VoiceOver). Documentation of screen reader support for ARIA is scarce, though there are efforts like PowerMapper's ARIA screen reader compatibility table.

ARIA live regions provide a mechanism for notifying screen readers when content is updated on the page. This is particularly important for PWAs that update content dynamically while offline or syncing.

Progressive enhancement is recommended: start with standard semantic HTML markup, then add ARIA enhancements on top. This ensures the largest number of users can access the content.

It's critical to test ARIA implementations with screen readers before deployment. The experience doesn't have to be identical in every screen reader, but it does have to be usable in most.

Here's what many developers get wrong: they implement service workers for offline functionality but forget to make the offline experience accessible. Your PWA works offline? Great. Can a screen reader user navigate it offline? Can they understand what content is cached versus what requires a network connection?

These aren't hypothetical questions. They're WCAG compliance requirements.

Push Notifications: The Accessibility Challenge Nobody's Talking About

Push notifications in PWAs have become more dynamic in 2025, allowing richer media content, better action buttons, and background syncing for real-time interactions.

They've also introduced new accessibility challenges.

With the use of a status message, information can be provided to the user without changing focus or unnecessarily interrupting their work. That's WCAG Success Criterion 4.1.3: Status Messages (Level AA).

ARIA live regions are used to announce dynamic content changes to screen reader users and are particularly useful for real-time updates like notifications, form validation messages, or chat applications.

Here's the problem: many PWAs implement push notifications without considering how screen reader users will be notified. The notification appears visually, but there's no ARIA live region announcing it. The user misses critical information.

Or worse, the notification interrupts the user's workflow without warning, violating WCAG's requirement that users maintain control over content updates.

Notifications for PWAs now support improved permission UI that gives users control over what they'll get and when, explaining the value before asking for access. That's good UX and good accessibility.

But if your push notifications aren't announced to screen readers, if they don't have sufficient colour contrast, if they require mouse interaction to dismiss, you're creating accessibility barriers.

The Web Content Accessibility Guidelines recommend a minimum contrast ratio of 4.5:1 for regular text and 3:1 for large text. Your notification badges meet that threshold? Your action buttons are keyboard-accessible? Your rich media content has alt text?

These aren't optional nice-to-haves. They're Level AA conformance requirements.

The Cost Argument: Why PWAs Look Attractive (And Where That Breaks Down)

Let's talk about money, because that's usually why businesses choose PWAs over native apps.

PWAs use one build that runs across all devices. That drastically lowers upfront investment and makes ongoing updates more affordable. Native apps require separate builds for iOS and Android, resulting in higher development and maintenance costs.

According to industry research, native apps are 3-4 times more expensive than PWAs.

Progressive web apps offer significant cost advantages over native app development while providing similar user experiences because you maintain a single codebase instead of rebuiling the same feature for different app stores (Web.dev progressive web apps guide). You're using a single codebase that works across all platforms.

PWAs excel in accessibility, speed of deployment, and lower costs. They're accessible on any device with a web browser, offering broad accessibility, and they eliminate the need for app store approval and installation.

That all sounds great. Here's where the cost argument breaks down.

If you're building a PWA and discover halfway through that your target users need voice assistant integration, you can't add it. That's not a development limitation. It's a technology limitation. PWAs fundamentally cannot integrate with Siri, Google Assistant, or Alexa.

If your accessibility audit reveals that Firefox users can't use your Web Speech API voice features, you've got two options: build workarounds (expensive) or tell 3-4% of your users they can't use that feature (accessibility violation).

If you're deploying in Australia and discover your PWA doesn't meet WCAG 2.2 Level AA requirements, the cost of remediation might eliminate the initial cost savings. Professional WCAG audits for comprehensive platforms range from AU$10,000 to AU$35,000. Technical remediation starts at AU$5,000 and can reach AU$20,000 depending on complexity.

The cost advantage of PWAs assumes you're building accessibility in from the start, not retrofitting it later. If you're treating accessibility as an afterthought, your costs will balloon regardless of whether you chose PWA or native development.

Testing Requirements: Why Lighthouse Isn't Enough

Google Lighthouse is a powerful, open-source automated tool that runs audits against web pages in categories including Performance, Accessibility, Best Practices, SEO, and Progressive Web App.

It's also insufficient for WCAG compliance.

Lighthouse can catch many accessibility issues automatically. It can't evaluate whether your alt text is meaningful, whether your keyboard navigation flow makes logical sense, or whether your voice features work for users with speech disabilities.

Lighthouse includes an "Additional Items to Manually Check" section that suggests accessibility tests that should be conducted manually. That's Lighthouse itself telling you that automated testing is only a first step.

While automated tools like Lighthouse are helpful, they can't catch all accessibility issues. Some aspects like meaningfulness of alt text or logical flow of keyboard navigation require human judgment.

Automated tools should be complemented by manual testing and user testing with people with disabilities.

The 30/70 Rule:

Automated testing catches approximately 30% of accessibility issues. The other 70% requires manual testing.

That means:

1. Automated Testing (30%):

- Run Lighthouse accessibility audits

- Use tools like axe, WAVE, or pa11y

- Integrate into CI/CD pipelines to catch regressions

1. Manual Testing (70%):

- Keyboard-only navigation testing (no mouse)

- Screen reader testing (NVDA, JAWS, VoiceOver)

- Checking error states and form validation manually

- Testing voice features with actual users who rely on them

- Verifying offline functionality with assistive technology

Lighthouse can be run as a Chrome DevTools extension, a command-line tool, or as part of continuous integration systems. Chrome DevTools is the easiest method for most developers.

For extended accessibility tests beyond Lighthouse's capabilities, specialised tools like axe-core or pa11y are helpful open-source solutions that can be easily integrated with testing frameworks.

Accessibility testing typically combines automated tools (Axe, Google Lighthouse, WAVE) that rapidly scan for WCAG violations, manual testing using keyboard navigation and screen readers, and user testing with assistive technologies to detect context-sensitive issues automated testing can't find.

If you're only running Lighthouse and calling it "accessibility tested," you're not WCAG compliant. You're wishful thinking.

The Voice User Interface Accessibility Gap

The W3C has published the "Natural Language Interface Accessibility User Requirements" document, which aims to identify accessibility-related user needs and requirements for Voice User Interfaces (VUIs).

This document outlines accessibility-related user needs, requirements, and scenarios for natural language interfaces. It's supposed to influence accessibility requirements in related specifications and in the design of applications that include natural language interfaces.

Here's the uncomfortable truth buried in that document: WCAG doesn't specify how a voice assistant should recover from misheard commands. Yet this is a daily frustration for many users.

The W3C is working to identify where there are gaps in WCAG 3.0 as they relate to Voice Agents, their accessibility, usability, and potential privacy implications for people with disabilities.

Translation: the standards are still being figured out.

Design guidelines recommend following WCAG and other guidelines to ensure usability for individuals with disabilities when implementing VUIs. For visual components, text spacing requirements are specified in WCAG 2.1 success criterion 1.4.12. Success criterion 3.3.4 addresses error prevention.

But what about purely voice interactions that have no visual component? What about error recovery when the voice system misunderstands a command? What about users with speech disabilities who need alternatives to voice input?

These are active areas of research, not solved problems.

Essential accessibility features for VUI include ensuring hands-free operation for users with motor impairments, implementing voice recognition that can adapt to speech patterns affected by physical disabilities, and allowing users to set the pace of interaction.

Natural language interfaces can be made accessible to users with disabilities at the platform and application levels via multiple modes of input and output. Some users with physical disabilities may need speech input. Others may need a keyboard, switch input, an eye tracking system, or some combination.

The key phrase there is "multiple modes of input and output." If your PWA relies solely on voice input with no keyboard alternative, you're violating WCAG. If it relies solely on visual output with no speech synthesis, you're violating WCAG.

Designers should follow WCAG guidelines when implementing voice features:

• Ensure screen readers, keyboard navigation, and other assistive tools work properly
• Include ARIA attributes for voice-activated elements
• Provide alternative input methods for users who cannot use voice
• Design for error recovery when voice commands are misheard
• Allow users to control the pace and volume of voice output

That's the baseline. Not the goal. The baseline.

The Australian Business Reality Check

Progressive Web Apps have firmly established themselves as a game-changer for Australian enterprises, aiming to elevate user experience, significantly reduce long-term development costs, and improve overall digital accessibility nationwide.

That's the marketing pitch. Here's the reality check.

Australian-specific PWA adoption statistics for 2025 aren't available in published research. The market research that does exist focuses on global trends with North America dominating the PWA market due to high concentration of technology firms and early adopters.

We don't have reliable quantitative data for Australia-specific PWA adoption rates or market size. For Australian market insights, you'd need to contact local tech industry organisations or specialised market research firms.

What we do know is that Australia's regulatory environment for digital accessibility is strengthening, not weakening. The Digital Inclusion Standard takes effect in January 2025 for new services and July 2025 for existing services. The DDA review is ongoing. The European Accessibility Act will influence international digital services selling to Australian customers.

Australian businesses aren't operating in a vacuum. If you're building a PWA, you need to meet the same WCAG 2.2 Level AA standards that apply to traditional websites and native apps.

You need to conduct both automated and manual accessibility testing. You need to consider how users with disabilities will interact with voice features, offline functionality, and push notifications. You need to document your accessibility compliance for potential AHRC complaints.

And you need to be honest about the limitations. PWAs can't integrate with system-level voice assistants. That's not a temporary limitation. It's a fundamental architectural constraint.

For some businesses, that's acceptable. For others, it's a dealbreaker.

The Bottom Line: Should You Build a PWA?

Let's answer the question directly: should your Australian business build a Progressive Web App?

It depends.

Build a PWA if:

• You need rapid deployment across multiple platforms
• Your budget favours a single codebase over platform-specific development
• Your users don't require deep OS integration
• You can commit to WCAG 2.2 Level AA compliance from the start
• Your core functionality doesn't require Siri, Google Assistant, or Alexa integration
• You're prepared to conduct comprehensive accessibility testing (automated + manual)

Choose a native app if:

• Voice assistant integration is critical for your use case
• You need deep OS integration for accessibility features
• Your target users rely heavily on platform-specific assistive technologies
• Performance and offline functionality must be seamless
• You can justify the higher development and maintenance costs

Don't build either if:

• You're treating accessibility as an optional add-on
• You're not prepared to test with users who have disabilities
• You're planning to skip manual accessibility testing
• You think WCAG compliance is just about automated Lighthouse scans

The integration of voice assistants and AI into PWAs is revolutionising user interactions for some users. For others, it's creating new barriers.

PWAs offer significant advantages in cost, deployment speed, and cross-platform compatibility. They also have significant limitations in voice assistant integration, browser support for speech APIs, and OS-level accessibility features.

The good news is that these limitations are knowable and plannable. You don't have to discover halfway through development that your PWA can't integrate with Siri. You know that now.

The question is: what are you going to do with that information?

Build with accessibility in mind from day one. Test with real users who have disabilities. Don't rely solely on automated tools. Be honest about limitations. Provide alternatives when technology constraints prevent ideal solutions.

And whatever you do, don't promise Sarah Martinez that she'll be able to use Siri to order coffee through your PWA. Because she can't. And that's not her problem to solve.

It's yours.

---

About Webcoda

Webcoda specialises in accessible web development and WCAG 2.2 compliance for Australian organisations. With 20 years of experience delivering 500+ websites and deep expertise in Progressive Web App development, we help businesses build accessible digital experiences that actually work for everyone.

Need help with PWA accessibility or WCAG 2.2 compliance?Contact our development team for a confidential accessibility assessment.