Skip to content

Latest commit

 

History

History
25 lines (13 loc) · 2.27 KB

adr-019.md

File metadata and controls

25 lines (13 loc) · 2.27 KB

ADR 19: Keep layout information optional

Context

As per ADR 18, Alfa will receive layout information as input to its audit, without considering how it was built.

Most data producers involve rendering the page in a browser and can therefore easily add layout information to the mix. However, there are still many that do not involve browsers and have harder time producing layout. This notably includes our own JSX syntax, pre-rendering systems such as React, or abstract DOM manipulations without CSS such as Cheerio.

Additionally, layout information provided as input is tied to a specific device and context. Several checks need to inspect the page with a different one. E.g. to test whether a skip link is visible when focused (while it may be moved offscreen when unfocused), or compare the page between several orientations of the device. It is not realistic to require callers to provide layout information for all these cases upfront, especially since the caller shouldn't be required to know which devices and contexts the audit will try and use.

Decision

We will keep layout information optional.

Status

Accepted.

Consequences

Data producers will be able to skip layout information if they want, at the cost of having a less accurate audit. Most notably, we will still be able to write JSX without layout data for our own unit tests; since most of our unit tests do not involve layout, this removes the need for a lot of boilerplate code in tests.

Changing device or context during an audit will be possible. Some checks might be less accurate with the new device or context due to the lack of layout information for these, but these checks would be altogether impossible if layout was mandatory.

We must, however, keep heuristics for every check that uses layout information. These heuristics are often complex, and getting more and more complex due to finding more corner cases that are not correctly handled. We must, nonetheless, keep maintaining them and refining them. Notably, these heuristics are still used when checking with a different device or context, therefore we cannot degrade them to simpler version and must keep them as accurate as possible. This puts some burden on the development team to maintain both versions of checks (with or without layout).