Accessibility
Our design system ensures accessibility is built into every layer of the experience. High color contrast, legible typography, and clear visual hierarchy make content easy to read for all users. Interactive elements always display visible focus indicators, ensuring full keyboard navigation support. States such as error or warning are color-coded with proper contrast, so icons and messages remain clear. These standards align with WCAG guidelines, allowing us to create inclusive, user-friendly interfaces that work seamlessly for everyone.
Colour & Contrast
Legible design begins with contrast. Text and interactive elements must stand out clearly from their backgrounds to remain readable in all environments.
Minimum Contrast Ratio:
Body text must achieve at least 4.5:1 contrast against its background.
Large Text:
Headings or large text require a minimum 3:1 contrast ratio.
Color - Code States:
Error, warning, success, and informational states (text + icons) must all meet WCAG contrast rules. No meaning should rely on color alone.
Typography & Legibility
Text legibility is paramount. We follow best practices for font size, spacing, and font choice. Body text uses at least 16px, as recommended for comfortable, with a generous line-height. Headings and UI labels use a clear typographic scale, all built with relative units so users can zoom or scale text in their browser.
Our typography tokens are normalized for readability: They adapt to user settings and maintain consistent vertical rhythm. For example, line lengths are limited to 66 characters, flush-left alignment is standard (as per USWDS guidance), and colour contrast for text is assured by design tokens. All text and UI labels follow WCAG 1.4.4 (Resize Text) and 1.4.1 (Use of Colour) by supporting user scaling and not relying on colour alone to convey information.
Component States & Focus
All interactive components have well-defined visual states (normal, hover, disabled, selected, error, etc.). In particular, focus indicators are designed to be highly visible and consistent. We adhere to WCAG SC 2.4.7 “Focus Visible”, which requires “the keyboard focus indicator is visible” in every focusable UI. In Appex Now, a focused element always shows a distinct outline or shadow with at least a 3:1 contrast against the unfocused state.
In code, our CSS includes clear: Focus styles for buttons, inputs, links, and custom controls. We never remove browser outlines without replacement, as one accessibility rule puts it, if you decide to get rid of the default outlines, make sure to replace them with something else, because many users rely on them.
For example, focused buttons get a 2px solid outline in the brand accent colour (passing 4.5:1 against both light and dark backgrounds), and form fields get a bright ring or border. Our design tokens specify focus colours and offsets so these states are consistent. By default, any component’s focus state is tested to ensure it’s at least as visible as the image above, meeting WCAG focus appearance rules.
Keyboard Navigation
All Appex Now components support keyboard interaction. We follow the principle that if you can interact with something via mouse, you must be able to do it by keyboard. In practice, this means:
Tab Order: We define a logical tab sequence that follows the visual flow (left-to-right, top-to-bottom). For composite components (menus, accordions, tables), our specs include the expected Tab/Shift+Tab order.
Key Bindings: Interactive controls work with Space/Enter (for activation) and standard arrow keys where appropriate. The design system specifies these for widgets like dropdowns and sliders.
Focus Management: Components that open or close content (modals, menus, popovers) trap or restore focus appropriately. We document these behaviours. when a modal opens, focus shifts to the dialog, and when it closes, focus returns to the triggering button.
Documentation: Every component spec includes a "Keyboard interactions" section. For example, our breadcrumb component spec explicitly lists that Tab moves focus through each link .
These decisions help keyboard-only users and assistive tech users navigate seamlessly. By designing with keyboard in mind, we satisfy WCAG 2.1 SC 2.1.1 (Keyboard Accessible) and ensure no interactive element is left unreachable .
Forms, Labels, & Error Handling
Forms in the design system are designed for clarity and correctness. Every input has a visible label,
WCAG SC 3.3.2: “Provide labels or instructions for inputs”.
Optional helper text is provided only when it adds value, keeping interfaces clean. We also enforce that required fields are clearly indicated in text (not colour alone). When forms validate, errors are described in plain language and announced. In line with WCAG SC 3.3.1 (Error Identification), any automatic input error is flagged with descriptive text and colour change. For instance, a missing field triggers an inline message like “This field is required,” and focus moves to the first error.
Our component styles include visible error states (e.g. red border + icon) plus the text explanation. The design system guidelines specify that:
Colour is never the only cue: errors include icons and text so users with colour blindness still detect them. We recommend combining error hints with to link the message to the field.
These practices ensure forms meet accessibility rules: users always know what input is needed and how to fix mistakes.
By codifying accessible patterns, Appex Now scales inclusive design across products. Reusable components mean that once a component is built accessibly, all teams get a better starting point. For example, our button, card, and navigation components were all built with WCAG best practices (colours, focus, structure) before ever shipping. This way, multiple brands or apps consuming Appex Now inherit these properties. We embrace the broader principles of inclusive design – considering different abilities, devices, and contexts – in our system philosophy.
Practically, the system provides:
Adaptive Tokens: Colour and spacing tokens that respond to user preferences (e.g. high-contrast theme support, scalable type).
Responsive Patterns: Components work on all devices and support touch, voice (via proper labeling), and keyboard.
Guidance Library: A living style guide that encourages a mindset of accessibility; for instance, linking to patterns like Heydon Pickering’s Inclusive Components and providing accessibility checklists per component.
Customisation Hooks: Since we know no system covers every need, we supply “smart” settings – e.g. automatic link color picking or focus ring thickness controls – so that developers can tweak accessibility aspects without heavy custom code .
In other words, we treat accessibility as a core design tenet, not an afterthought.
This reflects findings from others: A design system “infuses accessibility guidance and tools into colour, form design, and other system concerns”. Our team regularly reviews real user feedback (including from users with disabilities) to improve components. As a result, Appex Now’s design tokens, UI libraries, and documentation work in concert to deliver inclusive experiences across the entire product suite.
Documentation & Best Practices
Finally, Appex Now’s documentation emphasizes accessibility at every turn. Each component page in our style guide has an Accessibility section with does-and-don’ts.
We provide code examples annotated with ARIA and alt attributes, plus links to relevant WCAG or ARIA documentation. For instance, our image component docs include recommended alt text patterns and flag decorative vs. content images.
Broader guidelines: Our design principles page states accessibility first, and we maintain an internal accessibility checklist (covering colour, focus, semantics, responsive design). Whenever a new pattern is added (e.g. data table, carousel), we include real-world usage examples demonstrating accessible integration.