This guide is intended for form designers, developers, and administrators building forms with Nintex K2 SmartForms. It covers styling best practices that improve accessibility for all users, with a focus on how those practices apply within the K2 environment. Whether you are creating a new form or reviewing an existing one, the recommendations here will help you identify and address common accessibility barriers.
Accessibility standards alignment
The practices in this guide align with the Web Content Accessibility Guidelines (WCAG), published by the World Wide Web Consortium (W3C) in versions 2.1 and 2.2. WCAG provides internationally recognized standards for accessible digital content and is referenced by many accessibility regulations and organizational policies.
The table below maps the key practices covered in this guide to their relevant WCAG success criteria, so you can understand the compliance implications of each decision.
| Accessibility practice | Relevant WCAG success criteria | Description |
| Accessible typography and font sizes | 1.4.4 Resize text | Ensures text can be resized up to 200% without loss of content or functionality, improving readability for users with low vision. |
| Sufficient color contrast | 1.4.3 Contrast (minimum) 1.4.11 Non-text contrast | Ensures text and user interface components remain distinguishable for users with low vision or color vision deficiencies. |
| Visible focus indicators | 2.4.7 Focus visible 2.4.11 Focus appearance (WCAG 2.2) | Ensures keyboard users can clearly see which element currently has focus while navigating forms. |
| Clear form labels and instructions | 3.3.2 Labels or instructions | Requires form fields to have clear labels or instructions so users understand what information is required. |
| Accessible error identification | 3.3.1 Error identification 3.3.3 Error suggestion | Ensures users are informed when an error occurs and understand how to correct it. |
| Required field indicators | 3.3.2 Labels or instructions | Ensures required fields are clearly communicated before form submission. |
| Layout reflow at high zoom | 1.4.10 Reflow | Ensures content remains usable without horizontal scrolling at high zoom levels. |
| Keyboard navigation and focus management | 2.1.1 Keyboard | Ensures all functionality can be accessed using a keyboard. |
| Screen reader compatibility | 4.1.2 Name, role, value | Ensures assistive technologies can correctly interpret form controls and communicate their purpose to users. |
Why this matters
Aligning form design with WCAG guidelines helps organizations:
- Improve usability for people with disabilities
- Support compliance with accessibility regulations and policies
- Reduce barriers to completing digital forms
- Provide more inclusive digital services
For teams using Nintex K2 SmartForms, these standards should inform decisions around themes, style profiles, control labels, and custom CSS, as styling choices can directly affect accessibility outcomes.
Best practices
The table below outlines recommended practices for accessible form design, along with guidance on how each applies within Nintex K2. Code examples and things to avoid are provided in the reference table that follows.
| Topic | Best practice | Nintex K2 considerations |
| Font sizes and typography | Use a minimum base font size of 16px. Labels are typically 16–18px and helper text should not go below 14px. Prefer relative units (rem/em) and readable sans-serif fonts with good line height. | Controls inherit styling from the theme or style profile. Override label styles carefully and verify that typography remains consistent and accessible across all views and forms. |
| Color contrast | Ensure text meets WCAG contrast ratios: 4.5:1 for normal text, 3:1 for large text, and 3:1 for UI components. Check labels, inputs, buttons, and error messages. | When customizing themes or style profiles, verify contrast for all visible elements. Ensure that any custom CSS overrides do not reduce contrast below the required ratios. |
| Focus indicators | Maintain strong, clearly visible focus styles on all interactive controls including inputs, dropdowns, radios, and buttons. Test using keyboard-only navigation. | Some K2 themes apply subtle focus styling that may not meet WCAG requirements. Always verify that tab navigation clearly shows focus on every interactive control. |
| Spacing and layout | Use 4–8px between labels and fields, 16–24px between fields, and 32px or more between sections. Prefer single-column layouts for longer forms. | SmartForms layouts often use tables or panels. Avoid overcrowding controls within grids and prefer single-column layouts to improve readability and reduce cognitive load. |
| Error styling | Combine color, text, and optionally icons to communicate errors. Place error messages directly next to the relevant field and ensure strong contrast. | When using K2 validation rules, confirm that messages appear adjacent to the control and that error styling remains accessible in custom themes. |
| Form labels | Always include persistent labels above or beside each input. Use placeholder text only for supplementary hints, not as a replacement for labels. | SmartForms supports both control labels and watermark (placeholder) text. Use labels as the primary identifier and treat watermark text as optional additional context. |
| Buttons | Use a minimum text size of 16px with adequate padding for click and tap targets. Ensure strong contrast between button text and background, and make primary actions visually distinct from secondary ones. | Submit, save, and cancel buttons inherit styles from the theme. Verify that button contrast meets WCAG requirements and that primary actions are clearly distinguishable. |
| Required field indicators | Use a combination of text and visual indicators to mark required fields. Include a legend explaining any symbols used and apply indicators consistently across the form. | Required indicators may be applied automatically through the theme or style profile. When customizing, verify that indicators remain visible, meet contrast requirements, and are consistent across all views and forms. |
| Zoom and reflow | Ensure the form remains usable at 200–400% zoom without requiring horizontal scrolling. Layouts should reflow vertically as the viewport narrows. | SmartForms layouts that rely on fixed tables or grids may not reflow well at high zoom. Where possible, prefer single-column layouts and test at multiple zoom levels. |
| Accessibility text | Provide short, meaningful accessibility descriptions for controls. Avoid unnecessary characters or overly long descriptions that duplicate the label. | SmartForms controls include an Accessibility Text property. If left blank, screen readers will fall back to the control name, which is often sufficient for clearly labelled controls. |
| Tooltips | Use tooltips to add supplementary context that is not already conveyed by the label or accessibility text. Avoid repeating information the screen reader will already announce. | Tooltips in SmartForms are read by screen readers. Ensure they complement rather than duplicate the accessibility text or label. |
| Layout simplicity | Use short, consistent labels and avoid deeply nested control structures. Simpler layouts reduce cognitive load and produce cleaner screen reader output. | Excessive nesting of controls within tables or layout containers can cause verbose and confusing screen reader output. Simplify layouts where possible. |
| Screen reader testing | Test forms using NVDA or JAWS to confirm correct reading order, accurate label announcements, and accessible keyboard navigation. | Test SmartForms with both screen readers and keyboard-only navigation to verify that controls are announced correctly and that the reading order matches the visual layout. |
| Accessibility testing | Test with real users where possible. Use contrast checkers, verify keyboard navigation, and test at zoom levels from 100–400% on both desktop and mobile. | Verify form behavior across desktop browsers and mobile layouts. Do not rely on visual inspection alone — assistive technology testing is essential for identifying hidden barriers. |
Code examples and things to avoid
| Topic | Example | Avoid |
| Font sizes and typography | body { font-size: 1rem; } label { font-size: 1.1rem; font-weight: 600; } | Fonts smaller than 14px, light-weight fonts on light backgrounds, decorative fonts, and small line heights. |
| Color contrast | label { color: #1a1a1a; } input { border: 1px solid #666; } | Light grey text on white backgrounds, placeholder text used as labels, and errors communicated only by color. |
| Focus indicators | input:focus, select:focus, textarea:focus { outline: 3px solid #005fcc; outline-offset: 2px; } | Using outline: none without providing a visible alternative. |
| Spacing and layout | .form-field { margin-bottom: 1.5rem; } | Overcrowded layouts, too many fields in narrow grids, and inconsistent spacing between fields. |
| Error styling | .input-error { border: 2px solid #c62828; } .error-message { color: #c62828; font-weight: 600; } | Highlighting fields only in red, placing error messages far from the relevant field, and using low contrast indicators. |
| Buttons | button { font-size: 1rem; padding: 10px 16px; } | Small clickable areas, poor contrast between button text and background, and buttons that look like non-interactive elements. |
| Required field indicators | .required-indicator { color: #c62828; font-weight: 600; } | Indicating required fields with color alone, using unexplained symbols, or placing indicators away from their labels. |
Common accessibility mistakes in enterprise forms
Even when guidelines are understood, implementation issues frequently occur during form design and customization. The following mistakes are among the most common seen in enterprise web forms, along with the impact they have on users and how to address them.
Relying on color alone to convey meaning
Using color as the only indicator for errors, required fields, or status changes is one of the most widespread accessibility issues. A field highlighted in red when invalid, with no accompanying message or icon, will go unnoticed by users with color vision deficiencies. This often happens when error styling is applied quickly without considering users who cannot distinguish color differences.
Always combine color with text labels, icons, and clear instructions placed near the affected field.
Removing focus indicators
Focus outlines are often removed to achieve a cleaner visual design, without realizing the impact on keyboard users. Without a visible focus indicator, someone navigating the form by keyboard has no way of knowing which control is currently active. This can make a form effectively unusable without a mouse.
If default browser focus styling is removed, replace it with a high-contrast custom style that is clearly visible across all interactive controls.
Using placeholder text instead of labels
Placeholder text disappears the moment a user starts typing, which means users can no longer see what a field is asking for while they are completing it. This is particularly problematic for users with cognitive disabilities or those using screen readers and commonly occurs when designers prioritize a minimal visual appearance over usability.
Always include a persistent label above or beside the input. Placeholder text should only supplement a label, never replace it.
Overly complex layouts
Multi-column grids and deeply nested containers are common in enterprise forms, often because teams try to reduce scrolling or fit more information on screen. However, complex layouts increase cognitive load, make it harder to scan the form, and can produce a confusing or illogical reading order for screen reader users.
Prefer simple, structured layouts. For longer forms, a single-column layout almost always improves usability and accessibility.
Poor error message placement
Error messages placed at the top of a form, or far from the field that triggered them, leave users unsure about what needs correcting. This is especially disorienting for screen reader users, who may have moved focus away from the relevant field by the time the error is announced.
Place error messages directly adjacent to the field they relate to. The message should clearly describe the problem and explain how to fix it.
Inconsistent styling across forms
When different teams customize forms independently, the result is often inconsistent required field indicators, varying error styles, and different button behaviors across the application. Users who learn the conventions of one form may be confused or misled by another.
Use shared style profiles, themes, and design standards to maintain consistent accessibility patterns. In Nintex K2, accessibility improvements should be applied at the theme and style profile level wherever possible, so they generate consistently across all forms.
Skipping accessibility testing
Forms that look correct visually can still contain significant barriers for users relying on assistive technologies. Incorrect reading order, missing labels, and invisible focus states are all issues that visual inspection will not reveal. Accessibility testing is frequently skipped due to time pressure or an assumption that a visually tidy form is an accessible one.
Build accessibility testing into the development process as a standard step. Test keyboard navigation, use screen readers such as NVDA or JAWS, check contrast ratios, and test at zoom levels between 200% and 400%.
Getting started
If you are applying these practices for the first time, a good starting point is to audit your existing forms against the most impactful areas: color contrast, focus indicators, label usage, and error messaging. These four areas address most common barriers and can often be improved through theme or style profile changes without rebuilding forms from scratch.
For new forms, use the best practices table in this guide as a checklist during design and review. Where possible, involve users with disabilities in testing to surface issues that automated tools and checklists may miss.
Most accessibility barriers in enterprise forms stem from styling decisions, layout complexity, or insufficient testing — not from missing platform features. Consistent practices and thorough testing will significantly reduce barriers for users of all abilities.