Accessibility Statement

1. Our commitment

Classical Not Classical™ is a concert built on the idea that the orchestra belongs to everyone. The same idea applies to this website. We are committed to making classicalnotclassical.com and news.classicalnotclassical.com accessible to people with disabilities, including people who are blind or have low vision, people who are deaf or hard of hearing, people with motor impairments who navigate by keyboard or switch, and people with cognitive or vestibular conditions who are sensitive to motion.

Accessibility is treated as part of the design, not a layer on top of it. We do not use automated accessibility “overlay” widgets; we fix the underlying code instead.

2. The standard we work to

Our baseline is the Web Content Accessibility Guidelines (WCAG) 2.1, Level AA, published by the World Wide Web Consortium (W3C). It is the level most widely applied by U.S. courts and most widely recognized by the disability community, which is why we hold ourselves to it.

We also test against the newer WCAG 2.2 Level AA criteria and treat them as our direction of travel. Where this statement claims conformance, it claims it against 2.1 AA; where we have met a 2.2 criterion we say so specifically.

We also follow the relevant parts of the WAI-ARIA Authoring Practices for custom interface elements such as our video controls.

3. Conformance status

Classical Not Classical is partially conformant with WCAG 2.1 Level AA. “Partially conformant” means that most of the content conforms to the standard, and that some content or functionality, described in section 5 below, does not yet fully conform or depends on third-party services we do not control.

On the review date shown at the top of this page, automated testing of every page returned no Level A or Level AA violations, and we separately verified that every text and background colour pair in the site’s palette exceeds the 4.5:1 contrast minimum. Section 6 describes exactly what we tested and how. We are deliberately not claiming full conformance, because some criteria — notably those involving the embedded video player and testing with real assistive-technology users — we have not yet been able to verify to that standard.

4. What we have done

Measures we have taken to make the site accessible include:

• Semantic structure. Every page has a single main landmark, a logical heading order beginning with one h1, labeled navigation and footer landmarks, and a “Skip to main content” link that appears as the first focusable element on every page.
• Keyboard access. All navigation, links, buttons, video players, and form fields can be reached and operated with a keyboard alone. Custom video controls expose play, pause, seek (arrow keys, Home, End), and full screen to the keyboard, and report their state to assistive technology.
• Visible focus. A consistent, high-contrast gold focus indicator is shown on every interactive element when navigating by keyboard.
• Color and contrast. The site uses a fixed palette of five text colors on three background shades. We have computed all fifteen combinations: the lowest is 5.10:1 and the highest 17.48:1, so every pairing clears the 4.5:1 minimum for normal text with room to spare. Links inside running text are underlined so they do not rely on color alone.
• Text alternatives. Every meaningful image, including the wordmark, the subtitle art, and photographs, carries descriptive alternative text. Purely decorative graphics are hidden from screen readers.
• Motion control. The hero sketch animation plays once and stops; it can be paused with a control that becomes visible when it receives keyboard focus. The scrolling list of featured artists pauses on hover and focus and has a visible pause button. Both are disabled automatically when your operating system’s “reduce motion” preference is on. Nothing on the site flashes.
• Forms. Every field in the booking form has a visible, programmatically associated label. Required fields are marked, browser-native validation messages are used, and success and error states are announced to screen readers through a live region as well as shown visually.
• Resizable, reflowable text. The site is built with relative units and responsive layouts, and pinch-to-zoom is not disabled on mobile devices. We have not yet completed a systematic audit of every page at 200% text zoom and at a 320-pixel viewport width, so we are not claiming that criterion; it is on our list, and we will say so here when it is done.
• Language and titles. Every page declares its language and has a unique, descriptive title.
• Privacy-respecting defaults. Analytics do not load unless you opt in, and a Global Privacy Control or Do Not Track signal is honored automatically without even showing you a banner. Fonts and video thumbnails are served from our own server. The practical accessibility benefit is that pages carry far less third-party script, which makes them faster and more predictable for assistive technology.
• Reduced motion, everywhere. Both the main site and the newsroom respect your operating system’s “reduce motion” setting. With it on, scroll animations, parallax, and the consent banner’s slide-in are all disabled.

5. Known limitations

Despite our best efforts, the following limitations exist. We list them so that you know what to expect and can tell us if a workaround does not work for you.

Embedded video players (YouTube)

Performance videos are hosted on YouTube and played through YouTube’s embedded player, which we do not control. Our own overlay provides accessible play, pause, seek, and full-screen controls, but the underlying player’s accessibility (for example, caption rendering and settings) depends on YouTube. If you have difficulty with an embedded player, every video is also available directly on YouTube, where the platform’s full accessibility features are available.

Captions and audio description for music performances

The videos on this site are instrumental music performances with no spoken dialogue or narration. Each video is identified on the page by its title and performer. We are adding a text description of each video (what is being performed, by whom, and where) to our YouTube captions so that the “[instrumental music]” nature of the audio is communicated to caption users, and we will provide transcripts of any future video that contains speech. Extended audio description is not currently provided.

Wordmark and subtitle rendered as images

The Classical Not Classical wordmark and the “Starring world renowned pianist and arranger Michael Rainwater” subtitle are custom lettering delivered as images. They carry full alternative text and the page also contains the same information as real text for screen readers, but the artwork itself does not reflow or change color with user style sheets.

Newsroom (news.classicalnotclassical.com)

The newsroom runs on a separate template. It has the same skip link, the same reduced-motion handling, and the same palette as the main site, and it carries no analytics or third-party scripts at all. Its testing has been less extensive than the main site’s, and its article content is authored over time rather than fixed, so please report any issue you find there.

Keyboard shortcuts inside the video player

Our embedded players are configured with YouTube’s native keyboard shortcuts turned off, so that key presses go to our own controls instead of being captured by the player. Our overlay provides play, pause, seek, and full screen to the keyboard, but YouTube’s own shortcut set is not available inside an embed on this site. If this is a barrier for you, the same videos on YouTube have the full shortcut set.

Video thumbnails are custom controls, not buttons

The click-to-play video thumbnails are built as custom controls rather than native HTML buttons. They are reachable by Tab, activate with Enter or Space, and announce themselves as buttons with a descriptive label, so they behave correctly in testing. Native elements are still more reliable across the full range of assistive technology, and converting them is on our list.

Third-party sites we link to

Social-media platforms, streaming services, press publications, and michaelrainwatermusic.com are outside our control and may not meet the same standard.

Older documents

Any PDF or Word document we make available (for example, a press kit or white paper on request) may not be fully tagged for screen readers. If you need one in an accessible format, contact us and we will provide the content as accessible HTML or plain text.

6. How we assessed the site

This statement is based on a self-evaluation carried out on September 10, 2026. We describe it in detail because a conformance claim is only worth what the testing behind it is worth.

Automated testing. Every page was tested with axe-core 4.10.2 against the combined WCAG 2.0, 2.1, and 2.2 Level A and Level AA rule sets, run in a Chromium browser at a 1440-pixel viewport. The ten pages tested were the home page, About, Book the Show, Press, Media, Las Vegas, this Accessibility Statement, the Privacy Policy, the Terms of Use, and the 404 page. The run returned no violations on any page.

We want to be honest about what that does and does not mean. Automated tools reliably detect only a subset of accessibility problems — missing text alternatives, unlabeled form fields, insufficient contrast, empty controls. Industry estimates put that subset at roughly a third of all barriers. A clean automated run is a floor, not a certificate.

Contrast. Because automated contrast checks cannot evaluate text over gradients or background images, we computed the contrast ratio for every combination of the site’s five text colors against its three background shades by hand. All fifteen pass the 4.5:1 threshold for normal text; the lowest is 5.10:1.

Manual testing. We carried out a keyboard-only walkthrough of the site’s interactive components — the main and mobile navigation, the skip links, the booking form including its error and success states, the video thumbnails and player controls, and the analytics consent banner — confirming that each can be reached, operated, and escaped without a mouse, and that the focus indicator remains visible throughout. We also reviewed the underlying HTML structure, ARIA usage, focus styles, and reduced-motion handling by reading the code.

What we have not done. The site has not been evaluated by an independent third-party auditor. It has not been tested by people who use screen readers daily, which is a different and more revealing exercise than a developer running one. We have not completed a systematic zoom and reflow audit. We intend to address all three, and we will update this section, with dates, when we do.

7. Technical information

The site is built with HTML5, CSS, and JavaScript, using WAI-ARIA where native HTML is not sufficient. It is designed to work with current versions of Safari, Chrome, Firefox, and Edge on desktop and mobile, and with the screen readers commonly paired with them (VoiceOver, NVDA, JAWS, TalkBack). Core content and navigation remain available if JavaScript is disabled; the video players, the booking-form submission, and the animations require JavaScript.

8. Feedback and contact

If you find a barrier on this site, if a page or feature is not working with your assistive technology, or if you need any information from the site in an alternative format, please tell us. We treat accessibility reports as a priority.

When you write, it helps to include the page address, what you were trying to do, the device, browser, and any assistive technology you were using, and what happened. We aim to acknowledge every report within five (5) business days and to fix confirmed barriers, or provide the content another way, as quickly as we reasonably can.

9. Reviewing this statement

This statement was first published on September 8, 2026. We review it, and re-test the site, whenever we make significant changes and at least once a year. The dates at the top of the page show when it was last reviewed.