WebDX 2026 roadmap #8
Description
The WebDX CG has agreed to the following focus areas for 2026. Each link below searches for issues that match a given label, across the WebDX repositories:
Focus area 1: coordinated research and prioritization
-
Identify broad developer pain points
Continue providing research insights that are collaboratively conducted at a high level to identify and understand the major obstacles developers face when using the Web.
-
Support Interop 2027 prioritization
Coordinate research on features that are already standardized but not yet Baseline to support implementation prioritization.
Provide the Interop 2027 process with reliable and valid data by coordinating the State of CSS, HTML, JS surveys.
-
Maintain and expand mechanisms to collect user signals on existing features throughout the year to ensure prioritization reflects ongoing developer needs.
-
Address the issue that available surveys underrepresent women, which calls into question their predictive power.
Actively work to increase the demographic share of women respondents to 20% across coordinated surveys.
Focus area 2: enriched developer guidance
-
Integrate accessibility into feature status
Incorporate Accessibility Compat Data (ACD) into the web-features ecosystem.
Establish clear indicators for features that may technically "work" in a browser but fail with assistive technologies, potentially affecting their Baseline eligibility or strictly warning developers.
-
Expose data regarding the immediate roadmap of features to help developers predict availability. This includes visualizing partial implementations, "Intent to Ship" messages, and active implementation commits.
Provide estimated timelines or confidence levels for when specific features are expected to become Baseline.
-
Clarify Limited Availability with vendor positions
Differentiate between features that are merely "new" and those that are stalled.
Explicitly expose negative vendor positions (e.g., "Will not implement") alongside status data so developers know if a feature in "Limited Availability" is unlikely to ever progress to Baseline.
-
Enable guidance for progressive enhancement
Develop data structures to highlight when a non-Baseline feature is safe to use as a progressive enhancement.
Add specific descriptors for features that are platform-specific (e.g., mobile-only) or where partial usage is viable, ensuring developers don't block large portions of the platform based on a binary status.
Focus are 3: data completeness and granularity
-
Conduct a systematic audit and mapping of the thousands of compatibility keys (BCD) currently not associated with any web-feature entry to ensure the dataset represents the entire platform, not just high-profile features.
-
Enforce structural consistency
Implement automated linting and validation rules to prevent mismatches between compat_keys and compute_from logic.
Require specific documentation notes for any feature that must deviate from standard computing logic.
-
Develop and document a standardized process for splitting and merging features to reflect changes in browser implementations (e.g., when browsers ship different subsets of a specification).
Focus are 4: aligning standards/specs and implementation
-
Integrate with standards workflows
Provide hooks for Working Groups to mark issues or Pull Requests with web-features IDs early in the process.
Monitor standard bodies' activities to trigger the creation of feature entries before shipping.
-
Create mappings between web-features and horizontal review trackers (Accessibility, I18n, Privacy).
Ensure that features shipping before reviews are complete are clearly identified to prevent ecosystem fragmentation.
-
Shift tracking from "Spec Stability" to "Feature Stability" to accurately reflect the usability of specific capabilities (e.g., similar to Media Capabilities) rather than entire documents.
Link tests more naturally with specification updates to catch interoperability bugs (like anchor-positioning issues) earlier in the standardization process.
See also: