Accessibility-first Corporate Web Experience

Accessibility added at the end becomes a list of patches. Accessibility designed in from the first wireframe becomes ordinary quality. This page describes the working practice we use on corporate platforms — what is decided in design, what is enforced in code, and how it is tested before launch.

Decisions made in design

Most accessibility problems are created before any code exists: contrast that fails at small sizes, a layout whose reading order contradicts its visual order, a form that communicates errors only with colour, an interaction that only exists on hover. Designing accessibility-first means resolving those in the design phase — annotating heading structure, defining focus states as part of the component, specifying error and empty states in words, and checking contrast on tokens rather than on final screenshots.

What the practice covers

We work to WCAG 2.2 AA as a design and engineering target. It is a technical standard for the product, not a legal or certification claim.

  • Semantic HTML: landmarks, real headings, lists, buttons and links used for their actual purpose.
  • Full keyboard operation, including menus, modals, carousels, tabs and custom controls.
  • Logical focus order, visible focus styling and focus trapping handled correctly in overlays.
  • Contrast checked at the token level so themes and states stay compliant.
  • Form accessibility: associated labels, described errors, programmatic error announcement, no colour-only signalling.
  • Screen reader passes on primary journeys with at least one desktop and one mobile combination.
  • Reduced-motion support so animation respects the operating system preference.
  • Alternative text discipline for meaningful images and correct hiding of decorative ones.
  • Accessible video and media handling: captions, controls and no autoplay traps.

Accessibility in the design system

On a large platform, accessibility only holds if it lives in the components. A button that manages its own focus state, a dialog that returns focus on close, a field that renders its error correctly — once these behaviours exist in the design system, every page built from them inherits the behaviour. The same applies to editorial guardrails. Component options are constrained so an editor cannot accidentally produce an inaccessible page: no heading level skipping, alt text required where it matters, contrast-safe colour choices only.

How it is tested

Automated tools catch perhaps a third of real issues, so testing combines layers rather than relying on a score.

  • Automated checks in CI on key templates, so regressions surface with the pull request.
  • Manual keyboard-only walkthroughs of the primary journeys.
  • Screen reader verification on the same journeys.
  • Zoom and reflow testing at 200% and 400%, plus text-spacing overrides.
  • Motion-sensitivity and colour-vision checks on data displays and status indicators.
  • A written pre-launch report listing what was tested, what was fixed and what remains open.

Keeping it after launch

Accessibility regresses quietly. A new campaign block, a third-party widget or an editor pasting styled markup can undo months of work, so we treat it as an ongoing check: automated runs on releases, a manual review at agreed intervals and accessibility acceptance criteria on new work. MadeByCat has worked this way across enterprise platforms since 2007 — 950+ projects for 100+ organisations, with teams in İstanbul, Cambridge and Dubai. Accessibility is part of the delivery standard rather than a separately sold add-on.

Frequently asked questions

Do you certify WCAG compliance? No. We design and build to WCAG 2.2 AA as a technical target and document what was tested and fixed. Formal certification or legal conformance statements are outside our scope. Can accessibility be retrofitted to an existing site? Substantially, yes. We audit, prioritise by user impact and fix in phases. Structural problems — reading order, component behaviour, form patterns — take longer than contrast or alt text issues. Is an accessibility overlay widget enough? No. Overlays cannot repair semantics, focus order or form logic. They may complement real work but they do not replace it. Does accessibility limit the design? It constrains some choices — contrast, motion, hover-only interaction — but it rarely limits ambition. Most of our award-recognised work meets these constraints and is stronger for the clarity they force.