About This Document

Name of Product/Version: OneUptime - Web Application

Report Date: January 2026

Product Description: OneUptime is a comprehensive observability platform that provides uptime monitoring, incident management, status pages, and on-call scheduling capabilities.

Contact Information: accessibility@oneuptime.com

Applicable Standards/Guidelines

This report covers the degree of conformance for the following accessibility standard/guidelines:

Standard/Guideline	Included In Report
Web Content Accessibility Guidelines 2.1	Level A (Yes), Level AA (Yes), Level AAA (No)
EN 301 549 Accessibility requirements for ICT products and services	Yes
Revised Section 508 standards	Yes
BITV 2.0 (German Accessibility Standard)	Yes (based on EN 301 549 alignment)

Terms

The terms used in this document are based on ISO/IEC/IEEE 26514:2022:

Supports: The functionality of the product has at least one method that meets the criterion without known defects or meets with equivalent facilitation.
Partially Supports: Some functionality of the product does not meet the criterion.
Does Not Support: The majority of product functionality does not meet the criterion.
Not Applicable: The criterion is not relevant to the product.

WCAG 2.1 Level A Conformance

Criteria	Conformance Level	Remarks and Explanations
1.1.1 Non-text Content	Supports	Images include descriptive alt text attributes. Icons use aria-hidden="true" for decorative elements. File upload previews include contextual alt text.
1.2.1 Audio-only and Video-only (Prerecorded)	Not Applicable	The application does not contain prerecorded audio-only or video-only content.
1.2.2 Captions (Prerecorded)	Not Applicable	The application does not contain prerecorded synchronized media.
1.2.3 Audio Description or Media Alternative (Prerecorded)	Not Applicable	The application does not contain prerecorded synchronized media.
1.3.1 Info and Relationships	Supports	Semantic HTML is used throughout. Forms include proper labels and fieldsets. Data tables include headers with scope="col" attributes. Screen reader-only text provides context for visual elements.
1.3.2 Meaningful Sequence	Supports	Content is presented in a logical reading order. DOM structure follows visual presentation.
1.3.3 Sensory Characteristics	Supports	Instructions do not rely solely on sensory characteristics. Error states use both color and text indicators.
1.4.1 Use of Color	Supports	Color is not used as the only means of conveying information. Status indicators use icons in addition to color.
1.4.2 Audio Control	Not Applicable	The application does not automatically play audio for more than 3 seconds.
2.1.1 Keyboard	Supports	All functionality is accessible via keyboard. Interactive elements support tabIndex. Modal close buttons support keyboard activation via Enter, Space, and Escape keys.
2.1.2 No Keyboard Trap	Supports	Users can navigate away from all components using standard keyboard navigation.
2.1.4 Character Key Shortcuts	Not Applicable	The application does not implement character key shortcuts.
2.2.1 Timing Adjustable	Supports	Session timeouts can be extended or disabled. No content-based time limits exist.
2.2.2 Pause, Stop, Hide	Supports	Auto-updating content (such as real-time dashboards) can be paused or configured.
2.3.1 Three Flashes or Below Threshold	Supports	The application does not contain content that flashes more than three times per second.
2.4.1 Bypass Blocks	Supports	Skip to main content link is provided for keyboard users. Navigation landmarks are implemented using role="navigation" and aria-label. Main content area is properly identified.
2.4.2 Page Titled	Supports	All pages have descriptive titles that describe the page topic or purpose.
2.4.3 Focus Order	Supports	Focus order follows logical reading sequence. TabIndex is properly managed across components.
2.4.4 Link Purpose (In Context)	Supports	Link text clearly describes the destination or purpose of the link.
2.5.1 Pointer Gestures	Supports	All functionality that uses multipoint or path-based gestures can be operated with a single pointer.
2.5.2 Pointer Cancellation	Supports	Actions are triggered on the up-event rather than down-event.
2.5.3 Label in Name	Supports	Visible labels match accessible names. Screen reader-only text uses sr-only class appropriately.
2.5.4 Motion Actuation	Not Applicable	The application does not require device motion for functionality.
3.1.1 Language of Page	Supports	All pages include lang="en" attribute on the HTML element.
3.2.1 On Focus	Supports	No context changes occur when components receive focus.
3.2.2 On Input	Supports	Form controls do not trigger unexpected context changes when changed.
3.3.1 Error Identification	Supports	Form errors are identified and described in text. Error states include visual and programmatic indicators.
3.3.2 Labels or Instructions	Supports	Form fields include visible labels and instructions. FieldLabel component provides consistent labeling.
4.1.1 Parsing	Supports	HTML is well-formed with unique IDs. React components ensure valid markup generation.
4.1.2 Name, Role, Value	Supports	Semantic roles are used extensively (role="menu", role="dialog", role="switch", role="status", role="alert", etc.). ARIA attributes are implemented across components. Status indicators include aria-label for screen reader announcements.

WCAG 2.1 Level AA Conformance

Criteria	Conformance Level	Remarks and Explanations
1.2.4 Captions (Live)	Not Applicable	The application does not contain live synchronized media.
1.2.5 Audio Description (Prerecorded)	Not Applicable	The application does not contain prerecorded video content.
1.3.4 Orientation	Supports	Content is not restricted to a single display orientation.
1.3.5 Identify Input Purpose	Supports	Common input fields support autocomplete attributes including email, password, phone, name, and URL fields for improved autofill support.
1.4.3 Contrast (Minimum)	Supports	Tailwind CSS color classes provide good contrast. Color indicators include aria-labels for screen reader users. Progress bars include descriptive labels.
1.4.4 Resize Text	Supports	Text can be resized up to 200% without loss of content or functionality.
1.4.5 Images of Text	Supports	Text is rendered as text rather than images. Logos are the exception as permitted.
1.4.10 Reflow	Supports	Responsive design ensures content reflows at different viewport widths without horizontal scrolling.
1.4.11 Non-text Contrast	Supports	Focus indicators use ring-indigo-500 with good contrast.
1.4.12 Text Spacing	Supports	Content remains accessible when text spacing is adjusted within WCAG requirements.
1.4.13 Content on Hover or Focus	Supports	Tooltips are accessible via both hover and keyboard focus. Tooltip content is interactive and persistent, allowing users to hover over the tooltip content. Tooltips include proper ARIA attributes for screen readers.
2.4.5 Multiple Ways	Supports	Multiple navigation methods are provided including menus, search, and direct links.
2.4.6 Headings and Labels	Supports	Headings and labels describe topic or purpose. Semantic heading hierarchy is maintained.
2.4.7 Focus Visible	Supports	Focus indicators are visible using focus:ring-2 and focus-visible:outline CSS patterns.
3.1.2 Language of Parts	Supports	The application is primarily in English. Multi-language content sections are appropriately marked.
3.2.3 Consistent Navigation	Supports	Navigation components appear consistently across pages. SideMenu component maintains consistent structure.
3.2.4 Consistent Identification	Supports	Components with the same functionality are identified consistently throughout the application.
3.3.3 Error Suggestion	Supports	Error messages provide guidance on correction. Input fields are linked to error messages via aria-describedby and marked with aria-invalid for screen readers.
3.3.4 Error Prevention (Legal, Financial, Data)	Supports	Confirmation dialogs are used for destructive actions. Data submissions can be reviewed before final confirmation.
4.1.3 Status Messages	Supports	Toast notifications use aria-live="assertive". Alert components use role="alert" with aria-live="polite" for screen reader announcements. Status bubbles include role="status" for accessibility.

EN 301 549 / BITV 2.0 Relevant Criteria

EN 301 549 is the European standard for digital accessibility, and BITV 2.0 (Barrierefreie-Informationstechnik-Verordnung) is the German implementation based on EN 301 549. The following criteria are particularly relevant for web applications:

Section	Criteria	Conformance Level	Remarks
9.1	Perceivable (WCAG 2.1 Level A and AA)	Supports	See WCAG criteria above for detailed conformance. All Level A criteria are fully supported; most Level AA criteria are supported with minor exceptions noted.
9.2	Operable (WCAG 2.1 Level A and AA)	Supports	See WCAG criteria above for detailed conformance. Full keyboard navigation, focus management, and navigation landmarks implemented.
9.3	Understandable (WCAG 2.1 Level A and AA)	Supports	See WCAG criteria above for detailed conformance.
9.4	Robust (WCAG 2.1 Level A and AA)	Supports	See WCAG criteria above for detailed conformance. ARIA roles, states, and properties are properly implemented across all components.
11.7	User Preferences	Supports	The application respects system-level accessibility preferences such as reduced motion where applicable. Font sizes can be adjusted via browser settings.
12.1.1	Accessibility and Compatibility Features	Supports	Documentation of accessibility features is provided in this VPAT.
12.2.4	Accessible Documentation	Supports	Product documentation follows accessibility best practices with proper semantic structure, headings, and navigation.

Revised Section 508 Standards

OneUptime's conformance to the Revised Section 508 Standards (as referenced in the 2017 update) aligns with our WCAG 2.1 Level A and AA conformance as detailed above. The Revised Section 508 Standards incorporate WCAG 2.0 Level A and AA success criteria for web content.

Chapter 5: Software

Criteria	Conformance Level	Remarks
501.1 Scope	Supports	OneUptime is a web-based application accessed through standard web browsers.
502 Interoperability with Assistive Technology	Supports	The application uses standard web technologies and comprehensive ARIA implementations to support assistive technology including screen readers and keyboard-only navigation.
503 Applications	Supports	User interface components provide accessible names and roles through ARIA attributes. All interactive elements support keyboard operation.
504 Authoring Tools	Supports	Where the application allows content creation, accessibility guidance is provided and form controls are fully accessible.

Accessibility Features Implemented

OneUptime has implemented the following accessibility features throughout the application:

ARIA Support

ARIA Labels: aria-labelledby, aria-label used across interactive components including icon-only buttons
ARIA States: aria-expanded, aria-checked, aria-pressed, aria-disabled, aria-invalid, aria-sort for sortable tables
ARIA Live Regions: aria-live="polite" and aria-live="assertive" for dynamic content, loading indicators, and status updates
ARIA Roles: role="dialog", role="menu", role="switch", role="navigation", role="alert", role="button", role="status"

Keyboard Navigation

Full keyboard navigation support for interactive elements
Visible focus indicators using focus ring styles
TabIndex management for logical focus order
Arrow key navigation in dropdown menus with Home/End support
Accordion components support Enter/Space keys for expand/collapse
Copy buttons support keyboard activation
Escape key closes modals and dropdown menus
Modal dialogs trap focus and support initial focus management
Pagination controls are fully keyboard accessible with aria-labels
Toggle switches support keyboard operation with proper aria-checked
Radio groups support keyboard navigation with proper labels

Screen Reader Support

Screen reader-only text using sr-only class pattern
Descriptive button and link text
Form labels associated with inputs
Status messages announced via live regions
Loading states announced with role="status" and aria-live
Table headers include scope attributes and aria-sort for sortable columns

Visual Accessibility

Error states indicated by both color and icons with aria-invalid and aria-describedby
Consistent focus styles across the application
Responsive design that maintains accessibility at all viewport sizes
Semantic heading hierarchy
Color indicators include text alternatives via aria-label
Progress bars include role="progressbar" with aria-valuenow/min/max

Component-Specific Accessibility

Tabs: Proper tablist/tab/tabpanel roles with aria-selected and aria-controls
Card Select: Uses radiogroup role with radio role options and aria-checked
Checkboxes: Properly linked descriptions via aria-describedby
Progress Bars: Full progressbar role implementation with value attributes
Color Pickers: Keyboard accessible with button role and aria-labels
Tooltips: Interactive tooltips accessible via hover and focus with ARIA support
Toggle Switches: Uses role="switch" with unique aria-labelledby and aria-describedby for errors
Radio Groups: Proper radiogroup role with aria-label, individual options have unique IDs and labels
More Menu: Full menu role with keyboard navigation (Arrow keys, Home, End, Escape)
Dropdowns: Includes aria-label, aria-invalid, and aria-describedby for error states
Modals: Escape key support, focus trapping, aria-describedby for descriptions
Pagination: Navigation landmark with keyboard-accessible Previous/Next controls and aria-current for current page

Known Limitations and Roadmap

We are continuously working to improve accessibility. The following areas have been identified for future enhancement:

Enhancing color contrast in some secondary UI elements for 1.4.11 compliance
Adding automated accessibility testing to our CI/CD pipeline
Expanding support for high contrast mode and reduced motion preferences
Improving screen reader announcements for complex data visualizations

Evaluation Methodology

This VPAT was prepared based on:

Manual code review of React components and their ARIA implementations
Analysis of Tailwind CSS accessibility classes used throughout the application
Review of form components, navigation patterns, and interactive elements

We recommend conducting a full accessibility audit with assistive technology testing for comprehensive conformance verification.