Effective Date: 23-Jan-2023
Last Updated: 16-Jan-2025
Plain-language summary: Tech Fleet is committed to digital accessibility for people with disabilities, seniors, and anyone who relies on assistive technology. We design, build, test, and maintain techfleet.network to meet or exceed WCAG 2.1 AA today and WCAG 2.2 AA / WCAG 3.0 “Silver” as those standards mature. This policy explains our standards, what we do, your legal rights in your country, and how to ask for help or file a complaint.
1. Commitment Statement
Tech Fleet, a Delaware nonprofit corporation (“Tech Fleet,” “we,” “us,” or “our”) is committed to ensuring digital accessibility for people with disabilities and seniors across every country we operate in. We are continually improving the user experience for everyone by adhering to the current and upcoming versions of the Web Content Accessibility Guidelines (WCAG) published by the W3C Web Accessibility Initiative.
Accessibility is a civil right. Our nonprofit mission — training the next generation of tech professionals — cannot succeed unless every learner, volunteer, mentor, client, and visitor can use this Platform on equal terms, regardless of disability, age, device, network, or assistive technology.
2. Scope
This policy applies to:
All web content, applications, learning materials, emails, PDFs, videos, audio recordings, presentations, and downloadable documents we publish on or through techfleet.network.
Mobile and responsive views of the Platform on phones, tablets, laptops, and large displays.
Internal tools used by Tech Fleet staff, mentors, and volunteers when those tools are part of the program experience.
Procurement: any third-party software, vendor, or service we adopt going forward must meet our accessibility requirements (see Section 9).
Some legacy third-party content embedded from external sites (for example, partner videos, donor portals, or external recordings) may not yet meet our standard. We mark those known limitations in Section 12 and work continuously to remediate or replace them.
3. Standards We Conform To
We design, build, and audit the Platform against the following technical standards. Where standards differ, we apply the strictest requirement.
W3C Web Content Accessibility Guidelines (WCAG) 2.1 Level AA — baseline conformance target.
W3C WCAG 2.2 Level AA — we meet all 2.2 success criteria, including 2.4.11 Focus Not Obscured (Minimum), 2.5.7 Dragging Movements, 2.5.8 Target Size (Minimum), 3.2.6 Consistent Help, 3.3.7 Redundant Entry, and 3.3.8 Accessible Authentication (Minimum).
W3C WCAG 3.0 “Silver” — we track the working draft and adopt outcome-based testing (e.g., Bronze/Silver/Gold ratings) where it improves on 2.x.
W3C WAI-ARIA 1.2 Authoring Practices for custom interactive components.
EN 301 549 v3.2.1 — the harmonised European standard for ICT accessibility, which incorporates WCAG 2.1 AA and additional requirements for documents, software, hardware, and support services.
U.S. Section 508 of the Rehabilitation Act, as updated by the 2018 ICT Refresh, which incorporates WCAG 2.0 AA at minimum (we meet 2.1 AA).
ISO/IEC 40500:2012 (international adoption of WCAG 2.0).
ISO/IEC 30071-1:2019 — development of user interfaces that are accessible to people with disabilities.
CAN/ASC EN 301 549:2024 (Canada’s adoption of EN 301 549).
Web accessibility recommendations issued by national authorities in jurisdictions where we operate, where they exceed WCAG.
4. Legal Framework We Comply With
This policy is designed to meet or exceed accessibility obligations everywhere on Earth where users can reach the Platform. The list below is illustrative, not exhaustive; we monitor changes and update this policy as laws evolve.
4.1 North America
United States — Americans with Disabilities Act (ADA) Titles II and III, including DOJ guidance treating commercial websites as places of public accommodation; Section 504 of the Rehabilitation Act; Section 508 of the Rehabilitation Act; the 21st Century Communications and Video Accessibility Act (CVAA); the Air Carrier Access Act for any travel-adjacent content; California Unruh Civil Rights Act; New York State and New York City Human Rights Laws; Colorado HB21-1110; Minnesota State accessibility standards.
Canada — Accessible Canada Act (ACA, 2019) and its regulations; Accessibility for Ontarians with Disabilities Act (AODA), including the Integrated Accessibility Standards Regulation (IASR) and WCAG 2.0 AA web standard; Accessibility for Manitobans Act; Nova Scotia Accessibility Act; Quebec’s Standard sur l’accessibilité du Web (SGQRI 008); British Columbia Accessible BC Act.
Mexico — Ley General para la Inclusión de las Personas con Discapacidad and NOM-008-SSA3 where applicable.
4.2 European Union, EEA, and United Kingdom
European Accessibility Act (Directive (EU) 2019/882), enforceable from 28 June 2025, covering e-commerce, e-books, banking, transport, and consumer ICT services.
Web Accessibility Directive (Directive (EU) 2016/2102) for public-sector bodies, applying EN 301 549.
EU Charter of Fundamental Rights (Article 21 — non-discrimination; Article 26 — integration of persons with disabilities).
United Kingdom Equality Act 2010 (including the duty to make reasonable adjustments) and the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018.
Ireland Disability Act 2005 and Equal Status Acts.
Germany BITV 2.0 and Behindertengleichstellungsgesetz (BGG); Barrierefreiheitsstärkungsgesetz (BFSG, in force June 2025).
France Loi n° 2005-102 and RGAA 4.1.
Italy Stanca Act (Law 4/2004) and AgID guidelines.
Spain Royal Decree 1112/2018.
Netherlands Tijdelijk besluit digitale toegankelijkheid overheid.
Nordic accessibility laws in Denmark, Sweden, Norway, Finland, and Iceland implementing EU directives.
Switzerland Federal Act on the Elimination of Discrimination against People with Disabilities (BehiG) and P028 web accessibility standard.
4.3 Latin America and the Caribbean
Brazil Lei Brasileira de Inclusão (Law 13.146/2015) and ABNT NBR 17225 / e-MAG accessibility model.
Argentina Ley 26.653 — Acceso de la Información Pública.
Chile Ley 20.422 and Decreto Supremo 1/2015.
Colombia Ley 1618/2013 and NTC 5854.
Mexico, Peru, Uruguay, Costa Rica, Panama, and Ecuador laws implementing the UN CRPD.
4.4 United Nations and International
UN Convention on the Rights of Persons with Disabilities (CRPD), Articles 9 (Accessibility) and 21 (Freedom of expression and access to information).
UN Sustainable Development Goals 4, 10, and 11 — inclusive education, reduced inequality, and inclusive cities.
Marrakesh Treaty for accessible-format works.
4.5 Asia-Pacific
Australia Disability Discrimination Act 1992 and Disability (Access to Premises – Buildings) Standards; Australian Government Digital Service Standard requiring WCAG 2.1 AA.
New Zealand Human Rights Act 1993 and NZ Government Web Accessibility Standard 1.1.
Japan JIS X 8341-3:2016, aligned with WCAG 2.0.
South Korea Act on Welfare of Persons with Disabilities and KS X OT0003.
China GB/T 37668-2019 and the Law on the Protection of Persons with Disabilities.
India Rights of Persons with Disabilities Act 2016 and GIGW 3.0 / IS 17802.
Singapore Enabling Masterplan and IMDA accessibility guidelines.
Hong Kong Disability Discrimination Ordinance and OGCIO web accessibility recognition scheme.
Taiwan Web Accessibility Guidelines 2.0.
Thailand, Malaysia, Indonesia, Philippines, Vietnam laws implementing the UN CRPD.
4.6 Middle East and Africa
Israel Equal Rights for Persons with Disabilities Law and IS 5568 (WCAG 2.0 AA).
United Arab Emirates Federal Law No. 29 of 2006 and TDRA Web Accessibility Policy v2.
Saudi Arabia Digital Government Authority accessibility standards.
South Africa Promotion of Equality and Prevention of Unfair Discrimination Act and SANS standards.
Kenya, Nigeria, Ghana, Egypt, Morocco — national disability and ICT laws aligned with the UN CRPD.
5. What “Accessibility” Means Here
Accessibility means designing the Platform so that people of all abilities — including people who are blind, have low vision, are color-blind, are Deaf or hard of hearing, are deaf-blind, have motor or dexterity differences, have cognitive, learning, or neurodivergent profiles (such as autism, ADHD, dyslexia, dyscalculia), or have temporary or situational impairments — can perceive, understand, navigate, contribute to, and complete every meaningful task. We also account for older adults and users on slow networks, small screens, or low-end devices.
6. Conformance Approach (POUR)
6.1 Perceivable
Text alternatives (alt text) for all non-decorative images, charts, and icons.
Captions for all pre-recorded video; live captions for live events; audio descriptions for video where meaning depends on visuals; transcripts for podcasts and audio-only content.
Sufficient color contrast (≥4.5:1 for body text, ≥3:1 for large text and UI components and graphical objects), independently verified by automated and manual checks.
Information is never conveyed by color alone; we pair color with text, icons, or patterns.
Content reflows on screens as narrow as 320 CSS pixels without horizontal scrolling and supports user-controlled text spacing per WCAG 1.4.12.
No autoplaying audio; media has accessible controls.
6.2 Operable
Full keyboard support — every interactive element is reachable and usable with Tab/Shift+Tab/Enter/Space/Arrow keys with a visible focus ring, no keyboard traps, and no positive tabindex values.
Skip-to-content links and consistent landmark structure (header, nav, main, footer, complementary).
Touch targets are at least 24×24 CSS pixels (WCAG 2.2 Minimum) and we aim for 44×44 (WCAG 2.5.5 Enhanced) on primary controls.
Sessions warn before time-out and let users extend, save, or restart per WCAG 2.2.1; we do not silently log users out and lose their work.
No content flashes more than three times per second.
Animation, parallax, and motion respect prefers-reduced-motion at the OS level.
Drag operations have a single-pointer alternative (WCAG 2.5.7).
6.3 Understandable
Plain-language content at roughly a 9th-grade reading level wherever feasible; jargon is defined or linked.
HTML lang attribute is set on every page; mid-content language switches are marked.
Form labels, instructions, and error messages are programmatically associated with the right field, are descriptive, and suggest a fix.
Consistent navigation, consistent component naming, and a consistent help mechanism (Fleety chatbot + email contact + this policy) on every page (WCAG 3.2.6).
Forms do not re-ask for information we already have on file (WCAG 3.3.7).
Authentication never depends on a cognitive function test that has no alternative; password managers, copy/paste, and TOTP via a standard authenticator app are supported (WCAG 3.3.8).
6.4 Robust
Semantic HTML5 with valid ARIA roles, states, and properties only when native elements are insufficient.
Live regions announce status messages (loading, success, error) without forcing focus changes (WCAG 4.1.3).
Compatibility with current and recent versions of NVDA, JAWS, VoiceOver (macOS and iOS), TalkBack, Narrator, and Dragon NaturallySpeaking on supported browsers (current and prior major version of Chrome, Edge, Firefox, and Safari).
Progressive enhancement — the Platform remains usable when JavaScript is partially blocked or slow to load.
7. Platform Features That Back This Up
This policy is enforced by code, not just by intent. The Platform ships the following accessibility features today:
Skip links and a single semantic <main> landmark on every route.
Visible 2-px focus ring on every interactive element, never removed by stylesheets.
Light and dark themes that both meet WCAG 1.4.3 and 1.4.11 contrast requirements; the user’s OS preference is respected by default and a manual toggle is always available.
Reduced-motion support — animations, transitions, and parallax are removed or replaced with instant transitions when prefers-reduced-motion: reduce is set.
Resizable text to 200% without loss of content or function; layouts reflow on screens ≥320 CSS pixels.
ARIA live regions for toast notifications, form errors, and asynchronous loading states.
All form fields have programmatic labels, descriptions for complex inputs, and inline error messages with suggestions.
Idle session warnings 30 minutes after the last interaction with a one-click extend option.
TOTP-based two-factor authentication compatible with Google Authenticator, 1Password, Bitwarden, and other standard authenticators — no SMS-only or biometric-only paths that could exclude users.
Keyboard shortcuts include a modifier or can be disabled, per WCAG 2.1.4.
All third-party embeds (videos, recordings, knowledge base) are tested for accessibility before launch and remediated or replaced if they fail.
A continuous accessibility test suite runs in CI on every pull request, including axe-core checks and a custom WCAG 2.1 AA + 2.2 AA checklist (see e2e/a11y/) covering all Level A and AA success criteria.
Lighthouse and Web Vitals (LCP, INP, CLS) budgets are enforced so the Platform stays usable on low-bandwidth and low-power devices.
Behavior-driven (BDD) accessibility scenarios are stored in the database and gate releases.
8. Testing and Auditing
We combine automated, manual, and lived-experience testing:
Automated — axe-core, Lighthouse, Pa11y, ESLint jsx-a11y, and color-contrast linters run in CI on every change.
Manual — keyboard-only walkthroughs of every release; screen-reader walkthroughs with NVDA, JAWS, VoiceOver, and TalkBack at least quarterly; mobile and zoom testing on iOS and Android.
Independent audits — a third-party accessibility audit is commissioned at least annually and after any major redesign; results inform a public remediation plan.
User testing — we recruit testers with disabilities for usability sessions on major new features.
Document accessibility — PDFs are tagged, have a logical reading order, language metadata, and bookmarks; DOCX files use real heading styles, alt text, and table headers; presentations follow accessible-slide guidance.
9. Procurement and Vendor Accountability
Before adopting a new tool, plug-in, or service we:
Request an Accessibility Conformance Report (ACR) using the Voluntary Product Accessibility Template (VPAT 2.5) covering WCAG 2.1 AA, Section 508, and EN 301 549.
Test the tool with keyboard-only navigation and at least one screen reader.
Document any gaps and either require remediation in the contract, supply an accessible alternative path inside the Platform, or do not adopt the tool.
Re-evaluate vendors annually.
10. Training and Culture
Every engineer, designer, content writer, and program manager at Tech Fleet completes accessibility onboarding within 30 days of joining and refresher training annually. Training covers WCAG 2.1/2.2/3.0, ARIA Authoring Practices, inclusive language, disability etiquette, and how to test with assistive technology. Accessibility is a release-blocking criterion in code review, design review, and content review.
11. Reasonable Accommodations
If you need a reasonable accommodation to apply for, participate in, or complete any Tech Fleet program — for example, extended time on a quiz, an alternative format for a document, a different communication channel, captioning for a live event that does not yet have it, or assistive equipment loan — contact info@techfleet.network. We will work with you in good faith and at no cost to you, in line with the ADA, the UK Equality Act 2010, the EU Accessibility Act, the UN CRPD, and any other applicable law in your country. We will not refuse an accommodation unless granting it would impose an undue hardship as defined by your local law, and even then we will offer the closest available alternative.
12. Known Limitations
We are transparent about gaps and we keep this list current.
A small number of legacy training videos do not yet have audio descriptions; transcripts and captions are available, and we are remediating on a published schedule.
Some third-party embeds (for example, donor portals or partner recordings) may not fully meet WCAG 2.1 AA. We provide accessible alternatives or contact info on request.
Beta features may be released for limited testing before final accessibility verification; they are clearly labeled “beta” and excluded from required workflows.
If you find a barrier that is not on this list, please tell us using Section 13. We treat accessibility defects as priority bugs.
13. Feedback, Complaints, and Enforcement
We welcome your feedback. To report an accessibility barrier, request an alternative format, or ask a question:
Email: info@techfleet.org
Mailing address: Tech Fleet, Accessibility Office, 8 The Grn, Suite 6369, Dover, Delaware 19901, USA.
In your message, please tell us: the page or feature involved (with a URL if possible), the barrier you experienced, the assistive technology, browser, and operating system you were using, and the best way to reach you.
We will acknowledge your message within 2 business days and provide a substantive response within 10 business days. If we cannot fix the issue immediately, we will give you a target date and an interim alternative way to complete your task.
If you are not satisfied with our response, you may escalate to:
United States — the U.S. Department of Justice (ADA.gov), the U.S. Access Board, or your State Attorney General.
European Union / EEA — the national enforcement body designated under the European Accessibility Act in your country.
United Kingdom — the Equality and Human Rights Commission (EHRC).
Canada — the Accessibility Commissioner under the Accessible Canada Act, or your provincial body (e.g., Ontario AODA Office).
Australia — the Australian Human Rights Commission.
Other jurisdictions — your national disability rights authority or ombudsperson.
We will not retaliate against anyone who files an accessibility complaint in good faith.
14. Governance and Accountability
Tech Fleet’s Executive Director is the executive sponsor for accessibility. The Director of Engineering is the responsible owner. The Accessibility Working Group meets at least monthly, reviews audit results, prioritises remediation, and reports to the Board of Directors at least quarterly. This policy is reviewed at least annually and whenever a referenced standard or law changes materially.
15. Continuous Improvement
Accessibility is never “done.” We commit to:
Publishing an updated Accessibility Statement at least once per year, including audit results and a remediation roadmap.
Tracking accessibility defects in the same backlog as security and reliability defects, with the same severity scale.
Sharing what we learn with the wider nonprofit and EdTech community.