Accessibility Statement

Last updated: April 13, 2026

1. Our Commitment

dosya.dev is committed to ensuring digital accessibility for people of all abilities. We believe that everyone should have equal access to file transfer, storage, and sharing services regardless of disability, impairment, or assistive technology used.

We are continually improving the user experience for everyone and applying the relevant accessibility standards to ensure we provide equal access to all users.

2. Conformance Status

We aim to conform to the Web Content Accessibility Guidelines (WCAG) 2.2 Level AA standards. These guidelines explain how to make web content more accessible for people with disabilities and more user-friendly for everyone.

While we strive for full conformance, we acknowledge that some areas of our website may not yet fully meet all WCAG 2.2 Level AA criteria. We are actively working to identify and resolve these gaps.

3. Accessibility Features

dosya.dev includes the following accessibility features:

3.1 Navigation and Structure

  • Semantic HTML: We use proper HTML elements (headings, landmarks, lists, forms) to convey document structure and meaning to assistive technologies.
  • Keyboard Navigation: All interactive elements and functionality can be accessed using a keyboard alone, without requiring a mouse or touchscreen.
  • Skip Navigation: Skip-to-content links are provided to allow keyboard users to bypass repetitive navigation elements.
  • Consistent Navigation: Navigation menus are consistent across all pages to provide a predictable browsing experience.
  • Breadcrumb Navigation: Dashboard pages include breadcrumb trails to help users understand their location within the site hierarchy.
  • Focus Indicators: Visible focus indicators are provided for all interactive elements to help keyboard users track their position on the page.

3.2 Visual Design

  • Color Contrast: Text and interactive elements maintain sufficient color contrast ratios (at least 4.5:1 for normal text, 3:1 for large text) against their backgrounds.
  • Resizable Text: All text can be resized up to 200% without loss of content or functionality using browser zoom controls.
  • Responsive Design: The website is fully responsive and adapts to different screen sizes, orientations, and zoom levels.
  • No Color-Only Information: We do not use color as the sole means of conveying information. Visual indicators such as icons, labels, and patterns supplement color cues.
  • Reduced Motion: We respect the prefers-reduced-motion media query and disable non-essential animations for users who have indicated this preference in their operating system settings.

3.3 Content and Media

  • Alternative Text: All meaningful images and icons include descriptive alternative text for screen readers. Decorative images are marked with empty alt attributes.
  • ARIA Labels: Interactive elements, buttons, and dynamic content regions use appropriate ARIA roles, states, and properties to convey their purpose and status to assistive technologies.
  • Link Text: Links use descriptive text that clearly indicates their destination or purpose, avoiding generic phrases like "click here."
  • Form Labels: All form fields have associated labels, placeholder text is supplementary rather than a replacement for labels, and error messages are clearly associated with the relevant fields.
  • Error Identification: Form validation errors are clearly identified with descriptive text messages and are announced to screen readers.

3.4 File Management

  • Upload Progress: File upload progress is conveyed both visually and to assistive technologies using ARIA live regions.
  • Drag and Drop Alternative: While drag-and-drop file upload is supported, an accessible file picker button is always available as an alternative.
  • Status Updates: Transfer status changes, completion notifications, and error alerts are announced to screen readers using live regions.

4. Tested Assistive Technologies

We test dosya.dev for compatibility with the following assistive technologies:

  • Screen Readers: NVDA (Windows), JAWS (Windows), VoiceOver (macOS/iOS), TalkBack (Android)
  • Voice Control: Dragon NaturallySpeaking, Voice Control (macOS/iOS)
  • Screen Magnification: ZoomText, built-in OS magnification tools
  • Browsers: Chrome, Firefox, Safari, and Edge (latest two major versions)

5. Known Limitations

While we strive for comprehensive accessibility, the following areas have known limitations that we are actively working to address:

  • Complex Data Tables: Some file management tables with sorting and filtering may not fully convey their interactive state to all screen readers. We are working to improve ARIA markup in these components.
  • Third-Party Integrations: Some third-party services or embedded content (e.g., payment forms, OAuth login providers) may not fully meet our accessibility standards. We work with our vendors to improve their accessibility and provide alternative workflows where possible.
  • PDF Previews: Inline PDF previews may not be fully accessible to screen readers. Users can download files directly as an alternative.
  • Real-Time Notifications: Some real-time status notifications may not be reliably captured by all screen readers in all circumstances.

We are committed to fixing these issues and include accessibility improvements in every release cycle.

6. Standards and Guidelines

Our accessibility efforts are guided by the following standards and guidelines:

  • WCAG 2.2: Web Content Accessibility Guidelines 2.2 (Level AA target)
  • Section 508: United States Section 508 of the Rehabilitation Act
  • EN 301 549: European standard for accessibility requirements for ICT products and services
  • ADA: Americans with Disabilities Act, Title III
  • EAA: European Accessibility Act (Directive 2019/882)
  • ARIA: WAI-ARIA (Accessible Rich Internet Applications) 1.2 specification

7. Assessment and Testing

We assess the accessibility of dosya.dev through the following methods:

  • Automated Testing: We use automated accessibility scanning tools (such as axe-core and Lighthouse) integrated into our development pipeline to catch common issues during development.
  • Manual Testing: Our team conducts regular manual accessibility audits using screen readers, keyboard-only navigation, and other assistive technologies.
  • User Testing: We periodically conduct usability testing sessions with users who rely on assistive technologies to gather direct feedback.
  • Third-Party Audits: We engage independent accessibility consultants to conduct periodic audits and provide recommendations for improvement.

8. Feedback and Reporting Issues

We welcome your feedback on the accessibility of dosya.dev. If you encounter any accessibility barriers or have suggestions for improvement, please let us know:

When reporting an accessibility issue, please include:

  • A description of the problem you encountered
  • The page URL where the issue occurred
  • The browser and assistive technology you were using
  • Any steps to reproduce the issue

We aim to acknowledge accessibility feedback within 2 business days and resolve reported issues within 30 days where feasible. For critical barriers that prevent access to core functionality, we will prioritize an expedited resolution.

9. Enforcement Procedure

If you are not satisfied with our response to your accessibility feedback, you may escalate the matter through the following channels:

  • United States: You may file a complaint with the U.S. Department of Justice Civil Rights Division or the appropriate federal agency.
  • European Union: You may contact the national enforcement body in your EU member state responsible for digital accessibility.
  • United Kingdom: You may contact the Equality and Human Rights Commission (EHRC) or the Equality Advisory Support Service (EASS).

10. Ongoing Efforts

Accessibility is an ongoing commitment at dosya.dev. Our current and planned efforts include:

  • Integrating accessibility checks into our continuous integration and deployment pipeline.
  • Providing accessibility training for all team members involved in design and development.
  • Including accessibility acceptance criteria in all feature development stories.
  • Conducting quarterly accessibility reviews of new and updated features.
  • Maintaining an internal accessibility knowledge base and design guidelines.
  • Engaging with the disability community to understand evolving needs and best practices.