Accessibility

1. Our Commitment

Pathrel Limited is committed to making the Pathrel careers and education catalogue usable by as many people as possible, including those with visual, motor, cognitive, and hearing impairments. This site is meant to be usable on a slow connection, on a small screen, with a keyboard, and with a screen reader, and we treat accessibility as a core engineering requirement rather than a compliance exercise.

We target WCAG 2.2 Level AA as our baseline standard. That is the standard we measure ourselves against, not a claim of having reached every part of it. The gaps we currently know about are listed in Section 4, and we will not claim full conformance until they are closed and independently verified.

This statement applies to the public catalogue at pathrel.com and its subdomains. It does not cover the operator console, which is an internal tool used by trained staff, though we apply the same engineering principles there.

2. What Already Works

The following accessibility features are built into the site today:

2.1 Keyboard Navigation

• Every page is fully keyboard reachable. A visible focus ring follows the cursor as you tab through links, buttons, and form fields.
• A skip to content link is the first element on every page. It is hidden until focused, then appears as a visible button that jumps past the navigation to the main content.
• Logical tab order follows the visual layout. Menus, forms, and interactive controls can be operated without a mouse.
• Keyboard shortcuts do not conflict with browser or screen reader shortcuts, and no feature requires a mouse-only interaction.

2.2 No JavaScript Required

• The entire catalogue is usable with scripting disabled or still loading. Search is an ordinary HTML form, filters and sorting are real links, and pagination is links rather than JavaScript-driven page changes.
• This matters because assistive technology users, security-conscious readers, and people on very slow connections often browse with JavaScript off.
• Content appears in the HTML on first render, so it is available to screen readers and search engines without waiting for client-side hydration.

2.3 Screen Reader Support

• Rankings are real HTML tables with column headers and captions, rather than rows of styled divs, so a screen reader can announce what a number belongs to.
• Navigation regions, search, and pagination carry appropriate ARIA labels and roles.
• Form fields have associated labels, and the honeypot fields hidden from assistive technology are marked aria-hidden.
• The page language is declared as English in the HTML element, so screen readers use the correct pronunciation.
• Status messages, such as form submission feedback, use ARIA live regions so they are announced without requiring the user to navigate to them.

2.4 Visual Design

• Colour is never the only signal. An exposure rating is always printed as a number as well as a coloured bar. Status indicators carry text labels alongside their colour.
• Both themes are contrast checked. The light theme exists precisely because a dark interface is harder for some readers. Both meet WCAG AA contrast ratios for body text.
• Text scales with the browser. The layout is built in relative units (rem, ch, viewport percentages), so increasing the font size in your browser or operating system does not break the layout or cause overlapping text.
• Pages are responsive. The catalogue is usable on a small phone over a slow connection, not only on a desktop with fibre. Layouts reflow rather than requiring horizontal scrolling at common viewport widths.

2.5 Motion and Animation

• Motion respects your settings. With prefers-reduced-motion enabled in your operating system or browser, all animations are removed rather than shortened. Counters jump straight to their final value, reveal animations are skipped, and decorative motion stops entirely.
• The three-dimensional decorative figures stop moving entirely under reduced motion, and every fact they show also appears as text nearby.
• No animation flashes more than three times per second, to avoid triggering photosensitive seizures.

2.6 Figures and Data

• Every figure carries a text description of what it plots, and no figure is the only place a fact appears. A chart that shows exposure by sector is accompanied by the same numbers in the caption or body text.
• Decorative three-dimensional figures are marked aria-hidden, so a screen reader does not attempt to interpret them.
• Data tables include scope attributes on header cells, so a screen reader can announce the row and column context for each value.

2.7 Forms and Input

• Every form field has a visible label and an associated HTML label element, so screen readers announce the field's purpose when focus moves to it.
• Required fields are marked with both a visual indicator and the HTML required attribute, so the browser enforces validation and screen readers announce the requirement.
• Error messages are associated with their fields via aria-describedby, so a screen reader reads the error when focus returns to the field after a failed submission.
• Input sizes on mobile use text-base to prevent iOS auto-zoom, which disorients users who rely on magnification.

3. Standards and Guidelines

We measure our work against the following standards:

• Web Content Accessibility Guidelines (WCAG) 2.2, Level AA, published by the W3C. This is our primary conformance target.
• Kenya Persons with Disabilities Act, which requires reasonable accommodation for persons with disabilities accessing digital services.
• Kenya Information and Communications Act, under which the Communications Authority of Kenya sets accessibility expectations for digital platforms.
• ARIA Authoring Practices Guide, for patterns that go beyond what native HTML provides.

We do not currently hold a formal accessibility certification. When we do, it will be named here, along with the certifying body and the date of certification.

4. Known Gaps

We test continuously, but the following issues are known and not yet resolved:

1. Screen reader testing is incomplete. The catalogue has not yet been tested end to end with NVDA, JAWS, or VoiceOver across every page type. Until that testing is complete and findings are addressed, we will not claim conformance.
2. Long unbroken text in some records. Certain records hold long paragraphs written for an internal audience, which read awkwardly when spoken aloud. We are reviewing these on a cycle.
3. Form errors are visual only in some places. Some form validation errors are announced visually rather than through an ARIA live region, so a screen reader may not read them automatically after a failed submission.
4. Drag and drop in the comparison tool. The career comparison feature relies on drag and drop for reordering, and does not yet offer a keyboard alternative for that action.
5. Focus management on dynamic content. When some interactive sections expand or filter their contents, focus is not always moved to the updated region, which can disorient a keyboard or screen reader user.
6. Colour contrast on small text. Some secondary metadata text (timestamps, tag labels) sits close to the AA threshold at small sizes. We are adjusting these tokens.
7. Video and audio content. The site does not currently host video or audio, but when it does, captions and transcripts will be provided from launch. This is listed as a gap so it is not forgotten.
8. Mobile gesture alternatives. Some swipe-based interactions on mobile devices do not have tap-based alternatives, which may affect users who cannot perform swipe gestures.

5. How to Get a Record in Another Format

If a record is hard to read in its current form, write to us and we will send it to you in one of the following formats:

• Plain text, with all figures and fields listed in a linear document.
• Large print, with the body text set at 18pt or larger.
• A spoken recording, read aloud and sent as an audio file.
• A structured data file, such as CSV or JSON, for users who prefer to process catalogue data with their own tools.

We aim to provide alternative formats within five working days of the request. There is no charge for this service.

6. Reporting an Accessibility Problem

If something here is hard or impossible to use, that is a defect and we want the report. Write to [email protected] with:

• The page URL where you encountered the problem.
• What you were trying to do.
• What happened instead.
• The browser, device, and assistive technology you were using, if any.
• Whether the problem is consistent or intermittent.

We will reply within five working days. If you need a record read out or sent in another format while we fix the underlying issue, ask and we will send it.

7. Enforcement and Complaints

If you are not satisfied with our response, you have the right to escalate:

• Kenya National Commission on Human Rights (KNCHR): Handles disability rights complaints under the Persons with Disabilities Act. They can investigate and recommend remedies.
• Communications Authority of Kenya (CA): For matters relating to access to digital services and electronic platforms.
• Office of the Data Protection Commissioner (ODPC): For matters where an accessibility failure also involves personal data.

We will cooperate fully with any investigation and provide records of our accessibility work on request.

8. Review Schedule

This statement is reviewed at least every six months, and whenever a significant feature is added or a known gap is closed. The "Last updated" date on the page reflects the most recent revision.

Previous versions of this statement are available on request from [email protected].

9. Contact

For any question about this statement or accessibility at Pathrel:

• Email: [email protected]
• Postal: Pathrel Limited, Nairobi, Kenya
• Response time: Five working days for accessibility reports, two working days for urgent blockers

We take every report seriously. The person who reads that inbox is the person who can fix what you found.