Placeholder for layout testing only. This sample accessibility statement has not been approved by the client and does not claim certification or legal compliance. Replace bracketed fields and validate every stated measure against the final production site before launch.
Statement date: [STATEMENT DATE]
Last reviewed: [LAST REVIEW DATE]
Our Accessibility Commitment
[COMPANY LEGAL NAME] is committed to providing an inclusive online experience for visitors with disabilities. Our goal is to make information about the Disney Princess Experience perceivable, operable, understandable, and robust for as many people as reasonably possible, including people who use assistive technologies. This placeholder statement is included so the design can be tested with substantial content. The final statement should describe only measures that have been implemented and verified.
Accessibility Goal
The project is being developed with the Web Content Accessibility Guidelines (WCAG) 2.2 Level AA as a design and testing reference. This sentence describes a development goal, not a certification or warranty that every page, component, document, video, third-party service, or future update fully conforms. The final site should be evaluated before launch and periodically thereafter.
Measures Included in the Build
Current technical and editorial measures intended to support accessibility include:
- A “skip to content” link for keyboard users.
- Semantic page regions, heading structure, navigation markup, form labels, and descriptive page titles.
- Visible keyboard focus indicators and controls that can be reached without a mouse.
- Responsive layouts designed to reflow for phone screens and browser zoom.
- Text and interactive colors selected with contrast in mind.
- A reduced-motion mode that respects the visitor’s operating-system preference.
- Text alternatives for meaningful images and empty alternative text for decorative imagery, where appropriate.
- A click-to-load video preview so the page remains usable before the third-party player is activated.
- Live HTML text for headings, descriptions, labels, and legal copy instead of baking essential words into raster images.
Keyboard Navigation
Visitors should be able to move through primary navigation, video controls, form fields, buttons, and footer links using standard keyboard commands. Focus should follow a logical visual order and remain visible. The final site should be tested with Tab, Shift+Tab, Enter, Space, and relevant arrow-key interactions. Keyboard traps, hidden controls, and unexpected focus changes should be treated as defects.
Visual Presentation and Readability
The layout is intended to support browser zoom and responsive reflow without requiring two-dimensional scrolling for ordinary text content. Visitors may use browser or operating-system tools to enlarge text, adjust color settings, or increase contrast. Images that contain decorative lettering may be accompanied by equivalent live text where the information is necessary to understand or use the page.
Long legal pages use readable line lengths, scalable type, section headings, lists, and horizontally scrollable data tables. These features should be checked at common zoom levels, at narrow viewport widths, and with user styles where practical.
Forms and Error Messages
Form controls should have programmatically associated labels, clear instructions, meaningful error messages, and a logical focus order. Required fields should not be communicated by color alone. If the Royal List form is connected to an email service provider, its validation, consent control, success message, failure message, and unsubscribe process should be reassessed after integration.
Video, Audio, and Motion
Final video content should include accurate captions for spoken dialogue and meaningful sound, and audio-described or text-based alternatives when needed to communicate important visual information. The embedded player should expose accessible controls. Autoplay with sound should be avoided. Any animation or motion added later should respect reduced-motion preferences and should not flash at a rate that could create a seizure risk.
Supported Browsers and Assistive Technologies
The final site is intended to work with current major browsers, including recent versions of Chrome, Safari, Firefox, and Edge, on supported desktop and mobile operating systems. Testing should include representative screen-reader and browser combinations selected by the client’s accessibility team, such as VoiceOver with Safari, NVDA with Firefox or Chrome, and TalkBack with Chrome. Older or unsupported software may not provide the same experience.
Third-Party Content
Some functionality may be supplied by third parties, including Vimeo, ticketing services, venues, maps, social networks, or email providers. Although the project team can select, configure, and report issues with these services, it may not control their source code or accessibility roadmap. The final statement should identify material third-party limitations and offer an accessible alternative path whenever one is reasonably available.
Known Limitations
The following items must be reviewed before the final statement is approved:
- [KNOWN LIMITATION OR “NONE IDENTIFIED IN MOST RECENT REVIEW”].
- [STATUS OF VIDEO CAPTIONS, TRANSCRIPT, AND AUDIO DESCRIPTION].
- [STATUS OF THIRD-PARTY TICKETING AND CONSENT TOOLS].
- [DATE AND SCOPE OF THE MOST RECENT MANUAL ASSISTIVE-TECHNOLOGY TEST].
A known issue should include a plain-language description, affected content or function, available workaround, remediation owner, and estimated correction date when feasible. A limitation should not be removed from the statement until the correction has been verified.
Feedback and Assistance
If a visitor encounters an accessibility barrier or needs information in another format, the final site should provide a monitored contact method. Helpful details may include the page address, the feature involved, the browser or assistive technology used, and a description of the problem. Visitors should not be required to disclose a disability to request general assistance.
Email: [ACCESSIBILITY EMAIL]
Telephone: [ACCESSIBILITY TELEPHONE]
Mail: [COMPANY LEGAL NAME], Attn: Accessibility, [MAILING ADDRESS]
Target response time: [NUMBER] business days. If an immediate event-related accommodation is needed, contact [EVENT OR VENUE ACCESSIBILITY CONTACT] using [APPROVED CONTACT METHOD].
Assessment and Continuous Improvement
Accessibility should be incorporated into design review, content entry, code review, quality assurance, vendor selection, and release management. Automated tests can identify some issues but do not replace keyboard, zoom, contrast, screen-reader, caption, and usability review by qualified people. New pages, plugins, campaigns, forms, and embedded tools should be checked before release.
The final statement should record the assessment method, scope, reviewer, date, and planned review cadence. Feedback trends should be used to prioritize improvements, and editors should receive guidance for headings, link text, alternative text, tables, and media descriptions.
Statement Updates
This statement should be updated when the site changes materially, when a significant accessibility issue is identified or corrected, or after a scheduled reassessment. The “Last reviewed” date should reflect a real review rather than an automated publishing date.
End of placeholder accessibility copy. Validate every claim and replace with client-approved language before launch.