I am writing as a U.S.-based NocoBase user to share an important accessibility consideration for organizations that use NocoBase in the United States.
In the U.S., many public agencies, healthcare organizations, universities, and businesses are expected to make their websites and web applications accessible to users with disabilities. This is commonly discussed under the Americans with Disabilities Act, or ADA. From a technical standpoint, the most widely used accessibility standard is WCAG, which stands for Web Content Accessibility Guidelines.
For U.S. public-sector organizations, the Department of Justice has adopted WCAG 2.1 Level AA as the technical standard for web content and mobile app accessibility under ADA Title II. Even for private organizations, WCAG Level AA is commonly used as the practical benchmark for accessibility risk reduction and inclusive design.
I understand that NocoBase is developed by an international team, and U.S. ADA expectations may not be familiar to developers outside the United States. The main idea is simple: users with disabilities should be able to use NocoBase applications with screen readers, keyboard-only navigation, visible focus indicators, sufficient color contrast, and other assistive technologies.
This is especially important because NocoBase is not only a website. It is a platform used to build real business applications, forms, dashboards, tables, workflows, and administrative portals. If the core components are not accessible, then every application built on top of NocoBase may inherit those accessibility issues.
I would like to respectfully request that NocoBase consider making WCAG accessibility a product-level priority. This does not mean NocoBase must provide legal advice or guarantee ADA compliance for every customer application. However, stronger WCAG support at the framework, component, and theme level would help U.S. customers build accessible applications more confidently.
I have included a suggested accessibility roadmap below that may help guide future development.
Thank you for considering this request. I believe accessibility support would make NocoBase more inclusive, more enterprise-ready, and more attractive to U.S. organizations in healthcare, education, government, and business environments.
Suggested WCAG/ADA Accessibility Roadmap for NocoBase
Recommended Target
NocoBase should consider supporting WCAG 2.1 Level AA as the minimum accessibility target, with WCAG 2.2 Level AA as a forward-looking development standard.
This would help U.S. customers who need to meet ADA-related accessibility expectations and would also improve usability for all users.
- Build an Official Accessible Theme
Create an official WCAG AA accessible theme for NocoBase.
Recommended improvements:
- Ensure normal text has at least 4.5:1 color contrast.
- Ensure large text, icons, borders, and meaningful UI controls have at least 3:1 contrast.
- Avoid light gray text on white backgrounds.
- Avoid using color alone to communicate status, errors, warnings, or success.
- Provide accessible light mode and dark mode options.
- Make focus indicators highly visible in all themes.
Example:
Instead of showing a red field border only, display a clear text error such as “Error: This field is required.”
- Improve Keyboard-Only Navigation
All major NocoBase workflows should be usable without a mouse.
Users should be able to:
- Navigate the application using Tab and Shift+Tab.
- Activate buttons and links using Enter or Space.
- Open and close menus, dropdowns, drawers, and modals with the keyboard.
- Use Escape to close menus and modals when appropriate.
- Move through tables, filters, form fields, and action buttons logically.
- Complete create, read, update, delete, search, filter, upload, and export workflows without using a mouse.
Recommended developer action:
Add manual keyboard-only testing to the release process for every major UI component.
- Add Strong Visible Focus Indicators
Keyboard users must always know where they are on the page.
Recommended improvements:
- Add a clear default focus style for buttons, links, fields, menus, tabs, modals, table actions, and custom components.
- Do not remove browser focus outlines unless replacing them with an equally visible custom indicator.
- Ensure focus is not hidden behind sticky headers, sidebars, modals, or floating toolbars.
- Ensure focus order follows the visual and logical order of the page.
- Strengthen Screen Reader Support
NocoBase components should use semantic HTML and appropriate ARIA attributes so screen readers can understand the interface.
Recommended improvements:
- Use native HTML buttons for actions instead of clickable div or span elements.
- Use real links for navigation.
- Use proper labels for all form fields.
- Add accessible names for icon-only buttons.
- Make error messages programmatically associated with the related input field.
- Add aria-live regions for important status messages, such as “Record saved successfully” or “Validation error.”
- Ensure menus, tabs, drawers, and modals follow expected ARIA patterns.
Example:
An icon-only edit button should not only display a pencil icon. It should have an accessible name such as “Edit record.”
- Make Forms Accessible by Default
Forms are one of the most important parts of NocoBase. They should be accessible without requiring custom code from each customer.
Recommended improvements:
- Every form input should have a visible label.
- Required fields should be clearly identified.
- Placeholder text should not be used as the only label.
- Help text should be associated with the correct input.
- Validation errors should be visible and announced to screen readers.
- After failed submission, focus should move to the first error or an error summary.
- Date, time, number, select, relation, upload, and rich text fields should all be tested for accessibility.
- Improve Modal, Drawer, and Popup Accessibility
NocoBase uses many drawers, popups, and modals. These need strong accessibility behavior.
Recommended improvements:
- When a modal or drawer opens, keyboard focus should move inside it.
- Focus should remain inside the modal until it is closed.
- Escape should close the modal when appropriate.
- The close button should have a clear accessible name.
- After closing, focus should return to the button or element that opened it.
- Screen readers should be able to identify the modal title and purpose.
- Improve Table and Data Grid Accessibility
Tables and data grids are central to NocoBase. They need to work well for screen reader and keyboard users.
Recommended improvements:
- Table headers should be properly associated with cells.
- Sort buttons should announce the current sort state.
- Row action buttons should have clear names, such as “Edit patient record” or “Delete authorization record.”
- Pagination controls should be keyboard accessible.
- Bulk selection checkboxes should have clear labels.
- Empty states should be announced clearly.
- Filters should have accessible labels and instructions.
- Improve Dashboard and Chart Accessibility
Dashboards should not rely only on visual charts.
Recommended improvements:
- Provide text summaries for charts and metrics.
- Provide table equivalents for chart data.
- Do not rely on hover-only tooltips.
- Ensure chart colors meet contrast requirements.
- Avoid using color alone to distinguish categories.
- Make filters and dashboard controls keyboard accessible.
- Add Accessibility Requirements for Plugin Developers
Because NocoBase has a plugin architecture, third-party and custom plugins can introduce accessibility problems.
Recommended improvements:
- Publish an accessibility checklist for plugin developers.
- Provide accessible component examples.
- Require labels for custom fields.
- Require keyboard support for custom blocks and actions.
- Encourage semantic HTML before ARIA.
- Provide guidance for accessible modals, menus, buttons, tables, and forms.
- Add Automated Accessibility Testing
Automated testing will not catch every issue, but it can prevent many common accessibility problems.
Recommended developer action:
Add accessibility testing into the NocoBase development workflow using tools such as:
- axe-core
- Lighthouse accessibility audits
- Playwright accessibility checks
- Storybook accessibility testing, if Storybook is used
- Contrast checking tools
- Manual NVDA testing on Windows
- Manual VoiceOver testing on macOS and iOS
- Manual keyboard-only testing
- Publish an Accessibility Statement or Roadmap
NocoBase could help customers by publishing an accessibility roadmap or conformance statement.
This could include:
- Current accessibility goals
- Known limitations
- Supported WCAG target level
- Components already reviewed
- Components still needing review
- Recommended customer configuration steps
- Guidance for accessible theme customization
- Guidance for accessible plugin development
- Suggested Priority Order
Phase 1: Foundation
- Accessible theme
- Global focus indicators
- Keyboard navigation baseline
- Screen reader labels for common buttons and form fields
- Accessible modal and drawer behavior
Phase 2: Core Components
- Forms
- Tables
- Filters
- Menus
- Tabs
- Upload fields
- Date/time fields
- Relation fields
- Action buttons
Phase 3: Advanced Interfaces
- Dashboards
- Charts
- Kanban views
- Calendar views
- Workflow interfaces
- Plugin developer guidance
Phase 4: Testing and Documentation
- Automated accessibility tests
- Manual testing process
- Accessibility checklist
- Accessibility documentation
- Public roadmap or conformance statement
Why This Matters
Improving WCAG accessibility would help NocoBase support users who rely on screen readers, keyboard navigation, high contrast settings, and assistive technologies. It would also help U.S. customers reduce compliance risk when building applications for healthcare, education, government, enterprise, and public-facing workflows.
This would make NocoBase more inclusive, more professional, and more competitive for organizations that must consider ADA and WCAG accessibility requirements.