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 plus manual methodology 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 it is tested against that standard on every release and on a quarterly cadence, and that we will fix anything that fails. 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 pass. Every rendered page in site/ is run through axe-core, the same open-source rule engine that powers the customer audit. axe-core executes inside a Chromium 131 headless 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.

Manual keyboard pass. The operator drives every interactive element using only the Tab, Shift+Tab, Enter, Space, and arrow keys. Focus must be visible at every step (the global focus ring is a 3-pixel solid outline in the brand link color, applied to a, button, summary, input, textarea, and select). The skip link must take focus on the first Tab on every page. The primary navigation, the audit intake form, the contact form, and every <details> on /support must be fully operable from the keyboard with no mouse. There are no keyboard traps.

Manual screen-reader verification. The operator runs the primary user flows (homepage to audit, audit form, contact form, support FAQ) under VoiceOver on macOS and NVDA on Windows. Heading-level navigation must announce a single H1 per page plus a logical H2/H3 outline; landmark navigation must announce header, navigation, main, and footer in that order; form fields must announce their label, type, required status, and any error text; links must announce text that makes sense out of context.

Color-contrast pass. Body text against the cream background and link text against the same background are verified against 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 verified to have 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. The automated axe-core pass runs on every release as part of the build pipeline (see site_build.py). The full manual pass (keyboard, screen reader, contrast, structure) runs at minimum quarterly and on any major content change. Findings are tracked in the same backlog as customer audit findings and are 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 a single media query at 30em. 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, fonts, or scripts. The marketing site loads nothing from any third party. The system font stack is used. There is no chat widget, no embedded video, no marketing pixel. Every byte loaded by the browser comes from sitebrace.com itself.

Known limitations

No known significant accessibility issues on sitebrace.com today. The last full audit pass (automated plus manual keyboard, screen reader, and contrast) was completed on the review date below and found no outstanding Level A or Level AA failures.

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 the same cadence as the manual audit pass: at minimum quarterly, and 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: May 10, 2026.

Next scheduled review: August 2026 (quarterly cadence), or sooner if material changes ship.