At a glance
- WCAG 2.2 Level AA is Meridian's accessibility target for the public website.
- No conformance claim is made until complete automated and knowledgeable human evaluation is documented.
- Accessibility should be considered throughout design, development, content publishing, procurement, release review, and maintenance.
- People who encounter a barrier should have a direct way to report it and request the information or service in an accessible alternative.
1. Commitment to accessibility
Meridian is committed to improving access to its website for people with disabilities and for people using different devices, input methods, browsers, settings, and assistive technologies.
Accessibility is an ongoing responsibility across strategy, design, engineering, content, quality assurance, procurement, and maintenance.
Perceivable
Information and interface components should be presented in ways people can perceive, including text alternatives, adaptable structure, captions where required, and sufficient visual distinction.
Operable
Navigation and controls should work with a keyboard and other input methods, provide enough time, avoid harmful motion or flashing, and make focus and location understandable.
Understandable
Content, navigation, instructions, labels, validation, and interactions should be readable, predictable, and helpful when people make or correct mistakes.
Robust
Content should use valid semantics, accessible names, roles, states, and values so it works reliably with current and future browsers and assistive technologies.
2. Scope of this statement
This statement is intended to cover Meridian's public website and public content controlled by Meridian. The exact domain, included subdomains, languages, documents, payment flows, and embedded services must be confirmed during assessment.
Client websites and systems created or supported by Meridian are governed by their respective owners, requirements, agreements, and accessibility statements.
The restricted content-management studio and third-party provider interfaces may be governed partly by provider accessibility practices and may require separate assessment.
3. Accessibility standard and conformance status
Meridian has selected WCAG 2.2 Level AA as the target for the public website. Level AA requires satisfaction of all applicable Level A and Level AA success criteria across complete pages and responsive variations.
The current status is not evaluated. This statement does not claim certification, verified compliance, full conformance, or the absence of barriers.
Meridian does not currently claim WCAG conformance. A complete evaluation has not yet been documented, so Level AA is a target rather than a certification or verified result. Web Content Accessibility Guidelines 2.2
4. Measures supporting accessibility
The measures listed above define the intended operating standard for requirements, design, implementation, content, testing, third-party selection, feedback, and continuous improvement.
A measure should not be described publicly as implemented until there is evidence that the relevant process is active and repeatable.
Accessibility Requirements
Include accessibility targets and acceptance criteria in website, component, content, and feature requirements.
Accessible Design System
Build reusable components with documented keyboard behavior, focus treatment, states, semantics, contrast, motion, and content guidance.
Semantic Implementation
Prefer native HTML and use WAI-ARIA only where needed, with correct relationships, labels, names, roles, states, and values.
Accessible Content Practices
Provide descriptive headings and links, meaningful alternatives for non-text content, plain language, transcripts or captions where required, and accessible documents.
Keyboard and Focus Quality
Ensure every interactive function is keyboard operable, focus remains visible and logical, and overlays or dynamic interfaces manage focus appropriately.
Responsive and Adaptable Experiences
Support zoom, text spacing, reflow, different orientations, reduced motion, and small or magnified viewports without losing essential information or functionality.
Layered Testing
Combine automated checks with manual keyboard, visual, semantic, screen-reader, browser, device, and task-based evaluation.
Release Review
Treat unresolved high-impact accessibility barriers as release risks and document any accepted limitation with an owner and remediation plan.
Feedback and Remediation
Provide a direct reporting channel, acknowledge barriers, offer reasonable alternatives, prioritize fixes by user impact, and communicate progress.
Third-Party Evaluation
Consider accessibility when selecting and integrating payment, scheduling, analytics, media, maps, forms, documents, and other external services.
Training and Ownership
Assign responsibilities and give designers, developers, authors, reviewers, and decision-makers the knowledge needed for their accessibility role.
Continuous Improvement
Review accessibility after material changes, monitor recurring issues, and improve components and publishing practices rather than treating accessibility as a one-time audit.
5. Expected accessible experience
The expected-features list describes the behaviors Meridian intends to support. It is a quality checklist and not evidence that every feature currently passes on every page.
Where a feature cannot immediately be made accessible, Meridian should provide an effective alternative and document the limitation and remediation plan.
- Logical heading structure and page landmarks
- Descriptive page titles, links, buttons, labels, and instructions
- Keyboard access to all interactive functions
- Visible focus and logical focus order
- Skip or bypass mechanisms for repeated content
- Text alternatives for informative images and controls
- Captions, transcripts, or alternatives for time-based media when applicable
- Sufficient color contrast without relying on color alone
- Content that supports zoom, text spacing, and responsive reflow
- Forms with programmatic labels, clear errors, and correction guidance
- Controls with appropriate target size and alternatives to complex gestures
- Reduced or controllable animation and no unsafe flashing
- Consistent navigation and identification
- Status messages available to assistive technologies where needed
- Accessible downloads or an accessible HTML alternative
6. Technical specifications and compatibility
The website relies on web technologies listed above. Accessibility depends on those technologies working together with browsers, operating systems, assistive technologies, user settings, authored content, and third-party services.
Tested browser and assistive-technology combinations will be published only after they have been evaluated and documented.
Technologies relied upon
- HTML
- CSS
- JavaScript
- WAI-ARIA
- SVG
Compatibility to be tested
- Current versions of major desktop and mobile browsers
- Keyboard-only and keyboard-equivalent input
- Representative screen readers on desktop and mobile
- Browser zoom, text enlargement, and text-spacing overrides
- High-contrast, forced-colors, dark-mode, and reduced-motion preferences
- Touch, pointer, voice, switch, and other alternative input where relevant
What you need
- A reasonably current browser with accessibility support
- JavaScript enabled for interactive features that require it
- Assistive technology configured and used according to its supported browser combinations
7. Assessment approach
Automated tools can identify some problems but cannot determine overall accessibility or WCAG conformance. Meridian's assessment should combine automated checks with knowledgeable manual evaluation and real task testing.
The assessment record should identify the scope, sample, environments, tools, methods, findings, exceptions, evaluator, and date.
Assessment status
Planned self-evaluation supported by automated testing, expert manual review, assistive-technology testing, and user evaluation where practical.
- Automated testing completed: No
- Expert manual testing completed: No
- Keyboard testing completed: No
- Assistive-technology testing completed: No
- User testing with disabled people completed: No
8. Known limitations and alternatives
Known limitations have not yet been established because the required evaluation is pending. After assessment, each material barrier should be explained in plain language with its impact, available alternative, status, owner, and expected resolution date.
Third-party content outside Meridian's control should be identified separately, together with any available accessible alternative or provider contact route.
No verified limitations are listed because a complete evaluation has not yet been documented. An empty list is not a claim that the website has no accessibility barriers.
9. Feedback and assistance
People who encounter a barrier can use the accessibility-feedback route. Meridian should acknowledge the report, investigate it, provide an accessible alternative where practical, and communicate the remediation plan.
A monitored accessibility email, response-time target, and escalation process must be established before this statement is final.
Report an accessibility barrier
If you cannot access content, complete a task, or use a feature, contact Meridian. The report will be reviewed and Meridian will work to provide a reasonable alternative and address the underlying barrier where possible.
- The page address or name of the affected content
- The task you were trying to complete
- A description of the barrier and any error message
- Your browser, device, operating system, and assistive technology if you are comfortable sharing them
- The format or alternative that would help you access the information or service
- A preferred contact method for the response
10. Third-party content and services
Payment, scheduling, maps, media, social content, documents, analytics, forms, and other external services may have accessibility characteristics controlled by their providers.
Meridian should consider accessibility during selection and integration, avoid unnecessary barriers, provide alternatives where practical, and report issues to the responsible provider.
11. Continuous improvement
Accessibility should be reviewed throughout development and after material changes, not only after launch. Reusable fixes should be applied at the component or content-system level wherever possible.
Meridian should review barrier reports, audit results, recurring defects, third-party limitations, and publishing practices to prioritize improvements by user impact.
12. Approval and statement maintenance
No individual has formally approved this statement. Before publication, Meridian should assign an accountable owner who can approve the target, scope, assessment status, limitations, feedback process, and review schedule.
The statement should be updated after material accessibility changes, completed assessments, or significant new limitations, and should otherwise be reviewed on a defined schedule.