Accessibility statement

Effective September 25, 2026. Last updated October 6, 2026.

Our commitment

We want everyone to be able to read and use ebo2.com and app.ebo2.com, including people who use screen readers, keyboards, magnification, voice control, or other assistive technology, and people who find long or technical text hard going. Our target is Level AA of the Web Content Accessibility Guidelines (WCAG) 2.2, the standard published by the World Wide Web Consortium. This statement covers ebo2.com and app.ebo2.com.

The sites exist to help people understand a health procedure and compare the clinics that offer it, so a page that some readers cannot use fails at the one job it has. This statement says how close we are to our target, how we check, what we know does not work yet, and how to tell us about a problem.

Conformance status

WCAG describes a site as fully conformant when all of its content meets the standard, and as partially conformant when some parts do not. ebo2.com and app.ebo2.com are partially conformant with WCAG 2.2 Level AA. We build every page of ebo2.com to Level AA and test for it, but the problems listed under Known limitations remain, and app.ebo2.com has not yet been checked as thoroughly as ebo2.com.

No independent auditor has assessed either site. This statement rests on our own assessment, using the automated checks described in the next section, and says plainly that no manual review has been done yet. When we fix a limitation or find a new one, we update this statement.

How we test

• Automated audits. Each time ebo2.com's code changes, our automated checks run Lighthouse accessibility audits on a sample of its pages, and the checks fail if any sample page scores below 95 out of 100. The sample covers six kinds of page: the home page, the main guide, the cost guide, the clinic directory, a state page, and a clinic page. The checks run on every proposed change and again when a change reaches the main version of the site. The sample does not yet include any tool, report, or data page.
• Automated browser tests. Tests that drive a real browser on a phone-sized screen check particular behavior: that the home page has a skip link and a main landmark, that our main pages each have a single top-level heading, that the cookie banner can be reached and used with a keyboard, that opening it from the footer moves focus into it, and that making a choice returns focus to the link you used.
• Tests of the tools. The same kind of tests check the four tools. They check that every form control in each tool has a label, and that the questions for your doctor names each group of checkboxes. In the price check, the session cost planner, and the clinic finder, they check that an error message says what is wrong, is tied to its field through the attribute that screen readers use to read the two together, and moves focus to that field. In every tool, they check that focus moves to the result after you search or submit. They work the price check from the keyboard alone, clear the questions list from the keyboard, and check that a refused location request in the clinic finder explains itself next to the button. They also check that, without JavaScript, each tool shows a plain note and its reference information.
• Tests on narrow screens. Tests check that these pages fit a screen 390 pixels wide without scrolling sideways: the price check, the session cost planner, and the questions for your doctor, each with a result showing; the tools page; the reports page; the price, clinic transparency, regulatory, and studies comparison reports; and the data page.
• No manual audit yet. We have not had a person review these pages with a screen reader, and we have not had a third-party audit. Our automated checks cannot replace either.

Automated tools find only some accessibility problems, so a passing score does not mean that every page works for everyone. That is why your feedback matters.

What we do

On ebo2.com:

• Semantic HTML. Pages use real headings, lists, landmarks, and labeled form fields, so assistive technology can present and navigate them. Each page declares that it is in English, so screen readers pronounce it correctly.
• Keyboard access. We build pages so that links, buttons, and form controls can be reached and used with a keyboard alone. A "Skip to content" link comes first on every page, and the menu on small screens opens and closes from the keyboard.
• Visible focus. A clear 3-pixel outline shows which element has keyboard focus.
• Sufficient contrast. We choose text and background colors to meet WCAG AA contrast ratios.
• Readable text. Body text is set in Atkinson Hyperlegible Next, a typeface designed to be easy to read for people with low vision. Text sizes are relative, so they grow when you raise your browser's text size or zoom in, and pages fit narrow screens without sideways scrolling, except for wide tables, which scroll inside their own box.
• Room to tap. Buttons are at least 44 pixels tall, form fields at least 48, and the blocks in the research page's year chart, each of which is a link, at least 24 pixels square.
• Less motion. If your device asks for reduced motion, smooth scrolling and the small animations on the home page and the state map are turned off.
• Text alternatives. Images that carry information have text alternatives, and decorative illustrations are marked so that screen readers skip them. Charts carry a text summary.
• Maps in words. The state map on the directory page is a set of links, one for each state with listings, named with the state and its number of clinics and ordered alphabetically, and the list below the map gives the same counts as text. Every clinic page gives the clinic's address as text, with links for directions.
• Tables. Data tables use header cells, so screen readers can tell you which row and column a value belongs to, and the tables on our policy pages have captions.
• Forms. Every field in the contact form has a visible label, and the form tells your browser which fields hold your name and email address so that it can fill them in. If something is missing, the form says what, in words.
• Cookie choices. The cookie banner offers three buttons of equal weight, works with a keyboard, and can be reopened from the footer of every page.
• Tools. Every field in the four tools has a visible label, with a hint where the format matters, and groups of choices have a name. When something is wrong, the tool says what in words, ties the message to the field so that a screen reader reads them together, marks the field as invalid, and moves focus to the first field that needs fixing. After you search or submit, focus moves to the heading of the result, and a live region announces a short summary, such as the number of clinics found or the total of a plan. Text fields and menus are at least 48 pixels tall, and each checkbox or option has a label you can tap on a row at least 44 pixels tall. The price chart is an image with a text summary, a table below it gives the main figures, and every price it shows is listed in a table further down the page. The session cost planner and the questions for your doctor can print just your plan or list, or copy it as plain text.
• Plain language. We write in plain English and keep a glossary of the medical and technical terms the site uses.
• Captions. The sites have no video or audio today. Any video we publish in the future will have captions.

Reading ebo2.com does not need JavaScript: the text and links of every page work without it. Only a few features need it: the cookie banner, the clinic map, and the interactive part of each tool. Without JavaScript, each tool page shows a short note and its reference information instead: the table of published prices, the steps to add up a course by hand, the full list of situations and questions, or the list of states with links to the directory.

Known limitations

app.ebo2.com

app.ebo2.com, where accounts live, is newer. We build it to the same target, but we have not yet checked it the way we check ebo2.com: no automated accessibility audits run on it. We know of two problems on its sign-up, sign-in, and password forms. Error messages appear in red text that, in the light color scheme, is lighter than the WCAG AA contrast minimum, and screen readers are not told when an error appears. We intend to fix both. Until we do, if an error stops you, contact us and we will help. Please tell us about any other barrier you find there.

The year chart on the research page

The chart of studies by year on our research page scrolls sideways on phones, so that each block stays large enough to tap. On a small screen you need to scroll the chart to see later years. Its legend and year labels are visual only, but each block is a link whose name gives the year, the kind of study, the number of people in it where known, and its title, and the list of studies below the chart gives the same information as text.

The tools, the reports, and the data page

The tools, the reports, and the data page are new, and our checks of them are narrower than our checks of the older pages. None of them is in the sample that our Lighthouse audits score. The clinic finder is not yet in our narrow-screen tests. No one has yet listened to how a screen reader announces the tools' results, so we know the live regions are in place but not how each screen reader reads them. On the price check, the line that marks your price on the chart is visual only, though the result above the chart says the same thing in words. The interactive part of each tool needs JavaScript. If any of this gets in your way, tell us, and we will try to get you the same answer another way.

The clinic map

A clinic page shows a map: map tiles from OpenStreetMap, a third-party service, with our pin on the clinic. The map is a picture, named for screen readers as a map of the clinic in its town, and it has nothing to operate, so it needs no keyboard. Every clinic page also gives the clinic's address as text, with links to get directions or to open the location in Apple Maps, so you do not need the map to find a clinic.

Other websites

Websites we link to, such as clinic websites, journal articles, and PubMed, are run by others and are outside this statement. If you cannot read a study we link to, tell us: our notes on each study in the research library summarize what it found and what limits it, and we will try to point you to another version.

Compatibility

The sites are built with standard HTML and CSS, with WAI-ARIA attributes where HTML alone cannot describe a control, and a little JavaScript for features such as the cookie banner, the clinic map, and the tools. We aim for them to work with current versions of Chrome, Edge, Firefox, and Safari, on computers and phones, together with the screen readers and magnifiers that people use with those browsers.

Our automated tests run in Chromium, the engine behind Chrome and Edge, on a phone-sized screen. We do not yet run them in Firefox or Safari, so a problem that appears only in those browsers is more likely to reach the sites before we notice it. app.ebo2.com follows your device's light or dark setting; ebo2.com has one color scheme. If the sites do not work with the browser or assistive technology you use, please tell us which one.

Report a barrier

If something on ebo2.com or app.ebo2.com is hard to use, tell us through the contact form; "Report an error or request a correction" is the best topic to choose. It helps to include the page address, what you were trying to do, what happened, and the browser and any assistive technology you use. You do not need to know which guideline is involved.

Our goal is to respond within five business days. We will tell you what we found and what we plan to do, and if a fix will take time, we will try to get you the information you need another way in the meantime. If you cannot use the form, write to EBO2.com, 1968 S. Coast Hwy, #1921, Laguna Beach, CA 92651, United States.

Alternative formats

If you need something from the sites in a different form, such as the text of a page as plain text, a table as a simple list, or a description of a chart or map, ask us through the contact form. Tell us which page and what format works for you. We will send it by email where we reasonably can, at no charge, and if we cannot provide that format, we will say so and offer another. We aim to reply within the same five business days.

You can also print any page or save it from your browser, and most browsers offer a reader view that shows the main text of our pages without the menus.

About this statement

We first published this statement on September 25, 2026, and last reviewed it on October 3, 2026. It reflects our own assessment of the sites as they stood on that date, using the automated audits and browser tests described above; no outside organization has reviewed it. It measures the sites against WCAG 2.2 at Level AA, the level that accessibility guidance most often refers to.

We review the statement when we fix a limitation, find a new one, change how we test, or add a new kind of page, and the change history below records each update. If you think something in it is wrong or out of date, tell us the same way you would report a barrier.

Change history

• October 6, 2026: the clinic map is now our own picture made of OpenStreetMap's map tiles, shown without a "Show map" step and named for screen readers, so the section on it no longer says it may not meet WCAG 2.2 Level AA.
• October 3, 2026: the studies comparison report is in our narrow-screen tests, so the known limitations no longer say that it is not, and the list of narrow-screen tests names it. The clinic finder is still not in those tests.
• October 2, 2026 (second update that day): added the tools, the reports, and the data page: what we build into the tools, what our automated tests of them check and what they do not, and their known limitations, including that our Lighthouse sample does not yet cover them.
• October 2, 2026: expanded every section.
• September 25, 2026: first published.