Accessibility statement

Design for more than a pointer and a large screen

Navigation, menus, links, buttons, accordions, and forms should work by keyboard without a trap. Focus should remain visible and return sensibly when a menu closes. Headings, landmarks, lists, tables, labels, errors, and status messages should convey structure to assistive technology. The layout should remain usable when text is enlarged and at narrow widths without forcing sideways reading. Colour cannot be the only way to show state. Images need useful alternative text when they carry meaning and empty alternatives when they are decorative. Motion should respect the user's reduced-motion preference, and important information should never depend on animation. These rules apply to shared templates first because one defect there reaches many pages. New components require keyboard, screen-reader, zoom, contrast, and responsive review before they become part of the site.

Retest shared components after every change.

• Keyboard access and visible focus
• Semantic structure and labelled controls
• Zoom and narrow-screen reflow
• Text alternatives and non-colour cues
• Reduced-motion support

Make forms recoverable

A consultation form should identify every field, explain required information, and give errors next to the problem in language that helps a person fix it. Error summaries and status changes should be announced to screen readers. Keyboard focus should move only when that movement helps. Time limits, character limits, consent choices, and submission results need visible and programmatic communication. A failed delivery must not look like success. Repeated submission should not create duplicate enquiries. The form should not rely on placeholder text as its only label or use colour alone for errors. People may use voice input, password managers, browser autofill, zoom, or assistive technology, so standard controls are preferred. Before launch, test empty, malformed, too-long, keyboard-only, screen-reader, and server-failure paths with the real endpoint. Current privacy and security duties remain separate from accessibility.

• Persistent labels and clear requirements
• Specific, announced error messages
• Keyboard and assistive-technology flow
• Truthful success and failure states
• Real endpoint tested before launch

Write content people can find and understand

Page titles and first headings should identify the subject. Heading levels need a meaningful order instead of being chosen for size. Link text should describe its destination without requiring the surrounding sentence. Long guidance benefits from short paragraphs, direct language, descriptive section headings, and lists only where the information is genuinely list-shaped. Tables need headers and should not be used to force visual layout. Acronyms and specialist terms should be explained at first meaningful use or linked to the glossary. Source links should identify the issuing authority and document. Downloads need file type and purpose where that is not obvious. Content editors should avoid text embedded in images and verify that alternative text does not repeat nearby captions. Accessibility is part of editorial review, not a correction applied after the page is published.

• Descriptive titles, headings, and links
• Readable paragraphs and purposeful lists
• Structured tables and explained acronyms
• Clear source and download labels
• No essential text trapped in images

Test, report, and avoid overclaiming

Takelegal should maintain a test matrix covering representative desktop and mobile sizes, keyboard operation, screen-reader checks, zoom, contrast, reduced motion, form errors, and page structure. Automated tools can find missing labels or contrast failures, but manual testing remains necessary. User reports take priority because they identify a real barrier in context. A report should include the page, task, device or browser if known, assistive technology if the user wishes to share it, and a way to respond. Do not require a disability disclosure. Record the issue, impact, owner, workaround, fix, and verification. Publish known limitations when they materially affect use and provide an alternative route where possible. This statement should be reviewed when the design, forms, contact route, or testing status changes. Formal conformance should be claimed only after appropriate assessment supports it.

• Manual and automated test record
• Barrier report without required diagnosis
• Owner, workaround, fix, and verification
• Known limitation disclosed where material
• No unsupported conformance claim