A page about what we do, what we do not, and where to write.

A non-exhaustive list of the practices we apply when building and maintaining the Site:

• Semantic HTML. We use the right element for the job — headings, landmarks, lists, buttons, links — so the page is meaningful to screen readers and other assistive technologies before any styling is applied.
• Keyboard operability. Every interactive element on the Site can be reached with a keyboard, in a logical tab order, with a visible focus indicator. Try it:Tabmoves forward,Shift + Tabmoves backward,Enteractivates.
• Colour contrast. Body text and interface elements are checked against the WCAG 2.1 AA contrast ratios for the warm-grey and brass palette in use throughout the Site.
• Alternative text. Decorative images carry an empty alt attribute so assistive technology skips them. Meaningful images carry alt text or, in the case of the illustrations that accompany each Insights post, a paragraph- length description in the SVG’s <desc> element.
• Responsive layout. The Site reflows from a wide desktop down to a narrow phone without horizontal scrolling, without overflow, and without content trapped at sizes that cannot be zoomed.
• Headings as structure. Each page is built around a single H1, with H2 and H3 used as structural navigation rather than for typographic emphasis.

Honest disclosure beats marketing language. Three areas where the current Site is short of where we want it to be:

• Motion is on by default. The Site uses scroll-triggered animations, fade-in reveals, and a marquee band in places. We have deliberately not gated these behind the prefers-reduced-motion media query for the current revision because the editorial design depends on motion to read correctly. Visitors who need reduced motion can disable JavaScript in their browser to see the static layout, or use a browser-level animation suppressor. A per-session motion toggle is on our roadmap for a future revision.
• Hand-drawn illustrations carry summary descriptions. The cover illustrations for each Insights post describe the scene as a whole in one paragraph (via the SVG <desc> element), rather than describing each element individually. For most editorial illustration, this is the conventional approach. We acknowledge it leaves some detail unspoken for screen-reader users, and we welcome feedback on specific illustrations where the summary is insufficient.
• The Tulgra screenshot carousel auto-advances. The carousel on the Tulgra page rotates between screenshots on a six-second timer. It pauses on hover and on keyboard focus, and the thumbnails below can be clicked to override the rotation, but we have not yet added an explicit pause button. We will add one in a future revision.

We routinely check the Site with:

• Recent versions of Safari, Chrome, Firefox, and Edge on both macOS and Windows.
• VoiceOver on macOS and iOS, and Narrator on Windows, on a best-effort basis when revising significant sections of the Site.
• Keyboard-only navigation, with no pointing device, to confirm that every interactive element is reachable and that the focus indicator is visible against the page background.
• Browser developer tools (Lighthouse, the Chrome Accessibility panel) for automated checks against WCAG criteria that lend themselves to automation.

Automated tools catch a useful subset of issues but not all of them. If you encounter something that did not surface in our checks, we want to hear about it.

If something on the Site is not working for you — if a control is not reachable from the keyboard, if a screen reader announces something incorrectly, if contrast is failing in a place we missed, or if any other part of the Site is creating a barrier — please write to us:

accessibility@karakorconsulting.com

Tell us the page you were on, the browser and assistive technology you were using, and what you expected to happen. We acknowledge accessibility reports within two business days and we share a plan or a fix within ten business days. If a fix takes longer than that, we explain why and when to expect it.

If email is not the right channel for you, you can also reach us through the contact details on our About page, including by post.

The Site links out to third-party services and content we do not control — Microsoft Forms for Tulgra licence requests, Firebase-hosted installer downloads, external articles and standards documents referenced in Insights posts. Each of those services has its own accessibility posture. Where a third-party tool we rely on creates a barrier, please tell us; we will work with the service’s provider or find an alternative.

The same discipline we bring to a client’s security posture, we bring to our own website. A statement like this one is the accessibility equivalent of the written security posture we recommend to firms: a dated, public document that names what we do, what we do not, who is responsible, and how to reach them.

We update this page when we change something material. The date at the top reflects the most recent revision.