Accessibility information you can review — and a clear route to support.
Learn about our accessibility approach, the scope of available information, and how to report an access barrier or request an alternative format.
A design target is not a conformance assessment. Any validated status and known limitations will be stated with its scope and review date.
01 · Our approach
Building for different ways of using the web.
Our design goal is that people can navigate, understand and use TEMVERIS services through more than one interaction method. Tested coverage and current limitations must be assessed and published separately.
Perceivable information
Text alternatives, captions and content that does not rely on color alone.
Operable controls
Keyboard access, visible focus and generous targets.
Understandable journeys
Clear labels, predictable navigation and recoverable errors.
Compatible interfaces
Semantic structure that works with assistive technologies.
No global claim of independent certification or full conformance is made on this page.
02 · What this covers
Check the experience and scope relevant to you.
Coverage and assessment dates vary by experience. A scope without evidence must remain unverified.
Public website
This page and the public marketing site. No published assessment — request documentation.
Product web application
Record review, approvals and administration. No published assessment — request documentation.
Mobile experience
Responsive web on phones and tablets. No published assessment — request documentation.
Documentation and downloads
Guides, help content and any PDFs. No published assessment — request documentation.
Sign-in and account access
Authentication and account recovery. No published assessment — request documentation.
Connected experiences
Third-party or customer-configured surfaces. No published assessment — request documentation.
03 · Standards
Understand the standard and the evidence.
WCAG 2.2 Level AA is the design and acceptance target for the proposed page and workflows. A target, a self-check and an independent assessment are different kinds of information.
TARGET
What we design toward
WCAG 2.2 AA guides design and acceptance.
SELF-CHECK
What our team reviewed
Results need documented evidence before publication.
ASSESSMENT
What an assessment found
Requires documented scope, method and approval.
04 · Testing methods
How accessibility can be evaluated.
The methods listed describe the planned verification model; executed test results require documented evidence.
| METHOD | WHAT IT CHECKS | WHAT IT DOES NOT PROVE | RESULT |
|---|---|---|---|
| Automated checks | Missing names, contrast, structure issues | Most barriers in real use | Not yet published |
| Keyboard review | Tab order, focus visibility, traps | Screen-reader announcements | Not yet published |
| Screen-reader review | Names, roles, states, announcements | Every browser/AT combination | Not yet published |
| Zoom and text spacing | Reflow at 400%, spacing overrides | Cognitive load of content | Not yet published |
| Mobile touch | Target size, orientation, gestures | Desktop keyboard paths | Not yet published |
| User testing | Real tasks with disabled participants | Full coverage of every journey | Not yet published |
05 · Accessible journeys
Accessibility matters in the moments that matter.
These illustrative patterns describe the intended experience of reviewing a governed workforce record. Conceptual illustration — not evidence that product screens have passed an assessment.
Open menus, move between sections, activate buttons and links, complete forms, and dismiss dialogs with the keyboard. Focus must be visible and must not be hidden behind sticky navigation.
- Tab / Shift+Tabmove
- Enter / Spaceactivate
- Escclose
- ← →tabs
06 · Documentation & limitations
Access the information in a format that works for you.
When documentation is available, a readable web version should be the default. Some materials may also be provided in another accessible format on request.
Known limitations and the next practical step
If an accessibility limitation has been verified, we publish the affected experience, a usable workaround where available, its review date and how to ask for help.
No verified limitations are published for this scope. This does not mean testing found no barriers.
07 · Report a barrier
Tell us where access is difficult.
No demo or sales conversation required. This preview does not send anything.
08 · Another format
Need the information in another format?
09 · After you contact us
What happens after you contact us?
Received
Your report is received if the request service confirms delivery.
Reviewed
The support owner reviews it.
Next steps
Follow the applicable support process.
A received request does not mean an issue is fixed or an accommodation is approved.
10 · Materials & environments
Review the accessibility materials that are available.
Availability and scope of reports depend on published owner-reviewed documentation. Request additional details when an item is not publicly available.
Public accessibility statement
This page: HTML
Scope and method summary
On request
Evaluated limitations
Published once verified
Conformance report
Only if approved
Accessible-format guidance
HTML, structured text, tagged PDF where available
Tested environments and what those results mean
If verified testing results are available, we will list the supported experience, browser/assistive technology combination, date and known limitations. Untested combinations have not necessarily been found incompatible; they may be untested.
11 · Questions
Accessibility questions, answered clearly.
12 · Enterprise evaluation
Evaluating TEMVERIS for your organization?
Ask about the accessibility scope relevant to your teams, procurement process and deployment. We will route the inquiry to the appropriate reviewer. Reporting a barrier never requires a demo.
Need help or want to report an access barrier?
Choose the route that fits your need: report a barrier, request another format, or ask for evidence for your organization.