Accessibility
At Skedulo, we strive to empower every individual to fully engage with Skedulo products and solutions without limitations. We're committed to embedding accessibility into the foundations of our design system and our product offering, and we're working towards adherence with Web Content Accessibility Guidelines (WCAG) 2.1 Level AA. The goal is to exceed minimum requirements whenever possible. Web accessibility ensures that people with disabilities can perceive, understand, navigate, interact with, and contribute to the applications we build. This means our applications need to be Perceivable, Operable, Understandable, and Robust (POUR). This includes providing keyboard interaction alternatives for all mouse-based actions, properly identifying all form fields and buttons, and providing text-based alternatives for every element. Standards compliant markup: The semantic markup and use of ARIA roles in our components are based on W3C standards and industry best practices. Keyboard navigation: Users should be able to navigate any page without a mouse. For every element a mouse user can click on, a keyboard-only user must be able to perform the same action. Key keyboard patterns include Tab/Shift+Tab to move between elements, Escape to close overlays, Enter/Space to activate, and arrow keys to navigate within components. Screen reader accessibility: Make sure screen reader users can navigate to every element. Keep users up-to-date when on-screen content changes — unexpected changes can be very confusing. Provide alternative text labels for all important interface elements. Color: Never convey information using color alone. Contrast ratios need to meet WCAG 2.1 Level AA guidelines. Typography: Text should remain usable at different zoom levels (e.g. 200% zoom). Apply heading hierarchy logically (H1, H2, H3, H4). Increase the size of meaningful interface icons as font size increases. Forms: Form validation should be easy to understand, view, and navigate. Errors and alerts should draw focus visually and from keyboard navigation/screen readers. Labels are required for all form fields — placeholder text is not enough because it disappears and is not treated as a label by screen readers. The only exception is Search fields, where the magnifying glass icon serves as a visible label (though a visually hidden label is still required).
Usage Guidance
When to use
- +Always follow accessibility guidelines for all UI development.
- +Ensure applications are Perceivable, Operable, Understandable, and Robust (POUR).
- +Test with keyboard navigation and screen readers.
When not to use
- −These guidelines apply to all contexts — there is no case where accessibility should be skipped.
Examples
Guidelines
Do
- ✓Use semantic HTML elements and ARIA roles based on W3C standards.
- ✓Ensure every mouse-based action has a keyboard alternative.
- ✓Provide alternative text labels for all important interface elements.
- ✓Maintain WCAG 2.1 Level AA contrast ratios.
- ✓Ensure text remains usable at 200% zoom.
- ✓Use visible labels on all form fields — not just placeholders.
- ✓Apply heading hierarchy logically (H1, H2, H3, H4).
Don't
- ✗Don't convey information using color alone.
- ✗Don't use placeholder text as the only label for form fields.
- ✗Don't use div/span for interactive elements — use button/a.
- ✗Don't remove focus outlines without providing alternatives.
- ✗Don't make unexpected on-screen changes without notifying assistive technologies.