Baseline browser compatibility audit for AI-built websites

Web Platform Baseline can help a team decide whether front-end features are ready for interoperable use across major browsers. Web.dev distinguishes support limited to some browsers, Newly available status when a feature is supported across the core set, and Widely available status after 30 months have passed from that interoperability point. The listed core set covers Chrome on desktop and Android, Edge, Firefox on desktop and Android, and Safari on macOS and iOS.

For an AI-assisted website, the useful decision is not whether generated code looks convincing in one preview. It is whether each material feature fits the project’s browser policy and whether critical journeys pass reproducible tests. Baseline supplies standardized feature-level compatibility evidence. CreatikLab’s operational interpretation is to place that evidence inside a broader release process covering behavior, accessibility, integrations, data delivery and business-critical conversions.

Web.dev identifies the Chrome team as the initiator of Baseline and the WebDX Community Group as the group that now defines it. Baseline is intended to make browser-support information easier to interpret when developers choose platform features or assess libraries. A capability that has not reached interoperability across the core set may remain classified as supported in only some browsers. Widely available adds the documented 30-month interval after interoperability.

The official page also identifies relevant tooling. Lighthouse can report the Baseline status of web features detected on a page. Browserslist supports Baseline queries, Visual Studio Code surfaces Baseline information, and the web-features package can supply data for custom tools. Web.dev also presents Baseline information in Chrome DevTools and a Baseline Checker that can use Google Analytics data to inform target selection. None of these feature-level signals establishes that a complete site or commercial journey works correctly.

AI can accelerate the production of components, styles and interactions, but speed changes the review burden rather than removing it. Generated code may introduce a platform feature without documenting why it was chosen, which environments were considered or what fallback exists. The commercial risk appears later if a form control, menu, checkout step or account workflow behaves differently for part of the audience and the team has no acceptance record explaining the decision.

CreatikLab therefore separates code generation from code acceptance. The author of a change, whether human or automated, is not the final authority on compatibility. Acceptance requires an inventory of relevant features, a declared support target and journey-level evidence. Baseline helps classify the feature inventory, while accountable owners decide whether a Newly available feature is appropriate, whether progressive enhancement is required or whether a more established implementation is preferable.

• Generation question: can the component be produced and integrated?
• Compatibility question: what is the Baseline status of its material features?
• Product question: which browsers, devices and user contexts must the journey support?
• Release question: what reproducible evidence demonstrates acceptable behavior?

The following matrix is a CreatikLab decision framework, not a Google product rule. It converts a feature status into an auditable engineering choice while treating commercial criticality as a separate variable. A decorative enhancement and a lead form should not receive the same risk treatment merely because they use the same technical feature.

• Widely available with non-critical use — evidence: Baseline report and normal regression tests; action: use unless project constraints disagree; owner: front-end lead.
• Widely available in a critical journey — evidence: Baseline report and browser-specific journey tests; action: release only after functional acceptance; owners: engineering and quality assurance.
• Newly available — evidence: exact feature inventory, browser policy and fallback test; action: adopt deliberately, progressively enhance or replace; owners: technical lead and product owner.
• Supported only in some browsers — evidence: affected environments and user impact; action: avoid in the critical path unless a tested alternative exists; owners: architect and quality assurance.
• Unknown or unresolved status — evidence: manual compatibility research and device tests; action: block automatic approval until reviewed; owner: designated compatibility reviewer.

The decision rule is proportional: the more commercially important the journey and the less mature the interoperability status, the stronger the fallback and test evidence must be. Baseline does not define the business threshold for a particular website. The delivery team must document that threshold, connect it to user and contractual needs, and obtain approval from the product owner.

1. Define the supported browser and device policy from audience evidence and contractual requirements. Do not silently substitute the Baseline core set for the project’s own policy.
2. Map critical journeys such as lead submission, authentication, purchase, booking or account management. Record the expected result and the downstream system that confirms completion.
3. Run the Lighthouse Baseline audit on representative pages and retain the report with the tested build. Use it to discover features requiring review, not as an automatic pass.
4. Use Browserslist Baseline queries where they fit the build pipeline. Document the chosen target so local development and continuous integration apply the same rule.
5. Inspect flagged or strategically important features. Classify each as Widely available, Newly available, supported only in some browsers or unresolved.
6. Choose a response for every exception: retain, replace, progressively enhance, provide a fallback or constrain the experience. Record the reason instead of accepting an automated fix without review.
7. Test critical journeys on the required browser and device combinations. Capture the environment, steps, expected behavior, observed behavior and supporting evidence.
8. Add regression checks, assign an owner to each exception and repeat the review when dependencies or material interface code change.

The official documentation does not prescribe this delivery sequence. It is CreatikLab’s implementation method for turning Baseline data into accountable release decisions. The desired output is a traceable chain from feature detection to user impact, remediation, retesting and acceptance, rather than an isolated compatibility score.

Compatibility work should not be reported only as a count of warnings removed. For a lead-generation website, define successful completion of the important journey and verify that the same conversion event is recorded consistently across supported environments. A qualified lead must be defined in business terms, such as acceptance by sales under documented criteria, rather than inferred from every form submission.

• Technical layer — feature, Baseline status, browser, device class, test result, error evidence and release identifier.
• Journey layer — start, validation, submission, confirmation and downstream receipt of the enquiry.
• Data layer — consent state, campaign parameters, duplicate handling and delivery to the intended CRM or operational system.
• Commercial layer — accepted lead, rejected lead with reason, opportunity progression and feedback owner.
• Change layer — compatibility exception introduced, reviewer, condition for removal and regression result.

The measurement record should let a reviewer reproduce both the technical test and the business verification. For example, a successful form test should show that validation behaved correctly, the confirmation state appeared, the intended system received the record and the team could distinguish a test submission from a genuine enquiry. Browser information must not be used as a substitute for consent or as proof of lead quality.

Baseline itself does not report leads, revenue or conversion quality. It contributes compatibility evidence. CreatikLab’s measurement approach joins that evidence to first-party journey and CRM validation while keeping the concepts distinct. A release can be technically compatible and commercially ineffective; it can also generate demand while hiding a browser-specific failure that requires correction.

• Do not assume Widely available means bug-free. It describes the maturity of platform support, not the correctness of a particular implementation.
• Do not assume the Baseline core set represents every browser, webview, assistive technology or device used by the audience.
• Do not assume a Lighthouse result validates authentication, forms, payments, CRM delivery, analytics or third-party scripts.
• Do not assume Newly available means unsuitable. It means the adoption decision needs context and proportionate testing.
• Do not assume an AI-generated fallback is accessible, maintainable or behaviorally equivalent without inspection.
• Do not convert the 30-month Widely available threshold into a promised support lifetime. It is a classification milestone, not a service guarantee.

Policy drift is another material risk. One developer may target Widely available features while another accepts anything that works in a local browser. Dependencies can also introduce features outside the intended policy. Controls include a versioned support policy, automated discovery where practical, explicit exceptions, retained acceptance evidence and regression tests attached to critical journeys.

Baseline should not be used to infer a price, delivery scope, commercial result, performance improvement or eligibility rule. Those matters require a separate scope based on the actual website, its dependencies, its users and its defects. A clean feature report also cannot prove accessibility conformance or visual consistency because those questions require their own evidence.

A buyer commissioning this work should ask for more than a compatibility score. An inspectable audit package can be specified to include a browser-support policy, a page and journey inventory, retained Lighthouse Baseline artifacts, a feature-risk register, reproducible defect evidence, remediation priorities, named owners, exception decisions and regression acceptance results. Any implementation scope should separately identify the proposed code changes, fallbacks, pipeline controls and validation required for critical lead-generation or commerce journeys.

Provider comparison should focus on evidence: Which features will be examined? Which environments will be tested? How will exceptions be approved? What will demonstrate that a lead reached the intended downstream system? Who will own regression after release? These questions distinguish an accountable release process from a generic cross-browser claim.

Review CreatikLab’s automation and AI service for custom web systems, then send Lia the website, supported audience, stack and failing journey. Ask Lia to assess fit and scope a concrete expert deliverable: a compatibility decision brief covering the target browser policy, critical journey inventory, required evidence and proposed acceptance criteria. Lia can confirm the appropriate next step after reviewing the actual system and requirements.

What does Web Platform Baseline tell a delivery team?

Baseline indicates whether a web-platform feature has become interoperable across the core browser set defined by the WebDX Community Group. It distinguishes features supported only in some browsers, Newly available features and Widely available features.

Does a Baseline label prove that a complete website works?

No. It describes support for individual web-platform features, not the correctness of an entire journey. Teams still need functional, accessibility, visual and integration testing on the browsers and devices relevant to their users.

What does Widely available mean?

Web.dev states that a feature becomes Widely available after 30 months have passed since it became interoperable across the core browser set. That status is a compatibility signal, not a guarantee for every device or embedded browser.

Which browsers are in the Baseline core set?

The set listed by web.dev includes Chrome on desktop and Android, Edge, Firefox on desktop and Android, and Safari on macOS and iOS.

Can Lighthouse detect Baseline status?

Web.dev describes a Lighthouse audit that identifies web features used on a page and reports their Baseline status. It should be combined with journey-level testing rather than treated as the only release gate.

How should a buyer compare providers for this work?

Ask for an inventory of reviewed features, reproducible test evidence, a browser-support policy, named remediation owners, regression controls and acceptance criteria tied to important user journeys. A generic claim of cross-browser compatibility is not enough.