Depends on the accessibility gate issue and on #63.
The timing budget in #35 measures a throttled mobile profile, which is a
statement about how long the page takes and none at all about whether it is
readable when it arrives. The audit in #36 runs at whatever viewport the harness
opens with, so a page that requires a desktop width passes it. Nothing in the
plan says the pages have to work on a narrow screen or at enlarged text, and
nothing checks it.
That is a strange gap for this project in particular. The reason the clients
exist is a phone and a television, and the site that explains them opening as a
page somebody has to scroll sideways would say more than any paragraph on it.
Two failures, both decidable by a machine, and both invisible to the checks
already planned.
Reflow. The page is loaded at 320 CSS pixels wide and nothing overflows the
document horizontally. That width is the narrow end of real phones, and it is
where a fixed width in a table, a code block or an image stops being a style
choice and starts hiding content off the side of the screen. Sideways scrolling
of a single element that has to be wide, such as a long command, is allowed and
named as such rather than caught as an accident.
Text scaling. The page is loaded with text at twice its size and no content is
clipped, overlapped or cut off by a container that was sized for one line. This
is the failure a reader who enlarges text meets on most sites, and it is caused
by fixed heights rather than by anything visible at the default size.
Both run in the same headless browser #63 pins, over every produced page, with
the same rule about honesty: a browser that cannot start reds the run and never
passes it, and a run that did not execute these legs prints that it did not
rather than printing nothing.
The width and the scale factor are read from the same file the byte budget
numbers in #34 come from, so the design system page states the numbers the check
enforces rather than a second set that agrees today.
Done when
Every produced page is loaded at 320 CSS pixels and at twice the default text
size in the headless browser; a deliberately fixed-width element reds the run and
the failure names the page and the element; a deliberately fixed-height container
that clips enlarged text reds the run; an element allowed to scroll sideways is
declared as such in the check rather than tolerated by the absence of a rule; a
browser that is present and cannot start reds the run; and the width and scale
factor come from the same numbers file as the byte budget.
Depends on the accessibility gate issue and on #63.
The timing budget in #35 measures a throttled mobile profile, which is a
statement about how long the page takes and none at all about whether it is
readable when it arrives. The audit in #36 runs at whatever viewport the harness
opens with, so a page that requires a desktop width passes it. Nothing in the
plan says the pages have to work on a narrow screen or at enlarged text, and
nothing checks it.
That is a strange gap for this project in particular. The reason the clients
exist is a phone and a television, and the site that explains them opening as a
page somebody has to scroll sideways would say more than any paragraph on it.
Two failures, both decidable by a machine, and both invisible to the checks
already planned.
Reflow. The page is loaded at 320 CSS pixels wide and nothing overflows the
document horizontally. That width is the narrow end of real phones, and it is
where a fixed width in a table, a code block or an image stops being a style
choice and starts hiding content off the side of the screen. Sideways scrolling
of a single element that has to be wide, such as a long command, is allowed and
named as such rather than caught as an accident.
Text scaling. The page is loaded with text at twice its size and no content is
clipped, overlapped or cut off by a container that was sized for one line. This
is the failure a reader who enlarges text meets on most sites, and it is caused
by fixed heights rather than by anything visible at the default size.
Both run in the same headless browser #63 pins, over every produced page, with
the same rule about honesty: a browser that cannot start reds the run and never
passes it, and a run that did not execute these legs prints that it did not
rather than printing nothing.
The width and the scale factor are read from the same file the byte budget
numbers in #34 come from, so the design system page states the numbers the check
enforces rather than a second set that agrees today.
Done when
Every produced page is loaded at 320 CSS pixels and at twice the default text
size in the headless browser; a deliberately fixed-width element reds the run and
the failure names the page and the element; a deliberately fixed-height container
that clips enlarged text reds the run; an element allowed to scroll sideways is
declared as such in the check rather than tolerated by the absence of a rule; a
browser that is present and cannot start reds the run; and the width and scale
factor come from the same numbers file as the byte budget.