web-platform-tests · zcorpan · Feb 3, 2026 · Jun 3, 2025 · Jul 3, 2025 · Jul 23, 2025
diff --git a/rfcs/tentative_testdriver_methods.md b/rfcs/tentative_testdriver_methods.md
@@ -0,0 +1,31 @@
+# RFC 226: Tentative testdriver methods
+
+## Summary
+Allow tentative methods to be added to testdriver.js which use WebDriver endpoints not yet defined in a specification.
+This should only be allowed where there is consensus between multiple browser vendors and where there is clear progress towards a specification.
+
+## Background
+As part of the [Interop 2025 Accessibility Investigation Area](https://github.com/web-platform-tests/interop-accessibility/issues/148), the intention is to extend browsers and WPT to allow additional accessibility properties to be tested by web platform tests.
+However, there are open questions regarding the shape of the API for exposing these properties, what properties should be exposed, how the tests should be written, etc.
+While the end goal is to extend the WebDriver specification with the required new endpoints, these open questions need to be answered before this is feasible.
+To answer these questions, it would be helpful if browser vendors could collaborate on a tentative but working implementation.
+
+## Details
+1. There must be publicly documented (e.g. as part of an Interop Investigation Area) consensus between at least two browser vendors and intent to work towards a specification.
+2. Any tests directly or indirectly calling tentative testdriver methods must be [marked tentative](https://web-platform-tests.org/writing-tests/file-names.html#:~:text=.tentative,-:%20).
+3. These testdriver methods should assert that the test is tentative (URL path includes `.tentative' or '/tentative/'). 
+
+## Alternatives considered
+1. Avoid any changes to the WPT repository until the specification is finalised.
+  This makes it very difficult for browser vendors to collaborate and to learn about problems that are much easier to discover and understand "in practice".
+  In contrast, if the specification were developed without a working implementation, there is a much higher risk of fundamental design problems in the specification which are much harder to fix later.
+2. Develop the implementation as vendor specific tests with methods in testdriver-vendor.js.
+  While this does allow a single vendor to iterate on a working implementation, it is still very difficult for multiple browser vendors to collaborate on this.
+  At the very least, other vendors may wish to contribute tests which exercise the implementation to ensure it fits their needs before agreeing to a final specification.
+
+## Risks
+1. Methods could be added which never end up being specified, resulting in cruft and non-standardised functionality.
+  This is not a significant risk to the web at large because these methods only impact tests and the tests must be marked tentative, preventing them from being considered for Interop scoring, for example.
+2. The API could change significantly before it becomes finalized, with many tests depending on the tentative API.
+  This could mean that migrating the tests to the final API requires significant effort.
+3. Because of the lack of specification, other vendors interested in ensuring interoperability with the feature being tested might have to reverse engineer how the tentative API is intended to function.