Back to policies

Legal and trust

Accessibility Statement

Version 1.0 · Effective 17 August 2026

Published 26 August 2026

HealthLynk stores and organises information; it does not diagnose, prescribe, provide medical treatment or replace professional medical advice.

HealthLynk Accessibility Statement

Version: 1.0 Effective date: 17 August 2026 Last updated: 17 August 2026

HealthLynk (Pty) Ltd is committed to making the HealthLynk platform accessible and usable by as many people as reasonably possible, including people with disabilities.

We recognise that access to personal health information is important and that a digital health-information service should not unnecessarily exclude people because of the technology, device or assistive technology they use.

This Accessibility Statement explains HealthLynk's accessibility goals, current approach, known limitations, reporting process and commitment to ongoing improvement.

1. About HealthLynk

HealthLynk is operated by:

Legal name: HealthLynk (Pty) Ltd Registration number: 2026/646559/07 Country of registration: Republic of South Africa Director: Yanga Sodoza Website: healthylynk.com Telephone: 074 663 3106 Email: YangaSodoza@outlook.com Business address: 131 Eoan Ave, Eden Heights, Scottsdene, Kraaifontein, Cape Town, Western Cape, South Africa, 7570

HealthLynk provides a digital platform that allows individuals and families to organise, store, manage, access and share health-related information and documents.

2. Our Accessibility Commitment

HealthLynk aims to provide a digital experience that can be used by people with a wide range of abilities and access needs.

Our accessibility work considers people who may have:

  • visual disabilities;
  • hearing disabilities;
  • physical or motor disabilities;
  • speech disabilities;
  • cognitive disabilities;
  • learning disabilities;
  • neurological disabilities;
  • temporary impairments;
  • age-related access requirements;
  • limited dexterity;
  • limited vision;
  • or combinations of different access needs.

Accessibility is treated as an ongoing part of product quality rather than a one-time compliance exercise.

3. Accessibility Standard

HealthLynk's target is to design and develop its public website and core application functionality with reference to:

Web Content Accessibility Guidelines (WCAG) 2.2, Level AA.

WCAG provides principles, guidelines and success criteria intended to improve accessibility for people with disabilities.

HealthLynk does not currently claim complete WCAG 2.2 Level AA conformance.

A formal accessibility assessment of the production Service will be performed as part of HealthLynk's pre-launch and ongoing quality review.

Any conformance claim will only be made after appropriate evaluation supports that claim.

4. The Four Accessibility Principles

HealthLynk aims to design digital content according to the four broad WCAG principles.

4.1 Perceivable

Information should be presented in ways that users can perceive.

This includes considering:

  • text alternatives;
  • readable content;
  • sufficient visual contrast;
  • meaningful structure;
  • scalable text;
  • content that does not depend solely on colour;
  • and alternatives for non-text information where appropriate.

4.2 Operable

Users should be able to operate HealthLynk through different input methods.

This includes considering:

  • keyboard accessibility;
  • logical focus order;
  • visible keyboard focus;
  • appropriately sized interactive controls;
  • sufficient time to perform actions;
  • accessible navigation;
  • and avoidance of interactions that unnecessarily depend on precise pointer movement.

4.3 Understandable

HealthLynk should be reasonably easy to understand.

This includes considering:

  • clear language;
  • consistent navigation;
  • predictable interaction;
  • meaningful field labels;
  • useful validation messages;
  • clear instructions;
  • understandable subscription information;
  • and support for correcting user errors.

4.4 Robust

HealthLynk should work reasonably well across supported browsers, devices and assistive technologies.

This includes using appropriate:

  • HTML structure;
  • semantic elements;
  • form relationships;
  • labels;
  • accessibility attributes;
  • headings;
  • link descriptions;
  • and application states.

5. Keyboard Accessibility

HealthLynk aims to ensure that core functionality can be used without requiring a mouse or touch screen.

Core tasks should be operable using a keyboard where technically applicable.

This includes actions such as:

  • navigating pages;
  • moving between controls;
  • opening relevant menus;
  • completing forms;
  • selecting actions;
  • submitting information;
  • accessing account settings;
  • and using important application functionality.

Keyboard focus should remain visible and should move through controls in a logical order.

HealthLynk should not intentionally create keyboard traps that prevent a user from navigating away from a control or interface region.

6. Screen Reader Support

HealthLynk aims to use semantic web structures so that supported assistive technologies can interpret the interface.

This includes appropriate use of:

  • headings;
  • landmarks;
  • buttons;
  • links;
  • form labels;
  • input descriptions;
  • error messages;
  • tables;
  • lists;
  • accessible names;
  • and status messages.

Visual styling should not replace the semantic meaning required by assistive technology.

For example, an element that functions as a button should normally be implemented in a way that assistive technology can recognise as an interactive control.

7. Forms

HealthLynk contains forms used for activities that may include:

  • registration;
  • verification;
  • adding health records;
  • creating profiles;
  • uploading documents;
  • managing subscriptions;
  • profile invitations;
  • contact requests;
  • and other account activities.

HealthLynk aims to ensure that forms provide:

  • visible labels;
  • programmatically associated labels;
  • useful instructions;
  • understandable validation;
  • identification of required information;
  • meaningful error messages;
  • and an appropriate opportunity to correct errors.

Where health or payment-related information is involved, users should have a reasonable opportunity to review important information before confirming the relevant action.

8. Error Messages

Error messages should help users understand:

  1. what went wrong;
  2. where the problem occurred; and
  3. where reasonably possible, how the problem can be corrected.

HealthLynk aims to avoid relying only on:

  • red colouring;
  • icons without explanation;
  • visual position;
  • or other purely visual indicators

to communicate an error.

Errors should be understandable to users of assistive technologies where reasonably possible.

9. Colour and Contrast

HealthLynk aims to provide sufficient contrast between important foreground and background content.

Colour should not ordinarily be the only method used to communicate important information.

For example, a validation error should not be indicated solely by changing a field border to red.

Where colour communicates meaning, an additional indicator such as:

  • text;
  • an icon with an accessible label;
  • a pattern;
  • or another meaningful cue

should be provided where appropriate.

10. Text Resizing and Responsive Layout

HealthLynk is designed to support different screen sizes and devices.

The interface should reasonably accommodate:

  • text enlargement;
  • browser zoom;
  • mobile displays;
  • tablet displays;
  • desktop displays;
  • and different device orientations.

Important information should not become unusable merely because a user increases text size or zooms the page within reasonable supported limits.

Horizontal scrolling should be avoided for ordinary text content where reasonably possible.

11. Mobile Accessibility

HealthLynk is intended to work across mobile and desktop environments.

Mobile accessibility considerations include:

  • appropriately sized touch targets;
  • sufficient spacing between controls;
  • avoiding unnecessarily precise gestures;
  • usable form controls;
  • readable text;
  • sensible content order;
  • and compatibility with mobile assistive technologies where reasonably possible.

Core functionality should not depend on a gesture that has no reasonable alternative where accessibility requires one.

12. Progressive Web Application

HealthLynk may operate as a Progressive Web Application.

Accessibility considerations therefore apply not only to the public website but also to the installed or app-like HealthLynk experience.

PWA functionality should aim to preserve:

  • semantic structure;
  • keyboard accessibility;
  • focus management;
  • screen-reader compatibility;
  • readable status information;
  • and accessible navigation.

Offline or limited-connectivity states should communicate their status clearly rather than relying solely on subtle visual changes.

13. Navigation

HealthLynk aims to make navigation predictable and understandable.

This may include:

  • logical heading structures;
  • meaningful page titles;
  • descriptive navigation links;
  • consistent placement of major navigation;
  • understandable breadcrumbs where appropriate;
  • skip-navigation mechanisms where useful;
  • and clear identification of the user's current location or context.

Links should use meaningful text where reasonably possible rather than ambiguous wording such as "click here" without context.

14. Focus Management

Interactive application interfaces may dynamically open:

  • dialogs;
  • menus;
  • confirmation windows;
  • file viewers;
  • alerts;
  • or other interface components.

Where this occurs, HealthLynk aims to manage keyboard focus appropriately.

For example:

  • focus should move appropriately when an important modal dialog opens;
  • keyboard users should be able to reach the controls inside it;
  • focus should not unexpectedly disappear;
  • and closing the interface should return focus to a sensible location where possible.

15. Uploaded Documents

HealthLynk allows users to upload health-related files.

HealthLynk cannot guarantee that every document uploaded by a user or third party is accessible.

For example, an uploaded:

  • scanned prescription;
  • medical report;
  • laboratory result;
  • photograph;
  • image-only PDF;
  • or healthcare-provider document

may not contain accessible text or structure.

Where HealthLynk generates its own documents, we aim to improve their accessibility over time.

Users who encounter difficulty accessing a HealthLynk-generated document may contact HealthLynk for assistance.

16. HealthLynk-Generated PDFs and Exports

HealthLynk may generate:

  • PDF summaries;
  • health histories;
  • downloadable reports;
  • CSV exports;
  • ZIP archives;
  • or other exported information.

HealthLynk aims to make its own generated documents as usable as reasonably possible.

The production accessibility review will specifically consider generated PDFs and other important output formats.

Where a particular generated format is inaccessible to a user, HealthLynk will consider whether the same information can reasonably be provided in another accessible format.

17. Images and Icons

Meaningful images should have appropriate text alternatives where required.

Decorative images should generally not create unnecessary noise for screen-reader users.

Icons used as controls should have understandable accessible names.

An icon should not require a user to infer an important action solely from its visual appearance where a suitable label can reasonably be provided.

18. Charts and Visualised Information

If HealthLynk introduces charts, visual health timelines or other graphical displays, important information should not be available only through a visual representation.

Where appropriate, HealthLynk should provide:

  • underlying text;
  • accessible labels;
  • structured summaries;
  • tabular information;
  • or another reasonable alternative.

A user's ability to understand their own health information should not unnecessarily depend on distinguishing colours or interpreting an image.

19. Video and Audio

If HealthLynk publishes important video or audio content in future, accessibility requirements will be considered before or during publication.

Depending on the content, this may include:

  • captions;
  • transcripts;
  • audio descriptions;
  • accessible media-player controls;
  • and text alternatives.

HealthLynk does not currently rely on video or audio as the sole means of accessing core personal-health information.

20. Language and Plain Communication

Health-related and legal information can be difficult to understand.

HealthLynk aims to use language that is as clear as reasonably possible while maintaining necessary accuracy.

We aim to avoid unnecessary:

  • technical jargon;
  • medical terminology;
  • legal terminology;
  • complex instructions;
  • and unexplained abbreviations

in ordinary user-facing interfaces.

Where technical or medical terminology is necessary, HealthLynk may provide additional explanations where appropriate.

This does not mean that HealthLynk interprets medical information or provides medical advice.

21. Authentication Accessibility

Account security is important because HealthLynk may contain sensitive health information.

Security measures should nevertheless be designed with accessibility in mind.

HealthLynk will consider accessibility when implementing functionality such as:

  • passwords;
  • one-time verification codes;
  • email verification;
  • multi-factor authentication;
  • CAPTCHA or anti-bot protection;
  • and account recovery.

Security measures should not unnecessarily exclude users with disabilities where a secure accessible alternative can reasonably be provided.

22. CAPTCHA and Anti-Abuse Controls

HealthLynk may use anti-abuse or CAPTCHA technologies to protect forms and accounts.

Where such technologies are used, HealthLynk aims to provide accessible mechanisms or alternatives where reasonably available.

A security mechanism should not intentionally require a user to complete a task that depends exclusively on:

  • sight;
  • hearing;
  • fine motor control;
  • or another ability

where an accessible alternative can reasonably achieve the same security purpose.

23. Time Limits and Session Expiry

Security requirements may require authenticated HealthLynk sessions, invitations, verification codes or other temporary actions to expire.

Where a user-controlled process has a meaningful time limit, HealthLynk will consider whether:

  • the time limit is necessary;
  • advance warning can be provided;
  • additional time can safely be requested;
  • entered information can be preserved;
  • or another reasonable accommodation is possible.

Security-sensitive expiry periods may not always be capable of being disabled.

24. Notifications and Status Messages

Important application events should be communicated in a way that is reasonably accessible.

Examples include:

  • successful record creation;
  • failed uploads;
  • form errors;
  • profile-invitation status;
  • payment results;
  • subscription changes;
  • security notices;
  • and export-generation status.

Where content changes dynamically, HealthLynk should consider whether assistive technologies need to be notified of the change rather than relying solely on a visual update.

25. Payment Accessibility

HealthLynk intends to use PayFast by Network for online payment processing.

Some parts of the payment experience may therefore be controlled by PayFast rather than HealthLynk.

HealthLynk aims to make the HealthLynk-controlled portion of the subscription process accessible, including:

  • plan selection;
  • pricing information;
  • billing frequency;
  • trial information;
  • recurring-payment disclosures;
  • acceptance of applicable policies;
  • and navigation to the payment provider.

Accessibility limitations in a third-party payment environment may be outside HealthLynk's direct technical control.

HealthLynk nevertheless welcomes reports concerning difficulties encountered during the payment journey so that we can investigate and, where appropriate, raise the matter with the relevant provider.

26. Third-Party Services

HealthLynk may rely on third parties for services such as:

  • payment processing;
  • email;
  • infrastructure;
  • embedded functionality;
  • or other external components.

HealthLynk cannot guarantee the accessibility of every external service.

When selecting and integrating significant user-facing third-party technologies, HealthLynk aims to consider accessibility as one of the relevant factors.

Where an inaccessible third-party component creates a significant barrier to HealthLynk functionality, we will consider reasonable alternatives where practicable.

27. Accessibility of Legal and Compliance Information

HealthLynk's important public legal and compliance documents should be made available in accessible web-based formats where reasonably possible.

These include:

  • Terms of Service;
  • Privacy Policy and POPIA Privacy Notice;
  • Refund, Cancellation and Subscription Policy;
  • PAIA Manual;
  • Medical Disclaimer;
  • Cookie Policy;
  • Security and Data Protection Statement;
  • Acceptable Use Policy; and
  • this Accessibility Statement.

Where a downloadable document is also provided, HealthLynk aims to retain an accessible web version where practical.

28. Accessibility and Health Information

Accessibility changes should not weaken HealthLynk's privacy and security protections.

Where an accessibility accommodation involves sensitive health information, HealthLynk will consider:

  • the user's accessibility requirement;
  • the confidentiality of the information;
  • appropriate identity verification;
  • the security of the delivery method;
  • and whether the accommodation can be provided without exposing the information to an unauthorised person.

A disability-related accessibility request will not be treated as permission to disclose private medical information to another person.

29. Alternative Assistance

If a user cannot complete an important HealthLynk process because of an accessibility barrier, HealthLynk will consider reasonable alternative assistance where practicable.

This may include assistance concerning:

  • account access;
  • understanding public information;
  • subscription cancellation;
  • refund requests;
  • privacy requests;
  • PAIA procedures;
  • or accessing HealthLynk-generated information.

HealthLynk will not ask a user to provide unnecessary medical details merely to explain an accessibility problem.

30. Accessible Support

Users should be able to report an accessibility problem without needing to use the inaccessible functionality that caused the problem.

Accessibility enquiries may currently be submitted through:

Email: YangaSodoza@outlook.com Telephone: 074 663 3106

These details will be replaced with HealthLynk's official support contact once operational.

Where possible, please tell us:

  • which page or feature caused difficulty;
  • what you were trying to do;
  • what device or browser you were using;
  • what assistive technology you were using, if relevant;
  • and what problem you experienced.

You are not required to disclose a medical diagnosis in order to report an accessibility problem.

31. Accessibility Feedback

HealthLynk welcomes accessibility feedback.

Useful feedback may concern issues such as:

  • keyboard navigation;
  • screen-reader output;
  • focus visibility;
  • colour contrast;
  • text size;
  • mobile usability;
  • unclear forms;
  • inaccessible documents;
  • error messages;
  • payment accessibility;
  • or any other barrier that makes HealthLynk difficult to use.

Accessibility reports will be reviewed and prioritised according to their impact and severity.

32. Prioritising Accessibility Issues

When assessing an accessibility problem, HealthLynk may consider:

  • whether the issue prevents access to core functionality;
  • the sensitivity or importance of the affected information;
  • whether a workaround exists;
  • the number of people potentially affected;
  • the severity of the barrier;
  • whether the issue affects security or privacy;
  • the complexity of remediation;
  • and whether an interim accommodation can be provided.

Accessibility defects that prevent a person from independently accessing important health information should generally receive higher priority than minor cosmetic issues.

33. Testing Approach

HealthLynk intends to assess accessibility using a combination of:

  • automated accessibility testing;
  • manual keyboard testing;
  • screen-reader testing;
  • browser zoom and text-resize testing;
  • mobile and responsive testing;
  • colour-contrast review;
  • form and validation testing;
  • focus-management testing;
  • and review against relevant WCAG 2.2 Level AA requirements.

Automated testing alone will not be treated as proof that the Service is accessible.

Human review remains necessary because many accessibility barriers cannot be reliably identified by automated tools.

34. Assistive Technology Testing

As the Service matures, HealthLynk intends to test important user journeys with representative assistive technologies where reasonably practical.

Priority journeys may include:

  • creating an account;
  • signing in;
  • verification;
  • navigating the dashboard;
  • creating or managing a profile;
  • adding a health record;
  • uploading a document;
  • accessing the health timeline;
  • downloading an export;
  • managing sharing;
  • accepting or managing profile claims;
  • viewing subscription information;
  • subscribing;
  • and cancelling a subscription.

The combinations of browsers and assistive technologies used for testing may evolve over time.

35. Known Limitations

HealthLynk is an evolving platform.

At the date of this Statement, the production application has not yet completed the final formal WCAG 2.2 Level AA accessibility evaluation.

Potential limitations requiring verification include:

  • accessibility of generated PDF documents;
  • behaviour of complex file-upload interfaces;
  • modal and focus management;
  • mobile screen-reader behaviour;
  • payment-provider accessibility;
  • CAPTCHA accessibility;
  • PWA behaviour with assistive technologies;
  • status announcements in dynamic application interfaces;
  • and accessibility of user-uploaded health documents.

This section will be updated after the formal production accessibility audit.

HealthLynk will not knowingly claim that these areas fully conform until they have been appropriately assessed.

36. Pre-Launch Accessibility Review

Before HealthLynk makes a formal WCAG conformance statement, the production platform will be reviewed against relevant WCAG 2.2 Level AA requirements.

The review should include at least:

  • public landing pages;
  • registration;
  • sign-in;
  • email verification;
  • password recovery;
  • dashboard;
  • profile management;
  • health timeline;
  • encounter forms;
  • prescription workflows;
  • test workflows;
  • receipt workflows;
  • document upload;
  • document viewing;
  • profile invitations;
  • profile claiming;
  • access management;
  • exports;
  • account settings;
  • pricing;
  • subscription checkout;
  • cancellation;
  • privacy/contact forms;
  • legal/compliance pages;
  • error states;
  • maintenance pages;
  • mobile layouts;
  • and the installed PWA experience.

Any material accessibility defects identified should be recorded and prioritised for remediation.

37. Accessibility as the Platform Develops

Accessibility will be considered when introducing significant new functionality.

Examples include:

  • artificial-intelligence features;
  • OCR;
  • document extraction;
  • health-data visualisation;
  • notifications;
  • organisation dashboards;
  • healthcare-provider functionality;
  • mobile functionality;
  • and new forms or workflows.

New features should not unnecessarily regress accessibility already achieved elsewhere in the Service.

38. Procurement and Third-Party Components

When HealthLynk introduces significant user-facing third-party software or components, accessibility should be considered during selection.

Where multiple technically and commercially suitable options exist, accessibility may be one factor in choosing between them.

An inaccessible dependency should not automatically become a permanent exception merely because it was developed by a third party.

39. Reasonable Accommodation

Where a person encounters an accessibility barrier, HealthLynk will consider reasonable steps that may allow the person to access the relevant information or service.

The appropriate solution will depend on factors such as:

  • the nature of the barrier;
  • the requested functionality;
  • security;
  • privacy;
  • technical feasibility;
  • urgency;
  • and available alternatives.

Providing reasonable accessibility assistance does not require HealthLynk to weaken legitimate security controls protecting health information.

40. No Accessibility Surcharge

HealthLynk will not intentionally charge a customer an additional fee merely because the customer requires an accessible method of using an ordinary HealthLynk service.

Normal subscription charges may still apply to the underlying service.

Where a specific accessible format creates a legally permitted reproduction or PAIA-related fee, any such fee will be handled according to the applicable legal framework rather than imposed as a disability-related surcharge.

41. South African Equality Principles

HealthLynk supports the principle that people with disabilities should be able to participate meaningfully in digital services.

HealthLynk will not intentionally design its Service to unfairly exclude a person merely because of disability.

Accessibility practices will be reviewed alongside applicable South African equality, consumer-protection and other legal obligations.

42. No False Conformance Claims

HealthLynk will not claim that:

  • the Service is fully accessible;
  • the Service fully conforms to WCAG 2.2 Level AA;
  • every page has been accessibility tested;
  • every assistive technology is supported;
  • or HealthLynk has received an accessibility certification

unless the relevant statement can genuinely be supported.

Accessibility status will be described accurately and updated as testing and improvements are completed.

43. Changes to This Statement

HealthLynk may update this Accessibility Statement as:

  • accessibility testing is completed;
  • barriers are identified or resolved;
  • new functionality is introduced;
  • accessibility standards evolve;
  • supported technologies change;
  • or applicable legal requirements change.

The latest version will be published on the HealthLynk website.

Material updates will be reflected in the version number and last-updated date.

44. Contact HealthLynk About Accessibility

For accessibility questions, feedback or requests for assistance:

HealthLynk (Pty) Ltd Registration Number: 2026/646559/07 Director: Yanga Sodoza Website: healthylynk.com Email: YangaSodoza@outlook.com Telephone: 074 663 3106 Business address: 131 Eoan Ave, Eden Heights, Scottsdene, Kraaifontein, Cape Town, Western Cape, South Africa, 7570

When HealthLynk's official support email becomes operational, this Statement will be updated accordingly.

Related Documents

This Accessibility Statement should be read together with:

  1. HealthLynk Terms of Service
  2. HealthLynk Privacy Policy and POPIA Privacy Notice
  3. HealthLynk Refund, Cancellation and Subscription Policy
  4. HealthLynk PAIA Manual
  5. HealthLynk Medical Disclaimer
  6. HealthLynk Cookie Policy
  7. HealthLynk Security and Data Protection Statement
  8. HealthLynk Acceptable Use Policy

Pre-Publication Accessibility Verification

Before HealthLynk makes a formal accessibility-conformance claim, the production Service will undergo an accessibility review.

The final review will establish:

  • the WCAG version used for assessment;
  • the conformance level assessed;
  • pages and workflows tested;
  • automated-testing results;
  • manual-testing results;
  • keyboard accessibility;
  • screen-reader behaviour;
  • colour contrast;
  • zoom and reflow;
  • mobile accessibility;
  • form accessibility;
  • error identification;
  • focus behaviour;
  • authentication accessibility;
  • CAPTCHA accessibility;
  • document/export accessibility;
  • payment-flow accessibility;
  • third-party limitations;
  • known outstanding issues;
  • and remediation priorities.

Following that assessment, this Statement will be updated to accurately describe HealthLynk's actual conformance status.

HealthLynk (Pty) Ltd Your health information. Organised around you.