Your Accessibility Questions,
Honestly Answered

Everything clients ask us about audits, consulting, and VPAT Documentation in plain language.

The process of conducting a WCAG audit typically starts with defining the scope, including key user journeys, templates, and platforms. Once the scope is finalized, we perform a combination of automated and manual accessibility testing.

Automated tools help identify common issues across pages, while manual testing ensures compliance with WCAG success criteria using keyboard navigation, screen readers, and other assistive technologies.

All identified issues are then documented with clear descriptions, recommendations, and mappings to WCAG guidelines. Finally, the report is shared with the client along with guidance on remediation and next steps.

In automated accessibility testing, we use tools such as crawlers, browser extensions, accessibility linters, and CI/CD integrations with rulesets like axe-core, WAVE, or Equalize Digital Accessibility Checker. These tools help identify common and programmatic issues at scale.

Manual accessibility testing involves a human tester evaluating the application using keyboard navigation, contrast checking tools, and assistive technologies like screen readers, magnifiers, and voice navigation.

In many cases, users with disabilities also participate in testing to provide real-world, lived experience feedback. Both approaches are essential, as automated tools cannot detect all accessibility issues.

Yes — and this is one of the most important points we want to be clear about. Under accessibility law, the responsibility for procuring accessible software lies with your organization, not the vendor. If a third-party tool on your platform creates a barrier for a user, it is your organization that is held liable, regardless of who built that component.

That said, auditing third-party tools doesn’t mean you’re expected to fix everything in them. What it does is give you a documented, defensible record. Our audit reports serve two critical purposes in this context:

  • They alert the third-party vendor to specific issues, creating a formal paper trail and prompting them to take action.
  • They provide the factual basis for noting these items in your VPAT — clearly indicating that the issue exists in a third-party component outside your direct control.

The key takeaway: You can acknowledge a third-party issue in a VPAT even when you lack the ability to fix it yourself. What you cannot do is be unaware of it. An audit ensures you know what’s there — and that knowledge protects you.

Mobile accessibility testing is different because of the way users interact with mobile devices. Instead of keyboard and mouse, users rely on touch gestures and mobile screen readers like VoiceOver and TalkBack. There are also platform-specific behaviors, gestures, and UI patterns that need to be tested separately. While the core accessibility principles remain the same, the way they are implemented and tested differs between web and mobile.

Because they are separate products, governed by separate accessibility standards, and tested with different tools. A desktop website is evaluated against WCAG. A native iOS app is evaluated against WCAG and Apple’s Human Interface Guidelines as interpreted through its accessibility APIs. An Android app follows a similar but distinct path with Google’s accessibility standards.

The interaction models are also fundamentally different. Desktop users navigate primarily with keyboards and pointer devices. Mobile users rely on touch, gesture-based screen readers, and voice control. An issue that is critical on mobile (e.g., a target that’s too small to tap accurately) may not even exist on desktop.

Combining these into one audit would either make the scope impossibly large or result in a superficial treatment of both. Keeping them separate ensures each platform gets the depth of review it actually needs.

False positives, findings that appear to be violations but turn out not to be upon closer examination, are a normal part of rigorous accessibility testing. We handle them transparently.

When a potential issue is flagged, our auditors investigate whether it is a genuine barrier or a false positive introduced by an automated tool or an edge-case test condition. If we determine it’s a false positive, we document that determination and the reasoning behind it. This creates a clear audit trail that your team can reference and share with stakeholders.

During the review period, your development team may also push back on findings, and we encourage that. If your team can demonstrate that something we flagged is not actually a barrier in context, we revise the finding accordingly. The goal is accuracy, not inflated issue counts

Generally, it is recommended to start the accessibility audit on desktop with one primary screen reader and browser combination. At DigitalA11Y, we use NVDA with Chrome as a baseline, as it provides reliable results during manual testing. However, depending on the project scope and requirements, we also perform validation checks across other browser and assistive technology combinations. Since most elements remain consistent in responsive design, we perform quick checks on mobile using mobile screen readers. In our experience, responsive pages are similar to the desktop version, with slight variations like hamburger menus in navigation, FAQ accordions, etc.

For large, complex platforms, there is simply no way for an auditor to walk in cold and define the scope accurately. Larger platforms have product areas with different user flows, roles, and levels of criticality — and only your team knows which of those matter most right now.

Scoping collaboratively means we sit down together and map out: which user journeys are highest priority, which areas are actively maintained versus legacy, what’s about to change in a release cycle, and where your procurement or compliance obligations are most pressing.

This prevents two common problems: over-scoping (auditing pages that are being retired next quarter) and under-scoping (missing a critical checkout flow because no one mentioned it). The result is an audit that is both thorough and actionable within your real-world constraints.

Good scoping isn’t about limiting what we look at — it’s about making sure every hour of audit work delivers maximum value to your organization and your users.

Accessibility is a continuous journey. As products evolve with new features and updates in every sprint, accessibility also needs to be maintained continuously. Even with strong processes and guardrails in place, there can be cases where accessibility issues are introduced into production.

Because of this ongoing change, achieving and maintaining 100% WCAG compliance at all times is challenging. The goal should be to build accessibility into the development process and continuously improve over time.

A template, in the context of an accessibility audit, is a page or screen pattern that represents a category of similar pages — not a literal design file. For example, a news website might have thousands of individual article pages, but they all share the same underlying structure: a headline, a byline, a body text area, a sidebar, and a comment section. That structure is the template.

Auditing every individual article page would be redundant and enormously expensive without providing meaningfully more insight. If the template is accessible, the pages built from it will be accessible. If the template has a structural issue, every page built from it has that same issue — and fixing the template fixes them all.

By identifying and auditing unique templates, we cover the full range of structural patterns your platform uses without inflating the scope unnecessarily. It’s how we make audits both thorough and economically viable.

Yes, to a large extent. If the website is responsive and the content, components, and functionality are consistent across devices, then a web accessibility audit will cover most of the mobile web experience.

However, there can still be mobile-specific issues, especially related to screen readers, touch interactions, and responsive behavior. In our experience, most differences come from elements like navigation (hamburger menus), accordions, and dynamic components. Following semantic HTML and proper ARIA authoring practices helps ensure that the experience works well across both desktop and mobile.

The short answer is no. WCAG is technology-agnostic, which means it applies to both web and mobile. In WCAG 2.1 and WCAG 2.2, several success criteria specifically address mobile accessibility, such as touch targets, orientation, and input modalities. There is also guidance from the W3C Mobile Accessibility Task Force that helps interpret WCAG for mobile use cases.

For testing mobile applications on iOS and Android, there are a number of free and commercial tools available. For example, Accessibility Scanner for Android and Xcode Accessibility Inspector for iOS are widely used.

At DigitalA11Y, we recommend using a combination of tools along with manual testing using screen readers like TalkBack and VoiceOver. Tools can help identify basic issues, but manual testing is essential to validate real user experience.

Yes, mobile app accessibility is evaluated against the same WCAG compliance requirements. However, how those requirements are implemented may differ based on the platform.

For example, concepts like keyboard accessibility translate to focus navigation on mobile, and visual requirements like contrast remain the same. The key is to interpret WCAG success criteria in the context of mobile platforms and ensure they are implemented using platform-specific accessibility features.

The honest answer is that genuine accessibility testing is labor-intensive in a way that most people underestimate. Automated tools catch somewhere between 20–40% of real accessibility issues. The rest require trained human evaluators — people who can operate screen readers fluently, who understand the nuanced intent behind WCAG success criteria, and who can distinguish a true barrier from a technical quirk.

Each finding in a thorough audit isn’t just flagged — it’s tested across assistive technology combinations, documented with precise failure descriptions, mapped to the relevant standard, and assigned a remediation recommendation that a developer can actually act on. That process, done right, takes time.

What an audit saves, however, is considerable: remediation costs caught early are a fraction of what they cost after release, legal exposure is reduced, and the cost of retrofitting a product that was never designed accessibly is almost always higher than the audit that would have caught the issues sooner.

Accessibility is not a one-time project — it’s an ongoing program. Our approach to future audits depends on the pace of change in your product and the nature of your compliance obligations.

For most organizations, we recommend a cadence of annual full audits supplemented by targeted reviews whenever significant new features are released. We also offer advisory support during design and development so that new work is built accessibly from the start, reducing the remediation burden at each audit cycle.

For products under active procurement scrutiny or legal obligation, more frequent spot-checks may be appropriate. We work with your team to define a cadence that matches your risk profile and release schedule.

We don’t just hand over a report. We walk you through the findings, answer your questions, help you prioritize issues, and remain available to discuss any accessibility concerns that arise throughout the project.

We use a layered approach: automated tools (which catch around 30–40% of issues), manual keyboard testing, color contrast checks, and screen reader testing by a blind subject matter expert. After testing, our team reviews the underlying code to confirm every finding is a genuine WCAG failure — not a browser or assistive technology quirk. Only real issues make it into the report.

Yes. Automated tools are useful for a first pass, but they can’t replicate real human interaction. Our audits are primarily human-driven — a blind expert uses a screen reader to navigate your site as a real user would. If a person can’t successfully find what they need, that’s the issue we care most about.

We use Axe Core (known for its accuracy and minimal false positives), WAVE, and our own in-house Chrome extension built on the AXE rules engine. For large websites, we also deploy custom crawlers. All automated findings are reviewed manually before being included in the report.

For manual testing, assistive technologies such as screen readers (NVDA, VoiceOver), magnifiers, and keyboard-only navigation are used. No single tool can cover everything, so a mix of tools and manual validation is always recommended.

Our primary setup is NVDA with Chrome. For broader coverage, we also test:

  • Android: TalkBack with Chrome
  • Windows: JAWS with Chrome and Firefox, NVDA with Chrome and Firefox
  • macOS: VoiceOver with Safari
  • iOS: VoiceOver with Safari

Yes. Every audit includes testing by a blind subject matter expert who evaluates your website using a screen reader. This catches issues that only surface during real-world usage, not just code-level checks.

Yes, as an add-on service. We can include individuals with motor disabilities, low vision, and other conditions — sourced from both the US and other regions for diverse feedback. At least one or two people with visual disabilities will navigate the site while we observe. Sessions are recorded and shared with you. Note: these users are not accessibility subject matter experts — they provide real-world usability feedback, which is different from the expert screen reader testing included in every audit. Additional charges apply.

A WCAG audit evaluates your site page by page against specific technical criteria. User testing evaluates complete user flows — for example, how difficult it is for a person with a disability to sign in, complete a form, or make a purchase. We rate flow difficulty on a scale and focus on whether real tasks can be completed, not just whether individual criteria pass or fail.

The report is delivered as an Excel or Google Sheets file. It includes issue IDs, page names, URLs, WCAG success criteria references, descriptions, recommendations, affected code snippets, and linked screenshots stored in a cloud folder (Google Drive, OneDrive, or Dropbox — your choice). The file is structured for easy import into JIRA or any other project management tool your team uses.

The report is organized across several tabs:

  • Resources — accessibility guidelines and reference materials
  • Cover — project and consultant details
  • Glossary — explains each tab
  • Evaluation methodology — tools used, testing criteria, scope
  • Scope — exact pages and workflows audited
  • Executive summary — total issues by severity, for stakeholders who need the highlights
  • Audit findings — the full issue list with descriptions, code snippets, and recommendations
  • Conformance chart — how your site performs against each WCAG criterion

Issues are categorized by their real-world impact on users with disabilities:

  • Blocker Completely prevents users from completing a critical task
  • Critical Significantly hinders the experience, though access isn’t fully blocked
  • Serious Creates frustration and extra effort; users can still proceed
  • Moderate Noticeable impact, affects efficiency more than access
  • Minor Minimal impact; mostly consistency or structural issues

Yes. The report includes code snippets showing the problematic code alongside suggested fixes. We tailor recommendations to your codebase where possible, and often link to relevant examples and resources to help your developers implement fixes faster. We don’t write full custom code (like entire JavaScript files), but the guidance is specific enough that a developer can act on it immediately.

Every report goes through a two-tier review: a senior auditor checks initial findings for accuracy and consistency with WCAG standards, and then the lead auditor does a second pass to validate results and confirm recommendations are technically sound. Only verified issues make it into the final report.

Pricing ranges from $150 to $500 per page, depending on complexity. A simple informational page costs much less than a multi-step checkout flow with custom interactive components. To give you an accurate quote, we review your list of pages and workflows first and respond within a day or two.

The timeline for an accessibility audit depends on the scope, number of templates, and complexity of the platform.

Time is also built in for internal quality assurance and peer review. Once the audit is complete, we schedule a walkthrough to present findings and answer your team’s questions.

As a general estimate, a 10-page audit can take around 5 to 7 working days.

There may also be a backlog, as multiple projects are often in the pipeline. It is always better to confirm timelines with the accessibility vendor before starting the engagement.

Once the scope is finalized and the contract is signed, we can begin within 2–3 days. That window is used to hold a kickoff meeting, gather access credentials, and prepare the testing environment.

For most applications with dynamic content, forms, custom components, and modals, it’s common to uncover 250–500 individual issues. These typically fall into 15–25 unique patterns (like missing labels, keyboard traps, or contrast failures) that repeat across pages. The volume can seem overwhelming, but we help you prioritize so the most impactful fixes come first.

Yes – WordPress, Drupal, Sitecore, or custom-built systems. We assess both the CMS itself (does it support accessible content creation?) and how your team is actually using it. We provide recommendations for content authors and developers, and our in-house developers can review code-level configurations for custom components.

We schedule a walkthrough session to go through findings with your team, answer questions, and help you understand the next steps. Our subject matter experts remain available throughout remediation — your developers can reach out by email or schedule calls to discuss specific issues. We don’t hand over a report and disappear.

Yes. Once your team has addressed the issues, we return to validate every fix. We confirm that each flagged item has been properly resolved, check that no new issues have been introduced, and sign off on the changes. After successful validation, we help you draft an accessibility statement for your website.

We’ll make it right. If there are genuine issues we missed, we retest and validate those areas at no additional cost. Our fees are non-refundable given the consulting work already invested, but if something was overlooked, we work with you to resolve it within the original scope and budget. We treat this as a partnership.

Absolutely. After the audit, we identify high-leverage fixes – issues that affect multiple success criteria or appear across many page templates, so one fix benefits the whole site. We factor in your timeline and provide a targeted action plan. For example, if you have 300 issues and a tight deadline, we’ll tell you the specific 30 fixes that will move the needle most before your next milestone.

A VPAT assesses your product against every WCAG success criterion and assigns one of four statuses to each:

  • Supports The feature fully meets the accessibility requirement
  • Partially supports The feature meets the requirement in some areas but has gaps
  • Does not support The feature does not meet the requirement
  • Not applicable The criterion does not apply to the product

“Partially compliant” means that across all criteria, some are fully supported, some are partially supported, and some are not supported. It is not a pass or fail — it is an honest snapshot of where your product stands at a given point in time.

In practice, very few digital products achieve full compliance across every criterion. A partially compliant VPAT is completely acceptable and common, provided the product allows users with disabilities to complete essential tasks without being blocked. It also helps you track progress — each remediation cycle should move more criteria from “partially supports” to “supports.”

A partially compliant VPAT is far better than no VPAT at all. It demonstrates transparency, shows your commitment to improvement, and gives stakeholders an accurate picture of where you stand — which is what procurement teams and regulators actually want to see.

Accessibility standards like WCAG define the minimum technical requirements needed to reduce barriers. A product can technically pass every criterion on a checklist and still be confusing, exhausting, or unusable for people with disabilities in the real world.

Compliance asks: does this element have an accessible label? Usability asks: can a real person using a screen reader actually complete this task without getting lost or stuck?

These are different questions. A form might have technically correct labels but be structured so illogically that a screen reader user cannot figure out how to submit it. A checkout flow might pass all contrast checks but have a focus order so disjointed that keyboard users lose their place on every step.

This is why we prioritize:

  • User journeys over isolated pages — we test whether full tasks can be completed, not just whether individual elements pass
  • Functional outcomes over theoretical pass/fail — can users log in, submit a form, view a report, complete a purchase?
  • Real assistive technology behavior over tool-based assumptions — what actually happens when a blind user navigates your site, not just what the code suggests should happen

Compliance sets the baseline. Usability determines real accessibility. Our approach ensures that meeting standards also results in a product that is practically usable — not just technically compliant on paper.

We aim to transfer knowledge, not just deliver reports. Our consulting includes guidance on best practices, and we recommend dedicating some hours to training an internal accessibility champion — someone who can drive accessibility efforts from within your organization. Accessibility works best as a collaboration between our external expertise and your team’s internal ownership.

The most impactful use of consulting hours is during the validation phase. Once your team has applied fixes from the audit, use consulting time to review the changes, get sign-off, and ensure everything is clean before pushing to production. Save your questions and edge cases for these sessions rather than spreading them out.

We offer three models to suit different needs:

Partnership model — A fully customized arrangement for long-term or complex projects, including dedicated hours, strategic planning, and ongoing support.

Hourly billing — Ideal for smaller or one-off projects. You pay only for the time you use.

Retainer package — A set number of hours each month at a discounted rate. Best for ongoing, predictable needs.

Our rate is $70 per hour for consulting beyond the complimentary hours included in your package. We also often provide some extra consulting hours at no charge to help you get the most out of our service.

Yes. Additional consulting hours can be purchased in blocks as needed, beyond what’s included in your package.

Our support hours are 10:00 AM – 10:00 PM IST, Monday to Friday. We can also accommodate urgent requests outside these hours when pre-scheduled.

We’re available via Slack, email, or phone. Your developers can also schedule calls with our team to discuss specific recommendations and implementation strategies, or reach out by email for clarification on any findings.

We can re-audit your website whenever standards are updated and provide a detailed report of any new issues. Your team would then be responsible for implementing the fixes. For comprehensive ongoing maintenance, we recommend engaging a dedicated accessibility maintenance service, as that level of support requires additional developers and CMS access.

We don’t just hand over a report. We walk you through the findings, answer your questions, help you prioritize issues, and remain available to discuss any accessibility concerns that arise throughout the project.

Yes, it is recommended to include accessibility testing in every release. This can be done using accessibility linters, browser extensions, and automated testing integrated into CI/CD pipelines. By doing this, teams can catch accessibility issues early and reduce the number of issues reaching production.

No, and this is a common misconception that delays VPAT documentation unnecessarily. A VPAT is not a certificate of perfect compliance. It is an honest, documented statement of where your product currently stands against accessibility standards.

A well-drafted VPAT can and should reflect the actual state of the product: areas where conformance is full, areas where it is partial, and areas where issues remain. The value of a VPAT is its accuracy, not its perfection. Procurement officers and accessibility reviewers are experienced enough to evaluate a candid document and they are far more suspicious of one that claims full conformance across the board with no caveats.

A VPAT with honest partial conformance ratings is more credible, and more legally defensible, than one that overstates compliance. Accuracy is the asset.

A VPAT should be updated whenever the information it contains is no longer accurate. In practice, this means reviewing it after significant product updates, after a new accessibility audit, or when issues that were previously noted as unresolved have been remediated.

As a general guide, most products warrant a VPAT review at least annually — aligned with regular audit cycles. For products that ship frequently or that are actively being remediated, more frequent updates may be appropriate to ensure the document reflects current reality.

An outdated VPAT that claims better conformance than the product actually achieves is a liability, not an asset. The document should always be something you’re comfortable standing behind.

It depends on how your platforms are structured:

If your website has different versions for different countries (distinct URLs or major functional differences), each version may need its own VPAT.
If a mobile app is fully integrated into the website and not a separate product, one VPAT may cover both — provided both components are addressed within it.
If the website and app are separate products, each typically requires its own VPAT.

Combining web, iOS, and Android into a single VPAT creates a document that can’t accurately represent any of them.

Separate VPATs also make procurement conversations cleaner. When a buyer is evaluating your iOS app, they want a document specifically about that product — not a document where they have to mentally filter out web and Android references.

One product, one VPAT. Each document can be precise, accurate, and directly useful to the audience evaluating that specific platform.

They serve different purposes and, in most cases, you need both rather than choosing between them.

A VPAT (or its output, the Accessibility Conformance Report) is a structured, standardized document primarily used in B2B procurement contexts. When a government agency or enterprise buyer evaluates your product, they want a VPAT because it maps your product’s conformance against specific technical criteria in a format they can evaluate and compare. It’s a formal instrument.

An accessibility statement is a public-facing document on your website or app that tells users — including disabled users — about your product’s accessibility, how to request accommodations, and how to report issues. It’s required by law in many jurisdictions (including the EU under EN 301 549 and the UK under public sector regulations) and serves a fundamentally different audience.

If you do both: you need both documents, each suited to its own audience.

If you sell to enterprise or government buyers: you need a VPAT.

If you have a public-facing website or app: you likely need an accessibility statement.

An accessibility statement does not replace a VPAT, it complements it. We include an accessibility statement as part of our standard package.

A VPAT (Voluntary Product Accessibility Template) is a document that explains how accessible a digital product is — whether a website, web app, software, or mobile app. It evaluates conformance against accessibility standards such as WCAG, Section 508, or EN 301 549.

Think of it as a report card for accessibility: it shows what works well, what needs improvement, and how the product measures up against relevant standards. It is the industry-recognized way to communicate your product’s accessibility status to stakeholders, clients, or government bodies.

No. There is no official WCAG certification issued by any recognized authority. WCAG is a set of international standards developed by the W3C, but the W3C does not offer any form of certification.

A VPAT is the closest equivalent, it’s the accepted industry standard for documenting and communicating your accessibility compliance to stakeholders, clients, and government bodies.

A VPAT includes your product details, the accessibility standards it is evaluated against, and a detailed assessment for every WCAG success criterion. Each criterion is assigned one of the following statuses:

  • Supports The feature meets the accessibility requirement.
  • Partially supports The feature meets the requirement in some areas but has gaps.
  • Does not support The feature does not meet the requirement.
  • Not applicable The criterion does not apply to the product.

Each status is accompanied by a brief explanation so readers understand the level of compliance and what may need to be improved.

A VPAT is typically prepared after the audit and remediation, as it reflects the current state of your product’s accessibility. Completing it post-remediation allows most criteria to be marked as “Supports,” which presents a stronger and more accurate compliance position.

That said, a VPAT can be created at any stage. We can prepare a pre-remediation VPAT to establish a baseline, it will likely show partial compliance, and then update it after fixes are implemented to reflect improved conformance. The right timing depends on your compliance goals.

There are four VPAT types, each aligned to a different standard or region:

  • WCAG — Global standard, widely recognized across the UK, EU, Canada, and beyond. WCAG 2.1 or 2.2 Level AA is the most commonly adopted.
  • Section 508 — U.S. federal requirement for government agencies and contractors. Relevant if you serve U.S. federal clients.
  • EN 301 549 — European standard, mandatory for EU public sector and aligned with UK regulations. Extends beyond web to cover mobile apps and other ICT.
  • International — Covers all of the above in a single document, making it usable across geographies. Our VPAT 2.5 International template includes dedicated sections for Section 508, EN 301 549, and Revised 508.
  • U.S. federal clients → VPAT based on Section 508
  • Global or general clients → VPAT based on WCAG 2.1/2.2 AA
  • EU or UK clients → VPAT aligned with EN 301 549
  • Mixed or enterprise clients → International VPAT covering WCAG + Section 508 + EN 301 549

If you’re unsure, an International VPAT is the safest choice — one document that works across all regions.

Yes. The VPAT can be tailored to emphasize the standards most relevant to your organization. For example, if your primary audience is U.S. federal agencies, we’d focus on Section 508. If you operate in Europe, we’d align the report to EN 301 549. If you need broad coverage, we can map compliance across multiple standards in a single international VPAT.

Accessibility of content you don’t control is addressed transparently in the VPAT. We approach it in three ways:

Acknowledge shared responsibility — The VPAT notes where accessibility is a shared obligation between your platform and those who manage content within it..

Clarify scope — We clearly separate what your platform is responsible for versus what third-party contributors or users are responsible for.

Note content responsibility — We include a clause explaining that the accessibility of customer-generated or third-party content is outside your direct control, while noting what tools or guidance your platform provides to support accessible content.

The cost of a VPAT depends on the complexity of your product and the scope of the assessment. Typically, pricing ranges from $1,000 to $5,000. We’re happy to provide a more specific quote based on your product and requirements.

Yes, we can provide a VPAT template to help you get started. However, filling out a VPAT correctly requires accessibility expertise and a thorough understanding of WCAG success criteria. We recommend working with our team to ensure the document is accurate and credible.

A VPAT is the template or format used to document accessibility compliance, while an ACR (Accessibility Conformance Report) is the completed report based on that template.

In simple terms, VPAT is the structure, and ACR is the final document that contains the evaluation results.

No, a VPAT is not required to achieve WCAG compliance. WCAG compliance is based on how well a product meets the success criteria.

However, a VPAT is often required as a supporting document to demonstrate compliance, especially in procurement, legal, or enterprise contexts.

A VPAT can be created by the product owner, internal accessibility teams, or external accessibility consultants like DigitalA11Y.

In most cases, organizations prefer working with accessibility experts to ensure the VPAT is accurate, properly evaluated against WCAG, and aligned with industry expectations.

No, not all pages are tested manually in an accessibility audit. Instead, we focus on key templates and critical user journeys. Since many pages are built using the same templates and components, testing these representative pages provides broader coverage. Automated accessibility testing can be performed across all pages to identify additional issues.

Scoping is the process of defining exactly what will be audited — which pages, screens, user flows, and components are included — before the audit begins. It’s done for three reasons. First, it ensures the audit covers the areas that matter most to your users and your business, rather than spending time on pages with little impact. Second, it gives you an accurate cost estimate upfront with no surprises — the more we understand the complexity of what needs testing, the more precise our quote. Third, it makes the audit defensible: a well-defined scope means the findings reflect a representative sample of your product, which is important for compliance reporting and VPATs. Scoping is a collaborative process — you know your product best, and we know what makes a thorough, representative audit.

Every accessibility audit is unique. While scoping websites, web applications, and mobile applications, the rule we follow is to identify key user journeys. We also look for recurring templates and components, and check which pages have high traffic. Through this process, we identify the pages for audit, as it is not possible to perform a manual accessibility audit on all pages.

A unique template is a distinct page type with its own layout and interactive elements. For example, on an e-commerce site:

  • Homepage — main landing page with featured products and navigation
  • Category page — product listings with filters and sorting
  • Product detail page — images, pricing, “Add to Cart” functionality
  • Checkout flow — the full purchase journey from cart to confirmation

If your site has 50 product pages that all use the same template, we audit one or two of them. Finding an issue on one tells us the same issue exists across all 50 — and fixing the template fixes them all at once.

Complexity is determined by how many interactive and dynamic elements a page contains. Pages with the following take longer to audit thoroughly:

  • Forms with validation and error messaging
  • Interactive components — dropdowns, tabs, accordions, modals
  • Data visualizations like charts and graphs
  • Carousels, sliders, and media players
  • Dynamic content that updates without a page refresh
  • Multi-step flows like checkout or registration

A simple informational page takes far less time than a complex dashboard. Complexity directly affects the time required and the cost of the audit.

Yes, where relevant. We map how users move through your site to complete key tasks. For example, finding a product, adding it to cart, checking out, and receiving confirmation. This ensures we don’t miss accessibility barriers at critical touchpoints that could prevent someone from completing their goal. If your application includes a multi-step flow like onboarding or an application process, we include the full journey from start to finish (If Required)

In our experience, clients understand their platform better than anyone else. Having a walkthrough call helps clarify things from the start. While evaluating large websites and web applications, identifying the right user journeys and templates is critical. Collaborating with business or marketing teams helps define a scope that aligns with real user behavior and priorities.

ThiTo scope the audit accurately, we typically need:

  • Any existing accessibility documentation, previous audits, or VPATs
  • URLs of all platforms to be audited (website, iOS app, Android app)
  • Test logins and demo accounts for all user roles
  • Access to staging or UAT environments if available, plus any VPN or whitelisting details
  • A list of key user journeys and critical workflows
  • Design system or component library links (Figma, Storybook, etc.) if applicable
  • Technical stack details — React, Angular, Flutter, native, etc.

We review the site and identify commonly used page types — homepage, content pages, blog listing, single post, contact page, product pages, and any modals or navigation components. We then match pages to templates based on layout structure, functionality, and the page builder being used (Elementor, WPBakery, etc.). One representative page is selected per unique template, giving us full coverage without unnecessary repetition.

If the interactions are closely related — for example, a form that triggers a confirmation modal — we treat them as part of the same page. If tabs contain substantial independent content, they may be counted as separate pages. Multi-step flows like checkout or onboarding are always treated as a complete journey and audited end to end, not as isolated pages.

Yes, third-party platforms should be identified and included in the scope. While the client may not have full control over third-party platforms, they are still responsible for the overall user experience. During a WCAG audit, if a third-party platform has significant accessibility issues, we highlight them clearly in the report. The client can then work with the provider to fix the issues or consider alternative solutions.

Screenshots can give us a basic sense of layout and visual elements, which is useful for an initial review. However, a full accessibility assessment requires live, interactive testing — screenshots alone can’t reveal dynamic content behavior, keyboard focus order, screen reader announcements, error handling, or how assistive technologies interact with the page. They’re a helpful supplement, not a substitute for hands-on testing.

Yes. Dark mode doesn’t change functionality, but it does affect contrast and visual accessibility. We verify that text, icons, and interactive elements maintain adequate contrast levels in both modes. Functionality is tested once; contrast and visibility are checked in each mode.

The overall process is consistent — screen identification, screen reader testing, contrast checks, and interaction testing — but we tailor it to each platform’s guidelines and behaviors. Android testing uses TalkBack with Chrome; iOS testing uses VoiceOver with Safari. Platform-specific accessibility APIs, touch target expectations, and navigation patterns are all evaluated against the relevant OS guidelines.

Generally, it is recommended to start the accessibility audit on desktop with one primary screen reader and browser combination. At DigitalA11Y, we use NVDA with Chrome as a baseline, as it provides reliable results during manual testing. However, depending on the project scope and requirements, we also perform validation checks across other browser and assistive technology combinations. Since most elements remain consistent in responsive design, we perform quick checks on mobile using mobile screen readers. In our experience, responsive pages are similar to the desktop version, with slight variations like hamburger menus in navigation, FAQ accordions, etc.

Defining the scope of a WCAG compliance audit follows a structured but practical approach. We start by understanding the platform—whether it is a website, web application, or mobile app. Then we identify key user journeys such as login, signup, search, checkout, and other critical flows.

We also look at unique templates, reusable components, and high-traffic pages. The goal is to ensure that all major functionalities are covered without testing every single page manually. WCAG compliance is evaluated by validating these representative pages and components against the guidelines.

In most cases, we work closely with the client to finalize the scope, as they have better visibility into business-critical flows, user behavior, and priorities. This helps define a scope that is both effective and aligned with real user impact.

As discussed earlier, we prioritize critical user journeys and key template pages in an accessibility audit. Recurring templates and components are included, as fixing them improves accessibility across multiple pages. Pages with very low traffic or duplicate structures may not be tested individually. This approach ensures broader compliance coverage with optimized effort.

Mobile apps and websites look similar on the surface but are architecturally very different products. A website lives in a browser, which itself provides a layer of accessibility infrastructure. A native mobile app is built directly on the platform’s accessibility APIs — UIKit/SwiftUI on iOS, or Jetpack Compose/Android Views on Android — and must be evaluated entirely within that context.

Scoping for a mobile app requires understanding the app’s screen inventory, navigation patterns, platform-specific gestures, and how the app handles system-level accessibility settings like Dynamic Type, display accommodations, or Switch Control. These are questions that have no equivalent in a web audit.

Most clients who come to DigitalA11Y do not initially realize the effort involved in accessibility. It is not just about running automated tools. A significant part of the work involves manual testing, including keyboard navigation, screen reader testing, and validating issues against WCAG guidelines.

This process requires time, expertise, and attention to detail, which is why accessibility audits may cost more than expected.

A typical WCAG audit can cost anywhere from around $1,250 to $2,500 USD for a 10-page audit. However, the actual cost depends on several factors such as the number of templates, pages, components, and the overall complexity of the platform.

Pricing may also vary based on the type of product—whether it is an e-commerce website, web application, simple marketing site, or a mobile app. In most cases, accessibility service providers estimate pricing based on scope and may charge per page or per template.

The cost of an accessibility audit is influenced by multiple factors, including the number of unique templates, complexity of components, type of platform (website, web app, or mobile app), and the depth of testing required.

Other factors such as integrations, third-party components, and timelines can also impact the overall effort and cost.

It depends on the type of product. Some businesses treat accessibility as a one-time effort, especially for small, static websites. In such cases, once the audit is completed and issues are fixed, the ongoing cost is minimal if there are no major changes.

However, for SaaS applications, web apps, and mobile apps, accessibility should be treated as an ongoing investment. Since the codebase evolves regularly, continuous testing and improvements are required to maintain compliance.

 Organizations can reduce accessibility costs by shifting accessibility earlier in the development process (shift-left approach). Making accessibility part of the organization’s culture, driven by leadership, has a significant impact.

Accessibility should be integrated into design, development, and QA processes. By catching issues early, teams can avoid costly fixes later and reduce the overall effort required during audits.

 WCAG compliance means meeting the accessibility standards defined in the Web Content Accessibility Guidelines (WCAG). These guidelines help ensure that digital products are accessible to people with disabilities.

It is important because it improves usability for all users, supports inclusive design, and helps organizations reach a wider audience. It also plays a key role in meeting legal and regulatory requirements in many regions.

WCAG itself is not a law, but it is widely used as the standard for digital accessibility in many regulations across the world. Laws such as ADA in the United States, EN 301 549 in Europe, and other country-specific regulations refer to WCAG as the benchmark for compliance.

So, while WCAG is not directly a law, following it helps organizations meet legal accessibility requirements.

Not conducting an accessibility audit can lead to multiple risks. These include poor user experience for people with disabilities, loss of potential customers, and reputational damage.

There is also legal risk, as organizations may face complaints, demand letters, or lawsuits if their digital products are not accessible. In addition, fixing accessibility issues later in the development cycle can be more expensive and time-consuming.

A WCAG audit helps identify accessibility issues and maps them against recognized standards. This gives organizations a clear understanding of their current level of compliance and what needs to be fixed.

Having an audit report and a remediation plan also demonstrates a good-faith effort toward accessibility, which can be important in legal and compliance situations. It provides documentation that can support organizations during audits, procurement, or legal reviews.

The best approach is to treat accessibility as a continuous process rather than a one-time activity. This means integrating accessibility into design, development, and QA workflows. Regular audits, continuous monitoring, and involving accessibility experts early in the lifecycle help maintain compliance over time.

Accessibility consulting hours can be used effectively by involving experts during key stages such as design reviews, development, and QA. Teams can use these hours to validate new features, clarify WCAG requirements, review components, and get guidance on complex accessibility issues. This helps prevent issues early instead of fixing them later.

This depends on how frequently the codebase changes. If the product is relatively stable, a yearly accessibility audit is usually sufficient. However, if there are frequent updates or new features, it is recommended to perform in-depth WCAG audits every 6 to 12 months, along with auditing new features before they are released.

In ongoing accessibility support services, DigitalA11Y typically offers office hours where consultants work closely with design, development, and product teams on a regular basis. Consultants are available on demand to review new features, validate designs, and provide guidance throughout the development lifecycle

To maintain WCAG compliance after an audit, teams should adopt continuous monitoring using automated crawlers and tools. Accessibility testing should be included during development and QA processes. It is also important to bring accessibility into the design phase and have designs reviewed by accessibility specialists. This proactive approach helps prevent issues from entering production.

Yes, it is recommended to include accessibility testing in every release. This can be done using accessibility linters, browser extensions, and automated testing integrated into CI/CD pipelines. By doing this, teams can catch accessibility issues early and reduce the number of issues reaching production.