Having decided on ADR 2, we will no longer be tied to any one specific browser and are left with the choice of what to do about things that browsers are not aligned on. For example, if Alfa needs to implement an API to perform a given task, and a given set of browsers do not agree on how the API should be implemented, Alfa can do several things:
-
Implement the API the way it is implemented in the least capable browser, in terms of support for the API, among a given set of browsers.
-
Implement the API the way it is implemented in the most capable browser, in terms of support for the API, among a given set of browsers.
-
Provide several implementations of the API that cover all the different implementations of the API among a given set of browsers.
Our proprietary accessibility conformance testing engine at Siteimprove takes the second approach in practice as it is usually run within the latest version of the Chrome browser and relies heavily on browser APIs. Other tools that operate with the concept of an accessibility support baseline will typically take a combination of the first and second approach where some browser APIs are used and then others implemented manually according to the capabilities of the accessibility support baseline.
The quality shared by the first and second approach is that they both produce just a single implementation of the API, though with potentially different capabilities. However, both approaches suffer from the fact that depending on how the API is implemented, an accessibility issue could be found in either the least or most capable browser, while being missed in the other. For example, a contrast issue might appear in a less capable browser that does not support a specific color format, while the contrast would be perfectly fine in a more capable browser that does support the specific color format. The third approach avoids this issue entirely by implementing the API in all possible ways for a given set of browsers.
We will take the third approach described in the previous section and incrementally adopt it throughout Alfa where it makes sense. To do so, we will introduce the concept of browser specific values that model abstract values that can take on multiple concrete values across different sets of browsers. This way, any API that we may want to implement can either return just a single value or a set of browser specific values in the case where the API would behave differently in different sets of browsers.
To decrease the complexity of working with browser specific values, we will implement them as monads and expose a set of operations that allow consumers to perform computations on browser specific values without having to worry about whether they take on one or multiple concrete values.
Accepted. (but not used currently)
By providing a building block for modelling browser specific values, we are in a position to substantially increase the usefulness of Alfa for individuals and organisations that need results for not just a single browser but a range of browsers, old or new.
The onus is of course on us, the Alfa development team, to account for misalignment between browsers and to constantly stay on top of it. We must be pragmatic about when and where to account for browser misalignment and find a balance between complexity added and value provided.