Accessibility & Compatibility Summary (WCAG 2.1 Level AA)

:gear: This document covers the accessibility and compatibility features of Specify 7. It serves as support documentation for users and assistive technology users.

Specify is built with modern web standards (React, HTML5, CSS3) and is designed to be compatible with standard web browsers, including their built-in accessibility features and assistive technologies such as screen readers, screen magnifiers, and voice control software.


Accessibility Features

1. Semantic HTML and ARIA

The application uses standard HTML form elements, semantic landmarks, and WAI-ARIA attributes throughout.

[!note]
The codebase defines a custom useId hook that generates stable, human-readable IDs for ARIA associations (e.g., aria-labelledby, aria-describedby), ensuring consistent label-to-control relationships across re-renders.

Implemented patterns:

Feature Implementation
Landmarks <nav>, <main>, <aside>, <header>, <footer> with aria-label where needed
Form controls Native <input>, <select>, <textarea> with explicit <label> associations
Dialogs react-modal with role="dialog", aria-modal, proper focus trapping
Buttons & links Standard <button> and <a> elements; links provide text / aria-label / title
Tables Semantic <table>, <th>, <td> with scope attributes for tabular data
Lists / options Custom select elements with role="listbox", role="option", aria-selected

Key GitHub issues tracking implementation:

2. Keyboard Navigation and Focus Management

Specify 7 supports keyboard-only operation for all core workflows.

[!tip]
Press Tab to move between controls, Enter to activate buttons and links, and Esc to close dialogs.

Keyboard-accessible components:

  • Tree Viewer — Full keyboard navigation with arrow keys, Tab, and focus path persistence across sessions
  • Custom Select Elements — Keyboard-driven listbox with arrow keys, type-ahead, and Enter selection
  • Mapping Editor (Workbench) — Keyboard-navigable with focusable mapping lines and arrow key navigation
  • Dialogs — Focus trapped on open; Esc closes; initial focus set on the first actionable element
  • Form Tables — Newly added rows receive focus automatically
  • Query Builder — Keyboard-navigable filter fields and result sets
  • Data Entry forms — Optional automatic focus on the first editable field on open
  • Toasts — Auto-focused when they appear; focus restored to previous element on dismissal

Key GitHub issues:

3. Live Regions and Notifications

The application uses aria-live regions to announce dynamic content changes to assistive technologies.

Context ARIA Live Region Purpose
Upload status aria-live="polite" Announce data set upload progress
Validation messages aria-live="polite" Announce field validation errors
Search results aria-live="polite" Announce query completion and result count
Async task completion aria-live="polite" Notify when exports or uploads finish
Error toasts aria-live="assertive" Announce critical errors immediately

4. Visual Customization and Preferences

Users can adjust the interface to meet their visual needs:

Preference Purpose
Font size Configurable base font size for all text
Font family Selectable font family for form labels and data entry
Field background Custom background color for input fields
Color theme Light and dark mode support
Reduced transparency Disables translucent dialog backgrounds
Blur behind dialogs Configurable backdrop blur intensity

Key GitHub issue:

5. Language and Internationalization

  • The HTML lang attribute is set dynamically based on the user’s system language
  • Full internationalization (i18n) support for right-to-left (RTL) and left-to-right (LTR) languages, with locale-specific formatting for dates, numbers, and currency
  • Active translations for: English, Spanish, French, German, Russian, Portuguese (Brazil), Ukrainian, and Chinese

Key GitHub issue:

6. Autocomplete and Input Purpose

Form fields use appropriate autocomplete and spellcheck attributes to help users with cognitive disabilities and to enable browser autofill features.

Key GitHub issue:

7. Skip to Content Navigation

A “Skip to Content” link is available at the top of every page, allowing keyboard and screen reader users to bypass repetitive navigation.

[!note]
This link is visually hidden by default and becomes visible on focus via keyboard navigation (Tab on page load).


Compatibility with Assistive Technologies

Screen Readers

Testing has been performed with screen readers:

Screen Reader Browser Status
NVDA Firefox, Chrome Supported

Speech Recognition

Speech recognition is compatible through standard HTML controls on your host operating system.

Keyboard-Only Navigation

All core tasks can be completed using only the keyboard:

  1. Navigation: Tab to move through interactive elements, Enter to activate links and buttons
  2. Data entry: Standard input interactions; Tab moves between fields
  3. Dialogs: Esc to close; Tab cycles through dialog controls; Enter / Space to activate primary actions
  4. Tree view: Arrow keys to navigate hierarchy; Enter to select; Space to toggle expansion
  5. Custom selects: Arrow keys to browse options; Enter to confirm selection; Esc to close the listbox

OS-Level Settings

  • Reduce Motion — Supported
  • Browser zoom (up to 200%) — Layout remains functional; no content loss
  • OS-level font size adjustments — Respected by the application

WCAG 2.1 Level AA Conformance Statement

Specify substantially conforms to WCAG 2.1 Level AA for its supported web interfaces. We employ semantic HTML, ARIA best practices, and ongoing automated and manual testing to preserve accessibility.

Perceivable

SC Criterion Status Key GitHub Issues
1.3.1 Info and Relationships Supported #974, #978, #990, #979
1.3.5 Identify Input Purpose Supported #964
1.4.4 Resize Text Supported #1062
1.4.13 Content on Hover or Focus Supported #2838
Language of Page Supported #995

Operable

SC Criterion Status Key GitHub Issues
2.1.1 Keyboard Supported #980, #981, #983, #984, #1543, #2619
2.1.2 No Keyboard Trap Supported Same as 2.1.1
2.4.3 Focus Order Supported #1543
2.4.4 Link Purpose (In Context) Supported #988, #960
2.4.7 Focus Visible Supported #993

Understandable

SC Criterion Status Key GitHub Issues
3.2.3 Consistent Navigation Supported #961
3.2.4 Consistent Identification Supported #975
3.3.1 Error Identification Supported #992, #1796
3.3.2 Labels or Instructions Supported #992, #1796

Robust

SC Criterion Status Key GitHub Issues
4.1.2 Name, Role, Value Supported #975, #988, #960

Status

Most identified accessibility issues in core workflows have been resolved; we continuously monitor and improve complex controls to maintain conformance and prevent regressions.

References and Tracking

Issues on GitHub related to WCAG are labeled “4 - Accessibility”:
See Search results (sorted by updated desc)

Representative links:


Reporting Accessibility Issues

If you encounter an accessibility barrier in Specify 7 or would like to request an accomodation, please send it to:

  1. GitHub Issues: File a bug at github.com/specify/specify7/issues with the label “4 - Accessibility”
  2. Speciforum: Post in the Support category with details about the issue, the assistive technology used, and steps to reproduce
  3. Email: Contact the Specify team at support@specifysoftware.org