Perceivable
Information and controls are presented in ways people can perceive, including sufficient contrast, text alternatives, adaptable structure, captions where applicable, and support for zoom.
Accessibility statement
We want this site to work for as many people as possible.
Townline builds accessibility into the structure, content, forms, navigation, and testing of this website.
Our commitment
Keyboard, zoom, touch, and assistive technology are part of the build.
We aim to conform to the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA. The standard covers whether content can be perceived, operated, understood, and interpreted reliably by browsers and assistive technologies.
A website changes whenever code, content, documents, or third-party tools change, so accessibility is not a one-time badge. We pair accessible implementation with repeatable tests, written responsibilities, a feedback path, and continued review.
WCAG principles
What we mean by accessible.
Operable
Every interactive element works without a mouse, focus remains visible, targets are comfortably sized, navigation is consistent, and no experience depends on precise movement.
Understandable
Language, labels, navigation, instructions, validation, and errors are written and presented predictably.
Robust
Semantic HTML, appropriate names and roles, valid relationships, and status announcements support modern browsers and assistive technologies.
Current build
What is already in place.
These measures are present in the current Townline website.
StructureSemantic landmarks, one primary heading per page, logical heading order, lists, articles, labels, fieldsets, and descriptive page titles.
KeyboardKeyboard-operable navigation and forms, a skip link, visible focus indicators, native controls, and Escape support for the mobile menu.
Visual presentationHigh-contrast palettes, text that can reflow and zoom, non-color cues, readable spacing, large targets, and no critical text embedded in images.
FormsPersistent labels, instructions, autocomplete tokens, required-field indicators, grouped choices, field-specific errors, an error summary, busy state, and announced delivery status.
MotionNo essential animation or autoplay; decorative transitions are disabled when reduced motion is requested.
Responsive useLayouts adapt across desktop, tablet, mobile, zoom, and narrow viewports without requiring horizontal page scrolling.
Assistive technologyAccessible names, current-page state, expanded state, decorative-content hiding, alert and status announcements, and semantic HTML.
ResilienceForced-color support, usable native controls, progressive content structure, clear errors, and an email fallback when online delivery is unavailable.
Verification approach
Tools help. People still need to test.
Automated checks catch common problems, but they cannot confirm every WCAG requirement or tell us whether a task makes sense to a person using assistive technology.
Automated checks
Markup, names, contrast, form associations, document structure, and common WCAG patterns.
Keyboard review
Reading order, focus order, visible focus, operation, menu behavior, forms, and recovery.
Responsive review
Reflow, 200–400% zoom behavior, text spacing, touch targets, orientation, and content visibility.
Assistive technology
Screen-reader spot checks for structure, navigation, names, state, descriptions, and status changes.
Content review
Plain language, link purpose, instructions, alternatives, heading clarity, and document accessibility.
Ongoing governance
Staff guidance, issue tracking, review cadence, third-party monitoring, and feedback response.
Shared responsibility
New content and outside tools need their own review.
Uploaded PDFs, videos without captions, third-party embeds, external payment systems, and later content changes can introduce barriers even when the core website is accessible.
01Content ownersMaintain meaningful headings, link text, alternatives, tables, instructions, and readable language.
02Document ownersProvide tagged, structured, readable files or accessible HTML alternatives.
03VendorsEvaluate embedded tools and require accessibility evidence and remediation commitments.
04Product teamTest changes, document known issues, prioritize barriers, and respond to feedback.
Accessibility feedback
Tell us if something is getting in your way.
Please include the page, what you were trying to do, and the browser or assistive technology involved when relevant. We aim to acknowledge accessibility feedback within two business days.