If you built your site on Showit and ran a Lighthouse accessibility audit on it, the score you got is probably half the story.
Showit is not like WordPress, Squarespace, or Webflow. Those platforms render one page that adapts to the screen size you are looking at. Showit does something different: it builds the desktop layout and the mobile layout as two entirely separate documents that share the same URL. When a visitor on a phone hits your homepage, they are not seeing your desktop site stretched smaller. They are seeing a different page that you also designed, in a separate canvas, that happens to live at the same address.
This sounds like trivia until you start auditing one. Then it becomes the central problem.
Most Showit sites that we look at have been "fixed" by the owner or designer once already. They added alt text to images. They tightened up the color contrast on the hero. They felt good about it. Then the audit runs again and the score is the same as before.
The reason is almost always that the fix was applied to the desktop canvas only. The mobile canvas, which the screen reader on someone's phone is actually reading, never got touched.
Here is how to think about it, what specifically breaks, and how to fix it without redoing your whole site.
Why Showit works this way
Showit started as a portfolio platform for photographers, where pixel-perfect layouts mattered more than developer ergonomics. The product's bet was that designers wanted to drag elements onto a canvas and have them stay exactly where they put them, on every screen, forever. That is hard to do with responsive CSS, where elements reflow and jump and stack in ways the designer cannot fully predict. So Showit skipped responsive entirely. Each screen size gets its own canvas, and you place every element by hand on each one.
This makes for beautiful sites. It also makes for accessibility weirdness, because almost every assumption the screen reader and the audit tool make about how a webpage is structured assumes one document, not two.
When axe-core scans your homepage, it sees one of the two canvases -- usually the one that matches the viewport it was run at. When VoiceOver on an iPhone reads your homepage, it sees the mobile canvas. When NVDA on a desktop browser reads it, it sees the desktop canvas. They are reading different content from each other, and your fix only counted toward whichever one you happened to be looking at when you did it.
The five things that almost always fail
These are the patterns we see on roughly every Showit site we audit. Going through this list and checking each one, on both canvases, will catch the majority of what an audit is going to flag.
1. Heading hierarchy that looks fine but reads wrong
Showit lets you place text anywhere on the canvas. That is the appeal. It also means the visual order of your headings -- what your eye sees scanning top to bottom -- has nothing to do with the DOM order, which is what a screen reader follows.
A common pattern: the designer puts a big "Welcome" word near the top of the hero and tags it as H1 because it is the largest text. Then they place a smaller "About me" heading below the hero and tag it as H2. Visually it makes sense. But because of how the canvas places elements, the DOM ends up rendering "About me" before "Welcome." A screen reader user lands on the page, navigates by heading, and the first thing they hear is "About me" -- with no context, because the welcome heading they were supposed to land on first does not arrive until later.
Worse: the mobile canvas almost always rearranges the same headings in a different visual order, which means the DOM order is also different, which means the heading hierarchy that you finally got right on desktop is broken again on mobile.
The fix is not glamorous. Tab through the page with a keyboard, then tab through the mobile preview. Note what order the screen reader will encounter the headings. If the order does not start with H1 followed by sensible H2s, rearrange the elements on the canvas until the DOM order matches the heading levels, on both canvases. There is no shortcut here.
2. Form inputs that have visual labels but no programmatic ones
Showit's contact form blocks render a placeholder inside the input box -- "Your name," "Your email" -- and most designers leave it at that because it looks clean. To a sighted user this is fine. To a screen reader, the input has no label at all, because placeholders are not labels and assistive tech mostly ignores them.
What the auditor sees in axe-core is "form-field-multiple-labels" or "label" violations on every input on the page. What the visitor on a screen reader experiences is being told "edit text, blank" three times in a row with no idea what each field wants.
The fix: enable the explicit label option in the Showit form block settings. There is a checkbox in the field properties that says something like "Show label above field" or "Visible label." Turn it on for every field. The placeholder can stay if you like the visual; the label being programmatically associated is what matters.
And -- you saw this coming -- the form block on the mobile canvas is a separate instance with its own settings. You have to do this twice.
3. Image alt text that defaults to the filename
When you import images into Showit through Quick Setup or by dragging from the desktop, the alt text defaults to whatever the file was called. We have seen sites where every image's alt text is IMG_4823.JPG or final-final-revised-v3.jpg. These are not just useless; they are actively worse than blank, because the screen reader will dutifully read out the gibberish filename to every screen reader user who lands on the page.
The fix is straightforward but tedious: open every image element on the canvas, find the Alt Text field in the properties panel, and replace the filename with a real description -- or with empty alt (alt="") if the image is decorative. Decorative images are images that, if you removed them, the page would lose nothing meaningful. A divider line, a subtle texture, a flourish under your name. Those should have empty alt so the screen reader skips them. A photo of you, a product image, a diagram -- those need real alt text.
You guessed it: every image on the mobile canvas is a separate element with its own alt text field. It does not inherit from desktop.
4. Color contrast that passes the eye test and fails WCAG
Showit's default templates pick designer-pretty palettes. Soft grey on soft white. Cream on parchment. Gold on tan. These look beautiful and almost universally fail WCAG AA contrast, which requires a 4.5-to-1 ratio for body text and 3-to-1 for large text.
The fix here is purely a design call. Either darken the text, lighten the background, or accept that some text on your site is failing and decide whether to keep it. WebAIM's contrast checker is free and lets you paste your two colors in to get the ratio.
The annoying part is that contrast on Showit is set per text element, not site-wide. If you have twenty text blocks with similar but slightly different shades of grey -- which is almost guaranteed because of how Showit's color picker works -- you have to fix each one individually. And on both canvases.
5. Mobile menu drawers that trap focus or skip it entirely
The mobile menu on a Showit site is usually built as a hamburger icon that opens a drawer of links. Two failures show up here over and over.
The first is that opening the menu does not move keyboard focus into it. Someone tabbing through the page hits the hamburger, presses Enter, the menu visually opens, and their focus is still on the hamburger button. They then have to tab forward through the entire rest of the page before they reach the menu links, which by that point are visible on top of the rest of the content but invisible to the keyboard navigation order.
The second is the opposite: the menu opens, focus moves into it, and then never comes back out. The tab key cycles through the menu links forever and there is no way to escape back to the page.
Both of these are JavaScript fixes that need to be added through Showit's code injection or through a custom script. The fix is conceptually simple -- when the drawer opens, move focus to the first link inside it; when it closes, return focus to the hamburger button -- but you have to actually write the script and get it injected. There is no toggle for this in the standard Showit settings.
This one only exists on the mobile canvas, since desktop typically uses an inline nav, so at least you only have to fix it once.
The audit-twice rule
If you take one thing from this article, take this: every accessibility audit on a Showit site has to be run twice. Once at desktop width, once at mobile width. Every fix has to be made twice, on the desktop canvas and on the mobile canvas. Verifying with one screen reader (NVDA or VoiceOver) on one device is not enough; you need at least one pass on each screen size.
The reason this is not standard practice is that almost no automated tool tells you to do it. Lighthouse runs on one viewport size at a time. axe-core tests one DOM tree at a time. They have no idea that the page they are testing has a sibling document at the same URL that they have not seen.
The practical workflow we use:
Run axe-core or Lighthouse at desktop width. Note the violations. Open the desktop canvas. Fix each one. Re-run at desktop width. Confirm fixes.
Then -- this is the part most people skip -- resize the browser window to phone width, or use Chrome DevTools' device emulation to switch to a phone viewport, and re-run the audit at that width. The violations will look different, and many of the things you just fixed will be back. Open the mobile canvas. Fix them again. Re-run.
Only then do a manual screen reader pass. NVDA on a desktop browser at desktop width. VoiceOver on iOS at mobile width if you have an iPhone, or VoiceOver on Mac with the browser at mobile width if you do not. The two readers will surface different issues -- VoiceOver tends to be stricter about heading hierarchy and ARIA roles, NVDA tends to flag form labels and live regions more aggressively -- and a thorough pass needs both.
If this sounds like it doubles the work of an accessibility audit on a normal site, that is because it does.
What this means if you are hiring an auditor
If you are paying someone to audit a Showit site, the questions to ask before you hand over money:
Does the auditor know that Showit has separate desktop and mobile canvases? If the answer is "what canvases," you are about to pay for a half-audit.
Will the audit cover both canvases? The deliverable should explicitly state that fixes have been verified on both desktop and mobile widths.
Does the auditor use a real screen reader, not just automated tooling? axe-core and Lighthouse together still miss roughly half of what a real WCAG audit catches on a Showit site, because the heading hierarchy and focus issues only fully surface under manual screen reader navigation.
If the auditor cannot answer these clearly, the score they hand you back is not going to be the score the EAA enforcement officer or the ADA plaintiff lawyer gets when they run their own scan.
Closing
Showit is a fine platform for sites where pixel-perfect design matters more than developer flexibility. We are not trying to talk anyone out of using it. But the canvas-as-document architecture creates an accessibility tax that other platforms do not have, and almost every audit problem we see on a Showit site traces back to the same root cause: someone fixed it once, on one of the two canvases, and assumed they were done.
If you are auditing your own site, run the test twice. If you are paying someone else, make sure they know there are two documents.
If you want a free 5-minute scan of your Showit site -- axe-core baseline plus a Top 3 issues report -- drop the URL in the comments. We are running these for the first 5 sites that ask, no obligation, mainly because we are building case studies for a public review base.
Top comments (0)