Accessibility

So the results are in. Our criticism and review site is significantly more accessible than Moorview’s website.

Moorview’s homepage

Without dismissing the omnipresent “Sign up to our newsletter” (that even if you sign up, it keeps popping up):
962 accessibility nodes with 276 issues.

If you dismiss the “Sign up to our newsletter”, then its:
928 nodes with 216 issues.

There are issues across the whole spectrum. Contrast, keyboard focus and text labels. That’s not to mention no respect of prefers-reduced-motion* or any other accessibility indicators. Some text will be almost unreadable to people with contrast and colour issues. I could go through almost all the WCAG2.2 guidelines and find issues, but that would be me fixing their problems, and well. They are not paying me, so no free lunch here!

However, if you use uBlockOrigin (You should! There’s 6 tracking domains on Moorview’s page), you can add the following to ‘My Filters’

! 10 Sept 2026 https://www.moorviewcare.com
||static.parastorage.com/services/wix-thunderbolt/dist/popups.2b704839.chunk.min.js$script,domain=moorviewcare.com

And the newsletter popup now does not load.

* Although, I did find a media query for prefers-reduced-motion to disable the flashy animations, except support is hit and miss, it seems to only work in Chromium based browsers (Chrome/Edge etc.) but the way they’re handling image load, you get a lower resolution blurred version of images, then a repaint (a visual pop) when the page fully loads in anyway. The way they’re handling mobile vs desktop view isn’t properly responsive. They’re doing something beyond @screen max-width so you can’t resize and get an optimised view for the display you’re on, it has to detect you’re on a small screen at page load, otherwise it loads the desktop version.

Either way, it’s janky, and shows they haven’t spent enough time on it.

Our Site

Our homepage:
153 nodes, with 6 issues.

Comparing to our worst page:
1202 nodes, with 17 issues.

The main issues are because you can’t use the keyboard to focus on elements within the accessibility tools, until you use the keyboard (or pointer) to open it. So that’s those 6. The remaining elements are to do with the audio player. For audio files with markers, those fail on contrast, but that’s because they’re not shown until getting to that point, or navigating to them with a pointer or keyboard.

Accessibility nodes were tested with Firefox.

Someone should send the Web Content Accessibility Guidelines to Moorview, they might learn a thing or two…

We win on this one.