Accessibility.
Aceve builds tools that people use for hours, on their worst day, on whatever device is to hand — so accessibility isn't a compliance checkbox, it's what makes the software usable at all. This page pulls together the rules that the component pages apply individually.
Our commitment
Accessible products aren't a separate feature — they're what "well designed" already means. Sprout components ship with sensible defaults, but no component library can make an entire product accessible on its own. The patterns you choose, the content you write, and the way you assemble a flow all matter just as much as the building blocks.
Already surpassed — the legal minimum, not a real bar for Aceve.
The required floor. Every Aceve product meets this, no exceptions.
The reach goal — pursued wherever it doesn't cost the workflow.
Who we design for
Around 1 in 5 people live with a permanent disability. Many more encounter a temporary or situational barrier every single day. Designing for the edges of ability makes the product better for everyone in the middle too — and in construction, the "edges" show up constantly: gloved hands, bright job-site light, one-handed use on a ladder, a noisy site with no room for audio cues.
Navigates with a screen reader or magnification; can't rely on color, icons alone, or layout position to understand content.
Screen glare washes out low-contrast text; gloves make small touch targets and precise gestures difficult to use reliably.
Holding equipment, climbing, or carrying materials — needs every action reachable and completable using one hand alone.
Relies on captions and visible status indicators — audio-only alerts, confirmation sounds, and voice notes go unnoticed.
Can't turn sound on or off freely in either setting — every important cue still needs a clear, visible equivalent shown.
Benefits from plain language, predictable patterns, and information broken into small, clearly well-labelled steps.
Principles
Accessibility isn't a compliance checkbox. It's designing so that someone using a screen reader on a back-office dashboard, a color-blind estimator reading status tags, and a foreman with a cracked-screen phone in direct sunlight all get the same job done — not a degraded version of it.
Use Sprout components instead of one-off patterns — the same interaction behaves identically across every Aceve product.
AA is a component's baseline every Sprout product ships with, not an optional extra someone has to remember to ask for.
Anything conveyed by color, sound, or motion also needs a text, icon, or shape equivalent — never just one signal alone.
Assume conditions are worse than your desk: one hand, bright light, a cracked screen, unreliable connectivity on-site.
Language and imagery should respect the dignity and expertise of tradespeople — plain, not jargon-heavy, but never condescending.
Respect zoom, contrast, and reduced-motion settings, and warn people before a high-impact or hard-to-reverse change.
Color & contrast
Glare on a job site can wash out anything low-contrast — contrast isn't a nice-to-have here, it's the difference between a screen someone can read outdoors and one they can't.
Typography & content
Clear writing is an accessibility feature. It helps people with cognitive disabilities, people reading in a second language, and anyone skimming a screen between tasks on-site.
Avoid jargon, idioms, and non-literal phrases that don't translate well. Keep line length to around 45–75 characters for comfortable reading. Left-align body text; reserve centered text for hero titles and dividers. Avoid setting body copy in italics or all caps — both slow reading, especially for dyslexic users. Only underline actual links, so underline never has to be second-guessed. Break long content into headings, short paragraphs, and bullet lists.
Headings are structure, not decoration — screen reader users often navigate a page heading by heading.
- H1The page title. One per page.
- H2Major sections. As many as needed.
- H3Subheadings within a section.
Keyboard & focus
Important actions in a Sprout product should be reachable without a mouse or touch input — for keyboard-only users, switch-device users, and anyone whose pointer hand is occupied.
Every interactive element has a visible focus state — never remove the outline without replacing it with something equally visible. Tab order follows the visual order of the page: left to right, top to bottom. Opening and closing a dialog, drawer, or menu moves focus somewhere sensible, and never "loses" it back to the top of the page. Nothing traps keyboard focus — a user can always tab back out. State changes (expanded, selected, disabled) are exposed to assistive tech, not just shown visually. Test the whole flow with a keyboard alone — it's the fastest way to catch focus problems before they ship.
Touch targets & the field
Design for one-handed, gloved use first, not as an afterthought.
- •Provide a single-tap alternative to any swipe, pinch, drag, or multi-finger gesture.
- •Keep the primary action reachable within thumb range on a one-handed mobile layout.
- •Don't rely on hover-only states — many field devices are touch-only.
Layout, zoom & reflow
People change text size, zoom level, and orientation for all kinds of reasons — low vision, a cracked screen held at an angle, or just preference. The layout has to hold up.
Content reflows without horizontal scrolling at up to 400% browser zoom (down to a 320px viewport). Text remains readable and uncut at up to 200% text-only zoom. Navigation, search, and skip links stay in a consistent, predictable location. Use generous white space.
Images & media
- •Every meaningful image, icon, or diagram gets a concise, accurate text alternative — write it in the same tone of voice as the visible copy.
- •Purely decorative images are marked so assistive tech skips them (alt="" or aria-hidden="true"), not given a generic label.
- •Never embed important text inside an image — it can't be resized, translated, or read aloud.
- •Every video gets captions; provide a transcript for audio-only content.
Motion
Motion sensitivity is common. Motion should support understanding, never demand attention.
- •Respect the operating system's reduced-motion setting — swap transitions for instant or fade-only alternatives.
- •Avoid autoplaying video, flashing content, and parallax scrolling.
- •Always give people a way to pause, stop, or skip animation.
- •Use motion sparingly, to draw attention to one real change — not as ambient decoration.
Semantic HTML & ARIA
- •Use <button>, <nav>, <header>, <main>, and <footer> for what they actually mean — not a <div> with a click handler.
- •Use ARIA to describe custom components Sprout doesn't already provide — but the first rule of ARIA is: don't use ARIA if a native element already does the job.
- •Update ARIA state (aria-expanded, aria-selected, aria-disabled) automatically as the component's state changes.
- •Give every input, icon-only button, and custom control an accessible name.
- •Follow the WAI-ARIA Authoring Practices Guide for any pattern not already covered by a Sprout component.
Forms & errors
- •Every field has a visible, programmatically-associated label — not just placeholder text, which disappears on input and often fails contrast.
- •Errors are described in plain text next to the field, not communicated by color or icon alone.
- •Error messages explain what went wrong and how to fix it, in a helpful and human tone — never blame the person for the mistake.
- •Required fields are marked in text, not with an asterisk alone.
- •On submission failure, focus moves to the first error so keyboard and screen reader users don't have to hunt for it.
- •High-impact or hard-to-reverse actions are confirmed before they happen, not just explained after.