ARCH 1.0

Accessible Research Charter for Hypertext

Version 1.0, published 2026-06-09. Adopted internally by the Aris Program in February 2026.

Preamble

Research manuscripts have been frozen in the PDF paradigm for three decades. PDFs are designed for fixed page dimensions, offer limited support for small screens, require specialized tooling for accessibility, and cannot natively support interactive content. The web has solved all of these problems for every other kind of document. It is time for scholarship to catch up.

ARCH defines what a web-native research manuscript should be. It is a charter: a set of concrete, testable requirements organized around a simple principle: a research manuscript on the web should be accessible, responsive, and durable by default. It should take full advantage of mature, established web standards to provide a modern reading experience (including native support for interactive content) rather than merely reproducing a static printed page in a browser.

ARCH defines the structural and behavioral floor for web-native research manuscripts. BRAIID is the Aris Program's design system that builds the aesthetic layer on top of this floor.

ARCH does not prescribe how documents are authored. It describes what the output must do. Any authoring pipeline (including but not limited to the RSM toolchain) that produces ARCH-compliant output has done its job. ARCH also does not evaluate or apply in any way to the scientific merit, validity, or content of the research itself. That is the job of peer review, not a document charter.

Why ARCH Exists

A research manuscript is part of the scholarly record. Unlike a blog post or a marketing page, it must remain accessible and faithful to its original form for decades, potentially centuries. A PDF achieves this through rigidity: it is a frozen page image. But rigidity comes at the cost of accessibility, responsiveness, and interactivity.

ARCH provides an alternative path to permanence. An ARCH-compliant document is durable not because it is frozen, but because it is built on the most stable substrate the web offers: semantic HTML, standard CSS, and optional progressive JavaScript. These technologies are maintained by global standards bodies, supported by every browser, and have proven backward-compatible across decades. A well-structured HTML document from 2005 still renders correctly today. ARCH ensures that research manuscripts built for the web inherit this durability while gaining everything PDFs cannot offer: reading on any device, accessibility for all readers, and interactive content that brings research to life.

Conventions

The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY in this document are to be interpreted as described in RFC 2119.

1. HTML Structure

An ARCH-compliant document is an HTML5 document. The HTML is the document, not a container for a PDF viewer, not a wrapper around a canvas element, not a shell for a JavaScript application. The HTML itself carries the manuscript's full semantic structure.

1.1 Document Semantics

The document MUST use semantic HTML5 elements to represent its structure. Specifically:

• The manuscript body MUST be wrapped in an <article> element.
• Sections MUST use <section> elements with appropriate heading levels.
• Headings MUST follow a strict hierarchy (<h1> → <h2> → <h3>, no skipped levels).
• The document MUST contain exactly one <h1>.
• Figures MUST use <figure> and <figcaption>.
• Tables MUST use <table> with <thead>, <tbody>, and <caption>.
• Block quotations MUST use <blockquote> with <cite> where applicable.
• Code blocks MUST use <pre><code>.
• Navigation aids (table of contents, footnote sections) SHOULD use <nav>.

1.2 Accessibility

• All images MUST have a descriptive alt attribute. Decorative images MUST use alt="".
• All figures MUST have a <figcaption>.
• The alt attribute and <figcaption> MUST NOT be identical. alt describes the visual content, <figcaption> provides scholarly context.
• Mathematical content MUST be represented in the HTML source as LaTeX notation, MathML, or equivalent semantic markup. Visual rendering via JavaScript libraries (e.g., KaTeX, MathJax) is acceptable, as the scholarly content is the source notation, which persists in the document. The rendered output MUST be accessible to screen readers.
• The document MUST declare a language via the lang attribute on <html>.
• All interactive elements MUST be keyboard-navigable.
• ARIA attributes SHOULD be used where semantic HTML alone is insufficient.
• The document MUST meet WCAG 2.1 Level AA for color contrast and other presentation requirements.

1.3 Metadata

• The document MUST include a <title> reflecting the manuscript title.
• The document SHOULD include machine-readable metadata for title, authors, abstract, publication date, and identifiers (DOI, ORCID) via <meta> tags or embedded structured data (JSON-LD, RDFa, or Highwire Press tags).

1.4 Self-Containment

• The document MUST be functional as a static file served over HTTP with no server-side processing.
• The document SHOULD be self-contained: a single HTML file, or an HTML file with co-located assets (images, stylesheets, scripts) bundled in a common directory or archive that can be preserved as a unit.
• The document MUST NOT require external network requests to render its core textual and mathematical content.
• Stylesheets and scripts MAY be loaded externally but MUST NOT be required for the document to be readable.
• Fonts MAY be loaded from external sources (e.g., Google Fonts, Adobe Fonts) provided that the CSS declares fallback fonts from standard font families (e.g., sans-serif, serif, monospace). If external fonts fail to load, the document MUST remain readable using the fallback stack.

2. Content Integrity

A research manuscript is a scholarly artifact. Its claims, evidence, and arguments must be preserved exactly as the authors intended. The document format must guarantee that what the reader sees is what the authors wrote, not what a script generated, a server injected, or a library rendered at runtime.

2.1 Core Content in HTML

• All content that carries scholarly weight (text, figures, tables, equations, captions, citations, and references) MUST be present in the HTML source. It MUST NOT be generated, loaded, replaced, or modified by JavaScript in a way that could alter the interpretation of the scientific content.
• Content that is dynamically generated or loaded via JavaScript (e.g., interactive visualizations, explorable explanations, navigation aids) MUST NOT carry primary scholarly weight. If an interactive element conveys findings essential to the manuscript's arguments, a static representation of those findings MUST also be present in the HTML.
• Put simply: if the JavaScript fails, the science must survive.

2.2 Mathematical Content

Mathematical content MUST be represented in the HTML source as LaTeX notation, MathML, or equivalent semantic markup. Visual rendering of mathematical notation via JavaScript libraries (e.g., KaTeX, MathJax) is a presentation concern, not a content integrity concern. The scholarly content is the source notation itself, which persists in the document regardless of whether rendering succeeds. The rendered output MUST be accessible to screen readers.

This is not an exception to the content integrity principle. It is an application of it: the source notation is the content. The visual rendering is the presentation.

3. CSS Presentation

An ARCH-compliant document must be readable and navigable on any device, in any lighting condition. The presentation layer handles this. The HTML handles meaning. The CSS handles experience. BRAIID implements the Aris Program's specific presentation language on top of these requirements.

3.1 Responsive Design

• The document MUST be readable at viewport widths from 320px to 2560px without horizontal scrolling of body text.
• Layout MUST use relative units (%, em, rem, vw) for sizing. Fixed pixel widths MUST NOT be used for the document's primary layout.
• Typography SHOULD scale with viewport width, using clamp() or equivalent.
• Figures and tables MUST NOT overflow their container. They SHOULD scale proportionally, but they MAY use horizontal scroll on their own container as a fallback.

3.2 Theming

• The presentation layer MUST define CSS custom properties for at minimum: foreground color, background color, accent color, and font family.
• The document MUST support dark mode via prefers-color-scheme: dark, either by redefining custom properties or by providing a complete alternate color scheme.
• The document SHOULD provide a manual theme toggle in addition to automatic detection.

3.3 Contrast and Legibility

• Body text MUST meet WCAG 2.1 AA contrast ratio (4.5:1 against background).
• Large text (18pt+ or 14pt+ bold) MUST meet 3:1 contrast ratio.
• These ratios MUST hold in both light and dark modes.

3.4 Print

• The document SHOULD include a print stylesheet or print-appropriate @media print rules.
• Print output MUST hide interactive controls, navigation elements, and theme toggles.
• Print output SHOULD use dark-on-light colors regardless of screen theme.
• Figures SHOULD respect break-inside: avoid where possible.

3.5 Motion

• All animations and transitions MUST respect prefers-reduced-motion: reduce. When this preference is active, non-essential motion MUST be suppressed.

4. JavaScript Behavior

JavaScript in a research manuscript is a privilege, not a requirement. The document is a text, not an application. Interactivity enhances the reading experience. It must never gate it.

4.1 Progressive Enhancement

• The document MUST be fully readable with JavaScript disabled. All text, figures, tables, equations, and citations MUST render without JavaScript. This requirement exists not because JavaScript is fragile (modern JavaScript is a stable, standardized technology) but because the combination of HTML and CSS alone provides the strongest archival guarantee, and the scholarly record demands the highest level of durability for core content.
• Interactive figures MUST provide a static fallback (image, table, or descriptive text) when JavaScript is unavailable or fails.
• JavaScript MUST be used only for progressive enhancement: zoom, interactivity, navigation aids, theme toggling, and similar features that improve but do not constitute the reading experience.

4.2 JavaScript Standards

• All JavaScript MUST target ECMAScript 2015 (ES6) or later.
• JavaScript SHOULD be vanilla (standard ECMAScript with browser APIs) wherever possible, avoiding external libraries for functionality achievable with built-in language features.
• Web application frameworks (React, Vue, Angular, Svelte, etc.) SHOULD NOT be used. A manuscript is a document, not an application. This is not a stylistic preference. Component-based reactive frameworks are architected around hydration: the HTML payload served from the network is a shell, and the document's content is constructed at runtime by JavaScript executing in the browser. This pattern is structurally incompatible with Section 2.1 (core content MUST be present in the HTML source) and Section 4.1 (the document MUST be fully readable with JavaScript disabled). Server-side rendering and static pre-rendering can paper over this at first paint, but the source-of-truth remains the framework's component tree, the rendered HTML is an opaque compilation output, and the document remains coupled to the framework's runtime for any interactive behavior. An ARCH-compliant manuscript's source-of-truth must be the HTML document itself, with JavaScript layered as optional progressive enhancement. A document whose source-of-truth is a React component tree is not an HTML document. It is a JavaScript application that compiles to HTML.
• When external libraries are used, they MUST be pinned to an exact version. Importing an unversioned or latest-resolving dependency (e.g., jquery.js or library@latest) is not permitted. Exact version references (e.g., plotly-2.35.2.min.js) are required.
• External libraries SHOULD be bundled with the document rather than loaded from CDNs, consistent with the self-containment requirements in Section 5.

4.3 No Runtime Dependencies

• The document MUST NOT require a running server, backend API, or database connection to render.
• The document MUST NOT make network requests that are required for core content to display. Optional requests (analytics, font loading, CDN-hosted libraries for interactive figures) are permitted but MUST fail gracefully.
• Third-party scripts SHOULD be loaded with async or defer and MUST NOT block initial rendering.

4.4 User Preferences

• Scripts MUST respect prefers-reduced-motion.
• Scripts MUST respect prefers-color-scheme and not override system-level theme preferences without explicit user action.
• Scripts MUST NOT interfere with browser-native functionality: text selection, find-in-page, back/forward navigation, zoom, or standard keyboard shortcuts (e.g., Cmd/Ctrl+N, Cmd/Ctrl+T). The document MUST NOT override default browser keybindings.

4.5 Interactive Content

• Interactive elements (embedded visualizations, explorable explanations) SHOULD be embedded as self-contained units within the document.
• Interactive elements MUST use CSS containment (contain: layout or stricter) to prevent a broken or slow-loading widget from disrupting document flow. A reader MUST always be able to scroll past an interactive element to reach content below it.
• Interactive content SHOULD declare its own accessible label via aria-label or aria-labelledby.
• When an interactive element conveys findings essential to the manuscript's arguments, the static fallback required by Section 4.1 MUST be sufficient for a reader to understand those findings without interacting with the widget. The fallback MAY take any form (an image, a table, a descriptive paragraph), but it MUST convey the essential scholarly content, not merely indicate that an interactive element exists.

Compliant static fallbacks:

• Interactive scatter plot → static image of the plot with axis labels and summary data table.
• 3D molecular model → multiple annotated static views from relevant angles.
• Explorable parameter space → default-parameter static figure with descriptive text of key parameter relationships.

Non-compliant fallbacks:

• "JavaScript required to view this content."
• Empty container or placeholder text that does not convey findings.

5. Durability

Research manuscripts are part of the scholarly record. They must outlast the tools that created them, the servers that first hosted them, and the organizations that published them.

5.1 Archivability and Offline Access

• The document MUST be archivable: a complete copy of the document and its local assets MUST be sufficient to reproduce the reading experience indefinitely.
• The document MUST be fully readable offline. A reader who saves or downloads the document (and its local assets) MUST be able to open and read it without any network connection.
• The document MUST NOT depend on any external service for its core content to remain accessible. CDNs go down. Companies shut down. The document survives.

5.2 Standards Compliance

• The document MUST use valid HTML5, CSS3, and ECMAScript 2015+ (where JavaScript is used).
• The document SHOULD use only Web Platform features that have reached Baseline Widely Available status (cross-browser interoperability for at least 30 months) for any feature on which core content depends. Features at Baseline Newly Available status MAY be used for progressive enhancement where graceful degradation is provided.
• The document MUST NOT use proprietary plugins, browser extensions, or non-standard APIs for core functionality.

6. Research Manuscript Structure

Sections 1 to 5 define requirements for any durable, accessible web document. This section defines the additional structural requirements that make a document a research manuscript. A well-built blog post may satisfy Sections 1 to 5. A research manuscript must also satisfy Section 6.

6.1 Abstract

• The document MUST contain an abstract.
• The abstract MUST be a dedicated <section> with a heading (e.g., <h2>Abstract</h2>) or an element with role="doc-abstract".
• The abstract MUST appear before the first body section of the manuscript.
• The abstract MUST be present in the HTML source and MUST NOT be generated by JavaScript.

6.2 Author Information

• The document MUST identify all authors.
• Each author entry MUST include the author's name and institutional affiliation.
• Each author entry SHOULD include an ORCID identifier, linked as a URL (e.g., https://orcid.org/0000-0000-0000-0000).
• Author information MUST be present in the HTML source, either as visible content or as machine-readable structured data (JSON-LD, RDFa, or Highwire Press tags). It SHOULD be both.
• Corresponding author contact information SHOULD be indicated.

6.3 Citations and Bibliography

A research manuscript's relationship to prior work is expressed through its citations. These are not optional formatting. They are structural elements of the scholarly argument.

• The document MUST contain a bibliography section listing all referenced works.
• The bibliography MUST be an ordered or unordered list within a dedicated <section> (e.g., <section role="doc-bibliography">).
• Each bibliography entry MUST have a unique id attribute so that in-text citations can link to it.
• Each bibliography entry SHOULD include machine-readable identifiers where available: DOI as a linked URL, arXiv ID, PubMed ID, or ISBN. At minimum, entries with a DOI MUST link to it.
• In-text citations MUST be hyperlinks (<a>) linking to the corresponding bibliography entry's id.
• In-text citations SHOULD use role="doc-noteref" or equivalent ARIA markup to convey their function to assistive technologies.
• The bibliography MUST be present in the HTML source and MUST NOT be generated by JavaScript.

6.4 Cross-References

Research manuscripts refer to their own components: "as shown in Figure 3," "see Section 2.1," "from Equation 7." These references must resolve.

• All figures, tables, equations, and sections that are referenced in the text MUST have a unique id attribute.
• In-text references to figures, tables, equations, and sections MUST be hyperlinks (<a>) linking to the referenced element's id.
• Cross-reference links SHOULD use descriptive link text (e.g., "Figure 3" rather than "here" or "above").
• Cross-references MUST NOT rely on JavaScript to resolve. The <a href="#id"> pattern is sufficient and durable.

6.5 Footnotes and Endnotes

• Footnotes and endnotes, if present, MUST use role="doc-footnote" or role="doc-endnote" on the note content.
• Footnote references in the text MUST be hyperlinks to the note content, and SHOULD use role="doc-noteref".
• The note content SHOULD include a back-link to the referring location in the text.

Conformance

A document conforms to ARCH 1.0 if it satisfies all MUST requirements in this charter. A document that additionally satisfies all SHOULD requirements is considered fully conformant.

ARCH does not prescribe visual design. Two documents can both be ARCH-compliant and look entirely different. ARCH defines the structural and behavioral floor, not the aesthetic ceiling.

ARCH compliance is a statement about document structure, accessibility, and durability. It is not a statement about the scientific merit, validity, or correctness of the research content. Evaluation of scientific content is the responsibility of peer review and editorial processes, which are entirely outside the scope of this charter.

Scope and Limitations

ARCH applies to the rendered output, the HTML document that readers see. It does not govern the authoring format, the compilation process, the hosting platform, or the editorial workflow. A document written in RSM and compiled to HTML via the Aris toolchain is the primary target, but any authoring pipeline that produces ARCH-compliant output satisfies the charter.

ARCH 1.0 focuses on single-document manuscripts. The following are out of scope for this version and are candidates for future revisions:

• Multi-document collections and journal issues
• Living documents and versioned manuscripts
• Executable notebooks and computational reproducibility
• Research-specific semantic environments (theorem, definition, proof, lemma)
• Supplementary materials and data artifact packaging

ARCH is maintained by the Aris Program. The canonical source is at github.com/aris-pub/arch. The rendered version is at aris.pub/arch/1.0/.