AWRA OpsHub Search

Accessibility Statement

Building AWRA for inclusive and practical use

AWRA is used across teams with different abilities, environments, and device constraints. Accessibility is a product quality requirement, not a separate feature.

This statement describes our approach, current focus areas, and how we incorporate user feedback into ongoing improvements.

Accessible collaborative workspace

Perceivable

Content and interface components are designed to remain legible and understandable across devices and viewing conditions.

Operable

Critical flows are tested for keyboard accessibility and predictable interaction patterns where practical.

Understandable

We favor plain, contextual language for core tasks to reduce cognitive load in high-pressure workflows.

Our accessibility approach

Inclusive design starts in planning. We evaluate interface concepts for readability, hierarchy, and interaction clarity before implementation. This prevents inaccessible patterns from becoming entrenched in complex workflows.

Accessibility review is integrated into iterative delivery. We monitor color contrast, form labeling, focus management, and semantic structure as screens evolve. Small defects can compound quickly in enterprise products, so frequent review is critical.

We prioritize high-usage pathways first, including navigation, search, forms, approvals, and reporting views. Improving these paths creates immediate impact for a broad range of users while establishing stronger patterns for future modules.

Accessibility is also operational. Documentation, onboarding language, and support processes influence whether users can complete work effectively. We continue refining these layers based on customer feedback and observed friction.

Appearance and contrast

AWRA can be used light or dark. Each person chooses Light, Dark, or System — which follows the setting on their own computer or phone — and the choice applies to that person only, never to the whole organization. On the web the preference is stored on your account, so it follows you between devices; in the Android app it is stored on the handset, so a shared night-shift phone can stay dark for whoever picks it up next. Printing, PDFs and email stay light in every case, because a document is read on paper.

Dark mode is where contrast defects usually hide: a colour that was never stated is inherited from the browser, and a colour that was stated as a fixed value stops matching the surface behind it once the surface moves. Both fail silently, and both look correct in a light-mode screenshot. So the appearance layer is checked mechanically rather than by eye. Every colour in the dashboard resolves through a named token with a defined value in each theme, an automated check resolves each text colour against the background it actually sits on after the theme flips, and a second check refuses new hard-coded colours in the interface. All three run on every change and block release on a single finding — there is no threshold to relax and no allowance to spend.

Where an exception is genuinely correct — a barcode, which a scanner needs as dark ink on a light plate whatever the theme, or text on a fixed brand colour — it is listed individually with its reason rather than waved through as a class. Two things are deliberately outside the theme: machine-readable codes, and text intended to read as inactive, such as input placeholders and disabled controls, which are never used to carry information on their own.

This describes our own testing, not a third-party audit. We have not certified AWRA against a WCAG conformance level, and we would rather say so here than imply an assessment we have not had. If a screen is hard to read in either appearance, tell us which one and we will treat it as a defect.

Current focus areas

Keyboard interaction consistency in complex forms and data-heavy screens.

Descriptive labeling for controls used in procurement and finance workflows.

Error guidance clarity to support faster recovery during transaction entry.

Responsive layout behavior for users relying on zoom and smaller screens.

Feedback and remediation

We encourage users and admins to report accessibility barriers with task context.

Reported issues are triaged for impact and complexity, then scheduled into delivery cycles.

Where immediate fixes are not possible, we provide practical alternatives when available.

Our goal is continuous improvement through transparent, user-informed iteration.

Need to report an accessibility issue?

Share the workflow, device, and specific barrier so our team can reproduce and prioritize remediation effectively.

Contact Accessibility Team

Inclusive delivery across devices and contexts

Our users work in offices, warehouses, field operations, and low-bandwidth environments. Accessibility quality includes semantic UI, readable hierarchy, predictable feedback, and resilient responsiveness under zoom or mobile usage.

We continuously improve keyboard navigation, error messaging clarity, focus states, and contrast handling across high-traffic workflows.

Public accessibility commitments help procurement, IT, and operations leaders evaluate platform fit for diverse teams and real-world working conditions.

Inclusive digital interface testing across devices

Help Center

Need a quick answer while you read?

Run inventory, procurement, assets, sales, and field work with approved AWRA guidance for setup, migration, integrations, security, pricing, and support.

Search all approved AWRA public help articles.

Open Help Center