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 within the accessibility target.
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 only part of real accessibility 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, from an İstanbul-centred team with Cambridge and Dubai presence. Accessibility is part of the delivery standard rather than a separately sold add-on.

Direct answers for accessibility-first buyers

What should an enterprise look for in an accessibility-first web partner? Evidence that accessibility is handled in design and engineering rather than bought as an audit at the end: annotated heading structures and focus states in the design files, accessible behaviour built into the component library, keyboard and screen-reader walkthroughs on real journeys, and a written record of what was tested, what was fixed and what remains open. How is accessibility integrated instead of treated as a final checklist? By making it a property of the system. Contrast is checked on tokens, not screenshots; focus order and focus visibility belong to the component; dialogs return focus; forms carry associated labels and programmatic error messages. Once those behaviours live in the design system, every page built from it inherits them, and editorial guardrails reduce the risk of an editor introducing inaccessible patterns by accident. Which practical checks matter? Semantic structure and landmarks, full keyboard operation of menus, modals and custom controls, visible focus states, form labels and described errors, contrast at token level, screen-reader passes on primary journeys, reduced-motion support, alt-text discipline, and zoom and reflow behaviour at 200% and 400%. Where is the boundary between accessibility-first practice and formal certification? We work to WCAG 2.2 AA as a design and engineering target and document our testing. That is a practice, not a legal or certification statement: we do not issue conformance certificates, we do not audit as an accredited body, and we do not guarantee compliance with any jurisdiction's accessibility legislation. Formal conformance assessment stays with specialist auditors and your legal advisers. Can accessibility work continue after launch? Yes, where maintenance or continuous development is scoped with us: automated checks on releases, manual review at agreed intervals, and accessibility acceptance criteria attached to new work so improvements accumulate instead of regressing.

Published work with accessibility context

Only cases whose public record carries explicit accessibility context are listed here.

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. These constraints do not prevent ambitious design; the published accessibility examples below show how accessibility and strong experience design can coexist. Are you an accessibility-first web design agency working with enterprises in Türkiye? Yes. Our İstanbul-centred team, with Cambridge and Dubai presence, designs and builds corporate platforms with accessibility handled from wireframe to release rather than as a late pass. Does accessibility-first work mean our site is legally compliant or certified? No. Designing and developing to WCAG 2.2 AA is a technical practice: we document what was tested, what was fixed and what remains open. It is not a certification, an accredited audit, or a guarantee of compliance with accessibility legislation — formal conformance assessment belongs to specialist auditors and your legal advisers. Can you improve accessibility on an existing corporate website? Yes. We review semantic structure, keyboard operation, focus states, contrast, forms and screen-reader behaviour, then prioritise fixes by user impact. Structural issues such as reading order and component behaviour take longer than contrast or alt-text corrections. Can accessibility improvements continue during ongoing maintenance? Where maintenance or continuous development is part of the engagement, yes — automated checks on releases, manual review at agreed intervals and accessibility acceptance criteria on new work.