The Bridge Method · Version 1.0 · Published October 26, 2026
Accessible design rules for public-sector websites.
The web should work for everyone. If you design websites, The Bridge Method is here to help you build them accessible and inclusive, with practical guides and checklists you can use on your next project.
For many public institutions, the April 2027 ADA Title II deadline (opens in a new tab) is close. If you work on one of those websites, you do not have to start from zero. Start with what is here.
It is built for public-sector websites and useful for schools, nonprofits, and any site people depend on. Use it, adapt it, and share it freely under Creative Commons Attribution 4.0.
I wrote this down so it stays available for anyone who needs it.
Designing websites? This page is for you. Represent a public entity? See what your website has to resolve.
Cite as
Manrique, E. (2026). The Bridge Method: accessible design rules for public-sector websites (Version 1.0). Zenodo. DOI: 10.5281/zenodo.22986524
Why I created this method
I wrote these rules down for two reasons: to help public sites meet the law, and to leave a guide for designers who have none yet, in Latin America and anywhere accessibility is not yet required or taught.
Why a bridge
The method is named after the bridge Leonardo da Vinci drew (opens in a new tab) more than five hundred years ago. It needs no nails and no rope. Each beam holds the next, and it is built from plain timber, so anyone can make one.
The method works the same way. It stands on its own, each rule supports the next, and it costs nothing, so any designer can use it.
Many barriers are drawn before a line of code is written.
Designers are rarely taught how to prevent them. The method turns the standard into rules a designer can apply to a layout and a reviewer can check.
Colors that fail contrast
Text needs enough contrast with its background, or people with low vision cannot read it. Neither can anyone on a phone in sunlight. Body text needs a ratio of at least 4.5:1.
ExampleLight gray text (#999999) on white reaches 2.85:1 and fails. A darker gray (#595959) reaches 7:1 and passes.
WCAG 1.4.3
Text set too small or too light
Small or thin type is hard to read for people with low vision, and tiring for everyone else. The method sets body text at 16 px or larger, with a line height of 1.5.
ExampleOffice hours set as a 12 px light footnote become 16 px regular text, next to the address.
Method rule, related to WCAG 1.4.4 and 1.4.12
Forms without visible labels or useful errors
A placeholder disappears when someone starts typing, so the instruction is gone when they need it. An error that only turns a field red does not say what to fix.
ExamplePut the label “Date of birth” above the field, with the hint “MM/DD/YYYY”. If it fails, say: “Enter the date as month, day and year, for example 04/15/1980.”
WCAG 3.3.1, 3.3.2, 3.3.3
Focus states that were never drawn
People who use a keyboard need to see which button or link is selected. If the design file has no focus state, the developer has nothing to build.
ExampleDraw every button and link with a 3 px outline that has at least 3:1 contrast against the background, and place it in the design file next to the hover state.
WCAG 2.4.7, 1.4.11
Words locked inside images
A screen reader cannot read text that is part of an image. That text also cannot be translated, enlarged cleanly or reflowed on a small screen.
ExampleAn event flyer posted as a JPG. Publish the date, the place and how to register as text on the page, and keep the flyer as an extra image with a short description (alt text).
WCAG 1.4.5, 1.1.1
Five principles: what holds on every project
They are not steps. Each one applies at every stage of the work.
Design for the task
Start every template from the task a person must finish.
A rule you can check
Every decision has a number or a yes or no test.
Decide it in the design file
Contrast, order and labels are annotated, not guessed.
Clear in every version
Plain language first, and every published version designed together.
Every project teaches the next
Components and lessons go back into the shared system.
The visual rules at a glance
Eight groups of rules, each with a check and the WCAG criterion behind it. One example per group; the full set is in the PDF.
Download the design review checklist (in the Designer kit, PDF, 333 KB)
Color and contrast
Body text at least 4.5:1. Meaning never carried by color alone.
WCAG 1.4.3, 1.4.1
Typography
Body text 16 px or larger, line height 1.5, no text in images.
Method, WCAG 1.4.5
Layout and order
A 320 px layout with no side scrolling; reading order annotated.
WCAG 1.4.10, 1.3.2
Components
Every state drawn, including a visible focus state. Targets 24 px minimum.
WCAG 2.4.7, 2.5.8
Forms
Visible labels above fields; errors that say how to fix the problem.
WCAG 3.3.1, 3.3.2, 3.3.3
Images and icons
Each image marked informative, with alt text, or decorative.
WCAG 1.1.1
Motion and media
No auto-rotating carousels; space designed for captions.
WCAG 2.2.2, 1.2.2
Documents
A web page first; when a PDF is needed, a tagged one.
Method, WCAG 1.3.1
Five phases: the order of the work, from the designer's seat
They happen in order. Each phase starts from what the one before confirmed.
Phase 1
Understand
Critical task map and design barrier notes.
Phase 2
Define the system
Palette with approved pairs, type scale, focus and target sizes.
Phase 3
Design and annotate
Components with every state and notes developers can build from.
Phase 4
Review together
Two reviews with developers and testers, before and after the build.
Phase 5
Guide and transfer
Updated design system, help guides and short videos for editors.
The working sequence inside the phases
On a real project, the five phases run as twelve working steps. The order matters more than the tools: each step starts from what the step before it confirmed. The sequence applies to any site, sector or team size, and it reads like the bridge: each joint is a phase that holds its steps, from left to right, and the arrow along the ground carries the lessons into the next project.
How to read it. The bridge is the method. Its five joints are the five phases, in order from left to right, and each one holds its steps. It carries people from today’s site to a site where they can complete their critical tasks, and the arrow below closes the cycle: the lessons of step 12 start step 1 of the next project.
See the twelve working steps
Phase 1: Understand
- Review the current site: content, structure, barriers and how people use it.
- Listen to the people who run the site and the people who depend on it.
- Inventory the content and decide what stays, what changes and what goes.
- Agree on the critical tasks and how success will be measured.
Phase 2: Define the system
- Set the structure: navigation, page types and the path to each critical task.
- Build the accessible visual foundation and its approved-pairs table.
Phase 3: Design and annotate
- Sketch the critical tasks first, in simple wireframes.
- Present design options with the reasoning behind each, and decide together.
- Design the templates and components with all states, and annotate them.
Phase 4: Review together
- Hand off with notes for the build, then check the built pages against the design and the checklist.
Phase 5: Guide and transfer
- Leave help guides, short videos and clear content rules for the people who edit the site.
- Measure the critical tasks after launch and return the lessons to the design system.
Context · United States only
New to public-sector work? The key terms in plain words
The Bridge Method works on any site, in any country. If you design for a state or local government in the United States, these four terms explain what the law adds. Represent a public entity? See what your website has to resolve.
ADA Title II
The Americans with Disabilities Act (1990) is a U.S. civil rights law. Its Title II covers state and local governments: everything they offer the public, including websites and apps, must be usable by people with disabilities.
For example: A county website where residents pay property taxes must work for someone who uses a screen reader or only a keyboard.
The Department of Justice rule
The Department of Justice enforces Title II. In April 2024 it published a rule that says how public websites and mobile apps must meet the law, and by what date. It also covers content a firm builds or runs for a public entity under contract.
For example: A city of 80,000 people must meet the standard by April 26, 2027; a town of 8,000 people, by April 26, 2028.
WCAG 2.1 Level AA
The Web Content Accessibility Guidelines, published by the W3C. They are testable criteria in three levels, A, AA and AAA; the rule requires AA, which includes A. For a designer: text contrast of at least 4.5:1, text that can be enlarged to 200%, a visible keyboard focus and forms with clear labels.
For example: WCAG criterion 1.4.3 asks for 4.5:1 contrast for body text. The Bridge Method turns it into a rule you can check in the design file.
Who the covered entities are
State governments and their agencies; counties, cities and towns; courts; public school districts, community colleges and public universities; public libraries, hospitals and health departments; transit agencies; and special districts. Private businesses fall under Title III and federal agencies under Section 508.
For example: A community college, a county sheriff’s office and a city bus system are covered; a private law firm is not covered by this rule.
Coming in 2027
A free six-module course for designers
Self-paced and recorded, about six hours, in English and Spanish. Each module ends with an exercise on a real public-sector page.
1. Why public sites are different
2. Color, type and layout
3. Components and forms
4. Images, documents and motion
5. Plain language and multilingual content
6. Annotating and reviewing
Everyone deserves a digital experience that works for them.
Emir Manrique, Digital & Graphic Designer
Version history
1.0 · October 26, 2026 · First public release
License
Creative Commons Attribution 4.0 (CC BY 4.0)
Not legal advice
Applying the method does not by itself make a site conform to WCAG or comply with Title II; conformance requires testing of the built site. Automated tools catch only part of the issues; manual testing with assistive technology is needed to confirm conformance.