Application layer

Shell

Eight files, one grid. src/app/shell-frame.css owns the areas and nothing that sits in them; each region claims its own area from its own file, so a product with no inspector pays nothing for one. The frame normally claims the viewport, because the regions scroll inside themselves rather than the document scrolling under fixed chrome. The example below is pinned to a fixed height with bs-h-var, which is the framework's own escape hatch for a one-off measurement, and contained so the phone drawers stay inside it.

Drag either divider. Above 64em the panes are in the flow and resizable; below it they are off-canvas drawers that open on :target, which is why the toggle in the topbar is an anchor to the pane's own id and works with no script at all.

A pane is resizable and collapsible, and in the product this layer came out of those two fought: the resizer wrote style="inline-size: 320px", an inline declaration outranks every cascade layer, and from the first accidental grab of a divider the collapse class could never win again. The fix is not a stronger selector. A drag writes exactly one custom property, --bs-pane-size; the stylesheet derives --bs-pane-used from it inside a clamp; and the collapse rule re-declares the derived property, which the drag never writes. Two different properties, so there is no cascade contest to lose.

src/app/shell-tabs.css is the strip of open documents above the toolbar, and it is not src/nav/tabs.css: those switch between panels of one page, these are the things the user opened, they close, and there can be dozens. The close control is a sibling of the tab and never nested inside it, because a button inside a button is invalid and the inner control swallows the key that should have activated the tab.

Command

Six files for the surfaces an application uses to find and narrow what it holds. Every tool shipping this year has a palette and none of the CSS frameworks provide one, which is why the first of them is here.

Palette

Press the button. It is a real <dialog> opened with showModal(), which is where the focus containment, the inert background, Escape and the backdrop come from; none of those are written by this framework and none of them are lost when the module fails to load. Arrow up and down once it is open, then keep typing: focus never leaves the input, the marker moves, and the input tells the accessibility tree which option is marked through aria-activedescendant.

The module does not filter. What matches a query is the application's question and every product answers it differently, so the module moves the marker over whatever options are in the DOM at that moment and the list is yours to rebuild between keystrokes. Selection is aria-selected and nothing else: there is no internal index, so a consumer who re-renders cannot desynchronise it.

Search

The search field an application ships rather than the one a website ships. It carries the scope the search is confined to as a real button, offers what was searched for before, and its empty result is a suggestion rather than an apology. The panel is normally hidden with the hidden attribute and script drops it; it is left open below so it can be read.

The scope is a button and not a prefix inside the input. A scope rendered as text the user has to backspace through gets deleted by accident and cannot be announced. Its name carries both the scope and the verb, because the visible word alone announces as "Runs" and gives no clue that pressing it removes anything.

Chips and the filter bar

A chip is one facet with two states and a press target, which makes it a toggle button rather than a link or a checkbox with a label glued over it. Press them. The check mark is present when the chip is on and absent when it is off, so the two states differ in shape before they differ in hue, which is what keeps them readable in forced colors where the tint is discarded entirely.

The count is a live region, and it belongs to the filter bar because the filter bar is what caused the change. Filtering moves nothing and takes no focus, so a reader who is not looking at the list is otherwise given no signal that anything happened. Clear all is always present and disabled when there is nothing to clear, rather than appearing and disappearing and reflowing the row under the pointer.

Sort

Two decisions, so two controls. A single button cycling through six states is a button nobody can predict. The key is a native select, which is one element, keyboard operable everywhere, opens as the platform's own picker on a phone and needs no script; the direction is a toggle whose accessible name says which way the sort now runs, because an arrow that flips with no name change announces the same thing in both states.

One arrow, turned rather than swapped. A rotation is one element, one transform and no second SVG to keep in step, and under prefers-reduced-motion it stops turning and simply is in the right place, which was the state that mattered.

The empty result

"No results found" tells the reader a fact they already have. Three parts, all load bearing: the title names what was searched and where, the body says what that scope actually contains, and the ways out are real buttons in the tab order rather than an underlined phrase in a sentence.

Start aligned rather than centred. This block appears inside a result list, a palette or a pane 14rem wide, and centred text in a narrow column gives every line a different leading edge, which is measurably slower to read and looks like a placeholder. There is no illustration slot for the same reason: the space belongs to the sentence.

Controls

Eight files that sit on top of src/forms/button.css rather than replacing it. That file owns the box, the fills and the disabled paint; these own what the box does while a request is in flight, what it looks like when its whole label is a glyph, and what happens when two buttons have to read as one object.

The state machine

One attribute, so two states can never be on at once, which is the failure a pair of modifier classes invites. data-state takes idle, loading, success, error, optimistic and rollback. All four below are held open so they can be looked at; a real page sets the attribute and writes a sentence into the live region.

The four buttons are the same width, and that is the requirement rather than a coincidence. The label stays in flow in every state and keeps the box the width it was; it loses opacity, not its box, and every mark is out of flow and centred over it. A control that grows when it starts working moves itself out from under a finger that is already travelling toward it. The marks are currentColor and not green and red, because green on the iris fill has no measured pairing; --tint opts a neutral-fill button into hue as well.

Copy

Press it. The value goes to the clipboard, the mark morphs into a tick and the word does not change, because "Copied" is wider than "Copy key" and the button would resize under a pointer already pressing it. The sentence a screen reader gets goes to the live region, where it costs no layout at all. Every copy control on this site, including the ones in the card headers above, is this component driven by site/site.js.

Icon button

The one thing every implementation of this gets wrong is the target. A 16px glyph with 4px of padding is a 24px box, which is the SC 2.5.8 minimum and nothing over it, and on a phone it is missed as often as it is hit. Here the visible box stays as small as the design wants and an invisible overlay reaches out from it to the target size, so a row of them needs a gap of at least twice the reach or the two targets fight over the middle. Press between the two below and nothing happens, which is the gap doing its job.

The name is on the control and never on the SVG, and the SVG is hidden from the accessibility tree because it is not a second piece of information. "Edit this run" and not "Edit": a screen reader user listing the controls on a page gets each name out of its context.

Segmented

One of a small set, shown as one object. Exactly one member is on, so the members are radios and not buttons: a row of buttons cannot express "one of these is chosen" to assistive technology, and a fieldset of radios gets arrow-key roving from the platform for nothing. Arrow through it and watch the thumb follow, which it does with no script: the rules read which option is checked with :has() and translate the thumb by whole multiples of itself.

On an engine without :has() the index falls back to whatever the server rendered into --bs-segmented-index, so the correct segment is still highlighted, it just does not slide. Short labels only: every segment is the same width, which is what makes the thumb arithmetic work, and a set of long ones wraps at 320px and is the signal that the choice wanted a select instead.

Toggle group and split button

A toggle group is a row of independent on and off controls, which is not a button group (alternative actions) and not a segmented control (exactly one on). aria-pressed="false" is written out on the unpressed ones rather than omitted, because a button with no aria-pressed at all is announced as an ordinary button and half the row would stop being a toggle. The split button is two real buttons that look like one object: a single button that opens a menu when pressed near its trailing edge is not operable from a keyboard and cannot be described at all.

The toggle mark is a ring that grows a dot, so on and off differ in shape before they differ in hue, and it is in the flow at a fixed size in both states so toggling never changes the width of the button. The split button's second half needs its own accessible name: "Deploy options" and not "More", because More is every button on every page once the name is read out of context.

Theme

Light and dark, in the two shapes a product needs: a button for the bar, and a picker for a settings panel. Both controls below are live and both drive this page, so pressing either one changes what you are reading. Three states and not two: pinning a theme writes .theme-light or .theme-dark on the document element, which beats prefers-color-scheme in both directions, and clearing the pin hands the page back to the operating system. Following the system is a state, so it gets an option rather than being the thing that happens when you have not chosen.

The button's name is "Dark theme" in both states and never changes. Swapping it for "Light theme" once pressed resizes the control under the pointer that just pressed it, and leaves a screen reader user unable to tell whether the word is what they have or what they would get; the name states what the button turns on and aria-pressed states whether it is on. What moves is the mark, and it moves in shape rather than in hue - half a disc for light, a whole one for dark - so the state survives a monochrome display, a printout and forced colors. bs-theme-toggle--compact clips the word where a bar is tight and returns it at 768px, which is what keeps the button out of a second row at 320px without an aria-label repeating the same string.

src/behaviour/theme.js owns the storage key, the class, the sync and a prefers-color-scheme listener that moves a page following the system and leaves a pinned one alone, and it announces every change as bs-theme:change for anything that cannot follow a custom property. The key holds one of three values and light is what an absent key means, so a reader who has chosen nothing gets light rather than whatever their operating system happens to ask for, and following the system is the third option rather than the state you land in. The one part the module cannot do is the first paint: a theme read after the stylesheet has painted is a theme you watch arrive, so its header carries a short blocking snippet for the head, above the stylesheet links. This page runs it, which is why there is no flash here.

Floating action, and install

The one action a screen exists for, pinned where a thumb can reach it. It is position: fixed against the viewport in a real page, so the demo below sits in a contained box rather than floating over this documentation for the rest of your visit. The install row is the other end of the same idea: a deep link per editor, each of which also copies the configuration, because a custom-scheme link that no application has registered fails silently and leaves the reader believing an install happened.

npx -y -p @barebase/style bare-style-mcp

A pinned box sits on top of the end of the content, so a page carrying one owes it clearance: --bs-fab-clearance is the number to read into scroll-padding-block-end, and it already includes the safe area inset. The extended form with a word in it is a variant and not a state, because a control that grows a label on scroll animates its own width, which this framework does not do.

Pickers

Seven controls that every application builds and no CSS framework ships. Each one is built around a real form control rather than in place of one, which is the difference between a control that degrades and a control that disappears when a request for a script fails.

Combobox

A text input that owns a filtered listbox. The value has to be one of the options, so there is a selected option, an active option and a commit. Type into it: the list narrows, the count is announced, and focus never leaves the input, which is what keeps the caret alive and the next keystroke going into the field.

The markup ships a native select holding every option and an enhanced block carrying the hidden attribute. The module swaps which one is hidden, moves the id across so the label names the control the reader is now in, and writes every choice back into the select so the form still posts the same name with the same value. Remove the script and the select is still there, still named, still submitted: the fallback is the same element rather than a second implementation to keep in step.

Two states, not one, and one of them is an attribute for a reason. aria-selected marks the option that is the value; aria-activedescendant on the input names the option the arrow keys are on. No selector can follow an IDREF, so data-bs-active is that same fact in a form the cascade can see. The IDREF is what an assistive technology reads and the attribute is the paint.

Multiselect

A box holding the values already chosen as chips, with a text input on the same line for adding the next one. Type a tag and press Enter. Then put the caret in the empty field and press Left: the tokens are walked from the field, so eleven chips are one tab stop instead of eleven. Backspace in an empty field steps onto the last token rather than deleting it, and the second press removes it and announces the removal.

The row wraps and never scrolls sideways. A horizontally scrolling token row hides the values a user already chose behind a gesture that does not exist on a keyboard, and at 320px it hides most of them. What the form actually submits is the hidden multiple select: a div does not post, so without it the chips are decoration.

Stepper and rating

Almost every stepper is laid out from its content, so 9 becomes 10, the box grows a character, and the buttons move out from under the finger pressing them. Hold the plus below through the tens and nothing moves: the field is sized in ch from a hook and the value is tabular. The rating beside it is five radio inputs and a sixth for no rating, because a radio group cannot be emptied from the keyboard once a member is chosen and "click the chosen star again" has just made the mouse the only way to undo.

The stepper's buttons are in the tab sequence and each carries a name that says what it does to what: "One more seat", not "Increment" and certainly not "+", which announces as "plus" or as nothing at all. Its module only wires the two buttons to stepUp and stepDown, which is the one thing a button cannot do on its own, so a page shipping no script should ship no buttons and keep the number field. The rating has no module at all: a radio group already roves with the arrow keys, announces "3 stars, radio button, 3 of 5", and posts with the form.

Colour field

A swatch that opens the platform picker, and a text field holding the same value as hex. The hex field is not an extra, it is the keyboard path: what happens inside the operating system's colour picker is not the page's to fix, and on some platforms there is no keyboard route to a precise value at all. It is also the only form of the value a screen reader can read out.

A rejected value is not an error. The visitor is mid-typing and "#5b5" is three keystrokes from correct, so the hex field takes aria-invalid, the edge says so, and the last good colour stays applied: nothing is reverted under the caret and nothing shouts. Use src/app/colour-lab.css instead when the colour being chosen is a theme that has to stay legible; that panel is on this page already, in the corner.

Dropzone

Built around the real file input, never in place of it. The usual drop area hides the input with display: none and paints a div, which removes the only control on the page a keyboard can operate and the only one a screen reader can announce as "Choose file, button". Here the input stays visible, stays focusable and stays the thing that opens the picker; drag is the shortcut laid over it, which is also what SC 2.5.7 asks for.

Five states on one attribute, so a consumer sets one thing and nothing gets out of step: data-bs-state is idle, dragging, rejected or uploading, and hover is the pointer's own business. Only dragging needs script at all, because dragover is an event and not a selector. A rejected file gets a sentence in a role="alert", not a red border: which file, why, and what to do next.

Tree

Nested lists with the ARIA tree roles laid over them. Read the warning before choosing it: a tree is a scripted control by definition, because the roving tabindex and the expand and collapse cannot exist without script. This file renders whatever state the attributes describe and renders it correctly with no JavaScript, but a tree nothing drives is a picture of a tree. Where the page has no script, nested <details> from the accordion below is a real control rather than a decorated list.

Every part of that markup is load bearing. role="group" on every nested list, or the nesting is invisible to assistive technology and every item is announced at level one. aria-expanded on parent items only, because its absence is what marks a leaf. The twisty is in the markup on leaves as well as parents, where it is an empty box: drawing it only on parents indents files by half a chevron and the eye reads that as a fourth level.

Dates and time

src/app/calendar.css draws days and nothing else. The field that owns the value is a separate file, which is what lets a date picker, a range picker and a read-only month be the same grid with different things attached. It is a real <table>, because a calendar is a two dimensional table of days indexed by weekday across and by week down, and that is the only construction that gives a screen reader the column association for nothing.

Arrow around any of the three months below. Left and Right move a day, Up and Down a week, Home and End the edges of the focused week, Page Up and Page Down a month, and with Shift a year. The month is one tab stop rather than thirty-five, and the accessible name of every day is the whole date, which is what makes the component announce where it is.

Single

Each day is a button rather than a tabindex'd cell. The ARIA grid pattern puts tabindex on the cell and needs script to make anything focusable at all, so a page whose module fails to load gets a calendar no keyboard can reach; a button is focusable, activatable and announced as a control by the platform with nothing loaded. The cost is that an unenhanced month is thirty-odd tab stops, which is verbose rather than broken, and the module replaces it with one. The state is carried by attributes the platform already has: aria-current="date" for today, aria-pressed for the selection, and disabled or aria-disabled for a day that cannot be chosen. The month above is served with 11 March pressed and repaints from data-cal-value; today is marked when the reader pages to the month it is in, because the module reads the reader's own civil date rather than a slice of the UTC clock. Week numbers are the --weeks modifier: the column is always in the markup and hidden without it, so one server-rendered month serves both.

Range

The same grid with the geometry of a range on it. Range membership is geometry and geometry does not reach a screen reader, so it goes in the label as well: aria-label="9 March 2026, start of range". The endpoints are rounded on their outer edge and square on the inner one, so the band reads as one object rather than as two selected days with a tint between them.

Multi-date, and why the days are checkboxes

A booking screen, a shift rota and an out-of-office picker all want the same thing, and it is neither a single date nor a range: several dates that need not touch. The modifier is the same month with a different control in each cell, and the control is a real checkbox with a repeated name.

The days in a multi-date month are checkboxes, and they submit with JavaScript off. One repeated name posts as a list every server-side framework already parses - dates=2026-03-04&dates=2026-03-05&dates=2026-03-17 - so the month sends what the reader ticked whether or not this framework's module ever loaded. The alternative, buttons plus a hidden input a script keeps in step, was rejected because the value would then exist only where the script ran: turn scripting off and the buttons still press, the days still look chosen, and the form posts nothing. Every state below is drawn from :checked rather than from a class, so the paint cannot disagree with the value either.

Submit the form below with scripting disabled and the ticked days arrive at the server. The one value the module invents is the carry: a month the reader has paged away from is no longer in the document, so those dates are re-emitted as hidden inputs. Paging exists only when the module has loaded, so a page without it never reaches a month whose days are missing and the carry is empty by construction.

The control and the face are siblings rather than nested, so every state is a plain sibling selector - :checked, :disabled and :focus-visible each reach the day with no :has() and therefore no engine floor under the thing that says which days are chosen. The set is summarised and clearable, because nine highlighted cells scattered over a month is not readable as a set of nine, and bs-calendar__count is deliberately not a live region: bs-calendar__live already is one, and the module writes the chosen day and the new total into it together.

Shape, not only fill. A month can show a range and a set of picks at once, which is exactly the case where one accent colour on both stops carrying anything. Four states, four shapes: a single selection is a 6px rounded square, a range endpoint is rounded outward and square inward, an in-range day is a square-ended tinted band joined across days, and a multi pick is a full pill with a tick in the corner. The tick is two borders in currentColor, so it needs no glyph and survives forced colors untouched.

Date picker

The input is the control and the calendar is an affordance, which is the whole reason this component is worth building carefully and the single most common accessibility failure in the category. Type 1962-04-30 into the field below without opening the panel: it works, and it works with no script loaded. The input is never readonly, the accepted format is on screen rather than only in a placeholder, and that format text is tied to the input with aria-describedby.

The toggle is a separate button and not the field itself, because a field that opens a panel on focus cannot be typed into: the panel takes the first keystroke, or covers the text as it is entered, or both. Everything about the panel is the platform's - light dismiss, Escape, top-layer painting and the trigger relationship - and under 48em it is a bottom sheet, which src/feedback/popover.css already decides. Use <input type="date"> when you can: put bs-input on it and stop. This component exists for the cases the native control cannot serve - a panel you control, a month shared with a second field, your own disabled dates.

Date range

Two dates chosen together, with two real fields that can be typed into and three keyboard routes to the second endpoint. That is where range pickers fail: the first date is chosen with the keyboard and the second turns out to need a hover preview only a mouse can produce. Type both, press twice in the grid, or take a preset.

Two months where there is room and one where there is not. The trailing month is hidden below 48em rather than stacked, because two months stacked on a phone is a page the reader has to scroll through to compare and the second month is always one Page Down away in the first. The status line says what is expected next and is role="status", so it is announced without stealing focus from the grid the reader is still arrowing around.

Time picker

The field is <input type="time">, which already parses, validates, localises to a 12 or 24 hour clock by the reader's own settings, exposes hour and minute as separately arrowable segments and opens the platform's wheel on a phone. What it does not do is offer the eight times a booking form wants or show which slots are taken, which is the whole job of the list. Desktop Safari renders it as a plain text box, which is why the accepted format is written on screen rather than hinted at by segments.

Two states that are not the same thing, and conflating them is how listboxes get built wrong. aria-selected="true" is the chosen value, marked with a check, which is a shape and not a hue so it survives forced colors and greyscale printing. data-active="true" is where the arrow keys are, and it moves on every press including over options that are not chosen. A list that paints only one of the two either loses the reader's place while arrowing or forgets which time was picked the moment they arrow past it.

Scheduler

A week drawn as a time grid: hours down the side, days across the top, events placed by when they start and how long they run, and overlapping events side by side. CSS grid for the frame, two custom properties per event for the placement, and no library. Below 48em the week does not reflow, it scrolls sideways inside its own container, because seven days squeezed into 320px gives each 40px, which is narrower than the word Wednesday.

Placement is three numbers, all of them minutes past midnight and all of them unitless so the same value works whatever the hour height is set to. Overlap is two more per event, and it is the only part a consumer has to compute: the rule is the interval-graph colouring every calendar uses and it is four lines. Every event states its own start and end in text, in <time> elements, because position on a grid is not information a screen reader has and no amount of attributes on the wrapper fixes that. The hour gutter is aria-hidden for the opposite reason: every one of its labels is repeated inside the events beside it.

Metrics

Nine files, no charting library and no canvas. Every one of them states its reading in text as well as drawing it, because a picture of a number is not a number: it cannot be selected, searched, translated or read aloud. The drawing is the illustration of the text rather than the other way round, which is why most of these are a <figure> with a caption.

The board

A KPI carries a target and a freshness statement and has states, because it is fed by something that can fail. That is what separates it from src/data/stat.css, which is a fact already on the page. The four states below are the ones that ship undesigned, and each of them is expected to put words in the note, because dimming a number says nothing.

Direction and sentiment are not the same axis, and every dashboard that paints "up" green ships a bug the first time it displays an error rate. So they are separated: --up, --down and --flat set the shape, --good, --bad and --neutral set the hue, and a rising error rate is bs-delta--up bs-delta--bad. The second tile above is exactly that, and it stays correct for a reader who cannot separate the two hues because the triangle still points up and the word still says "up".

The grid's track expression is minmax(min(100%, 14rem), 1fr) rather than a bare minmax(14rem, 1fr), because a track cannot go under its minimum: at 320px a 14rem floor plus the page gutters pushes the row wider than the viewport and the whole document scrolls sideways. min(100%, 14rem) lets the floor collapse to the container when the container is the smaller of the two, which is the one arrangement correct at every width with no media query.

Gauge, meter and usage

Three readings against three different kinds of scale. A gauge is one value against a full scale drawn as a ring, made from one conic gradient with the hole punched by a mask so the surface behind shows through. A meter is a measurement inside a known range with bands, and it is not a progress bar: progress runs one way and ends, a meter moves in either direction and never completes. A usage bar answers the question a meter cannot, which is not "3.2 GB of 5" but which 3.2 GB.

The palette carries two status colours and the contract puts it out of scope, so there is no third hue for a middle band and inventing one was not on the table. The elevated band is drawn as a hatch of the critical colour against the track, so it reads as "on the way to critical" by texture, and the note states the band in words. The usage bar's segments are one ink in four textures for the same reason, and its legend swatch repeats the texture rather than a colour chip, which is the only version of that legend that survives a monochrome print and a replaced palette.

--bs-usage-bar-share is a segment's fraction of the whole quota and not of the used part, so the shares sum to less than one and the remainder shows as track. That is the difference between a usage bar and a pie: the empty part is the headroom, and headroom is the number people care about.

Live graph and log

The scrolling series a monitoring footer draws, and the bounded tail under it. The graph appends one column per tick at the end of the list and drops them off the front; the columns are fixed width, so the newest always lands on the trailing edge and nothing reflows. The slide is one transform-only keyframe running at the sample period, and under prefers-reduced-motion it is dropped and the columns simply appear, which is the whole of the reading anyway.

The live reading is text and it is not the plot. <output aria-live="polite"> announces the current value as it changes; the plot is role="img" with one label, because fourteen hundred empty list items announced individually is not information, it is a denial of service on a screen reader. Never put aria-live on the plot.

Levels are not a colour. Each row states its level as a word in the DOM, the marker down the leading edge repeats it as a shape - solid, dashed, hairline, absent - and the ink is the third channel. There is no amber in the palette, so warn is separated from error by shape and weight, which is the more legible answer at a glance anyway. role="log" is what tells assistive technology that new content is appended at the end, and tabindex="0" is not optional on a box that scrolls.

Flow

Five files about order. A stepper counts a sequence that has an end; a timeline records one that does not, so nothing in it is "current" and nothing is "to do". An activity feed is about who did something and leads with them; a pipeline is a diagram of stages made of real elements. All four are lists, because an ordered list is what puts a length and a position into the accessibility tree and no arrangement of divs does.

aria-current="step" is not optional and it is not a duplicate of data-state. The attribute is what assistive technology reads and the data attribute is what CSS can select on; neither can do the other's job. The step number is a CSS counter and is decorative, because generated content is announced inconsistently across engines and the list is ordered, so the position is in the accessibility tree already. Both components are vertical at 320px and turn horizontal only where there is room for them, which is what the --inline and --row modifiers carry.

The pipeline's connector is a list item with aria-hidden, so the list still counts three stages rather than six items. It is an element rather than a pseudo-element on the node because a branch is not always one line between two boxes and a pseudo cannot be given a state of its own. Every state has a word in bs-pipeline__state: the colour of a node is the fastest way to read the diagram and it is also the one that does not exist for a third of the people who will read it.

The datetime attribute is the whole reason to use <time>: "14:32" on its own is ambiguous about the day and the zone, and the attribute is what makes it unambiguous to anything parsing the page. The activity line is one paragraph, not three elements, because splitting "assigned INC-4821 to you" to style the middle one produces three announcements and a sentence that cannot be reordered for a language that puts the object first. The avatar is aria-hidden because the actor's name is right next to it and "R S Rae Sokolov" is a stutter rather than information.

Wizard

The panes a stepper is counting. Which step is visible has to survive a reload, and the only piece of state a stylesheet can read that outlives a page load is the URL, so the step is a fragment: :target selects it, the address bar remembers it, and the back button walks the flow backwards for nothing. Press Continue below and then press the browser's back button.

tabindex="-1" on the step is not decoration. Following a fragment link moves the browser's sequential focus point to the target only if the target can hold focus, and without it a keyboard user presses Continue and the next Tab lands back at the top of the document. On an engine without :has() every step is visible, stacked, in order, with working links between them, which is the right degradation for a setup flow because every field is still reachable and submittable. A form across steps is one form element wrapping the whole wizard, so the last step's submit sends everything.

Collaboration

Nine files for the surfaces where more than one person is in the product at once: the thread, the message in it, the box a reply is written in, the reactions under it, the faces beside it and the queue the work arrives in. Every one of them states in words what it also draws, because presence, delivery and unread are exactly the facts that get shipped as a colour and nothing else.

Thread

The unread marker is role="separator" with a label rather than a bare line, because a line that exists only in pixels is the single most useful landmark in a long thread and the one a screen reader user is most often denied. The typing line is a live region and its dots are aria-hidden: the words get announced, three animated discs would be noise every few seconds.

Delivery states are first class here rather than an afterthought, because optimistic rendering is normal in a message list. Failed is a danger edge plus a status line that says so in words and offers the retry: the reader who cannot see the edge is exactly the reader who will assume it sent. Message actions are visible by default and only a device with a genuinely hovering pointer gets the fade, which is the mobile-first ordering and also the correct one, because no reader should have to discover an affordance that has no way of being discovered.

Reaction marks are inline SVG and never emoji. An emoji renders differently on every platform, is announced as whatever the Unicode name happens to be, and cannot be recoloured to hold contrast against a chip. aria-pressed carries whether the reader has reacted and bs-reactions__name carries what the reaction means, because a count plus a mark says nothing on its own.

Composer

The send control must not change width. Both labels are laid into one grid cell, so the button is as wide as the longest of them from the first paint and swapping the hidden attribute changes nothing about the layout. A button that resizes mid-press moves the thing under the reader's finger. The field is a real <textarea> with a real label: a contenteditable div loses the label association, the form participation, the native undo stack and the mobile keyboard hints, and gains nothing but the ability to hold rich text badly.

The mention picker is a listbox, so the field that opened it keeps focus and drives it with aria-activedescendant. Moving focus into the list is the mistake that breaks typing: the caret leaves the composer, the next keystroke goes nowhere, and the mention is never inserted. A mention with somewhere to go is an anchor; a mention that is only a resolved name is a span, because a link that goes nowhere is worse than plain text for anyone tabbing through.

Presence, faces and the queue

Four shapes, not four colours. A presence dot is the smallest thing on the page and the most likely to be read by somebody who cannot separate green from red at 8px, so online is a filled disc, away is a half disc, busy is a bar across the middle and offline is an open ring. The hue is the second channel and the label is the third, and with --pip the label is off view but still in the accessibility tree, which is the whole reason it is clipped rather than deleted.

Unassigned is a state, not an absence. Rendering nothing when nobody owns the work reads as "loading" or as a template fault, so it gets a dashed ring where the face would be and the word in the name slot. Where the assignment cannot be changed, render a <span class="bs-assignee">: a disabled button is worse than a plain span, because it is still announced as a button and tells the reader an action exists that does not.

Unread on a queue row is three channels: weight on the title, a bar down the leading edge, and the word "Unread" in the DOM, taken out of view with a text indent rather than deleted. Bold is not a fact a screen reader reports, and a queue where unread is only bold is a queue half its users cannot triage. The whole row is not a link either: one link on the title, because a row-sized anchor swallows every other control in it and announces as one link whose name is the entire row including the timestamp.

Auth

Six files for the surface a customer sees before anything else, and for the states that flow spends most of its time in. The screen normally fills the viewport; the example is pinned to a fixed height with bs-min-h-var so it can sit in a documentation page. Type into it, press the reveal, submit it empty.

autocomplete is not decoration: username on the identifier and current-password on the password is what lets a password manager fill the form, and a form a manager cannot fill is a form users retype badly. The reveal is a real <button type="button"> with an accessible name and aria-pressed, not a background image on a span with a click handler; the name stays "Show password" in both states and the pressed state is what changes, which is how a screen reader announces a toggle. Only the browser can change an input's type, so the toggle itself is two lines a consumer writes, and without them the field is still a working password field.

The card carries the heading, so the accessible name of the page and the heading of the thing being done are the same string. A wordmark is not a heading. In a real page the card is a <main> and the title is the <h1>; here they are a div and a paragraph, because this documentation page already has both and a second one would be a worse page than a slightly less faithful example.

Provider buttons, and the three owners who publish a specification

The neutral bs-provider above is the shape a provider button takes when nobody has told you what it must look like. Google, Microsoft and Apple have told you. Their heights, corner radii, padding, permitted labels and both background pairs are the defaults on bs-provider--google, bs-provider--microsoft and bs-provider--apple, each quoted at the rule with its source, and each flipping to the owner's other appearance with the page theme.

The mark slot is empty in all three, and that is the example rather than a gap in it. None of the three grants anyone the right to redistribute their logo inside a package, so the framework ships the chrome and the owner's own file goes in the slot. A button waiting for that file collapses the slot, its gap and its mirror, which is what you are looking at: correct height, correct fill, correct label, centred, not broken. Drop the SVG in and the geometry each owner specifies is already reserved for it.

Google. Three labels and no others: "Sign in with Google", "Sign up with Google", "Continue with Google". Listed as a misuse is "Use the term 'Google' by itself in the button to represent the action of Sign in with Google", so "Google" is not a shorter spelling of any of them. The padding is quoted for Android and web as "12px left padding before the Google logo, 10px right padding after the Google logo and 12px right padding after the Sign in with Google text", which is the button's inline padding and its column gap rather than three separate numbers. Type is 14/20. No corner radius is published, so the framework's own is kept and a pill is one custom property. The mark keeps its own colours, because "You can't change the size or color of the Google 'G' logo" and a monochrome G is a listed misuse: this is the one slot that must not be handed a currentColor mark.

Microsoft. Two labels: "Sign in with Microsoft", and "If you don't have enough space for 'Sign in with Microsoft', it's ok to shorten it to 'Sign in'." Microsoft publishes its redline as a picture, so the geometry here is measured from the SVG on the same page rather than transcribed from prose. The lockup is 215x41 on a rect with no corner radius, which fixes the height at 41px and the corners at square; its four coloured squares occupy x 13 to 32, which is the 19px mark inside the 21px box Microsoft ships separately, leaving 12px from the leading edge of the button and 12px from the mark to the title. The title is left-aligned, so this is the one of the three that is not a centred pair. 41px is under this framework's own 44px comfort floor and well over the 24px SC 2.5.8 asks for; the owner's number wins because it is the owner's, and one custom property raises it.

Apple. "Use only Sign in with Apple, Sign up with Apple, or Continue with Apple." Minimum width is "140pt (140px @1x, 280px @2x)", minimum height "30pt", minimum margin "1/10 of the button's height" - two of those are proportions rather than fixed numbers, so the inline padding and the type size are both computed from the height: "the title's font size would be 43% of the button's height". The logo file carries its own spacing, so the button adds none: "Match the height of the logo file to the height of the button" and "Don't add vertical padding", which is why the mark is the full button height and the gap is zero. The height stays at 44px rather than dropping to the 30pt floor because Apple names 44 itself as "the default (and recommended) button height in iOS". Apple's two appearances are the inverse of the other two owners: the black button is for light backgrounds and the white one for dark, so the theme mapping runs the other way.

None of the three repaints on hover, and the strictest of them decides that for all three: Apple permits a custom button to change its "Background appearance. The overall color needs to remain black or white." A hover fill is a third colour. What they keep is the focus ring and the one pixel of active travel. Forced colors still wins over every one of them - a reader's palette outranks an owner's fill, and the theme re-declarations are wrapped in :where() precisely so a bare class in the forced-colors block can take a mandated fill back out.

One-time code, and the states

Six boxes that are one field. Paste a six-digit code into any of them and the whole row fills; type and it advances; backspace on an empty box walks back and clears the one before it. All of that is the module, and the field is complete and submittable without it, because maxlength="1" is what makes the platform's own behaviour usable with no script at all.

autocomplete="one-time-code" goes on every box and not only the first: iOS offers the code above the keyboard for whichever box has focus, so naming only the first means the offer disappears the moment the reader taps box two. type="text" with inputmode="numeric" and never type="number", which strips leading zeros, accepts e and plus, and ships spinner buttons that sit on top of a 36px box. placeholder=" " is not decoration either: it is what lets :placeholder-shown tell a filled box from an empty one, so the filled state is CSS with no class for anything to keep in sync.

role="alert" for the states that interrupt - error, locked, expired - because the reader has just pressed a button and needs the result. role="status" for the ones that report - sent, success - because they are polite news and must not cut across whatever is being read. Getting that backwards is why some forms shout and others say nothing. Colour never carries a state on its own: each variant sets an ink and a border style, the mark is a different glyph, and the title is a different sentence. There is no warning colour in the palette and none was invented, so locked and expired take the neutral strong ink with a distinct border and glyph.

Surfaces

Six files that hold other things: a frame that makes a block of markup read as a window, a stack of disclosures, a row that scrolls one slide at a time, a board of columns, a table with resizable columns and selectable rows, and the panel that retunes this page's own palette.

Window chrome

The bar with the dots and the title, for framing a terminal transcript or a shot of an application. It is a picture frame and not a landmark: the frame is a plain div, the dots carry no information and are hidden from the accessibility tree once, on the group rather than three times on its members, and the body clips whatever is inside it.

The second one is the answer to a desktop-shaped mock on a phone. Squeezing a two column layout into 320px leaves every column one character wide, and an overflow check reports nothing at all because the box is still inside the viewport. So bs-chrome--scaled lays the mock out at the width it was drawn for and renders it smaller, using zoom rather than a transform: zoom shrinks the box as well as the paint, so the frame's own height follows the mock instead of leaving a band under it. Narrow this page and watch the tiles inside the shot stay a grid while the shot itself changes shape, from --bs-chrome-aspect on a phone to --bs-chrome-aspect-wide from 48em up.

$ style add app/window-chrome
added src/app/window-chrome.css
1 file, 2.1 kB
$ _

The scaled shot is marked aria-hidden because it is decoration, and that is also why it carries no action: a control inside a hidden subtree is a focus stop with no accessible name. The reduction stops at 0.75 on a phone rather than going lower, because under about 0.6 the mock's own body text lands under 9px and a shot nobody can read is not a smaller shot, it is a picture. The first chrome sets no aspect at all, so it is as tall as its transcript and clips nothing.

Accordion

The control already exists in HTML. <details> holds the state, <summary> is the button, and the open attribute is what a screen reader announces. There is deliberately no behaviour module: a script toggling a class would be a second and worse copy of a control the platform ships, would take the state out of the accessibility tree, and would stop working the moment it failed to load. Open one in the second group and the others close, which is the name attribute rather than anything in the stylesheet.

There is no height animation, and that is a decision. A disclosure opening is a block-size change, block-size is a layout property, and this framework does not animate those. The one thing that moves is the chevron, which is a transform. The marker is decorative and drawn in currentColor borders; the open attribute is the state, which is also why it survives forced colors where a fill would not.

Carousel

A scroll container with scroll-snap, which means the scrolling itself - touch, trackpad, keyboard, the scrollbar - is the platform's. Tab to the track and press the arrow keys. The pagination is real links to the slides, so every slide is addressable and shareable without a script or a pointer. The previous and next buttons are the part that cannot be done without script, so they stay hidden until the module marks the component ready: a dead control that focus lands on is worse than no control.

The track contains its own horizontal overscroll, so a swipe that runs off the end of the slides does not turn into a browser back gesture. It deliberately does not contain the vertical axis: a carousel that swallows a vertical flick traps the page under the reader's thumb, which is the single most common way this component ships broken.

Board

The board scrolls, the page does not. A row of five 300px columns is 1500px wide, and if that width lands on the document then every page carrying a board scrolls sideways on a phone, including the parts of the page that have nothing to do with it. Tab to the board and use the arrow keys: a region only a pointer can scroll fails WCAG 2.1.1 on its own.

Drag is not in the stylesheet, because drag is not a rendering. The module provides it and provides the keyboard equivalent in the same breath: a board that can only be operated by dragging is unusable for anyone who cannot hold a pointer steady, and a keyboard path bolted on afterwards is how it always ends up missing. The grip is authored in the markup and hidden until the module marks the board ready, for the same reason the carousel's arrows are.

Data grid

A table with four things a table does not have: columns you can resize, a first column that stays put, rows you can select, and a header that stays put. Two of those already exist in src/data/table.css, so this file does not contain them and does not contain a second table either. Drag a column edge, or focus one and press Left and Right; Home and End go to the column's minimum and maximum, and Enter puts it back to the width the markup specifies.

Selection is two things and both are required. aria-selected on the row is the state and the checkbox is the control: a row that is tinted and not marked is invisible to a screen reader, and a row marked and not checked leaves a keyboard user no way to unselect it. table-layout: fixed is what makes a width mean something, because under the automatic algorithm the browser measures the content and a width is a suggestion, so a dragged column springs back the moment a cell disagrees with it. The one rule the module keeps is that a drag writes --bs-data-grid-col and never an inline-size: an inline used value outranks every cascade layer, so a column that had once been dragged could never again be changed by any rule here, including the clamp that stops it being dragged to nothing.

Colour lab

The last file in the group is already running on this page. The control in the corner opens it, and what it does is turn one seed colour into a whole theme and show the measured contrast of every pairing it produced. Every product built on a framework has a theming screen and every one of them ships the same defect: a colour input wired straight to a custom property, which lets an operator put yellow text on a green background and blame the framework for the complaint that follows. The panel offers no control that can pair two colours, so the failing pairing cannot be asked for.

It is the one file in src/ permitted to use forced-color-adjust, and only on the swatch fills. The contract grants exactly one exemption from the user's palette, for content whose own colours are the information, and a colour picker is that content: a swatch repainted in the user's palette shows the user's palette rather than the colour being chosen. The panel's own text, edges and controls take the user's palette like everything else here.