Inclusive access
Accessibility
What we build for, what currently works, what does not yet, and how to tell us when something blocks you.
Last updated
Our position
Motifuse should be usable by people navigating with a keyboard, a screen reader, magnification, high-contrast settings, reduced-motion preferences, voice control, or a phone. Accessibility is treated as a build constraint on new work rather than a pass to be done later, because retrofitting it is how it ends up not being done at all.
Being honest about the current state is part of that. Some of this site is in good shape. Some of the interactive tools are not yet, and those are named below rather than covered by a general aspiration.
The standard we work to
New and revised interfaces are built against WCAG 2.2 Level AA as a design target — perceivable content, operable controls, understandable behaviour, and robust markup. Where a control is custom, we follow the corresponding WAI-ARIA authoring pattern rather than inventing behaviour.
We have not commissioned an independent audit and do not publish a conformance report. Treat this page as a good-faith account of what is implemented, not as an assurance.
What is implemented
| Area | What is in place |
|---|---|
| Structure | Semantic landmarks on every page, one h1 per page, headings in order, and lists, tables, and forms marked up as such rather than styled to look like them. |
| Keyboard | A skip-to-content link, keyboard access to navigation, search, forms, accordions, tabs, and dialogs, and a visible focus indicator on every interactive control. |
| Focus management | Modal dialogs and the workspace mobile drawer take focus on open, trap Tab while open, close on Escape, and return focus to what opened them. |
| Custom controls | Tabs implement roving tabindex with arrow, Home, and End keys. Accordions, menus, and disclosures use native elements or the matching ARIA pattern. |
| Forms | Every field has a real label, related fields are grouped, errors name the field and the problem in text, and validation messages are associated with their input. |
| Status and results | Results that update without a page load are announced through live regions, and loading, empty, and error states are conveyed in text rather than by a spinner alone. |
| Colour | Body and interface text is checked against AA contrast in both light and dark themes. Status is never carried by colour alone — badges and callouts always include a text label or an icon as well. |
| Motion | The site honours prefers-reduced-motion globally: animations, transitions, skeleton pulses, and smooth scrolling become effectively instant. |
| Zoom and reflow | Layouts reflow to 320px and support 200% zoom without horizontal scrolling. Wide tables become labelled blocks on small screens rather than scrolling sideways. |
| Targets | Interactive controls are sized to meet the minimum target size, including inline links in dense lists. |
| Images | Meaningful images have descriptive alternative text; decorative graphics and interface mock-ups are hidden from assistive technology instead of being announced as noise. |
Known gaps
These are the areas we know are weakest. Listing them specifically is more useful than a general promise to improve:
- Canvas and pointer-driven editors — image cropping, and the DocForge template canvas — depend on dragging and positioning that has no full keyboard equivalent yet. This is the largest gap on the platform.
- The Reconova data grid is virtualised for performance, which affects how much of a large dataset a screen reader can traverse at once.
- Some charts and meters convey their value visually with a text equivalent nearby rather than in a fully described alternative.
- Some older tool pages predate the current form and error-summary patterns and have not been revised yet.
- Third-party embeds, including advertising, are outside our control and may not meet the same standard as the surrounding page.
- Automated checks run against common pages, but there is no scheduled manual audit across the whole tool directory.
Assistive technology
Development testing uses keyboard-only navigation, browser zoom, both colour themes, reduced-motion settings, and screen-reader spot checks on the paths that change. We do not test every tool against every combination of screen reader, browser, and operating system — the matrix is larger than one maintainer can cover, and claiming otherwise would be a fiction.
This is exactly where reports help most. A specific combination that fails is far more actionable than an automated score.
Reporting a barrier
Use the contact form and choose the accessibility category, or email contact@motifuse.com.
What helps us fix it
- The page URL or tool name.
- What you were trying to do.
- What blocked you, or what behaved unexpectedly.
- Your device, browser, operating system, zoom level, and assistive technology and version, if relevant.
- A screenshot or recording, if it helps and contains nothing private.
Accessibility reports are prioritised alongside safety and security corrections. We will not promise a response time we have not measured, but we will tell you what we found and what we intend to do.
If a tool is unusable for you
If a barrier is blocking work you need to finish, say so in your report. Where a tool has an accessible equivalent elsewhere on the site we will point you to it, and where the underlying task can be done another way we will help you find it while the fix is made.