Skip to main content

Industrial parts & procurement · Bangladesh-first, globally extensible

GRITNOX

Accessibility

Technical interfaces still have to work for people.

Gritnox targets WCAG 2.2 Level AA for the public catalog and documentation surfaces. This page records the measures in place, the limits that remain and the route for reporting a barrier.

WCAG 2.2 AA targetFeedback open
Report a barrier

01 · Standard

Target standard and scope

The public Gritnox experience is designed toward the Web Content Accessibility Guidelines (WCAG) 2.2 Level AA. Scope includes the homepage, catalog and part records, equipment and supplier directories, sourcing list and RFQ flow, contact intake and the public policy and documentation pages.

Role-scoped workspaces

The buyer, seller, administrator, chat, analytics and checkout workspaces are part of the current application, but they have not received the same accessibility review as the Gritnox public surfaces.

02 · Interface

Measures implemented in the public interface

Landmarks and headings

The shell exposes a banner, primary navigation, main content, footer and named document navigation regions.

Keyboard path

A skip link moves focus to the main content. Interactive elements use native links, buttons, selects, details and form controls.

Visible focus

A consistent focus ring is defined globally and interactive components preserve a visible focus state.

Responsive layout

Pages reflow without a fixed-width requirement, and dense tables use a local horizontal scroll container on small screens.

Non-color cues

Evidence and status badges include text labels. Color supports meaning but is not the only carrier.

Reduced motion

Animations and smooth scrolling are suppressed when the operating system requests reduced motion.

03 · Content

Content, forms and error handling

  • Form controls have associated labels, and required fields are identified in text rather than color alone.
  • Contact and RFQ errors are announced through alert regions and paired with field-level guidance where applicable.
  • Decorative icons and grid backgrounds are hidden from assistive technology; meaningful icons retain text labels.
  • Links and buttons use descriptive language instead of ambiguous standalone phrases where the interface permits it.
  • Documentation uses structured headings, lists, tables and plain-language summaries before technical detail.
  • The source list avoids relying on hover to reveal essential information.

04 · Verification

How accessibility is tested

The current verification process combines TypeScript and production-build checks, semantic review of the shared components, keyboard-only navigation, responsive inspection and manual contrast review of the design tokens.

Verification gap

Automated accessibility testing, screen-reader matrix testing and an independent audit are not yet part of the enforced repository checks. The project does not claim that every route passes WCAG 2.2 AA until those checks are completed and documented.

05 · Limits

Known limitations

  • Some dashboard, chart, map and chat screens have not received a dedicated accessibility review.
  • Font Awesome and Google Fonts are loaded from external providers; a blocked or slow provider can affect icons or typography.
  • Dense comparison tables require horizontal scrolling on narrow screens rather than a fully transformed mobile representation.
  • Some small metadata text uses reduced contrast for visual hierarchy and may not meet the target in every context.
  • Third-party checkout or media flows may introduce barriers outside the Gritnox public shell.
  • No formal screen-reader certification has been completed for this concept.

06 · Feedback

Report an accessibility barrier

Use the contact intake and select Accessibility feedback. Include the page path, the task you were attempting, the assistive technology or input method involved and the outcome you expected. Do not include passwords, payment details or confidential drawings.

Open contact intakeRead the help center

Accessibility requests are recorded as demo inquiries with a reference. A future production operator must publish a response process, remediation timeline and formal escalation route.