Dorik Accessibility Checklist 2026 | WCAG 2.1 AA & EAA for No-Code Sites
Last updated: 2026-06-08
Dorik is a no-code website builder that has grown quickly by pairing a clean block-based editor with AI site generation - describe the site you want and Dorik assembles pages from its block library, which makes it popular with founders, freelancers, and small businesses launching fast on a budget. That speed is exactly where the accessibility risk lives. AI-generated and prebuilt sections look polished, but the markup underneath inherits whatever the generator and the block templates produce: heading levels chosen for visual rhythm rather than document structure, hero images and icons with missing or generic alt text, buttons and links labelled 'Learn more' or 'Get started' repeated across the page, forms that rely on placeholder text instead of real labels, and color combinations from a theme palette that have not been checked for contrast. People who build with AI tend to trust the output and ship it, so these issues reach production unreviewed far more often than on hand-built sites. With the European Accessibility Act now in force for businesses serving EU consumers and ADA Title III claims continuing to name small-business sites in the US, a fast launch is no excuse for an inaccessible one. The reassuring part is that Dorik is block-based and exposes the settings you need - heading tags, alt-text fields, form options, theme colors - so most of these issues are fixable in the editor without code, as long as you actually review the AI's output instead of trusting it. This checklist covers the issues we see most often on Dorik sites and the specific settings and markup targets that fix each one. None of this is legal advice; consult a qualified attorney for your jurisdiction.
Common Accessibility Issues
When Dorik's AI assembles a page or you stack prebuilt blocks, the heading levels are chosen to look right, not to form a logical outline. Pages commonly end up with multiple H1s (one per hero block), skipped levels, and section titles that are styled text rather than real headings. Screen reader users who navigate by headings get a structure that does not reflect the page, and the AI will not fix it for you.
After generating or assembling a page, review the heading structure: exactly one H1 (the main page title/hero), then H2 for sections and H3 for subsections with no skipped levels. In each text/heading element, set the heading tag explicitly and control size with the typography settings. Make sure section titles that look like headings are marked up as real headings, not bold paragraphs.
<!-- AI output: two H1s + a non-heading section title -->
<h1>Launch Faster</h1> <!-- hero 1 -->
<h1>Trusted by Teams</h1> <!-- hero 2, second H1 -->
<p class="big-bold">Features</p> <!-- looks like a heading --><h1>Launch Faster</h1>
<h2>Trusted by Teams</h2>
<h2>Features</h2>AI-generated Dorik pages and stock-image blocks frequently ship with empty alt text, filename alt text, or generic placeholders like 'image' or 'hero', and decorative icons are sometimes exposed to assistive technology. Informative images - product shots, screenshots, infographics, and any image with text baked into it - then convey nothing to screen reader users.
Review every image the generator or block library placed and add meaningful alt text in the image settings, describing what the image communicates. For text baked into a graphic (a banner with an offer), reproduce that text as the alt or, better, as real on-page text. Mark purely decorative images and icons as decorative so they are skipped. Do not trust AI-supplied alt text without reading it - it is often generic or wrong.
<!-- AI block image, generic alt -->
<img src="hero-ai-1.jpg" alt="image"><img src="hero-ai-1.jpg"
alt="Dashboard showing weekly sales up 24% across three product lines">Dorik's block library and AI output reuse the same call-to-action wording everywhere, so a page ends up with several links all reading 'Learn more', 'Get started', or 'Read more'. Screen reader users who pull up a list of links hear the same phrase repeatedly with no way to tell the destinations apart, failing WCAG 2.4.4 Link Purpose.
Give each link and button a distinct, descriptive accessible name. Prefer wording that makes sense out of context ('Get started with the Pro plan', 'Read the accessibility guide') over a bare 'Learn more'. If the visible text must stay short for design, add a more specific accessible name with aria-label that includes the destination. Review the whole page for duplicated CTA text after generating it.
<a href="/pro">Learn more</a>
<a href="/blog">Learn more</a>
<a href="/contact">Learn more</a><a href="/pro">Learn more about the Pro plan</a>
<a href="/blog">Read the blog</a>
<a href="/contact">Contact our team</a>Dorik's form blocks can render field names as placeholder text inside the input rather than as persistent, programmatically associated labels. Placeholder text disappears on typing, is announced inconsistently by screen readers, and is usually low-contrast gray. Validation errors are often shown as a single general message instead of being tied to the field, and focus is not moved to the first error.
Enable visible, persistent labels associated with each input via for/id in the form block settings. Indicate required fields in text rather than color alone, associate each error message with its field via aria-describedby, set aria-invalid on failed fields, and move focus to the first invalid field on a failed submit. Confirm the success message is announced. Test the form with a keyboard and a screen reader in both success and error states.
<!-- Field name as placeholder only -->
<input type="email" name="email" placeholder="Enter your email"><label for="email">Email address <abbr title="required">*</abbr></label>
<input type="email" id="email" name="email"
required aria-required="true" aria-describedby="email-error">
<span id="email-error" role="alert"></span>Dorik's accordion, tab, and FAQ blocks present collapsible or tabbed content but do not always expose the expanded/collapsed state or implement the full keyboard pattern. Accordion headers may not announce as expandable controls or report whether they are open, and tabs may not support arrow-key navigation or announce the selected tab, so keyboard and screen reader users cannot operate the content reliably.
For accordions/FAQs, ensure each header is a real button exposing aria-expanded and aria-controls, with the panel as a labelled region. For tabs, apply the tablist pattern: role="tablist", tabs as buttons with role="tab", aria-selected and aria-controls, panels as role="tabpanel" with aria-labelledby, and Left/Right/Home/End key handling. If the block markup lacks this, add the ARIA via a custom-code/embed block or choose a block that behaves correctly. Test with Enter, Space, and arrow keys plus a screen reader.
<!-- FAQ header without role/state -->
<div class="faq-q">How does billing work?</div><button class="faq-q" aria-expanded="false" aria-controls="faq-1">
How does billing work?
</button>
<div id="faq-1" role="region">...</div>Dorik's theme palettes and AI-chosen color schemes favor on-trend light grays, pastel buttons, and low-contrast accent text. Because the editor previews against the theme's own background, body text below 4.5:1, button text on pale fills below 4.5:1, and UI components below 3:1 are easy to miss - and the same palette repeats across every page, so one weak color choice fails the whole site.
Check body text, link, and button colors with a contrast checker and adjust the values in Dorik's theme/global color settings so a single change corrects every page. Pay special attention to button text on button fill, light accent text, and any text placed over images or gradients. Re-check hover and focus states. Do not rely on the AI's color choices passing contrast - verify them.
/* Pastel button from theme palette */
.btn { color: #ffffff; background: #b9c8ff; } /* ~1.7:1 - fails *//* Corrected to meet 4.5:1 */
.btn { color: #ffffff; background: #3b5bdb; } /* ~5.4:1 - passes */Dorik blocks offer entrance animations and scroll-reveal effects that run for everyone regardless of the operating-system reduce-motion setting. AI-generated pages often enable these by default across many sections. Large or repeated positional motion can cause nausea and dizziness for people with vestibular disorders.
Add a prefers-reduced-motion media query in Dorik's custom CSS (or a custom-code block) that disables entrance animations, transforms, and transitions when reduced motion is requested, or turn the animations off in the block settings. Keep any remaining motion subtle and opacity-based rather than large positional movement.
/* Scroll-reveal applied to all visitors */
.block-animate { transform: translateY(60px); transition: transform .6s; }@media (prefers-reduced-motion: reduce) {
.block-animate, [class*="animate"] {
transform: none !important;
animation: none !important;
transition: none !important;
}
}Dorik-Specific Tips
- Never ship AI-generated pages unreviewed. The generator produces polished visuals but inherits accessibility problems - check headings, alt text, link wording, form labels, and contrast on every generated page before publishing.
- Fix the heading outline first: one H1 (the hero/page title), then H2/H3 with no skipped levels. Make sure section titles are real headings, not styled bold paragraphs.
- Read every alt text the AI or block library supplied. Generic 'image' or filename alt text is common; replace it with a meaningful description and mark decorative images and icons as decorative.
- Rewrite duplicated calls to action. A page of identical 'Learn more' links fails WCAG 2.4.4 - make each link's accessible name describe its destination.
- Set and verify theme colors once. Because the palette repeats site-wide, correcting body, link, and button contrast in the global color settings fixes every page at once; check hover and focus states too.
- Test the published page with the keyboard and a screen reader, not the editor preview. Accordion/tab/FAQ ARIA, form behavior, and focus order only behave like production on the live site.
Recommended Tools
axe DevTools
Browser extension that scans the published Dorik page for WCAG violations with specific fixes. Run it on the live front-end with forms, accordions, tabs, and AI-generated sections in place rather than on the editor preview.
WAVE by WebAIM
Visual evaluator that flags missing alt text, empty or duplicated links, contrast failures, and heading-order issues directly on the rendered page - useful for catching AI-generated structure problems.
WebAIM Contrast Checker
Check Dorik theme-palette body, link, and button colors against 4.5:1 and 3:1, including AI-chosen schemes and text placed over images or gradients.
NVDA + Firefox / VoiceOver + Safari
Manual screen-reader testing verifies heading announcements, accordion/tab/FAQ state, link purpose, and form labelling on Dorik sites - the things automated scanners and AI generation cannot judge for announcement quality.
Lighthouse (Chrome DevTools)
Built-in Chrome audit that catches common Dorik issues like low contrast, missing alt text, and missing accessible names. Treat a high score as necessary but not sufficient and pair it with manual keyboard and screen-reader testing.
Dorik Block Accessibility At a Glance
| Plugin / Tool | Block / Source | Common Failure | WCAG | Best Fix |
|---|---|---|---|---|
| AI-Generated Sections auto-assembled pages | Multiple H1s, broken outline | 1.3.1 | Review headings: one H1, logical H2/H3 | |
| Image / Hero Blocks stock + AI images | Missing or generic alt text | 1.1.1 | Meaningful alt; mark decoratives decorative | |
| Button / CTA Blocks calls to action | Repeated 'Learn more' links | 2.4.4 | Distinct, destination-specific link names | |
| Form Blocks contact / signup | Placeholder labels, general errors | 3.3.2 | Persistent labels; per-field error messages | |
| Accordion / Tab / FAQ collapsible content | No ARIA state, no keyboard pattern | 4.1.2 | Add aria-expanded / tablist roles + key handling |
Frequently Asked Questions
Are AI-generated Dorik sites accessible out of the box?
No - not reliably. AI site generation optimizes for a polished visual result, not for an accessible document, so generated Dorik pages routinely ship with multiple H1s and broken heading outlines, generic or missing image alt text, duplicated 'Learn more' links, placeholder-only form labels, and theme colors that have not been checked for contrast. None of that is visible in the preview, and because AI output feels finished, people tend to publish it unreviewed. Dorik is block-based and exposes the settings you need to fix all of these, so the platform can produce a conformant site - but only if you review the AI's output for headings, alt text, link wording, form labels, and contrast before you launch, and test the live page with a keyboard and a screen reader.
Can I fix Dorik accordion and FAQ accessibility without code?
Sometimes, depending on the block. The accordion, tab, and FAQ blocks do not always expose the expanded/collapsed state or implement the full keyboard pattern, so the first step is to test the live block: can you operate each header with Enter or Space, move between tabs with the arrow keys, and does a screen reader announce whether a section is open? If the built-in block handles state and keyboard correctly, you are done. If it does not, you can add the missing ARIA (aria-expanded and aria-controls on headers; role=tablist/tab/tabpanel plus arrow-key handling on tabs) using a custom-code or embed block, or avoid placing essential content inside a component a keyboard user cannot reach. Re-test with a screen reader after any change.
Does using Dorik help or hurt my European Accessibility Act compliance?
It is neutral - the platform neither guarantees nor prevents compliance. The European Accessibility Act applies to businesses providing covered products and services to consumers in the EU, and it points to WCAG (via the EN 301 549 standard) as the technical benchmark, which generally means WCAG 2.1 Level AA. Dorik gives you the controls to meet that bar - heading tags, alt-text fields, form label options, and theme colors - but a fast AI build that you publish unreviewed will usually fall short on headings, alt text, link purpose, form labels, and contrast. Treat the EAA as a build requirement: review and fix those items before launch, keep evidence of your testing, and remember this is general information, not legal advice - consult a qualified attorney for your situation.
Further Reading
- Ai Generated Code Accessibility Audit
- How To Choose Accessible Website Template
- Five Minute Accessibility Audit
Other CMS Checklists
Get our free accessibility toolkit
We're building a simple accessibility checker for non-developers. Join the waitlist for early access and a free EAA compliance checklist.
No spam. Unsubscribe anytime.