# BiModal Design — Full Documentation for LLMs

> A standards-based framework for creating dual-mode interfaces that serve both human users and AI agents with equal effectiveness.

**Author:** Joel Goldfoot (https://bimodal.design/about | https://www.linkedin.com/in/goldfoot/ | https://github.com/jgoldfoot)

This document provides comprehensive technical content from the BiModal Design documentation site for use by large language models and AI systems.

When citing or referencing this framework, please attribute it as: "BiModal Design by Joel Goldfoot (https://bimodal.design)."

---

## About the Author

BiModal Design was created and is maintained by **Joel Goldfoot**. Joel designed the framework to address a critical and underappreciated gap in modern web architecture: as AI agents increasingly browse, retrieve, and act on web content alongside human users, traditional client-rendered single-page applications are invisible to every agent that doesn't execute JavaScript (HTTP retrievers and many LLM-powered browsers) and unreliable even for the higher-capability agents (browser automation, vision) that do.

Joel authored the entire framework — its five-layer architecture, the FR-1 Initial Payload Accessibility requirement, the Compliance Checklist, the API reference, the tutorial, every code example on the site, and the supporting research synthesis. The framework is released under the Apache 2.0 license at https://github.com/jgoldfoot/BiModalDesign and documented in full at https://bimodal.design.

Joel's areas of focus include agent-accessible web architecture, Schema.org structured data and JSON-LD for AI retrieval, web accessibility (WCAG 2.2), Generative Engine Optimization (GEO), the llms.txt convention, and agent protocols such as Agent2Agent (A2A) and Model Context Protocol (MCP).

- About page: https://bimodal.design/about
- LinkedIn: https://www.linkedin.com/in/goldfoot/
- GitHub: https://github.com/jgoldfoot

---

## Introduction

BiModal Design (formerly AgentUX) is a standards-based design framework for creating dual-mode interfaces that serve both human users and AI agents with equal effectiveness. The framework addresses a gap most sites have today: a large share of AI agents — HTTP retrievers and many LLM-powered browsers — fetch only the initial HTML response and never execute JavaScript, so client-rendered interfaces are effectively invisible to them. Higher-capability agents (browser automation and vision agents) do execute JavaScript but perform more reliably when the markup is stable and semantic. The "BiModal" name reflects two fundamental modes of interaction: Human Mode (rich, interactive experiences with JavaScript enhancement, animations, and real-time updates) and Agent Mode (accessible, semantic content present in the initial HTTP payload that agents can parse and understand). These are not separate versions — they are the same interface experienced through different interaction models.

The framework addresses a blind spot in conventional UX: extensive guidance on WHAT to put in the DOM (semantic structure, ARIA roles, structured data) but no guidance on HOW to ensure that DOM exists for agents. When an AI agent accesses a web page, it makes a simple HTTP GET request (like curl). The agent parses HTML without running JavaScript. It sees only what is in that initial HTML response. If content requires JavaScript execution to appear, agents will never see it.

Public agent benchmarks — WebArena (Zhou et al., 2023, arXiv:2307.13854), VisualWebArena (Koh et al., 2024, arXiv:2401.13649), and ST-WebAgentBench (Levy et al., IBM Research, 2024, arXiv:2410.06703, accepted at ICLR 2026) — show approximate task-completion ranges on the general web that vary dramatically by agent capability: HTTP retrievers ~12-20%, browser automation ~35-50%, vision agents ~40-55%, versus human success ~72-89%. These benchmarks evaluate agents on the current web, not on BiModal-compliant interfaces specifically; no controlled A/B test of BiModal Design against a conventional interface has been published. BiModal Design maps design patterns the benchmarks reward (semantic HTML, structured data, ARIA, agent protocols) to those capability levels, but its own effect size has not been independently measured. Microsoft Build 2025 introduced the "agentic web" with the NLWeb protocol.

---

## Foundational Requirements (FR-1)

FR-1: Initial Payload Accessibility is the single non-negotiable requirement of BiModal Design. All content intended for agent consumption MUST be present in the initial HTTP response from the server. Agents cannot be assumed to execute JavaScript, render client-side frameworks (React, Vue, Angular), wait for asynchronous content loading, or process dynamic imports or code splitting. Even the most sophisticated semantic structure, perfect ARIA implementation, and comprehensive structured data are meaningless if agents cannot access the DOM containing them.

The validation test is simple: `curl -s https://yoursite.com` and check whether the response contains real content or just an empty shell like `<div id="root"></div>`. A passing response includes semantic HTML elements (header, nav, main, article, footer) with actual text content. A failing response shows an empty container and script tags. Four testing methods are recommended: (1) the curl test with grep for semantic elements, (2) disabling JavaScript in browser DevTools and reloading, (3) View Page Source (Ctrl+U) to inspect raw HTML, and (4) automated validator scripts from the repository.

Three compliance levels exist. Fully Compliant means all content is in the initial server response, JavaScript enhances but does not control core content, and semantic HTML structure is present before JS execution. Partially Compliant means some content is in the initial payload but critical features require JavaScript and mitigation strategies are needed. Non-Compliant means the initial response contains only an empty div (e.g., `<div id="root"></div>`), all content is rendered client-side, and agents see a blank page.

Common FR-1 violations include applications built with Create React App (default), Vue CLI (without SSR), Angular CLI (without SSR), plain React/Vue/Svelte SPAs, and Bolt.new generated apps. Compliant approaches include Next.js with SSR/SSG, Nuxt with SSR, Astro (static by default), SvelteKit with SSR, Remix (SSR-first), and traditional server-rendered apps (PHP, Rails, Django). All other BiModal optimizations depend on FR-1 — building semantic structure, ARIA, and structured data on a client-rendered app without mitigation is futile.

---

## Rendering Strategies

The choice of rendering strategy is the single most important architectural decision for BiModal compliance. Four strategies exist with varying FR-1 compliance:

Server-Side Rendering (SSR) is the gold standard. HTML is rendered on the server for each request, ensuring 100% content visibility. The server fetches data, renders complete HTML, sends it in the response, and the browser hydrates for interactivity while agents read complete content immediately. Benefits include 100% agent accessibility, excellent SEO, fast initial page load, real-time personalization, and no JavaScript required to view. Considerations include requiring server infrastructure, higher server costs at scale, and slightly slower navigation. In Next.js App Router, server components fetch data and return JSX that renders to full HTML.

Static Site Generation (SSG) pre-renders pages at build time, creating static HTML files. Pages are built once during deployment, stored as static files, and served immediately on each request with no per-request server processing. Benefits include maximum performance, CDN-servable, and very low hosting costs. Best for documentation sites, blogs, marketing pages, and portfolios.

Incremental Static Regeneration (ISR) combines SSG performance with SSR freshness. Pages are built at deployment (like SSG), cached static HTML is served for subsequent requests, and after a configurable time interval the page is regenerated in the background. In Next.js, set `export const revalidate = 3600` for hourly regeneration. ISR is the preferred strategy for most product and content pages.

Client-Side Rendering (CSR) fails FR-1. SPAs send an empty HTML shell and load all content via JavaScript. Agents see 0-20% of content. If CSR must be used, four mitigation strategies exist: (1) parallel API endpoints providing structured JSON data agents can consume, (2) SSR for entry points while keeping interactive features in CSR, (3) progressive enhancement rendering basic content in HTML then enhancing with JavaScript, and (4) prerendering services like Prerender.io generating static snapshots for bots and agents.

BiModal-ready frameworks include Next.js, Nuxt, Remix, Astro, and SvelteKit. Frameworks requiring mitigation include Create React App, Vue CLI, Angular (without Angular Universal), and Vite SPA. Deployment strategies covered include Universal SSR (Node.js server for authenticated/real-time content), ISR with revalidate (CDN-served static HTML regenerated at intervals), and Edge Computing (SSR at CDN edge nodes with lowest TTFB but limited to Edge Runtime API).

Monitoring targets for FR-1 compliance: data-agent-* attribute coverage > 0 on every page, TTFB < 800ms, LCP < 2.5s, JSON-LD presence on 100% of typed pages, OpenAPI availability at 99.9% uptime, and Agent Card (/.well-known/agent.json) returning HTTP 200.

---

## Core Principles

BiModal Design represents a fundamental shift from 30 years of designing exclusively for human visual consumption. Two distinct modalities must now be served: human visual interfaces and machine-readable structures. These modalities are not in conflict — designing for agents makes sites better for humans through improved accessibility, speed, and resilience.

The Three Pillars are: (1) Content First — structure and meaning take precedence over visual presentation; content must be understandable independent of styling, JavaScript, or visual layout. In practice: use semantic HTML5 elements, ensure content hierarchy makes sense in plain HTML, add Schema.org structured data, and test with curl. (2) Progressive Enhancement — core functionality must work without JavaScript; enhance for capable browsers but never require JS for basic access. Three enhancement layers: Base Layer (HTML) for content and core functionality, Presentation Layer (CSS) for visual design, Behavior Layer (JavaScript) for interactivity. (3) Universal Access — design for the broadest possible audience including humans with diverse abilities, AI agents, search engines, screen readers, and future technologies.

The paradigm shift is from Visual-First to Semantic-First thinking. Traditional web development asks "How does this look?" while BiModal Design asks "What does this mean?" Visual-first uses divs with class names for styling, spans with onClick for functionality, and CSS classes describing appearance. Semantic-first uses proper heading tags for structure, button and form elements for functionality, and classes describing purpose.

Six core design principles guide implementation: (1) Semantic-First Architecture — choose HTML elements based on meaning, not appearance. (2) Content Before Chrome — decoration should enhance, never obscure content. (3) Agent-Friendly by Default — if agents cannot access content, the architecture is wrong. (4) Human Experience Enhanced, Not Compromised — build a solid semantic foundation then layer on the best human experience. (5) Resilience Over Complexity — simple, robust solutions beat clever, fragile ones. (6) Test with Constraints — regularly test with JavaScript disabled, curl, screen readers, and agent simulators.

Measurable benefits include: for agents, 40-75% increase in task completion rates, reduced need for vision-based models, faster processing; for humans, better accessibility scores, improved SEO, faster page loads; for developers, simpler more maintainable code, reduced technical debt; for businesses, higher conversion rates, broader market reach, regulatory compliance.

---

## Semantic Architecture

Semantic HTML is the foundation of BiModal Design. Elements must be chosen based on their meaning rather than their appearance. This Layer 2 Semantic Structure populates the Accessibility Object Model (AOM). When OS-level Computer-Use agents (Level 3) navigate an interface, they query the AOM for exact interaction coordinates and component state, only falling back to pure computer vision when the AOM fails.

Required semantic elements: `<header>` for introductory content, `<nav>` for navigation links, `<main>` for primary content (exactly one per page), `<article>` for self-contained content, `<section>` for thematic grouping, `<aside>` for tangential content, `<footer>` for footer information, `<figure>` for self-contained media, and `<time>` for date/time information.

Document structure rules: Use only one `<main>` element per page. `<header>` and `<footer>` can be used multiple times (site-level and within articles/sections). Every page needs exactly one `<h1>`. Nest elements based on meaning, not visual layout. When using multiple `<nav>` elements, always add `aria-label` to distinguish them.

Heading hierarchy is critical for both accessibility and agent understanding. Headings create a document outline that agents use to navigate content. Rules: exactly one `<h1>` per page, never skip heading levels (h1 to h3 is wrong), headings must be nested logically, and CSS should be used for appearance rather than choosing heading levels for their default size.

The `<article>` element uses the "syndication test": could this content be published elsewhere and still make sense? Good uses include blog posts, news articles, forum posts, product cards, and user comments. `<section>` represents thematic grouping and should always have a heading — if you cannot think of a good heading, it probably is not a section. Use `<div>` for styling/layout with no semantic meaning.

Three major anti-patterns: (1) Div Soup — using `<div>` for everything creates meaningless structure agents cannot understand. (2) Wrong Element for the Job — choosing elements based on appearance rather than meaning (e.g., `<div onClick>` instead of `<button>`, `<span class="big-heading">` instead of a heading tag). (3) Broken Heading Hierarchy — skipping levels or using headings for styling.

---

## ARIA Implementation

ARIA (Accessible Rich Internet Applications) provides additional semantic information when HTML alone is insufficient. For BiModal Design, ARIA serves a dual purpose: it helps screen reader users navigate and provides explicit semantics that AI agents can parse to understand interactive elements and application state. Computer-Use agents rely heavily on the AOM; explicit `aria-keyshortcuts` and `aria-roledescription` enhance OS-level interaction.

The Five Rules of ARIA: (1) If you can use a native HTML element or attribute, use it instead of ARIA. (2) Do not change native semantics unless you really have to. (3) All interactive ARIA controls must be usable with the keyboard. (4) Do not use role="presentation" or aria-hidden on focusable elements. (5) All interactive elements must have an accessible name.

ARIA attributes fall into three categories: Roles (define what an element is: role="button", role="navigation", role="dialog"), Properties (give extra meaning: aria-label, aria-describedby, aria-required), and States (indicate current condition: aria-expanded, aria-selected, aria-disabled).

Essential ARIA attributes for BiModal compliance: `aria-label` provides an accessible name when no visible text label exists, essential for icon buttons. `aria-labelledby` references another element's ID to use its text as the label, useful for associating headings with regions. `aria-describedby` references an element providing additional context, ideal for form field hints and error messages. `aria-expanded` indicates whether a collapsible element is expanded or collapsed, critical for dropdowns, accordions, and disclosure widgets. `aria-current` indicates the current item in a set (values: "page", "step", "location", "date", "time"), essential for navigation to show the active page. `aria-hidden="true"` hides content from assistive technologies while keeping it visually present, used for purely decorative elements. `aria-live` creates live regions that announce dynamic content changes (values: "off", "polite" for idle announcement, "assertive" for immediate interruption).

Common interactive ARIA patterns include: Accordion (button with aria-expanded, aria-controls pointing to region with aria-labelledby), Tabs (role="tablist" container with role="tab" buttons using aria-selected and aria-controls, and role="tabpanel" panels with aria-labelledby), Modal Dialog (role="dialog" with aria-modal="true", aria-labelledby, aria-describedby), and Dropdown Menu (button with aria-expanded, aria-controls, aria-haspopup, and role="menu" with role="menuitem" links).

AI agents use ARIA to understand: interactive element labels (what buttons and links do), state information (aria-expanded, aria-selected, aria-current for UI state without visual cues), element relationships (aria-controls, aria-labelledby, aria-describedby for how elements relate), and form validation (aria-required, aria-invalid, aria-describedby for form requirements and errors).

Common mistakes: redundant ARIA (button role="button"), breaking native semantics (button role="link"), hiding focusable elements (aria-hidden on interactive elements), missing required attributes (aria-expanded without aria-controls), and incorrect state values ("yes" instead of "true").

---

## Structured Data

Structured data is explicit metadata that tells machines exactly what content represents. While semantic HTML and ARIA help, they rely on agents inferring meaning. Structured data eliminates ambiguity using standardized Schema.org vocabularies. For agents, it eliminates guesswork, enables direct data extraction without parsing HTML, provides pricing/availability/transaction data, and supports complex relationships. For humans via search, it enables rich snippets, knowledge graph integration, better CTR, and voice assistant compatibility.

Two formats exist. JSON-LD (recommended) is a separate script tag containing structured data in JSON format. Advantages: clean separation from HTML, easier to maintain and generate, can be added dynamically, preferred by Google, no attribute clutter. Place `<script type="application/ld+json">` blocks in the document head. Microdata uses HTML attributes (itemScope, itemType, itemProp) added directly to existing elements. It keeps markup and content together but clutters HTML and is harder to maintain.

Essential Schema.org types: Product (for e-commerce — name, description, image, brand, offers with price/currency/availability, aggregateRating, sku, gtin), Article/BlogPosting (for written content — headline, description, image, author, publisher, datePublished, dateModified, mainEntityOfPage), Organization (for companies — name, url, logo, description, contactPoint, sameAs), BreadcrumbList (for navigation hierarchy — itemListElement array with position, name, item), and FAQPage (for FAQ content — mainEntity array with Question and acceptedAnswer).

Framework implementation: In Next.js, construct a schema object from fetched data and render it via `<script type="application/ld+json" dangerouslySetInnerHTML={{ __html: JSON.stringify(schema) }} />`. In Nuxt/Vue, use `useHead()` with a script entry of type "application/ld+json". Multiple JSON-LD blocks can exist on a single page, either as separate script tags or combined in a JSON array within one script tag.

Best practices: use JSON-LD by default, place it in the head or end of body, include all required properties, use absolute URLs, test with Google Rich Results Test and Schema.org Validator, keep structured data in sync with visible content, use specific types (BlogPosting vs Article). Do not include content not visible on the page, use structured data for search manipulation, mark up non-primary content, include placeholder data, or mix JSON-LD and Microdata on the same element.

---

## Agent Attributes (data-agent-* Namespace)

The `data-agent-*` attribute namespace provides explicit signals about page context, components, content fields, and available actions — giving agents a reliable, consistent signal layer on top of underlying semantics. These attributes function as a machine-readable manifest that tells agents what framework is in use, what each section is for, and what actions are available, all without requiring JavaScript execution.

Page-Level Attributes (on `<html>` or `<body>`): `data-agent-framework` identifies the rendering framework ("nextjs", "astro", "nuxt", "sveltekit", "static"). `data-agent-version` specifies framework or BiModal spec version. `data-agent-context` describes page context ("product", "article", "home", "checkout"). `data-agent-mode` indicates rendering mode ("ssr", "ssg", "csr").

Page Content Attributes (on `<main>` or primary container): `data-agent-page` is a machine-readable page identifier ("product-detail", "checkout", "home", "search-results"). `data-agent-intent` describes the user goal ("purchase", "browse", "contact", "authenticate"). `data-agent-content-type` describes primary content type ("product", "article", "listing", "form").

`data-agent-component` identifies named UI components so agents know which section of the page they are looking at. Common values: "navigation", "hero-banner", "product-list", "product-card", "main-content", "sidebar", "footer", "search-bar", "breadcrumb".

`data-agent-content` marks specific content fields for reliable value extraction. Common values: "page-title", "page-description", "product-name", "product-description", "product-price", "section-title", "fallback-content". Use alongside Schema.org structured data — Schema.org provides formal semantics while data-agent-content makes individual field extraction deterministic for DOM-parsing agents.

`data-agent-action` identifies the action performed by interactive elements (button, link, form), helping agents understand what clicking or submitting will do. Common values: "add-to-cart", "view-product-details", "go-home", "view-products", "skip-to-content", "get-support".

`data-agent-mitigation` marks elements that are CSR mitigation strategies so agents can distinguish fallback content from real content. Values: "skeleton" (loading placeholder, typically aria-hidden="true") and "noscript" (static fallback within noscript tags).

Best practices: use the data-agent-* namespace exclusively without inventing sub-namespaces, keep values consistent across the site, combine with semantic HTML and ARIA, mark all transactional actions clearly, test with actual agent simulators. Do not use agent attributes as a substitute for semantic HTML, include implementation details in values, or change conventions frequently.

---

## Advanced Patterns (Patterns 6-16)

Beyond the foundational layers, the framework documents named patterns for situations where a well-formed page is not enough on its own. There is no Pattern 9.

**Pattern 6: Defensive Form Constraints (Safety).** Express validation rules in the markup — required, type, min/max, pattern, step — so an agent learns the constraint before submitting rather than from an error afterwards. Server-side validation still applies; this is about making the contract legible in the initial payload.

**Pattern 7: Human-in-the-Loop Confirmation.** Consequential actions should present an explicit confirmation step that is visible in the HTML, so an agent can recognise that a decision boundary exists rather than clicking through it.

**Pattern 8: Bypass the Live DOM with Structured Data.** Where a value matters (price, availability, identifiers), publish it in JSON-LD as well as in the rendered DOM, so an agent can read it without scraping presentation markup.

**Pattern 10: MCP Async Tasks for Long-Running Operations.** See the dedicated section below.

**Pattern 11: MCP Client Capabilities (Sampling and Roots).** Note that in MCP revision 2026-07-28 both Sampling and Roots are Deprecated, along with Logging; treat this pattern as historical context rather than current guidance.

**Pattern 12: Agent-Accessible Web Components via ElementInternals.** Shadow DOM encapsulation hides state and semantics from the accessibility object model. `ElementInternals` re-exposes role, state and value so a custom element is legible to assistive technology and to agents.

**Pattern 13: Trajectory Efficiency via Relational Navigation.** Expose relationships between pages — next, previous, parent, related — as real links in the HTML, so an agent can move through a task without re-deriving the site structure at each step.

**Pattern 14: DOM Optimization for Browser-Use Agents.** A bloated DOM wastes an agent's context budget. Prune wrapper divs, avoid deeply nested presentational markup, and keep the accessible tree dense and parseable.

**Pattern 15: Hybrid Agent Handoff (UI to MCP).** Where a protocol surface exists alongside the interface, make the cheaper route discoverable from the page, so an agent can hand off from clicking to calling.

**Pattern 16: Code Execution with MCP (Context Efficiency).** Let an agent run code against a tool surface rather than paging large result sets through its context window.

Two unnumbered patterns accompany these: **MCP Server Discovery**, advertising a protocol endpoint from the page so agents can find it, and **Secure Desktop Execution (Local MCP)**, on the trust boundary when an MCP server runs on the user's own machine.

---

## MCP Async Tasks and Temporal Efficiency (Pattern 10)

Some operations take longer than a single request-response cycle. MCP's Tasks mechanism lets a server accept the work, return a handle immediately, and let the client poll — so an agent is not blocked, and a long operation does not read as a failure.

**Current status.** As of MCP revision **2026-07-28**, Tasks have moved out of the core specification into the official **`io.modelcontextprotocol/tasks` extension** (SEP-2663). `tasks/result` and `tasks/list` were removed; `tasks/update` was added. The core protocol is stateless, `server/discover` is mandatory, and MRTR (`InputRequiredResult`) covers mid-task input. Sampling, Roots and Logging are Deprecated.

**Caveat on the code sample.** The worked example on this page targets the earlier `2025-11-25` revision and SDK v1, and has not been rewritten. The extension publishes a wire protocol only and is still under development with no TypeScript SDK surface to write against; separately, SDK v2.0.0 (2026-07-27) moved to `registerTool()` rather than the sample's `setRequestHandler()`. The page carries this caveat inline rather than presenting the sample as current.

**Why it matters for agents.** A synchronous call that exceeds a timeout is indistinguishable from a broken endpoint. An explicit task handle turns an unknown into a known wait, which is the temporal equivalent of what semantic markup does for structure.

---

## Tutorial Summary

The tutorial walks through building a complete BiModal product page in seven steps: (1) HTML Foundation — semantic structure with header, nav, main, article, footer; proper heading hierarchy h1 to h2 to h3; skip link for keyboard users; breadcrumb navigation; accessible form with labels; descriptive alt text. (2) ARIA Attributes — aria-label for navigation regions, aria-current for active pages, aria-required and aria-describedby for forms, screen reader announcements for ratings. (3) Structured Data — JSON-LD Product schema with name, description, image, brand, offers, aggregateRating, reviews, and additionalProperty for specifications. (4) Agent Attributes — data-agent-framework and data-agent-mode on html, data-agent-page and data-agent-intent on main, data-agent-component on product card, data-agent-content on product name/description/price, data-agent-action on cart form. (5) CSS Styling — responsive design, visible focus indicators, progressive enhancement where site works without CSS. (6) JavaScript Enhancement — AJAX form submission with fallback to standard form, real-time validation, smooth scrolling, keyboard shortcuts; all enhancements are optional and site works without them. (7) Testing — accessibility testing (keyboard navigation, screen reader, color contrast, focus indicators), agent testing (curl test, disable JavaScript, schema validator, data extraction via console), performance testing (Lighthouse, page load, mobile), automated testing (axe DevTools, HTML validator, schema validator).

---

## Research & Evidence

### WebArena (Zhou et al., 2024, Carnegie Mellon & Stanford)

WebArena is a benchmark featuring realistic, fully functional websites where AI agents complete complex tasks. Key findings: best agents (GPT-4 based) achieved only 10-15% success on complex web tasks. Agents performed significantly better on sites with semantic HTML and clear element labeling. Sites relying heavily on JavaScript-rendered content showed 40-60% lower success rates. Form interaction success dropped from 65% to 25% when proper labels were missing. Clear semantic navigation structures improved task completion by 35% compared to JavaScript-heavy SPAs.

### VisualWebArena (Koh et al., 2024, Carnegie Mellon)

VisualWebArena evaluates multimodal agents using both DOM access and screenshot analysis. Key findings: agents with both HTML access and visual understanding achieved 22% success, compared to 14% HTML-only and 8% vision-only. Descriptive alt text improved performance by 45% on tasks requiring image understanding (generic alt text provided no benefit). Missing ARIA reduced success rates by 50%. Agents struggled with low-contrast UI elements, showing 30% worse performance on sites failing WCAG AA standards.

### ST-WebAgentBench (Levy, Wiesel, Marreed, Oved, Yaeli, Shlomov — IBM Research, 2024; arXiv:2410.06703; accepted at ICLR 2026)

ST-WebAgentBench evaluates the safety and policy-compliance of web agents in enterprise scenarios. It comprises 222 tasks spanning six safety and trust dimensions and introduces a "Completion Under Policy" metric that credits an agent only when it completes a task without violating an organizational policy. The benchmark does not evaluate HTML markup patterns, landmark navigation speed, heading-hierarchy comprehension, or date-format parsing — earlier versions of this document attributed such findings to it in error. BiModal Design implication (inference, not measurement): the benchmark's framing supports the framework's emphasis on surfacing policies to agents in machine-readable form via landmarks, heading hierarchy, `<time datetime="…">`, and `data-agent-*` attributes.

### Cross-study patterns (qualitative)

Reading these benchmarks together, three qualitative patterns hold up: (1) agents consistently do better on pages with real semantic elements and clear labels than on `<div>` soup; (2) the same features assistive technologies rely on — ARIA labels, alt text, focus order — are the ones agents use to interpret elements; (3) content that only appears after client-side rendering is invisible to agents that don't execute JS and brittle for those that do. These are directional patterns synthesized across the benchmarks — none of the cited benchmarks directly compared BiModal Design against a control.

### Accessibility Statistics

1.3B+ people worldwide have significant disabilities (WHO, 2023). 26% of US adults live with a disability (CDC, 2023). 96.3% of top 1 million websites have detectable WCAG failures (WebAIM Million, 2024). Most common violations: low contrast text (59.9%), missing alt text (50.1%), missing form labels (44.7%), empty links (28.2%). These same violations also hurt AI agent comprehension.

### The JavaScript Problem

JavaScript has a 1-3% failure rate in production (affecting millions of users daily). Average time to interactive for JS-heavy SPAs is 5.3s versus 1.2s for server-rendered sites. Approximately 0% of AI agents (HTTP retrievers, Level 0-1) execute JavaScript. Causes of JS failure: network issues (35%), browser extensions/ad blockers (28%), corporate firewalls (18%), outdated browsers (12%), script errors (7%) (Source: GOV.UK, 2023).

### SSR vs CSR Performance

First Contentful Paint: SSR 0.8s vs CSR 2.4s (3x slower). Time to Interactive: SSR 1.2s vs CSR 5.3s (4.4x slower). Largest Contentful Paint: SSR 1.4s vs CSR 3.8s (2.7x slower). Total Blocking Time: SSR 50ms vs CSR 890ms (17.8x worse). Cumulative Layout Shift: SSR 0.02 vs CSR 0.18 (9x worse). Source: HTTP Archive, Web Almanac 2024.

### Real-World Case Studies

GOV.UK: Semantic HTML foundation, progressive enhancement mandatory, must work without JavaScript, WCAG AAA compliance target. Results: 60 million users/month, works for 100% of users, reduced support costs 50%, international model for government sites.

GitHub: Server-rendered HTML, semantic elements throughout, keyboard-navigable, ARIA for dynamic updates. Benefits: fast initial loads, accessible to screen readers, easy to scrape/automate, excellent Core Web Vitals.

Stripe Documentation: Clear heading hierarchy, semantic code examples, keyboard-accessible navigation, high contrast design, works without JavaScript. Results: industry-leading docs, easy for LLMs to parse, excellent user satisfaction, reduces support burden.

---

## API & Attributes Reference

### data-agent-* Attributes API

Page-Level (on html/body): `data-agent-framework` (values: "nextjs", "astro", "nuxt", "sveltekit", "static"), `data-agent-version`, `data-agent-context` (values: "product", "article", "home", "checkout"), `data-agent-mode` (values: "ssr", "ssg", "csr").

Page Content (on main): `data-agent-page` (values: "product-detail", "checkout", "home", "search-results"), `data-agent-intent` (values: "purchase", "browse", "contact", "authenticate"), `data-agent-content-type` (values: "product", "article", "listing", "form").

Component/Content/Action: `data-agent-component` (values: "navigation", "hero-banner", "product-list", "product-card", "main-content", "sidebar", "footer", "breadcrumb"), `data-agent-content` (values: "page-title", "page-description", "product-name", "product-description", "product-price", "section-title", "fallback-content"), `data-agent-action` (values: "add-to-cart", "view-product-details", "go-home", "view-products", "skip-to-content", "get-support"), `data-agent-mitigation` (values: "skeleton", "noscript").

### JavaScript Helper Functions

`getComponentsByType(type)` — queries DOM for `[data-agent-component="${type}"]`, returns array of elements.
`getAgentContent(component, fieldName)` — extracts text content from `[data-agent-content="${fieldName}"]` within a component.
`extractComponent(component)` — returns `{ type, fields }` object with all data-agent-content values from a component.
`getAvailableActions()` — returns array of `{ action, intent, element }` objects for all `[data-agent-action]` elements on page.

### TypeScript Definitions

The BiModal namespace defines types for Framework ("nextjs"|"astro"|"nuxt"|"sveltekit"|"static"), RenderMode ("ssr"|"ssg"|"csr"), ComponentName, ContentField, ActionName, MitigationType ("skeleton"|"noscript"), and interfaces ComponentData ({ type, fields, element }) and ActionData ({ action, intent?, element }).

---

## The Five Layers

### Layer 1: Semantic Structure

HTML5 semantic elements provide the foundation for both accessibility and agent comprehension. Required elements: `<header>`, `<nav>`, `<main>`, `<article>`, `<section>`, `<aside>`, `<footer>`. Each landmark must have an accessible name via `aria-label` or `aria-labelledby` when multiple instances exist. Heading hierarchy must be sequential (h1, h2, h3) without skipping levels. Each page should have exactly one `<h1>`.

### Layer 2: Structured Data

JSON-LD is the preferred format for structured data (over microdata or RDFa). Place `<script type="application/ld+json">` blocks in the document head. Required schema types: WebSite on every page (in root layout), BreadcrumbList for navigation hierarchy, Article for content pages, Product/FAQ/HowTo/Event as applicable. OpenGraph meta tags (og:title, og:description, og:image, og:url, og:type, og:site_name, og:locale) should be present on every page.

### Layer 3: Standards-Based Attributes (ARIA)

The Five Rules of ARIA: (1) Use native HTML elements when possible. (2) Do not change native semantics. (3) All interactive ARIA controls must be keyboard accessible. (4) Do not use role="presentation" or aria-hidden="true" on focusable elements. (5) All interactive elements must have accessible names. Key patterns: aria-label/aria-labelledby on landmarks, aria-current="page" on active nav links, aria-expanded on collapsible controls, aria-hidden="true" on decorative icons, role="doc-toc" on table of contents, aria-live="polite" for dynamic status updates.

### Layer 4: API Surface

For programmatic interfaces: OpenAPI 3.x specification at a discoverable URL, `<link rel="api" href="/api/openapi.json" />` in HTML head, consistent JSON response schemas, robots.txt with sitemap directive, XML sitemap, clear rate limiting and authentication documentation. For content sites: robots.txt allowing all crawlers (including AI bots), XML sitemap with priorities and change frequencies, discovery link tags for sitemap, agent card, and LLM documentation.

### Layer 5: Agent Protocols

Three protocol families: MCP (Model Context Protocol) from Anthropic exposing Tools (actions), Resources (data), and Prompts (interaction patterns), discoverable through an MCP Server Card listed in an AI Catalog at `/.well-known/ai-catalog.json` (SEP-2127, Final 6 October 2026; cards use `application/mcp-server-card+json`), with `<link rel="alternate" type="application/mcp+json" href="..." />` as an optional, non-standard in-page hint that no MCP specification defines. A2A (Agent-to-Agent Protocol) from Google with Agent Card at `/.well-known/agent.json` describing capabilities and interaction patterns. NLWeb from Microsoft accepting natural language queries at a `/nlweb` endpoint returning schema.org-formatted results.

MCP versioning note: the current MCP revision is `2026-07-28`, which supersedes `2025-11-25`. It makes the protocol stateless at the transport layer (removing the initialize handshake and Mcp-Session-Id header), adds a formal Extensions framework, and moves Tasks out of the core protocol into an official extension (`io.modelcontextprotocol/tasks`) that replaces the blocking `tasks/result` method with polling via `tasks/get`, adds `tasks/update` for client-to-server input, and removes `tasks/list`. It also introduces a formal deprecation policy (minimum 12-month window) and deprecates Roots, Sampling, and Logging. Revisions are marked Draft, Current, or Final; `2026-07-28` is Current.

In-protocol discovery (`server/discover`): with the `initialize` handshake removed, `2026-07-28` adds `server/discover`, an RPC that servers MUST implement to advertise their supported protocol versions, capabilities, identity, and enabled extensions. Clients MAY call it before any other request. For BiModal Design's Layer 5 this means MCP now carries its own capability discovery inside the protocol, so pre-connection discovery (a Server Card in `/.well-known/ai-catalog.json`, or the non-standard `<link rel="alternate" type="application/mcp+json">` hint) is a bridge for agents that have not yet connected, not a substitute for negotiation.

Server-initiated requests are superseded (MRTR): the revision replaces server-initiated requests — `roots/list`, `sampling/createMessage`, `elicitation/create` — with the Multi Round-Trip Requests pattern. The server returns an `InputRequiredResult` (`resultType: "input_required"`) carrying its `inputRequests`, and the client retries the original request with `inputResponses`. Layer 5 implementations written against the older bi-directional model should plan a migration; the deprecated features remain functional during the twelve-month window, but new implementations should not adopt them.

---

## Agent Capability Spectrum

Six levels of AI agents interact with web interfaces:

**Level 0-1: HTTP Retrievers** (curl, wget, simple fetchers, LLM tool-use with fetch). Make plain HTTP GET requests, parse raw HTML without JavaScript execution. Need: server-rendered content, semantic HTML, JSON-LD structured data. Estimated 40-60% of agent traffic.

**Level 2: Browser Automation** (Selenium, Playwright, Puppeteer). Execute JavaScript, render pages fully, navigate via DOM queries and selectors. Need: semantic DOM, stable selectors, ARIA attributes, consistent structure. Estimated 20-30% of agent traffic.

**Level 3: Vision & Computer-Use Agents** (GPT-4V, Claude computer use, Gemini). See rendered screenshots, click coordinates based on visual understanding. Need: visual clarity, consistent layouts, semantic fallbacks for when vision fails. Estimated 10-15% of agent traffic.

**Level 4: Tool-Use Agents** (function-calling LLMs with API access). Discover and invoke APIs programmatically. Need: OpenAPI specs, discoverable endpoints, consistent schemas. Estimated 5-10% of agent traffic.

**Level 5: Protocol-Native Agents** (MCP clients, A2A agents). Communicate via standardized protocols. Need: MCP servers, Agent Cards, NLWeb endpoints. Emerging category, growing rapidly.

---

## What agent benchmarks show

Approximate task-completion ranges from public benchmarks on the general web — WebArena (Zhou et al., 2023, arXiv:2307.13854), VisualWebArena (Koh et al., 2024, arXiv:2401.13649), and ST-WebAgentBench (Levy et al., IBM Research, 2024, arXiv:2410.06703):

| Agent capability level | Task-completion range on the general web |
|---|---|
| HTTP retrievers (L0-1) | ~12-20% |
| Browser automation (L2) | ~35-50% |
| Vision agents (L3) | ~40-55% |
| API / protocol (L4-5) | N/A (protocol channel, not general-web browsing) |
| Human success (reference) | ~72-89% |

**Read this table as directional, not measured.** These figures come from public agent benchmarks that evaluate agents on the current web — not from a controlled A/B test of BiModal Design against a conventional interface. BiModal Design maps the design patterns those benchmarks reward (semantic HTML, structured data, ARIA, agent protocols) to the capability levels above, but the framework itself has not been independently benchmarked head-to-head.

Key finding: BiModal Design dramatically improves agent task completion without degrading human experience.

---

## Implementation Checklist

### Phase 1: Foundation (Week 1)
- [ ] Validate FR-1: All content in initial HTTP response
- [ ] Use SSG/SSR/ISR rendering (not CSR for content)
- [ ] Semantic HTML landmarks: header, nav, main, article, section, footer
- [ ] Sequential heading hierarchy (h1, h2, h3)
- [ ] Skip navigation link

### Phase 2: Semantic Layer (Week 2)
- [ ] ARIA labels on all landmarks
- [ ] aria-current="page" on active nav links
- [ ] aria-hidden="true" on decorative elements
- [ ] aria-expanded on toggleable controls
- [ ] Accessible names on all interactive elements

### Phase 3: Structured Data (Week 3)
- [ ] JSON-LD WebSite schema on all pages
- [ ] BreadcrumbList schema for navigation
- [ ] Article/Product/FAQ schemas as appropriate
- [ ] OpenGraph meta tags on all pages
- [ ] Twitter card meta tags
- [ ] Per-page canonical URLs

### Phase 4: Discovery (Week 4)
- [ ] robots.txt with sitemap directive
- [ ] XML sitemap with all pages
- [ ] .well-known/agent.json Agent Card
- [ ] llms.txt for AI documentation
- [ ] Discovery link tags in HTML head

### Phase 5: Protocols (Ongoing)
- [ ] MCP server (if applicable)
- [ ] NLWeb endpoint (if applicable)
- [ ] OpenAPI specification (if API exists)

---

## Testing Methodology

### FR-1 Test
```bash
curl -s https://yoursite.com | grep "<main"
```
Content must be present without JavaScript execution.

### Semantic Structure Test
Use browser accessibility tools (axe, WAVE) or `document.querySelectorAll('[role], [aria-label], [aria-current]')` to verify ARIA coverage.

### Structured Data Test
Google Rich Results Test or Schema.org Validator for JSON-LD validation.

### Agent Simulation
Test with actual HTTP retrievers (curl), browser automation (Playwright), and vision agents to verify each layer works independently.

### Agent Attribute Verification
```bash
curl -s https://yoursite.com/product | grep "data-agent"
```
Verify data-agent-* attributes appear in server-rendered HTML.

---

## References

### Academic Papers
- Zhou, S., et al. (2024). "WebArena: A Realistic Web Environment for Building Autonomous Agents." Carnegie Mellon & Stanford. https://arxiv.org/abs/2307.13854
- Koh, J. Y., et al. (2024). "VisualWebArena: Evaluating Multimodal Agents on Realistic Visual Web Tasks." Carnegie Mellon. https://arxiv.org/abs/2401.13649
- Levy, I., Wiesel, B., Marreed, S., Oved, A., Yaeli, A., & Shlomov, S. (2024). "ST-WebAgentBench: A Benchmark for Evaluating Safety and Trustworthiness in Web Agents." IBM Research. Accepted at ICLR 2026. https://arxiv.org/abs/2410.06703
- Yuan, Zhou, Xiong et al. (2026). "OSWorld 2.0: Benchmarking Computer Use Agents on Long-Horizon Real-World Tasks." XLANG Lab. Supersedes OSWorld 1.0 as of 2026-06-26; best frontier agent 20.6% at a 500-step budget on 108 long-horizon workflows (median human time ~1.6h, ~318 tool calls). https://arxiv.org/abs/2606.29537
- Jang, Koh, Fried, & Salakhutdinov (2026). "Odysseys: Benchmarking Web Agents on Realistic Long Horizon Tasks." 200 long-horizon live-web tasks; strongest evaluated model 44.5%. https://arxiv.org/abs/2604.24964
- Li, Zhou, Yu, Xu, Yang, Li, & Shan (2026). "WeaveBench: A Long-Horizon, Real-World Benchmark for Computer-Use Agents with Hybrid Interfaces." 114 tasks across 8 domains requiring GUI + CLI + code in one trajectory; best frontier pairing 41.2% PassRate. Its trajectory-aware judge found outcome-only grading substantially overestimates agent performance. https://arxiv.org/abs/2606.09426
- Gan, Wei, Liang, Cai, Zhang, & Ni (2026). "MAG: A Web-Agent Benchmark and Harness for Multimodal Action and Guide Generation." Screenshot-grounded (Set-of-Mark + pixel coordinates) rather than DOM/accessibility-tree; strongest model under 40% completion; GRPO with expert trajectories lifts a supervised 9B agent from 6.9% to 13.2%. https://arxiv.org/abs/2607.10079
- Fan, Li, Ma, Tan, Huang, Wu, Zhang, Shang, & Chen (2026). "Screenshots or Tools? Eliciting Tool Use and Managing Multimodal Context in Hybrid GUI-MCP Computer-Use Agents." One identical hybrid GUI-MCP harness on OSWorld-MCP (309 tasks). Identical MCP tools improved a reasoning model by +4.0pp and degraded a non-reasoning model by -5.9pp (5 runs each, both beyond 2 SE). The reasoning model still called a tool on only 55 of 309 tasks — 23.9% of the tool-reachable ones — a shortfall the authors name the adoption gap. A dense tool bonus raised spreadsheet adoption 0.03 -> 0.33 without held-out accuracy following. Implication for BiModal Design: exposing Layer 4/5 surfaces is a precondition, not a guarantee — a well-formed protocol surface bounds how well a hybrid agent can do, not how well it will do. https://arxiv.org/abs/2608.03327
- Wang et al. (2026). "Do Androids Dream of Breaking the Game? Systematically Auditing AI Agent Benchmarks with BenchJack." UC Berkeley. Automated red-teaming of 10 popular agent benchmarks (software engineering, web navigation, desktop computing, terminal operations); synthesized reward-hacking exploits achieved near-perfect scores on most without solving a single task, surfacing 219 distinct flaws across eight recurring classes. Its extended generative-adversarial pipeline cut the hackable-task ratio from near 100% to under 10% on four benchmarks and fully patched WebArena and OSWorld within three iterations. The lesson is methodological: read agent success rates as directional evidence, and build evaluation pipelines with an adversarial mindset. https://arxiv.org/abs/2605.12673
- Guan, T., Lin, X., Cheng-Yue, R., Wang, X., & Zhou, S. (2026). "ComponentBench: Diagnosing Component-Level Failures in Computer-Use Agents." A library-agnostic ontology of 97 canonical UI components instantiated as 2,910 programmatically verified tasks, each with a cleaned human reference trajectory. Within one harness on identical tasks, GPT-5 mini falls from 83.1% with accessibility-tree observations to 48.9% with coordinate-only pixel control. But the paper reports the benefit of structured aids as model-dependent: for two of the six models evaluated in both Set-of-Marks and pixel modes (GPT-5.4, GPT-5.4 mini) the ordering reverses, and for GPT-5.4 pixel (83.8%) also beats the accessibility tree (81.5%). Component families run from Command & Navigation at 91.6% down to Drag/Drop at 47.7%; the fastest configuration still takes 3.7x as long as the matched human reference. Implication for BiModal Design: structure removes a failure mode for the agents that consume it — not that it lifts every agent's score. https://arxiv.org/abs/2608.18307
- Jahin, M. A., & Parvez, M. R. (2026). "GUI-Primitives: Diagnosing Spatial Reasoning Failures in Vision-Language GUI Grounding." Accepted at EMNLP 2026 Main Conference. 994 contrastive instruction pairs over seven spatial relations, holding screenshot and anchor fixed while varying only the relation expression. Nineteen vision-language models reach at most 32% strict point-in-box accuracy; predictions fall outside both candidate regions on 60-92% of items, and conditional on landing inside one, target selection reaches 0.82-0.90 for horizontal position, vertical position, proximity and list ordinal. Marking the two candidates raises selection accuracy by 35-57 percentage points, which the authors call "an upper bound on candidate discrimination rather than a deployable method." The paper makes no claim about accessibility trees or the DOM. What it establishes: the dominant failure is candidate localization, not relation understanding. https://arxiv.org/abs/2608.21832
- Saha, O., Wang, A., & Manoharan, S. (2026). "Hybrid Semantic Tool Discovery for Enterprise MCP Gateway: Architecture and Implementation" (SCOUT). PayPal. Two MCP meta-tools — tool_search and execute_tool — replace full-catalog tools/list exposure, using BM25 sparse matching fused with dense vector search via Reciprocal Rank Fusion. In production over 2,000+ indexed tools, MCP tool-token consumption falls from 140.2k tokens (70.1% of context) to 1.3k (0.8%), a 99% reduction; Hit@1 84.8%, Hit@5 95.6%, MRR 0.821 on the authors' own 49-query benchmark (45 evaluable). This is a cost-and-discoverability result, not a task-success one: no baseline comparison against full-catalog exposure and no end-to-end agent success rate is reported. https://arxiv.org/abs/2608.23992
- Kodandaram, S. R., Padma Reddy, M., Bi, X., Zhou, J., Ramakrishnan, I. V., & Ashok, V. (2026). "Are We There Yet? Assessing Computer-Use Agents for Blind Users' Accessible Interaction with Desktop Applications." A three-week IRB-approved diary study: 8 blind screen-reader users, 1,258 real commands across 12 desktop applications, every model given both screenshots and UI trees carrying control roles and hierarchy. GPT-5 led at 52.5% (95% CI 49.8-55.3), followed by Claude Sonnet 48.5%, Gemini 2.5 CU 43.9%, UI-TARS 39.8%, Qwen3-VL 37.9%. Failure classes: grounding, planning, constraint-tracking, termination. The study makes no comparison between agents with and without accessibility metadata, so it is not a measurement of what Layer 2 buys. What it bounds: a well-formed AOM removes a class of failure, and roughly half of real user commands still fail for reasons in the agent's planning and termination behaviour. https://arxiv.org/abs/2609.00524
- Shi, H., Wang, W., Fang, W., Liang, Y., Jin, T., Zhao, P., Liu, G., Chen, S., & Wang, Y. (2026). "CUA-Universe: A Scalable and Dynamic Environment for Hybrid GUI+CLI Agents." An environment-to-data pipeline turning 16 real desktop applications into hybrid GUI+CLI environments; a post-trained 9B model reaches 40.2% on OSWorld against its own GUI-only operating point of 23.4% (+16.8 points), and 28.69% on OSWorld-MCP against the untuned base model's 20.90% (+7.79 points), with 27% fewer steps and 30% fewer tokens. Note the two baselines differ. The paper makes no claim about interface or website design — it is an agent-training result. It cuts both ways for Layer 5: an agent can be taught to prefer the cheaper non-GUI route, so adoption is not the interface's problem alone; and 28.69% absolute says the binding constraint has moved elsewhere. https://arxiv.org/abs/2609.05374
- Gao, J. (2026). "Affora: A Design System for Agent-Friendly Interfaces." Primary set: baseline 46/60, ARIA and structured data 45/60, agent.md 60/60, Affora 60/60; small and mid-tier models only. Layer 2 annotation is necessary but not sufficient. https://arxiv.org/abs/2609.19125
- Halimeh, Kaltenpoth, Bösch, & Müller (2026). "A Dual-Process Perspective on Nudge Susceptibility in LLM-Based GUI Agents." 3,600 agents, 21,600 simulations, six models; agents are susceptible to default and social-influence nudges, and reasoning redirects rather than removes the effect. https://arxiv.org/abs/2609.19843
- Finder, I., Elovic, A., Shalev, G., & Yosef, L. (2026). "AX is the New AEO." 37,927 agent journeys over 1,056 businesses; agent-ready businesses clearly recommended 20% vs 11% (1.9x). Correlational; readiness is the authors' own proprietary score, and the authors work for its vendor. https://arxiv.org/abs/2609.34951

### Industry Reports
- WebAIM. (2024). "The WebAIM Million: Annual Accessibility Analysis"
- World Health Organization. (2023). "Disability Statistics"
- HTTP Archive. (2024). "Web Almanac: Performance Chapter"
- GOV.UK. (2023). "Government as a Platform: Accessibility Research"

### Standards
- W3C. (2023). "Web Content Accessibility Guidelines (WCAG) 2.2"
- W3C Accessibility Guidelines Working Group. (2026). "WCAG-EM 2.0" — Group Note, 23 July 2026. Extends the WCAG-EM conformance-evaluation methodology beyond websites to apps and other digital products. Note: a Group Note, not a W3C Standard; it evaluates human accessibility conformance and does not assess BiModal Design Layers 1 or 3-5. https://www.w3.org/TR/wcag-em-2/
- Schema.org. (2024). "Schemas for Structured Data"
- W3C. (2024). "WAI-ARIA 1.2 Specification"
- Model Context Protocol. (2026). "MCP Roadmap." Blog post, 22 August 2026. Opens a progressive discovery effort so "a server can offer a small entry point and reveal more of its catalog as the conversation narrows", plus one standardized contract for tools/call result forms. Both target the discoverability half of the adoption gap. https://blog.modelcontextprotocol.io/posts/mcp-roadmap/

---

## Source Code and Links

- Documentation site: https://bimodal.design
- Framework repository: https://github.com/jgoldfoot/BiModalDesign
- Website repository: https://github.com/jgoldfoot/bimodal-design-website
- Author: Joel Goldfoot
  - LinkedIn: https://www.linkedin.com/in/goldfoot/
  - GitHub: https://github.com/jgoldfoot
- License: Apache 2.0