We sell accessibility audits. This is our own.

Site Brace is operated by Aliso LLC dba Site Brace. We sell WCAG 2.1 Level AA accessibility audits for a living, so the bar for our own marketing site (sitebrace.com) is the bar we sell to customers. This page documents the conformance target we hold sitebrace.com to, the same axe-core scan we apply to it, the specific measures visible in the site code today, anything we are aware of that falls short, and how to tell us if you encounter a barrier we missed. We commit to acknowledging accessibility reports within one business day and substantively responding within five. There is no overlay widget on this site and there never will be.

Operated by: Aliso LLC dba Site Brace. Related: Security, Privacy Policy, Terms of Service.

Our conformance target

Target standard. Web Content Accessibility Guidelines (WCAG) 2.1, Level AA. That is 30 Level A success criteria plus 20 Level AA success criteria, 50 in total. It is the same target the U.S. Department of Justice cited in its April 2024 Title II web rule, the same target the European Accessibility Act builds on, and the same target our $149 customer audit measures against.

Conformance, not compliance. We are careful about which word we use, because the two mean different things and Site Brace's whole brand is being honest about that distinction.

• Conformance is a technical determination: does this page meet a written technical standard, criterion by criterion. It is something an auditor can measure and a developer can fix. We aim for, and claim, WCAG 2.1 Level AA conformance on sitebrace.com.
• Compliance is a legal determination under a specific law (the Americans with Disabilities Act, Section 508, the European Accessibility Act, the Accessibility for Ontarians with Disabilities Act, and so on). Whether a particular site is "ADA compliant" depends on the facts of the site, the users, and the jurisdiction; it is a determination a lawyer makes about evidence, not a deliverable an audit produces. We do not claim ADA compliance or Section 508 compliance or AEA compliance or AODA compliance for sitebrace.com, and we are skeptical of any vendor (including any of our competitors) that does.

What we will claim, in writing, is that sitebrace.com is built to meet WCAG 2.1 Level A and AA, that every changed page is tested against that standard before it ships, that the whole site is scanned monthly, and that we will fix anything that fails or that you report to us. That is the most a technical statement can honestly say. The rest is up to your own legal counsel.

How we audit our own site

Sitebrace.com is audited with the same methodology we ship to customers, against the same catalog of success criteria, on the same release cadence we recommend. If we found a process we did not trust enough to apply to our own marketing site, it would not be in the customer audit.

Automated scan. Every public page on sitebrace.com is run through axe-core, the same open-source rule engine that powers the customer audit. axe-core executes inside a headless Chromium browser driven by Playwright, against the catalog of roughly 90 axe-core rules mapped to WCAG 2.1 A and AA success criteria. The automated pass catches color-contrast failures, missing alt attributes, missing form labels, duplicate ID values, missing language declarations, empty headings, missing landmarks, and the rest of the machine-detectable failure modes. axe-core's published accuracy is that roughly 30 to 40 percent of WCAG issues can be caught automatically; the rest needs a person.

Color contrast. axe-core checks body text and link text against the background for the WCAG 1.4.3 contrast ratio (4.5:1 for body, 3:1 for large text). The palette is intentionally narrow (six text and link tokens, four severity-callout tokens) so contrast is easy to keep right; the tokens are defined in the :root block of _base.html and changing them requires a deliberate edit.

Headings, landmarks, and structure. Every page is built with exactly one H1, a logical H2/H3 outline with no skipped levels, a single main landmark, a header containing a primary navigation landmark, and a footer landmark. The skip link, the navigation, the main content, and the footer are the four top-level regions on every page.

Cadence. Every changed page is scanned with axe-core before it ships, and a scheduled job scans every public page on the live site on the first of each month and opens a ticket if anything fails. Anything it finds is fixed before the next release.

Measures we take

The list below is specific to what is actually in this site's code today, not an aspirational checklist. Open the page source on any page and you can verify each item directly.

• Semantic HTML. Headings, paragraphs, lists, tables, and form fields use their semantic elements (h1 through h4, p, ul, ol, table, label, button) rather than generic div styling. Disclosure widgets on /support and elsewhere use native <details> and <summary> rather than a JavaScript accordion pattern, so they keep keyboard and screen-reader support without us writing any.
• Exactly one H1 per page. Every page in PAGE_REGISTRY renders with exactly one top-level heading inside main. Section headings are H2; sub-section headings are H3.
• Skip link. The first focusable element on every page is "Skip to main content", which jumps focus to #main-content. It is visually hidden until focused and then anchored to the top-left at z-index 100.
• ARIA landmarks. Each page has a <header class="site-header"> with a <nav aria-label="Primary">, a single <main id="main-content">, and a <footer class="site-footer"> with a <nav aria-label="Footer">. Inside main, content is divided into <section> elements each with aria-labelledby pointing at that section's heading.
• Visible focus indicator. A 3-pixel solid outline in the brand link color, applied to all interactive elements (a, button, summary, input, textarea, select) at :focus. The default browser focus ring is never suppressed.
• Sufficient color contrast. Body text on the cream background is dark green-black at well above 4.5:1. Link text uses a darker green that also exceeds 4.5:1 against the same background. Visited links use an even darker shade to keep state distinguishable. The palette is defined once in :root in _base.html and the tokens are reused everywhere.
• Keyboard navigation across the whole site. Every interactive element is reachable, operable, and exit-able with the keyboard alone. The audit intake form, the contact form, and every disclosure on /support are full keyboard citizens.
• Form labels and helper text. Every input on the audit form and the contact form has a visible <label> programmatically associated with the input by for/id. Helper text uses aria-describedby; error text appears in a live region (aria-live="polite") and individual error messages are tied to inputs by the same aria-describedby pattern. Required fields use the native required attribute.
• Descriptive link text. Links read meaningfully out of context: "Get an audit", "Read the privacy policy", "contact form with subject SECURITY". There is no "click here" anywhere on the site.
• Page titles and descriptions. Every page sets a unique <title> and meta description through the Jinja title and description blocks. Open the source on any page; both are present.
• Language declaration. The root <html> element sets lang="en".
• Reduced reliance on color alone. Severity in audit-report mockups is conveyed with both a color token and a written severity label (Critical, Serious, Moderate, Minor). Links are distinguished by both color and underline, not color alone.
• 44-pixel minimum touch targets. Buttons and disclosure summaries have a min-height: 44px rule so they remain operable on touch devices and for users with motor impairments. Form inputs use the same minimum.
• Responsive layout and reflow. The site uses a fluid container (max-width: 56rem) and two breakpoints, at 48em and 30em, with a mobile navigation menu below 48em. Content reflows down to a small mobile viewport without horizontal scrolling and without breaking the heading outline.
• No overlay widget, ever. Site Brace does not sell, recommend, or install accessibility overlays. Overlays are not on the roadmap and never will be. The fix for an inaccessible site is to fix the site, not to inject ARIA at runtime.
• No third-party widgets or fonts. The system font stack is used. There is no chat widget, no embedded video, no marketing pixel. The one third-party script is the cookieless Plausible analytics beacon, which has no visible interface and does not change the page. Everything else the browser loads comes from sitebrace.com itself.

Known limitations

No known accessibility issues on sitebrace.com today. The latest monthly automated scan found no Level A or Level AA failures. We do not run manual testing with screen readers or other assistive technology on this site, and automated testing cannot catch every kind of barrier, so there may be problems we have not seen. If you run into one, please tell us.

If you encounter a barrier on sitebrace.com that we have missed, please tell us via the contact form below. Specific page URL plus the assistive technology you were using is the most useful detail.

Reporting an issue

The fastest way to reach us about an accessibility barrier is the contact form with subject "accessibility". The form routes directly into the same operator inbox we use for security disclosures, with the same response commitments:

• Acknowledgement within one business day. You will get a reply confirming we received your report and have the page in question.
• Substantive response within five business days. That means either a fix shipped, a fix scheduled with a specific release date, or a written explanation of why the issue is not what it appears to be (with a concrete next step you can take).

Helpful details to include, if you have them: the page URL, the specific element or behavior, the assistive technology and version (VoiceOver, NVDA, JAWS, TalkBack, Dragon, keyboard only, screen magnification, switch control), the browser and version, and a screenshot or recording if it helps. None of this is required; the report itself is enough.

If you do not receive an acknowledgement within one business day, the operator has dropped the message. Resend with subject "accessibility - resend" and we will fix the routing.

How we review this page

This page is reviewed on any change that materially affects the accessibility of the site (a new page template, a change to the design tokens in _base.html, a new interactive component, a new third-party dependency, a change in our methodology). When a review changes anything substantive on this page, the review date below is updated and the dateModified on the page's JSON-LD is updated to match.

Last reviewed: September 29, 2026. Latest automated scan of the whole site: September 1, 2026, with no Level A or AA failures found.