Accessibility

Our commitment

Navira is used to issue documents a business is legally required to produce. If a person cannot operate the software, they cannot do their job — so we treat accessibility as part of whether the product works, not as a feature bolted on afterwards.

This page is written to be checked. Everything in “what we have built” corresponds to something in our code, and everything we know we have not done is listed under “known limitations” rather than quietly left out.

The standard we aim for

WCAG 2.1 Level AA is the standard we build against, for both the public site and the signed-in application, in English and in Arabic.

We have not been audited against it by an independent third party and we do not publish a conformance report. What follows is a self-assessment. Where we fall short of Level AA today, it is named below.

What we have built

• Fully bilingual, right-to-left native. Every screen exists in English and Arabic. The lang and dir attributes are set on the document server-side, from your language preference, before the page paints — so there is no flash of the wrong reading direction and assistive technology is told the correct language from the first frame. Arabic is laid out with logical properties, not by mirroring an English layout.
• Colour contrast is measured, not eyeballed. We have a real implementation of the WCAG 2.1 SC 1.4.3 relative-luminance and contrast-ratio formulas, covered by unit tests. It drives a live pass/fail AA badge on the branding screen, so a merchant choosing a brand colour is told immediately whether it clears 4.5:1 rather than finding out from a customer.
• Reduced motion is respected. A global prefers-reduced-motion: reduce rule caps every animation and transition in the interface, with additional targeted rules for the swipeable rows and the language switch. If your system asks for less motion, the interface stops moving.
• Form errors are announced. Validation and submission errors render with role="alert", so a screen reader reads them when they appear instead of only when focus happens to reach them.
• Every icon-only control has an accessible name. The shared icon-button and icon-link components require a label — there is no default, so a nameless icon control cannot be written in the first place. The footer's social links and the language switch carry their own names in both languages.
• Toggles report their state. The show/hide control on password fields is a real toggle button with aria-pressed, not an icon that silently changes meaning.
• Keyboard focus is always visible. Links, buttons, inputs, selects, text areas and anything focusable carry a focus ring driven by :focus-visible — shown for keyboard use, not flashed at every mouse click.
• Touch targets clear the guidance. Icon controls render at 36 CSS pixels with a 44-pixel hit area on touch devices, which passes the 24-pixel AA minimum and meets the 44-pixel AAA guidance where it matters most.
• The mobile menu behaves like a dialog. It is marked aria-modal, takes focus when it opens, returns focus to the button that opened it when it closes, and closes on Escape.
• Invoices print properly. A print stylesheet strips the application chrome — sidebar, menus, dialogs, notifications — so a printed or saved invoice is the document itself, at a readable size, rather than a picture of a screen.

Known limitations, and what we are working on

These are the gaps we know about. Some are being closed now; others are honest statements that we have not done the work, and we would rather say so than let you assume otherwise.

• The skip-to-content link is new and untested with assistive technology. Every public page now starts with a link that jumps past the header to the main content, visible as soon as it takes keyboard focus. It is implemented and reviewed in code, but it has not yet been exercised with a screen reader — see the point below.
• We have not tested end-to-end with screen readers. The semantics above are implemented and reviewed in code, but we have not yet worked through the main flows — issuing an invoice, filing a VAT return, reconciling a bank statement — with JAWS, NVDA or VoiceOver, in either language. Until we have, treat the list above as “implemented” rather than “verified in use”.
• No independent audit, and no conformance report. Nothing here has been checked by an external accessibility auditor, and we do not publish a VPAT or ACR. If your procurement process needs one, tell us and we will say plainly where we stand rather than produce a document to order.
• Accessibility checks are not automated in our build. We have no automated audit running against every page on every deploy, so a regression is caught by review rather than by tooling.
• PDF invoices are not tagged for screen readers. PDFs are produced by printing the HTML invoice through a headless browser, which gives correct Arabic shaping but does not emit a tagged document structure. The HTML invoice and the customer portal link are the accessible route to the same content. If you need a document in another form, ask us.
• The dense screens have not been audited one by one. Bank reconciliation, the journal, and the larger report tables involve wide tables and multi-step interactions that we have not reviewed individually for keyboard operation and screen-reader output.
• Contrast checking is not a full sweep. The measurement described above covers the brand colour a merchant selects. It is not an automated audit of every text and background pair in the product across both light and dark themes.
• There is no accessibility preferences panel. We follow your operating system and browser settings — language, reading direction, reduced motion, text size — rather than offering a second set of controls inside the product. That is a deliberate choice, but it means a preference we do not read from the system cannot be set at all.

Reporting an accessibility problem

If any part of Navira is difficult or impossible for you to use, tell us. Email privacy@shahmco.com or use the contact page.

It helps if you can tell us the page or screen, what you were trying to do, and which assistive technology and browser you were using — but do not hold a report back because you do not have those details.

We will respond within 30 days, and the response will say plainly whether the problem is fixed, scheduled, or something we are not going to change — not that it has been “noted”. If a barrier is stopping you from issuing a document you are legally required to issue, say so and we will treat it as urgent.

Scope

This statement covers the Navira public site and the signed-in application. It does not cover the tax authorities' own portals, which we do not build or control. See also our security page and privacy policy.