Accessibility
Accessibility Statement
ThatDevPro is committed to making the web usable for everyone, regardless of ability, device, or assistive technology. This page describes how we approach accessibility on thatdevpro.com and in the work we deliver for clients.
Our commitment
We build accessible-by-default. Every page we hand-code starts from semantic HTML, keyboard operability, and sufficient color contrast — not as a retrofit, but as the foundation. Accessibility is not a plugin we bolt on at the end; it is part of how we structure markup, name controls, and test before launch.
Accessibility is also a service we sell. As an SDVOSB (Service-Disabled Veteran-Owned Small Business) studio that works with government-adjacent and public-facing organizations, we remediate existing client sites toward Section 508 and WCAG conformance — auditing markup, fixing focus and contrast issues, adding meaningful alternative text, and re-testing with keyboard and screen-reader workflows.
Conformance status
We target WCAG 2.2 Level AA and Section 508 (which references WCAG 2.0 Level AA as its technical baseline) for this website.
To be transparent about what that means: this is a self-assessment. We have evaluated this site against WCAG 2.2 Level AA success criteria using a combination of manual review, keyboard testing, and automated tooling. Based on that review, we believe this site substantially conforms to WCAG 2.2 Level AA. "Substantially conforms" means most of the site meets the standard, with the possibility of isolated exceptions noted below.
We have not commissioned an independent third-party audit or VPAT (Voluntary Product Accessibility Template) for this website. We do not claim certified or audited conformance. If an exception or barrier is identified, we treat it as a defect and fix it.
What we do
Concretely, on this hand-coded static site we apply the following practices:
- Semantic HTML
- Content uses native elements — headings in logical order, landmarks (
main,nav,header,footer), lists, and tables — so assistive technology can convey structure correctly. - Keyboard operability
- All interactive elements are reachable and operable with a keyboard alone, in a logical tab order, without keyboard traps.
- Visible focus
- Interactive elements show a clearly visible focus indicator so keyboard users can always see where they are on the page.
- Color contrast
- We aim for a contrast ratio of at least 4.5:1 for normal body text against its background, meeting WCAG AA for text, and we do not rely on color alone to convey meaning.
- Text alternatives
- Meaningful images carry descriptive
alttext; decorative images are marked so they are skipped by screen readers. - ARIA used sparingly
- We prefer native HTML semantics and add ARIA only where a native element cannot express the role or state — following the principle that no ARIA is better than bad ARIA.
- Reduced motion
- Animations and motion effects respect the
prefers-reduced-motionsetting, reducing or removing non-essential motion for visitors who request it. - Responsive zoom
- The layout reflows and remains usable when text is enlarged or the page is zoomed to 200%, without loss of content or horizontal scrolling traps.
- Form labels
- Form fields have programmatically associated labels, and error and instructional text is conveyed in a way assistive technology can read.
Known limitations
We want to be honest about where gaps may exist. Despite our efforts, some content may not yet fully conform:
- Embedded third-party content. Maps, embeds, scheduling widgets, or media players supplied by external providers are outside our direct control and may not fully meet WCAG 2.2 AA. Where possible, we provide an accessible alternative path to the same information.
- Legacy and downloadable documents. Older PDFs or files that predate our current standards may not be fully tagged or accessible. If you need an accessible version of a specific document, contact us and we will provide one.
- Newly published content. Occasionally a recently added page or image may briefly lag our standard before review. We correct these as they are found.
If you encounter a barrier not listed here, please tell us — see Feedback below.
Feedback and reporting an issue
If you experience any difficulty accessing content on this site, or if you have a suggestion for how we can improve, we want to hear from you. Please include the page address, a short description of the problem, and the browser and assistive technology you were using if you know them — that detail helps us reproduce and fix the issue quickly.
You can reach us through the contact page. We aim to acknowledge accessibility reports within 5 business days and to provide a path to the information or function you were trying to reach while we work on a permanent fix.
Date of last review
This statement and the accessibility of this site were last reviewed in June 2026. We revisit it as the site changes and as standards evolve.