Accessibility

This directory is a public information service, so accessibility is a requirement rather than a nice-to-have. We target WCAG 2.2 Level AA.

How the site is built for it

• Semantic HTML throughout: real headings, lists, lists of results, and landmarks.
• A skip link as the first tab stop, so keyboard users can jump past the header.
• Every interactive element has a visible focus indicator, and focus order follows reading order.
• Search and filtering use native form controls and ordinary links — no custom widgets to reimplement keyboard behaviour for. Filtering works with JavaScript disabled.
• Access status is always stated in text, never communicated by colour alone.
• Touch targets are at least 44×44 px, meeting the WCAG 2.2 target-size criterion.
• Colour contrast is checked against the AA thresholds, including badge text.
• Motion respects prefers-reduced-motion.
• Layout reflows to 320 px width and remains usable at 400% zoom.
• Status messages (result counts, no-results notices) are announced as live regions.
• Error and empty states are designed pages, not dead ends.

How it is tested

• Automated, axe-core in a real browser: the WCAG 2.0 A/AA, 2.1 AA and 2.2 AA rule sets run against fourteen pages — homepage, search (empty, with a query, and with filters), resource, publisher index and detail, category index and detail, tag, contribute, about, data & API, accessibility statement and privacy. Any violation fails the build.
• Automated, keyboard: the skip link moves focus into the content, search is completable with the keyboard alone, and every interactive element is checked for a visible focus indicator.
• Automated, responsive: five page types are checked for horizontal overflow at 320, 390, 768, 1280 and 1600 px, at 200% text size, and the filter disclosure is verified as keyboard-operable on a small phone.
• Manual: rendered pages were reviewed at multiple widths, and heading hierarchy, landmark structure and list semantics were reviewed by hand.
• Outstanding: a screen-reader pass with an actual screen reader has not been done yet. The automated checks are a floor, not a substitute.

An automated scan passing is not the same as being accessible. We treat a clean axe run as a floor, not a certificate.

Known limitations

• Dark mode is not implemented. The single light theme is deliberate: it keeps the payload small and the contrast predictable. Honouring prefers-color-scheme is tracked rather than shipped.
• Very long publisher and category filter lists scroll rather than offering a searchable combo box. The control is a standard checkbox list, which is operable but slower to traverse with a screen reader once a list grows past a few dozen entries.
• Search results are paginated rather than virtualised, so a screen reader announces a new page of results on navigation. This is conventional and predictable, but it is not ideal.
• The interface is written in English only. Malay-language labels would help a lot of users, and the catalogue already understands Malay search terms — the chrome does not.

Tell us what is broken

If something here gets in your way, that is a bug and we want it. Open an issue in the repository describing what you were doing, what happened, and what you expected — the browser, assistive technology and input method you were using help a great deal.