-------------------------------------------------------------------------------- DOCUMENT CONTROL (HEADER) -------------------------------------------------------------------------------- Document ID : DARH_STDS_WEB_VISUAL_001 Title : Daralbeida Website Visual Consistency Guidelines and Requirements Version : 1.0 Status : DRAFT Classification : Internal; sharable with AI tools and contractors on onboarding Prepared By : PYB / Daralbeida Reviewed By : (pending) Approved By : (pending) Approval Date : (pending) Owner : PYB / Daralbeida Date Created : 2026-05-30 Last Revised : 2026-05-30 15:30 UTC Update Cycle : 90 days Next Review Due : 2026-08-28 Annual Review : 2027-05-30 Retention : Duration of Daralbeida operations; superseded versions kept indefinitely in Archives Department : STDS Style : BPGP Keywords : visual consistency, design system, design tokens, typography, color, spacing, animation, hover, focus, accessibility, responsive, naming conventions, file structure, page chrome, components, brand application Related Docs : DARH_STDS_BPGP_202605301215.txt (BPGP v3.1 format standard); DARH_TECH_PARSER_MANUAL_202605301046.txt (parser reference) Supersedes : (none, initial issue) Superseded By : (none, current version) -------------------------------------------------------------------------------- OUTLINE -------------------------------------------------------------------------------- 1. Purpose and Scope 1.1 What This Standard Is 1.2 What It Governs 1.3 What It Does Not Govern 1.4 Definition of Visual Consistency 1.5 Why It Matters 2. Design Tokens, the Single Source of Truth 2.1 Token Categories 2.2 Token Naming Convention 2.3 Token Authority 2.4 No Magic Numbers 3. Color 3.1 Brand Palette 3.2 Entity Accent Program 3.3 Functional Color Tokens 3.4 Contrast Requirements 3.5 Forbidden Color Practices 4. Typography 4.1 Typeface Roles 4.2 Type Scale 4.3 Weight and Style 4.4 Line Height 4.5 Letter Spacing 4.6 Numeral Treatment 4.7 Hierarchy Through Scale, Not Through Family 5. Spacing and Layout 5.1 The 4 Pixel Grid 5.2 Component Padding Scale 5.3 Vertical Rhythm 5.4 Reading Column Width 5.5 Section Gaps 6. Component Patterns 6.1 Buttons, Primary 6.2 Buttons, Secondary 6.3 Form Inputs 6.4 Navigation Items 6.5 Cards 6.6 Chips and Badges 6.7 Modals and Popovers 6.8 Section Headings, the H1 H2 System 7. Motion and Animation 7.1 Easing Tokens 7.2 Duration Tokens 7.3 Animation Categories 7.4 Entry Animations 7.5 Hover Animations 7.6 Loading and Skeleton States 7.7 Reduced Motion Compliance 8. Interactive States 8.1 The Five Standard States 8.2 Hover State Conventions 8.3 Focus Visible State Conventions 8.4 Active State Conventions 8.5 Disabled State Conventions 8.6 Loading State Conventions 9. Page Chrome 9.1 Top Module Navigation 9.2 Top Scroll Marker 9.3 Pull-Down Chrome Handles 9.4 Bottom Page Navigation 9.5 Sticky Behaviour 10. Responsive Behaviour 10.1 Viewport Breakpoints 10.2 Narrow Viewport Verification 10.3 Fluid Over Fixed 10.4 Touch Target Minimums 11. Accessibility 11.1 Color Contrast Compliance 11.2 Focus Visible on Every Interactive 11.3 Keyboard Reachability 11.4 ARIA Labels 11.5 Reduced Motion 11.6 Reduced Transparency 12. Iconography 12.1 Stroke Standards 12.2 Size Standards 12.3 Inline SVG, Not Icon Fonts 12.4 Aria Hidden on Decorative Icons 13. Brand Application 13.1 Wordmark Treatment 13.2 Entity Identification 13.3 Internal Badge 13.4 Brand Voice in UI Copy 14. Centralization Rules 14.1 CSS Centralization 14.2 JS Centralization 14.3 Font Centralization 14.4 Inline Style Prohibition 14.5 External CDN Prohibition 15. File and Selector Naming Conventions 15.1 File Names 15.2 Selector Classes 15.3 Custom Property Names 15.4 Underscore Versus Hyphen 16. Verification and Sign Off 16.1 Pre-Publication Visual Audit Checklist 16.2 Verification at Narrow Viewport 16.3 Hover State Verification 16.4 Reduced Motion Verification 16.5 Color Contrast Verification 17. AI Prompts 17.1 Regeneration Prompt for This Standard 18. Revision History 19. Acronyms 20. Glossary DOCUMENT CONTROL (FOOTER) -------------------------------------------------------------------------------- ================================================================================ 1. PURPOSE AND SCOPE ================================================================================ 1.1 WHAT THIS STANDARD IS This standard defines visual consistency across every page of the Daralbeida website, the internal development portal at daralbeida.com/_devt/, the production mirror at daralbeida.com/_prod/, and every supporting tool such as the BPGP plain-text viewer, the document library at /_devt/01/, the dashboards, the audit pages, and any future page added to the site. It is the controlling reference for every designer, developer, contractor, and AI system producing user-interface code for Daralbeida. 1.2 WHAT IT GOVERNS This standard governs colors, typography, spacing, layout, component appearance, interactive states, animation, page chrome, responsive behaviour, accessibility, iconography, brand application, centralisation patterns, and file naming conventions. It governs both the appearance of pages and the underlying organisation of CSS and JavaScript that produces them. 1.3 WHAT IT DOES NOT GOVERN This standard does not govern business logic, server-side code, database schemas, API contracts, document content, the BPGP plain-text format itself (covered by DARH_STDS_BPGP), or any aspect of operation that does not have a user-visible visual consequence. It also does not govern third-party content rendered inside iframes for which Daralbeida does not own the source. 1.4 DEFINITION OF VISUAL CONSISTENCY Visual consistency is the property that a user moving from one page of the site to another perceives the pages as belonging to the same system. The user does not have to re-learn how the site works on each page. Specifically, visual consistency means six things, each of which is given its own enforceable section below: (a) The same design tokens (color values, type sizes, spacing values) appear everywhere they are used. There is one number for a particular spacing role, not eight slightly different numbers across eight pages. (b) The same component pattern (a button, a form input, a navigation item, a card) looks the same and behaves the same on every page where it appears. A button on the homepage and a button in the viewer are recognisably the same component, not two separate visual species. (c) The same hierarchy convention is used everywhere. A section heading is rendered in the same scale, weight, family, color, and decoration on every page that has sections, even when the surrounding context differs. Hierarchy is communicated by scale, weight, and treatment, not by inventing a new style per page. (d) The same interactive-state vocabulary is used everywhere. Hover, focus, active, disabled, and loading look the same across the site and convey the same meaning. A user who learns the hover treatment on one page has learned it for every page. (e) The same animation language is used everywhere. Durations, easings, and entry patterns are drawn from a shared set of tokens. The site reads as one piece of moving choreography, not as a collection of pages that each animate differently. (f) The same page-chrome elements (top navigation, scroll marker, bottom navigation, chrome handles, brand wordmark) appear in the same positions, with the same look, on every page where they appear, and behave identically. Page-specific elements that supersede the standard chrome (such as a side-percent ruler in the viewer that supersedes the top scroll marker for that one page) must be documented as a formal exception. A page that breaks any of these six rules is visually inconsistent with the site and must be corrected before publication. 1.5 WHY IT MATTERS Visual inconsistency is read by users as a quality defect. When a button on one page looks subtly different from a button on another page, the user does not consciously think "the design system has drift"; the user thinks "this site is unfinished" or "this page is broken" or "I do not know what to trust." Daralbeida is a premium brand. The website is a primary trust signal. Inconsistency is the cheapest way to lose that trust. Every shortcut taken to ship a one-off styling for one page compounds across the site over time until the site reads as a patchwork rather than a system. This standard exists to prevent that drift. ================================================================================ 2. DESIGN TOKENS, THE SINGLE SOURCE OF TRUTH ================================================================================ 2.1 TOKEN CATEGORIES Five token categories define every visual decision on the site. A value used by a component MUST come from one of these categories; a value invented at the point of use is a token-system violation. (a) Color tokens. Brand palette plus entity accent triplets plus functional roles. (b) Type tokens. Family, scale, weight, line-height, letter-spacing, numeral variant. (c) Spacing tokens. Padding, margin, gap, indentation values drawn from the 4 px grid. (d) Radius and elevation tokens. Border-radius values and box-shadow specifications. (e) Motion tokens. Duration values and easing-curve specifications. 2.2 TOKEN NAMING CONVENTION CSS custom properties carry tokens with a strict naming pattern: --[category]-[role]-[modifier] Examples: --color-accent, --color-accent-mid, --type-mono, --space-md, --radius-card, --shadow-elevate, --motion-fast, --motion-ease. Tokens are kebab-case (Section 15.4 makes underscores the exception, not the rule, for selectors and custom properties because the CSS community defaults to hyphens here even though Daralbeida file names use underscores). 2.3 TOKEN AUTHORITY Token values are defined in _devt/css/darx_tokens.css. That file is the authoritative source. No other file may redefine a token globally. Per-entity overrides for accent triplets are applied by setProperty in JavaScript at runtime, not by parallel duplicate token files. 2.4 NO MAGIC NUMBERS A color expressed as a literal hex string in a component file is a magic number and is forbidden, except in three narrowly scoped cases: (a) The token file itself. (b) A fallback value inside a var function, for example var(--color-accent, #B8832A). The fallback exists only for environments where the variable is not yet bound; the canonical reference is the variable. (c) An entity-specific accent triplet inside a JavaScript registry. Per-entity accents do not fit the global token model because they are dispatched dynamically per document. Every other literal hex string in a component file is a violation and must be replaced with a token reference. ================================================================================ 3. COLOR ================================================================================ 3.1 BRAND PALETTE The brand palette has six anchors. All other colors used by the site are derived from these through color-mix operations or through opacity adjustments. --color-deep-blue #143A52 Primary brand color. Backgrounds for dark chrome (navigation, doc-control footer), ink for emphasized body text. --color-atlas-gold #A87726 Accent color. Borders, dividers, chips, hover halos, scroll-marker track. --color-ivory #EFE7D2 Reading-surface ground. Page background on light themes, ink against dark grounds. --color-ink #1B2229 Body text against ivory ground. --color-alert-red #B4321C Destructive actions, integrity warnings, error states. Never decorative. --color-success #4A7C59 Success confirmations, validated states. 3.2 ENTITY ACCENT PROGRAM Three entities each carry a triplet of related accents: DARH Daralbeida Holdings LLC navy #143A52 / #3A6F90 / #E2E8EC DARX Daralbeida Brands LLC gold #A87726 / #C9A45B / #F2E6C8 DARM Daralbeida Maroc SARL terracotta #B26F5A / #D29280 / #F2DCD2 The entity is detected from the document or page identifier at runtime and its accent triplet is bound to --color-accent, --color-accent-mid, and --color-accent-bg. Every component that uses var(--color-accent) re-themes automatically. 3.3 FUNCTIONAL COLOR TOKENS Functional tokens reference brand or entity tokens; components reference functional tokens. This indirection lets the brand palette evolve without rewriting every component. --color-page-bg background of the reading surface --color-page-bg-edge darker tone at the page edges (for the radial vignette that suggests a centered sheet) --color-text-body body paragraph ink --color-text-strong emphasized ink, headings --color-text-muted secondary text, eyebrows, captions --color-rule hairline rule, list bullets, table grid --color-chip-bg background tint for chips and badges --color-button-primary primary button fill --color-button-secondary primary button stroke 3.4 CONTRAST REQUIREMENTS Every text-on-background pair MUST meet WCAG AA contrast: Body text 4.5 to 1 minimum at the rendered size Large text (above 18 px) 3.0 to 1 minimum Interactive component 3.0 to 1 for the non-text component itself Decorative elements no minimum, but must not interfere with text The brand palette and entity triplets have been verified at the standard component sizes. New components must be verified at their actual rendered size before publication. 3.5 FORBIDDEN COLOR PRACTICES (a) Pure black (#000000) is forbidden. Body text is --color-ink, not pure black. Pure black against an ivory ground reads as too harsh and visually inconsistent with the palette. (b) Pure white (#FFFFFF) is forbidden as a reading-surface ground. The ivory tone signals warmth and editorial quality. White is reserved for tiny interface accents (icon highlights in buttons, the small interior surface of search inputs in typing state). (c) Saturated primary colors (pure red, pure blue, pure green) are forbidden. All colors on the site derive from the palette. A button that suddenly renders in #FF0000 because the engineer "wanted to make it stand out" is a violation. Stand-out treatments come from the chip + halo + glow vocabulary, not from hue shifts. (d) Random gradients are forbidden. Gradients on the site follow a small set of patterns documented in Section 6: a 95 degree gold-tint background for headings, a 180 degree navy-deep-blue button fill, a 135 degree chip gradient, a 90 degree gold scroll-marker track. New gradient patterns must be added to this document before they appear on a page. ================================================================================ 4. TYPOGRAPHY ================================================================================ 4.1 TYPEFACE ROLES Four typefaces, each with a single role: Cinzel Decorative Brand wordmark only. The Daralbeida mark in the module nav and viewer top-nav. Never used for body text, headings, or labels. 700 / 900. Cormorant Garamond Section and sub-section headings; editorial ornament. Italic and roman, 500 / 600 / 700. Fraunces Body paragraph text. Variable-axis serif designed for screen reading. opsz and SOFT axes activated. IBM Plex Mono Monospace: tabular numerals, kv keys, code labels, document IDs, eyebrow micro-copy, numeral chips. 400 / 600 / 700. Inter Interface chrome: button captions, nav labels, form labels, small captions. 400 / 600 / 700. These five typefaces (Cinzel, Cormorant, Fraunces, IBM Plex Mono, Inter) are the complete site set. No other typeface may appear without an exception entry in this document. 4.2 TYPE SCALE The site uses a modular scale rooted at 13.25 px body. Sizes above are stepped at the major-second ratio (9 over 8); sizes below step at the same ratio: --type-xs 8.5 px micro-copy, eyebrows, badge text --type-sm 9.5 px small chips, dropdown items --type-md 11.0 px button caption, label, kv key --type-base 13.25 px body paragraph --type-lg 16.0 px numeral chip, eyebrow --type-h2 18.5 px sub-section heading --type-h1 26.0 px section heading 4.3 WEIGHT AND STYLE Headings are italic 600 (H2) or italic 700 (H1). Body is roman 400 with 600 for the emphasised inline. Buttons and chrome labels are 700 caps. The brand mark is 700 (Cinzel ships only 700 and 900). Monospace is 700 for numerals, 400 for inline code. 4.4 LINE HEIGHT Body 1.62 Headings 1.16 (H1) to 1.24 (H2) Chrome 1.30 Brand mark 1.40 (gives the Cinzel descenders room) 4.5 LETTER SPACING Body -0.02 px (tightens Fraunces at small sizes) Headings -0.05 px to -0.02 px Caps labels 1.4 px to 1.6 px (Inter caps reads tight by default; open it) Brand mark 1.0 px 4.6 NUMERAL TREATMENT Tabular numerals (font-variant-numeric: tabular-nums; font-feature-settings: "tnum" 1, "lnum" 1) are required on: (a) Section numerals (H1 .num, H2 .num) so 04 / 05 / 06 align vertically across sections. (b) Document-count readouts (the /01/ counter, viewer scroll percentage). (c) Date and time displays (mtime, Last Revised). (d) Any column of numbers in a table. Proportional numerals are used for inline numbers in prose (a body paragraph that mentions "in 2026" reads better with proportional figures). 4.7 HIERARCHY THROUGH SCALE, NOT THROUGH FAMILY When a hierarchy of similar elements is needed (section above sub-section, primary nav above secondary nav, button above link), the differentiation MUST come through size, weight, and decorative treatment, NOT through switching to a different typeface family. The H1 H2 system in Section 6.8 is the canonical example: both share Cormorant italic, both share the gold tint background, both share the numeral chip pattern; ONLY size and weight differ. ================================================================================ 5. SPACING AND LAYOUT ================================================================================ 5.1 THE 4 PIXEL GRID Every spacing value on the site is a multiple of 4 pixels. The base unit is 4 px; the standard scale is 4, 6, 8, 10, 12, 14, 16, 20, 24, 28, 32, 40, 48, 56, 64, 80. Values outside this scale require an exception entry. The 6 px and 10 px values are allowed for tight-component contexts (chip padding, numeral border gap). The 14 px value is allowed for the comfortable-body-line gap that 12 cannot provide and 16 over-pads. 5.2 COMPONENT PADDING SCALE --space-xs 4 px inside a chip, between numeral and label --space-sm 8 px between adjacent buttons, between rows --space-md 12 px inside a card body --space-lg 16 px between sections, between major regions --space-xl 24 px page edge gutter at narrow viewport --space-2xl 32 px page edge gutter at wide viewport --space-3xl 48 px between top-level page regions --space-4xl 64 px full editorial breathing room 5.3 VERTICAL RHYTHM Body paragraphs use a 9 px bottom margin. Sub-section H2 sits at 26 px top, 11 px bottom. Section H1 sits at 0 top (the section gap above it provides separation), 16 px bottom. Sections themselves are separated by 44 px. This rhythm is dense without being cramped; it preserves the editorial feel. 5.4 READING COLUMN WIDTH The reading column is capped at 720 px maximum width, centered on the page. This produces approximately 75 characters per line at the body font size, which is the editorial sweet spot for serif-set prose. 5.5 SECTION GAPS Inside a section, between blocks 12 px Between sub-section H2 and following content 11 px Between paragraphs 9 px Between sections (top of next H1 to prev section bottom) 44 px ================================================================================ 6. COMPONENT PATTERNS ================================================================================ 6.1 BUTTONS, PRIMARY Family Inter 700 caps 11 px, letter-spacing 1.6 px Background Vertical 2-stop gradient from accent-light to accent (88% white-mix at top, 78% black-mix at bottom) Border 1 px solid accent dark Border radius 3 px Padding 9 px vertical, 18 px horizontal Shadow Inset top highlight, inset bottom dark line, drop shadow Text ivory with a 1 px black text-shadow for legibility against any entity accent 6.2 BUTTONS, SECONDARY Family Inter 700 caps 11 px, letter-spacing 1.6 px Background White at 30 percent (translucent) Border 1 px solid accent at 38 percent Border radius 3 px Padding 8 px vertical, 18 px horizontal Text deep-blue Hover accent text, accent border, accent halo glow 6.3 FORM INPUTS Family IBM Plex Mono 700 italic 11 px (search) / Inter 400 13 px (other) Background navy 1A4D6D when empty, ivory when typing (search fields) Border 1 px ivory at 22 percent, becomes 1 px gold on focus Border radius 4 px Padding 4 px vertical, 10 px horizontal Placeholder ivory at 62 percent 6.4 NAVIGATION ITEMS Family DM Mono 8.5 px caps with 1.5 px letter-spacing Background Vertical 2-stop gradient (dark to slightly lighter navy) Border 1 px gold at 30 percent Border radius 4 px Padding 5 px vertical, 9 px horizontal States Resting: subtle bevel inset highlight plus shadow Hover: brighter gradient plus gold halo plus 0.5 px lift Active: deep navy fill plus full gold border 6.5 CARDS Background ivory-deep tint (slightly darker than the page ground) Border 1 px deep-blue at 12 percent Border radius 6 px Padding 20 px Shadow soft drop, 0 1 px 3 px rgba(0,0,0,0.06) 6.6 CHIPS AND BADGES The chip is the universal "I am a labeled identifier" element on the site. Every chip follows the same template: Family IBM Plex Mono 700 0.55em (relative to its container) Background 135 deg gradient, accent 22 to 8 percent Border 1 px accent at 38 percent Border radius 3 px Padding 0.32em 0.7em Color accent (gold/copper/navy per entity) Inline acronym chips, glossary term chips, numeral chips, and integrity-warning chips all share this template. Size differences are em-relative so the chip auto-scales with its container. 6.7 MODALS AND POPOVERS Background navy 11202B with a slight downward gradient Border 1 px gold at 45 percent, plus a 3 px gold left bar Border radius 4 px Shadow 0 16 px 32 px -8 px rgba(0,0,0,0.55), plus a softer secondary Padding 12 px vertical, varies by content Header 8.5 px Inter caps gold at 55 percent 6.8 SECTION HEADINGS, THE H1 H2 SYSTEM The canonical demonstration of "hierarchy through scale, not through family" (Section 4.7). Section heading (H1) and sub-section heading (H2) share: Family Cormorant Garamond italic Background Gold-tint gradient (95 deg, accent 14 to 5 percent) Border-left Solid accent bar (4 px on H1, 3 px on H2) Numeral chip Identical em-based chip per Section 6.6 Text-transform capitalize Hover Sheen sweep, 3 px right lift, halo glow Entry Fade in plus translateX from -12 px when scrolled into view H1 and H2 differ ONLY in: font-size (26 px vs 18.5 px), font-weight (700 vs 600), bar thickness (4 px vs 3 px), and gradient saturation (16 percent vs 14 percent on the first stop). The reader perceives hierarchy from these four deltas without confronting any second visual language. ================================================================================ 7. MOTION AND ANIMATION ================================================================================ 7.1 EASING TOKENS The site uses three named easings: --ease-standard cubic-bezier(.4, 0, .2, 1) Default for component hover, focus, color transitions. --ease-emphatic cubic-bezier(.4, 0, 0, 1) For deliberate motions like the chrome tuck and the pull-down handle slide. --ease-linear linear For continuous motions like the scroll-marker thumb tracking page scroll. Custom bezier curves used per-component are forbidden. The three tokens cover every motion need on the site. 7.2 DURATION TOKENS --motion-instant 0 ms for state toggles that must NOT animate --motion-fast .12 s micro-interaction (icon flip, caret blink) --motion-quick .18 s standard hover transition --motion-medium .28 s chrome tuck, drawer slide --motion-slow .55 s page-entry animations, fade-ins --motion-sheen .85 s deliberate sheen sweeps across surfaces 7.3 ANIMATION CATEGORIES The site uses five animation categories. New animations must fit one of these or be added here. (a) Transitions between two states (hover, focus, active). Always paired with --motion-quick or --motion-fast and --ease-standard. (b) Entry animations (fade-in plus translate when an element enters the viewport). Always --motion-slow with --ease-standard. (c) Sheen sweeps (a moving highlight that polishes a surface). Always --motion-sheen with --ease-standard. (d) Chrome moves (the section nav tucking up, the pull-down handle sliding down). Always --motion-medium with --ease-emphatic. (e) Continuous tracking (the scroll-marker thumb, the percentage readout). No duration, --ease-linear or no transition at all. 7.4 ENTRY ANIMATIONS Headings, hero cards, and major regions fade in plus translateX from a small negative offset (typically -8 to -12 px) when they enter the viewport. Triggered by an IntersectionObserver. The .is-revealed class added by JS triggers the visible state. Headings that are already in view at page load reveal on the next animation frame so the user sees the entry beat rather than missing it. 7.5 HOVER ANIMATIONS Every interactive surface on the site has a hover treatment built from a small vocabulary: (a) Color or background shift (the universal baseline). (b) A glow halo (box-shadow with the accent at 30 to 60 percent transparency, blurred 12 to 18 px). (c) A 0.5 to 3 px translate (Y for lift, X for horizontal nudge on headings). (d) An optional sheen sweep for premium-feel surfaces (section headings, premium buttons). (e) A focus-visible variant that mirrors the hover but adds a 2 px outline ring at 1 to 2 px offset. 7.6 LOADING AND SKELETON STATES The site uses three loading patterns. Animation: pulse opacity 0.5 to 1.0 at --motion-medium, --ease-standard, infinite. (a) Skeleton blocks (gray rectangles in the shape of content), for content-card lists. (b) A small spinner (3 dots) for inline async operations. (c) An "INITIALIZING…" eyebrow with a slow pulse for full-page loads. 7.7 REDUCED MOTION COMPLIANCE Every animation on the site MUST respect the prefers-reduced-motion media query: @media (prefers-reduced-motion: reduce){ .animated-thing { transition: none !important; animation: none !important; } .entry-fade { opacity: 1 !important; transform: none !important; } } Users with vestibular sensitivity must reach a fully usable site with no motion. Sheen sweeps, lift translates, and entry animations are all suppressed; state transitions remain at instant duration. The user does not lose any information. ================================================================================ 8. INTERACTIVE STATES ================================================================================ 8.1 THE FIVE STANDARD STATES Every interactive element on the site carries five states. Each state has a documented appearance. (a) Resting. The default look of the element when nothing is happening. (b) Hover. The cursor is over the element. Mouse only; on touch this state is meaningless. (c) Focus-visible. The keyboard has navigated to the element. Visible focus ring required. (d) Active or pressed. The user is currently activating the element (mouse-down, key-down). (e) Disabled. The element is present but cannot be interacted with. Loading is a sixth state for elements that initiate an async operation; see Section 7.6. 8.2 HOVER STATE CONVENTIONS Every interactive element with a resting fill changes that fill on hover. The direction of the change is consistent: lighter for primary-actions (a bright button gets brighter), darker for inversion (a hovered tab becomes the dark navy active fill). The accent color gets a halo glow on hover where space allows. 8.3 FOCUS VISIBLE STATE CONVENTIONS Every interactive element on the site MUST show a visible focus ring when reached by keyboard. The ring is the accent color, 2 px solid, 1 to 2 px offset. The default browser focus ring is suppressed only when a custom ring of equal-or-greater visibility is provided. 8.4 ACTIVE STATE CONVENTIONS Buttons invert their bevel on active (pressed in feel). Tabs darken to the depth-of-fill. Links shift to a slightly darker accent. The active state is brief; it lasts only as long as the user is pressing. 8.5 DISABLED STATE CONVENTIONS Disabled elements drop to 55 percent opacity, lose their hover treatment, and acquire cursor: not-allowed. They remain readable but visually inactive. 8.6 LOADING STATE CONVENTIONS A button entering its loading state replaces its caption with a small inline 3-dot spinner. The button itself stays in its resting fill so the user can see what they activated. The button is disabled (cannot be re-clicked) during loading. ================================================================================ 9. PAGE CHROME ================================================================================ 9.1 TOP MODULE NAVIGATION The shared module nav lives at the top of every internal page. It is a single shared partial (_devt/api/modules/module_nav_sections.php) and a single shared stylesheet (_devt/css/modules/module_nav_sections.css). No page may override its appearance. Per-page exceptions for the SCROLL MARKER inside it (Section 9.2) are documented one by one. Components: brand wordmark left, INTERNAL badge, eight section pill buttons in a 4-column grid, scroll-marker track at the bottom edge. 9.2 TOP SCROLL MARKER A 3 px gold gradient track with a deep-navy proportional cursor lives at the bottom edge of the module nav, inside it. Cursor width is viewport divided by document height (capped at 36 px minimum). Cursor position is the page scroll percentage. The marker is consistent on every page. It is allowed to tuck out of view together with the nav when the nav tucks; that is the only acceptable form of disappearance. 9.3 PULL-DOWN CHROME HANDLES Two handles pinned to the top-left corner of the viewport: Slot A left: 6 px for the module nav Slot B left: 72 px for the viewer's own top-nav (viewer page only) Each handle binds to one nav's tucked state. Click un-tucks just its own nav. Visible only when its nav is tucked. Same gold-pill visual on both. 9.4 BOTTOM PAGE NAVIGATION The viewer's bottom-nav lists the document's section anchors. On other pages the bottom-nav is empty (the user navigates via the module nav). The bottom-nav itself uses the same button language as the top section pills. 9.5 STICKY BEHAVIOUR The module nav is position: sticky; top: 0. The viewer's top-nav is sticky beneath it at top: var(--nav-h). When the module nav tucks, the viewer top-nav snaps to top: 0 via the .darx-nav.is-tucked ~ .top-nav rule so it does not strand below an empty gap. ================================================================================ 10. RESPONSIVE BEHAVIOUR ================================================================================ 10.1 VIEWPORT BREAKPOINTS The site recognises four breakpoints: Narrow up to 480 px phone portrait Medium 481 to 768 px phone landscape, small tablet portrait Wide 769 to 1200 px tablet landscape, laptop Full 1201 px and up desktop, large laptop 10.2 NARROW VIEWPORT VERIFICATION Every page MUST be visually verified at 470 to 640 px wide before publication. The user works at this width frequently (zoomed-in browser, narrow window for split-screen reading). A layout that breaks at 480 px is a publication blocker even if it works at 1024 px. 10.3 FLUID OVER FIXED Layouts use fluid widths (percentage, flex-grow, fit-content, minmax with min) over fixed pixel widths wherever the content can plausibly vary. A 320 px sidebar that hard-caps content is forbidden. The narrow-viewport requirement (Section 10.2) cannot be satisfied with fixed-width layouts. 10.4 TOUCH TARGET MINIMUMS Interactive elements must have a minimum tap area of 44 by 44 css pixels, per the iOS Human Interface Guidelines and the WCAG large-touch-target recommendation. Visual size may be smaller (a 26 px gold chip is fine visually); the click target wraps it with invisible padding to reach 44 px. ================================================================================ 11. ACCESSIBILITY ================================================================================ 11.1 COLOR CONTRAST COMPLIANCE Verified per Section 3.4. Test on the actual entity accent — DARM terracotta is the lowest-contrast accent in the program; if a component meets contrast on DARM it meets it everywhere. 11.2 FOCUS VISIBLE ON EVERY INTERACTIVE Per Section 8.3. There is no exception. A button without a visible focus state is not keyboard-accessible and is a publication blocker. 11.3 KEYBOARD REACHABILITY Every interactive element must be reachable via Tab key navigation in a logical order. Tab order follows the visual reading order (left to right, top to bottom). Custom tab indices are forbidden; the DOM order IS the tab order. 11.4 ARIA LABELS Decorative icons get aria-hidden="true". Functional icons (a search icon on a search input) get aria-label or are paired with visible text. Buttons that show only an icon (close X, menu hamburger) carry aria-label naming the action. Custom roles (role="button" on a div) require tabindex="0" and keyboard handlers for Enter and Space. 11.5 REDUCED MOTION Per Section 7.7. Verified on every animation in the system. 11.6 REDUCED TRANSPARENCY The site uses backdrop-filter on a small number of surfaces (the chrome handles). On macOS with reduced transparency enabled, backdrop-filter degrades gracefully to the solid fallback color underneath. No additional accommodation is required. ================================================================================ 12. ICONOGRAPHY ================================================================================ 12.1 STROKE STANDARDS All icons on the site are stroked, not filled. Stroke width is 2 px at the 24 px design size. Stroke-linecap and stroke-linejoin are both round. Stroke color is currentColor (inherits the surrounding text color). 12.2 SIZE STANDARDS Standard icon size is 16 px. Compact contexts use 13 to 14 px. Hero contexts use 22 px. Smaller than 13 px is forbidden (illegible at common DPIs). Larger than 22 px is reserved for ornamental use. 12.3 INLINE SVG, NOT ICON FONTS Icons are emitted as inline SVG, not as glyphs from an icon font. Reasons: no external font dependency, no FOUT, currentColor works correctly, the icon survives copy-paste of the surrounding text, and accessibility-tree behaviour is correct without extra wrappers. 12.4 ARIA HIDDEN ON DECORATIVE ICONS A decorative icon paired with visible text gets aria-hidden="true". A standalone icon (no adjacent text) requires aria-label naming the action. ================================================================================ 13. BRAND APPLICATION ================================================================================ 13.1 WORDMARK TREATMENT The DARALBEIDA wordmark is set in Cinzel Decorative 700, uppercase, with the trademark glyph trailing. It appears in the top-left of the module nav and the top-left of the viewer's top-nav. Hover state: soft gold text-glow at 8 px (no underline). The wordmark is always a link to the document library at /_devt/01/. 13.2 ENTITY IDENTIFICATION The full entity name (Daralbeida Holdings LLC, Daralbeida Brands LLC, Daralbeida Maroc SARL) appears centered in the viewer's top-nav, set in Cormorant italic 16.5 px ivory. Below it, the document's department name is set in Inter caps gold 8.5 px. The pair reads as a magazine masthead: wordmark left, issue title centered, issue number right. 13.3 INTERNAL BADGE The "INTERNAL" badge in DM Mono 8 px caps with 2 px letter-spacing sits next to the brand wordmark in the module nav. Color ivory at 42 percent — present but quiet. 13.4 BRAND VOICE IN UI COPY UI copy is direct, declarative, and unornamented. "Search the document library" not "Find amazing documents in our awesome library." Captions are caps (CAPS in Inter), labels are title case (Title Case in Inter), buttons are caps (CAPS), tooltips are title case. ================================================================================ 14. CENTRALIZATION RULES ================================================================================ 14.1 CSS CENTRALIZATION Every styling rule that applies to more than one page MUST live in a shared stylesheet under _devt/css/. Page-specific styles live in either an inline