Accessibility Statement

1. Our commitment

Byte Clarity believes a useful website is an accessible one. This statement describes the standards we hold ourselves to on byteclarity.com, what we've done to meet them, and where we know we have work left to do. We treat accessibility as an ongoing practice — not a checkbox we tick once — and we update this statement as the site evolves.

Accessibility also reflects how we serve our clients. Byte Clarity builds and operates technology for small businesses; we consider accessibility part of delivering "IT that works." We expect the same of our own property.

2. Standards we follow

This site targets conformance with the Web Content Accessibility Guidelines (WCAG) 2.1 at Level AA, published by the World Wide Web Consortium (W3C) and widely adopted as the practical baseline for commercial websites in the United States. Level AA addresses the majority of barriers faced by users with disabilities, including users of screen readers, users with low vision, users with color-vision deficiency, users with motor impairments relying on keyboard navigation, and users with cognitive or reading disabilities.

In addition, we aim to meet select WCAG 2.1 Level AAA criteria where those criteria improve the experience without compromising brand expression or visual hierarchy. We are transparent below about which AAA criteria we do and do not conform to, and why.

Our accessibility approach is also informed by:

• Americans with Disabilities Act (ADA) — as interpreted by U.S. federal courts, which increasingly treat WCAG 2.1 AA as the practical standard for accommodations on commercial websites
• Section 508 of the Rehabilitation Act (as amended) — harmonized with WCAG 2.0 AA for federal contexts; relevant to our public-sector adjacent work
• California Unruh Civil Rights Act — our primary client base is in California, and Unruh claims increasingly reference WCAG conformance

3. What we conform to (Level AA)

We actively design and develop to meet, among others, these Level AA criteria:

• Color contrast (1.4.3) — body text maintains at least a 4.5:1 contrast ratio against its background, and large text (18pt+ or 14pt bold) at least 3:1
• Non-text contrast (1.4.11) — interactive controls (buttons, form fields, focus indicators) have at least 3:1 contrast against adjacent colors
• Reflow (1.4.10) — content reflows without horizontal scrolling at 320 CSS pixel widths, and supports browser zoom up to 400%
• Text spacing (1.4.12) — line height, paragraph spacing, and letter spacing can be adjusted by user preference without breaking layouts
• Keyboard operable (2.1.1, 2.1.2) — every interactive element on the site can be reached and used with a keyboard alone, with no traps
• Focus visible (2.4.7) — the currently-focused element is always visibly indicated; we use styled focus rings that match our brand palette rather than removing them
• Multiple ways to navigate (2.4.5) — header navigation, footer navigation, and an HTML sitemap are provided; most major content is reachable from at least two paths
• Consistent navigation and identification (3.2.3, 3.2.4) — the header, footer, and key interactive components behave consistently on every page
• Labels and error messages (2.4.6, 3.3.3) — form fields have visible labels and clear validation errors that describe how to fix the problem
• Status messages (4.1.3) — confirmations, errors, and notifications are exposed to assistive technology via appropriate live-region semantics
• Language of page (3.1.1) — the site declares its primary language in the HTML lang attribute for screen-reader pronunciation
• Semantic structure — headings are used in hierarchical order, landmark roles (header, main, nav, footer) are applied, and lists are marked up as lists
• Image alternatives (1.1.1) — informative images have descriptive alt text; decorative images use empty alt="" so they are skipped by screen readers

4. AAA criteria we also aim for

We selectively adopt the following Level AAA criteria because they benefit users without compromising design:

• Keyboard (No Exception) (2.1.3) — every function is operable by keyboard, including the cookie-preferences modal and mobile menu
• Three Flashes (2.3.2) — no content flashes more than three times per second anywhere on the site
• Section Headings (2.4.10) — long-form pages (blog posts, policies, the homepage) use descriptive section headings throughout
• Consistent Identification — equivalent functionality (e.g., primary CTA buttons) uses consistent labels across the site
• No Interruptions (2.2.4) — the cookie banner is the only potentially interrupting element, and it respects the Global Privacy Control signal so users who have already expressed a preference are not interrupted

5. AAA criteria we don't target — and why

Some WCAG AAA criteria carry design or content tradeoffs we think degrade the experience for most users without meaningfully improving it for users with disabilities. We do not currently target these:

• Contrast (Enhanced) 7:1 (1.4.6) — AAA requires a 7:1 contrast ratio for body text. We maintain the AA 4.5:1 ratio, which is comfortable for the vast majority of readers and preserves our visual design.
• Visual Presentation (1.4.8) — AAA mandates constraints like paragraphs never exceeding 80 characters wide, no justified text, and user-selectable background/ foreground colors. We use well-tuned typographic defaults and do not implement user-customizable color controls.
• Images of Text (No Exception) (1.4.9) — we use real text wherever practical; a small number of branded graphics include stylized text for design reasons.
• Low or No Background Audio (1.4.7), Audio Description (Extended) (1.2.7), Sign Language (1.2.6) — we do not currently publish audio or video content. If we add it in the future, we will publish captions at AA level and revisit AAA criteria at that time.
• Link Purpose (Link Only) (2.4.9) — AAA requires every link to be self-descriptive without relying on surrounding context. We write clear link text but occasionally rely on nearby content ("read more" following a card headline, for example).
• Reading Level (3.1.5) — AAA mandates content at a lower-secondary reading level where possible. Much of our content is technical — describing IT, cybersecurity, and compliance concepts — and we would have to strip detail to hit this target. We aim for plain English but not a reading-grade ceiling.
• Pronunciation (3.1.6), Unusual Words (3.1.3), Abbreviations (3.1.4) — glossaries and pronunciation markup for every technical term would be disproportionate to the benefit. We define uncommon terms on first mention in-line.
• Context-Sensitive Help (3.3.5) — our forms are short and simple enough that field-level help isn't necessary. We will revisit this if we add longer multi-step forms.
• Error Prevention (All) (3.3.6) — we apply error prevention (review and confirm) to legal, financial, and data-modification actions (3.3.4 at AA), but not to every form submission. Most submissions are low-stakes contact requests where confirmation steps would add friction without meaningful benefit.

6. Accessibility features we've built in

• Skip navigation link at the top of every page for keyboard and screen-reader users to bypass repeated header content
• Reduced-motion support — the site honors the prefers-reduced-motion media query and reduces animation duration for users who prefer it
• Keyboard-accessible modals — the cookie preferences modal traps focus correctly, closes on Escape, and on click outside the dialog
• Accessible cookie consent banner — the consent banner uses role="dialog" with aria-label and live-region announcements
• Structured headings — every page has a single H1, with H2/H3 used for hierarchical sections so assistive technologies can outline the content
• Named form controls — every form input is labeled, and error messages are associated with their fields programmatically
• Alt text on meaningful images — decorative images are marked as such so screen readers don't announce them
• Non-color cues — we do not rely on color alone to convey meaning (for example, required fields are marked with text, not just red color)

7. Known issues and limitations

Accessibility is ongoing work. Items we know about or are actively improving:

• Some older blog posts migrated from our previous brand use images whose alt text was auto-generated by the prior platform. We are reviewing and rewriting these as we port posts.
• The HubSpot chat widget, when enabled, inherits its accessibility behavior from HubSpot. We rely on HubSpot's published conformance documentation; limitations there are outside our direct control.
• Third-party content we link to (vendor documentation, external articles) may not meet WCAG 2.1 AA. We do not assert conformance for content we do not control.
• Embedded video, when we add it, will include captions; transcripts and audio descriptions will follow as production capacity allows.

8. Assistive technology compatibility

We test against current versions of the following:

• Screen readers — VoiceOver (macOS and iOS), NVDA (Windows), JAWS (Windows)
• Browsers — current and previous major versions of Safari, Chrome, Firefox, and Edge
• Operating systems — recent releases of macOS, iOS, Windows, iPadOS, and Android
• Input devices — keyboard-only navigation, touch, mouse, pointer, and voice control

9. How we evaluate the site

Our accessibility process combines automated and manual review:

• Automated checks — we run axe-core and Lighthouse accessibility audits during development and before releases
• Manual keyboard testing — every interactive flow is walked through with Tab, Shift+Tab, Enter, Space, and Escape keys
• Screen-reader spot checks — key pages are tested with VoiceOver (macOS) before release; broader screen-reader coverage is applied during quarterly reviews
• Color-contrast audits — design tokens and component variants are measured against WCAG contrast ratios before being promoted into the shared palette

Automated tools catch an estimated 30-50% of accessibility issues. We treat them as a floor, not a ceiling, and manual testing is required before we claim conformance for a new page or component.

10. Report an accessibility issue

If you encounter an accessibility barrier — a page or feature you can't use with your assistive technology, content that's unclear or unreadable, a form you can't complete — please tell us. We treat accessibility reports as priority fixes.

When reporting, it helps (but is not required) to include:

• The page URL where the issue occurred
• A description of what you were trying to do and what went wrong
• Your assistive technology (screen reader, browser, operating system versions)
• How you'd like us to respond (email, phone, or other)

You can reach us through any of the following:

• Email: info@byteclarity.com with "Accessibility Report" in the subject line
• Phone: (279) 799-7583 during business hours
• Mail:
  Douglas Business Group LLC
  30 N Gould St Ste 5769
  Sheridan, WY 82801

We aim to acknowledge accessibility reports within two business days and to resolve or provide an interim remediation within ten business days. For issues that require a longer fix, we will stay in touch with you on progress.

11. Alternate formats

If any content on the site is not accessible to you and you need information in an alternate format — large print, plain-text, audio description, or a direct conversation — contact us at info@byteclarity.com. We will provide the information in a format that works for you at no additional cost.

12. Feedback beyond conformance

WCAG conformance is a baseline — not a complete picture of what makes a site usable. If you have ideas for making the site clearer, faster, or easier to use, even if they fall outside a specific WCAG criterion, we want to hear them. Email info@byteclarity.com with your thoughts.

13. Updates to this statement

We review this statement quarterly and after any major site change. The "Last reviewed" date at the top of this page reflects the most recent review. When we make material changes to our accessibility practice, we update this statement and — where appropriate — notify subscribers of the change.

---

This accessibility statement describes our current practice on byteclarity.com. Services we deliver to clients under a Master Services Agreement may have separate accessibility obligations governed by that agreement, particularly in healthcare, public-sector, and education engagements.