Accessibility Statement

Our commitment to making Networkli accessible to everyone

Last Updated: October 12, 2025

1. Our Commitment to Accessibility

Networkli is committed to ensuring digital accessibility for people with disabilities. We are continually improving the user experience for everyone and applying the relevant accessibility standards to ensure we provide equal access and opportunity to all users.

1.1 Our Accessibility Goals

  • Make professional networking accessible to everyone, regardless of ability
  • Provide an inclusive platform where all community members can connect meaningfully
  • Ensure our AI-powered matching is equitable and accessible
  • Continuously improve accessibility based on user feedback and testing
  • Meet or exceed applicable accessibility standards and legal requirements

1.2 Ongoing Efforts

Accessibility is an ongoing effort. We:

  • Conduct regular accessibility audits of our platform
  • Test with users who have disabilities
  • Train our development team on accessibility best practices
  • Incorporate accessibility into our design and development process
  • Address reported accessibility issues promptly

2. Accessibility Standards and Conformance

2.1 WCAG 2.1 Guidelines

The Web Content Accessibility Guidelines (WCAG) define requirements for designers and developers to improve accessibility for people with disabilities. WCAG 2.1 defines three levels of conformance:

  • Level A: Minimum level of accessibility
  • Level AA: Addresses major accessibility barriers (our target)
  • Level AAA: Highest level of accessibility (not achievable for all content)

2.2 Our Conformance Status

Current Status: Partially Conformant with WCAG 2.1 Level AA

"Partially conformant" means that some parts of the content do not fully conform to the accessibility standard. We are actively working to achieve full conformance.

2.3 Additional Standards

In addition to WCAG 2.1, we strive to comply with:

  • ADA (Americans with Disabilities Act): US federal law prohibiting disability discrimination
  • Section 508: US federal accessibility standard for electronic and information technology
  • EN 301 549: European standard for accessibility of ICT products and services
  • AODA (Accessibility for Ontarians with Disabilities Act): Ontario, Canada accessibility standard

3. Accessibility Features

Networkli includes the following accessibility features organized by WCAG principles:

3.1 Perceivable

Information and user interface components must be presentable to users in ways they can perceive.

Text Alternatives

  • Alt text for all meaningful images, including profile photos and icons
  • Descriptive labels for form inputs and buttons
  • ARIA labels for interactive elements (swipe cards, connection buttons)
  • Text descriptions for AI-generated match recommendations

Adaptable Content

  • Responsive design that adapts to different screen sizes and orientations
  • Content can be zoomed up to 200% without loss of functionality
  • Proper semantic HTML5 structure (headings, landmarks, lists)
  • Mobile apps support platform-specific accessibility features (VoiceOver, TalkBack)

Distinguishable Content

  • Color contrast: Minimum 4.5:1 ratio for normal text, 3:1 for large text
  • Text sizing: Font sizes are relative and scalable
  • Focus indicators: Visible keyboard focus indicators on all interactive elements
  • Color independence: Information is not conveyed by color alone
  • Audio control: Background sounds can be paused or controlled

3.2 Operable

User interface components and navigation must be operable.

Keyboard Accessibility

  • Full keyboard navigation support (Tab, Shift+Tab, Enter, Space, Escape)
  • All interactive elements accessible via keyboard
  • Logical tab order following visual layout
  • Keyboard shortcuts for common actions (documented in help section)
  • No keyboard traps (users can navigate away from all elements)

Sufficient Time

  • No time limits on reading or interacting with content
  • Session timeouts provide warnings and extension options (20-hour session limit)
  • Auto-updating content (like notifications) can be paused

Seizure and Physical Reactions

  • No content flashes more than 3 times per second
  • Animation and motion can be disabled (respects `prefers-reduced-motion`)
  • Smooth scrolling can be disabled

Navigable

  • Skip links: "Skip to main content" link on all pages
  • Page titles: Descriptive and unique titles for each page
  • Focus order: Logical and intuitive focus order
  • Link purpose: Link text clearly describes destination
  • Multiple ways: Navigation menu, search, breadcrumbs where applicable
  • Headings and labels: Descriptive headings and form labels
  • Focus visible: Clear visual indication of keyboard focus

Input Modalities

  • Touch targets are at least 44×44 pixels (mobile) for easy interaction
  • Pointer (mouse/touch) gestures have keyboard alternatives
  • Swipe actions can be performed with keyboard or alternative input
  • Motion-activated features have accessible alternatives

3.3 Understandable

Information and operation of user interface must be understandable.

Readable

  • Language of page is programmatically identified (lang="en")
  • Clear, plain language used throughout (avoiding jargon when possible)
  • Abbreviations and technical terms are explained
  • Reading level is appropriate for general audience (aim for 9th grade level)

Predictable

  • Consistent navigation across all pages
  • Consistent identification of components (buttons, icons, labels)
  • Focus does not cause unexpected context changes
  • Forms do not auto-submit without user confirmation

Input Assistance

  • Clear error identification and description
  • Labels and instructions for form inputs
  • Error suggestions provided when possible
  • Confirmation required for important actions (delete account, cancel subscription)
  • Input fields have autocomplete attributes for common data

3.4 Robust

Content must be robust enough to be interpreted by a wide variety of user agents, including assistive technologies.

Compatible

  • Valid HTML5 markup (passes W3C validation)
  • ARIA landmarks and roles for complex widgets
  • Name, role, value programmatically exposed for all UI components
  • Status messages announced to screen readers (ARIA live regions)

4. Compatibility with Assistive Technologies

Networkli is designed to be compatible with the following assistive technologies and browsers:

4.1 Screen Readers

Screen ReaderPlatformBrowserSupport Status
JAWSWindowsChrome, Firefox, Edge✓ Supported
NVDAWindowsChrome, Firefox✓ Supported
VoiceOvermacOSSafari, Chrome✓ Supported
VoiceOveriOSSafari, Mobile App✓ Supported
TalkBackAndroidChrome, Mobile App✓ Supported

4.2 Other Assistive Technologies

  • Screen magnification software: ZoomText, MAGic, built-in OS magnifiers
  • Speech recognition software: Dragon NaturallySpeaking, Windows Speech Recognition, Voice Control (macOS/iOS)
  • Switch control: iOS Switch Control, Android Switch Access
  • Alternative keyboards: On-screen keyboards, adaptive keyboards
  • Browser extensions: High contrast modes, text-to-speech readers

4.3 Supported Browsers and Platforms

We test Networkli on the following browsers and platforms:

  • Desktop: Chrome (latest 2 versions), Firefox (latest 2 versions), Safari (latest 2 versions), Edge (latest 2 versions)
  • Mobile: iOS Safari (latest 2 versions), Chrome for Android (latest 2 versions)
  • Mobile Apps: iOS 14+, Android 10+

5. Technical Specifications

Accessibility of Networkli relies on the following technologies:

5.1 Core Technologies

  • HTML5: Semantic markup and accessible elements
  • CSS3: Visual presentation and responsive design
  • JavaScript: Interactive functionality (progressively enhanced)
  • WAI-ARIA: Accessible Rich Internet Applications attributes and roles
  • Next.js: React-based framework with accessibility features

5.2 Required Browser Features

To use Networkli with full accessibility, your browser must support:

  • JavaScript (required for core functionality)
  • Cookies (required for authentication)
  • CSS Grid and Flexbox (for responsive layout)
  • ARIA attributes and landmarks
  • Focus management and keyboard events

6. Known Limitations and Issues

Despite our efforts, some accessibility barriers remain. We are actively working to address these issues:

6.1 Current Known Issues

Issue: Swipe interaction accessibility

  • Description: Swipe gestures for matching may be difficult for some users to perform
  • Workaround: Keyboard users can use arrow keys and Enter/Space; Accept/Pass buttons are also provided
  • Status: Improving keyboard navigation and button alternatives (Target: Q1 2026)

Issue: Real-time messaging updates

  • Description: New messages may not always be announced to screen readers in real-time
  • Workaround: Page refresh shows new messages; investigating ARIA live region improvements
  • Status: Implementing better ARIA live announcements (Target: Q4 2025)

Issue: Profile photo uploads

  • Description: Drag-and-drop file upload may not be fully accessible to keyboard users
  • Workaround: "Choose File" button provides accessible alternative
  • Status: Completed - accessible file input available

Issue: Some third-party content

  • Description: Embedded content from third parties (payment forms, social media) may have accessibility issues
  • Workaround: We work with vendors to ensure accessibility; contact us if you encounter issues
  • Status: Ongoing vendor engagement

6.2 Planned Improvements

We are committed to continuous improvement. Our accessibility roadmap includes:

  • Q4 2025: Implement comprehensive ARIA live regions for real-time updates
  • Q1 2026: Enhanced keyboard navigation for swipe interface
  • Q1 2026: Dark mode with WCAG AA color contrast
  • Q2 2026: Third-party accessibility audit and remediation
  • Q2 2026: User testing with disability communities
  • Ongoing: Regular WCAG 2.1 compliance monitoring

7. How We Test Accessibility

We use multiple approaches to assess and ensure accessibility:

7.1 Automated Testing

  • WAVE (Web Accessibility Evaluation Tool): Automated accessibility testing
  • Axe DevTools: Browser extension for accessibility testing
  • Lighthouse: Google's automated auditing tool
  • Pa11y: Automated accessibility testing in CI/CD pipeline

7.2 Manual Testing

  • Keyboard navigation: Testing all functionality without a mouse
  • Screen reader testing: Using NVDA, JAWS, VoiceOver, and TalkBack
  • Color contrast verification: Manual checks with contrast analyzers
  • Zoom testing: Testing at 200% zoom and with screen magnifiers
  • Mobile accessibility: Testing with mobile screen readers and assistive features

7.3 User Testing

  • Testing with users who have disabilities
  • Feedback from accessibility community
  • Beta testing with assistive technology users
  • Ongoing feedback collection through accessibility@networkli.co

7.4 External Evaluation

We plan to engage third-party accessibility experts for comprehensive audits:

  • Next audit scheduled: Q2 2026
  • Scope: Full WCAG 2.1 Level AA audit
  • Methodology: Automated testing + manual testing + assistive technology testing

8. Accessibility Feedback

We welcome your feedback on the accessibility of Networkli. Your input helps us improve the experience for all users.

8.1 How to Report Accessibility Issues

If you encounter an accessibility barrier on Networkli, please let us know:

Contact Information

Email (Preferred):

accessibility@networkli.co

We respond to all accessibility inquiries within 3 business days

General Support:

support@networkli.co

Mailing Address:

Networkli Accessibility Team
[Your Address]
[City, State ZIP]

8.2 What to Include in Your Report

To help us address your concern quickly, please include:

  • Your contact information: So we can follow up with you
  • Description of the issue: What happened and what you expected
  • Page or feature: Where you encountered the issue (URL if possible)
  • Assistive technology: Screen reader, browser, OS version you were using
  • Steps to reproduce: How to experience the issue
  • Screenshots or recordings: If possible, visual documentation helps

8.3 Our Response Process

  • Acknowledgment: We'll confirm receipt of your report within 2 business days
  • Assessment: We'll evaluate the issue and determine severity
  • Action plan: We'll provide an estimated timeline for resolution
  • Resolution: We'll notify you when the issue is fixed
  • Follow-up: We may reach out for additional testing or feedback

8.4 Priority Levels

PriorityDescriptionTarget Resolution
CriticalPrevents access to core functionality7 days
HighSignificantly impairs user experience30 days
MediumMinor barrier with workaround available90 days
LowEnhancement or minor inconvenienceNext major release

Additional Accessibility Resources

Learn more about web accessibility:

Last Updated: October 12, 2025 | Version: 2.0

This accessibility statement was created using best practices from W3C WAI and reviewed for WCAG 2.1 Level AA compliance.

Privacy Policy | Terms of Service | Cookie Policy | Return Home