It began, as many things do, with a silly conversation. In this case, I was talking with our Front End Technology Competency Director (aka “boss man”) Mundi Morgado.
It went something like this…
Mundi Morgado I want you to build a visual screen reader.
Nathan Smith Who what now?
Mundi Morgado I want a CSS library that allows you to see the structure of a document. It shouldn’t use class so that you’re forced to focus on semantics. Also, make it theme-able.
Nathan Smith Sure, let me see what I can come up with.
Fast-forward a week, and we’ve got what we are now calling:
Construct.css: The throwaway CSS library with no class
Why throwaway? Well, it’s not really meant to be a fully fledged, production-ready style framework. Rather, it’s like training wheels for document semantics, with some bumper lanes (think: bowling) to keep you on the right track.
It’s part of our ongoing effort at TandemSeven to promote code literacy throughout our organization. As more of our UX designers are beginning to share responsibility for the accessibility and semantics of a project, it makes sense that we would build in such a way that allows UX and development to be more collaborative.
There are four main aspects to Construct.
Construct: “Basic”
First is the base Construct.css file, which applies a passably basic look and feel to the majority of common HTML elements. Check out this example of a basic page.
Construct: “Boxes”
Second, there is construct.boxes.css. This visually distinguishes otherwise invisible semantic elements, such as: header, main, nav, etc. That way, one can see where those elements are (or aren’t) as a page is being authored. Here’s a page with semantic boxes outlined.
Construct: “Theme”
Thirdly, theming is possible via construct.theme.css. This is mostly just an example — inspired by PaperCSS) — of how to make UI look “hand drawn,” to prevent observers from being too fixated on the look and feel, rather than the semantics of a document. Here’s the example theme in action.
Construct: “Debug”
Lastly, there is a construct.debug.css file that highlights and calls out invalid and/or problematic markup. Here’s a gnarly example of “everything” going wrong on a single HTML page. This was inspired by a11y.css, though it diverges in what is considered noteworthy.
For instance, we call out “div-itis” when multiple div:only-child have been nested within one another. We’re also opinionated about type=checkbox being contained inside of a

tag to have a dashed border, and to have its tag named displayed the top left corner.
section {
border: 1px dashed #f0f;
display: block;
margin-bottom: 2rem; /* 20px. */
padding: 2rem; /* 20px. */
position: relative;
section > :last-child {
margin-bottom: 0;
section::before {
background: #fff;
color: #f0f;
content: section;
font-family: Courier, monospace;
font-size: 1rem; /* 10px. */
letter-spacing: 0.1rem; /* 1px. */
line-height: 1.3;
text-transform: uppercase;
position: absolute;
top: 0;
left: 0.3rem; /* 3px. */
Warning messages (using ::after)
Likewise, here’s a snippet of code from the construct.debug.css file that drives the markup warning messages. This particular example causes