Our commitment to WCAG 2.1 Level AA: what is implemented today, the roadmap, known limitations, and how to request an accommodation or report a barrier.

Tuteliq is committed to providing an accessible and inclusive experience for all users, including people with disabilities. We believe digital services should be usable by everyone, regardless of ability.

Last updated: August 5, 2026 · Effective date: August 5, 2026 · Standard: WCAG 2.1 Level AA

1. Commitment to Accessibility

Tuteliq is committed to providing an accessible and inclusive experience for all users, including people with disabilities.

  • Build accessible products and services
  • Continuously improve accessibility
  • Work toward WCAG 2.1 Level AA standards
  • Provide accessible alternatives for features where gaps remain
  • Respond to accessibility concerns promptly
  • Seek to include people with disabilities in design decisions

2. Accessibility Standards and Compliance

2.1 Web Content Accessibility Guidelines (WCAG)

Standard followed: WCAG 2.1 Level AA (published June 2018). We adopted this standard in January 2023, transitioning from WCAG 2.0 Level A. Our current status is partially conformant / substantially compliant with WCAG 2.1 Level AA, not fully compliant. We are targeting further progress toward full Level AA conformance by December 2026.

Principle

Definition

Perceivable

Information and interface components must be perceivable by users

Operable

Interface and navigation must be operable using keyboard and other input

Understandable

Information and instructions must be clear and understandable

Robust

Content must work with assistive technologies

2.2 Other Accessibility Standards

We also reference:

  • Section 508 (Rehabilitation Act), US Federal accessibility requirement
  • ADA (Americans with Disabilities Act)
  • ATAG 2.0 (Authoring Tool Accessibility Guidelines) for our content creation tools
  • EN 301 549 (European accessibility standard)

2.3 Accessibility Assessment

This statement reflects an internal self-assessment; it is not an independent certification. We have not yet completed a third-party accessibility audit. Our planned assessment approach includes:

  • An independent third-party accessibility audit (planned, not yet completed)
  • Automated scanning with tools such as WAVE and AXE (planned rollout toward regular, frequent scans)
  • Manual accessibility testing by trained staff (ongoing)
  • User testing with people with disabilities (planned)

No full audit has been completed to date. We aim to complete our first full, independent audit and will publish the results here once available.

3. Accessible Website Features

3.1 Visual Accessibility

  • Text contrast ratio target of 4.5:1 (normal text) / 3:1 (large text)
  • Color is not used as the sole means of conveying information
  • High contrast theme available
  • Adjustable text size and browser zoom support
  • Clean, uncluttered, consistent layout and navigation
  • Visible focus indicators on interactive elements
  • Animated content can be paused; no flashing content

3.2 Keyboard Navigation

  • All functionality is designed to be reachable via keyboard
  • No keyboard traps: focus can move freely
  • Logical, predictable tab order
  • "Skip to main content" link available on focus

Key

Function

Tab

Move to next interactive element

Shift + Tab

Move to previous interactive element

Enter / Space

Activate buttons and links

Esc

Close modals and menus

Arrow keys

Navigate within menus and lists

3.3 Screen Reader Support

  • Tested informally with common screen readers, including NVDA and VoiceOver
  • Semantic HTML used throughout, with landmark regions (main, nav, footer)
  • ARIA labels applied to icon-only buttons and controls
  • Form labels associated with their inputs
  • Alternative text provided for meaningful images
  • Proper heading hierarchy (h1 > h2 > h3, not skipped)

3.4 Audio and Video Accessibility

Where we publish video or audio content, we aim to provide captions, transcripts, and keyboard-accessible player controls, and auto-play is disabled by default. Coverage across all existing media is still being completed.

3.5 Content Accessibility

  • Plain language, with jargon minimized or explained
  • Short paragraphs and use of lists for clarity
  • Meaningful link text rather than "click here"
  • Clear, helpful error messages

4. API and Developer Accessibility

The Tuteliq API is a standard JSON HTTP interface with no visual dependency, so it can be integrated by any assistive-technology-friendly client.

  • API documentation aims to meet WCAG Level AA standards
  • Code examples formatted for readability with screen readers
  • Parameter tables use proper header markup
  • Alternative formats (such as plain text) available on request

If you need documentation in a different format, email us and we will produce it.

5. Mobile Accessibility

We aim to support assistive technologies on mobile platforms, including VoiceOver on iOS/macOS and TalkBack on Android, and to provide touch targets of at least 48x48 density-independent pixels with adequate spacing. Support for Switch Control, Voice Control, and similar system-level accessibility features is an ongoing area of testing and improvement rather than a fully verified guarantee today.

6. Known Accessibility Issues

6.1 Current Limitations

We would rather be honest than claim full conformance. We are working to address the following:

Issue

Status

Expected Fix

Some third-party map displays

Being addressed

Planned

Historical data reports

In progress

Legacy API documentation

Some dashboard charts

Being evaluated

6.2 Workarounds Available

If you encounter accessibility barriers:

  • Maps: a text-based location search and address entry are available as alternatives
  • Charts: data is available in table format, CSV export, and via the API for custom accessible visualization
  • Other issues: contact the accessibility team for an alternative format or method and an expected resolution timeline

7. Accessibility Features for Specific Disabilities

Blindness and low vision

  • Screen reader compatible pages (NVDA, VoiceOver, and similar tools)
  • Keyboard-only navigation
  • High contrast theme and adjustable text size
  • Information not conveyed by color alone
  • Clear focus indicators

Deafness and hard of hearing

  • Captions provided for video content where available
  • Transcripts provided for audio content where available
  • No audio-only notifications
  • Text-based communication channels available

Mobility impairments

  • Full keyboard navigation
  • No functionality that requires hover-only interaction
  • Adequate spacing between interactive targets

Cognitive and neurological disabilities

  • Simple, clear language and consistent navigation
  • Minimal distractions and ample white space
  • Predictable interface behavior
  • Help and support readily available

Color blindness

  • Color is never the sole means of conveying information
  • Icons, patterns, and text labels used alongside color
  • High contrast color combinations

8. Accessibility Commitment and Roadmap

8.1 Current Initiatives (2026)

In progress:

  • Dashboard accessibility review
  • Adding captions to training materials
  • Working toward WCAG Level AA compliance in API documentation

Planned:

  • Mobile app accessibility improvements
  • Legacy data portal upgrade
  • Staff accessibility training

8.2 2026–2027 Roadmap

  • WCAG 2.1 Level AA conformance across all products
  • Regular accessibility audits, including an independent third-party audit
  • User testing with people with disabilities
  • An accessibility checklist applied to all new features
  • Expanded assistive technology testing

8.3 Planned Accessibility Testing Cadence

The cadence below reflects our target operating model; we are still building up to it and not all items are fully in place today.

Testing Type

Target Frequency

Automated scanning (e.g. AXE, WAVE)

Planned, moving toward routine cadence

Manual testing

Ongoing as features ship

Screen reader spot checks

Periodic

Independent third-party audit

Not yet performed; planned

9. Request Accommodation Process

9.1 Requesting Accessibility Features

  • Email accessibility@tuteliq.ai with subject "Accessibility Request: [brief description]", including your needs, current barriers, and any suggested solutions.
  • We acknowledge within 2 business days and complete an assessment within 5 business days.
  • Where possible, a solution is provided within 15 days.

Support options may include technical accommodations, alternative formats, extended timelines, and one-on-one support.

9.2 Reporting Accessibility Barriers

Email accessibility@tuteliq.ai with the page or feature affected, what you tried, a description of the barrier, and screenshots if helpful. We acknowledge within 24 hours, investigate, offer a workaround where possible, and provide a timeline for a permanent fix with updates as work progresses.

10. Staff Accessibility Training

We are building accessibility training into our organization, covering accessibility awareness and disability etiquette for all staff, WCAG fundamentals and assistive technology testing for developers, accessible design principles for product and design teams, and communicating with users with disabilities for customer support.

11. Third-Party Accessibility

11.1 Vendor Accessibility Requirements

We expect third-party services we rely on to provide accessible interfaces, support standard assistive technologies, provide accessibility documentation, respond to accessibility issues, and commit to ongoing accessibility improvements.

11.2 Sub-Processor Accessibility

Third-party embedded components, such as payment checkout and messaging widgets, follow the accessibility posture of their vendor. We monitor and report issues upstream as we become aware of them.

12. Accessibility and Legal Compliance

12.1 Regulatory Framework We Consider

ADA (Americans with Disabilities Act), Section 508, ATAG 2.0, EN 301 549, AODA (Accessibility for Ontarians with Disabilities Act), and Sweden's Accessibility Act.

12.2 Tuteliq's Compliance Status

Regulation

Scope

ADA Title III

Ongoing effort

Website and services

Section 508

If used by US government

AODA

If serving Canadian users

WCAG 2.1 AA

All web content

EN 301 549 / European Accessibility Act

EU services

13. Contact and Support

13.1 Accessibility Questions and Support

Email accessibility@tuteliq.ai (response within 2 business days; English, with other languages available on request). For urgent issues, include "URGENT" in the subject line for a response within 24 hours.

13.2 Complaints and Feedback

Please report barriers to us first at accessibility@tuteliq.ai and allow 30 days for a response and remedy. If unresolved, US users may contact the Department of Justice, Civil Rights Division; EU users may contact the relevant national accessibility authority; Canadian users may contact their provincial accessibility authority.

13.3 Request for Alternative Formats

We can provide documents in:

  • Large print (16pt or larger)
  • Digital text suitable for screen readers
  • Accessible PDF
  • Word document (for adjustment)
  • Plain language summary
  • Audio format, on request

Email accessibility@tuteliq.ai specifying the format needed and any deadline. We aim to respond within 10 business days, at no cost. Braille, ASL interpretation, and other specialized formats can be arranged with advance notice where feasible.

14. Glossary

  • Accessibility: extent to which people with disabilities can use a product or service
  • ADA: Americans with Disabilities Act (US law)
  • ARIA: Accessible Rich Internet Applications (web standard)
  • Assistive technology: software or hardware helping people with disabilities
  • Captions: text of audio content for deaf or hard of hearing users
  • Focus indicator: visual mark showing which element is selected during keyboard navigation
  • Keyboard navigation: using Tab and arrow keys to navigate without a mouse
  • NVDA: free screen reader software
  • Screen reader: software that reads page content aloud
  • Semantic HTML: HTML that describes content meaning
  • Skip link: link allowing users to skip navigation
  • TalkBack: Android screen reader
  • VoiceOver: Apple screen reader (iOS/macOS)
  • WCAG: Web Content Accessibility Guidelines

15. Policy Updates

We will update this policy when accessibility standards change, when we implement new accessibility features, when we identify new barriers, and at minimum annually. Material changes are posted with an effective date and clearly marked as updated.

Related: Privacy Policy · Terms of Service · Security · All legal documents · Contact us

Document version 2.0 · Last updated August 5, 2026 · Next review August 5, 2027 · For accessibility support or feedback, email accessibility@tuteliq.ai (response time: 2 business days)

Get Started Free · Read Documentation · View Pricing